[theora] Indexing Ogg files for faster seeking

[Silvia Pfeiffer]

On Wed, Oct 14, 2009 at 7:46 AM, Chris Pearce <chris at pearce.org.nz> wrote:
>
>> I personally think the multi-index is better
>
> I think we now all agree on this at least. :)

That's a good start. :-)

>> Also, I still believe it would make sense to include the Index packets
>> into Ogg Skeleton (as you may have gathered from the emails I just
>> sent on the other thread).
>
> I accept that adding the index to the skeleton would be a carrot to
> encourage players to use the skeleton, just so they can get the index.
> It's not clear to me how a player is otherwise advantaged by reading the
> skeleton track, hence my reluctance to include the index in the skeleton.

I have seen the need in professional video applications where the
beginning of the file is mapped to a time that is not 0. For example,
in the olden days, all film would start at smpte time 1:00:00.000
rather than 0. If there are annotations to such files etc, one will
want to retain such a basetime mapping. This is why Skeleton allows a
non-zero basetime. This is not something you will find in the tracks
themselves.


>> Ogg Skeleton has been built to be extensible and to include all "meta
>> data" about the content tracks, so IMO it is still a natural fit. Ogg
>> Skeleton is really a wrapper for every other content track in Ogg, so
>> an Index should really go into it. People who don't want to use the
>> Index can just use a previous version of Ogg Skeleton. Or
>> alternatively we can make the new Ogg Skeleton version flexible to
>> include or not include an index per track. Splicing in won't be more
>> difficult if we follow Conrad's suggestion of adding a index packet
>> per track rather than merging it with the existing packet per track.
>
> What software out there currently reads the skeleton?

I think lots of software skips it, which you could call "basic
support". But it is increasing functionality with, e.g. Media Fragment
support, when e.g. you want to address tracks by a name (e.g. "sign
language") and want to do specific things in your player with it that
will make a difference and will encourage players to implement proper
support for it. Many of these more hard core applications (you may
call them "semi-professional") have not reached Ogg yet - or people
diss Ogg as a system that is incapable of supporting them. But it's
not - it's what skeleton was made for. So, while right now you may not
find many players supporting it properly, it's the future that I'm
concerned about. And an index like the one you're proposing is really
just another type of optional meta data for tracks that I'd rather put
into Skeleton and make optional there than put into an extra track
that decoders may then start relying on.


> I'm also concerned that any players which actually read the skeleton
> will be crashy. I'll mock up some Oggs with indexes in the skeleton, and
> see how players handle them.

Make sure to include the index in a way that is backwards compatible.
And then if some players crash, they are actual bugs.


>> Also, is the "length" basically the difference between the
>> playback start and end time, but in bytes? How does that help?
>
> Yup, it's the length in bytes. I included that so that you can jump
> between segments easily in chained files. That way if you have a chain
> of multiple ogg files ("sequentially multiplexed bitstreams" as you
> refer to them in the Skeleton RFC), you know can determine the offset of
> the start of the next segment/file. When seeking, if the seek target is
> outside of the bounds of your segment's index's [start time, end time],
> you know to skip to the start of the next segment to try seeking in there.

Fair enough.


>> Anyway - I love the work and I want it moved forward. Let's sort out
>> the details.
>
> Yes lets! What is the process to getting this "blessed" by the community
> and an official Ogg standard? What's the process?

Mostly it's discussion and general agreement here. If enough people
care about it, they will speak up - also for or against including it
into Skeleton. If not, code and persistence wins against the
indifferent. ;-)

Cheers,
Silvia.