Re: [rtcweb] Finishing up the Video Codec document

Peter Saint-Andre - &yet <peter@andyet.net> Sun, 07 December 2014 02:14 UTC

Return-Path: <peter@andyet.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 ECCF31A6FE5 for <rtcweb@ietfa.amsl.com>; Sat, 6 Dec 2014 18:14:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 fjFppFHVFDdk for <rtcweb@ietfa.amsl.com>; Sat, 6 Dec 2014 18:14:51 -0800 (PST)
Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 091421A6FE0 for <rtcweb@ietf.org>; Sat, 6 Dec 2014 18:14:51 -0800 (PST)
Received: by mail-ie0-f177.google.com with SMTP id rd18so2822941iec.22 for <rtcweb@ietf.org>; Sat, 06 Dec 2014 18:14:50 -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 :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=I8M5UUpQFnYNaLf+cA3bZQsK1ChdmQjxdux6TJMKD/o=; b=GIafZi/NAwT36OVPyxTPVXNOqIIAXa1X9EfCbG9lGvOo1/pp8wcuLBMfNxTb5tOdUh 7RoW+gkF1rvXTue8688IP9cXn0D3luFKwyBBS+fuEUj6I78nU8rmOwTOZOpQZhCJqa2W Qfw2d32R/lvcsECu+BMZ7rsFFNMVOFuQWBboMA591fOVh8aofFtcG1GtRcFYawRoOzHU IoQJn/lHQVfFZam0hjtT0cz33M+jfBVJNnjFPJxsMXoMBt+bCo/+kl4tPaSYbtaAqNTW J0pZk7PQMa2zMMLSe/wMFOdok4sFWa1zh6OnxVsVEUrThzkoKjCjWE/vNI/1x4wb31Z0 z+DA==
X-Gm-Message-State: ALoCoQnxqNpm0gi/KRWUJddPJ4DnKY8fBgPuiTDAdEvACt1+spvTcePGrv1ugUH6AYPaSh06LLq/
X-Received: by 10.50.12.97 with SMTP id x1mr9157876igb.48.1417918490446; Sat, 06 Dec 2014 18:14:50 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id 73sm9169958ioz.30.2014.12.06.18.14.49 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 06 Dec 2014 18:14:49 -0800 (PST)
Message-ID: <5483B818.7050102@andyet.net>
Date: Sat, 06 Dec 2014 19:14:48 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Adam Roach <adam@nostrum.com>, Ron <ron@debian.org>, rtcweb@ietf.org
References: <547511DB.5050100@nostrum.com> <547FC4FD.2050300@andyet.net> <20141204150041.GI10449@hex.shelbyville.oz> <54808198.7030207@andyet.net> <54808719.10402@nostrum.com>
In-Reply-To: <54808719.10402@nostrum.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/8FTyncTlHEObnJr5gEtLY0ihyXM
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: Sun, 07 Dec 2014 02:14:53 -0000

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'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. :-)
>
> 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:
>
>> "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."
>
> 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 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.)

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.

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?

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.

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).

Peter

-- 
Peter Saint-Andre
CTO @ &yet
https://andyet.com/