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

["Cavigioli, Chris" <[e-mail]>]

I like that proposal, Dave.

+1    INTEL CORP has already implemented both H.264 and VP8 ... both encode and decode.   Done.   

We already demonstrated hardware WebRTC to the public at MWC'14 in Barcelona in February on our smartphone platform.   Done.

We welcome the consensus decision made by IETF and look forward to moving forward with WebRTC.
-chris

-----Original Message-----
From: rtcweb [mailto:[e-mail]] On Behalf Of David Singer
Sent: Monday, December 08, 2014 5:19 PM
To: [e-mail]
Subject: Re: [rtcweb] confirming sense of the room: mti codec


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

_______________________________________________
rtcweb mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtcweb