Re: [rtcweb] Proposed Video Selection Process

[Matt Fredrickson <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>> 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 <[e-mail]> 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 [mailto:[e-mail]]
>>>> Sent: Thursday, November 21, 2013 01:56 PM
>>>> To: [e-mail]<[e-mail]>
>>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>