[theora-dev] Keyframe seeking in Ogg and spec
xiphmont at xiph.org
Mon Sep 16 14:11:53 PDT 2002
On Mon, Sep 16, 2002 at 05:23:08PM -0300, Tabuleiro wrote:
> > That's true. On the other hand the timing information is handled by the
> > codec layer and not on the Ogg layer. So it is sufficient if the codec
> > can reconstruct the time information. Anyway it would be more convenient
> > to have the same time base.
> > In Ogg DSF I convert samples/frames to a reference time to get them in
> > sync. Therefore the number of frames/sec is stored in the header as the
> > number of samples in "vi.rate"
> Great. So what you are saying is that once you know the frame rate for the
> default video you just pass it in the header, and each granulepos indicates
> a frame number. Then the codec reconstructs the absolute time by multiplying
> the frame number by the specified rate.
It's a little more complicated than that, but you have the right basic
> It should work fine, unless you want
> to add variable times for each video frame, which we probably don't ( I
> don't, at least :) )
One can define a different mapping. This is all by codec, each codec
does what it wants, within restrictions of practicality and retraints
specced by Ogg.
> And what you do when you want to invoke a seek operation? I assume you seek
> on the audio, and starts getting video data (discarded until it reaches a
> keyframe.) True?
You could do that. Or you could seek both audio and video, take the
earliest, and do partial decode up to the exact requested A/V frame
number. The framework and the app will have this freedom.
> BTW, I looked at the VP3 code and the codec can tell if a frame is a
> keyframe or not without any extra header information. Is it the case to
> simply mark each sample incrementally (option 1 as suggested previously by
> Monty) and let the higher layers take care of seeking until they find a
> keyframe (or cache their position as they pass?)
We could do that; it's practical. I prefer to embed state in the
granulepos to simplify the seeking complexity slightly. It's a
tradeoff, and you're right to point out that scheme 1 would work fine.
> Of course, thanks! This addresses the problem for file based access (or fast
> seeking media), my main concerns. So it looks it can be done with a simple
> header page indicating frame rate and video dimensions, assuming we do not
> use variable frame rates.
Within VP3 in any case. A non-fixed-rate mechanism has the freedom to
implement a scheme appropriate to how it functions (and a timestamp
would work just fine; it might have to work harder on seeking, but not
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'theora-dev-request at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the Theora-dev