Re: [rtcweb] Finishing up the Video Codec document

John Leslie <john@jlc.net> Fri, 12 December 2014 17:34 UTC

Return-Path: <john@jlc.net>
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 D91AC1A6FB5 for <rtcweb@ietfa.amsl.com>; Fri, 12 Dec 2014 09:34:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.51
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7PjqZMCWEfE for <rtcweb@ietfa.amsl.com>; Fri, 12 Dec 2014 09:34:18 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0131A1BBF for <rtcweb@ietf.org>; Fri, 12 Dec 2014 09:34:18 -0800 (PST)
Received: by mailhost.jlc.net (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 <john@jlc.net>
To: Peter Saint-Andre - &yet <peter@andyet.net>
Message-ID: <20141212173415.GH47023@verdi>
References: <547511DB.5050100@nostrum.com> <547FC4FD.2050300@andyet.net> <20141204150041.GI10449@hex.shelbyville.oz> <54808198.7030207@andyet.net> <54808719.10402@nostrum.com> <5483B818.7050102@andyet.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <5483B818.7050102@andyet.net>
User-Agent: Mutt/1.4.1i
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/O-R5fwtzsoT75ZWDDxeHzhskaVM
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Finishing up the Video Codec document
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: Fri, 12 Dec 2014 17:34:21 -0000

On Sat, 06 Dec 2014,
Peter Saint-Andre - &yet <peter@andyet.net> 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).

   +1

--
John Leslie <john@jlc.net>