Re: [codec] A concrete proposal for requirements and testing

Jean-Marc Valin <jean-marc.valin@octasic.com> Thu, 07 April 2011 01:35 UTC

Return-Path: <jean-marc.valin@octasic.com>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DD643A69E3 for <codec@core3.amsl.com>; Wed, 6 Apr 2011 18:35:45 -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=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-PDg2b3zDQi for <codec@core3.amsl.com>; Wed, 6 Apr 2011 18:35:44 -0700 (PDT)
Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 3B52D3A6824 for <codec@ietf.org>; Wed, 6 Apr 2011 18:35:44 -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-mh-mrz21.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0LJ9000S3DTITZA0@vl-mh-mrz21.ip.videotron.ca> for codec@ietf.org; Wed, 06 Apr 2011 21:36:55 -0400 (EDT)
Message-id: <4D9D1546.7010901@octasic.com>
Date: Wed, 06 Apr 2011 21:37: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: Paul Coverdale <coverdale@sympatico.ca>
References: <64212FE1AE068044AD567CCB214073F123A10234@MAIL2.octasic.com> <F5AD4C2E5FBF304ABAE7394E9979AF7C26BC47FA@LHREML503-MBX.china.huawei.com> <4D9CB1AA.3050101@octasic.com> <BLU0-SMTP62BA6C70DCFE9EAC0B522ED0A50@phx.gbl>
In-reply-to: <BLU0-SMTP62BA6C70DCFE9EAC0B522ED0A50@phx.gbl>
Cc: codec@ietf.org
Subject: Re: [codec] A concrete proposal for requirements and testing
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 07 Apr 2011 01:35:45 -0000

On 11-04-06 06:41 PM, Paul Coverdale wrote:
> When I mentioned 40-60 listeners for an MOS test, this was the number that
> we used to try to use in tests in Nortel. Of course, more listeners are
> better, but often there are constraints on time and money. The ITU examples
> I sent earlier specify 32 listeners for the NB/WB test and 24 for the SWB
> test. I would suggest 24 listeners as a minimum.

Thanks. Noted.

> I (and others) suggested the use of objectives ("nice to have") as well as
> requirements ("must have") in the requirements document, but I didn't
> specifically propose "no worse than AMR-NB" (or AMR-WB) as an objective. In
> fact, my preference would be to include AMR-NB and AMR-WB as requirements in
> section 4.2, since there is not much else of substance there.

I strongly disagree with including AMR-NB and AMR-WB as strict 
requirements for several reasons. Those codecs are not credible 
alternatives to Opus within the charter of this WG, to "try to avoid 
encumbered technologies."

Also, I note from the ITU test plan for G.729.1 (then G.729EV) you sent 
that it does not even mention AMR-NB. As for AMR-WB (G.722.2), it is 
only included at a bit-rate of 8.85 kb/s even though the lowest G.729.1 
bit-rate is (AFAIK) 14 kb/s. Looking at this paper from Nokia: 
http://research.nokia.com/files/public/%5B11%5D_ICASSP2010_Voice%20Quality%20Evaluation%20of%20Various%20Codecs.pdf

we see that G.729.1 is clearly worse than AMR-WB. Despite that, it seems 
like the ITU-T has seen the value of this codec, which supports both 
narrowband and wideband at multiple rates. The codec we're designing 
here is meant to do not only narrowband and wideband, but also 
super-wideband and fullband, for both speech and music and for mono and 
stereo. This is something which -- to the best of my knowledge -- has 
not been done before for an interactive codec. Requiring Opus to also 
beat all codecs out there in all circumstances is thus totally 
unreasonable (despite the fact that the tests we did so far indicate we 
may be close to that).

Cheers,

	Jean-Marc