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

Lorenzo Miniero <lorenzo@meetecho.com> Fri, 01 November 2013 20:19 UTC

Return-Path: <lorenzo@meetecho.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F8611E811D for <rtcweb@ietfa.amsl.com>; Fri, 1 Nov 2013 13:19:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level:
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAmL8RdIfnpy for <rtcweb@ietfa.amsl.com>; Fri, 1 Nov 2013 13:19:26 -0700 (PDT)
Received: from smtpdg10.aruba.it (smtpdg7.aruba.it [62.149.158.237]) by ietfa.amsl.com (Postfix) with ESMTP id 23B9511E8131 for <rtcweb@ietf.org>; Fri, 1 Nov 2013 13:19:25 -0700 (PDT)
Received: from rainpc ([82.49.174.20]) by smtpcmd04.ad.aruba.it with bizsmtp id kLKN1m00e0SmHqA01LKNR0; Fri, 01 Nov 2013 21:19:24 +0100
Date: Fri, 1 Nov 2013 21:19:22 +0100
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Adam Roach <adam@nostrum.com>
Message-ID: <20131101211922.3ed7833d@rainpc>
In-Reply-To: <52740478.6030109@nostrum.com>
References: <CAOqqYVEER_HprgauRawO+_gGdLdMY1MUY8jrMhhi3yVDL31bFg@mail.gmail.com> <52740478.6030109@nostrum.com>
Organization: Meetecho
X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.19; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Cc: Harald Alvestrand <hta@google.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Congratuiations on the Cisco announcement - but we still prefer VP8
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Nov 2013 20:19:32 -0000

On Fri, 01 Nov 2013 14:43:52 -0500
Adam Roach <adam@nostrum.com> 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