Re: [codec] possible issues to track

"Benjamin M. Schwartz" <bmschwar@fas.harvard.edu> Thu, 25 March 2010 22:53 UTC

Return-Path: <bmschwar@fas.harvard.edu>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BD2C3A6B57 for <codec@core3.amsl.com>; Thu, 25 Mar 2010 15:53:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.014
X-Spam-Level:
X-Spam-Status: No, score=-4.014 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1shuSBmTRnc for <codec@core3.amsl.com>; Thu, 25 Mar 2010 15:53:54 -0700 (PDT)
Received: from us17.unix.fas.harvard.edu (us17.unix.fas.harvard.edu [140.247.35.197]) by core3.amsl.com (Postfix) with ESMTP id CE8113A6B4C for <codec@ietf.org>; Thu, 25 Mar 2010 15:53:44 -0700 (PDT)
Received: from us17.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us17.unix.fas.harvard.edu (Postfix) with ESMTP id C883141E3D2; Thu, 25 Mar 2010 18:54:06 -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=eqSC7gAsGune50b Q9SFdoShAtQFvmM5AkcnQtKuC/ow=; b=Pvw34oHpRRNlBf3khWrxfsTbnoVC+pf ghbJzEDIfcnmkOweGVMY7Qr80eeExna1I5gE2283cKFkm0SnMDx1KK8yFXRwNfnk kJt0dkC8G7x1xy43hMqKOt5/TyXWryjN1XMLAsZbHvx5nG+Ve+NPCUwaYE/1vG8l 3mW/k7Lg3LvM=
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=quCXRkSYY rNmfGL6OWNCmv+vAvF16IGbzjAToUi1gA3N+1haK0PRHidcrcyoyNkWNM5ynvBpp Zy7BqPnsQylHJWJEVl2J+EukWkQv7k686pI2prKfJ8QKLZ0qQY71eTKA9/Js9Dk6 HP+P4VdVU9UsMHRbtirRumHI4GxWYImSso=
Received: from [172.23.141.91] (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 us17.unix.fas.harvard.edu (Postfix) with ESMTPSA id C3A1541E394; Thu, 25 Mar 2010 18:54:06 -0400 (EDT)
Message-ID: <4BABE98E.2000602@fas.harvard.edu>
Date: Thu, 25 Mar 2010 18:54:06 -0400
From: "Benjamin M. Schwartz" <bmschwar@fas.harvard.edu>
User-Agent: Thunderbird 2.0.0.23 (X11/20091019)
MIME-Version: 1.0
To: Michael Knappe <mknappe@juniper.net>
References: <C7D12D46.137D9%mknappe@juniper.net>
In-Reply-To: <C7D12D46.137D9%mknappe@juniper.net>
X-Enigmail-Version: 0.95.7
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enig50B956ECFA8376603B794AED"
Cc: Codec WG <codec@ietf.org>
Subject: Re: [codec] possible issues to track
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: bens@alum.mit.edu
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 25 Mar 2010 22:53:55 -0000

Michael Knappe wrote:
> Ben, how would you approach channel counts larger than 2? Joint coding
> between any two L-R pairs, with other channels (like the center channel)
> left singular?

I agree with Stephen Botzko that the mechanism should not be part of the
requirements.  However, we will need to agree on an interface, i.e. the
abstraction barriers.  I think:

1. The codec should provide an interface for coding a pair of closely
coupled channels with the presumption that they represent something like a
stereo pair.

2.  The format should provide an efficient way to pack multiple
independent synchronized codec channels into a single stream.

3. The format should provide a way to specify N named output channels as
linear combinations of the coded channels.

Advantages:
 - Stereo can be specially optimized.  There are mature techniques for
efficient coding of stereo, and plenty of test samples.  CELT can already
code joint stereo more efficiently than independent coding or a simple
mid-side split.
 - Surround sound can support all the various configurations (e.g. 5.1,
Ambisonics, custom speaker sets) without any major work within the spec.
 - The codec does not need to know anything about specific surround-sound
configurations, saving development time and effort.

Disadvantages:
 - This approach cannot achieve maximally efficient coding of
surround-sound, as can be achieved using techniques like those mentioned
in [1] and [2].

--Ben
[1] http://people.xiph.org/~xiphmont/surround/demo.html
[2] http://people.xiph.org/~xiphmont/surround/demo2.html