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

[Gaelle Martin-Cocher <[e-mail]>]

-----Original Message-----
From: Mo Zanaty (mzanaty) [mailto:[e-mail]] 
Sent: Friday, December 12, 2014 12:55 PM
To: Gaelle Martin-Cocher; [e-mail]
Subject: Re: [rtcweb] confirming sense of the room: mti codec

Agreed, from the viewpoint of specifications. But from the viewpoint of implementations, there is often quite a difference between the level of support when the spec says ³can² versus ³MUST².
[gmc] but no so much when the spec says should versus must. 

E.g. WebRTC endpoints must implement at least one of VP8 and H.264 and should implement the other one. 
That says: unless you have a very good reasons, you have to implement both. 
This allows implementations to evolve from one to two codecs while not changing the spec.
I think everybody should be equally unhappy but might actually deliver products according to the specs; making the consensus translatable in something tangible.
Would that be acceptable?


Mandatory codec agility is even more important than specific mandatory codecs, but it may take the latter to force the former.
[GMC] generally agree.  There is quite a few more options to the above one: Shall implement at least two codecs, one is a defined MTI, the other if up to you (or is in a list of recommended codecs). The second codec can be a future looking codec. Other option: browser and non-browser do not have the same number of codecs to implement. A third option is an asymmetry in the number of decoders and encoders.

My comment was not based on hypothetical concerns or foresight. It was from direct experience trying to add H.264 into the webrtc.org codebase and Mozilla¹s fork. The current support in Firefox barely meets the bar of shippable, and webrtc.org support is not shippable at all. (I think your Blackberry colleagues who also started down this path can corroborate
this.) 
[gmc] we are aware of some current limitations in some implementations. It was stated also by a few that the video codec is currently not the bottleneck to launch services, but the state of overall WebRTC implementations in various browsers. 

There are still many holes, and lots of refactoring is still in progress to have a truly robust multi-codec media engine where resilience and other aspects are harmonized for all codecs. The end result will be a platform that can more easily and rapidly handle VP9, H.265, Daala, netvc, etc. without lots of additional refactoring or gaps in functionality across codecs. It does require extra effort, but I see it as essential investment that should not be deferred.

Actually implementing multiple codecs can also reveal gaps in specs. 

[gmc] Agree. We are in a situation where some mobile apps/libraries/SDKs already implement multiple codecs (not necessarily the MTI ones) and are on the forefront of "debugging" webRTC for these aspects. 
Browser wise, well, yes I agree, that may take much more time.
Achieving interoperability is also (usually, in some worlds) achieved via conformance tests.
If these tests are limited in the OTT/WebRTC world, it is not by multiplying MTI functions (whatever they are) that implementations will be better. It will still be product A attempting to interoperate with e.g. browsers B, C, product D... hit/miss, try again. Indeed that will take time to verify all of WebRTC functions across a large list of implementations.

For example, I strongly support your argument for decoding many formats even if you can only encode one or a few. It is a good technical direction. But try to implement it with current standards, and you will hit some walls.

[gmc] Standards are/should be evolving ? 



Gaëlle
Mo

On 12/12/14, 10:27 AM, Gaelle Martin-Cocher <[e-mail]>
wrote:

Multiple codecs can be supported even if there is only a single MTI defined in WebRTC. 
This has been confirmed by those who will implement scalable codecs.

I am not aware of anyone asking for removing the codec negotiation/capability discovery even if there is a single MTI.
As such supporting multiple codecs is independent from the MTI discussion.
The question is not do we need multiple codecs but do we need multiple MTIs (and which). 

Gaëlle


-----Original Message-----
From: rtcweb [mailto:[e-mail]] On Behalf Of Mo Zanaty
(mzanaty)
Sent: Monday, December 08, 2014 3:42 PM
To: Sean Turner; [e-mail]
Subject: Re: [rtcweb] confirming sense of the room: mti codec


To reiterate another point from the meeting, there are technical advantages to supporting multiple codecs. Dynamic discovery of local capabilities, negotiation of remote capabilities, understanding how different error resilience mechanisms can work (or not) with different codecs, faster adoption of new (non-mandatory) codecs, easier path to deprecating old (mandatory) codecs, etc. All those legs never get exercised effectively in single-codec implementations, leaving land mines in browsers, apps, services and sometimes even specs. They become easier or free once the groundwork is laid for multiple codecs. While some have argued against that extra complexity, I see it as essential for any important standard.

Mo