diff options
author | Aki <please@ignore.pl> | 2021-10-01 23:46:47 +0200 |
---|---|---|
committer | Aki <please@ignore.pl> | 2021-10-01 23:46:47 +0200 |
commit | ddd76aa4e1571c8d5965709db5c3cd47a89c9a38 (patch) | |
tree | 4e07bfaebede6531a70984fdebc855bca52f394a /vorbis/doc/oggstream.html | |
parent | 3a507e08b1d4e5970b27401a7e6517570d529400 (diff) | |
parent | c2d2c3551501110fddd78674d5435bfaa70382a3 (diff) | |
download | starshatter-ddd76aa4e1571c8d5965709db5c3cd47a89c9a38.zip starshatter-ddd76aa4e1571c8d5965709db5c3cd47a89c9a38.tar.gz starshatter-ddd76aa4e1571c8d5965709db5c3cd47a89c9a38.tar.bz2 |
Project is now built with CMake
Diffstat (limited to 'vorbis/doc/oggstream.html')
-rw-r--r-- | vorbis/doc/oggstream.html | 234 |
1 files changed, 234 insertions, 0 deletions
diff --git a/vorbis/doc/oggstream.html b/vorbis/doc/oggstream.html new file mode 100644 index 0000000..6952ed9 --- /dev/null +++ b/vorbis/doc/oggstream.html @@ -0,0 +1,234 @@ +<!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> |