Re: [rtcweb] Video codecs: Clear positions....

Bernard Aboba <> Tue, 09 December 2014 20:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C54E41A036A for <>; Tue, 9 Dec 2014 12:11:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WB1Xn4UW_OKY for <>; Tue, 9 Dec 2014 12:11:13 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 491231A0101 for <>; Tue, 9 Dec 2014 12:11:13 -0800 (PST)
Received: by with SMTP id l18so1814997wgh.40 for <>; Tue, 09 Dec 2014 12:11:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yXJx5csF5gJhlwt5OaOkq9grgFnQ9p/zRbfSdPO+ZVg=; b=nJJ8lhnVSX7231g68GeZ0EwPjKftYSq69aR4rDSuzYD0HjosMzRCq2SP6HRXrtm6uu XaYQVYz0tyNjx1aP+4hyyR+sZpkClSDKJ0HPB5ar/jX+mNNtM+aVcLHNS9kA4U8I4V93 cCGhQJPC6HwLt7RMokQkw0dz9jf4iKjHr9cPIYRndPG2TBRHkI+M6MofE/EoQVFilZ6N D4LRtQb4ynZvifgY4K52w++3jX6xhwa6DDAYRu38wP3dEcywU5l+6pymWkuJE32N1lbD Tnckilx9gNoiKmI0h9w82ddKTHLUg56n984TUVpF8J0TZVKB8yIn9HijNW0NFzvgywIY 2wSg==
X-Received: by with SMTP id md16mr6956636wic.37.1418155872001; Tue, 09 Dec 2014 12:11:12 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 9 Dec 2014 12:10:51 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Bernard Aboba <>
Date: Tue, 9 Dec 2014 12:10:51 -0800
Message-ID: <>
To: David Singer <>
Content-Type: multipart/alternative; boundary=001a11c3380efca4ac0509ce2445
Cc: "" <>
Subject: Re: [rtcweb] Video codecs: Clear positions....
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Dec 2014 20:11:16 -0000

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.

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

On Tue, Dec 9, 2014 at 11:35 AM, David Singer <> wrote:

> > On Dec 9, 2014, at 11:31 , Mohammed Raad <>
> wrote:
> >
> > You know, that's a very strange path to take. I mean it really does
> sound like attempting to come to an agreement regarding what features
> future products should have by limiting participation in this technical
> decision process to those committed to deploy specific technologies. I
> think you ought to read the definition of anti competitive practice again.
> Please be respectful of your language.
> I am trying to find out a simple answer:  how many endpoints would, in
> fact, expect to support both codecs?
> I am not trying to limit participation.  I am trying to find out whether
> we would actually get the purported effect.
> If all the people humming yes make webrtc-compatible endpoints, we do not
> get the effect we want.  Is it that hard to see that?
> David Singer
> Manager, Software Standards, Apple Inc.
> _______________________________________________
> rtcweb mailing list