Re: Time in video file

Hi

Thanks to all for answering my question. I guess I'll go with the
approach of adding duplicate frames to add up to the missing frames.
Does the Theora encoder have a way of knowing that I'm inserting a
duplicate frame? So it doesn't use unnecessary CPU cycles?

Or maybe this answers my question?
https://trac.xiph.org/ticket/1730

-- Bjoern

On Tue, Mar 15, 2011 at 8:36 PM, Gregory Maxwell <[email protected]> wrote:
> On Tue, Mar 15, 2011 at 3:10 PM, Richard Watts <[email protected]> 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 <[email protected]> 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.
> _______________________________________________
> theora-dev mailing list
> [email protected]
> http://lists.xiph.org/mailman/listinfo/theora-dev
>