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

[tim panton <[e-mail]>]

Adam, thanks for sticking you head above the parapet ! 
I’m largely in favour of this solution, further, I think it represents the realities on the ground better
than any other proposal to date, as such it merits support.

On 10 Nov 2014, at 02:08, Adam Roach <[e-mail]> wrote:

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

I do have a slight qualm about the " ‘both’ or perhaps only ‘one’ “ language above. I think irrespective of new data, there will 
always be devices who’s hardware or business model is best served by a specific codec, but that can meet every other requirement
of a webRTC device.

I feel the appropriate language here is ‘either’ , ensuring that every device can always interact with a user agent
but that devices can’t necessarily communicate video between each other without a transcoding middle man.

This leaves WebRTC-compatible endpoint as a category for things that implement neither video codec (e.g. audio only devices), or
don’t implement the data channel because it isn’t relevant to their application domain or only implement SDES (etc) - This gives a 
clearer separation.

This language choice matters most for developers who are selecting a native library to use when building a webRTC device. They need to
know what is supported -  'WebRTC-compatible’ means that they have to look very carefully at all the missing features, WebRTC-device
says that it will work with any user agent. 

With the current formulation there are no libraries that I know of suitable for building a webRTC device, making it an empty category.

Tim.