[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] The RTP payload format for multichannel codecs's signal ling problem
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.
I don't think that is a good solution due to that if one is only capable
of handling mono playback, then one might refuse to use this
functionality, although one would in fact be able to support it. Therefore
it seems rather important to be able to downgrade a channel setup from
maximum to a small set. For a more critical example one might not support
6+1 channel, however one is interested of using 2 channels.
Secondly, I don't know if the set of possible channels is obvious what
requires less capability between all possible configuration. Is a
quadraphonic setup less or more than a L+R, Center and Surround setup?
Having explicit declaration of all used channel modes avoid these problems.
Magnus,
That's true - however, explicitly declaring (in the SDP) which channel
modes are intended to be used leads to the question of what should a
receiver do if it later receives a stream with inband parameters that
violate the modes that were declared earlier. E.g., if it was declared
that only mono should be sent, then what should a receiver do if it later
ends up receiving stereo?
Note, of course, that this is only an issue for those payload formats where
channel parameters are carried inband. If you're going to allow - for such
payload formats - less than the complete channel functionality to be
declared in advance, then the payload format specification needs to say
*something* about what a receiver should do it it receives data with
different functionality. Even saying "the receivers actions are undefined"
in this case is better than saying nothing :-)
Ross.
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt