Re: [codec] Individuals and hats

Cullen Jennings <fluffy@cisco.com> Fri, 15 April 2011 00:54 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: codec@ietfc.amsl.com
Delivered-To: codec@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 360C9E0888 for <codec@ietfc.amsl.com>; Thu, 14 Apr 2011 17:54:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.576
X-Spam-Level:
X-Spam-Status: No, score=-110.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9e3chmZK8xUN for <codec@ietfc.amsl.com>; Thu, 14 Apr 2011 17:54:16 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id 2635DE0876 for <codec@ietf.org>; Thu, 14 Apr 2011 17:54:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=3821; q=dns/txt; s=iport; t=1302828856; x=1304038456; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=kM5UmniZ/NobG/Lit35BcZtQO0klAGrbvVCvxW6VZzM=; b=SNqVbfhNEhhBsWbz12+K5qYeE5ngeAVEx4wPW8ehDfgQVi4zUk/0w+0E LTXLBfyROYIRbenkZx3eNkQk6u8paRI6WSqvE1F+0w/PU59OiaDgFPyqx d7+fipj+L7I1wJ8e0Vwv6AscX35ab3ckvkTduAnFPy1msCX74Dyil+NtZ 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEACOWp02rRDoI/2dsb2JhbAClf3eIb547nQ6FbgSFWogVg3M
X-IronPort-AV: E=Sophos;i="4.64,214,1301875200"; d="scan'208";a="430468187"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by sj-iport-1.cisco.com with ESMTP; 15 Apr 2011 00:54:15 +0000
Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3F0sEwh016196 for <codec@ietf.org>; Fri, 15 Apr 2011 00:54:15 GMT
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1084)
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <4DA6961B.5090706@natvig.com>
Date: Thu, 14 Apr 2011 18:54:14 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <D721ACF1-E898-4422-B1F0-EE35B5F00ABF@cisco.com>
References: <4DA6961B.5090706@natvig.com>
To: codec@ietf.org
X-Mailer: Apple Mail (2.1084)
Subject: Re: [codec] Individuals and hats
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 00:54:17 -0000

With my chair hat on, please indulge me in a bit of a rambling email.... the goals and motivations of people at IETF are often very complex and even a single person can have multiple conflicting goals. We have many people in this WG that have past experiences in comparing codecs. Some of them have done it in processes such at used at ITU-T. Others have done it other ways - for example Skype tried different codecs with users and looked at statistical lengths of calls. Longer calls meant more revenue for them and it was a very directly and object measure. It's not clear if the calls were longer because people loved the better quality and had more to say or if they were having such hard problems hearing each other that they had to repeat things and the calls took longer but no matter which of these it was, from Skype point of view the longer calls were better. Some people view less than 6 listeners as too small a sample set. Some people view less than 10,000 listeners too small a sample set. One thing should be clear to everyone, it's not easy to decide which is better and there are a wide variety of ways codecs are compares. A small fraction of people in this WG would probably be just as happy to see opus never happened but many of the people commenting on test plans are simply trying to say what they think is the best way to compare codecs. When someone proposes some testing approach, I would not assume that any given person was trying to block this work regardless of what role their employer may have in USAC or any other work. 

Discussing testing that no one will do, regardless if it is even impossible or not is a waste of time. We need to focus on what we can and will do. I realize there is a diversity in how formal tests can be and what different people would consider good enough. This is going to be easier if people work on the assumption that most the people on the list are good faith actors and are actually trying to get to a reasonable codec with a reasonable "truth in advertising" results about how good it actually is. 

Cullen <with my co-hair hat on>


PS - Trying to figure out anyone motivations is an impossible task - my employer, via mergers, is an founding member of MPEG-LA. My employer would probably make more money if everyone used uncompressed 24 bit audio samples at an 196 KHz sample rate. My employer use patents defensively and would be very happy to see all other companies do the same. I'm a huge supporter of how free  communication can change the world for better bringing peace and prosperity and have been involved with many projects, including lots of open source to help make this happen. Same for my employer. I like the IETF and want to see it remain one of the relevant SDOs for the internet. I once bet someone a beer that wavelet based codecs were not the future and have an economic incentive (of one beer) for them to fail. It's highly unlikely I can figure all of my own motivations in a this WG much less someone else's. 




On Apr 14, 2011, at 12:37 AM, Thorvald Natvig wrote:

> 
> I see from cursory googling that there is an overlap between some of the
> proponents of the impossible test plan and developers of MPEG USAC,
> which seems likely to become one of the most patent encumbered codecs in
> history.
> 
> There seems to be clear royalty-based gain to be had for individuals and
> companies if this workgroup should fail. Everyone in the IETF wears the
> hat of an individual, but it might be better to be upfront about the
> motivations for helping the workgroup succeed when there is such a clear
> conflict of interest.
> 
> Sincerely,
> Thorvald