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

After some more thought on this, I'm trying to work out whether the back
link
offset needs precision.
Semantically, the only need we have for this is to be able to seek
back to a point
before the start of the earliest event still active at the time of the
original seek.

As far as I know, and please correct me if I'm wrong, nothing in Ogg
mandates that
this backlink actually resolves to a a particular "existing"
granulepos in the stream,
right ? The hypothetic canonical seek algorithm will bisect till it
finds the latest page
that has a granulepos equal or less than the granulepos we're seeking
to. Therefore,
it should be OK if the backlink links to somewhere before the actual
position of the
backlink. If this is fine, which I think it is, then we can blithely
drop precision on that
backlink (eg, remove the low bits and add 1 to the remaining value,
which is always
overestimating it). If the precision loss isn't too great, then we
won't throw an undue
extra load onto the seeker, which will seek to the same page most of
the time, if the
precision loss is kept to acceptable limits.

Additionally, though I'm a bit uncomfortable with this, one could
mandate a maximum
lifetime for an event. Events passing that lifetime would have to be
sent again. If the
max lifetime is long enough, the extra bandwidth would be negligible
(only needed for
those very long events). This would have to be balanced against the
bits we take off
that backlink (low bits for precision, high bits for lifetime).

And we get those bits back as granulespace fodder.

Am I missing something here that would make this unworkable or breaking spec ?

Thanks

On 14-Feb-08, at 9:43 AM, ogg.k.ogg.k@googlemail.com wrote:
> As far as I know, and please correct me if I'm wrong, nothing in Ogg
> mandates that
> this backlink actually resolves to a a particular "existing"
> granulepos in the stream,
> right ? The hypothetic canonical seek algorithm will bisect till it
> finds the latest page
> that has a granulepos equal or less than the granulepos we're seeking
> to. Therefore,
> it should be OK if the backlink links to somewhere before the actual
> position of the
> backlink.
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.

  -r

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