[theora] Indexing Ogg files for faster seeking

[Chris Pearce]

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.

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

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.

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


Chris P.