Re: Time in video file

Am Dienstag, den 15.03.2011, 16:07 -0400 schrieb Gregory Maxwell:
> On Tue, Mar 15, 2011 at 3:54 PM, Richard Watts <[email protected]> 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.

Can you please take look at this ticket:
https://trac.xiph.org/ticket/1730

This is exactly about this issue.
-- 
Regards,
        Alexey