[ogg-dev] New Ogg Dirac mapping draft

[ogg.k.ogg.k at googlemail.com]

> Many Ogg tools assume they can repaginate, and probably won't get the
> one-page-per-packet stuff right. This leads to the usual argument

This could be something to add to Skeleton. Kate (and probably CMML)
needs the one-packet-per-page thing also, and any discontinuous codec
probably needs it as well (well, not *need*, but no good buffering without
it). It's trivial for a muxer to do, and it's transparent to a demuxer.

> The granulepos will no longer be numerically non-decreasing, so
> implementations that make this assumption will break.

Wouldn't pretty much anything that deal with Ogg be broken by this ?
How would, say, oggz-validate deal with this, apart from treating Dirac
differently ? Seeking would not work without knowing a particular stream
is Dirac too (would have to bsearch on time, not granpos directly). I'd
have thought this to be a hard requirement rather than an assumption.
If using Skeleton, seeking can now be done on time values even if you
don't know which codec it is - I think this breaks this too (though I have
not thought too hard about this).

> lower for large (>8K) packets. I'd almost rather see us take this
> route, with a new Ogg page type, if the Dirac developers want a

Intriguing, can you expand on what you mean by "new Ogg page type" ?