[ogg-dev] Seeking to granules in discontinuous streams

[Ralph Giles]

On 12-Feb-08, at 2:02 AM, ogg.k.ogg.k at 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