diff options
| author | Aki <please@ignore.pl> | 2024-03-03 12:51:03 +0100 |
|---|---|---|
| committer | Aki <please@ignore.pl> | 2024-03-03 12:51:03 +0100 |
| commit | 8e94244f86e657e4113e35438e59cf5771882b25 (patch) | |
| tree | b4a84a732f7f29abc8b6a129f51e406c101e7f77 /contrib/vorbis/doc/oggstream.html | |
| parent | dad0e8562c8e5994fcf2ebedac5a7ec920297d1f (diff) | |
| download | starshatter-8e94244f86e657e4113e35438e59cf5771882b25.zip starshatter-8e94244f86e657e4113e35438e59cf5771882b25.tar.gz starshatter-8e94244f86e657e4113e35438e59cf5771882b25.tar.bz2 | |
libogg and libvorbis are no longer part of this source tree
Diffstat (limited to 'contrib/vorbis/doc/oggstream.html')
| -rw-r--r-- | contrib/vorbis/doc/oggstream.html | 234 |
1 files changed, 0 insertions, 234 deletions
diff --git a/contrib/vorbis/doc/oggstream.html b/contrib/vorbis/doc/oggstream.html deleted file mode 100644 index 6952ed9..0000000 --- a/contrib/vorbis/doc/oggstream.html +++ /dev/null @@ -1,234 +0,0 @@ -<!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> |