diff options
-rw-r--r-- | doc/vorbis-ogg.html | 164 |
1 files changed, 164 insertions, 0 deletions
diff --git a/doc/vorbis-ogg.html b/doc/vorbis-ogg.html new file mode 100644 index 00000000..3c28a185 --- /dev/null +++ b/doc/vorbis-ogg.html @@ -0,0 +1,164 @@ +<HTML><HEAD><TITLE>xiph.org: Ogg Vorbis documentation</TITLE> +<BODY bgcolor="#ffffff" text="#202020" link="#006666" vlink="#000000"> +<nobr><img src="white-ogg.png"><img src="vorbisword2.png"></nobr><p> + +<h1><font color=#000070> +Ogg Vorbis I format specification: embedding Vorbis into an Ogg stream +</font></h1> + +<em>Last update to this document: July 14, 2002</em><br> + +<h1>Overview</h1> + +This document describes using Ogg logical and physical transport +streams to encapsulate Vorbis compressed audio packet data into file +form.<p> + +_<a href="vorbis-spec-intro.html">Ogg Vorbis I format specification: +high-level description</a>_ provides an overview of the construction +of Vorbis audio packets.<p> The _<a href="oggstream.html">Ogg +bitstream overview</a>_ and <a href="framing.html">Ogg logical +bitstream and framing spec</a>_ provide detailed descriptions of Ogg +transport streams. This specification document assumes a working +knowledge of the concepts covered in these named backround +documents. Please read them first.<p> + + +<h2>Restrictions</h2> + +The Ogg/Vorbis I specification currently dictates that Ogg/Vorbis +streams use Ogg transport streams in degenerate, unmultiplexed +form only. That is: + +<ul> +<li>A meta-headerless Ogg file encapsulates the Vorbis I packets +<li>The Ogg stream may be chained, i.e. contain multiple, contigous logical streams (links). +<li>The Ogg stream must be unmultiplexed (only one stream, a Vorbis audio stream, per link) +</ul> + +This is not to say that it is not currently possible to multiplex +Vorbis with other media types into a multi-stream Ogg file. At the +time this document was written, Ogg was becoming a popular container +for low-bitrate movies consisting of DiVX video and Vorbis audio. +However, a 'Vorbis I audio file' is taken to imply Vorbis audio +existing alone within a degenerate Ogg stream. A compliant 'Vorbis +audio player' is not required to implement Ogg support beyond the +specific support of Vorbis within a degenrate ogg stream (naturally, +application authors are encouraged to support full multiplexed Ogg +handling). +<p> + +<h2>MIME type</h2> + +The correct MIME type of any Ogg file is <tt>application/x-ogg</tt>. +However, if a file is a Vorbis I audio file (which implies a +degenerate Ogg stream including only unmultiplexed Vorbis audio), the +mime type <tt>audio/x-vorbis</tt> is also allowed. + +<h1>Encapsulation</h1> + +Ogg encapsulation of a Vorbis packet stream is straightforward.<p> + +<ul> +<li>The first Vorbis packet [the indentification header], which +uniquely identifies a stream as Vorbis audio, is placed alone in the +first page of the logical Ogg stream. This results in a first Ogg +page of exactly 58 bytes at the very beginning of the logical stream.<p> + +<li>This first page is marked 'beginning of stream' in the page flags.<p> + +<li>The second and third vorbis packets [comment and setup +headers] may span one or more pages beginning on the second page of +the logical stream. However many pages they span, the third header +packet finishes the page on which it ends. The next [first audio] packet +must begin on a fresh page.<p> + +<li>The granule position of these first pages containing only headers is +zero.<p> + +<li>The first audio packet of the logical stream begins a fresh Ogg page.<p> + +<li>Packets are placed into ogg pages in order until the end of stream.<p> + +<li>The last page is marked 'end of stream' in the page flags.<p> + +<li>Vorbis packets may span page boundaries. <p> + +<li>The granule position of pages contining Vorbis audio is in units +of PCM audio samples (per channel; a stereo stream's granule position +does no increment at twice the speed of a mono stream).<p> + +<li>The granule position of a page represents the end PCM sample +position of the last packet <em>completed</em> on that page. A page +that is entirely spanned by a single packet (that completes on a +subsequent page) has no granule position, and the granule position is +set to '-1'.<p> + +<li>The granule (PCM) position of the first page need not indicate + that the stream started at position zero. Although the granule + position belongs to the last completed packet on the page and a + valid granule position must be positive, by + inference it may indicate that the PCM position of the beginning + of audio is positive or negative.<p> + + <ul> + <li>A positive starting value simply indicates that this stream begins at + some positive time offset, potentially within a larger + program. This is a common case when connecting to the middle + of broadcast stream.<p> <li>A negative value indicates that + output samples preceeding time zero should be discarded during + decoding; this technique is used to allow sample-granularity + editing of the stream start time of already-encoded Vorbis + streams. The number of samples to be discarded must not exceed + the overlap-add span of the first two audio packets.<p> + </uL> + In both of these cases in which the initial audio PCM starting + offset is nonzero, the second finished audio packet must flush the + page on which it appears and the third packet begin a fresh page. + This allows the decoder to always be able to perform PCM position + adjustments before needing to return any PCM data from synthesis, + resulting in correct positioning information without any aditional + seeking logic.<p> + + (Note however that failure to do so should, at worst, cause a + decoder implementation to return incorrect positioning information + for seeking operations at the very beginning of the stream.)<p> + +<li> A granule position on the final page in a stream that indicates +less audio data than the final packet would normally return is used to +end the stream on other than even frame boundaries. The difference +between the actual available data returned and the declared amount +indicates how many trailing samples to discard from the decoding +process.<p> +</ul> +<hr> +<a href="http://www.xiph.org/"> +<img src="white-xifish.png" align=left border=0> +</a> +<font size=-2 color=#505050> + +Ogg is a <a href="http://www.xiph.org">Xiph.org Foundation</a> effort +to protect essential tenets of Internet multimedia from corporate +hostage-taking; Open Source is the net's greatest tool to keep +everyone honest. See <a href="http://www.xiph.org/about.html">About +the Xiph.org Foundation</a> for details. +<p> + +Ogg Vorbis is the first Ogg audio CODEC. Anyone may freely use and +distribute the Ogg and Vorbis specification, whether in a private, +public or corporate capacity. However, the Xiph.org Foundation and +the Ogg project (xiph.org) reserve the right to set the Ogg Vorbis +specification and certify specification compliance.<p> + +Xiph.org's Vorbis software CODEC implementation is distributed under a +BSD-like license. This does not restrict third parties from +distributing independent implementations of Vorbis software under +other licenses.<p> + +Ogg, Vorbis, Xiph.org Foundation and their logos are trademarks (tm) +of the <a href="http://www.xiph.org/">Xiph.org Foundation</a>. These +pages are copyright (C) 1994-2002 Xiph.org Foundation. All rights +reserved.<p> + +</body> + |