Re: [rtcweb] Video codec selection - way forward

[Gili <[e-mail]>]

+1

On 19/11/2013 1:09 AM, Maik Merten wrote:
> I'm sure the prospect of implementing H.261 is not a desirable one but 
> I wonder if
>
>  - implementing the codec of "the other codec camp" is more desirable
>  - the end-users will appreciate spuriously failing video calls
>
>
> Basically this boils down on what the question is. "Who enjoys 
> implementing H.261?" clearly will be answered as "nobody". However, 
> "who can live with the inconvenience of implementing H.261 for the 
> sake of interoperability and accessibility" may be answered differently.
>
> It would, of course, be preferable if H.261 can be substituted with a 
> higher performing alternative, although I guess the set of codecs with 
> a universally accepted status as "no worries regarding IPR or 
> licensing" is limited.
>
>
> Maik
>
>
> Am 19.11.2013 01:07, schrieb David Singer:
>> It's an interesting idea, but the quality of H.261, the availability 
>> of decent implementations, and its (functional) restrictions may mean 
>> that people are very loath to spend (waste) engineering time on it.  
>> Is this a MUST that would, in fact, get respected?
>>
>>
>> On Nov 17, 2013, at 11:54 , Maik Merten <[e-mail]> 
>> wrote:
>>
>>> Hello,
>>>
>>> just wondering if something like
>>>
>>> "9. All entities SHOULD support both H.264 and VP8. All entities 
>>> MUST at least implement one of those. Entities that do not support 
>>> both H.264 and VP8 MUST implement H.261."
>>>
>>> has already popped up. My reasoning is that implementations 
>>> supporting both high performance codecs will always negotiate to use 
>>> on of those - H.261 should never be relevant there.
>>>
>>> It appears that all implementors are willing to implement either 
>>> H.264 or VP8 (but not necessarily both). This obviously means that 
>>> negotiation failure regarding a high-performance codec is a 
>>> possiblity. In this case H.261 is actually useful so that basic 
>>> video calls can still be established (for instance, I guess deaf 
>>> people may always appreciate a video connection, as long as sign 
>>> language can be transmitted).
>>>
>>>
>>> Maik
>>>
>>>
>>> Am 14.11.2013 12:37, schrieb Jeremy Fuller:
>>>> Hi,
>>>> Gaining IETF consensus on making it mandatory to support only H.264 or
>>>> only VP8 has clearly failed. I would welcome anyone to share their
>>>> thoughts on why they believe this situation will change anytime in the
>>>> next few years.  Therefore, can I suggest that we remove items 1 and 2
>>>> from the list. Hopefully this will speed up the process by focusing
>>>> efforts towards gaining agreement on one of the remaining options.
>>>> The following alternatives has been proposed:
>>>>
>>>> 1. All entities MUST support H.264
>>>> 2. All entities MUST support VP8
>>>> 3. All entities MUST support both H.264 and VP8
>>>> 4. Browsers MUST support both H.264 and VP8, other entities MUST
>>>>     support at least one of H.264 and VP8
>>>> 5. All entities MUST support at least one of H.264 and VP8
>>>> 6. All entities MUST support H.261
>>>> 7. There is no MTI video codec
>>>> 8. All entities MUST support H.261 and all entities MUST support at
>>>>     least one of H.264 and VP8
>>>>
>>>> Regards,
>>>> Jeremy Fuller
>>>>
>>>>
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>>
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb