[theora-dev] Time in video file

Gregory Maxwell gmaxwell at gmail.com
Tue Mar 15 12:36:53 PDT 2011


On Tue, Mar 15, 2011 at 3:10 PM, Richard Watts <rrw at kynesim.co.uk> wrote:
> This, however, is just broken as a design. However, I doubt that anyone
> here will be prepared to listen to reason (or indeed do anything other
> than simply rail at me), so I shall shut up and leave you to your
> 1000fps frame-dupping. Good luck with that.

It's not a "broken design", it's a fixed rate design that can be
shoehorned into doing VFR by running it at a higher rate.

Because ogg has very low overhead for small (i.e. zero byte) packets
it's not an enormous deal overhead wise.  For 1000fps it adds about
8kbit/sec. For audio that would suck, but for video the overhead is
inconsequential.

It's not ideal in the VFR  case, but lets not pretend that anything is
ideal across all use cases.  Consider instead a format that attaches a
1ms resolution counter to every frame (like MKV): it's still not able
to exactly represent the times of frames at many common frame rates
(like the NTSC derived ones), and it frees encoders to do moronic
things like spit out a burst of frames 1ms apart, completely
exhausting computational resources, with no way of negotiating or a
decoder knowing in advance that this will happen.   I'm not saying
this to knock on MKV— the ogg encap for theora has the same problem
(but only when useed with a high rate to do VFR),  just pointing out
that engineering is usually an exercise in tradeoffs and that 'better'
almost always depends on a subjective prioritization of criteria.

On Tue, Mar 15, 2011 at 3:14 PM, Richard Watts <rrw at kynesim.co.uk> wrote:
[snip]
>  (also, note that Bjoern is not (necessarily) talking about VFR, though
> this is somewhat hard to discern since the Theora spec seems not to
> take into account the difference between how fast your clock is running
> and how many fps you are attempting to sample at)

It forces you to upconvert to a single fixed rate.  I think that is
actually much simpler than requiring the source and receiver to do the
same non-obvious control of drift. There is a constant fixed rate
clock. Each side simply makes a best effort to stay in synch with it.


More information about the theora-dev mailing list