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

Ron <ron@debian.org> Mon, 04 November 2013 18:11 UTC

Return-Path: <ron@debian.org>
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 AEFF521E822F for <rtcweb@ietfa.amsl.com>; Mon, 4 Nov 2013 10:11:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level:
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
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 p2gjTTU-4g-w for <rtcweb@ietfa.amsl.com>; Mon, 4 Nov 2013 10:11:25 -0800 (PST)
Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 9751A21E821B for <rtcweb@ietf.org>; Mon, 4 Nov 2013 10:11:17 -0800 (PST)
Received: from ppp118-210-230-117.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([118.210.230.117]) by ipmail05.adl6.internode.on.net with ESMTP; 05 Nov 2013 04:41:13 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 9BB814F8F3; Tue, 5 Nov 2013 04:35:37 +1030 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12felVnYnGD6; Tue, 5 Nov 2013 04:35:36 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id CFD1E4F902; Tue, 5 Nov 2013 04:35:36 +1030 (CST)
Date: Tue, 05 Nov 2013 04:35:36 +1030
From: Ron <ron@debian.org>
To: Jonathan Rosenberg <jdrosen@jdrosen.net>
Message-ID: <20131104180536.GZ3245@audi.shelbyville.oz>
References: <CAOqqYVEER_HprgauRawO+_gGdLdMY1MUY8jrMhhi3yVDL31bFg@mail.gmail.com> <20131102124801.GY3245@audi.shelbyville.oz> <CA+23+fE1S_K93xk+3WNbq1RAFt8QD++pF74OJowu_+qz71H91g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CA+23+fE1S_K93xk+3WNbq1RAFt8QD++pF74OJowu_+qz71H91g@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: 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: Mon, 04 Nov 2013 18:11:31 -0000

On Mon, Nov 04, 2013 at 09:58:23AM -0500, Jonathan Rosenberg wrote:
> I do not believe that "genuinely free" is the only, nor even the primary,
> consideration here.
> 
> I believe we should in general be thinking about what it takes to make
> webRTC successful. And more than anything else, that means making it a
> platform that application developers can utilize. If we do our jobs well,
> we'll have many thousands (hundreds of thousands even) of applications on
> the web that are enabled with real-time comms and frankly a great many of
> them will know nothing about codecs or the nuances of MPEG-LA licensing.
> What are the considerations for making webRTC attractive to them?
> 
> I assert that the primary thing they'll want is to interconnect their
> application with some kind of video network or user base that can add value
> to their application. Let me give an example. Lets say there is a bank, and
> this bank wants to add the ability for a user to look at their investment
> portfolio online, click a button, and have a voice/video call with their
> investment advisor. To build such an app into their existing banking web
> app, the bank will need webRTC to connect to the voice and video contact
> center and clients their investment advisors have. Today, all of that is
> based on H.264.

And 'tomorrow' it will be based on something else that is better.
I don't think anyone in either camp doubts that change is in progress.

> So - I would assert that frankly our primary consideration for webRTC is
> interoperability. And interoperability as a requirement clearly points to
> H.264.

Interoperability as a requirement clearly points to the fact that selection
of a MTI codec that is Free in as many dimensions as possible is absolutely
*essential* for the future success of WebRTC.

How can you have interoperability if a significant portion of potential
implementers are fundamentally prohibited from distributing the MTI codec?

You are talking here of interoperability with legacy equipment, which the
WG charter explicitly notes is something to be considered on a best effort
basis only, not something to sacrifice other goals over.

I'm talking about interoperability with _all_ future implementations of
*this* standard.  If some people can't distribute the MTI codec, then
we have already guaranteed interoperability failure and a forking of the
developer and user base.  Before we've even got started.


The Cisco announcement does indeed make it possible that more people
than otherwise might have would also be able to provide H.264, both as
a negotiation option and for creating gateways to legacy equipment.
That can only be a good thing, for which I'm sure many will be grateful.

But it's still not without significant problems, as many people here
have already indicated, and it still doesn't come close to either the
immediate freedom, or assurance of future availability, or out of the
box quality, that we would have by choosing VP8 today.  And that _is_
more than anything what it will take for WebRTC to be successful in an
already fragmented application space.


> There are other considerations too. Some of the ones I'd list are:
> 
> * Interoperates with install base

Which means all installed WebRTC applications need a freely available
codec and solid guarantees of always being able to distribute it.

> * Widespread deployment

Which will come once there are many implementations of WebRTC that
meet a wide range of users needs.  A codec with limited freedoms
means limited deployment.  Kind of by definition.

> * Appeals to the existing set of video application developers - in other
> words, the biggest consumers of webRTC should be the folks who are already
> providing video communications applications on the Internet (which by
> definition none of them do so natively from the browser). Don't we want
> them to come to the web with webRTC?

As you noted above, most of them care nothing about the nuances of
codec selection - they just need it to be available on all of their
target platforms, and they need to be able to distribute their apps
on their own terms, that meet their needs and the needs of their
users.

Requiring all their users to download a separate plugin blob before
their application will work at all, if it's actually still even
available at the time they need it, is both a huge barrier and a
huge risk.

Who do I complain to and what recourse do I have if my customers
cannot download it because of a temporary or permanent outage of
the only legal download site?

> * Available widely in hardware - especially mobile phones

I think the earlier discussion on this point has cast a pretty
deep shadow over how actually available hardware H.264 is to
developers in general on pretty much every platform.

> * Broad availability of expertise
> * Broad availability of toolsets
> * Multiple codebases and implementations to choose from

Again, all excellent points that point to the necessity of a Free
codec selection which encourages the maximum possible diversity.

> And none of that has anything to do with IPR or royalties.

I wouldn't go quite that far, but indeed the important question is
which choice places the least restrictions on the broadest number
of potential WebRTC developers and users.

And on that question, it still seems clear that the evidence indicates
it is a no-brainer to see that of the currently proposed candidates,
VP8 wins on this very important point hands down.

  Ron


> On Sat, Nov 2, 2013 at 8:48 AM, Ron <ron@debian.org> wrote:
> 
> > On Thu, Oct 31, 2013 at 07:47:31PM +0100, 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.
> >
> > This is my belief also.
> >
> > While the Cisco announcement is certainly an interesting approach to trying
> > to extricate their existing technology investment from the deep quagmire of
> > encumbrances that currently bind it, the result still falls well short of
> > not only the ideal, but also the already existing alternative choices that
> > we have available to us.
> >
> > Given the choice between a genuinely Free option, that anyone is free to
> > improve and distribute however they wish - and a no-cost binary-only option
> > that is available from only a single supplier, while Happy Hour lasts - the
> > decision still seems to be something of a no-brainer.  Even before you also
> > consider that the Free Option is not constrained to only its lowest
> > possible
> > performance mode in the implementation that is available to people today.
> >
> > VP8 still seems like the only obvious and enduring choice for an MTI codec
> > for WebRTC at present.
> >
> >   Ron