doc/oggstream.html - platform/external/libvorbis - Git at Google

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 <html>
 <head>

 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15"/>
 <title>Ogg Vorbis Documentation</title>

 <style type="text/css">
 body {
   margin: 0 18px 0 18px;
   padding-bottom: 30px;
   font-family: Verdana, Arial, Helvetica, sans-serif;
   color: #333333;
   font-size: .8em;
 }

 a {
   color: #3366cc;
 }

 img {
   border: 0;
 }

 #xiphlogo {
   margin: 30px 0 16px 0;
 }

 #content p {
   line-height: 1.4;
 }

 h1, h1 a, h2, h2 a, h3, h3 a {
   font-weight: bold;
   color: #ff9900;
   margin: 1.3em 0 8px 0;
 }

 h1 {
   font-size: 1.3em;
 }

 h2 {
   font-size: 1.2em;
 }

 h3 {
   font-size: 1.1em;
 }

 li {
   line-height: 1.4;
 }

 #copyright {
   margin-top: 30px;
   line-height: 1.5em;
   text-align: center;
   font-size: .8em;
   color: #888888;
   clear: both;
 }
 </style>

 </head>

 <body>

 <div id="xiphlogo">
   <a href="http://www.xiph.org/"><img src="fish_xiph_org.png" alt="Fish Logo and Xiph.org"/></a>
 </div>

 <h1>Ogg logical and physical bitstream overview</h1>

 <h2>Ogg bitstreams</h2>

 <p>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>

 <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>

 <p>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>

 <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>

 <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>

 <p>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 'Ogg Vorbis Audio Bitstream', for example, has a
 specific physical bitstream structure.
 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>

 <p>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>

 <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>

 <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>

 <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>

 <p>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>

 <p>Each chained logical bitstream must have a unique serial number within
 the scope of the physical bitstream.</p>

 <h3>concurrent multiplexing (grouping)</h3>

 <p>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>

 <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>

 <p>Each grouped bitstream must have a unique serial number within the
 scope of the physical bitstream.</p>

 <h3>sequential and concurrent multiplexing</h3>

 <p>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>

 <p>Below, we present an example of a grouped and chained bitstream:</p>

 <p><img src="stream.png" alt="stream"/></p>

 <p>In this example, we see pages from five total logical bitstreams
 multiplexed into a physical bitstream. Note the following
 characteristics:</p>

 <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.</li>

 <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).</li>
 </ol>

 <div id="copyright">
   The Xiph Fish Logo is a
   trademark (&trade;) of Xiph.Org.<br/>

   These pages &copy; 1994 - 2005 Xiph.Org. All rights reserved.
 </div>

 </body>
 </html>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
	<html>
	<head>

	<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15"/>
	<title>Ogg Vorbis Documentation</title>

	<style type="text/css">
	body {
	margin: 0 18px 0 18px;
	padding-bottom: 30px;
	font-family: Verdana, Arial, Helvetica, sans-serif;
	color: #333333;
	font-size: .8em;
	}

	a {
	color: #3366cc;
	}

	img {
	border: 0;
	}

	#xiphlogo {
	margin: 30px 0 16px 0;
	}

	#content p {
	line-height: 1.4;
	}

	h1, h1 a, h2, h2 a, h3, h3 a {
	font-weight: bold;
	color: #ff9900;
	margin: 1.3em 0 8px 0;
	}

	h1 {
	font-size: 1.3em;
	}

	h2 {
	font-size: 1.2em;
	}

	h3 {
	font-size: 1.1em;
	}

	li {
	line-height: 1.4;
	}

	#copyright {
	margin-top: 30px;
	line-height: 1.5em;
	text-align: center;
	font-size: .8em;
	color: #888888;
	clear: both;
	}
	</style>

	</head>

	<body>

	<div id="xiphlogo">
	<a href="http://www.xiph.org/"><img src="fish_xiph_org.png" alt="Fish Logo and Xiph.org"/></a>
	</div>

	<h1>Ogg logical and physical bitstream overview</h1>

	<h2>Ogg bitstreams</h2>

	<p>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>

	<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>

	<p>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>

	<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>

	<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>

	<p>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 'Ogg Vorbis Audio Bitstream', for example, has a
	specific physical bitstream structure.
	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>

	<p>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>

	<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>

	<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>

	<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>

	<p>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>

	<p>Each chained logical bitstream must have a unique serial number within
	the scope of the physical bitstream.</p>

	<h3>concurrent multiplexing (grouping)</h3>

	<p>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>

	<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>

	<p>Each grouped bitstream must have a unique serial number within the
	scope of the physical bitstream.</p>

	<h3>sequential and concurrent multiplexing</h3>

	<p>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>

	<p>Below, we present an example of a grouped and chained bitstream:</p>

	<p><img src="stream.png" alt="stream"/></p>

	<p>In this example, we see pages from five total logical bitstreams
	multiplexed into a physical bitstream. Note the following
	characteristics:</p>

	<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.</li>

	<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).</li>
	</ol>

	<div id="copyright">
	The Xiph Fish Logo is a
	trademark (™) of Xiph.Org.<br/>

	These pages © 1994 - 2005 Xiph.Org. All rights reserved.
	</div>

	</body>
	</html>