Subject: [AVT] Re: I-D ACTION:draft-lakaniemi-avt-rtp-evbr-00.txt

From: Colin Perkins <[email-masked]>
Date: Wed, 14 Nov 2007 10:30:40 +0000

On 13 Nov 2007, at 19:15, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: RTP payload format for the ITU-T Embedded Variable Bit- 
> Rate speech/audio codec
> 	Author(s)	: A. Lakaniemi
> 	Filename	: draft-lakaniemi-avt-rtp-evbr-00.txt
> 	Pages		: 28
> 	Date		: 2007-11-13
> 	
>    This document specifies the Real-Time Transport Protocol (RTP)
>    payload format for the Embedded Variable Bit-Rate (EV-VBR)
>    speech/audio codec. A media type registration for this RTP payload
>    format is also included.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-lakaniemi-avt-rtp- 
> evbr-00.txt

 From a quick initial read through, this seems generally very  
reasonable. Two areas seem problematic, however:

Section 3.5 discusses RTP header usage, stating "In case the EV-VBR  
session consists multiple RTP sessions, the RTP sessions are further  
separated by using different payload type (PT) values for each of the  
RTP streams" and "Each of the RTP sessions involved in the EV-VBR  
session SHALL use the same SSRC value". A better approach would be to  
allow the usual choice of SSRC, and use a common RTCP CNAME to  
associate the streams, reusing the mechanism needed for lip-sync  
between audio and video.

Section 4 defines a new RTCP APP packet. I generally find APP packets  
to be the wrong approach for anything other than application-specific  
information. Either define a new RTCP packet type (with its own RTCP  
PT value), or use an AVPF feedback packet type.

Cheers,
-- 
Colin Perkins
http://csperkins.org/

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

---

From: <[email-masked]>
Date: Fri, 16 Nov 2007 14:38:11 +0200

Colin,

Thanks for the feedback. See some comments in-line.

>associate the streams, reusing the mechanism needed for lip-sync  

The intention is not to specify anything too exotic regarding the PT
and/or SSRC usage. My thinking here was that since the audio data
carried by the set of RTP streams originates from the same source, it
seemed logical to use the same SSRC value for each of the RTP streams --
which would also tie the streams together with the data present in the
RTP header.

Anyway, I realize the proposed SSRC handling is not fully in line with
the RTP spec ("This identifier [SSRC] SHOULD be chosen randomly") and I
will change this part for the next revision if it is seen problematic.
Do you see some unfavourable consequences with the proposed approach?

A related issue is the timestamp handling accross RTP sessions. Since
all the layers of a certain EV-VBR frame come from a single audio source
and they will be combined back into a single frame in the receiving end
prior to decoding, using the same timestamp value for the layers of the
same encoded frame accross RTP sessions would simplify the data
handling. Is this seen problematic?

>PT value), or use an AVPF feedback packet type.

This is obviously one of the open issues in the draft. RTCP APP packet
seemed like an easy (and therefore tempting) solution, although I had
some doubts about it already before this discussion. I will try to work
on pros and cons of more appropriate solutions, including (but not
necessarily limited to)
1. New RTCP packet type
2. (New) AVPF FB packet type
3. Usage of an existing mechanism, such as TIMBR

>Cheers,

Regards,
Ari

---

From: Colin Perkins <[email-masked]>
Date: Fri, 16 Nov 2007 13:24:29 +0000

Ari,

On 16 Nov 2007, at 12:38, <[email-masked]> wrote:
> seemed logical to use the same SSRC value for each of the RTP  
> streams -- which would also tie the streams together with the data  
> present in the RTP header.
>

Yes - one can no longer use standard RTP receiver code, using the  
RTCP CNAME to group related streams (specified in RFC 3550), to  
process this payload format. Instead, you have a special case, which  
recognises this payload, and matches based on SSRC.

> all the layers of a certain EV-VBR frame come from a single audio  
> source and they will be combined back into a single frame in the  
> receiving end prior to decoding, using the same timestamp value for  
> the layers of the same encoded frame accross RTP sessions would  
> simplify the data handling. Is this seen problematic?

Again, it introduces a special case into the receiver code. Rather  
than use the standard mechanism to synchronise streams, one has to  
recognise this payload format, and do something different.

We have standard mechanisms to time synchronise and group flows  
across multiple RTP sessions. This payload format should use them,  
rather than trying to reinvent the wheel in an incompatible way.

Regards,
Colin

---

From: <[email-masked]>
Date: Mon, 19 Nov 2007 08:40:12 +0200

Colin,

OK, I can see the problem and I agree that there is no use breaking
backwards compatibility. I will change the draft text for the next
revision accordingly.

Regards,
Ari

>-----Original Message-----
>From: ext Colin Perkins [mailto:[email-masked]] 
>Sent: 16 November, 2007 15:24
>To: Lakaniemi Ari (Nokia-NRC/Helsinki)
>Cc: [email-masked]
>Subject: Re: [AVT] RE: I-D ACTION:draft-lakaniemi-avt-rtp-evbr-00.txt 
>
>Ari,
>

---

From: "SOLLAUD Aurelien RD-TECH-LAN" <[email-masked]>
Date: Tue, 27 Nov 2007 17:37:27 +0100

