[ogg-dev] Seeking to granules in discontinuous streams

[ogg.k.ogg.k at googlemail.com]

> It is more complex, because the granulepos is available at the page
> level.

Ah. Good point, I always forget about the partial page problem :(
I conveniently flush pages after each data packet in my case (due to
unknown/arbitrary latency), so I tend to forget easily about those.

> We've generally designed the seeking algorithm so it can be
> implemented without looking inside the packets beyond looking up the
> samplerate in the first few packets. And you can repeat both the
> samplerate and how much to shift the granulepos to get a backlink in
> a skeleton packet.

This puzzles me: what are you referring to when you say "the seeking
algorithm" ? If you're referring a particular implementation, then it does
mandate the linear (or is it affine ?) granule/time mapping, but I've not
seen any of this in the Ogg docs. If, you're referring to the structure of
Ogg packets/pages where you have to do one (or more) bisection(s),
then this is more general, and cannot rely on this knowledge, which is
particular to each codec.

Actually, I'm thinking about all this while writing, and it's hitting me that
it should not matter whether you have partial pages or not: if you have a
partial page, it means that no packets end on that page (I'm assuming
the semantics of a -1 granulepos is the same for both continuous and
discontinous streams here). You can therefore ignore that page for the
purposes of seeking, since you couldn't make use of it to start decoding
anyway. Unless you have monster packets that span pages all the time,
this won't happen much anyway.
Or is there a reason such pages have to be handled specially ?

> Of course we could add your scheme to Skeleton as well, but the start
> of the packet data could be on a completely different page from the
> granulepos.

That was not the intent, my scheme is likely to be very specific to my case.
My point was to try to understand how the splitting of granules in two would
avoid a double bisection, which it doesn't if I got that well, so I'm trying to
get an explanation of its interest, which so far seems to be that it keeps all
the granule data in the same place, at the page level, which so far does
not convince me it is worth the loss of 32 bits of granule space.

> We need to work out recommendations for this. And it depends on your
> purposes: the mod_annodex thing of trying to efficiently serve a
> chunk out of an existing file is the most demanding. But even for
> generic playback from a file, you have to know whether you need to
> find the kate packet after a seek or just wait and see if one
> eventually falls out.

Provided you seeked at or before the backlink, just playing and waiting
for the next packet is enough, since that's the point of that backlink.