[ogg-dev] Seeking to granules in discontinuous streams

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

> The advantage of storing this in the granulepos field itself, like
> theora and CMML do, is that the seek code may already understand how
> to handle the back pointer. Right now everything assumes the mapping
> is from 'initialized decoder' + 'granulepos from page header' =>
> timestamp, or in the case of theora and CMML => 'timestamp' + 'last
> keyframe timestamp.' Having to look in the accompanying page data is
> an additional complication.

Since the format of that back pointer is specific to each codec, the seek
code must already know how that codec does its backlink, for each codec
it supports. This is not generic for all codecs. Therefore, picking an extra
64 bits granulepos at the start of the data is a fairly trivial complication, as
the Ogg layer will have the data handy since it just seeked to it. That extra
complication comes with the plus of not chopping off half the granule bit
space for the backlink, leaving only a 4 billionth of the granule space
available (if one assumes no reserved bits).
Or is there something that makes it that much easier to deal with a backlink
in the granulepos itself ?
For reference, my data packets start with start granule, end granule, backlink
granule, all 64 bits, so picking the granule is just a simple constant offset
lookup into the data packet, eg, you replace:

backlink = granulepos<<32;

by

backlink = read64le(op.packet+constant_offset);

Hardly complex.

> decoders to find all the relevant data. Put another way, start-time
> labelling for substreams with low page frequency helps buffering after
> they're muxed, but it only goes so far if there's not also a lower
> bound on that frequency.

If I understand what you want to get at, the frequency would be tied to the
maximum delay between two packets ?
FWIW, we only need to find a packet from the disc stream on the first
bisection (to find the backlink). For the second bisection, it is enough to
seek to a time before that backlink, as streaming in will eventually encounter
the backlinked packet, and that's enough for our purposes. Therefore, the
second bisection can be done timewise on the main continuous codec (eg,
the accompanying theora video).
If there is no accompanying theora video (or similar), then I don't think the
problem happens, since you'll be swamped by kate packets anyway, since
there'll be nothing else there, so you don't waste time looking for them.
Still means you get the hit for the first bisection.

Following on your point about a lower bound on the frequency, maybe one
could add "keepalive" packets when no data packets have been issued for
a long enough time, and such packets would carry no data but the backlink
itself. Hmm, I like the idea. The packets would be very small (well, datawise,
most of the data will be Ogg header stuff), and we wouldn't get that bad data
duplication that was inherent in the "echo" method described in the Writ doc.

Mind you, that kind of frequency info is something that might be usefully put
in a new skeleton field, if it could help the seek code seek more efficiently.
Not sure if and how it could though.