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