diff options
author | Monty <xiphmont@xiph.org> | 2002-07-14 08:12:09 +0000 |
---|---|---|
committer | Monty <xiphmont@xiph.org> | 2002-07-14 08:12:09 +0000 |
commit | 72a2d56597ef4261c8be504f559b7be03be2c408 (patch) | |
tree | d75f92f7baeab47852ddb46737569e5566b76c74 /doc | |
parent | 181344643797087fe72c07ddeede88d543114df6 (diff) | |
download | ogg-git-72a2d56597ef4261c8be504f559b7be03be2c408.tar.gz |
Updates and spelling corrections
svn path=/trunk/ogg/; revision=3630
Diffstat (limited to 'doc')
-rw-r--r-- | doc/framing.html | 51 | ||||
-rw-r--r-- | doc/oggstream.html | 35 |
2 files changed, 48 insertions, 38 deletions
diff --git a/doc/framing.html b/doc/framing.html index 50bba5e..9ea9795 100644 --- a/doc/framing.html +++ b/doc/framing.html @@ -7,18 +7,24 @@ src="vorbisword2.png" border=0></a></nobr><p> Ogg logical bitstream framing </font></h1> -<em>Last update to this document: February 18, 2001</em><br> +<em>Last update to this document: July 14, 2002</em><br> <h2>Ogg bitstreams</h2> +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 Tarkin video codec. + +<h2>Application example: Vorbis</h2> 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-seperation +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 seperate data back into packets at the original packet +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> @@ -57,7 +63,7 @@ bitstream mapping</a>. 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 preceeded by a page +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> @@ -123,12 +129,12 @@ consists of nothing more than a lacing value of zero in the header.<p> <h3>Packets spanning pages</h3> -Packets are not resticted to beginning and ending within a page, +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 forseen as being useful for +approximately 4-8kB (large packets are foreseen as being useful for initialization data at the beginning of a logical bitstream).<p> After segmenting a packet, the encoder may decide not to place all the @@ -148,12 +154,12 @@ 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 -preceeding segment table to determine if the packet is new or +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 -preceeding page, implying that the previous page's segment table +preceding page, implying that the previous page's segment table cannot be trusted.<p> Note that a packet can span an arbitrary number of pages; the above @@ -192,7 +198,7 @@ buffered packet segments.<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 inadvertant coincidence in the byte stream).<p> + (as opposed to an inadvertent coincidence in the byte stream).<p> <pre><tt> byte value @@ -228,19 +234,20 @@ buffered packet segments.<p> set = last page of logical bitstream (eos) </tt></pre> -<h4>PCM absolute position</h4> +<h4>absolute granule position</h4> - (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' + (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 be the frame number). 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 thenext page do not count). The rationale here is - that the position specified in the frame header of the last page - tells how long the PCM data coded by the bitstream is. A truncated - stream will still return the proper number of samples that can be - decoded fully. + 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> A special value of '-1' (in two's complement) indicates that no packets finish on this page. @@ -260,10 +267,10 @@ buffered packet segments.<p> <h4>stream serial number</h4> - Ogg allows for seperate logical bitstreams to be mixed at page + 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 seperate bitstreams to be decoded concurrently. The serial + 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: diff --git a/doc/oggstream.html b/doc/oggstream.html index 56a50d7..6870f46 100644 --- a/doc/oggstream.html +++ b/doc/oggstream.html @@ -8,7 +8,7 @@ src="vorbisword2.png" border=0></a></nobr><p> Ogg logical and physical bitstream overview </font></h1> -<em>Last update to this document: July 18, 1999</em><br> +<em>Last update to this document: July 14, 2002</em><br> <h2>Ogg bitstreams</h2> @@ -18,12 +18,12 @@ high-level structure or boundary information; strung together, they appear to be streams of random bytes with no landmarks.<p> Raw packets may be used directly by transport mechanisms that provide -their own framing and packet-seperation mechanisms (such as UDP +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 seperate data back into packets at the original packet +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> @@ -36,15 +36,18 @@ 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> -Multiple logical bitstreams can be combined (with restricctions) into -a single <em>physical bitstream</em>. A physical bitstream consists -of multiple logical bitstreams multiplexed at the page level. 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 fromt he physical bitstream and redirecting them into -the appropriate logical decoding entitiy. The simplest physical -bitstream is a single, unmultiplexed logical bitstream. <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> <a href=framing.html>Ogg Logical Bitstream Framing</a> discusses the page format of an Ogg bitstream, the packet coding process @@ -58,9 +61,9 @@ 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 '<a href="vorbis-stream.html">Ogg Vorbis +restrictive) mapping. An '<a href="vorbis-ogg.html">Ogg Vorbis Audio Bitstream</a>', for example, has a <a -href="vorbis-stream.html">specific physical bitstream structure</a>. +href="vorbis-ogg.html">specific physical bitstream structure</a>. An 'Ogg A/V' bitstream (not currently specified) will also mandate a specific, restricted physical bitstream format.<p> @@ -106,7 +109,7 @@ the scope of the physical bitstream.<p> Logical bitstreams may also be multiplexed 'in parallel' (<em>grouped</em>). An example of grouping would be to allow -streaming of seperate audio and video streams, using differnt codecs +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> @@ -153,7 +156,7 @@ bitstreams in the previous group have terminated.<p> 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 appearence to bitrate demands is one +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). |