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

Jean-Marc Valin <jean-marc.valin@octasic.com> Mon, 18 April 2011 21:46 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 B7818E07F3 for <codec@ietfc.amsl.com>; Mon, 18 Apr 2011 14:46:49 -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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7Q1T1cGfjUz for <codec@ietfc.amsl.com>; Mon, 18 Apr 2011 14:46:48 -0700 (PDT)
Received: from toroondcbmts08-srv.bellnexxia.net (toroondcbmts08.bellnexxia.net [207.236.237.42]) by ietfc.amsl.com (Postfix) with ESMTP id 77E07E0718 for <codec@ietf.org>; Mon, 18 Apr 2011 14:46:45 -0700 (PDT)
Received: from toip58-bus.srvr.bell.ca ([67.69.240.185]) by toroondcbmts08-srv.bellnexxia.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20110418214644.VEXK12818.toroondcbmts08-srv.bellnexxia.net@toip58-bus.srvr.bell.ca>; Mon, 18 Apr 2011 17:46:44 -0400
Received: from toip36-bus.srvr.bell.ca ([67.69.240.37]) by toip58-bus.srvr.bell.ca with ESMTP; 18 Apr 2011 17:46:38 -0400
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAMGorE3PPaAN/2dsb2JhbAClQXfGBYMSgl8EkXUH
Received: from mail.octasic.com ([207.61.160.13]) by toip36-bus.srvr.bell.ca with ESMTP; 18 Apr 2011 17:46:38 -0400
Received: from [10.100.50.90] (10.100.50.90) by MAIL1.octasic.com (10.100.10.44) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 18 Apr 2011 17:46:38 -0400
Message-ID: <4DACB13E.9050101@octasic.com>
Date: Mon, 18 Apr 2011 17:46:38 -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
MIME-Version: 1.0
To: David Virette <david.virette@huawei.com>
References: <F5AD4C2E5FBF304ABAE7394E9979AF7C26BC684E@LHREML503-MBX.china.huawei.com> <4DA7B88F.80002@jmvalin.ca> <4DA7CE76.1040502@jmvalin.ca> <031201cbfdd2$7d229910$7767cb30$%virette@huawei.com> <4DAC7AEE.8050101@octasic.com> <037101cbfe0b$1c6c5c30$55451490$%virette@huawei.com>
In-Reply-To: <037101cbfe0b$1c6c5c30$55451490$%virette@huawei.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.100.50.90]
Cc: 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: Mon, 18 Apr 2011 21:46:49 -0000

On 11-04-18 04:56 PM, David Virette wrote:
> Hi Jean-Marc,
> I agree that a well-designed VoIP application should ideally use the
> available bandwidth and I think that in the current test plan, the maximum
> available bandwidth will always be taken into account. For super-wideband
> mode, the input will be 32 kHz, then low pass filtered at 14 kHz and then
> probably resampled at 24 kHz for OPUS allowing it to use its maximum
> bandwidth for those modes.

Well, if you low-pass filter at 14 kHz then by definition you're not using 
all the available bandwidth. If what you have is a 32 kHz input signal, 
then the best thing you can do is resample it to *48* kHz (without any 
low-pass filtering) and then feed it to Opus at that rate. You can consider 
Opus as a 48 kHz codec that can also do lower bandwidths. In fact, the best 
way to use Opus is to always run it at 48 kHz and to let it scale bandwidth 
internally based on the bit-rate. A while ago I posted this sample of Opus 
scaling from 8 kb/s narrowband to 60 kb/s fullband: 
http://jmvalin.ca/misc_stuff/opus_sweep.wav

Cheers,

	Jean-Marc