TransOggChangesFromOgg: Difference between revisions

From XiphWiki
Jump to navigation Jump to search
No edit summary
m (minor wording)
 
Line 5: Line 5:
== Full stream metadata on every packet ==
== Full stream metadata on every packet ==


Most containers replicate some codec data into the container layer for ease of implementation, balancing overhead/complexity with convenience.  This pushes back (but does not eliminate) the need for a codec-specific 'stubs' or 'packetizers'.
Most containers replicate some codec data into the container layer for ease of implementation, balancing overhead/complexity with convenience.  This pushes back (but does not eliminate) the need for a codec-specific 'packetizer stubs' or 'mux shims'.


The original Ogg design took a 'maximally minimalist' stance on stream
The original Ogg design took a maximally minimalist stance on stream
metadata, not replicating any data into the container layer that could
metadata, not replicating any data into the container layer that could
be provided by a codec stub.  This was not a popular design decision
be provided by a codec stub.  This was not a popular design decision
to put it mildly, mainly because it pushed more of the implementation
to put it mildly, substantially because it pushed more of the implementation
work out of the container lib and onto external framework implementors.
work out of the container lib and onto external framework implementors.



Latest revision as of 08:04, 3 September 2012

TransOgg is intended to be the next major revision of the Ogg container. The major changes over the original container are summarized below.

Transport Changes

Full stream metadata on every packet

Most containers replicate some codec data into the container layer for ease of implementation, balancing overhead/complexity with convenience. This pushes back (but does not eliminate) the need for a codec-specific 'packetizer stubs' or 'mux shims'.

The original Ogg design took a maximally minimalist stance on stream metadata, not replicating any data into the container layer that could be provided by a codec stub. This was not a popular design decision to put it mildly, substantially because it pushed more of the implementation work out of the container lib and onto external framework implementors.

For that reason, transOgg goes the opposite direction. It stamps full container metadata on every packet, pushing back the need for packetizers even further, and hopefully saving more work.

Generalized/formalized timing and interleave metadata

The timing, interleave, structure, and codec-specific fields must be fully generalized, specified and declared by the container.

New lacing scheme

Packet size encoding is tweaked to use a new extension pivot; rather than extending the packet size encoding from an extension value of 255, the new pivot is 252. This allows the length of any packet segment in a page to be encoded in at most three bytes, preserves small-packet encoding efficiency and also allows signalling for runs of zero-packets in null-packet based VFR schemes.

Metadata

The core philosophy of building a layered container out of a basic streaming transport is unchanged. As in the original Ogg design, metadata is encapsulated within the low-level transport as a stream. Unlike the original Ogg, transOgg metadata is mandatory and necessary for stream operation. Metadata uses stream ID 0 in all links. All other stream IDs must be unique to the complete stream.

Structural metadata

This is the essential metadata required for operation of the transOgg's mux layer. As in the original Ogg, no metadata is required to capture, parse and recover packets from the page stream, however structural metadata is required to interpret many of the values contained in the page. This data exists in the form of a header/footer pair and is mandatory.

  • Per-stream metadata, such as timing, sync/order flags, codec flags, etc.
  • Mandatory stream-global information (enumeration of codecs)
  • Per-stream codec setup information (codec headers)
  • seeking index (optional)
  • Chaining linkage

Semantic metadata

This is metadata used to properly present or semantically augment the data of the stream itself.

  • Stream relationships (primary/secondary angles, languages, overlays, etc)
  • Non-linear features such as chapters
  • Fixed (header/footer) and streamable semantic metadata
  • Streamed (rolling) headers for in-band capture

More Information