[theora] Indexing Ogg files for faster seeking

[Silvia Pfeiffer]

On Wed, Oct 14, 2009 at 12:50 PM, Chris Pearce <chris at pearce.org.nz> wrote:
> On 10/14/2009 12:04 PM, Silvia Pfeiffer wrote:
>>> Right, you have to decode the pages, and use the pages' granulepos to
>>> calculate each packet's granulepos. Players already know how to do this,
>>> that's how they calculate the presentation time of frames.
>>
>> Even then you don't always have them. The basetime is the basetime of
>> the first packet. In a file that has been cut out of a larger file and
>> is a subpart, you don't know what the starting time is - it could be 2
>> hours  21 min and not 0. This is what basetime was created for.
>> Presentation time otoh tells you how much away from basetime you
>> should be parsing before starting to present it. In the normal file
>> case, basetime is 0 and the granulepos tells you the presentation
>> time. But granulepos doesn't let you reliably map to a time offset.
>
> So the purpose of basetime is that it should be added to every frame's
> presentation time? Along with the UTC field? I guess that's useful for
> say home movies or somesuch.

For basetime, yes. But not for UTC. UTC is just a marker to map
baseline to. Nothing to add - all arithmetics are done on the normal
timeline.


> I accept that there may be some applications where the basetime and UTC
> time are wanted.

Yeah, when they were done there seemed a need, but it hasn't been used
to its full capabilities yet.


> Presentation time as per the skeleton is the timestamp of the first
> sample, unmodified by basetime? That can be determined by decoding
> (perhaps a few) pages. It's still nice to have - if we have the end time
> as well to calculate the duration.

Yeah, I suppose you will want the end time too. We didn't add it to
Skeleton because if you chop the Ogg off at the end, you'd have to
change the headers at the start. Also, for live streams, there isn't
any end time. But it is obviously a good thing to have for canned
content.


>> So, can the "length" be calculated as length=playbackend -
>> playbackstart ? Just wondering if we are duplicating information here.
>
> No. Length is in bytes, it's not the duration. I think you understood
> why we want from in my other email. The index stores the duration as
> playbackend-playbackstart, so that we don't need to seek to the end to
> get the duration in the absence of X-Content-Duration HTTP header.

Yup, all clear now. :)

Ta,
Silvia.