[rtcweb] Incentives (Re: Video codecs: Clear positions....)

Harald Alvestrand <harald@alvestrand.no> Wed, 10 December 2014 04:49 UTC

Return-Path: <harald@alvestrand.no>
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 5CC2F1A1AA4 for <rtcweb@ietfa.amsl.com>; Tue, 9 Dec 2014 20:49:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 gPQcqmax-nJe for <rtcweb@ietfa.amsl.com>; Tue, 9 Dec 2014 20:48:57 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id 93AE61A024E for <rtcweb@ietf.org>; Tue, 9 Dec 2014 20:48:56 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id E1D697C36BE for <rtcweb@ietf.org>; Wed, 10 Dec 2014 05:48:52 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waB1MVKLwo2g for <rtcweb@ietf.org>; Wed, 10 Dec 2014 05:48:51 +0100 (CET)
Received: from [IPv6:2001:470:de0a:27:6004:c89f:bb68:a447] (unknown [IPv6:2001:470:de0a:27:6004:c89f:bb68:a447]) by mork.alvestrand.no (Postfix) with ESMTPSA id 4D55C7C36AE for <rtcweb@ietf.org>; Wed, 10 Dec 2014 05:48:51 +0100 (CET)
Message-ID: <5487D0B2.9070804@alvestrand.no>
Date: Wed, 10 Dec 2014 05:48:50 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <5486C48D.8040602@alvestrand.no> <F092E8C6-380C-4B20-B71F-449162617BC5@apple.com> <CA+E6M0mfHomZByk0h1Fdxis3Q+Z0cOPve+qWqq_BVOtq9qB6sg@mail.gmail.com> <D18AB097-8C30-40BC-83DF-D2249D615CF4@apple.com> <CAOW+2dvWTnmkHeNZM_XQZo35iwbvML1wS0dd7uM36hHX8R9TGw@mail.gmail.com>
In-Reply-To: <CAOW+2dvWTnmkHeNZM_XQZo35iwbvML1wS0dd7uM36hHX8R9TGw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------060207030308030408060608"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/A0467tnH7AZzfqnFrmu4I1GnyHU
Subject: [rtcweb] Incentives (Re: Video codecs: Clear positions....)
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: Wed, 10 Dec 2014 04:49:00 -0000

It's perhaps not surprising that I disagree with Bernard on every point
he makes below, but since I respect Bernard quite a lot, I'll try to
make it clear why.

On 12/09/2014 09:10 PM, Bernard Aboba wrote:
> David Singer said: 
>
> "I am trying to find out a simple answer:  how many endpoints would,
> in fact, expect to support both codecs?"
>
> [BA]  The proposal has built-in incentives for implementers in each
> category to either ignore the recommendations or ignore
> interoperability (or both).   
>
> As it stands, the proposal doesn't require that "WebRTC-compatible
> endpoints" support either H.264 or VP8.  I understand why an endpoint
> not supporting video shouldn't have to, but if the WebRTC-compatible
> endpoint does support video, why shouldn't it support at least one of
> the MTI codecs?   The way it is written a WebRTC-compatible endpoint
> that supported only H.261 would be compliant while being able to
> communicate with either browsers or non-browsers, which seems silly.

This is irrelevant to the proposal made.
The term "WebRTC-compatible" is introduced solely to point out that
there are things that will talk (successfully!) to WebRTC endpoints that
aren't WebRTC - and there's nothing whatsoever we or anyone else can do
to prevent that.

>
> The "non-browser" is required to support both codecs, but only until a
> clause is triggered to choose a single MTI.  For a  "non-browser" such
> as a mobile application, there is no real need to support both VP8 and
> H.264, assuming that browsers support both.  So I would expect most
> folks in this category to ignore the recommendation or wait for the
> "trigger" (then ignore that too if the selected codec isn't the one
> they've already chosen).   It would make more sense for this category
> to mandate implementation of either VP8 or H.264 (implementer's
> choice) and dump the trigger clause. 
>
> The "browser" subset is supposed to support both codecs.  However, the
> "trigger" clause for the "non-browser" case muddies the waters,
> particularly in situations where implementing a previously
> non-supported codec could take a while.  Who wants to spend a lot of
> effort implementing a codec that  might not even be required by the
> time the implementation is complete (and that will probably be
> guaranteed to be obsolete by then anyway)? 

I think the incentives here make sense.

First off, let's assume that codec agility is a Good Thing.
Most implementors I've talked to about codecs say that they intend to
support codecs that aren't in the MTI, and won't be in the MTI any time
soon. (this includes AVC-High profile as well as the next generation
codecs HEVC and VP9).

So the extra cost of implementing two MTI codecs is strictly limited to
the cost of supporting the codec; the rest of the machinery for picking
a codec is already present.

People have sharply differing opinions on the quality they expect to get
out of the two codecs. So we can assume from the get-go that there will
be different preferences stated during negotiation.
However, among those who don't prefer one codec for special reasons, one
would expect market forces to work here; they will, over time, tend to
prefer what works best (for whatever value of "best" makes sense for
them). Implementing both gives flexibility here, which is a Good Thing.

With regard to the stability of MTI (the "trigger clause"), I heard two
concerns voiced:

- The people for whom H.264 interoperability without transcoding is of
paramount importance want assurance that their investment in
browser-based systems is not lost due to a later MTI change.

- The people for whom cost, silicon area or license freedom is of
paramount importance want to make sure that if we're in a situation
where a single codec clearly makes sense, they can go there.

Given the size of a modern browser, the last group are *not* the browser
vendors - supporting another middle-aged codec in software is just
another piece of code. (modulo the Firefox "download dance", which *is*
a complicating factor.)

Having the "trigger clause", formulated the way it is, gives something
to both these groups: The first group gets assurance that its
browser-targeted investment is protected - the second group gets
assurance that if a clearly sane (from their viewpoint) outcome is later
possible, they can go for it.

And the "trigger cause" serves as an additional incitement for *current*
implementors to actually do both, in order to be future-proof; there's
no telling which, if any, of the MTI codecs will actually reach the
trigger condition first - and those implementors who have implemented
both know that in the event of an MTI change, and a rollout of a large
number of devices with only one codec, they will be able to interoperate
without an upgrade - no matter which codec gets dropped.

Summary: I think a lot of people have incentive to follow the
recommendation.
We should stick to our recommendation and move on.

Harald