00001 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
00002 <html>
00003 <head>
00004
00005 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15"/>
00006 <title>Ogg Vorbis Documentation</title>
00007
00008 <style type="text/css">
00009 body {
00010 margin: 0 18px 0 18px;
00011 padding-bottom: 30px;
00012 font-family: Verdana, Arial, Helvetica, sans-serif;
00013 color: #333333;
00014 font-size: .8em;
00015 }
00016
00017 a {
00018 color: #3366cc;
00019 }
00020
00021 img {
00022 border: 0;
00023 }
00024
00025 #xiphlogo {
00026 margin: 30px 0 16px 0;
00027 }
00028
00029 #content p {
00030 line-height: 1.4;
00031 }
00032
00033 h1, h1 a, h2, h2 a, h3, h3 a {
00034 font-weight: bold;
00035 color: #ff9900;
00036 margin: 1.3em 0 8px 0;
00037 }
00038
00039 h1 {
00040 font-size: 1.3em;
00041 }
00042
00043 h2 {
00044 font-size: 1.2em;
00045 }
00046
00047 h3 {
00048 font-size: 1.1em;
00049 }
00050
00051 li {
00052 line-height: 1.4;
00053 }
00054
00055 #copyright {
00056 margin-top: 30px;
00057 line-height: 1.5em;
00058 text-align: center;
00059 font-size: .8em;
00060 color: #888888;
00061 clear: both;
00062 }
00063 </style>
00064
00065 </head>
00066
00067 <body>
00068
00069 <div id="xiphlogo">
00070 <a href="http://www.xiph.org/"><img src="fish_xiph_org.png" alt="Fish Logo and Xiph.org"/></a>
00071 </div>
00072
00073 <h1>Ogg logical and physical bitstream overview</h1>
00074
00075 <h2>Ogg bitstreams</h2>
00076
00077 <p>Ogg codecs use octet vectors of raw, compressed data
00078 (<em>packets</em>). These compressed packets do not have any
00079 high-level structure or boundary information; strung together, they
00080 appear to be streams of random bytes with no landmarks.</p>
00081
00082 <p>Raw packets may be used directly by transport mechanisms that provide
00083 their own framing and packet-separation mechanisms (such as UDP
00084 datagrams). For stream based storage (such as files) and transport
00085 (such as TCP streams or pipes), Vorbis and other future Ogg codecs use
00086 the Ogg bitstream format to provide framing/sync, sync recapture
00087 after error, landmarks during seeking, and enough information to
00088 properly separate data back into packets at the original packet
00089 boundaries without relying on decoding to find packet boundaries.</p>
00090
00091 <h2>Logical and physical bitstreams</h2>
00092
00093 <p>Raw packets are grouped and encoded into contiguous pages of
00094 structured bitstream data called <em>logical bitstreams</em>. A
00095 logical bitstream consists of pages, in order, belonging to a single
00096 codec instance. Each page is a self contained entity (although it is
00097 possible that a packet may be split and encoded across one or more
00098 pages); that is, the page decode mechanism is designed to recognize,
00099 verify and handle single pages at a time from the overall bitstream.</p>
00100
00101 <p>Multiple logical bitstreams can be combined (with restrictions) into a
00102 single <em>physical bitstream</em>. A physical bitstream consists of
00103 multiple logical bitstreams multiplexed at the page level and may
00104 include a 'meta-header' at the beginning of the multiplexed logical
00105 stream that serves as identification magic. Whole pages are taken in
00106 order from multiple logical bitstreams and combined into a single
00107 physical stream of pages. The decoder reconstructs the original
00108 logical bitstreams from the physical bitstream by taking the pages in
00109 order from the physical bitstream and redirecting them into the
00110 appropriate logical decoding entity. The simplest physical bitstream
00111 is a single, unmultiplexed logical bitstream with no meta-header; this
00112 is referred to as a 'degenerate stream'.</p>
00113
00114 <p><a href="framing.html">Ogg Logical Bitstream Framing</a> discusses
00115 the page format of an Ogg bitstream, the packet coding process
00116 and logical bitstreams in detail. The remainder of this document
00117 specifies requirements for constructing finished, physical Ogg
00118 bitstreams.</p>
00119
00120 <h2>Mapping Restrictions</h2>
00121
00122 <p>Logical bitstreams may not be mapped/multiplexed into physical
00123 bitstreams without restriction. Here we discuss design restrictions
00124 on Ogg physical bitstreams in general, mostly to introduce
00125 design rationale. Each 'media' format defines its own (generally more
00126 restrictive) mapping. An 'Ogg Vorbis Audio Bitstream', for example, has a
00127 specific physical bitstream structure.
00128 An 'Ogg A/V' bitstream (not currently specified) will also mandate a
00129 specific, restricted physical bitstream format.</p>
00130
00131 <h3>additional end-to-end structure</h3>
00132
00133 <p>The <a href="framing.html">framing specification</a> defines
00134 'beginning of stream' and 'end of stream' page markers via a header
00135 flag (it is possible for a stream to consist of a single page). A
00136 stream always consists of an integer number of pages, an easy
00137 requirement given the variable size nature of pages.</p>
00138
00139 <p>In addition to the header flag marking the first and last pages of a
00140 logical bitstream, the first page of an Ogg bitstream obeys
00141 additional restrictions. Each individual media mapping specifies its
00142 own implementation details regarding these restrictions.</p>
00143
00144 <p>The first page of a logical Ogg bitstream consists of a single,
00145 small 'initial header' packet that includes sufficient information to
00146 identify the exact CODEC type and media requirements of the logical
00147 bitstream. The intent of this restriction is to simplify identifying
00148 the bitstream type and content; for a given media type (or across all
00149 Ogg media types) we can know that we only need a small, fixed
00150 amount of data to uniquely identify the bitstream type.</p>
00151
00152 <p>As an example, Ogg Vorbis places the name and revision of the Vorbis
00153 CODEC, the audio rate and the audio quality into this initial header,
00154 thus simplifying vastly the certain identification of an Ogg Vorbis
00155 audio bitstream.</p>
00156
00157 <h3>sequential multiplexing (chaining)</h3>
00158
00159 <p>The simplest form of logical bitstream multiplexing is concatenation
00160 (<em>chaining</em>). Complete logical bitstreams are strung
00161 one-after-another in order. The bitstreams do not overlap; the final
00162 page of a given logical bitstream is immediately followed by the
00163 initial page of the next. Chaining is the only logical->physical
00164 mapping allowed by Ogg Vorbis.</p>
00165
00166 <p>Each chained logical bitstream must have a unique serial number within
00167 the scope of the physical bitstream.</p>
00168
00169 <h3>concurrent multiplexing (grouping)</h3>
00170
00171 <p>Logical bitstreams may also be multiplexed 'in parallel'
00172 (<em>grouped</em>). An example of grouping would be to allow
00173 streaming of separate audio and video streams, using different codecs
00174 and different logical bitstreams, in the same physical bitstream.
00175 Whole pages from multiple logical bitstreams are mixed together.</p>
00176
00177 <p>The initial pages of each logical bitstream must appear first; the
00178 media mapping specifies the order of the initial pages. For example,
00179 Ogg A/V will eventually specify an Ogg video bitstream with
00180 audio. The mapping may specify that the physical bitstream must begin
00181 with the initial page of a logical video bitstream, followed by the
00182 initial page of an audio stream. Unlike initial pages, terminal pages
00183 for the logical bitstreams need not all occur contiguously (although a
00184 specific media mapping may require this; it is not mandated by the
00185 generic Ogg stream spec). Terminal pages may be 'nil' pages,
00186 that is, pages containing no content but simply a page header with
00187 position information and the 'last page of bitstream' flag set in the
00188 page header.</p>
00189
00190 <p>Each grouped bitstream must have a unique serial number within the
00191 scope of the physical bitstream.</p>
00192
00193 <h3>sequential and concurrent multiplexing</h3>
00194
00195 <p>Groups of concurrently multiplexed bitstreams may be chained
00196 consecutively. Such a physical bitstream obeys all the rules of both
00197 grouped and chained multiplexed streams; the groups, when unchained ,
00198 must stand on their own as a valid concurrently multiplexed
00199 bitstream.</p>
00200
00201 <h3>multiplexing example</h3>
00202
00203 <p>Below, we present an example of a grouped and chained bitstream:</p>
00204
00205 <p><img src="stream.png" alt="stream"/></p>
00206
00207 <p>In this example, we see pages from five total logical bitstreams
00208 multiplexed into a physical bitstream. Note the following
00209 characteristics:</p>
00210
00211 <ol>
00212 <li>Grouped bitstreams begin together; all of the initial pages
00213 must appear before any data pages. When concurrently multiplexed
00214 groups are chained, the new group does not begin until all the
00215 bitstreams in the previous group have terminated.</li>
00216
00217 <li>The pages of concurrently multiplexed bitstreams need not conform
00218 to a regular order; the only requirement is that page <tt>n</tt> of a
00219 logical bitstream follow page <tt>n-1</tt> in the physical bitstream.
00220 There are no restrictions on intervening pages belonging to other
00221 logical bitstreams. (Tying page appearance to bitrate demands is one
00222 logical strategy, ie, the page appears at the chronological point
00223 where decode requires more information).</li>
00224 </ol>
00225
00226 <div id="copyright">
00227 The Xiph Fish Logo is a
00228 trademark (™) of Xiph.Org.<br/>
00229
00230 These pages © 1994 - 2005 Xiph.Org. All rights reserved.
00231 </div>
00232
00233 </body>
00234 </html>
