| [16] | 1 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> |
|---|
| 2 | <html> |
|---|
| 3 | <head> |
|---|
| 4 | |
|---|
| 5 | <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15"/> |
|---|
| 6 | <title>Ogg Vorbis Documentation</title> |
|---|
| 7 | |
|---|
| 8 | <style type="text/css"> |
|---|
| 9 | body { |
|---|
| 10 | margin: 0 18px 0 18px; |
|---|
| 11 | padding-bottom: 30px; |
|---|
| 12 | font-family: Verdana, Arial, Helvetica, sans-serif; |
|---|
| 13 | color: #333333; |
|---|
| 14 | font-size: .8em; |
|---|
| 15 | } |
|---|
| 16 | |
|---|
| 17 | a { |
|---|
| 18 | color: #3366cc; |
|---|
| 19 | } |
|---|
| 20 | |
|---|
| 21 | img { |
|---|
| 22 | border: 0; |
|---|
| 23 | } |
|---|
| 24 | |
|---|
| 25 | #xiphlogo { |
|---|
| 26 | margin: 30px 0 16px 0; |
|---|
| 27 | } |
|---|
| 28 | |
|---|
| 29 | #content p { |
|---|
| 30 | line-height: 1.4; |
|---|
| 31 | } |
|---|
| 32 | |
|---|
| 33 | h1, h1 a, h2, h2 a, h3, h3 a { |
|---|
| 34 | font-weight: bold; |
|---|
| 35 | color: #ff9900; |
|---|
| 36 | margin: 1.3em 0 8px 0; |
|---|
| 37 | } |
|---|
| 38 | |
|---|
| 39 | h1 { |
|---|
| 40 | font-size: 1.3em; |
|---|
| 41 | } |
|---|
| 42 | |
|---|
| 43 | h2 { |
|---|
| 44 | font-size: 1.2em; |
|---|
| 45 | } |
|---|
| 46 | |
|---|
| 47 | h3 { |
|---|
| 48 | font-size: 1.1em; |
|---|
| 49 | } |
|---|
| 50 | |
|---|
| 51 | li { |
|---|
| 52 | line-height: 1.4; |
|---|
| 53 | } |
|---|
| 54 | |
|---|
| 55 | #copyright { |
|---|
| 56 | margin-top: 30px; |
|---|
| 57 | line-height: 1.5em; |
|---|
| 58 | text-align: center; |
|---|
| 59 | font-size: .8em; |
|---|
| 60 | color: #888888; |
|---|
| 61 | clear: both; |
|---|
| 62 | } |
|---|
| 63 | </style> |
|---|
| 64 | |
|---|
| 65 | </head> |
|---|
| 66 | |
|---|
| 67 | <body> |
|---|
| 68 | |
|---|
| 69 | <div id="xiphlogo"> |
|---|
| 70 | <a href="http://www.xiph.org/"><img src="fish_xiph_org.png" alt="Fish Logo and Xiph.org"/></a> |
|---|
| 71 | </div> |
|---|
| 72 | |
|---|
| 73 | <h1>Ogg logical and physical bitstream overview</h1> |
|---|
| 74 | |
|---|
| 75 | <h2>Ogg bitstreams</h2> |
|---|
| 76 | |
|---|
| 77 | <p>Ogg codecs use octet vectors of raw, compressed data |
|---|
| 78 | (<em>packets</em>). These compressed packets do not have any |
|---|
| 79 | high-level structure or boundary information; strung together, they |
|---|
| 80 | appear to be streams of random bytes with no landmarks.</p> |
|---|
| 81 | |
|---|
| 82 | <p>Raw packets may be used directly by transport mechanisms that provide |
|---|
| 83 | their own framing and packet-separation mechanisms (such as UDP |
|---|
| 84 | datagrams). For stream based storage (such as files) and transport |
|---|
| 85 | (such as TCP streams or pipes), Vorbis and other future Ogg codecs use |
|---|
| 86 | the Ogg bitstream format to provide framing/sync, sync recapture |
|---|
| 87 | after error, landmarks during seeking, and enough information to |
|---|
| 88 | properly separate data back into packets at the original packet |
|---|
| 89 | boundaries without relying on decoding to find packet boundaries.</p> |
|---|
| 90 | |
|---|
| 91 | <h2>Logical and physical bitstreams</h2> |
|---|
| 92 | |
|---|
| 93 | <p>Raw packets are grouped and encoded into contiguous pages of |
|---|
| 94 | structured bitstream data called <em>logical bitstreams</em>. A |
|---|
| 95 | logical bitstream consists of pages, in order, belonging to a single |
|---|
| 96 | codec instance. Each page is a self contained entity (although it is |
|---|
| 97 | possible that a packet may be split and encoded across one or more |
|---|
| 98 | pages); that is, the page decode mechanism is designed to recognize, |
|---|
| 99 | verify and handle single pages at a time from the overall bitstream.</p> |
|---|
| 100 | |
|---|
| 101 | <p>Multiple logical bitstreams can be combined (with restrictions) into a |
|---|
| 102 | single <em>physical bitstream</em>. A physical bitstream consists of |
|---|
| 103 | multiple logical bitstreams multiplexed at the page level and may |
|---|
| 104 | include a 'meta-header' at the beginning of the multiplexed logical |
|---|
| 105 | stream that serves as identification magic. Whole pages are taken in |
|---|
| 106 | order from multiple logical bitstreams and combined into a single |
|---|
| 107 | physical stream of pages. The decoder reconstructs the original |
|---|
| 108 | logical bitstreams from the physical bitstream by taking the pages in |
|---|
| 109 | order from the physical bitstream and redirecting them into the |
|---|
| 110 | appropriate logical decoding entity. The simplest physical bitstream |
|---|
| 111 | is a single, unmultiplexed logical bitstream with no meta-header; this |
|---|
| 112 | is referred to as a 'degenerate stream'.</p> |
|---|
| 113 | |
|---|
| 114 | <p><a href="framing.html">Ogg Logical Bitstream Framing</a> discusses |
|---|
| 115 | the page format of an Ogg bitstream, the packet coding process |
|---|
| 116 | and logical bitstreams in detail. The remainder of this document |
|---|
| 117 | specifies requirements for constructing finished, physical Ogg |
|---|
| 118 | bitstreams.</p> |
|---|
| 119 | |
|---|
| 120 | <h2>Mapping Restrictions</h2> |
|---|
| 121 | |
|---|
| 122 | <p>Logical bitstreams may not be mapped/multiplexed into physical |
|---|
| 123 | bitstreams without restriction. Here we discuss design restrictions |
|---|
| 124 | on Ogg physical bitstreams in general, mostly to introduce |
|---|
| 125 | design rationale. Each 'media' format defines its own (generally more |
|---|
| 126 | restrictive) mapping. An 'Ogg Vorbis Audio Bitstream', for example, has a |
|---|
| 127 | specific physical bitstream structure. |
|---|
| 128 | An 'Ogg A/V' bitstream (not currently specified) will also mandate a |
|---|
| 129 | specific, restricted physical bitstream format.</p> |
|---|
| 130 | |
|---|
| 131 | <h3>additional end-to-end structure</h3> |
|---|
| 132 | |
|---|
| 133 | <p>The <a href="framing.html">framing specification</a> defines |
|---|
| 134 | 'beginning of stream' and 'end of stream' page markers via a header |
|---|
| 135 | flag (it is possible for a stream to consist of a single page). A |
|---|
| 136 | stream always consists of an integer number of pages, an easy |
|---|
| 137 | requirement given the variable size nature of pages.</p> |
|---|
| 138 | |
|---|
| 139 | <p>In addition to the header flag marking the first and last pages of a |
|---|
| 140 | logical bitstream, the first page of an Ogg bitstream obeys |
|---|
| 141 | additional restrictions. Each individual media mapping specifies its |
|---|
| 142 | own implementation details regarding these restrictions.</p> |
|---|
| 143 | |
|---|
| 144 | <p>The first page of a logical Ogg bitstream consists of a single, |
|---|
| 145 | small 'initial header' packet that includes sufficient information to |
|---|
| 146 | identify the exact CODEC type and media requirements of the logical |
|---|
| 147 | bitstream. The intent of this restriction is to simplify identifying |
|---|
| 148 | the bitstream type and content; for a given media type (or across all |
|---|
| 149 | Ogg media types) we can know that we only need a small, fixed |
|---|
| 150 | amount of data to uniquely identify the bitstream type.</p> |
|---|
| 151 | |
|---|
| 152 | <p>As an example, Ogg Vorbis places the name and revision of the Vorbis |
|---|
| 153 | CODEC, the audio rate and the audio quality into this initial header, |
|---|
| 154 | thus simplifying vastly the certain identification of an Ogg Vorbis |
|---|
| 155 | audio bitstream.</p> |
|---|
| 156 | |
|---|
| 157 | <h3>sequential multiplexing (chaining)</h3> |
|---|
| 158 | |
|---|
| 159 | <p>The simplest form of logical bitstream multiplexing is concatenation |
|---|
| 160 | (<em>chaining</em>). Complete logical bitstreams are strung |
|---|
| 161 | one-after-another in order. The bitstreams do not overlap; the final |
|---|
| 162 | page of a given logical bitstream is immediately followed by the |
|---|
| 163 | initial page of the next. Chaining is the only logical->physical |
|---|
| 164 | mapping allowed by Ogg Vorbis.</p> |
|---|
| 165 | |
|---|
| 166 | <p>Each chained logical bitstream must have a unique serial number within |
|---|
| 167 | the scope of the physical bitstream.</p> |
|---|
| 168 | |
|---|
| 169 | <h3>concurrent multiplexing (grouping)</h3> |
|---|
| 170 | |
|---|
| 171 | <p>Logical bitstreams may also be multiplexed 'in parallel' |
|---|
| 172 | (<em>grouped</em>). An example of grouping would be to allow |
|---|
| 173 | streaming of separate audio and video streams, using different codecs |
|---|
| 174 | and different logical bitstreams, in the same physical bitstream. |
|---|
| 175 | Whole pages from multiple logical bitstreams are mixed together.</p> |
|---|
| 176 | |
|---|
| 177 | <p>The initial pages of each logical bitstream must appear first; the |
|---|
| 178 | media mapping specifies the order of the initial pages. For example, |
|---|
| 179 | Ogg A/V will eventually specify an Ogg video bitstream with |
|---|
| 180 | audio. The mapping may specify that the physical bitstream must begin |
|---|
| 181 | with the initial page of a logical video bitstream, followed by the |
|---|
| 182 | initial page of an audio stream. Unlike initial pages, terminal pages |
|---|
| 183 | for the logical bitstreams need not all occur contiguously (although a |
|---|
| 184 | specific media mapping may require this; it is not mandated by the |
|---|
| 185 | generic Ogg stream spec). Terminal pages may be 'nil' pages, |
|---|
| 186 | that is, pages containing no content but simply a page header with |
|---|
| 187 | position information and the 'last page of bitstream' flag set in the |
|---|
| 188 | page header.</p> |
|---|
| 189 | |
|---|
| 190 | <p>Each grouped bitstream must have a unique serial number within the |
|---|
| 191 | scope of the physical bitstream.</p> |
|---|
| 192 | |
|---|
| 193 | <h3>sequential and concurrent multiplexing</h3> |
|---|
| 194 | |
|---|
| 195 | <p>Groups of concurrently multiplexed bitstreams may be chained |
|---|
| 196 | consecutively. Such a physical bitstream obeys all the rules of both |
|---|
| 197 | grouped and chained multiplexed streams; the groups, when unchained , |
|---|
| 198 | must stand on their own as a valid concurrently multiplexed |
|---|
| 199 | bitstream.</p> |
|---|
| 200 | |
|---|
| 201 | <h3>multiplexing example</h3> |
|---|
| 202 | |
|---|
| 203 | <p>Below, we present an example of a grouped and chained bitstream:</p> |
|---|
| 204 | |
|---|
| 205 | <p><img src="stream.png" alt="stream"/></p> |
|---|
| 206 | |
|---|
| 207 | <p>In this example, we see pages from five total logical bitstreams |
|---|
| 208 | multiplexed into a physical bitstream. Note the following |
|---|
| 209 | characteristics:</p> |
|---|
| 210 | |
|---|
| 211 | <ol> |
|---|
| 212 | <li>Grouped bitstreams begin together; all of the initial pages |
|---|
| 213 | must appear before any data pages. When concurrently multiplexed |
|---|
| 214 | groups are chained, the new group does not begin until all the |
|---|
| 215 | bitstreams in the previous group have terminated.</li> |
|---|
| 216 | |
|---|
| 217 | <li>The pages of concurrently multiplexed bitstreams need not conform |
|---|
| 218 | to a regular order; the only requirement is that page <tt>n</tt> of a |
|---|
| 219 | logical bitstream follow page <tt>n-1</tt> in the physical bitstream. |
|---|
| 220 | There are no restrictions on intervening pages belonging to other |
|---|
| 221 | logical bitstreams. (Tying page appearance to bitrate demands is one |
|---|
| 222 | logical strategy, ie, the page appears at the chronological point |
|---|
| 223 | where decode requires more information).</li> |
|---|
| 224 | </ol> |
|---|
| 225 | |
|---|
| 226 | <div id="copyright"> |
|---|
| 227 | The Xiph Fish Logo is a |
|---|
| 228 | trademark (™) of Xiph.Org.<br/> |
|---|
| 229 | |
|---|
| 230 | These pages © 1994 - 2005 Xiph.Org. All rights reserved. |
|---|
| 231 | </div> |
|---|
| 232 | |
|---|
| 233 | </body> |
|---|
| 234 | </html> |
|---|
