The Vorbis->Ogg encapsulation spec
authorMonty <xiphmont@xiph.org>
Sun, 14 Jul 2002 08:49:24 +0000 (08:49 +0000)
committerMonty <xiphmont@xiph.org>
Sun, 14 Jul 2002 08:49:24 +0000 (08:49 +0000)
svn path=/trunk/vorbis/; revision=3631

doc/vorbis-ogg.html [new file with mode: 0644]

diff --git a/doc/vorbis-ogg.html b/doc/vorbis-ogg.html
new file mode 100644 (file)
index 0000000..3c28a18
--- /dev/null
@@ -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>
+