IETF Logo Mail Archive

Re: [rtcweb] Proposed Video Selection Process

Stefan Slivinski <sslivinski@lifesize.com> Thu, 21 November 2013 19:34 UTC

Return-Path: <sslivinski@lifesize.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 223BB1AE0EC for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 11:34:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFhm9IxRFl8V for <rtcweb@ietfa.amsl.com>; Thu, 21 Nov 2013 11:34:46 -0800 (PST)
Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with SMTP id E97721AE0F1 for <rtcweb@ietf.org>; Thu, 21 Nov 2013 11:34:45 -0800 (PST)
Received: from mail1.lifesize.com ([207.114.244.10]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKUo5gTkgEJcqxfRM1/SyemvjDcXIgA/Jm@postini.com; Thu, 21 Nov 2013 11:34:39 PST
Received: from ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109]) by ausmsex00.austin.kmvtechnologies.com ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Thu, 21 Nov 2013 13:31:07 -0600
From: Stefan Slivinski <sslivinski@lifesize.com>
To: "'rtcweb@ietf.org'" <rtcweb@ietf.org>
Date: Thu, 21 Nov 2013 13:31:05 -0600
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: Ac7m68Cf7/thuJ34R3Orj6krJlGcVgABHgHr
Message-ID: <7949EED078736C4881C92F656DC6F6C130EA8AD7DA@ausmsex00.austin.kmvtechnologies.com>
In-Reply-To: <528E57EC.6020000@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] Proposed Video Selection Process
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Nov 2013 19:41:38 -0000

I'm a new comer, so just a brief intro: I have a background developing real time video codecs for embedded devices so I'm in a position to comment at a technical level within this group

For clarity purposes the proposed alternatives in Magnus' email on nov 18th; are we strictly speaking about decoders?  Historically mandatory requirements are they relate to video compatibility define just the decoders.  Obviously if there is only a single mandatory video decoder this implies a mandatory encoder, however in the case where there are 2 mandatory decoders only a single encoder is technically required.

Clarifying this is fairly important because in the case of both h264 and vp8 (and in the future vp9 and h265) the decoder complexity is fairly low and hardware acceleration is not critical but in the case of the encoders where the complexity can be 3x or worse, hardware acceleration becomes increasingly important

Stefan


----- Original Message -----
From: Adam Roach [mailto:adam@nostrum.com]
Sent: Thursday, November 21, 2013 12:58 PM
To: Magnus Westerlund <magnus.westerlund@ericsson.com>; rtcweb@ietf.org <rtcweb@ietf.org>
Subject: Re: [rtcweb] Proposed Video Selection Process

On 11/21/13 08:51, Magnus Westerlund wrote:
> We (WG chairs) are proposing that the working group consent to a method
> that will establish an MTI, even if the MTI chosen does not have rough
> consensus.

Although this is phrased very carefully, I think this email 
inadvertently glosses over the fact that this is a formal call for 
consensus around the proposed approach. I also think you need to be 
crystal clear -- and I'm going to borrow RFC 3929's language here -- 
"that the working group's consensus to use [this specific] method stands 
in for the working group's consensus on the technical issue."

I wanted to point this out because it would be very easy to accidentally 
read the email as an announcement for the way the codec will be 
selected, rather than a call for consensus around a proposed approach.

/a
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb

v2.23.0 | Report a Bug | By Email