[theora-dev] Keyframe seeking in Ogg and spec

[Monty]

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
idea, yes.

> 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
too much).

Monty
--- >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.