> >information. Either define a new RTCP packet type (with its 
> own RTCP PT 
> >value), or use an AVPF feedback packet type.
> >
> 
> This is obviously one of the open issues in the draft. RTCP 
> APP packet seemed like an easy (and therefore tempting) 
> solution, although I had some doubts about it already before 
> this discussion. I will try to work on pros and cons of more 
> appropriate solutions, including (but not necessarily limited 
> to) 1. New RTCP packet type 2. (New) AVPF FB packet type 3. 
> Usage of an existing mechanism, such as TIMBR
> 

Hi

I think we should define a generic, codec-independant way to transport this type of codec bit-rate control command. Actually, modern audio codecs developped in the ITU-T or elsewhere tend to be scalable and layered. 
It doesn't seem appropriate that every payload format define a way to do the same thing.
As I understood it during the elaboration of the CCM draft, it is not the goal of the current CCM TMMBR to perform the thing we are talking about. Anyway, if it is done as a new kind of CCM, I suggest to open this kind of command to any profile, not only AVPF.

Regards,
Aurélien

---

From: <[email-masked]>
Date: Thu, 29 Nov 2007 14:50:31 +0200

Hi Aurélien,

I agree that it does not make too much sense to replicate exactly the same bit-rate control mechansims for multiple payloads.

However, at least for EV-VBR the proposed mechanism is not only for bit-rate control but the intention is to enable also expressing receiver's (changed) preference regarding the configuration of the (upcoming) bandwidth extension and stereo options. I assume that future (layered) codecs with more advanced features/options would need to be able to express their preferences among even larger set of options when changing the bit-rate/configuration. On the other hand, I expect different codecs to offer different sets of options (and different rules on combining the options). Thus, it seems likely that (also future) codecs (will) have different requirements for a such bit-rate/configuration control messages.

Regards,
Ari

>From: ext SOLLAUD Aurelien RD-TECH-LAN 
>[mailto:[email-masked]] 
>Sent: 27 November, 2007 18:37
>To: Lakaniemi Ari (Nokia-NRC/Helsinki); [email-masked]
>Cc: [email-masked]
>Subject: RE: [AVT] RE: I-D ACTION:draft-lakaniemi-avt-rtp-evbr-00.txt 
>
>I think we should define a generic, codec-independant way to 
>transport this type of codec bit-rate control command. 
>Actually, modern audio codecs developped in the ITU-T or 
>elsewhere tend to be scalable and layered. 
>As I understood it during the elaboration of the CCM draft, it 
>is not the goal of the current CCM TMMBR to perform the thing 
>we are talking about. Anyway, if it is done as a new kind of 
>CCM, I suggest to open this kind of command to any profile, 
>not only AVPF.
>
>Regards,
>Aurélien
>

---

From: "SOLLAUD Aurelien RD-TECH-LAN" <[email-masked]>
Date: Thu, 29 Nov 2007 15:45:09 +0100

Hi

I agree we don't know all future needs, but the requirement to control the bit-rate, the wideband/superwideband mode and the mono/stereo mode, are well identified for codecs currently developed (At least in the ITU-T G.xxx series).

In addition the number of remaining PT for RTCP packets is not infinite, so it is worth working on a common, open, and extensible enveloppe for these codec commands.

I don't have a precise solution in mind, it is just to bring the issue to the WG and get feedback.

Aurélien

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] 
> Envoyé : jeudi 29 novembre 2007 13:51
> À : SOLLAUD Aurelien RD-TECH-LAN; [email-masked]
> Cc : [email-masked]
> Objet : RE: [AVT] RE: I-D ACTION:draft-lakaniemi-avt-rtp-evbr-00.txt 
> 
> Hi Aurélien,
> 
> I agree that it does not make too much sense to replicate 
> exactly the same bit-rate control mechansims for multiple payloads.
> 
> However, at least for EV-VBR the proposed mechanism is not 
> only for bit-rate control but the intention is to enable also 
> expressing receiver's (changed) preference regarding the 
> configuration of the (upcoming) bandwidth extension and 
> stereo options. I assume that future (layered) codecs with 
> more advanced features/options would need to be able to 
> express their preferences among even larger set of options 
> when changing the bit-rate/configuration. On the other hand, 
> I expect different codecs to offer different sets of options 
> (and different rules on combining the options). Thus, it 
> seems likely that (also future) codecs (will) have different 
> requirements for a such bit-rate/configuration control messages.
> 
> Regards,
> Ari
> 
> >> This is obviously one of the open issues in the draft. RTCP APP 
> >> packet seemed like an easy (and therefore tempting) solution, 
> >> although I had some doubts about it already before this 
> discussion. I 
> >> will try to work on pros and cons of more appropriate solutions, 
> >> including (but not necessarily limited
> transport 
> >this type of codec bit-rate control command.
> >It doesn't seem appropriate that every payload format define 
> a way to 
> >do the same thing.
> >As I understood it during the elaboration of the CCM draft, 
> it is not 
> >the goal of the current CCM TMMBR to perform the thing we 
> are talking 
> >about. Anyway, if it is done as a new kind of CCM, I suggest to open 
> >this kind of command to any profile, not only AVPF.
> >
> >Regards,
> >Aurélien
> >
>