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

Eric Rescorla <ekr@rtfm.com> Mon, 16 December 2013 04:05 UTC

Return-Path: <ekr@rtfm.com>
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 93EB81AE2A1 for <rtcweb@ietfa.amsl.com>; Sun, 15 Dec 2013 20:05:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 pG4w80vBcc9u for <rtcweb@ietfa.amsl.com>; Sun, 15 Dec 2013 20:05:24 -0800 (PST)
Received: from mail-ig0-f181.google.com (mail-ig0-f181.google.com [209.85.213.181]) by ietfa.amsl.com (Postfix) with ESMTP id 87EAE1AE075 for <rtcweb@ietf.org>; Sun, 15 Dec 2013 20:05:24 -0800 (PST)
Received: by mail-ig0-f181.google.com with SMTP id k19so2932729igc.2 for <rtcweb@ietf.org>; Sun, 15 Dec 2013 20:05:24 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Nfwq6FKSsjPINpd5oNDwm3FcmbtGj8RCUZHi6ghgzEQ=; b=CXL34QPZk7pDBI/1b1OzukJ99BsxuQErVYxwvC/mSrYqE96Ywro7D8IYW3sakptdZ7 mLf/8cW7eREFCaEZMoFnYt1ZSqdcDkuBwFa5gTGSCjM7NX97+ZR/kvuBZ1hghqMoGFl3 cZN16Yu8got62ZSFYvoTWmEJXOr+PXCFOuwLSo+ApyjxuAYAbdECTGi8HfPJM8dTpcD4 Ao44oUlTen/Tzk0674nuMZvr6oatuaMufMlq8UFUkJM+d4nDxb4HLwOI65d+P6UUb6Fz JOYIaNpMUw5kBapzhEeWCvtJsNlyO5At4SvzMqD3vf2oNdvtiCPPzq5lpEs28YouwyPx VmZw==
X-Gm-Message-State: ALoCoQmRwTxi8Jud0L8kpqteR9Fb5rtxVBlZRfdS0ULhMslxfPqi+lH3/t8dT6wheClPmQTX4/WH
X-Received: by 10.42.232.206 with SMTP id jv14mr4644icb.52.1387166723878; Sun, 15 Dec 2013 20:05:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.64.252.38 with HTTP; Sun, 15 Dec 2013 20:04:43 -0800 (PST)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <52AE759C.7020209@bbs.darktech.org>
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> <20131215075757.GB3245@audi.shelbyville.oz> <52AE54F8.5070300@bbs.darktech.org> <CABcZeBNqE25O+BNLboXDrJ1ypp26uRAw8ehwtyor9gJccpuzGw@mail.gmail.com> <52AE759C.7020209@bbs.darktech.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 15 Dec 2013 20:04:43 -0800
Message-ID: <CABcZeBMjTGs41t7y=xvaLdn4i63HxC2YQUkrd-itq=VkuKvpTA@mail.gmail.com>
To: cowwoc <cowwoc@bbs.darktech.org>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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: Mon, 16 Dec 2013 04:05:32 -0000

On Sun, Dec 15, 2013 at 7:38 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
> I've seen multiple VP8 proponents rate the following options as Acceptable:
>
> H.261 as MTI
> Theora as MTI
> Implement two of [H.261, H.264, VP8] as MTI
>
> They might not love the option but they are willing to accept it as a
> compromise. On the flip side, I've seen multiple H.264 backers rate "H.264 s
> MTI" as "Yes" and all other options as "No". They did not include a single
> option as "Acceptable".

You might try taking a closer look at the survey results. I'm not a mind-reader
so I don't know what an "H.264 backer" is, but the following people voted
positively for H.264 and negatively for VP8. I've listed their votes below
(accreting Yes and Acceptable, since the difference doesn't seem relevant
here):

Stefan Hakkansson   (264, None, 2/3 [VP8, H263, H.264], 263)
Bernard Aboba (264 only)
Sal Loreto (264, None, 263 only)

Perhaps I missed some, since I just went by responses to the thread, but this
seems sufficient to demonstrate that your characterization of the data isn't
accurate.

-Ekr


> On 15/12/2013 8:25 PM, Eric Rescorla wrote:
>
> I'm sure I'm going to regret asking this, but what compromise do you think
> either side has offered?
>
> -Ekr
>
>
> On Sun, Dec 15, 2013 at 5:18 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>
> +1
>
> If the H.264 crowd was as willing to compromise on some other option then we
> could reach a solution that would be satisfactory to all parties. I still
> hope that we can reach such a compromise.
>
> Gili
>
>
> On 15/12/2013 2:57 AM, Ron wrote:
>
> 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
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>