[ogg-dev] Seeking to granules in discontinuous streams

[Ralph Giles]

On 11-Feb-08, at 2:46 AM, ogg.k.ogg.k at googlemail.com wrote:

> 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);

It is more complex, because the granulepos is available at the page  
level. 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.

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.

> If I understand what you want to get at, the frequency would be  
> tied to the
> maximum delay between two packets ?

Yes, possibly with a hint about this in the skeleton metadata.

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

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.

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

That's the sort of thing I was talking about.

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

I can think of two 'seeking hints' that might be useful in skeleton.  
One is some kind of minumum page frequency, to help an implementation  
decide if it's looked hard enough for a packet from a particular  
stream. Another is just a way to say a particular stream isn't  
essential for playback: if you find a page, great, otherwise just  
wait for the next one to fall out. These could be combined of course.

  -r