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

On 12 Sep 2004, at 09:11, Randell Jesup wrote:
> Colin Perkins <csp@csperkins.org> writes:
>>> The fact that VMR-WB is capable of processing narrowband (8 kHz) or
>>> wideband (16 kHz) media does not have anything to do with its 
>>> internal
>>> sampling frequency.
>>
>> Exactly. This is why the RTP timestamp rate should be either 8kHz or 
>> 16kHz,
>> depending on the input source.
>
>         Well, this (having the RTP timestamp rate be the sampling
> frequency) isn't the case for a number of non-audio RTP streams (such 
> as
> video streams, which typically use 90000 regardless of pixel, line, or
> frame rate), so there's precedent for a "fixed" timestamp rate.

Video has different timestamp rules, so that doesn't apply. MPEG audio 
uses a fixed rate, for compatibility with other MPEG content. It's 
problematic when building a multi-format media tool, since unlike other 
codecs it doesn't use the sampling rate.

>         There's no reason all the audio codecs couldn't have used
> any value (even 90000); it's convention that it be the sampling rate.
> It avoids a multiply/divide to convert a timestamp into a sample-time,
> and there's no error involved (which there would be if sample and
> timestamps didn't convert cleanly), but that's about it.
>
>         Having timestamp rate be sampling rate can allow implicit
> determination of the packetization-interval, but that should be 
> provided
> separately anyways.  This implicit packetization-interval only adds
> something if the packetization-interval is non-static within a session 
> (and
> most if not all audio codecs disallow that excluding 
> silence-supression).
>
>
>         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.

>         The important thing about timestamps is that they provide
> *enough* resolution to accurately know when to play the date contained
> within.  For example, for professional audio work, one might have a 
> real
> need for an N-times multiple of the sample rate.  The reason is that
> sample rate defines the bandwidth of the signal, but the timing of the
> signal required might be tighter, such as if it needs to be mixed with
> other streams (especially other higher-bandwidth streams).  Back in the
> Amiga video days we had a ~1400x480i video mode, even though NTSC
> monitors were lucky to show anything approaching 640.  The reason was
> that fine control of where a signal started (such as the curve of a
> 'C') produced better, smoother diagonals and curves.  (anti-aliasing of
> a sort, if you like.)
>
>
>         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.

Colin

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