197 lines
8.9 KiB
HTML
197 lines
8.9 KiB
HTML
<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>
|
|
|
|
|