Re: [rtcweb] Codec Draft

Harald Alvestrand <harald@alvestrand.no> Sun, 18 December 2011 22:12 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6082E21F8482 for <rtcweb@ietfa.amsl.com>; Sun, 18 Dec 2011 14:12:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.999
X-Spam-Level:
X-Spam-Status: No, score=-107.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsO6X-SAr4GB for <rtcweb@ietfa.amsl.com>; Sun, 18 Dec 2011 14:12:13 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 86A3A21F8484 for <rtcweb@ietf.org>; Sun, 18 Dec 2011 14:12:13 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6C50F39E148; Sun, 18 Dec 2011 23:12:12 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X9PQls1gMYeI; Sun, 18 Dec 2011 23:12:11 +0100 (CET)
Received: from [192.168.1.71] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 390AF39E106; Sun, 18 Dec 2011 23:12:11 +0100 (CET)
Message-ID: <4EEE653B.9090307@alvestrand.no>
Date: Sun, 18 Dec 2011 23:12:11 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: Rob Glidden <rob.glidden@sbcglobal.net>
References: <746276993.96103.1324085707648.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4EECEA08.5050300@sbcglobal.net>
In-Reply-To: <4EECEA08.5050300@sbcglobal.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org, Cary Bran <Cary.Bran@plantronics.com>
Subject: Re: [rtcweb] Codec Draft
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Dec 2011 22:12:14 -0000

On 12/17/2011 08:14 PM, Rob Glidden wrote:
> Chris:
>
> No, not at all, I'm saying something altogether different: I am saying 
> all these kinds of characterizations supporting old text, however 
> framed, cast wrong procedural net, for multiple reasons.
>
> Proposed new text is straightforward and should be unobjectionable:
>
> "The REQUIRED video codec should be a royalty-free codec which has 
> been specified by a recognized standards process such as MPEG or other 
> due-process standards group and provide reviewable substantiation of 
> its royalty-free status."
The long parse of that is (as I read it):

* Royalty-free is a requirement.
* Specified (not just blessed) by an acceptable standards process is a 
requirement.
* MPEG's process is an acceptable standards process.
* There has to be documentation of royalty-free status that can be reviewed.

Implicit in the statement (given that this is the only statement) is:

* There is no reason to talk about the technical quality of the codec.
* The form of IPR documentation, or the amount of review, can be left 
unspecified. This can be read as an implicit assumption that MPEG's 
currently specified IPR process is "good enough".
* It is OK to wait until such a royalty-free codec exists before 
emitting the specification.

Of these seven points, there is only one I'm sure I agree with.

              Harald


>
> Rob
>
> On 12/16/2011 5:35 PM, Chris Blizzard wrote:
>> ----- Original Message -----
>>> From: "Rob Glidden"<rob.glidden@sbcglobal.net>
>>> To: "Chris Blizzard"<blizzard@mozilla.com>
>>> Cc: "Harald Alvestrand"<harald@alvestrand.no>rand.no>, rtcweb@ietf.org, 
>>> "Cary Bran"<Cary.Bran@plantronics.com>
>>> Sent: Thursday, December 15, 2011 10:45:59 AM
>>> Subject: Re: [rtcweb] Codec Draft
>>> Chris:
>>>
>>> "MPEG-LA-is-a-monopolist" characterization casts wrong procedural net,
>>> among reasons pending lawsuits -- one more reason to be accurate and
>>> follow procedure.
>>>
>> Sorry for the follow-up, but just to be clear, this is not what I 
>> said.  What I said is this:
>>
>>>> To get at the heart of the issue, I think that many people would
>>>> like to use H.264 support as the default. It's lower-friction and
>>>> widely deployed. But that's entirely up to the rights holders for
>>>> that technology. That's why there's a date and a specific call-out
>>>> to MPEG LA as the monopoly rights holder in the text. It's up to
>>>> them to decide, and they have three months from tomorrow to do so.
>>>>
>>>> --Chris
>>>>
>> MPEG LA is the monopoly licensor for H.264.  Patents are legal 
>> government-sponsored monopolies and they license many of the patents 
>> for that technology.  (Although they clearly disallow the assertion 
>> that they have all of them via their license!)  "Monopolist" as you 
>> put it has a somewhat criminal tone in normal usage and would be the 
>> result of their actions with that monopoly in place.  I want to be 
>> clear that I did not mean that and that's your interpretation, not mine.
>>
>> --Chris
>>
>
>