Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8

[Lorenzo Miniero <[e-mail]>]

On Fri, 01 Nov 2013 14:43:52 -0500
Adam Roach <[e-mail]> wrote:

> On 10/31/13 13:47, Harald Alvestrand wrote:
> >
> > We congratulate Cisco on their intention to make an open source H.264 
> > codec available and usable by the community. We look forward to seeing 
> > the result of this effort.
> >
> >
> > Google still believes that VP8 - a freely available, fully open, 
> > high-quality video codec that you can download, compile for your 
> > platform, include in your binary, distribute and put into production 
> > today - is the best choice of a Mandatory to Implement video codec for 
> > the WebRTC effort.
> >
> 
> I agree with Harald that VP8 is a better codec than H.264 baseline in a 
> number of important ways.
> 
> But I also want to reiterate that having an MTI codec has never been 
> about choosing the best codec or even a good codec. It's about choosing 
> an emergency backup codec-of-last-resort. It's about having one single 
> mandated codec that everyone has in their back pocket in case nothing 
> else works.
> 
> The core of RTCWEB is about session *negotiation*. Endpoints will 
> negotiate the best codec they have in common. Once the next generation 
> of codecs come out, this "best codec in common" will only be the MTI if 
> they were about to fail anyway.
> 
> So it doesn't have to be good.
> 
> It just has to be better than failure.
> 
> /a


Those are good points. But were that the case, we could have sticked with an older codec, one that didn't have to carry the burden of royalty fees: a choice that several people have often discarded exactly because it wasn't good enough.

That's also why I, as it is probably redundant to restate, actually support Harald's view. My concern is that, with H.264, MTI will not mean *a* codec in a negotiatiated session, which is what we all agree RTCWEB still is, or should be. It will be *the* codec, because several implementations, including two currently missing browsers (whenever they'll start to care), will *only* provide H.264, thus forcing everyone to comply with it. Who's going to do anything else, when you know the only way to reach all browsers is *the* codec? And for a lot of people, including me, there's currently (or actually, will be) only one way to do so, which is a plugin (in RTCWEB, ironic) that may or may not be available two months after we start using it.

I'm at the wrong edge of the knife, and I don't like it.

Lorenzo