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

[Ralph Giles]

On Tue, Aug 12, 2008 at 5:46 AM, ogg.k.ogg.k wrote:

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

> 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
convert the stream values to time and compare that way, it will work
fine. We've tried to encourage that direction with calls like
th_granule_time(), and in general it's difficult to calculate a
numeric value for theora because of the skips at the keyframes.

David, can you think of a fancier encoding that would make your
granulepos values non-decreasing?

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

  granule position: An increasing position number for a specific
     logical bitstream stored in the page header.  Its meaning is
     dependent on the codec for that logical bitstream and specified in
     a specific media mapping.

The question is whether 'position number' is literally the same as the
value of the granule position field. :)

Also, I say 'non-decreasing' since a codec doesn't necessarily advance
decoding with every packet. The seeking algorithm only requires
non-decreasing time-equivalents, so 'increasing' in the RFC is an
artificial constraint.

>>                                                  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" ?

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.

There were a couple of things we talked about wanting to do if we
revised the Ogg page structure:

* The CRC rejection of corrupt data isn't always what you want (i.e.
good for audio where digital noise is unacceptable, bad for video
where a goopy picture is better than no picture at all) and is
expensive to calculate when muxing high-bitrate streams. So it would
be nice if we could flag the CRC just covering the page header fields
and not the packet data.

* Having packets both span and pack in the same page increases the
expense of seeking, so it would be nice to do something about this. A
preserve-flag in skeleton like you suggested for one-page-per-packet
might help here, but we could also solve it with a new page type that
just doesn't allow it.

* Various codecs have wanted one-page-per-packet regardless to reduce
buffering requirements for low-frequency packet streams.

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

There hasn't been a concrete suggestion for this, but the general idea
is that we introduce an new Ogg page version 1, with a flag for
whether CRC includes the payload data or not, and either another flag
or another page version that selects a different packet length
encoding which doesn't support packing. Whether we want to add
multiple explicit timestamp fields like mux authors have requested, I
don't know.

 -r