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

> Leaving aside what the hypothetical seek algorithm would or wouldn't
> do, I believe that would work. It's still different from existing
> schemes though.
Yes, it is different technically.

However, I was trying to find something sufficiently close to the system
of granuleshift, which you seem to want to become the "standard" way
of mapping time to granules, despite Ogg leaving this to each codec.

What I outlined is a superset of that system, with the granuleshift as
in Theora/CMML, and a second granuleshift in the other direction, to
mask out the lower bits, if any. If that second granuleshift is zero, it
resolves back to the theora/CMML system, I think. I have implemented
it, so I may be missing something that doesn't work though.

It means it is slightly more complex, yes, but allows a codec to decide
whether it wants less precision on the backlink in exchange for more
granulespace bits. Theora does not need this, as it only needs 8 bits
(I think) max between keyframes, so there is no granulespace shortage.

Now, if your point is just that it's different, then fair enough, but I
tried to
make it as close as possible to the granuleshift system, and it is backward
compatible with it.

Well, it doesn't quite work because the second part of the gpos is an
offset,
rather than absolute, and the precision we shed on one, we need to recover
on the other one, to keep the ability to timestamp events at the correct
granularity. It would have worked if the second part was absolute as well, as
the loss of precision on one would not have meant a loss of precision on the
other one.

So I'll call it a day, use the Theora/CMML system, use more bits for the
base gpos, and mandate a resend for events with a lifetime which is more
than the max resulting offset.

Thanks for your answers and help, and sorry again for the badgering.

On 15-Feb-08, at 6:44 AM, ogg.k.ogg.k@googlemail.com wrote:
> Well, it doesn't quite work because the second part of the gpos is  
> an offset,
> rather than absolute, and the precision we shed on one, we need to  
> recover
> on the other one, to keep the ability to timestamp events at the  
> correct
> granularity. It would have worked if the second part was absolute  
> as well, as
> the loss of precision on one would not have meant a loss of  
> precision on the
> other one.
Hah. So much for our helpful suggestions. :)

  -r