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

cowwoc <cowwoc@bbs.darktech.org> Mon, 16 December 2013 06:31 UTC

Return-Path: <cowwoc@bbs.darktech.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 88B991AE2B4 for <rtcweb@ietfa.amsl.com>; Sun, 15 Dec 2013 22:31:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LXSdiArqk5eN for <rtcweb@ietfa.amsl.com>; Sun, 15 Dec 2013 22:31:06 -0800 (PST)
Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by ietfa.amsl.com (Postfix) with ESMTP id 32E421AE114 for <rtcweb@ietf.org>; Sun, 15 Dec 2013 22:31:06 -0800 (PST)
Received: by mail-ie0-f179.google.com with SMTP id x13so5739519ief.24 for <rtcweb@ietf.org>; Sun, 15 Dec 2013 22:31:05 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=rjqLFerG60f7KsR+igljZNi1wK6EIv9C5tLuIkNZLJ0=; b=dKPQTnAnteS3Vcmz1Mk17g/PkmqbOdK+YzLqTR1kfUnpLIOu9HY2GXXkR9UyFR820A Eh7fepStwvwTElOOxHhK2J6DGlNGUme/pPIKxfX9wwFKqnb8194ddy8bZbVelsZNOvAv /5oE/WH5X7bL8QHWmJJJA496JdI7byHEgmOcZYIppAyrDdyOGHF/QvEJ3/ulBcmuwUkv 0R0mtnx+TSeIenx/xuwGo8BQdtupzGiBB5LIt/DGejaxWfkCjgqqa/cZzQn9T6z/61Gt wUraZ50lu4axuwEu2+R0b6ryA6TFHcMMcGfGuvVnK32MlPd15t/VuwZY4MEASxKaadl0 zqkQ==
X-Gm-Message-State: ALoCoQn+Yd79pESLkmqzi6n3n/AzGoxYUYoD191fxx8+IPu6pI7pWzxSAXeF9XzWWOFg3UUgC0tj
X-Received: by 10.43.182.74 with SMTP id pl10mr42574icc.70.1387175465291; Sun, 15 Dec 2013 22:31:05 -0800 (PST)
Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com. [206.248.171.209]) by mx.google.com with ESMTPSA id k6sm14677623igx.8.2013.12.15.22.31.03 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Dec 2013 22:31:04 -0800 (PST)
Message-ID: <52AE9E0C.9060707@bbs.darktech.org>
Date: Mon, 16 Dec 2013 01:30:36 -0500
From: cowwoc <cowwoc@bbs.darktech.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Eric Rescorla <ekr@rtfm.com>
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> <CABcZeBMjTGs41t7y=xvaLdn4i63HxC2YQUkrd-itq=VkuKvpTA@mail.gmail.com> <52AE9129.8090702@bbs.darktech.org> <CABcZeBPOxqa2YQxOrTp9sVF-tQrpg-Kn=CbazBXOx_9dajhUZA@mail.gmail.com>
In-Reply-To: <CABcZeBPOxqa2YQxOrTp9sVF-tQrpg-Kn=CbazBXOx_9dajhUZA@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 06:31:10 -0000

On 16/12/2013 12:50 AM, Eric Rescorla wrote:
>> On second thought, I think you're right.
> At the risk of pressing the point, this seems like it would be a good
> time for you to explicitly retract your comments about the motives of
> H.264 proponents.

The only thing that changed is that I have a better appreciation for why 
some H.264 proponents cannot accept older codecs such as H.261 or 
Theora. I'm still bothered by the fact that none of them extended a 
olive branch to people who objected to IPR-encumbered codecs. I find it 
hard to believe that none of their use-cases would be adequately served 
by these codecs. That being said, let's wait for more straw poll results 
to come in.

> No, because "you" is different people.
>
> To take a simple example, consider the case of a browser which
> implements VP8-only. Clearly, the browser has no H.264 IPR risk, at
> the cost of not being able to talk to people who do H.264. However, If
> someone else (say a conferencing system) decides to build a system
> with a VP8-H.264 transcoder, then *they* are the person incurring the
> IPR risk. That's really not the same thing at all.
>
> I'm certainly not suggesting that no-MTI is a good thing, but it
> isn't the same as MTI-X from the perspective of IPR exposure.
>
> -Ekr

Fair enough. So we're pushing out the IPR risk to companies who author 
transcoding bridges. This is certainly acceptable for some businesses, 
but it's worth noting that other business models would be wiped out by 
the need for transcoding.

This is why I favor the "Must implement two of [VP8, H.264, older 
codec]" option. Companies who need high-end video can fallback on 
transcoders. Companies who want to avoid IPR issues can fallback on 
older codecs. I like this option best because it displeases everyone 
equally. Everyone is compromising on something they want but getting 
something in return. And again, we are only talking about the fallback 
scenario. If the peers are compatible, there is no need for transcoding 
or older codecs.

Gili