[theora] Indexing Ogg files for faster seeking

[Conrad Parker]

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.

great.

wiki? :)

Conrad.