Re: [codec] Discussion around ITU LS

Jean-Marc Valin <jmvalin@mozilla.com> Wed, 14 September 2011 00:59 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 5DFBD11E8083 for <codec@ietfa.amsl.com>; Tue, 13 Sep 2011 17:59:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 hV5kuqPsIg6D for <codec@ietfa.amsl.com>; Tue, 13 Sep 2011 17:59:58 -0700 (PDT)
Received: from dm-mail03.mozilla.org (dm-mail03.mozilla.org [63.245.208.213]) by ietfa.amsl.com (Postfix) with ESMTP id 9625511E8086 for <codec@ietf.org>; Tue, 13 Sep 2011 17:59:58 -0700 (PDT)
Received: from [172.16.167.211] (unknown [216.1.177.100]) (Authenticated sender: jvalin@mozilla.com) by dm-mail03.mozilla.org (Postfix) with ESMTP id CB52F4AEDCE; Tue, 13 Sep 2011 18:02:05 -0700 (PDT)
Message-ID: <4E6FFD21.4090801@mozilla.com>
Date: Tue, 13 Sep 2011 18:02:25 -0700
From: Jean-Marc Valin <jmvalin@mozilla.com>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
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> <4E68D175.9090703@mozilla.com> <6A58A83F7040374B9FB4EEEDBD835512A400EE@LHREML503-MBX.china.huawei.com>
In-Reply-To: <6A58A83F7040374B9FB4EEEDBD835512A400EE@LHREML503-MBX.china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1
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: Wed, 14 Sep 2011 00:59:59 -0000

Hi Anisse,

Keep in mind that what we are standardizing here is a format more than
an actual implementation, so there's nothing that prevents anyone from
using any stretching/shortening algorithm. And in fact, thanks to Google
we now have an open-source time stretching/shortening algorithm as part
of the GIPS NetEQ jitter buffer they recently released:
http://webrtc.googlecode.com/svn/trunk/src/modules/audio_coding/NetEQ/main/source/
(see accelerate.c and expand.c more specifically). So I have really no
desire to reinvent the wheel.

In fact, I think this functionality belongs closer to the jitter buffer
than to the codec. Something like the PLC (which is also not going to be
normatively specified) belongs to the Opus decoder because it has to
interact with the codec state (i.e. regenerate not only the missing
data, but its effect on the predictors), which is not the case for the
stretching/shortening algo.

Cheers,

    Jean-Marc

On 12/09/11 01:00 AM, Anisse Taleb wrote:
> Dear Jean Marc,
>
> The issue is really to understand how the Opus codec is optimized for the internet. I was under the impression that a major argument for starting this work in IETF is to supply a codec that is optimized for use on the internet and therefore functionality that facilitates operation in an IP based transport would be defacto part of the codec distribution. 
>
> The question of whether this is integrated in the decoder itself or outside the decoder (i.e. post-processing) depends mainly on the qualify and complexity of the two solution.  You seem to prefer the use of this feature as a post-processing stage to the audio output, would you like to elaborate why is this better than an integrated approach ? 
>
> Regardless of whether this is implemented inside or outside the decoder (your preferred solution), I strongly believe that such a feature needs to be part of the code distribution.
>
> Kind regards,
> /Anisse
>
> ________________________________________
> From: Jean-Marc Valin [jmvalin@mozilla.com]
> Sent: 08 September 2011 16:30
> To: Anisse Taleb
> Cc: Cullen Jennings; Jonathan Rosenberg; codec@ietf.org
> Subject: Re: [codec] Discussion around ITU LS
>
> 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
>>
>>