[xiph-commits] r3267 - standards

conrad at svn.annodex.net conrad at svn.annodex.net
Mon Nov 5 00:06:22 PST 2007


Author: conrad
Date: 2007-11-05 00:06:22 -0800 (Mon, 05 Nov 2007)
New Revision: 3267

Modified:
   standards/draft-pfeiffer-oggskeleton-current.xml
Log:
typos, and minor clarification about granuleshift


Modified: standards/draft-pfeiffer-oggskeleton-current.xml
===================================================================
--- standards/draft-pfeiffer-oggskeleton-current.xml	2007-11-03 22:52:35 UTC (rev 3266)
+++ standards/draft-pfeiffer-oggskeleton-current.xml	2007-11-05 08:06:22 UTC (rev 3267)
@@ -250,7 +250,7 @@
           bitstream. This document specifies the minor version 0.
           </t>
 	  <t>Presentationtime numerator &amp; denominator: 8 Byte signed
-          integer each
+          integer each.
           They represent together the time at which to start
           presenting the Ogg physical bitstream given as a rational number.
           The denominator represents the temporal resolution at which the
@@ -263,7 +263,7 @@
           created stream.
 	  </t>
 	  <t>Basetime numerator &amp; denominator: 8 Byte signed integer
-	  each
+	  each.
           They represent together the basetime of the
 	  Ogg physical bitstream given as a rational number like the
           presentationtime. This number is fixed once the physical bitstream
@@ -375,7 +375,7 @@
              particular logical bitstream consisting of the bos page and the
              secondary header pages.</t>
 	  <t>Granulerate numerator &amp; denominator: 8 Byte signed integer
-             each
+             each.
              They represent the temporal resolution of the
              logical bitstream in Hz given as a rational number in the
              same way as the basetime attribute above.</t>
@@ -390,13 +390,14 @@
           <t>Granuleshift: a 1 Byte unsigned integer describing
              whether to partition the granule_position into two for that
              logical bitstream, and how many of the lower bits to use for
-             the partitioning. The upper bits then still signify a
-             time-continuous granule position for a directly decodable
-             and presentable data granule. The lower bits allow for
-             specification of a finer resolution such that for example
-             predicted frames of a video can be addressed as well, though
-             not decoded without tracing back to the last fully decodable
-             data granule. This is e.g. the case with Ogg Theora.</t>
+             the partitioning. The upper bits signify a time-continuous
+             granule position for an independently decodable and presentable
+             data granule. The lower bits are generally used to specify the
+             relative offset of dependent packets, such as predicted frames
+             of a video. Hence these can be addressed, though not decoded
+             without tracing back to the last fully decodable data granule.
+             This is the case with Ogg Theora; the general procedure is
+             given in section 3.2.</t>
           <t>Padding/future use: 3 Bytes padding data that may be used for
              future requirements and are mandated to zero in this revision.</t>
 	  <t>Message header fields: header fields, following the generic 
@@ -449,7 +450,7 @@
           <t>There are no content pages or data packets. As the skeleton
              eos page is included before the first data page of any logical
              bitstream, there actually cannot be any content data packets.</t>
-          <t>The skeleton eos page contains one packet of length zero.</t>
+          <t>The skeleton eos page MUST contain one packet of length zero.</t>
           </list>
         </t>
 
@@ -619,7 +620,7 @@
       granulerate of this page's logical bitstream provides the time
       position that is reached in that bitstream after decoding all data
       packets finished on this page. However, the granule_position field
-      in an Ogg page allows for a more fine-grained description of
+      in an Ogg page allows for a more finely-grained description of
       the temporal position. The following image explains the composition
       of the granule_position field in an Ogg page:
       </t>
@@ -652,7 +653,7 @@
       </t>
 
       <t>The calculation of the temporal position of an Ogg page using
-	  Skeleton is thus specified through the following algorithm:
+	  Skeleton is thus specified through the following formula:
       <artwork><![CDATA[
 t_page = basetime + ((keyindex + keyoffset) / granulerate)
       ]]></artwork>
@@ -744,7 +745,7 @@
       </t>
 
       <t>The seeking action is performed on the interleaved bitstream, in
-      which, the data packets occur in a temporally consecutive order based
+      which the data packets occur in a temporally consecutive order based
       on the time at which their data ends. These times are represented in
       the granule positions of the Ogg pages, which are only allowed to
       monotonically increase within one logical bitstream. This



More information about the commits mailing list