Re: [AVT] RE: <draft-ietf-avt-rtp-vmr-wb-03.txt>: sampling rate

Colin Perkins <csp@csperkins.org> writes:
>>         Not that such things exist currently, but playing devil's
>> advocate, one could create a codec that takes a variable-sampling-rate
>> input depending on current conditions.  (Similar to video codecs that
>> vary the frame rate, resolution, and/or bitrate within a stream.)
>
>Sure, one could. I don't think it would be a good idea though: the
>convention that the sampling rate equals the timestamp rate is very helpful
>when building multi-format systems.

        Actually, such a codec could be VERY useful.  One of the big
problems with audio codecs nowadays is that they're situation-specific.
A "good" codec for speech is not a good codec for music, and a good music
codec may not do as well at covering packet loss and uses a lot more
bandwidth when the stream has plain speech.

        You could define a codec that generates (effectively) two or more
internal encodings depending on the audio data at that point in time
(perhaps switching per-packet or even more often), and could switch the
input sample rate to support that on a frame-by-frame basis.  The likely
logical solution for that would be to have the decoder output the highest
frequency that could be needed, and to use that same rate for all the RTP
timestamps, regardless if the encoder was currently doing the (say) 32KHz
sampling or 16KHz or 8KHz sampling.

        Such a codec might be a nice thing - it'd use extra bandwidth
only when needed.  Music-on-hold would sound good (though it might handle
packet loss less smoothly), and speech would use less bits and might be
more robust to packet loss (such as with iLBC).

        By insisting on the point that "timestamp rate == sample rate",
you close off a series of possibilities such as this, or make them much
more painful (like requiring dual synchronized streams at different
rates), or frequent (expensive) renegotiations of RTP stream parameters.

>>         While I don't see a _need_ for a multi-rate audio codec to use
>> a fixed timestamp rate, I also don't see a _need_ for the timestamp rate
>> to be the sample rate for audio, other than tradition.  Perhaps I'm
>> missing something.
>
>It's a very useful convention, not a requirement. I don't see anything in
>this codec that justifies breaking that convention.

        And I guess that's the crux - you see it as a convention to be
followed unless there's a VERY strong argument.  I and others seem to feel
that it's at most a minor convention which gives minimal benefit, and given
a reasonable argument that there's some advantage breaking the convention
that we should do so.

-- 
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team
rjesup@wgate.com


_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt