[xiph-rtp] Chaining

[Ralph Giles]

On Tue, Aug 30, 2005 at 11:01:36AM -0700, David Barrett wrote:

> All this talk on sample rates is scaring me.  I didn't realize it was a 
> requirement to be *absolutely* regular with framerate.  I thought we 
> were talking about *average* framerates.  I assumed anything stating 
> framerate is purely advisory, and the decoder should be prepared to 
> handle frames that come in on any sample frequency (ie, not puke if it 
> gets a frame before or after what it's expecting).

Well, that works, but. All the Xiph codecs are notionally fixed frame
rate, and if your actual source material isn't, the encoder is expected
to resample it so that it is.

That said, the decoders always produce N samples for N samples of
input, so you can ignore the native framerate, or use an inflated
rate and implicitly drop a lot of samples to emulate variable
frame rates if you have an out-of-bad channel like the RTP header
timestamps. With Vorbis and Speex, changing the local sample rate
will cause some quality loss because the encoder's model assumes
a fixed rate. Current theora encoders don't really do anything
relative to absolute time, so there shouldn't be an effect
(so far).

What Aaron is talking about with the 90000Hz thing is (I believe)
the choice of timebase for the timestamps in the RTP header. This
timebase (what you multiply the 32 bit timestamp by to get wall
clock time) is defined by the payload spec, i.e. what we're
discussing.

The recommendation for audio is that this be the same as, or
some multiple of the actual sample rate. e.g. 44100 or 48000 Hz.
For video, RFC 1889 says that just using the native video
frame rate doesn't provide enough resolution for measuring
packet arrival jitter (presumedly in the same timebase). My
guess is that 90000 HZ provides plenty of such resolution,
as well as dividing evenly by standard frame rates: 24, 25,
29.97, 30, 50, 60. RFC 1890 doesn't mention this explicitly
but seems to assume it will be the time base for video codecs.

That's my understanding of what we're talking about anyway.

Variable framerates are really only made possible with software's
flexibility and only motivated by crappy clocks in consumer capture
devices. Professional A/V hardware tends to assume a fixed framerate,
and based on that so do a lot of digital standards.

 -r