Re: [codec] Discussion around ITU LS

Jean-Marc Valin <jmvalin@mozilla.com> Thu, 08 September 2011 14:28 UTC

Return-Path: <jmvalin@mozilla.com>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8347521F8B9F for <codec@ietfa.amsl.com>; Thu, 8 Sep 2011 07:28:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdKeydquovYn for <codec@ietfa.amsl.com>; Thu, 8 Sep 2011 07:28:07 -0700 (PDT)
Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBD721F8B9E for <codec@ietf.org>; Thu, 8 Sep 2011 07:28:07 -0700 (PDT)
Received: from [192.168.1.142] (modemcable239.192-178-173.mc.videotron.ca [173.178.192.239]) (Authenticated sender: jvalin@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id C92C94AEDBA; Thu, 8 Sep 2011 07:29:57 -0700 (PDT)
Message-ID: <4E68D175.9090703@mozilla.com>
Date: Thu, 08 Sep 2011 10:30:13 -0400
From: Jean-Marc Valin <jmvalin@mozilla.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Anisse Taleb <Anisse.Taleb@huawei.com>
References: <35921B63-3FBC-411D-B587-4AB81F218E57@cisco.com> <4E66F111.9070008@mozilla.com> <6A58A83F7040374B9FB4EEEDBD835512A3FBAA@LHREML503-MBX.china.huawei.com>
In-Reply-To: <6A58A83F7040374B9FB4EEEDBD835512A3FBAA@LHREML503-MBX.china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Jonathan Rosenberg <jonathan.rosenberg@skype.net>, "codec@ietf.org" <codec@ietf.org>
Subject: Re: [codec] Discussion around ITU LS
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: Thu, 08 Sep 2011 14:28:07 -0000

Hi Anisse,

I agree that time stretching/shortening is a desirable feature. However, 
I think in the case of Opus it is best implemented outside the decoder 
using a good generic algorithm, rather than re-inventing the wheel. Of 
course, if you think an integrated implementation would be better, you 
are welcome submit a patch for it.

Cheers,

     Jean-Marc

On 08/09/11 06:38 AM, Anisse Taleb wrote:
> Dear Jean Marc,
>
>>> Does the WG consider  time shortening / stretching functionality they
>>> would want to include in opus as a technique to use for PLC?
>> While time stretching/shortening is something that can be useful, I
>> don't think it's really necessary for a codec *specification*. In fact
>> even the PLC is provided only as an example.
>
> Quoting the requirements document RFC 6366:
> "  It is desirable for the reference implementation to provide a time stretching/shortening
>     implementation, although it should not be normative."
>
> While I agree that this is something that should be non-normative, such an integrated implementation
> would be an important feature for any codec deployed on the internet and really differentiate Opus wrt. "codecs" which are considered unsuitable for the internet.
>
> Kind regards,
> /Anisse
>
>