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

Jean-Marc Valin <jmvalin@jmvalin.ca> Thu, 31 March 2011 16:42 UTC

Return-Path: <jmvalin@jmvalin.ca>
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 489593A6A33 for <codec@core3.amsl.com>; Thu, 31 Mar 2011 09:42:01 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwsP63RaBMH9 for <codec@core3.amsl.com>; Thu, 31 Mar 2011 09:42:00 -0700 (PDT)
Received: from smtpi4.usherbrooke.ca (smtpi4.USherbrooke.ca [132.210.236.3]) by core3.amsl.com (Postfix) with ESMTP id 2C86D3A6844 for <codec@ietf.org>; Thu, 31 Mar 2011 09:42:00 -0700 (PDT)
Received: from localhost (www11.sti.USherbrooke.ca [132.210.244.221]) by smtpi4.usherbrooke.ca (8.13.8/8.13.8) with ESMTP id p2VGhTil008982; Thu, 31 Mar 2011 12:43:29 -0400
Received: from 130.129.65.136 ([130.129.65.136]) by www.usherbrooke.ca (Horde Framework) with HTTP; Thu, 31 Mar 2011 12:43:29 -0400
Message-ID: <20110331124329.216219p5zb5npnpc@www.usherbrooke.ca>
Date: Thu, 31 Mar 2011 12:43:29 -0400
From: Jean-Marc Valin <jmvalin@jmvalin.ca>
To: Roman Shpount <roman@telurix.com>
References: <64212FE1AE068044AD567CCB214073F123A10234@MAIL2.octasic.com> <AANLkTinrS6e+i_VE5Q91gbNV5yhwi3Ad+wZOUsKYGNZn@mail.gmail.com>
In-Reply-To: <AANLkTinrS6e+i_VE5Q91gbNV5yhwi3Ad+wZOUsKYGNZn@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) H3 (4.3.7)
X-Originating-IP: 130.129.65.136
X-UdeS-MailScanner-Information:
X-UdeS-MailScanner-ID: p2VGhTil008982
X-UdeS-MailScanner: Aucun code suspect détecté
X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-7.499, requis 5, autolearn=not spam, BAYES_00 -2.60, RDNS_NONE 0.10, UDES_MONBUREAU03 -5.00)
X-UdeS-MailScanner-From: jmvalin@jmvalin.ca
Cc: "codec@ietf.org" <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, 31 Mar 2011 16:42:01 -0000

Hi,

Sorry, we should have made this clearer that when we mean "better" we  
mean quality vs bitrate coding efficiency. Otherwise nobody can ever  
beat the "16-bit PCM" codec (except maybe the 24-bit PCM codec) ;-)

Or are you suggesting that we compare G.722 to Opus running at 64  
kb/s? In that case should we be running Opus at its optimal point,  
which would probably be fullband stereo?

Cheers,

	Jean-Marc


Roman Shpount <roman@telurix.com> a écrit :

> I might be missing something, but how is it that G.722 is clearly
> out-performed by G.722.1? As far as I know G.722 at 64 KB has higher quality
> then wideband G.722.1 at any rate. Obviously, G.722 has higher bandwidth
> requirements, but has higher quality and lower bandwidth. Outperforming
> G.722 at 16KHz for all languages, and especially for multiple simultaneous
> speakers or non-speech sources is not an easy thing and should be tested
> against.
> _____________
> Roman Shpount
>
>
> On Thu, Mar 31, 2011 at 10:53 AM, Jean-Marc Valin <
> jean-marc.valin@octasic.com> wrote:
>
>>  Hi,
>>
>> Following the meeting and post-meeting discussions about requirements and
>> testing, we would like to make the following proposal which addresses the
>> opposing views which prevented consensus in the meeting today.
>>
>> First, we propose to remove the following codecs from the requirements:
>>
>> - GSM-FR, based on consensus from the list
>> - G.722, based on being clearly out-performed by G.722.1
>> - Speex-UWB, based on the fact that the author himself does not recommend
>> it being used :-)
>>
>> We can keep the other reference codecs as minimum quality requirement and
>> include being no worse than AMR-NB and AMR-WB as "objectives" that are "nice
>> to have", but not hard requirements.
>>
>> From there and based on the listening tests presented by Jan Skoglund
>> today, let's see what we can already conclude and what still needs more
>> testing:
>>
>> 1) The narrowband test showed that Opus had higher quality than Speex at 11
>> kb/s. Does anyone disagree that this is sufficient to meet the Sec 4.2
>> requirement of out-performing Speex in narrowband mode?
>>
>> 2) The narrowband test showed that Opus had higher quality at 11 kb/s than
>> iLBC at 15 kb/s. Does anyone disagree that this is sufficient to meet the
>> Sec 4.2 requirement of out-performing iLBC.
>>
>> 3) There have been no formal comparison with AMR-NB yet. What do you think
>> would be sufficient to assess the quality of Opus compared to AMR-NB?
>>
>> 4) The wideband test showed that Opus at 19.85 kb/s had higher quality than
>> Speex-WB at 24 kb/s. Does anyone disagree that this is sufficient to meet
>> the Sec 4.2 requirement of out-performing Speex in wideband mode?
>>
>> 5) The wideband test showed that Opus at 19.85 kb/s had higher quality than
>> G.722.1 at 24 kb/s. Does anyone disagree that this is sufficient to meet the
>> Sec 4.2 requirement of out-performing G.722.1?
>>
>> 6) The wideband test showed that Opus at 19.85 kb/s had higher quality than
>> AMR-WB at 19.85 kb/s. Does anyone disagree that this is sufficient to
>> concluded that the proposed "nice to have" objective of "no worse than
>> AMR-WB" is met?
>>
>> 7) The fullband test showed that Opus at 32 kb/s had higher quality than
>> G.719 at 32 kb/s. Does anyone disagree that this is sufficient to meet the
>> Sec 4.2 requirement of out-performing G.722.1C, considering that G.719 has
>> already been shown to out-perform G.722.1C
>>
>> If you disagree with any of the points above -- as may very well be the
>> case -- please do provide a concrete test proposal that would be sufficient
>> to convince you.
>>
>> Cheers,
>>
>>     Jean-Marc and Koen
>>
>> _______________________________________________
>> codec mailing list
>> codec@ietf.org
>> https://www.ietf.org/mailman/listinfo/codec
>>
>>
>