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

Hi,

sorry, there is a bug in the CMML spec and wiki page ... I discussed
this with Silvia earlier this week but haven't gotten around to
correcting it yet.

CMML granulepos is much like theora's; the previous granule is stored
in the higher bits, and the delta since then is stored in the lower
bits. The current timestamp is the sum of the two. This is the
behavior of the implementations (and has been for many years), and
what is supposed to be in the spec ...

Conrad.

On 14/02/2008, ogg.k.ogg.k@googlemail.com <ogg.k.ogg.k@googlemail.com>
wrote:
> Some more thinking about this whole granulepos splitting. Sorry for
>  the badgering :)
>
>  The CMML way was presented as a similar way as the Theora way, which I
didn't
>  see (I actually use such a system to allow multiple events to start at
>  the same time,
>  and this feels like the Theora way).
>  Theora can find any frame's previous keyframe granulepos by clearing
>  the low bits
>  of the frame's granulepos. In CMML, this is the other way round: you
>  have to shift
>  left by 32 to get the previous frame. This is what puzzled me I think.
>
>  Now, if one were to swap the 2 32 bit granulepos bits in CMML granules,
then you
>  would still get a strictly increasing granulepos (since the previous
>  pointer can never
>  get backwards in time), and this would be more similar to Theora (eg,
>  clear off the low
>  bits). The high bits are now the backlink, and the low bits are the
>  granulepos are the
>  actual granule of the current packet (not an offset from the frame as
>  Theora does,
>  but closer to what it does).
>
>  You still lose 32 bits of granulespace, of course, which really
>  bothers me. At millisecond
>  precision, 32 bits (signed) just give 24 days. Yeah, I know I've said
>  it before :)
>
>  Anyway, this makes a generic seeking algorithm handle Theora and CMML the
same
>  way, clear off the low bits below the granule shift and start off from
there.
>
> _______________________________________________
>  ogg-dev mailing list
>  ogg-dev@xiph.org
>  http://lists.xiph.org/mailman/listinfo/ogg-dev
>
>

> CMML granulepos is much like theora's; the previous granule is stored
> in the higher bits, and the delta since then is stored in the lower
> bits. The current timestamp is the sum of the two. This is the
> behavior of the implementations (and has been for many years), and
> what is supposed to be in the spec ...
Ah, good. That removes a lot of the dislike I had to it.

And if you store an offset rather than another granulepos, then it goes some
way towards fixing the issue I have with the massive loss in granulespace,
as you can then choose to leave less bits for the offset, which was not possible
with a two-granulepos system.

Good, good, I'll give it some more thought on that new (to me) encoding, and
if I can live with it for my purposes. Which would be good for simplicity.

Thanks

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