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