ogg dev - Feb 2008 - Seeking to granules in discontinuous streams

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

On 12-Feb-08, at 2:02 AM, ogg.k.ogg.k@googlemail.com wrote:
>> 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.
Ah, right. So it might be ok for Ogg Kate.
> This puzzles me: what are you referring to when you say "the seeking
> algorithm" ?
The hypothetical seeking algorithm. We should be writing it down, I  
suppose, but what's generally going on is we're trying to negotiate  
both an Ogg mapping profile for multiplexed audio/video/text streams  
and a seeking algorithm (or a hierarchy of them) we can then  
document, in the sense of "implement this and conforming files will  
work."
> 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).
The problem is that you can have *both* packed and continued packets  
on the same page, so you can have a page with the end of one packet  
(and thus marked with that packet's granulepos) and the start of  
another packet that finishes on a subsequent page. And in fact the  
current libogg implementation does just this if you hand it larger  
packets, though we should make it stop.

Of course, you do just skip pages marked with a -1 one when you're  
seeking because they don't tell you anything, but that's not the only  
case.
> 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've had a lot of complaints from mux and framework implementors  
about how hard it is to generate timestamps for Ogg streams, so we've  
been trying to regularize the current bits and avoid adding any  
additional complication. I'm not sure what the requirements are on  
back references for current media frameworks, but not doing anything  
unnecessarily new there has in essence been my argument.

  -r

On 13/02/2008, Ralph Giles <giles@xiph.org> wrote:
>
> The hypothetical seeking algorithm. We should be writing it down, I
> suppose
This is about the closest we have to a source document on that:
http://web.archive.org/web/20031201054855/http://www.xiph.org/archives/theora-dev/200209/0040.html

K.