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

[David Singer <[e-mail]>]

> 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.
> 
> 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.



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.


David Singer
Manager, Software Standards, Apple Inc.