[rtcweb] on Ross Finlayson's choices - was Re: Straw Poll on Video Codec Alternatives

[Tim Panton <[e-mail]>]

On 30 Dec 2013, at 03:45, Ross Finlayson <[e-mail]> wrote:

> The term 'browser' isn't well-defined in this context.  An application may support the RTCWeb protocols, and render audio/video, but might not necessarily be thought of as being a general-purpose web browser.  So it doesn't seem to make sense to make such a distinction.  

In my mind the distinction relates to the multi-purpose/programmable nature of a browser as opposed to the single purpose and static 
programming of an app or device. - (and I agree it isn't well defined).

So the goal of this option is to maximise the chances that user with a webRTC browser will be able to interact with the
device or app on the other end. 

Examples might be browsing to your rtcweb doorbell to see who is there, or calling in to a 'professional' video conference system.
We'd want both to work without transcoding, but we don't want to impose the requirement to implement H264 on the doorbell,
or that the whole videoconference engine has to support VP8. 
(Think about how you configure your home router for example - via http/web)

It also neatly avoids the problem that cisco's h264 licence won't help on mobile or embedded devices and allows them to use
VP8 with the certainty that the user's browser will support it. 

Tim.