Chris@1:
Chris@1: Ogg codecs use octet vectors of raw, compressed data Chris@1: (packets). These compressed packets do not have any Chris@1: high-level structure or boundary information; strung together, they Chris@1: appear to be streams of random bytes with no landmarks.
Chris@1: Chris@1:Raw packets may be used directly by transport mechanisms that provide Chris@1: their own framing and packet-separation mechanisms (such as UDP Chris@1: datagrams). For stream based storage (such as files) and transport Chris@1: (such as TCP streams or pipes), Vorbis and other future Ogg codecs use Chris@1: the Ogg bitstream format to provide framing/sync, sync recapture Chris@1: after error, landmarks during seeking, and enough information to Chris@1: properly separate data back into packets at the original packet Chris@1: boundaries without relying on decoding to find packet boundaries.
Chris@1: Chris@1:Raw packets are grouped and encoded into contiguous pages of Chris@1: structured bitstream data called logical bitstreams. A Chris@1: logical bitstream consists of pages, in order, belonging to a single Chris@1: codec instance. Each page is a self contained entity (although it is Chris@1: possible that a packet may be split and encoded across one or more Chris@1: pages); that is, the page decode mechanism is designed to recognize, Chris@1: verify and handle single pages at a time from the overall bitstream.
Chris@1: Chris@1:Multiple logical bitstreams can be combined (with restrictions) into a Chris@1: single physical bitstream. A physical bitstream consists of Chris@1: multiple logical bitstreams multiplexed at the page level and may Chris@1: include a 'meta-header' at the beginning of the multiplexed logical Chris@1: stream that serves as identification magic. Whole pages are taken in Chris@1: order from multiple logical bitstreams and combined into a single Chris@1: physical stream of pages. The decoder reconstructs the original Chris@1: logical bitstreams from the physical bitstream by taking the pages in Chris@1: order from the physical bitstream and redirecting them into the Chris@1: appropriate logical decoding entity. The simplest physical bitstream Chris@1: is a single, unmultiplexed logical bitstream with no meta-header; this Chris@1: is referred to as a 'degenerate stream'.
Chris@1: Chris@1:Ogg Logical Bitstream Framing discusses Chris@1: the page format of an Ogg bitstream, the packet coding process Chris@1: and logical bitstreams in detail. The remainder of this document Chris@1: specifies requirements for constructing finished, physical Ogg Chris@1: bitstreams.
Chris@1: Chris@1:Logical bitstreams may not be mapped/multiplexed into physical Chris@1: bitstreams without restriction. Here we discuss design restrictions Chris@1: on Ogg physical bitstreams in general, mostly to introduce Chris@1: design rationale. Each 'media' format defines its own (generally more Chris@1: restrictive) mapping. An 'Ogg Vorbis Audio Bitstream', for example, has a Chris@1: specific physical bitstream structure. Chris@1: An 'Ogg A/V' bitstream (not currently specified) will also mandate a Chris@1: specific, restricted physical bitstream format.
Chris@1: Chris@1:The framing specification defines Chris@1: 'beginning of stream' and 'end of stream' page markers via a header Chris@1: flag (it is possible for a stream to consist of a single page). A Chris@1: stream always consists of an integer number of pages, an easy Chris@1: requirement given the variable size nature of pages.
Chris@1: Chris@1:In addition to the header flag marking the first and last pages of a Chris@1: logical bitstream, the first page of an Ogg bitstream obeys Chris@1: additional restrictions. Each individual media mapping specifies its Chris@1: own implementation details regarding these restrictions.
Chris@1: Chris@1:The first page of a logical Ogg bitstream consists of a single, Chris@1: small 'initial header' packet that includes sufficient information to Chris@1: identify the exact CODEC type and media requirements of the logical Chris@1: bitstream. The intent of this restriction is to simplify identifying Chris@1: the bitstream type and content; for a given media type (or across all Chris@1: Ogg media types) we can know that we only need a small, fixed Chris@1: amount of data to uniquely identify the bitstream type.
Chris@1: Chris@1:As an example, Ogg Vorbis places the name and revision of the Vorbis Chris@1: CODEC, the audio rate and the audio quality into this initial header, Chris@1: thus simplifying vastly the certain identification of an Ogg Vorbis Chris@1: audio bitstream.
Chris@1: Chris@1:The simplest form of logical bitstream multiplexing is concatenation Chris@1: (chaining). Complete logical bitstreams are strung Chris@1: one-after-another in order. The bitstreams do not overlap; the final Chris@1: page of a given logical bitstream is immediately followed by the Chris@1: initial page of the next. Chaining is the only logical->physical Chris@1: mapping allowed by Ogg Vorbis.
Chris@1: Chris@1:Each chained logical bitstream must have a unique serial number within Chris@1: the scope of the physical bitstream.
Chris@1: Chris@1:Logical bitstreams may also be multiplexed 'in parallel' Chris@1: (grouped). An example of grouping would be to allow Chris@1: streaming of separate audio and video streams, using different codecs Chris@1: and different logical bitstreams, in the same physical bitstream. Chris@1: Whole pages from multiple logical bitstreams are mixed together.
Chris@1: Chris@1:The initial pages of each logical bitstream must appear first; the Chris@1: media mapping specifies the order of the initial pages. For example, Chris@1: Ogg A/V will eventually specify an Ogg video bitstream with Chris@1: audio. The mapping may specify that the physical bitstream must begin Chris@1: with the initial page of a logical video bitstream, followed by the Chris@1: initial page of an audio stream. Unlike initial pages, terminal pages Chris@1: for the logical bitstreams need not all occur contiguously (although a Chris@1: specific media mapping may require this; it is not mandated by the Chris@1: generic Ogg stream spec). Terminal pages may be 'nil' pages, Chris@1: that is, pages containing no content but simply a page header with Chris@1: position information and the 'last page of bitstream' flag set in the Chris@1: page header.
Chris@1: Chris@1:Each grouped bitstream must have a unique serial number within the Chris@1: scope of the physical bitstream.
Chris@1: Chris@1:Groups of concurrently multiplexed bitstreams may be chained Chris@1: consecutively. Such a physical bitstream obeys all the rules of both Chris@1: grouped and chained multiplexed streams; the groups, when unchained , Chris@1: must stand on their own as a valid concurrently multiplexed Chris@1: bitstream.
Chris@1: Chris@1:Below, we present an example of a grouped and chained bitstream:
Chris@1: Chris@1:
In this example, we see pages from five total logical bitstreams Chris@1: multiplexed into a physical bitstream. Note the following Chris@1: characteristics:
Chris@1: Chris@1: