Re: [AVT] The RTP payload format for multichannel codecs's signalling problem

Ross Finlayson <finlayson@live.com> Thu, 05 February 2004 22:08 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15602 for <avt-archive@odin.ietf.org>; Thu, 5 Feb 2004 17:08:38 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorfO-0006EV-Qm for avt-archive@odin.ietf.org; Thu, 05 Feb 2004 17:08:11 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15M8AIf023908 for avt-archive@odin.ietf.org; Thu, 5 Feb 2004 17:08:10 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AorfF-00068i-Em; Thu, 05 Feb 2004 17:08:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoreh-000634-5m for avt@optimus.ietf.org; Thu, 05 Feb 2004 17:07:27 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15507 for <avt@ietf.org>; Thu, 5 Feb 2004 17:07:24 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aoree-0001XW-00 for avt@ietf.org; Thu, 05 Feb 2004 17:07:25 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aordj-0001VN-00 for avt@ietf.org; Thu, 05 Feb 2004 17:06:27 -0500
Received: from ns.live.com ([66.80.62.34]) by ietf-mx with esmtp (Exim 4.12) id 1AordO-0001SV-00 for avt@ietf.org; Thu, 05 Feb 2004 17:06:06 -0500
Received: from ns.live.com (localhost.live.com [127.0.0.1]) by ns.live.com (8.12.10/8.12.10) with ESMTP id i15M5tXe050523 for <avt@ietf.org>; Thu, 5 Feb 2004 14:05:59 -0800 (PST) (envelope-from rsf@ns.live.com)
Received: (from rsf@localhost) by ns.live.com (8.12.10/8.12.9/Submit) id i15M5siN050510; Thu, 5 Feb 2004 14:05:54 -0800 (PST) (envelope-from rsf)
Message-Id: <6.0.1.1.1.20040205135742.03461eb0@localhost>
X-Sender: rsf@localhost (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1
Date: Thu, 05 Feb 2004 14:04:37 -0800
To: avt@ietf.org
From: Ross Finlayson <finlayson@live.com>
Subject: Re: [AVT] The RTP payload format for multichannel codecs's signalling problem
In-Reply-To: <40223D4C.4020209@ericsson.com>
References: <40223D4C.4020209@ericsson.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>

It seems to me that for any codec that carries channel etc. parameters 
inband - and allows these parameters to change 'on the fly' - there is an 
implicit assumption that each receiver should be able to handle all 
possible settings of these inband parameters.  So, given this, your first 
proposed solution seems to make the most sense: Declare the AMR-WB+ RTP 
payload type to be for stereo, even though all frames within such a stream 
might actually turn out to be mono.

	Ross.


_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt