[theora-dev] Time in video file

[Gregory Maxwell]

On Tue, Mar 15, 2011 at 3:54 PM, Richard Watts <rrw at kynesim.co.uk> wrote:
>  But you're still using (many!) more bits than you need to represent
> what is, in essence, a timer. Worse, you have now lost any information
> you ever had as to the actual underlying frame rate. Even worse, the
> decoder now needs to make some sort of decision as to which of these
> frames it should actually output (unless you really do have VSYNC =
> 1kHz in which case I want your monitor).

And yet a 32bit 1ms timer (which would probably wrap far too fast)
attached to every vorbis frame, e.g. would impose 5kbit/sec. overhead
(or twice that for 64bit counters) in the worst case.  Ogg avoids this
by not attaching the granpos to every packet. But this means the
special care must be taken in order to support variable rate things
cleanly.

Of course, this can be improved by adding more special cases.

What cortado does for drop frames (zero byte frames) is that it just
doesn't paint them. Why would it? They're drops. They don't change the
output, they don't change the buffer states.

Of course, if the encoder outputs too many real frames and it falls
behind, then it has to drop more. But thats just the normal mechanism
for falling behind.

(Cortado does paint every two seconds or so even during drops, because
the graphics api in use doesn't deal with damage completely, so it
needs to periodically repaint in order to recover the screen)

[sniping a bunch of stuff that I find completely agreeable]

>  CBR gets you out of more of it, but as you observe, there is very
> little to stop a VFR encoder emitting ghastly numbers of frames
> (of course, that emission of ghastly numbers of frames is precisely
> what you are suggesting for timekeeping, so I'd think it ungentlemanly
> of you to then complain about it!).

There is a difference between a zero byte placeholder and a frame that
takes work to decode!

Yes, it's an extra condition, but so is the logic required to decode
frame durations elsewhere.