[theora-dev] Time in video file
rrw at kynesim.co.uk
Tue Mar 15 12:01:49 PDT 2011
On 15/03/11 18:45, Ralph Giles wrote:
> On 15 March 2011 10:54, Richard Watts<rrw at kynesim.co.uk> wrote:
>> What generally happens in video codec land is that the codec headers contain a
>> nominal frame rate, but you will only use that in practice to set your expectations
>> of the approximate rate of arrival of frames.
>> Pacing is generally done by a more accurate clock delivered around the side
>> (e.g. via Ogg's granulepos - which is a completely abstract value that can mean
>> anything you like, but in practice tends to be a timestamp in ms).
> While what you describe is indeed a common way to support variable
> framerate encodings, what Ben said is correct. Theora video in the Ogg
> container is strictly fixed framerate and the encoder must take care
> of this.
There's a difference between fixed frame rate and fixed timing; I'll
accept that I'm just wrong in using this to implement VFR - though
as I understand it, Bjoern's problem is dropped frames, so my technique
would be legitimate in his case, albeit somewhat hard for the decoder to
But I can't see any sensible way to maintain AVsync over long periods
without putting my timestamps somewhere - if I don't do this, I can't
recover the source clock and my A and my V will eventually drift away
from each other.
Does the scheme given in A.2.2 / A.2.3 somehow ensure this - I'm not
sure I see how it can?
> I believe many players do support per-frame presentation timestamps on
> theora video in the MKV container. While that also goes against the
> wording of the theora bitstream specification, unlike the case with
> Ogg there's no technical reason it can't be done.
Eh? The Theora standard has a section on encapsulating Theora in Ogg
which, as you say, explicitly reserves the granulepos field and uses
it for a kind of 'fast seek'. It says nothing about encapsulating Theora
in MKV .. (does it?)
More information about the theora-dev