Re: [rtcweb] Finishing up the Video Codec document

John Leslie <> Fri, 12 December 2014 17:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D91AC1A6FB5 for <>; Fri, 12 Dec 2014 09:34:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.51
X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O7PjqZMCWEfE for <>; Fri, 12 Dec 2014 09:34:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2E0131A1BBF for <>; Fri, 12 Dec 2014 09:34:18 -0800 (PST)
Received: by (Postfix, from userid 104) id DDEA3C94BD; Fri, 12 Dec 2014 12:34:15 -0500 (EST)
Date: Fri, 12 Dec 2014 12:34:15 -0500
From: John Leslie <>
To: Peter Saint-Andre - &yet <>
Message-ID: <20141212173415.GH47023@verdi>
References: <> <> <20141204150041.GI10449@hex.shelbyville.oz> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.4.1i
Subject: Re: [rtcweb] Finishing up the Video Codec document
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: Fri, 12 Dec 2014 17:34:21 -0000

On Sat, 06 Dec 2014,
Peter Saint-Andre - &yet <> wrote:
> On 12/4/14, 9:08 AM, Adam Roach wrote:
>> On 12/4/14 07:45, Peter Saint-Andre - &yet wrote:
>>> On 12/4/14, 8:00 AM, Ron wrote:
>>>> On Wed, Dec 03, 2014 at 07:20:45PM -0700, Peter Saint-Andre - &yet
>>>> wrote:
>>>>> IMHO we need to either pull out the future-oriented text entirely
>>>>> (which has its own problems) or significantly improve it. I would
>>>>> be happy to propose text for the latter.

   I share Peter's concern: but not knowing what text is proposed, I'm
not ready to respond to specifics.

   Generally, we _cannot_ bind any future WG; and we _must_ avoid making
a WG statement about the validity of any IPR claims...

[Ron@debian responded:]

>>>> I'd definitely be interested in seeing proposals from you to improve
>>>> upon these things.  It seemed premature to explore this until we had
>>>> some sense of whether this kind of compromise could fly at all, but
>>>> now that it seems it can, I think these are important details for us
>>>> to clarify as best we can.
>>> OK, I'll get to work. :-)

[Adam Roach responded:]
>> Awesome, thanks. I've always found your prose to be clearer and easier
>> to read than mine anyway. :)
>> When you draft your text, keep in mind that what we're trying to do is
>> capture the essence of the agreement that we've formed a critical mass
>> around. The less formal (i.e., not really document-ready) version of
>> this is:

============================== Adam's text ==============================
>>> "WebRTC devices MUST implement both VP8 and H.264. If compelling
>>> evidence arises that one of the codecs is available for use on a
>>> royalty-free basis, such as all IPR declarations known for the codec
>>> being of (IETF) Royalty-Free or (ISO) type 1, the IETF will change
>>> this normative statement to indicate that only that codec is required.
>>> For absolute, crystal clarity, this provision is only applicable to
>>> WebRTC devices, and not to WebRTC User Agents."
============================== Adam's text ==============================
>> There's nuance to be added there, for sure, but I'd encourage you not to
>> color way outside those lines. Expanding scope to discuss issues such as
>> *other* circumstances that may cause revisiting the MTI, for example,
>> are far more likely to weaken consensus than they are to strengthen it.

   (I don't know whether this is the text which Hawaii hummed for.)

   Actually, I have less problems with this text than with other versions
I have seen. It lists a specific condition of IPR declarations which is
not subject to on-list arguments (which is acceptable), but goes beyond
that with "such as" (which I find worrysome).

   Obviously, the condition it listed is wildly improbable except for
the "such as" language (which would enable on-list arguments). Further,
the pretense that this document could bind a future WG is ridiculous.

[Peter responded to Adam:]
> I see two kinds of triggers:
> 1. A trigger that is specific to the alternatives we have been presented 
> so far. That is: only H.264 or VP8 (or both) can be MTI. If we learn 
> that one of them can be used royalty-free, then that codec will be the 
> only MTI codec.
> Questions:
> 1a. Does this trigger fire as soon as one codec is learned to be usable 
> royalty-free? So this is a first-past-the-post contest? (Let's say codec 
> "c1" is learned to be usable RF and the next week or month or quarter 
> "c2" is learned to be usable RF. What happens?)
> 1b. Text along the lines of "the IETF will change this normative 
> statement" does not make it clear how that will happen. Is there an 
> automatic trigger (i.e., it's built into this document)? Or does the 
> IETF need to do something (e.g., publish an RFC that obsoletes this one)?
> (There is some interaction between 1a and 1b. If some process is needed 
> to declare "c1" the only MTI, then it's possible that we might learn 
> that "c2" can also be used RF before the obsoleting RFC can be published.)

   Peter is not being difficult here: no process is specified for the
IETF to "change this normative statement", and it could take many months
to do so.

> 2. A trigger that is more general and future-proof. That is: someday 
> (perhaps before too much longer on the standardization timescale) we 
> will have other alternatives to consider: H.265, VP9, VP10, Daala, and 
> who knows what.

   (I'd be amazed if we didn't have at least one of these ready to use
before this document is published as an RFC.)

> Another question:
> 2a. There is some interaction between 1b and 2. Let's say it takes us 10 
> years to learn that "c1" can be used RF. Hurray! But by that time, we 
> might have "c3" and "c4" and "c5" to consider. Are we forbidden from 
> considering anything but "c1" and "c2" at that time?

   Peter _is_ being difficult here: obviously nothing we could do would
bind us or any other WG that tightly.

> I *think* that the trigger you're talking about is #1. Personally I am 
> much more interested in #2 because I don't think we'll really settle 
> this issue in the medium term or long term until we have the video 
> equivalent of Opus.

   IMHO, if we accept this text, we'll effectively bind future
implementations to implement both H.264 and VP8 for many years to come.
YMMV, of course...

> Because I think we're talking about different triggers for different 
> purposes, my impression is that the text we have in mind would differ 
> significantly (in particular, I feel no compulsion to "stay within the 
> lines" because I think those lines are not useful, and indeed are 
> positively harmful, in the long term).


John Leslie <>