Re: [rtcweb] H.264's high-low play (Was: H.264 IPR disclosures (or persistent lack thereof))

Ron <ron@debian.org> Sun, 15 December 2013 07:58 UTC

Return-Path: <ron@debian.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5541ACCE5 for <rtcweb@ietfa.amsl.com>; Sat, 14 Dec 2013 23:58:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhFekTrhHy12 for <rtcweb@ietfa.amsl.com>; Sat, 14 Dec 2013 23:58:08 -0800 (PST)
Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 7121B1AE1A1 for <rtcweb@ietf.org>; Sat, 14 Dec 2013 23:58:07 -0800 (PST)
Received: from ppp118-210-162-115.lns20.adl6.internode.on.net (HELO audi.shelbyville.oz) ([118.210.162.115]) by ipmail06.adl2.internode.on.net with ESMTP; 15 Dec 2013 18:28:00 +1030
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 856CC4F8F3 for <rtcweb@ietf.org>; Sun, 15 Dec 2013 18:27:58 +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 POJjcHPhh+oK for <rtcweb@ietf.org>; Sun, 15 Dec 2013 18:27:57 +1030 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id C1CA74F902; Sun, 15 Dec 2013 18:27:57 +1030 (CST)
Date: Sun, 15 Dec 2013 18:27:57 +1030
From: Ron <ron@debian.org>
To: rtcweb@ietf.org
Message-ID: <20131215075757.GB3245@audi.shelbyville.oz>
References: <949EF20990823C4C85C18D59AA11AD8B0F88D6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <20131213033344.GW3245@audi.shelbyville.oz> <CECFF758.205FF%mzanaty@cisco.com> <E44893DD4E290745BB608EB23FDDB7620A16219B@008-AM1MPN1-042.mgdnok.nokia.com> <20131214102855.GY3245@audi.shelbyville.oz> <20131214122049.604352b3@rainpc> <20131214132520.GZ3245@audi.shelbyville.oz> <52AC7B89.3030103@bbs.darktech.org> <CAMwTW+g6q0gRbdioEkw8aUjpBY1s=V=sHbPNXaebFbhr6WihJQ@mail.gmail.com> <CABcZeBNx5wpKDgd6TgA9U3_nxEKXdCsXpo8Kp663yQ6e_iN9vQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABcZeBNx5wpKDgd6TgA9U3_nxEKXdCsXpo8Kp663yQ6e_iN9vQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [rtcweb] H.264's high-low play (Was: H.264 IPR disclosures (or persistent lack thereof))
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: Sun, 15 Dec 2013 07:58:18 -0000

On Sat, Dec 14, 2013 at 11:40:57AM -0800, Eric Rescorla wrote:
> You mean aside from the original suggestion coming from Cullen in the
> first place?

My understanding is there has already _been one_ for a very long time now.
Possibly even since before there was a WebRTC WG, certainly since before
Cisco offered to host one for H.264.

It might need some tweaking to suit everyone here, but I'm fairly sure
that if this is the only sticking point that work would get done.


> By contrast, the primary argument for VP8 is that it's free (despite
> some people saying they couldn't implement it).

I don't remember seeing too many arguments that listed technical reasons
why they _couldn't_.  Only why they said they _wouldn't_ or didn't want
to.  And all of those arguments were basically "oh noes, teh unknown IPR"
(and which realistically I think actually boil down to, in every case,
"we own IPR for H.264, we don't own any for VP8" - which isn't much of a
safety net for the majority of people who don't own H.264 IPR).

Which if we agree is transferred to someone else if you download a binary
from them, can be mitigated for VP8 at least as well as for H.264.  (and
if we don't agree on that, then Cisco's offer doesn't help either).

In fact it's still mitigated _better_ for VP8, since Google is giving you
a "free licence" to *all* of the known applicable IPR, along with a strong
defensive reciprocity guarantee - while the Cisco offer is _only_ licencing
you the MPEG-LA pool, which leaves you no licence at all to the other known
IPR that exists outside of that pool, and no promise from even MPEG-LA that
you are in any way safe for having a licence from them.


> So, if Google were to make a plugin available, that would alleviate the
> concerns of people that it really was encumbered, but it doesn't do
> anything for the existing installed base.

The existing installed base for WebRTC is pretty much exclusively VP8
at present.  So no, it won't do anything for them at all :)  They already
have it.

For people yet to implement WebRTC, that don't already have VP8 available,
they probably also don't already have Opus available either.  If linking
to libvpx (or a downloaded plugin of it) and linking to libopus, presents
a total showstopper technical difficulty to them, then I don't hold out
much hope for the quality, or delivery, or a WebRTC implementation from
them at all.  This is surely the most trivial part of anything that they
will need to do.

We already established that almost every platform with "hardware H.264"
would need to reimplement it in software for this anyway.  I don't see
how this poses any significant extra difficulty to do for VP8 instead
(or as well should they choose).


The notable thing to my mind, is that the people who considered VP8 as
the only viable option when this was a two horse race, have almost
universally attempted to compromise on some other option that also met
the needs and fears of the people who said the IPR situation surrounding
it was untenable for them.  I can't think of (m)any people from the
H.264 or bust camp that have engaged with that to satisfy the concerns
expressed about it.  Presently they're still arguing that they don't
even need to disclose to the IETF at all ...

If people are going to talk of Solomonic solutions, then if Solomon was
a chair, I suspect he'd know who cared more about this baby's welfare :>

  Ron