[xiph-cvs] cvs commit: ogg/doc framing.html oggstream.html
Monty
xiphmont at xiph.org
Sun Jul 14 01:12:10 PDT 2002
xiphmont 02/07/14 01:12:09
Modified: doc framing.html oggstream.html
Log:
Updates and spelling corrections
Revision Changes Path
1.5 +29 -22 ogg/doc/framing.html
Index: framing.html
===================================================================
RCS file: /usr/local/cvsroot/ogg/doc/framing.html,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- framing.html 2002/07/03 03:10:07 1.4
+++ framing.html 2002/07/14 08:12:08 1.5
@@ -7,18 +7,24 @@
Ogg logical bitstream framing
</font></h1>
-Last update to this document: February 18, 2001</em><br>
+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 @@
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 @@
<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 @@
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 @@
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 @@
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 @@
<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:
<p><p>1.3 +19 -16 ogg/doc/oggstream.html
Index: oggstream.html
===================================================================
RCS file: /usr/local/cvsroot/ogg/doc/oggstream.html,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- oggstream.html 2002/07/03 03:10:07 1.2
+++ oggstream.html 2002/07/14 08:12:09 1.3
@@ -8,7 +8,7 @@
Ogg logical and physical bitstream overview
</font></h1>
-Last update to this document: July 18, 1999</em><br>
+Last update to this document: July 14, 2002</em><br>
<h2>Ogg bitstreams</h2>
@@ -18,12 +18,12 @@
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 @@
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 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 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 @@
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 @@
Logical bitstreams may also be multiplexed 'in parallel'
(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 @@
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).
<p><p><p>--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to 'cvs-request at xiph.org'
containing only the word 'unsubscribe' in the body. No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.
More information about the commits
mailing list