Re: [rtcweb] Proposed Video Selection Process

Stefan Slivinski <> Fri, 22 November 2013 16:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 071E51AE163 for <>; Fri, 22 Nov 2013 08:16:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tsI2E0fv4ipF for <>; Fri, 22 Nov 2013 08:16:24 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id 1B4CB1ADFDA for <>; Fri, 22 Nov 2013 08:16:22 -0800 (PST)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID DSNKUo+DTng5K3Uvt863Ja37tbnfIeH458t/; Fri, 22 Nov 2013 08:16:17 PST
Received: from ([fe80::edad:d9e3:99d1:8109]) by ([fe80::edad:d9e3:99d1:8109%14]) with mapi; Fri, 22 Nov 2013 10:09:52 -0600
From: Stefan Slivinski <>
To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <>
Date: Fri, 22 Nov 2013 10:09:49 -0600
Thread-Topic: [rtcweb] Proposed Video Selection Process
Thread-Index: Ac7nbQV3sTFvF7d3RpyCmDUGOXlt8AALveuw
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "''" <>
Subject: Re: [rtcweb] Proposed Video Selection Process
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Nov 2013 16:16:27 -0000

Something else worth noting with the proposal of "MUST implement both VP8 and H.264 decoders, and MUST implement at least one of VP8 and H.264 encoders", 
It allows you to choose the appropriate codec for your architecture, especially those architectures where there is hardware acceleration for only one encoder.  It would be very undesirable for a vendor be able to send H.264 at 1080p but only 360p for VP8 because they didn’t have hardware acceleration available for it.  Decoders are less of a concern because they are far less complex.

Another point worth noting:  there are far less patents on decoders than on encoders, so it allows a vendor to mitigate their risk by choosing the encoder they feel most comfortable with.

-----Original Message-----
From: "Martin J. Dürst" [] 
Sent: Friday, November 22, 2013 2:24 AM
To: Stefan Slivinski
Cc: ''
Subject: Re: [rtcweb] Proposed Video Selection Process

On 2013/11/22 5:02, Stefan Slivinski wrote:
> I in no way intended to suggest  a specific implementation of a video 
> codec.  My question was around whether we are voting on requiring 
> decoders (my assumption) or both encoders and decoders

My understanding is that all the proposals in each instance mean "both encoder and decoder". So as an example, a proposal of "MUST implement both VP8 and H.264" means "MUST implement both VP8 encoder and decoder, and H.264 encoder and decoder".

Your question brings up other choices. For example, interoperability would be satisfied by something like "MUST implement both VP8 and H.264 decoders, and MUST implement at least one of VP8 and H.264 encoders".

One condition for this to work is the possibility of asymmetric communication, i.e. if side A implemented only a VP8 encoder, and side B only implemented a H.264 encoder, then traffic A->B would be VP8, whereas traffic B->A would be H.264. I don't know the in's and out's of the negotiation and protocol machinery to confirm or deny that this is possible.

Choices like the one above definitely open new horizons for Eric's selection generator. But frankly speaking, except for the specific choice of "MUST implement both VP8 and H.264 decoders, and MUST implement at least one of VP8 and H.264 encoders", which is less onerous than "MUST implement both VP8 and H.264", but still interoperable, I don't see any choices with different requirements for encoders and decoders that would make sense.

Regards,   Martin.

> ----- Original Message -----
> From: Basil Mohamed Gohar []
> Sent: Thursday, November 21, 2013 01:56 PM
> To:<>
> Subject: Re: [rtcweb] Proposed Video Selection Process
> On 11/21/2013 02:31 PM, Stefan Slivinski wrote:
>> 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
> What is being specified as MTI is a format, and not a specific 
> implementation.  So, MTI will not take the form of "OpenH264" or 
> "libvpx", but rather, "H.264 Constrainted Baseline Profile" or "VP8".
> The same was done for the MTI audio codec, which is Opus, not 
> *libopus*, which is one specific implementation of the codec.
> There was a suggestion that the WG also offer a reference 
> implementation of the MTI codec choice, but that seems like it won't 
> happen, nor is it really the purpose of the WG to do so.  We are 
> picking from already-existing and implemented formats in the first place.