-<!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 bitstream framing</h1>\r
-\r
-<h2>Ogg bitstreams</h2>\r
-\r
-<p>The Ogg transport bitstream is designed to provide framing, error\r
-protection and seeking structure for higher-level codec streams that\r
-consist of raw, unencapsulated data packets, such as the Vorbis audio\r
-codec or Tarkin video codec.</p>\r
-\r
-<h2>Application example: Vorbis</h2>\r
-\r
-<p>Vorbis encodes short-time blocks of PCM data into raw packets of\r
-bit-packed data. These raw packets may be used directly by transport\r
-mechanisms that provide their own framing and packet-separation\r
-mechanisms (such as UDP datagrams). For stream based storage (such as\r
-files) and transport (such as TCP streams or pipes), Vorbis uses the\r
-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>Design constraints for Ogg bitstreams</h2>\r
-\r
-<ol>\r
-<li>True streaming; we must not need to seek to build a 100%\r
- complete bitstream.</li>\r
-<li>Use no more than approximately 1-2% of bitstream bandwidth for\r
- packet boundary marking, high-level framing, sync and seeking.</li>\r
-<li>Specification of absolute position within the original sample\r
- stream.</li>\r
-<li>Simple mechanism to ease limited editing, such as a simplified\r
- concatenation mechanism.</li>\r
-<li>Detection of corruption, recapture after error and direct, random\r
- access to data at arbitrary positions in the bitstream.</li>\r
-</ol>\r
-\r
-<h2>Logical and Physical Bitstreams</h2>\r
-\r
-<p>A <em>logical</em> Ogg bitstream is a contiguous stream of\r
-sequential pages belonging only to the logical bitstream. A\r
-<em>physical</em> Ogg bitstream is constructed from one or more\r
-than one logical Ogg bitstream (the simplest physical bitstream\r
-is simply a single logical bitstream). We describe below the exact\r
-formatting of an Ogg logical bitstream. Combining logical\r
-bitstreams into more complex physical bitstreams is described in the\r
-<a href="oggstream.html">Ogg bitstream overview</a>. The exact\r
-mapping of raw Vorbis packets into a valid Ogg Vorbis physical\r
-bitstream is described in <a href="vorbis-stream.html">Vorbis\r
-bitstream mapping</a>.</p>\r
-\r
-<h2>Bitstream structure</h2>\r
-\r
-<p>An Ogg stream is structured by dividing incoming packets into\r
-segments of up to 255 bytes and then wrapping a group of contiguous\r
-packet segments into a variable length page preceded by a page\r
-header. Both the header size and page size are variable; the page\r
-header contains sizing information and checksum data to determine\r
-header/page size and data integrity.</p>\r
-\r
-<p>The bitstream is captured (or recaptured) by looking for the beginning\r
-of a page, specifically the capture pattern. Once the capture pattern\r
-is found, the decoder verifies page sync and integrity by computing\r
-and comparing the checksum. At that point, the decoder can extract the\r
-packets themselves.</p>\r
-\r
-<h3>Packet segmentation</h3>\r
-\r
-<p>Packets are logically divided into multiple segments before encoding\r
-into a page. Note that the segmentation and fragmentation process is a\r
-logical one; it's used to compute page header values and the original\r
-page data need not be disturbed, even when a packet spans page\r
-boundaries.</p>\r
-\r
-<p>The raw packet is logically divided into [n] 255 byte segments and a\r
-last fractional segment of < 255 bytes. A packet size may well\r
-consist only of the trailing fractional segment, and a fractional\r
-segment may be zero length. These values, called "lacing values" are\r
-then saved and placed into the header segment table.</p>\r
-\r
-<p>An example should make the basic concept clear:</p>\r
-\r
-<pre>\r
-<tt>\r
-raw packet:\r
- ___________________________________________\r
- |______________packet data__________________| 753 bytes\r
-\r
-lacing values for page header segment table: 255,255,243\r
-</tt>\r
-</pre>\r
-\r
-<p>We simply add the lacing values for the total size; the last lacing\r
-value for a packet is always the value that is less than 255. Note\r
-that this encoding both avoids imposing a maximum packet size as well\r
-as imposing minimum overhead on small packets (as opposed to, eg,\r
-simply using two bytes at the head of every packet and having a max\r
-packet size of 32k. Small packets (<255, the typical case) are\r
-penalized with twice the segmentation overhead). Using the lacing\r
-values as suggested, small packets see the minimum possible\r
-byte-aligned overheade (1 byte) and large packets, over 512 bytes or\r
-so, see a fairly constant ~.5% overhead on encoding space.</p>\r
-\r
-<p>Note that a lacing value of 255 implies that a second lacing value\r
-follows in the packet, and a value of < 255 marks the end of the\r
-packet after that many additional bytes. A packet of 255 bytes (or a\r
-multiple of 255 bytes) is terminated by a lacing value of 0:</p>\r
-\r
-<pre><tt>\r
-raw packet:\r
- _______________________________\r
- |________packet data____________| 255 bytes\r
-\r
-lacing values: 255, 0\r
-</tt></pre>\r
-\r
-<p>Note also that a 'nil' (zero length) packet is not an error; it\r
-consists of nothing more than a lacing value of zero in the header.</p>\r
-\r
-<h3>Packets spanning pages</h3>\r
-\r
-<p>Packets are not restricted to beginning and ending within a page,\r
-although individual segments are, by definition, required to do so.\r
-Packets are not restricted to a maximum size, although excessively\r
-large packets in the data stream are discouraged; the Ogg\r
-bitstream specification strongly recommends nominal page size of\r
-approximately 4-8kB (large packets are foreseen as being useful for\r
-initialization data at the beginning of a logical bitstream).</p>\r
-\r
-<p>After segmenting a packet, the encoder may decide not to place all the\r
-resulting segments into the current page; to do so, the encoder places\r
-the lacing values of the segments it wishes to belong to the current\r
-page into the current segment table, then finishes the page. The next\r
-page is begun with the first value in the segment table belonging to\r
-the next packet segment, thus continuing the packet (data in the\r
-packet body must also correspond properly to the lacing values in the\r
-spanned pages. The segment data in the first packet corresponding to\r
-the lacing values of the first page belong in that page; packet\r
-segments listed in the segment table of the following page must begin\r
-the page body of the subsequent page).</p>\r
-\r
-<p>The last mechanic to spanning a page boundary is to set the header\r
-flag in the new page to indicate that the first lacing value in the\r
-segment table continues rather than begins a packet; a header flag of\r
-0x01 is set to indicate a continued packet. Although mandatory, it\r
-is not actually algorithmically necessary; one could inspect the\r
-preceding segment table to determine if the packet is new or\r
-continued. Adding the information to the packet_header flag allows a\r
-simpler design (with no overhead) that needs only inspect the current\r
-page header after frame capture. This also allows faster error\r
-recovery in the event that the packet originates in a corrupt\r
-preceding page, implying that the previous page's segment table\r
-cannot be trusted.</p>\r
-\r
-<p>Note that a packet can span an arbitrary number of pages; the above\r
-spanning process is repeated for each spanned page boundary. Also a\r
-'zero termination' on a packet size that is an even multiple of 255\r
-must appear even if the lacing value appears in the next page as a\r
-zero-length continuation of the current packet. The header flag\r
-should be set to 0x01 to indicate that the packet spanned, even though\r
-the span is a nil case as far as data is concerned.</p>\r
-\r
-<p>The encoding looks odd, but is properly optimized for speed and the\r
-expected case of the majority of packets being between 50 and 200\r
-bytes (note that it is designed such that packets of wildly different\r
-sizes can be handled within the model; placing packet size\r
-restrictions on the encoder would have only slightly simplified design\r
-in page generation and increased overall encoder complexity).</p>\r
-\r
-<p>The main point behind tracking individual packets (and packet\r
-segments) is to allow more flexible encoding tricks that requiring\r
-explicit knowledge of packet size. An example is simple bandwidth\r
-limiting, implemented by simply truncating packets in the nominal case\r
-if the packet is arranged so that the least sensitive portion of the\r
-data comes last.</p>\r
-\r
-<h3>Page header</h3>\r
-\r
-<p>The headering mechanism is designed to avoid copying and re-assembly\r
-of the packet data (ie, making the packet segmentation process a\r
-logical one); the header can be generated directly from incoming\r
-packet data. The encoder buffers packet data until it finishes a\r
-complete page at which point it writes the header followed by the\r
-buffered packet segments.</p>\r
-\r
-<h4>capture_pattern</h4>\r
-\r
-<p>A header begins with a capture pattern that simplifies identifying\r
-pages; once the decoder has found the capture pattern it can do a more\r
-intensive job of verifying that it has in fact found a page boundary\r
-(as opposed to an inadvertent coincidence in the byte stream).</p>\r
-\r
-<pre><tt>\r
- byte value\r
-\r
- 0 0x4f 'O'\r
- 1 0x67 'g'\r
- 2 0x67 'g'\r
- 3 0x53 'S' \r
-</tt></pre>\r
-\r
-<h4>stream_structure_version</h4>\r
-\r
-<p>The capture pattern is followed by the stream structure revision:</p>\r
-\r
-<pre><tt>\r
- byte value\r
-\r
- 4 0x00\r
-</tt></pre>\r
- \r
-<h4>header_type_flag</h4>\r
- \r
-<p>The header type flag identifies this page's context in the bitstream:</p>\r
-\r
-<pre><tt>\r
- byte value\r
-\r
- 5 bitflags: 0x01: unset = fresh packet\r
- set = continued packet\r
- 0x02: unset = not first page of logical bitstream\r
- set = first page of logical bitstream (bos)\r
- 0x04: unset = not last page of logical bitstream\r
- set = last page of logical bitstream (eos)\r
-</tt></pre>\r
-\r
-<h4>absolute granule position</h4>\r
-\r
-<p>(This is packed in the same way the rest of Ogg data is packed; LSb\r
-of LSB first. Note that the 'position' data specifies a 'sample'\r
-number (eg, in a CD quality sample is four octets, 16 bits for left\r
-and 16 bits for right; in video it would likely be the frame number.\r
-It is up to the specific codec in use to define the semantic meaning\r
-of the granule position value). The position specified is the total\r
-samples encoded after including all packets finished on this page\r
-(packets begun on this page but continuing on to the next page do not\r
-count). The rationale here is that the position specified in the\r
-frame header of the last page tells how long the data coded by the\r
-bitstream is. A truncated stream will still return the proper number\r
-of samples that can be decoded fully.</p>\r
-\r
-<p>A special value of '-1' (in two's complement) indicates that no packets\r
-finish on this page.</p>\r
-\r
-<pre><tt>\r
- byte value\r
-\r
- 6 0xXX LSB\r
- 7 0xXX\r
- 8 0xXX\r
- 9 0xXX\r
- 10 0xXX\r
- 11 0xXX\r
- 12 0xXX\r
- 13 0xXX MSB\r
-</tt></pre>\r
-\r
-<h4>stream serial number</h4>\r
- \r
-<p>Ogg allows for separate logical bitstreams to be mixed at page\r
-granularity in a physical bitstream. The most common case would be\r
-sequential arrangement, but it is possible to interleave pages for\r
-two separate bitstreams to be decoded concurrently. The serial\r
-number is the means by which pages physical pages are associated with\r
-a particular logical stream. Each logical stream must have a unique\r
-serial number within a physical stream:</p>\r
-\r
-<pre><tt>\r
- byte value\r
-\r
- 14 0xXX LSB\r
- 15 0xXX\r
- 16 0xXX\r
- 17 0xXX MSB\r
-</tt></pre>\r
-\r
-<h4>page sequence no</h4>\r
-\r
-<p>Page counter; lets us know if a page is lost (useful where packets\r
-span page boundaries).</p>\r
-\r
-<pre><tt>\r
- byte value\r
-\r
- 18 0xXX LSB\r
- 19 0xXX\r
- 20 0xXX\r
- 21 0xXX MSB\r
-</tt></pre>\r
-\r
-<h4>page checksum</h4>\r
- \r
-<p>32 bit CRC value (direct algorithm, initial val and final XOR = 0,\r
-generator polynomial=0x04c11db7). The value is computed over the\r
-entire header (with the CRC field in the header set to zero) and then\r
-continued over the page. The CRC field is then filled with the\r
-computed value.</p>\r
-\r
-<p>(A thorough discussion of CRC algorithms can be found in <a\r
-href="ftp://ftp.rocksoft.com/papers/crc_v3.txt">"A\r
-Painless Guide to CRC Error Detection Algorithms"</a> by Ross\r
-Williams <a\r
-href="mailto:ross@guest.adelaide.edu.au">ross@guest.adelaide.edu.au</a>.)</p>\r
-\r
-<pre><tt>\r
- byte value\r
-\r
- 22 0xXX LSB\r
- 23 0xXX\r
- 24 0xXX\r
- 25 0xXX MSB\r
-</tt></pre>\r
-\r
-<h4>page_segments</h4>\r
-\r
-<p>The number of segment entries to appear in the segment table. The\r
-maximum number of 255 segments (255 bytes each) sets the maximum\r
-possible physical page size at 65307 bytes or just under 64kB (thus\r
-we know that a header corrupted so as destroy sizing/alignment\r
-information will not cause a runaway bitstream. We'll read in the\r
-page according to the corrupted size information that's guaranteed to\r
-be a reasonable size regardless, notice the checksum mismatch, drop\r
-sync and then look for recapture).</p>\r
-\r
-<pre><tt>\r
- byte value\r
-\r
- 26 0x00-0xff (0-255)\r
-</tt></pre>\r
-\r
-<h4>segment_table (containing packet lacing values)</h4>\r
-\r
-<p>The lacing values for each packet segment physically appearing in\r
-this page are listed in contiguous order.</p>\r
-\r
-<pre><tt>\r
- byte value\r
-\r
- 27 0x00-0xff (0-255)\r
- [...]\r
- n 0x00-0xff (0-255, n=page_segments+26)\r
-</tt></pre>\r
-\r
-<p>Total page size is calculated directly from the known header size and\r
-lacing values in the segment table. Packet data segments follow\r
-immediately after the header.</p>\r
-\r
-<p>Page headers typically impose a flat .25-.5% space overhead assuming\r
-nominal ~8k page sizes. The segmentation table needed for exact\r
-packet recovery in the streaming layer adds approximately .5-1%\r
-nominal assuming expected encoder behavior in the 44.1kHz, 128kbps\r
-stereo encodings.</p>\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="http://www.xiph.org/"><img src="fish_xiph_org.png" alt="Fish Logo and Xiph.Org"/></a>
+</div>
+
+<h1>Ogg logical bitstream framing</h1>
+
+<h2>Ogg bitstreams</h2>
+
+<p>The Ogg transport bitstream is designed to provide framing, error
+protection and seeking structure for higher-level codec streams that
+consist of raw, unencapsulated data packets, such as the Vorbis audio
+codec or Theora video codec.</p>
+
+<h2>Application example: Vorbis</h2>
+
+<p>Vorbis encodes short-time blocks of PCM data into raw packets of
+bit-packed data. These 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 uses 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>Design constraints for Ogg bitstreams</h2>
+
+<ol>
+<li>True streaming; we must not need to seek to build a 100%
+ complete bitstream.</li>
+<li>Use no more than approximately 1-2% of bitstream bandwidth for
+ packet boundary marking, high-level framing, sync and seeking.</li>
+<li>Specification of absolute position within the original sample
+ stream.</li>
+<li>Simple mechanism to ease limited editing, such as a simplified
+ concatenation mechanism.</li>
+<li>Detection of corruption, recapture after error and direct, random
+ access to data at arbitrary positions in the bitstream.</li>
+</ol>
+
+<h2>Logical and Physical Bitstreams</h2>
+
+<p>A <em>logical</em> Ogg bitstream is a contiguous stream of
+sequential pages belonging only to the logical bitstream. A
+<em>physical</em> Ogg bitstream is constructed from one or more
+than one logical Ogg bitstream (the simplest physical bitstream
+is simply a single logical bitstream). We describe below the exact
+formatting of an Ogg logical bitstream. Combining logical
+bitstreams into more complex physical bitstreams is described in the
+<a href="oggstream.html">Ogg bitstream overview</a>. The exact
+mapping of raw Vorbis packets into a valid Ogg Vorbis physical
+bitstream is described in the Vorbis I Specification.</p>
+
+<h2>Bitstream structure</h2>
+
+<p>An Ogg stream is structured by dividing incoming packets into
+segments of up to 255 bytes and then wrapping a group of contiguous
+packet segments into a variable length page preceded by a page
+header. Both the header size and page size are variable; the page
+header contains sizing information and checksum data to determine
+header/page size and data integrity.</p>
+
+<p>The bitstream is captured (or recaptured) by looking for the beginning
+of a page, specifically the capture pattern. Once the capture pattern
+is found, the decoder verifies page sync and integrity by computing
+and comparing the checksum. At that point, the decoder can extract the
+packets themselves.</p>
+
+<h3>Packet segmentation</h3>
+
+<p>Packets are logically divided into multiple segments before encoding
+into a page. Note that the segmentation and fragmentation process is a
+logical one; it's used to compute page header values and the original
+page data need not be disturbed, even when a packet spans page
+boundaries.</p>
+
+<p>The raw packet is logically divided into [n] 255 byte segments and a
+last fractional segment of < 255 bytes. A packet size may well
+consist only of the trailing fractional segment, and a fractional
+segment may be zero length. These values, called "lacing values" are
+then saved and placed into the header segment table.</p>
+
+<p>An example should make the basic concept clear:</p>
+
+<pre>
+<tt>
+raw packet:
+ ___________________________________________
+ |______________packet data__________________| 753 bytes
+
+lacing values for page header segment table: 255,255,243
+</tt>
+</pre>
+
+<p>We simply add the lacing values for the total size; the last lacing
+value for a packet is always the value that is less than 255. Note
+that this encoding both avoids imposing a maximum packet size as well
+as imposing minimum overhead on small packets (as opposed to, eg,
+simply using two bytes at the head of every packet and having a max
+packet size of 32k. Small packets (<255, the typical case) are
+penalized with twice the segmentation overhead). Using the lacing
+values as suggested, small packets see the minimum possible
+byte-aligned overheade (1 byte) and large packets, over 512 bytes or
+so, see a fairly constant ~.5% overhead on encoding space.</p>
+
+<p>Note that a lacing value of 255 implies that a second lacing value
+follows in the packet, and a value of < 255 marks the end of the
+packet after that many additional bytes. A packet of 255 bytes (or a
+multiple of 255 bytes) is terminated by a lacing value of 0:</p>
+
+<pre><tt>
+raw packet:
+ _______________________________
+ |________packet data____________| 255 bytes
+
+lacing values: 255, 0
+</tt></pre>
+
+<p>Note also that a 'nil' (zero length) packet is not an error; it
+consists of nothing more than a lacing value of zero in the header.</p>
+
+<h3>Packets spanning pages</h3>
+
+<p>Packets are not restricted to beginning and ending within a page,
+although individual segments are, by definition, required to do so.
+Packets are not restricted to a maximum size, although excessively
+large packets in the data stream are discouraged; the Ogg
+bitstream specification strongly recommends nominal page size of
+approximately 4-8kB (large packets are foreseen as being useful for
+initialization data at the beginning of a logical bitstream).</p>
+
+<p>After segmenting a packet, the encoder may decide not to place all the
+resulting segments into the current page; to do so, the encoder places
+the lacing values of the segments it wishes to belong to the current
+page into the current segment table, then finishes the page. The next
+page is begun with the first value in the segment table belonging to
+the next packet segment, thus continuing the packet (data in the
+packet body must also correspond properly to the lacing values in the
+spanned pages. The segment data in the first packet corresponding to
+the lacing values of the first page belong in that page; packet
+segments listed in the segment table of the following page must begin
+the page body of the subsequent page).</p>
+
+<p>The last mechanic to spanning a page boundary is to set the header
+flag in the new page to indicate that the first lacing value in the
+segment table continues rather than begins a packet; a header flag of
+0x01 is set to indicate a continued packet. Although mandatory, it
+is not actually algorithmically necessary; one could inspect the
+preceding segment table to determine if the packet is new or
+continued. Adding the information to the packet_header flag allows a
+simpler design (with no overhead) that needs only inspect the current
+page header after frame capture. This also allows faster error
+recovery in the event that the packet originates in a corrupt
+preceding page, implying that the previous page's segment table
+cannot be trusted.</p>
+
+<p>Note that a packet can span an arbitrary number of pages; the above
+spanning process is repeated for each spanned page boundary. Also a
+'zero termination' on a packet size that is an even multiple of 255
+must appear even if the lacing value appears in the next page as a
+zero-length continuation of the current packet. The header flag
+should be set to 0x01 to indicate that the packet spanned, even though
+the span is a nil case as far as data is concerned.</p>
+
+<p>The encoding looks odd, but is properly optimized for speed and the
+expected case of the majority of packets being between 50 and 200
+bytes (note that it is designed such that packets of wildly different
+sizes can be handled within the model; placing packet size
+restrictions on the encoder would have only slightly simplified design
+in page generation and increased overall encoder complexity).</p>
+
+<p>The main point behind tracking individual packets (and packet
+segments) is to allow more flexible encoding tricks that requiring
+explicit knowledge of packet size. An example is simple bandwidth
+limiting, implemented by simply truncating packets in the nominal case
+if the packet is arranged so that the least sensitive portion of the
+data comes last.</p>
+
+<h3>Page header</h3>
+
+<p>The headering mechanism is designed to avoid copying and re-assembly
+of the packet data (ie, making the packet segmentation process a
+logical one); the header can be generated directly from incoming
+packet data. The encoder buffers packet data until it finishes a
+complete page at which point it writes the header followed by the
+buffered packet segments.</p>
+
+<h4>capture_pattern</h4>
+
+<p>A header begins with a capture pattern that simplifies identifying
+pages; once the decoder has found the capture pattern it can do a more
+intensive job of verifying that it has in fact found a page boundary
+(as opposed to an inadvertent coincidence in the byte stream).</p>
+
+<pre><tt>
+ byte value
+
+ 0 0x4f 'O'
+ 1 0x67 'g'
+ 2 0x67 'g'
+ 3 0x53 'S'
+</tt></pre>
+
+<h4>stream_structure_version</h4>
+
+<p>The capture pattern is followed by the stream structure revision:</p>
+
+<pre><tt>
+ byte value
+
+ 4 0x00
+</tt></pre>
+
+<h4>header_type_flag</h4>
+
+<p>The header type flag identifies this page's context in the bitstream:</p>
+
+<pre><tt>
+ byte value
+
+ 5 bitflags: 0x01: unset = fresh packet
+ set = continued packet
+ 0x02: unset = not first page of logical bitstream
+ set = first page of logical bitstream (bos)
+ 0x04: unset = not last page of logical bitstream
+ set = last page of logical bitstream (eos)
+</tt></pre>
+
+<h4>absolute granule position</h4>
+
+<p>(This is packed in the same way the rest of Ogg data is packed; LSb
+of LSB first. Note that the 'position' data specifies a 'sample'
+number (eg, in a CD quality sample is four octets, 16 bits for left
+and 16 bits for right; in video it would likely be the frame number.
+It is up to the specific codec in use to define the semantic meaning
+of the granule position value). The position specified is the total
+samples encoded after including all packets finished on this page
+(packets begun on this page but continuing on to the next page do not
+count). The rationale here is that the position specified in the
+frame header of the last page tells how long the data coded by the
+bitstream is. A truncated stream will still return the proper number
+of samples that can be decoded fully.</p>
+
+<p>A special value of '-1' (in two's complement) indicates that no packets
+finish on this page.</p>
+
+<pre><tt>
+ byte value
+
+ 6 0xXX LSB
+ 7 0xXX
+ 8 0xXX
+ 9 0xXX
+ 10 0xXX
+ 11 0xXX
+ 12 0xXX
+ 13 0xXX MSB
+</tt></pre>
+
+<h4>stream serial number</h4>
+
+<p>Ogg allows for separate logical bitstreams to be mixed at page
+granularity in a physical bitstream. The most common case would be
+sequential arrangement, but it is possible to interleave pages for
+two separate bitstreams to be decoded concurrently. The serial
+number is the means by which pages physical pages are associated with
+a particular logical stream. Each logical stream must have a unique
+serial number within a physical stream:</p>
+
+<pre><tt>
+ byte value
+
+ 14 0xXX LSB
+ 15 0xXX
+ 16 0xXX
+ 17 0xXX MSB
+</tt></pre>
+
+<h4>page sequence no</h4>
+
+<p>Page counter; lets us know if a page is lost (useful where packets
+span page boundaries).</p>
+
+<pre><tt>
+ byte value
+
+ 18 0xXX LSB
+ 19 0xXX
+ 20 0xXX
+ 21 0xXX MSB
+</tt></pre>
+
+<h4>page checksum</h4>
+
+<p>32 bit CRC value (direct algorithm, initial val and final XOR = 0,
+generator polynomial=0x04c11db7). The value is computed over the
+entire header (with the CRC field in the header set to zero) and then
+continued over the page. The CRC field is then filled with the
+computed value.</p>
+
+<p>(A thorough discussion of CRC algorithms can be found in <a
+href="http://www.ross.net/crc/download/crc_v3.txt">"A
+Painless Guide to CRC Error Detection Algorithms"</a> by Ross
+Williams <a href="mailto:ross@ross.net">ross@ross.net</a>.)</p>
+
+<pre><tt>
+ byte value
+
+ 22 0xXX LSB
+ 23 0xXX
+ 24 0xXX
+ 25 0xXX MSB
+</tt></pre>
+
+<h4>page_segments</h4>
+
+<p>The number of segment entries to appear in the segment table. The
+maximum number of 255 segments (255 bytes each) sets the maximum
+possible physical page size at 65307 bytes or just under 64kB (thus
+we know that a header corrupted so as destroy sizing/alignment
+information will not cause a runaway bitstream. We'll read in the
+page according to the corrupted size information that's guaranteed to
+be a reasonable size regardless, notice the checksum mismatch, drop
+sync and then look for recapture).</p>
+
+<pre><tt>
+ byte value
+
+ 26 0x00-0xff (0-255)
+</tt></pre>
+
+<h4>segment_table (containing packet lacing values)</h4>
+
+<p>The lacing values for each packet segment physically appearing in
+this page are listed in contiguous order.</p>
+
+<pre><tt>
+ byte value
+
+ 27 0x00-0xff (0-255)
+ [...]
+ n 0x00-0xff (0-255, n=page_segments+26)
+</tt></pre>
+
+<p>Total page size is calculated directly from the known header size and
+lacing values in the segment table. Packet data segments follow
+immediately after the header.</p>
+
+<p>Page headers typically impose a flat .25-.5% space overhead assuming
+nominal ~8k page sizes. The segmentation table needed for exact
+packet recovery in the streaming layer adds approximately .5-1%
+nominal assuming expected encoder behavior in the 44.1kHz, 128kbps
+stereo encodings.</p>
+
+<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