Re: [rtcweb] Finishing up the Video Codec document

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Sun, 07 December 2014 09:09 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
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 4DC151A1B6D for <rtcweb@ietfa.amsl.com>; Sun, 7 Dec 2014 01:09:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.199
X-Spam-Level:
X-Spam-Status: No, score=0.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 ihPV41tsKiR2 for <rtcweb@ietfa.amsl.com>; Sun, 7 Dec 2014 01:09:07 -0800 (PST)
Received: from scintmta01-14.scbb.aoyama.ac.jp (scintmta01-14.scbb.aoyama.ac.jp [133.2.253.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1DA1A1ACC for <rtcweb@ietf.org>; Sun, 7 Dec 2014 01:09:07 -0800 (PST)
Received: from scmeg01-14.scbb.aoyama.ac.jp (scmse.scbb.aoyama.ac.jp [133.2.253.15]) by scintmta01-14.scbb.aoyama.ac.jp (Postfix) with ESMTP id 2A95132E554; Sun, 7 Dec 2014 18:08:22 +0900 (JST)
Received: from itmail2.it.aoyama.ac.jp (unknown [133.2.206.134]) by scmeg01-14.scbb.aoyama.ac.jp with smtp id 39cc_35ac_779a8722_e018_418f_b04d_3b5482f0acce; Sun, 07 Dec 2014 18:08:21 +0900
Received: from [133.2.249.139] (unknown [133.2.249.139]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 446B6BF511; Sun, 7 Dec 2014 18:08:21 +0900 (JST)
Message-ID: <54841903.2050208@it.aoyama.ac.jp>
Date: Sun, 07 Dec 2014 18:08:19 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Peter Saint-Andre - &yet <peter@andyet.net>, 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> <5483B818.7050102@andyet.net>
In-Reply-To: <5483B818.7050102@andyet.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/sDYzuWvjle7gyIQBGDvRZ1MgDNc
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 09:09:09 -0000

Hello Peter,

I agree with Ron and Harald that the details are difficult if not 
impossible to nail down. I see this as a broad statement of intent, with 
two purposes: 1) encourage better license conditions from those who have 
the power to make that happen, and 2) let the world know most of us 
(maybe even everybody?) would prefer to have only one MTI codec, RF and 
otherwise unencumbered of course.

The rest can only be decided in the future, not now.

Regards,   Martin.

On 2014/12/07 11:14, 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'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
>