[theora] Indexing Ogg files for faster seeking
chris at pearce.org.nz
Tue Oct 13 18:50:40 PDT 2009
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.
More information about the theora