Re: [rtcweb] ~"I'd love it if patents evaporated...If not now, when"

[Tim Panton <[e-mail]>]

On 13 Nov 2013, at 16:55, John Leslie <[e-mail]> wrote:

>  Both H.264 and VP8 deserve "SHOULD implement" status. Neither,
> IMHO, will achieve consensus for "MUST implement" status. Yes, this
> is a sorry state to find ourselves in. But the marketplace has
> sorted out much worse problems in my memory.
> 
>   And I claim that both camps are actually more likely to implement
> (or allow extensions for) the other side's codec if it is _not_ MTI,
> simply because they can back out at the first sign of lawyers.
> 
>   I will not go into any details about how VP8 endpoints might talk
> to H.264 endpoints, but I'm _very_ confident ways will be found if
> we actually _publish_ an RFC saying both are "SHOULD implement".
> 
>   (Surely I'm not the _only_ person who'd like to see _both_ H.264
> and VP8 legacy devices using our standard...)

I'm coming around to this POV. With the possible slight variant that we should clarify
that this applies to _browsers_ not rtcweb compatible endpoints.

Ideally we'd see browsers implementing both VP8 and H264 - but single purpose 
endpoints (doorbells, prison video phones, baby alarms, smart-fashion mirrors, video mixers etc) using whichever
codec suits their hardware/legal/usecase needs best, and exchanging rtcweb media with
a browser at the far end. 

Non browser endpoints need to be confident they can talk to any browser and browsers need to
be able to talk to anything.

I think that's what is behind the option #4 in Gonzalo's proposal. 
>  4. Browsers MUST support both H.264 and VP8

- What this highlights is that we've created a media protocol that will be used by things that aren't browsers,
we need to address that requirement, without just seeing it as legacy support.

Tim.

Tip of the Hat to @nstratford for helping clarify my thinking on this.