123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197 |
- <HTML><HEAD><TITLE>xiph.org: Ogg Vorbis documentation</TITLE>
- <BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000">
- <nobr><a href="http://www.xiph.org/ogg/index.html"><img src="white-ogg.png" border=0><img
- src="vorbisword2.png" border=0></a></nobr><p>
- <h1><font color=#000070>
- Ogg logical and physical bitstream overview
- </font></h1>
- <em>Last update to this document: July 14, 2002</em><br>
- <h2>Ogg bitstreams</h2>
- Ogg codecs use octet vectors of raw, compressed data
- (<em>packets</em>). These compressed packets do not have any
- high-level structure or boundary information; strung together, they
- appear to be streams of random bytes with no landmarks.<p>
- Raw packets may be used directly by transport mechanisms that provide
- their own framing and packet-separation mechanisms (such as UDP
- datagrams). For stream based storage (such as files) and transport
- (such as TCP streams or pipes), Vorbis and other future Ogg codecs use
- the Ogg bitstream format to provide framing/sync, sync recapture
- after error, landmarks during seeking, and enough information to
- properly separate data back into packets at the original packet
- boundaries without relying on decoding to find packet boundaries.<p>
- <h2>Logical and physical bitstreams</h2>
- Raw packets are grouped and encoded into contiguous pages of
- structured bitstream data called <em>logical bitstreams</em>. A
- logical bitstream consists of pages, in order, belonging to a single
- codec instance. Each page is a self contained entity (although it is
- possible that a packet may be split and encoded across one or more
- pages); that is, the page decode mechanism is designed to recognize,
- verify and handle single pages at a time from the overall bitstream.<p>
- Multiple logical bitstreams can be combined (with restrictions) into a
- single <em>physical bitstream</em>. A physical bitstream consists of
- multiple logical bitstreams multiplexed at the page level and may
- include a 'meta-header' at the beginning of the multiplexed logical
- stream that serves as identification magic. Whole pages are taken in
- order from multiple logical bitstreams and combined into a single
- physical stream of pages. The decoder reconstructs the original
- logical bitstreams from the physical bitstream by taking the pages in
- order from the physical bitstream and redirecting them into the
- appropriate logical decoding entity. The simplest physical bitstream
- is a single, unmultiplexed logical bitstream with no meta-header; this
- is referred to as a 'degenerate stream'. <p>
- <a href=framing.html>Ogg Logical Bitstream Framing</a> discusses
- the page format of an Ogg bitstream, the packet coding process
- and logical bitstreams in detail. The remainder of this document
- specifies requirements for constructing finished, physical Ogg
- bitstreams.<p>
- <h2>Mapping Restrictions</h2>
- Logical bitstreams may not be mapped/multiplexed into physical
- bitstreams without restriction. Here we discuss design restrictions
- on Ogg physical bitstreams in general, mostly to introduce
- design rationale. Each 'media' format defines its own (generally more
- restrictive) mapping. An '<a href="vorbis-ogg.html">Ogg Vorbis
- Audio Bitstream</a>', for example, has a <a
- href="vorbis-ogg.html">specific physical bitstream structure</a>.
- An 'Ogg A/V' bitstream (not currently specified) will also mandate a
- specific, restricted physical bitstream format.<p>
- <h3>additional end-to-end structure</h3>
- The <a href="framing.html">framing specification</a> defines
- 'beginning of stream' and 'end of stream' page markers via a header
- flag (it is possible for a stream to consist of a single page). A
- stream always consists of an integer number of pages, an easy
- requirement given the variable size nature of pages.<p>
- In addition to the header flag marking the first and last pages of a
- logical bitstream, the first page of an Ogg bitstream obeys
- additional restrictions. Each individual media mapping specifies its
- own implementation details regarding these restrictions.<p>
- The first page of a logical Ogg bitstream consists of a single,
- small 'initial header' packet that includes sufficient information to
- identify the exact CODEC type and media requirements of the logical
- bitstream. The intent of this restriction is to simplify identifying
- the bitstream type and content; for a given media type (or across all
- Ogg media types) we can know that we only need a small, fixed
- amount of data to uniquely identify the bitstream type.<p>
- As an example, Ogg Vorbis places the name and revision of the Vorbis
- CODEC, the audio rate and the audio quality into this initial header,
- thus simplifying vastly the certain identification of an Ogg Vorbis
- audio bitstream.<p>
- <h3>sequential multiplexing (chaining)</h3>
- The simplest form of logical bitstream multiplexing is concatenation
- (<em>chaining</em>). Complete logical bitstreams are strung
- one-after-another in order. The bitstreams do not overlap; the final
- page of a given logical bitstream is immediately followed by the
- initial page of the next. Chaining is the only logical->physical
- mapping allowed by Ogg Vorbis.<p>
- Each chained logical bitstream must have a unique serial number within
- the scope of the physical bitstream.<p>
- <h3>concurrent multiplexing (grouping)</h3>
- Logical bitstreams may also be multiplexed 'in parallel'
- (<em>grouped</em>). An example of grouping would be to allow
- streaming of separate audio and video streams, using different codecs
- and different logical bitstreams, in the same physical bitstream.
- Whole pages from multiple logical bitstreams are mixed together.<p>
- The initial pages of each logical bitstream must appear first; the
- media mapping specifies the order of the initial pages. For example,
- Ogg A/V will eventually specify an Ogg video bitstream with
- audio. The mapping may specify that the physical bitstream must begin
- with the initial page of a logical video bitstream, followed by the
- initial page of an audio stream. Unlike initial pages, terminal pages
- for the logical bitstreams need not all occur contiguously (although a
- specific media mapping may require this; it is not mandated by the
- generic Ogg stream spec). Terminal pages may be 'nil' pages,
- that is, pages containing no content but simply a page header with
- position information and the 'last page of bitstream' flag set in the
- page header.<p>
- Each grouped bitstream must have a unique serial number within the
- scope of the physical bitstream.<p>
- <h3>sequential and concurrent multiplexing</h3>
- Groups of concurrently multiplexed bitstreams may be chained
- consecutively. Such a physical bitstream obeys all the rules of both
- grouped and chained multiplexed streams; the groups, when unchained ,
- must stand on their own as a valid concurrently multiplexed
- bitstream.<p>
- <h3>multiplexing example</h3>
- Below, we present an example of a grouped and chained bitstream:<p>
- <img src=stream.png><p>
- In this example, we see pages from five total logical bitstreams
- multiplexed into a physical bitstream. Note the following
- characteristics:
- <ol><li>Grouped bitstreams begin together; all of the initial pages
- must appear before any data pages. When concurrently multiplexed
- groups are chained, the new group does not begin until all the
- bitstreams in the previous group have terminated.<p>
- <li>The pages of concurrently multiplexed bitstreams need not conform
- to a regular order; the only requirement is that page <tt>n</tt> of a
- logical bitstream follow page <tt>n-1</tt> in the physical bitstream.
- There are no restrictions on intervening pages belonging to other
- logical bitstreams. (Tying page appearance to bitrate demands is one
- logical strategy, ie, the page appears at the chronological point
- where decode requires more information).
- </ol>
- <hr>
- <a href="http://www.xiph.org/">
- <img src="white-xifish.png" align=left border=0>
- </a>
- <font size=-2 color=#505050>
- Ogg is a <a href="http://www.xiph.org">Xiph.org Foundation</a> effort
- to protect essential tenets of Internet multimedia from corporate
- hostage-taking; Open Source is the net's greatest tool to keep
- everyone honest. See <a href="http://www.xiph.org/about.html">About
- the Xiph.org Foundation</a> for details.
- <p>
- Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and
- distribute the Ogg and Vorbis specification, whether in a private,
- public or corporate capacity. However, the Xiph.org Foundation and
- the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis
- specification and certify specification compliance.<p>
- Xiph.org's Vorbis software CODEC implementation is distributed under a
- BSD-like license. This does not restrict third parties from
- distributing independent implementations of Vorbis software under
- other licenses.<p>
- Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm)
- of the <a href="http://www.xiph.org/">Xiph.org Foundation</a>. These
- pages are copyright (C) 1994-2002 Xiph.org Foundation. All rights
- reserved.<p>
- </body>
|