Re: [codec] draft test and processing plan for the IETF Codec

Jean-Marc Valin <jean-marc.valin@octasic.com> Tue, 19 April 2011 00:59 UTC

Return-Path: <jean-marc.valin@octasic.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 11520E074B for <codec@ietfc.amsl.com>; Mon, 18 Apr 2011 17:59:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 9fwFbMb+tZcG for <codec@ietfc.amsl.com>; Mon, 18 Apr 2011 17:59:11 -0700 (PDT)
Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by ietfc.amsl.com (Postfix) with ESMTP id 5510AE06ED for <codec@ietf.org>; Mon, 18 Apr 2011 17:59:11 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="ISO-8859-1"; format="flowed"
Received: from [192.168.1.14] ([184.160.206.46]) by VL-MR-MRZ20.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0LJV00AU6K23MN60@VL-MR-MRZ20.ip.videotron.ca> for codec@ietf.org; Mon, 18 Apr 2011 20:58:52 -0400 (EDT)
Message-id: <4DACDE5E.2090600@octasic.com>
Date: Mon, 18 Apr 2011 20:59:10 -0400
From: Jean-Marc Valin <jean-marc.valin@octasic.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8
To: Anisse Taleb <anisse.taleb@huawei.com>
References: <F5AD4C2E5FBF304ABAE7394E9979AF7C26BC684E@LHREML503-MBX.china.huawei.com> <BCB3F026FAC4C145A4A3330806FEFDA93BA8B6463D@EMBX01-HQ.jnpr.net> <BLU0-SMTP463B56C50578E4BB6938BBD0AD0@phx.gbl> <4DA6F158.7070103@octasic.com> <F5AD4C2E5FBF304ABAE7394E9979AF7C26BC8B9A@LHREML503-MBX.china.huawei.com>
In-reply-to: <F5AD4C2E5FBF304ABAE7394E9979AF7C26BC8B9A@LHREML503-MBX.china.huawei.com>
Cc: "codec@ietf.org" <codec@ietf.org>
Subject: Re: [codec] draft test and processing plan for the IETF Codec
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: Tue, 19 Apr 2011 00:59:12 -0000

On 11-04-18 07:37 PM, Anisse Taleb wrote:
> JM, Greg, Paul, [taking emails in chronological order was ill advised
> :-)]
>
> I do not disagree with the statistical pitfalls you mention. As Paul
> stated and also what I wrote in a direct reply to this, there is no
> single uber-requirement to be passed by the codec, rather a vector of
> requirements that summarize the performance of the codec compared to
> other codecs. These have to be analyzed and discussed one by one.

Then, I guess we have no need for BTs and NWTs in the test plan. In the 
end, once the results are analyzed, we'll be able to take each "codec 
pair" and say either "A is better than B", "B is better than A", or "A 
is tied with B" (null hypothesis). The WG members can then decide what 
to conclude from those.

Cheers,

	Jean-Marc

> Kind regards, /Anisse
>
>> -----Original Message----- From: codec-bounces@ietf.org
>> [mailto:codec-bounces@ietf.org] On Behalf Of Jean-Marc Valin Sent:
>> Thursday, April 14, 2011 3:07 PM To: Paul Coverdale Cc:
>> codec@ietf.org Subject: Re: [codec] draft test and processing plan
>> for the IETF Codec
>>
>>> I don't think the situation is as dire as you make out. Your
>>> analysis assumes that all requirements are completely
>>> independent. This is not the case, in many cases if you meet one
>>> requirement you are likely to meet others of the same kind (eg
>>> performance as a function of bit rate).
>>>
>>> But in any case, the statistical analysis procedure outlined in
>>> the test plan doesn't assume that every requirement must be met
>>> with absolute certainty, it allows for a confidence interval.
>>
>> This is exactly what Greg is considering in his analysis. He's
>> starting from the assumption that the codec really meets *all* 162
>> requirements. Consider just the NWT requirements: if we were truly
>> no worse than the reference codec, then with 87 tests against a 95%
>> confidence interval, we would be expected to fail about 4 tests
>> just by random chance. Considering both NWT and BT requirements,
>> the odds of passing Anisse's proposed test plan given the
>> assumptions above are 4.1483e-33. See http://xkcd.com/882/ for a
>> more rigorous analysis.
>>
>> Cheers,
>>
>> Jean-Marc _______________________________________________ codec
>> mailing list codec@ietf.org
>> https://www.ietf.org/mailman/listinfo/codec
> _______________________________________________ codec mailing list
> codec@ietf.org https://www.ietf.org/mailman/listinfo/codec
>
>