Re: [rtcweb] confirming sense of the room: mti codec

[Randell Jesup <[e-mail]>]

On 12/8/2014 8:19 PM, David Singer wrote:
>> On Dec 8, 2014, at 10:00 , Iñaki Baz Castillo <[e-mail]> wrote:
>>
>> 2014-12-08 18:55 GMT+01:00 Randell Jesup <[e-mail]>:
>>> +1 - it's by no means my preferred solution, but it's one I can live with,
>>> and better than the alternative of the status-quo - no MTI at all.  If it
>>> wasn't for OpenH264, my answer would be different.
>>>
>>> I can't see adopting H.264 as sole MTI, and I can't see that we'd get
>>> consensus to adopt VP8 as sole MTI.
>> There was a much better solution:
>>
>> - Don't make VP8 nor H264 MTI.
>> - So for now no MTI video codec.
>> - And a W3C compromise: First video codec 100% royalty free would
>> become MTI in WebRTC.

And engender endless further discussions about what is "100% royalty 
free".  I'll note that even MPEG-LA deciding to RF baseline H.264 
doesn't mean it's 100% royalty-free (witness Nokia's lawsuits). You can 
never say "100%" with royalties/patents unless something is so old every 
possible patent has expired - and you're still not really safe on your 
encoder even then, unless you use an old, published encoder largely 
unchanged.  I hear we haven't boiled the Indian Ocean yet.... ;-)

>> Things would be exactly as they are now, but at least we avoid a
>> "MUST" that will be ignored by 50% of the market.
> That would be more honest, indeed. It is effectively where we are going to be.  And it offers a carrot in the right direction.
>
> I am curious to know how many of the people supporting the proposed position actually would implement both encode and decode of both codecs?  This follows from comments on this thread that people who feel they fall into a different category are asking others to solve their problem.
>
> So, rather than +1, please say “I would expect to implement both” (non-binding, of course) — it would be a more useful thing to see, I think.

Easy for me.  Mozilla has already implemented both, and have been 
shipping them for months.

> Another possible choice:
>
> * admit that we already have possible non-interoperability (WebRTC-compatible Endpoints that choose differently), and that anyone who doesn’t want to do both will say that this what they are making (as was suggested):  simply delete the requirement or definitions for WebRTC User-agent and Device. Nothing stops those that want to from implementing both, without or without the mandate.  I don’t think this would make any material difference to what happens, but it makes the spec and reality a little closer.
>
>
>
> Finally, I wonder, what would it be like if we actually tried to get closer to interop: ALL endpoints — anything that can operate at one end of a WebRTC session, be it device, UA, gateway, compatible-endpoint, whatever — must be able to decode (actually, offer to receive) both, and must be able to encode at least one?  I’d have to think about the consequences of doing decode-only, but it’s a loss less work than a decent encoder, for a start. This would result in interop if people actually did it.

That option was floated when we did the survey.  I rated it above many 
others myself (though not as good as vp8-only).  IIRC it didn't do well; 
too many people in the A and not B or B and not A camps.

-- 
Randell Jesup -- rjesup a t mozilla d o t com