Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-amrwbplus-04.txt

From: Colin Perkins <[email-masked]>
Date: Thu, 13 Jan 2005 18:53:24 +0000

Hi,

One comment: the draft defines the "channels" parameter as the maximum  
number of channels allowed to be used for a given payload type (see  
sections 4.1 and 7.1). This is different from other audio formats,  
where the parameter defines the actual number of audio channels (see  
section 2 of RFC 3555). Is there a strong reason for this discrepancy?  
If not, it would be appropriate to align the meaning of the parameter  
with existing practice.

Colin

On 20 Dec 2004, at 20:50, Magnus Westerlund wrote:

> Hi,
>
> This update is basically editorial. It contains one real technical  
> change, namely the creation of a normative table for number of RTP TS  
> ticks per frame depending on used ISF.
>
> We authors have the intention to go to WG last call after the  
> christmas holidays. So please review and send us feedback so that we  
> can get a great specification.
>
> Cheers
>
> Magnus
>
> [email-masked] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts  
>> directories.
>> This draft is a work item of the Audio/Video Transport Working Group  
>> of the IETF.
>> 	Title		: Real-Time Transport Protocol (RTP) Payload Format 			  for  
>> Extended AMR Wideband (AMR-WB+) Audio Codec
>> 	Author(s)	: J. Sjoberg, et al.
>> 	Filename	: draft-ietf-avt-rtp-amrwbplus-04.txt
>> 	Pages		: 35
>> 	Date		: 2004-12-17
>> 	
>> This document specifies a real-time transport protocol (RTP) payload
>>     format to be used for Extended AMR Wideband (AMR-WB+) encoded  
>> audio
>>     signals.  The AMR-WB+ codec is an audio extension of the AMR-WB
>>     codec providing additional frame types designed to give higher
>>     quality of music and speech than the original frame types.  A  
>> media
>>     type registration is included for AMR-WB+.
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-amrwbplus 
>> -04.txt
>
>
> -- 
>
> Magnus Westerlund
>
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
>

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Jan 2005 10:06:53 +0100

Hi Colin,

We authors has discussed this and think it is motivated to change the 
definition for AMR-WB+. This is due to the built in support of stereo 
encoding in the codec. Support is required for all decoders to handle 
both mono and stereo frame types, including downmixing to mono. The 
signalling of the usage of stereo is integrated into the frame type. The 
codec also support switching between mono and stereo in mid stream.

Due to these properties having the normal "channels" definition would 
require a AMR-WB+ peer to from the beginning either exclude the use of 
mono or stereo, or define two payload types. It would also require the 
complexity of restricting certain frame-types to one payload type, and 
having some other only go on another. As noted in the draft, stereo 
down-mixing is required to be supported by the decoder and therefore the 
signalling of channels is only an optimization to avoid throwing bits at 
stereo encoding if the receiver anyway is going to down mix it.

Thus we think the in the AMR-WB+ definition of channels has the 
following properties:
- Avoid creating an artificial separation of stereo and mono that 
doesn't exist in AMR-WB+. And therefore avoid usage of two PTs.
- Provides the correct semantics for the codec in negotiation due to its 
mandatory down-mixing capabilities.

If you think it is better to avoid tainting the "channels" definition we 
can rename the parameter something else, and use it on the fmtp line in 
SDP. The codec would then not at all use the "channels" definition and 
not add any channels information after the clock rate in the a=rtpmap 
attribute.

Comments?

Cheers

Magnus

-- 

Magnus Westerlund

---

From: Colin Perkins <[email-masked]>
Date: Sat, 15 Jan 2005 18:11:48 +0000

Magnus,

On 14 Jan 2005, at 09:06, Magnus Westerlund wrote:
> signalling of the usage of stereo is integrated into the frame type. 
> The codec also support switching between mono and stereo in mid 
> stream.
>
> down-mixing is required to be supported by the decoder and therefore 
> the signalling of channels is only an optimization to avoid throwing 
> bits at stereo encoding if the receiver anyway is going to down mix 
> it.
>
> - Provides the correct semantics for the codec in negotiation due to 
> its mandatory down-mixing capabilities.

Okay, but the draft needs note that the channels parameter is 
interpreted differently for AMR-WB+ compared to other codecs, and to 
explain why this works.

Colin

---

From: Stephen Casner <[email-masked]>
Date: Sat, 15 Jan 2005 20:08:25 -0800 (PST)

> If not, it would be appropriate to align the meaning of the parameter

I think the purpose of the channels parameter, at least in early
payload type definitions, was to let the receiver know how to
demultiplex interleaved samples or frames.  Since the encoding of
stereo in AMR-WB+ is entirely within the frame, and is indicated
there, then it seems the channels parameter does not really apply.

                                                        -- Steve

---

From: Dave Singer <[email-masked]>
Date: Mon, 17 Jan 2005 10:00:21 +0800

>there, then it seems the channels parameter does not really apply.

It also really helps to know how to setup the audio output device, and so on.

-- 
David Singer
Apple Computer/QuickTime