doc/oggstream.html

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