-<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">\r
-<html>\r
-<head>\r
-\r
-<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-15"/>\r
-<title>Ogg Vorbis Documentation</title>\r
-\r
-<style type="text/css">\r
-body {\r
- margin: 0 18px 0 18px;\r
- padding-bottom: 30px;\r
- font-family: Verdana, Arial, Helvetica, sans-serif;\r
- color: #333333;\r
- font-size: .8em;\r
-}\r
-\r
-a {\r
- color: #3366cc;\r
-}\r
-\r
-img {\r
- border: 0;\r
-}\r
-\r
-#xiphlogo {\r
- margin: 30px 0 16px 0;\r
-}\r
-\r
-#content p {\r
- line-height: 1.4;\r
-}\r
-\r
-h1, h1 a, h2, h2 a, h3, h3 a {\r
- font-weight: bold;\r
- color: #ff9900;\r
- margin: 1.3em 0 8px 0;\r
-}\r
-\r
-h1 {\r
- font-size: 1.3em;\r
-}\r
-\r
-h2 {\r
- font-size: 1.2em;\r
-}\r
-\r
-h3 {\r
- font-size: 1.1em;\r
-}\r
-\r
-li {\r
- line-height: 1.4;\r
-}\r
-\r
-#copyright {\r
- margin-top: 30px;\r
- line-height: 1.5em;\r
- text-align: center;\r
- font-size: .8em;\r
- color: #888888;\r
- clear: both;\r
-}\r
-</style>\r
-\r
-</head>\r
-\r
-<body>\r
-\r
-<div id="xiphlogo">\r
- <a href="http://www.xiph.org/"><img src="fish_xiph_org.png" alt="Fish Logo and Xiph.org"/></a>\r
-</div>\r
-\r
-<h1>Ogg logical and physical bitstream overview</h1>\r
-\r
-<h2>Ogg bitstreams</h2>\r
-\r
-<p>Ogg codecs use octet vectors of raw, compressed data\r
-(<em>packets</em>). These compressed packets do not have any\r
-high-level structure or boundary information; strung together, they\r
-appear to be streams of random bytes with no landmarks.</p>\r
-\r
-<p>Raw packets may be used directly by transport mechanisms that provide\r
-their own framing and packet-separation mechanisms (such as UDP\r
-datagrams). For stream based storage (such as files) and transport\r
-(such as TCP streams or pipes), Vorbis and other future Ogg codecs use\r
-the Ogg bitstream format to provide framing/sync, sync recapture\r
-after error, landmarks during seeking, and enough information to\r
-properly separate data back into packets at the original packet\r
-boundaries without relying on decoding to find packet boundaries.</p>\r
-\r
-<h2>Logical and physical bitstreams</h2>\r
-\r
-<p>Raw packets are grouped and encoded into contiguous pages of\r
-structured bitstream data called <em>logical bitstreams</em>. A\r
-logical bitstream consists of pages, in order, belonging to a single\r
-codec instance. Each page is a self contained entity (although it is\r
-possible that a packet may be split and encoded across one or more\r
-pages); that is, the page decode mechanism is designed to recognize,\r
-verify and handle single pages at a time from the overall bitstream.</p>\r
-\r
-<p>Multiple logical bitstreams can be combined (with restrictions) into a\r
-single <em>physical bitstream</em>. A physical bitstream consists of\r
-multiple logical bitstreams multiplexed at the page level and may\r
-include a 'meta-header' at the beginning of the multiplexed logical\r
-stream that serves as identification magic. Whole pages are taken in\r
-order from multiple logical bitstreams and combined into a single\r
-physical stream of pages. The decoder reconstructs the original\r
-logical bitstreams from the physical bitstream by taking the pages in\r
-order from the physical bitstream and redirecting them into the\r
-appropriate logical decoding entity. The simplest physical bitstream\r
-is a single, unmultiplexed logical bitstream with no meta-header; this\r
-is referred to as a 'degenerate stream'.</p>\r
-\r
-<p><a href="framing.html">Ogg Logical Bitstream Framing</a> discusses\r
-the page format of an Ogg bitstream, the packet coding process\r
-and logical bitstreams in detail. The remainder of this document\r
-specifies requirements for constructing finished, physical Ogg\r
-bitstreams.</p>\r
-\r
-<h2>Mapping Restrictions</h2>\r
-\r
-<p>Logical bitstreams may not be mapped/multiplexed into physical\r
-bitstreams without restriction. Here we discuss design restrictions\r
-on Ogg physical bitstreams in general, mostly to introduce\r
-design rationale. Each 'media' format defines its own (generally more\r
-restrictive) mapping. An 'Ogg Vorbis Audio Bitstream', for example, has a\r
-specific physical bitstream structure.\r
-An 'Ogg A/V' bitstream (not currently specified) will also mandate a\r
-specific, restricted physical bitstream format.</p>\r
-\r
-<h3>additional end-to-end structure</h3>\r
-\r
-<p>The <a href="framing.html">framing specification</a> defines\r
-'beginning of stream' and 'end of stream' page markers via a header\r
-flag (it is possible for a stream to consist of a single page). A\r
-stream always consists of an integer number of pages, an easy\r
-requirement given the variable size nature of pages.</p>\r
-\r
-<p>In addition to the header flag marking the first and last pages of a\r
-logical bitstream, the first page of an Ogg bitstream obeys\r
-additional restrictions. Each individual media mapping specifies its\r
-own implementation details regarding these restrictions.</p>\r
-\r
-<p>The first page of a logical Ogg bitstream consists of a single,\r
-small 'initial header' packet that includes sufficient information to\r
-identify the exact CODEC type and media requirements of the logical\r
-bitstream. The intent of this restriction is to simplify identifying\r
-the bitstream type and content; for a given media type (or across all\r
-Ogg media types) we can know that we only need a small, fixed\r
-amount of data to uniquely identify the bitstream type.</p>\r
-\r
-<p>As an example, Ogg Vorbis places the name and revision of the Vorbis\r
-CODEC, the audio rate and the audio quality into this initial header,\r
-thus simplifying vastly the certain identification of an Ogg Vorbis\r
-audio bitstream.</p>\r
-\r
-<h3>sequential multiplexing (chaining)</h3>\r
-\r
-<p>The simplest form of logical bitstream multiplexing is concatenation\r
-(<em>chaining</em>). Complete logical bitstreams are strung\r
-one-after-another in order. The bitstreams do not overlap; the final\r
-page of a given logical bitstream is immediately followed by the\r
-initial page of the next. Chaining is the only logical->physical\r
-mapping allowed by Ogg Vorbis.</p>\r
-\r
-<p>Each chained logical bitstream must have a unique serial number within\r
-the scope of the physical bitstream.</p>\r
-\r
-<h3>concurrent multiplexing (grouping)</h3>\r
-\r
-<p>Logical bitstreams may also be multiplexed 'in parallel'\r
-(<em>grouped</em>). An example of grouping would be to allow\r
-streaming of separate audio and video streams, using different codecs\r
-and different logical bitstreams, in the same physical bitstream.\r
-Whole pages from multiple logical bitstreams are mixed together.</p>\r
-\r
-<p>The initial pages of each logical bitstream must appear first; the\r
-media mapping specifies the order of the initial pages. For example,\r
-Ogg A/V will eventually specify an Ogg video bitstream with\r
-audio. The mapping may specify that the physical bitstream must begin\r
-with the initial page of a logical video bitstream, followed by the\r
-initial page of an audio stream. Unlike initial pages, terminal pages\r
-for the logical bitstreams need not all occur contiguously (although a\r
-specific media mapping may require this; it is not mandated by the\r
-generic Ogg stream spec). Terminal pages may be 'nil' pages,\r
-that is, pages containing no content but simply a page header with\r
-position information and the 'last page of bitstream' flag set in the\r
-page header.</p>\r
-\r
-<p>Each grouped bitstream must have a unique serial number within the\r
-scope of the physical bitstream.</p>\r
-\r
-<h3>sequential and concurrent multiplexing</h3>\r
-\r
-<p>Groups of concurrently multiplexed bitstreams may be chained\r
-consecutively. Such a physical bitstream obeys all the rules of both\r
-grouped and chained multiplexed streams; the groups, when unchained ,\r
-must stand on their own as a valid concurrently multiplexed\r
-bitstream.</p>\r
-\r
-<h3>multiplexing example</h3>\r
-\r
-<p>Below, we present an example of a grouped and chained bitstream:</p>\r
-\r
-<p><img src="stream.png" alt="stream"/></p>\r
-\r
-<p>In this example, we see pages from five total logical bitstreams\r
-multiplexed into a physical bitstream. Note the following\r
-characteristics:</p>\r
-\r
-<ol>\r
-<li>Grouped bitstreams begin together; all of the initial pages\r
-must appear before any data pages. When concurrently multiplexed\r
-groups are chained, the new group does not begin until all the\r
-bitstreams in the previous group have terminated.</li>\r
-\r
-<li>The pages of concurrently multiplexed bitstreams need not conform\r
-to a regular order; the only requirement is that page <tt>n</tt> of a\r
-logical bitstream follow page <tt>n-1</tt> in the physical bitstream.\r
-There are no restrictions on intervening pages belonging to other\r
-logical bitstreams. (Tying page appearance to bitrate demands is one\r
-logical strategy, ie, the page appears at the chronological point\r
-where decode requires more information).</li>\r
-</ol>\r
-\r
-<div id="copyright">\r
- The Xiph Fish Logo is a\r
- trademark (™) of Xiph.Org.<br/>\r
-\r
- These pages © 1994 - 2005 Xiph.Org. All rights reserved.\r
-</div>\r
-\r
-</body>\r
-</html>\r
+<!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="https://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>
projects / platform / upstream / libvorbis.git / blobdiff