Re: [codec] Discussion around ITU LS
"Michael Ramalho (mramalho)" <mramalho@cisco.com> Wed, 14 September 2011 13:21 UTC
Return-Path: <mramalho@cisco.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 39BF921F8BFE for <codec@ietfa.amsl.com>; Wed, 14 Sep 2011 06:21:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.207
X-Spam-Level:
X-Spam-Status: No, score=-2.207 tagged_above=-999 required=5 tests=[AWL=0.392, 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 b+q6xYYxfk3i for <codec@ietfa.amsl.com>; Wed, 14 Sep 2011 06:21:07 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7570421F8B58 for <codec@ietf.org>; Wed, 14 Sep 2011 06:21:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mramalho@cisco.com; l=8153; q=dns/txt; s=iport; t=1316006597; x=1317216197; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=k3KE3Xt/gWq+cRMN/P6W0KvpWXQFEp8XlZfWacHU53s=; b=DvvKadj3A4Nn8IcJq1W4X2n7jat48s/2xi8iisxt5gVjlwmQ6Ja2hISC ncPTnVzwnhliKecpHqqlc5aKJxZg4JlzW8qeYj7SRa0D4SpeU2c1O3f1B adyARa2TAXSqnnwwO5xMWpO9Izd3/8rsbfeDo0zptQTYTnibNFdpkcbre Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ar4AALypcE6tJV2c/2dsb2JhbABBmGyOe3iBUwEBAQECAQEBAQ8BHQoxAwYFBQcEAgEIEQQBAQEKBhcBBgEmHwkIAgQBEggTB4dVBJdpAZ46hg5gBIdukHWMHw
X-IronPort-AV: E=Sophos;i="4.68,380,1312156800"; d="scan'208";a="21404062"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 14 Sep 2011 13:23:16 +0000
Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p8EDNGPt003535; Wed, 14 Sep 2011 13:23:16 GMT
Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Sep 2011 08:23:16 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 14 Sep 2011 08:23:13 -0500
Message-ID: <999109E6BC528947A871CDEB5EB908A0049A1C5C@XMB-RCD-209.cisco.com>
In-Reply-To: <6A58A83F7040374B9FB4EEEDBD835512A404F2@LHREML503-MBX.china.huawei.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [codec] Discussion around ITU LS
Thread-Index: AQHMbNdFqNL2VxoWr0KOLjBFjn6nQ5VBQIaAgAIGLdWAADZ+gIAF5oZEgAKlxYCAALuIO4AAHcCQ
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><4E6FFD21.4090801@mozilla.com> <6A58A83F7040374B9FB4EEEDBD835512A404F2@LHREML503-MBX.china.huawei.com>
From: "Michael Ramalho (mramalho)" <mramalho@cisco.com>
To: Anisse Taleb <Anisse.Taleb@huawei.com>, Jean-Marc Valin <jmvalin@mozilla.com>
X-OriginalArrivalTime: 14 Sep 2011 13:23:16.0208 (UTC) FILETIME=[76227700:01CC72E1]
Cc: Jonathan Rosenberg <jonathan.rosenberg@skype.net>, 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 13:21:12 -0000
Jean-Marc, I believed, as I think a lot of folks on this list did, that a USER of OPUS need NOT BE A SPEECH/AUDIO CODING EXPERT to use OPUS. The fact (as you stated on a previous volley) that you could easily add the time-warping capabilities post OPUS decoding defeats the point - you want your users NOT to need to be that expert in signal processing. I find it amazing that Anisse's constructive comments are being met with such resistance ... as such capabilities were touted as a major reason why this work needed to be performed in the IETF. How exactly is OPUS technically differentiated (other than marginal differences in quality at bit rates within a factor of ~ 1.3x *) from existing codecs developed in other SDOs? Although such time warping capabilities were weakly worded in the actual IETF requirements as "desirable" - the functionality Anisse is asking to be in the baseline codec was highlighted as a major reason why the IETF needed to do this work. So, don't re-invent the wheel ... put an important capability that THE IETF used as (partial) RATIONALE for this work into the actual delivery of the base OPUS codec. To infer that a user of OPUS needs to be as expert as an audio/speech coder to add this capability is ludicrous. Regards, Michael Ramalho, Ph.D. PS - Said another way, if you add these capabilities the CODEC working group will in fact deliver a codec with native capabilities differentiated from all other SDOs ... and strengthens the IETF justification for this work ... and all this debate goes away! * - The parenthetical is not intended as a derogatory remark or jab, but rather is just a reflection of the state of the art in speech/audio coding. You all worked hard for that 1.3x. -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Anisse Taleb Sent: Wednesday, September 14, 2011 8:44 AM To: Jean-Marc Valin Cc: Jonathan Rosenberg; codec@ietf.org Subject: Re: [codec] Discussion around ITU LS Dear Jean-Marc, > 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. I think you are confusing format of the specification and objectives of the WG. The charter clearly states that the goal is to ensure the existence of a single high-quality audio codec that is optimized for use over the internet. > So I have really no desire to reinvent the wheel. We are already reinventing new wheels by introducing a new codec :-). Joke aside, as I said in my previous email, it would be good that such functionality is present in the code distribution. I didn't mean that it should be developed from scratch, if what NetEQ offers is suitable, freely available and easily distributed, inclusion of such "example code" in the opus code distribution would be more than welcome, and I would say even necessary according to the target of this group and the requirements on the internet codec. If that is not agreeable, I would suggest that the codec specification, either clearly and explicitly states that time scaling is not supported by the Opus codec and a link to an external code, NetEQ for example, is provided. Please consider this as a way to avoid confusion (which I strongly believe is the case) on the nature of the functionality offered by the "Internet Codec" developed by IETF. The purpose of the IETF codec WG is to design a codec which specifically targets Internet applications (easily distributed with all needed functionality) and it was felt that such a codec was not available in other SDOs. There have been many comments on this very mailing list in favor of such functionality, it is even mentioned in the requirements document albeit with a weak wording. I am certainly baffled as to why such an essential functionality for optimal use of the codec on the internet is meeting such resistance. What functionality does the Opus codec offer which makes it optimized (or more optimized than other codecs) for the use over the internet ? Kind regards, /Anisse ________________________________________ From: Jean-Marc Valin [jmvalin@mozilla.com] Sent: 14 September 2011 03:02 To: Anisse Taleb Cc: Cullen Jennings; Jonathan Rosenberg; codec@ietf.org Subject: Re: [codec] Discussion around ITU LS 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/ma in/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 >> >> _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec
- [codec] Discussion around ITU LS Cullen Jennings
- Re: [codec] Discussion around ITU LS Stephan Wenger
- Re: [codec] Discussion around ITU LS Monty Montgomery
- Re: [codec] Discussion around ITU LS Jean-Marc Valin
- Re: [codec] Discussion around ITU LS Gregory Maxwell
- Re: [codec] Discussion around ITU LS Anisse Taleb
- Re: [codec] Discussion around ITU LS Jean-Marc Valin
- Re: [codec] Discussion around ITU LS Anisse Taleb
- Re: [codec] Discussion around ITU LS Jean-Marc Valin
- Re: [codec] Discussion around ITU LS Christian Hoene
- Re: [codec] Discussion around ITU LS Anisse Taleb
- Re: [codec] Discussion around ITU LS Michael Ramalho (mramalho)
- Re: [codec] Discussion around ITU LS Benjamin M. Schwartz
- Re: [codec] Discussion around ITU LS Gregory Maxwell
- Re: [codec] Discussion around ITU LS Jean-Marc Valin
- Re: [codec] Discussion around ITU LS Jean-Marc Valin
- Re: [codec] Discussion around ITU LS Michael Ramalho (mramalho)
- Re: [codec] Discussion around ITU LS Benjamin M. Schwartz
- Re: [codec] Discussion around ITU LS Benjamin M. Schwartz
- Re: [codec] Discussion around ITU LS Anisse Taleb
- Re: [codec] Discussion around ITU LS Koen Vos