[ogg-dev] Fwd: New Ogg Dirac mapping draft

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

>> 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.
>
> That's a good idea. Any suggestions for where?

Well, there are reserved bits in fisbone just after the granule shift.
I doubt adding this to the message headers would be a good way to do it,
but that'd another way.

>> Wouldn't pretty much anything that deal with Ogg be broken by this ?
>
> It depends how they're written. If they calculate a numerical
> granulepos for the desired point on the timeline and seek by comparing
> stream granulepos to that numeric value, they will fail. If they

And that's the canonical way AFAIK. Comparing times computed from
the granpos you get from pages you get from a bsearch requires good
knowledge of the codec, whereas comparing granpos can seek within
any codec.

> OTOH, the RFC can be read to require the numeric values be increasing.

I recall pointing out a discrepancy between Ogg docs and the RFC, and
I think someone (either Silvia or Conrad, probably Silvia) fixed the RFC.
(That was the reason I'd originally included the low counter bits for Kate).

>> Intriguing, can you expand on what you mean by "new Ogg page type" ?
>
> The Ogg page header has a version field and 5 unused flag bits, so we
> can add new page types if we want. ogg_stream_pagein() will reject
> pages with newer version numbers, and extra flags are ignored.

Which is essentially creating a new format, as an old demuxer will be able
to do nothing at all with such a stream, or do you have a cunning plan to
make those backward compatible ?

> * The lacing method of encoding packet length and page spanning is
> less efficient for large packets, so for HD video a 'large page' type
> would be nice.

I'll take this opportunity to mention my pet idea (don't think I ever mentioned
it on ogg-dev), to start with a byte, then, if larger than 255, add two bytes,
then for packets larger than 255+65536, add 4 bytes. This lacing is worse
than the current one only for packets between 256 and 511 bytes (admittedly
a probably common case, but adding only one byte). Now that you mention
flags, lacing type could be put in flags, so this worsening could be avoided
too.

> encoding which doesn't support packing. Whether we want to add
> multiple explicit timestamp fields like mux authors have requested, I
> don't know.

Certainly a criticism of Ogg I heard more than once :)