Re: [codec] possible issues to track

"Christian Hoene" <hoene@uni-tuebingen.de> Thu, 25 March 2010 23:08 UTC

Return-Path: <hoene@uni-tuebingen.de>
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 65E523A683C for <codec@core3.amsl.com>; Thu, 25 Mar 2010 16:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.953
X-Spam-Level:
X-Spam-Status: No, score=-2.953 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 UXlgphfSX+7m for <codec@core3.amsl.com>; Thu, 25 Mar 2010 16:08:52 -0700 (PDT)
Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 9865A3A6C98 for <codec@ietf.org>; Thu, 25 Mar 2010 16:08:46 -0700 (PDT)
Received: from hoeneT60 (dhcp-wireless-open-abg-27-226.meeting.ietf.org [130.129.27.226]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o2PN8v1p027401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 26 Mar 2010 00:09:05 +0100
From: Christian Hoene <hoene@uni-tuebingen.de>
To: bens@alum.mit.edu, codec@ietf.org
References: <C7D12D46.137D9%mknappe@juniper.net> <4BABE98E.2000602@fas.harvard.edu>
In-Reply-To: <4BABE98E.2000602@fas.harvard.edu>
Date: Thu, 25 Mar 2010 16:08:56 -0700
Message-ID: <003801cacc70$2a16c820$7e445860$@de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcrMbiHbdQCh6piiRq+xhN638golfgAAaddw
Content-Language: de
X-AntiVirus-Spam-Check: failed (checked by Avira MailGate: version: 3.0.0-4; spam filter version: unknown; host: mx05)
X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.196; VDF: 7.10.5.225; host: mx05); id=23318-6liL4Q
Subject: Re: [codec] possible issues to track
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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 23:08:53 -0000

>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.

Later would make the mixing in a conference server also quite easy. Just pack the encoded active streams and set the linear equation
according to the placement of the participants. Very efficient!

Christian