[xiph-rtp] Chaining

[David Barrett]

On Tue, 30 Aug 2005 12:44 pm, Ralph Giles wrote:
>
> 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.

Ah, ok.

> 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.

Ohh, ok.  I'm sorry, I was confused.  So you'd need to decide this even 
if you had a totally irregular framerate; it's an orthogonal issue.  
I'll read up on the spec to understand this better.

> 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.

Thanks, I hadn't considered the AV hardware issue.

Another motivation, however, is downsampling to a non-factor framerate.  
For example, assume a 30fps camera -- you can only "regularly" broadcast 
at 1, 3, 5, 15, and 30 fps.  But 15-30fps is a big range.  Assuming my 
target is 22fps (such as picked by an adaptive rate adjuster based on 
current conditons).  15 is unnecessarily slow, and 30 is too fast -- 
both by significant margins.  Plus, switching from 15 to 30 instantly 
(or worse, toggling back and forth if you're right on the border) is 
jarring.  However, I can get an average framerate of 22fps through 
irregular frame dropping.  It won't be as visually pleasing as a 
"regular" framerate, but for some video (especially live video from 
crappy webcams) it might be acceptable.

-david