Re: [rtcweb] MTI Video Codec: a novel proposal

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

Thanks for the effort Adam.



We would still prefer a single video MTI codec. That said, here is an alternative to/modification of the ‘novel proposal’ to try to mitigate the concerns.



When video interoperability is required, the following applies:

- All WebRTC endpoints SHOULD implement decoding for at least

   VP8 and H.264.



- In operating environments that expose a platform provided

   implementation of H.264, WebRTC endpoints MUST implement H.264



- In operating environments that expose a platform provided

   implementation of VP8, WebRTC endpoints MUST implement VP8



- Otherwise (in operating environments that do not expose a

   platform provided implementation of H.264 and/or VP8):

     - WebRTC "Devices/non-browser" SHALL implement at least

       one of VP8 and H.264.

     - WebRTC "UAs/browsers" SHALL implement encoding for at

       least one of VP8 and H.264.





The rationales are as follow:



If RF is a requirement, I don't see how the proposal meets the requirement.

If interoperability is a requirement, one agreed upon codec/API is enough.

Multiplying non-agreed upon codecs, at all or at different levels, does not seem to fulfill any of those two requirements and is mechanically increasing the cost of WebRTC implementations.



I believe we should aim at being inclusive and not making some of the WebRTC endpoints, particularly device/non browser, webRTC-compatible endpoints only if they would differ just by one codec.

Elsewhere that is called profiling. Is that a way to go? That is somewhat what the gateway draft looks like.



Some device/OS vendors have released API to hardware supported codec (BlackBerry included). One of the goal is to offer codec access without additional cost to non-platform-native UA/browser/device/non-browser, hence maximizing interoperability for WebRTC endpoints. And without having multiple occurrences of codecs being loaded on the platform.

We should leverage this possibility as this becomes more widely available across platforms.



The IETF RFCs will serve many use-cases and may be implemented with other specifications than the W3C WebRTC 1.0. or without any additional specifications. Most non-browser/device endpoints while implementing (some/all) the IETF WebRTC RFCs will not interop with other non-browser/device endpoints by choice and that has nothing to do with codec support (they might well support the same codec). I think the distinction between native and non-native endpoints also matters a lot.

Interoperability at the codec level for apps/Non-browser/device endpoints is not an obvious requirement for all cases.



"... the IETF will change this normative statement..." It will take some time to have a clear assessment. The ISO process is not finished. It takes an even longer time to deprecate a codec from a platform/non-browser/device. I doubt this will be practical. Opinions changes over time. Agreement to revisit now may not stand in few months. Instead of being unclear on what will trigger the revisit of that text, it would be preferable to avoid creating such a burden.




I hope this helps.



Gaëlle





From: rtcweb [mailto:[e-mail]] On Behalf Of Adam Roach
Sent: Sunday, November 09, 2014 9:08 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [rtcweb] MTI Video Codec: a novel proposal

It appears that we're running headlong into another in-person discussion about the relative merits of H.264 and VP8 as MTI candidates again. Matthew Kaufman has argued that this conversation is doomed to failure because no major player has been willing to change their position. The players he cited were Cisco, Google, and Mozilla, who have represented the three main positions on this topic pretty effectively. Although we participate as individuals in the IETF, I think it's fair to say that the last time we had this conversation, the median positions of participants from those companies were "H.264 or die", "VP8 or die", and "either one as long as it's *only* one", respectively.

However, even if nothing else has changed, I think one salient point may have become quite important: we're all tired of this. Over two years ago, in March of 2012 -- before I even had an particular interest in WebRTC except as a user -- this had already become such a long-running acrimonious debate that I was brought in as a neutral third party to try to mediate. I'm weary of this argument; and, with the exception of a few aggressive voices who seem to enjoy the battle more than the outcome, I'm hearing a similar exhausted timbre in the messages of other participants (and the key stakeholders in particular).

So, I want to float a proposal that represents a compromise, to see if we can finally close this issue. First, I want to start out by reiterating a well-worn observation that the hallmark of a good compromise is that nobody leaves happy, but everyone can force themselves to accept it. And I want to be crystal clear: the solution I'm about to float just barely clears the bar of what I think I can live with. This proposal is based on an observation that the dominating issues in this conversation remain those of licensing, not technology or even incumbency. I’ve discussed this extensively with representatives of all three of the players I mention above, and they are willing to sign on.

This proposal is based on the definitions of "WebRTC User Agent", "WebRTC device", and "WebRTC-compatible endpoint" in section 2.2 of draft-ietf-rtcweb-overview-12.txt. My proposal would be as follows:

  1.  WebRTC User Agents MUST implement both VP8 and H.264.
  2.  WebRTC devices MUST implement both VP8 and H.264. If compelling evidence arises that one of the codecs is available for use on a royalty-free basis, such as all IPR declarations known for the codec being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change this normative statement to indicate that only that codec is required. For absolute, crystal clarity, this provision is only applicable to WebRTC devices, and not to WebRTC User Agents.
  3.  WebRTC-compatible endpoints are free to implement any video codecs they see fit, if any (this follows logically from the definition of "WebRTC-compatible endpoint," and doesn't really need to be stated, but I want this proposal to be as explicit as possible).

This has the property of ensuring that all devices and user agents can work with all devices and user agents. This has the property of giving no one exactly what they want. And, unlike any other previous plans, this has the property of coming to a decision while maintaining pressure on the only parties who can make a change in the IPR landscape to do so.

/a