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

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

(gmc] Please see inline.

From: rtcweb [mailto:[e-mail]] On Behalf Of Randell Jesup
Sent: Wednesday, November 12, 2014 9:42 AM
To: [e-mail]
Subject: Re: [rtcweb] MTI Video Codec: a novel proposal

On 11/11/2014 5:41 PM, Gaelle Martin-Cocher wrote:

Thanks for the effort Adam.

Agreed.  This is an incredibly thorny issue due to politics, ideology, money, etc - almost none of which is technical, except in the ramifications of various not-clean-1-codec-MTI options, as mentioned somewhat here.  While I personally (this is the IETF) would prefer a pure VP8 MTI, I realize that isn't going to happen right now, and this may be (to steal a quote from B5) our last best hope for peace... I mean MTI.
[GMC] except that it does not mitigate any issues.
As an example, I can't think of a single good justification to implement two encoders. Can anyone elaborate?
Interop might not be in a better place if a number of WebRTC-compatible-endpoints-that-are-compatible-endpoints-but-by-one-codec are not implementing the same codec.



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

You assume "platform" codec implementations (H.264 and VP8) are inherently useful for WebRTC.  They often aren't.  You can include wiggle words about "usable" or "realtime", which helps but certainly makes the decision the domain of the implementing device/browser (to decide if it's usable).  I would extend this to must support both if they have "usable" platform-provided implementations.
[GMC] No that is not the assumption. The platform supplied  implementation would be "good enough" for many not for all endpoints. That is pretty clear. An endpoints that wishes to have its own implementation of a required codec would do it and would be willing to afford the additional cost implications.
The proposed requirement here does not mandate an endpoint to use the supplied platform codec implementation. It can chose to use it, or implement its own. This is about mitigating the concerns and cost to various actors.

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.

Agreed - but this can be easier said than done, especially on Android, and may require per-device/OS-version validation to use.
[GMC] I guess the (web) industry has demonstrated its willingness to support a variety of endpoints/actors by exposing platform codec implementations. APIs will evolve. Yes, it might takes time before we reach a perfect world.
The 'novel proposal' will not remove the need of per-device/OS version validation. Even in the 'novel proposal' some endpoints will leverage and use H264/VP8 codecs provided by a platform implementations to claim "H264/VP8 support".

Older OS's (Windows pre 8.x for example) don't have viable realtime H.264 codecs by default, and we haven't yet verified if the Win8 codec meets the WebRTC needs (though likely it does), and so far as I know it's software-only.  Others may not be available to applications (iOS? especially older iOS).
[GMC] this is true for VP8 too.  Hence the proposed "otherwise" requirements.


--

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