Re: [rtcweb] Proposed Video Selection Process

Paul Giralt <> Fri, 22 November 2013 19:57 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 918C91AE01A for <>; Fri, 22 Nov 2013 11:57:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.026
X-Spam-Status: No, score=-15.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MlY1EcxVSdaI for <>; Fri, 22 Nov 2013 11:57:11 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 27AAD1ACCEA for <>; Fri, 22 Nov 2013 11:57:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=8863; q=dns/txt; s=iport; t=1385150224; x=1386359824; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=eyeYCDBK7i7FJfmKOKfGN7TN2Z9QxdoKfZ0r/raqiW4=; b=WEkazNn4qDDNnxpAWgl1kBAIcfIukqu3vD8zoZW6PmU6MxzpOyIAnbu2 V5Z2Cj/Xp/OjAVSc8+jLWlK53EvptsN3FDR6PnffSkwWfNFei3qJabqz7 A383ssdk4si08BFjV/6/MzVLgRfm+3LTlCN0ZudsXg+5x6B9QNZ9dJGZR c=;
X-Files: signature.asc : 841
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.93,753,1378857600"; d="asc'?scan'208"; a="286752425"
Received: from ([]) by with ESMTP; 22 Nov 2013 19:57:03 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id rAMJv2Wa020845 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Nov 2013 19:57:03 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_157A422D-0369-4B3E-AFA4-711DE2C5CF00"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\))
From: Paul Giralt <>
In-Reply-To: <>
Date: Fri, 22 Nov 2013 14:57:01 -0500
Message-Id: <>
References: <> <> <> <> <> <>
To: Matt Fredrickson <>
X-Mailer: Apple Mail (2.1812)
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 19:57:13 -0000

I may be missing something but I don't know that this is entirely correct. From 3264: 

   The list of media formats for each media stream conveys two pieces of
   information, namely the set of formats (codecs and any parameters
   associated with the codec, in the case of RTP) that the offerer is
   capable of sending and/or receiving (depending on the direction
   attributes), and, in the case of RTP, the RTP payload type numbers
   used to identify those formats.

To me, this means that a capability in an offer or answer (with a direction attribute of sendrecv) means that you are capable of both sending and receiving for that particular capability. I don't see a way where you can specify (within a single m= line) that you are capable of receiving on two of the specified payload types, but only capable of sending on one of the two. In other words, if an offer or answer specifies both H.264 and VP8 with a sendrecv attribute, this implies that you are capable of both sending and receiving both. 

You could, of course, specify two separate m= lines where you specify both codecs as recvonly and the codec you support for sending as sendonly, but this is very complicated because now you have two separate m= lines for what really should be one bi-directional stream. 

Someone please correct me if I'm misunderstanding this. 


On Nov 22, 2013, at 2:10 PM, Matt Fredrickson <> wrote:

> That is my understanding of O/A as well (at least last time I had to
> deal with this in RFC3264 land).
> Matthew Fredrickson
> On Fri, Nov 22, 2013 at 11:19 AM, Roman Shpount <> wrote:
>> Actually O/A model is asymmetric by default. All you specify in SDP are the
>> codecs you can receive. You are allowed to send a stream in any codec remote
>> side supports. So if both sides state that they support codecs X and Y in
>> SDP, one side can send X in one direction and another side can send Y in
>> opposite.
>> _____________
>> Roman Shpount
>> On Fri, Nov 22, 2013 at 11:40 AM, tim panton <> wrote:
>>> Surely this flies in the face of the whole O/A model, which imposes a sort
>>> of symmetry on the endpoints ?
>>> (Unless there is some arcane SDP FRACK at play here).
>>> T.
>>> On 22 Nov 2013, at 08:24, Silvia Pfeiffer <>
>>> wrote:
>>> I think this has value. It might bring apple and Microsoft to the table,
>>> since decoding-only is often the less patent-affecting part.
>>> Silvia.
>>> On 22 Nov 2013 02:24, Martin J. Dürst <> wrote:
>>>> 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.
>>>> _______________________________________________
>>>> rtcweb mailing list
>>> _______________________________________________
>>> rtcweb mailing list
>>> _______________________________________________
>>> rtcweb mailing list
>> _______________________________________________
>> rtcweb mailing list
> _______________________________________________
> rtcweb mailing list