Re: [codec] Discussion around ITU LS

"Benjamin M. Schwartz" <bmschwar@fas.harvard.edu> Wed, 14 September 2011 15:29 UTC

Return-Path: <bmschwar@fas.harvard.edu>
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 918B321F8B1F for <codec@ietfa.amsl.com>; Wed, 14 Sep 2011 08:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.352
X-Spam-Level:
X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 0w6lmYB1+Zmo for <codec@ietfa.amsl.com>; Wed, 14 Sep 2011 08:29:03 -0700 (PDT)
Received: from us18.unix.fas.harvard.edu (us18.unix.fas.harvard.edu [140.247.35.198]) by ietfa.amsl.com (Postfix) with ESMTP id C434021F8B36 for <codec@ietf.org>; Wed, 14 Sep 2011 08:28:59 -0700 (PDT)
Received: from us18.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us18.unix.fas.harvard.edu (Postfix) with ESMTP id ADF2E4D5E62; Wed, 14 Sep 2011 11:31:08 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; s=mail; bh=95KPCFIz+nKo7qa 5We1n1RO8IAo0LJ5kWPvpepGtdDY=; b=VeifQnV+Lg4SD+rgZ/CBMTVufrbHwZ3 KejfnG6fqsscwf3ubVEBB/pl/SVGdROVpGcjXV1BTrRZ5adcdoo8yqONW3dWCrPW a56s/V//XmDkutIuDn2l6CwcPtuaZitcIYq4ITsMbca4bgKzCMMm4mfZhjXK8f84 1iz4Q9Sj+jZw=
DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; q=dns; s=mail; b=BtRz0ZEmc 7aQOf5FHAgbbLhHs3m1LlmNgX/s2Lq0el0UW2nekF1jUViWrkNLmmRnbQzs0/kYu cJVby7MMKytTku61dw6fx2Vi4LRrIVGATvCQoh7BcULADAsRqd88xl+NNdNrWXQ7 vEpzi6RzbW0Q8Sf0lua/M2emgFxGL9GnzU=
Received: from [172.23.141.122] (bwhmaincampuspat25.partners.org [170.223.207.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us18.unix.fas.harvard.edu (Postfix) with ESMTPSA id 988D24D5E5F; Wed, 14 Sep 2011 11:31:08 -0400 (EDT)
Message-ID: <4E70C8BB.7070408@fas.harvard.edu>
Date: Wed, 14 Sep 2011 11:31:07 -0400
From: "Benjamin M. Schwartz" <bmschwar@fas.harvard.edu>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13
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> <4E6FFD21.4090801@mozilla.com> <6A58A83F7040374B9FB4EEEDBD835512A404F2@LHREML503-MBX.china.huawei.com>
In-Reply-To: <6A58A83F7040374B9FB4EEEDBD835512A404F2@LHREML503-MBX.china.huawei.com>
X-Enigmail-Version: 1.1.2
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigEEEDD933A51255EF61979BC8"
Cc: "codec@ietf.org" <codec@ietf.org>, Jonathan Rosenberg <jonathan.rosenberg@skype.net>
Subject: Re: [codec] Discussion around ITU LS
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: bens@alum.mit.edu
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 15:29:07 -0000

On 09/14/2011 08:43 AM, Anisse Taleb wrote:
> What functionality does the Opus codec offer which makes it optimized (or more optimized than other codecs) for the use over the internet ?

The Opus codec offers coding
- optimized for both speech and non-speech sounds, in stereo and mono,
- coding 5 different bandwidths from Narrow to Full
- with latencies as low as 5ms
- and packet rates as low as 10 Hz,
- over the whole continuum of bitrates from 6kbps to 500kbps,
- with seamless variability in all of these parameters.
- It is robust to packet loss if packet loss is present,
 - but does not sacrifice efficiency when there is low packet loss.
- It can efficiently produce both CBR and VBR streams.
- It is designed to work well on a variety of computing hardware,
including systems with and without floating-point units.
- In each of these aspects its performance is either the best in the world
or not far behind the best, and the specification encourages compatible
improvement.

This functionality makes Opus more optimized than other codecs for use
over the internet because (correspondingly)
- all sorts of audio are transmitted over the internet
- endpoints may be gateways into limited-bandwidth systems
- ultra-low latency is sometimes desired (but not always)
- per-packet overhead on the internet can be significant
- the available bandwidth on the internet spans orders of magnitude
- the performance of a connection over the internet is highly dynamic, as
is its content
- The internet is not a reliable transport
 - but the degree of unreliability varies widely
- Some connections are limited by the available instantaneous bandwidth,
while others are limited by the aggregate cost of data transmission.
- All sorts of different devices are connected to the internet, including
both high-power desktop computers and low-power special-purpose devices.
- Devices connected to the internet often live for a long time and remain
important participants, so standards are typically used for decades once
deployed.

I am not aware of any other codec that is competitive with Opus on all
these fronts.

What makes Opus optimized for the internet is _not_ the non-normative
accessories like clock skew correction.  That kind of (useful)
functionality can go into libraries like opus-tools [1], which already
offers resampling and other similar non-normative additions such as
noise-shaping dither to improve the quality of 16-bit output.

--Ben

[1] http://git.xiph.org/?p=users/jm/opus-tools.git;a=summary