[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] RE: I-D ACTION:draft-lakaniemi-avt-rtp-evbr-00.txt
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 : ari.lakaniemi at nokia.com [mailto:ari.lakaniemi at nokia.com]
> Envoyé : jeudi 29 novembre 2007 13:51
> À : SOLLAUD Aurelien RD-TECH-LAN; csp at csperkins.org
> Cc : avt at ietf.org
> 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
>
> >-----Original Message-----
> >From: ext SOLLAUD Aurelien RD-TECH-LAN
> >[mailto:aurelien.sollaud at orange-ftgroup.com]
> >Sent: 27 November, 2007 18:37
> >To: Lakaniemi Ari (Nokia-NRC/Helsinki); csp at csperkins.org
> >Cc: avt at ietf.org
> >Subject: RE: [AVT] RE: I-D ACTION:draft-lakaniemi-avt-rtp-evbr-00.txt
> >
> >> >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.
> >> >
> >>
> >> 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
> >
>
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt