diff options
| author | Jack Moffitt <jack@xiph.org> | 2000-09-03 05:54:26 +0000 |
|---|---|---|
| committer | Jack Moffitt <jack@xiph.org> | 2000-09-03 05:54:26 +0000 |
| commit | f49beca1438135e247e96b3feef7b0750c9340d9 (patch) | |
| tree | 1d5ac0d04a81d4954932d3073ea096bd576abf2c /doc/oggstream.html | |
| download | ogg-git-f49beca1438135e247e96b3feef7b0750c9340d9.tar.gz | |
Initial revision
svn path=/trunk/ogg/; revision=618
Diffstat (limited to 'doc/oggstream.html')
| -rw-r--r-- | doc/oggstream.html | 192 |
1 files changed, 192 insertions, 0 deletions
diff --git a/doc/oggstream.html b/doc/oggstream.html new file mode 100644 index 0000000..46a221c --- /dev/null +++ b/doc/oggstream.html @@ -0,0 +1,192 @@ +<HTML><HEAD><TITLE>xiph.org: Ogg Vorbis documentation</TITLE> +<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000"> +<nobr><a href="vorbis.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 18, 1999</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-seperation 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 seperate 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 restricctions) into +a single <em>physical bitstream</em>. A physical bitstream consists +of multiple logical bitstreams multiplexed at the page level. 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 fromt he physical bitstream and redirecting them into +the appropriate logical decoding entitiy. The simplest physical +bitstream is a single, unmultiplexed logical bitstream. <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-stream.html">Ogg Vorbis +Audio Bitstream</a>', for example, has a <a +href="vorbis-stream.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 seperate audio and video streams, using differnt 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 appearence 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">Xiphophorus</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 +Xiphophorus</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, +Xiphophorus and the Ogg project (xiph.org) reserve the right to set +the Ogg/Vorbis specification and certify specification compliance.<p> + +Xiphophorus's Vorbis software CODEC implementation is distributed +under the Lesser/Library GNU Public License. This does not restrict +third parties from distributing independent implementations of Vorbis +software under other licenses.<p> + +OggSquish, Vorbis, Xiphophorus and their logos are trademarks (tm) of +<a href="http://www.xiph.org/">Xiphophorus</a>. These pages are +copyright (C) 1994-2000 Xiphophorus. All rights reserved.<p> + +</body> + + |