Re: [rtcweb] Codec Draft

Cullen Jennings <fluffy@cisco.com> Fri, 30 December 2011 09:38 UTC

Return-Path: <fluffy@cisco.com>
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 C60B221F84D5 for <rtcweb@ietfa.amsl.com>; Fri, 30 Dec 2011 01:38:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.38
X-Spam-Level:
X-Spam-Status: No, score=-105.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, RCVD_IN_DNSWL_MED=-4, 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 PFObYyfxBxKr for <rtcweb@ietfa.amsl.com>; Fri, 30 Dec 2011 01:38:37 -0800 (PST)
Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id BB45121F84CC for <rtcweb@ietf.org>; Fri, 30 Dec 2011 01:38:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=5819; q=dns/txt; s=iport; t=1325237917; x=1326447517; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ppNNQEKQIw6wiQu6MSUz/qB0x5WHSRLPWjhh76T4ebc=; b=EevD5iUTiGfl/xwkxKlnKqY1tkn0hHYlB//t+2n9eWQciu3HUh+iT04a NI42pYobZXYDhsVRvRiZ9j5wc7DIir8Djnqx0bOmSI7rY2gZoWKX1T52Q USZfqOHoxUAcK5qYGeHix3ffk+78rHQuIKXD31nF6qbaZWRcOKKBY57o1 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqUAAF6F/U6rRDoI/2dsb2JhbABCnBKQYYEFgXIBAQEDAQEBAQ8BWwsFBwQLEQQBAQEuJygIBhMUDodYCJdnAZ4VBIssYwSVAoVPjHk
X-IronPort-AV: E=Sophos;i="4.71,431,1320624000"; d="scan'208";a="23076128"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 30 Dec 2011 09:38:36 +0000
Received: from [10.21.76.146] ([10.21.76.146]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pBU9cWwB026109; Fri, 30 Dec 2011 09:38:34 GMT
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=windows-1252
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <CAJNg7VLUAafSyGzR3jgXD77hYjER7-SHx61nBekXPkB2KexJiA@mail.gmail.com>
Date: Thu, 29 Dec 2011 08:49:59 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2D78F8F3-5331-4B2B-BD84-7200FC18156B@cisco.com>
References: <746276993.96103.1324085707648.JavaMail.root@zimbra1.shared.sjc1.mozilla.com> <4EECEA08.5050300@sbcglobal.net> <CAJNg7VLUAafSyGzR3jgXD77hYjER7-SHx61nBekXPkB2KexJiA@mail.gmail.com>
To: Marshall Eubanks <marshall.eubanks@gmail.com>
X-Mailer: Apple Mail (2.1251.1)
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: Fri, 30 Dec 2011 09:38:38 -0000

When the CODEC WG was formed there was interesting discussion around the point of making RF required. 

Lets say we have two proposals on the table, A and B. Some person of dubious morals decides they don't like proposal A. They make an IETF IPR disclosure on A that says that their employer *might* have IPR on A and they have not yet decided on licensing terms. At that point proposal A is removed from the table even thought much of the WG may not believe that the IPR being claimed is actually valid. The important thing is we leave give the participants of the WG the information we know about the IPR status yet at the same time allow them to decisions about if they want to go forward with proposal A or B. 

The above attack was a key part of they the codec WG charter uses the word "preferred" instead of "required". 

On a side note, has any SDO ever done a "reviewable substantiation of royalty-free status" for anything? I'd love to see one. 

On a separate note about the MPEG work on RF codecs …I think this is great to see any SDO taking this on. However, Lets say it takes 1/2 year to get going, then 1.5 years to finish the standard, then 2 years to get into chip sets, then another 2 years to get in enough chipsets of widely distributed products that it becomes interesting in the fact that a larger percentage of devices can do it … we are looking many years out. The timeline I just gave was much faster than the adoption of H.264 which is likely the mostly hazily invested in codec ever from point of adoption. My point is, I don't think the browser are going to wait for this new codec as the mandatory to implement codec for WebRTC. However, clearly WebRTC should be able to negotiate a new codec like this is both sides support it. My prediction is we will see development of royalty free video codecs at SDOs. IMHO none of the current SDOs have a process and IPR rules that both allows the open source community and individual contributors to participate while at the same time ensuring enough secrecy that ideas could not be "poached" by patent trolls and  ensuring that employers of participants where bound to an RF agreement. W3C is likely the closet model to allow something like this. 


On Dec 20, 2011, at 6:04 , Marshall Eubanks wrote:

> On Sat, Dec 17, 2011 at 2:14 PM, Rob Glidden <rob.glidden@sbcglobal.net> 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."
>> 
> 
> I like this text, except that "royalty-free" is like "non-encumbered
> by patents" and other such text - you can never be sure.
> All you can want is one that _claims_ to be royalty-free, and the text
> should reflect that IMO.
> 
> I also don't think that "and provide" scans very well as is.
> 
> So, how about
> 
> "The REQUIRED video codec should be a codec which has been both
> specified and asserted to be royalty-free by a recognized standards
> process such as MPEG or other
> due-process standards group and should provide reviewable substantiation of its
> royalty-free status."
> 
> Regards
> Marshall
> 
> 
>> 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
>>> 
>> 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb