[theora] Indexing Ogg files for faster seeking

Conrad Parker conrad at metadecks.org
Wed Sep 23 16:18:48 PDT 2009

2009/9/24 Chris Pearce <chris at pearce.org.nz>:
> On 24/09/09 05:49, Conrad Parker wrote:
>> OTOH, one thing I'm worried about is the cost of adding the index to
>> the beginning of a long file, which then requires rewriting the entire
>> file.
> If you can't bear that cost for your server side seeking solution, you
> could store the index in a separate file, and use that to speed up your
> client side seeking. And/or you could splice the index into the
> bitstream when you serve it.

right, I was just having that discussion with mdale ... splicing it in could
ensure the client always sees a file including an index.

> The index really needs to be in the Ogg header packets at the start of
> the media for it to be useful for web video.
> We discussed on #theora about indexing at encode time. You can reserve
> space for n indexed keyframes in the headers packets, and once you're
> done encoding you can choose n keyframes to put into the index. If you
> know the duration of the media in advance, you can guess how many
> keyframes you'll have and allocate space accordingly. My indexer
> currently only indexes keyframes which are more than 500ms after the
> previously indexed keyframe anyway.

great! not requiring an extra (second or third) encode pass is the main thing
I was asking about, so if the index can be added at ingest then it's no problem.

>> Could you transfer your spec to the Xiph wiki? we also need to discuss
>> implementation for Dirac etc.
> Any content type for which seeking to and playing from a target time
> requires you to decode forwards from a pre-determinable Ogg page can be
> indexed.


wiki? :)


More information about the theora mailing list