[xiph-commits] r4085 - standards
silvia at svn.annodex.net
silvia at svn.annodex.net
Mon Mar 22 17:19:06 PDT 2010
Author: silvia
Date: 2010-03-22 17:19:06 -0700 (Mon, 22 Mar 2010)
New Revision: 4085
Modified:
standards/draft-pfeiffer-oggskeleton-current.txt
standards/draft-pfeiffer-oggskeleton-current.xml
Log:
Serial numbers are unsigned; also made xml2rfc work on it again
Modified: standards/draft-pfeiffer-oggskeleton-current.txt
===================================================================
--- standards/draft-pfeiffer-oggskeleton-current.txt 2010-03-09 03:25:07 UTC (rev 4084)
+++ standards/draft-pfeiffer-oggskeleton-current.txt 2010-03-23 00:19:06 UTC (rev 4085)
@@ -12,12 +12,10 @@
Status of this Memo
- This document is an Internet-Draft and is subject to all provisions
- of Section 3 of RFC 3667. By submitting this Internet-Draft, each
- author represents that any applicable patent or other IPR claims of
- which he or she is aware have been or will be disclosed, and any of
- which he or she become aware will be disclosed, in accordance with
- RFC 3668.
+ By submitting this Internet-Draft, each author represents that any
+ applicable patent or other IPR claims of which he or she is aware
+ have been or will be disclosed, and any of which he or she becomes
+ aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
@@ -52,6 +50,8 @@
+
+
Pfeiffer & Parker Expires May 4, 2008 [Page 1]
Internet-Draft SKELETON November 2007
@@ -371,7 +371,7 @@
version number of the skeleton bitstream. This document
specifies the minor version 0.
- 4. Presentationtime numerator & denominator: 8 Byte signed integer
+ 4. Presentationtime numerator & denominator: 8 Byte unsigned 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
@@ -381,7 +381,7 @@
newly created physical bitstream presentationtime and basetime
are the same. When remultiplexing a subpart of the stream, this
number MUST be adapted to the requested start time offset of the
- newly created stream. Presentationtime must always be larger or
+ newly created stream. Presentationtime MUST always be larger or
equal to zero.
@@ -527,7 +527,7 @@
allowing to parse message header fields even if more fields get
inserted before them.
- 3. Serial number: 4 Byte unsigned integer containing the
+ 3. Serial number: 4 Byte signed integer containing the
bitstream_serial_number of the Ogg logical bitstream described
by this skeleton secondary header packet and thus connecting it
to the logical bitstream.
@@ -851,10 +851,10 @@
is mapped as instantaneous information (i.e. their granuleposition
represents the start time and the end time of the packet data), but
actually has a duration associated to it, which is provided through a
- subsequent packet. CMML is such an example. The keyindex part of
- the granule_position is then used to provide the temporal position of
- the reference packet and the keyoffset part provides a counter for
- the data in between.
+ subsequent packet. CMML [CMML] is such an example. The keyindex
+ part of the granule_position is then used to provide the temporal
+ position of the reference packet and the keyoffset part provides a
+ counter for the data in between.
The calculation of the temporal position of an Ogg page using
Skeleton is thus specified through the following formula:
Modified: standards/draft-pfeiffer-oggskeleton-current.xml
===================================================================
--- standards/draft-pfeiffer-oggskeleton-current.xml 2010-03-09 03:25:07 UTC (rev 4084)
+++ standards/draft-pfeiffer-oggskeleton-current.xml 2010-03-23 00:19:06 UTC (rev 4085)
@@ -4,7 +4,7 @@
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
-<rfc category="info" ipr="full3667" docName="draft-pfeiffer-oggskeleton-00">
+<rfc category="info" ipr="full3978" docName="draft-pfeiffer-oggskeleton-00">
<front>
<title abbrev="SKELETON">The "skeleton" meta information track for Ogg</title>
@@ -227,6 +227,7 @@
<t>The fields in the skeleton ident header have the following
meaning:
</t>
+ <t>
<list style="numbers">
<t>Identifier: a 8 Byte field that identifies this bitstream
as a skeleton. It contains the magic numbers:
@@ -279,7 +280,7 @@
bos page of the skeleton bitstream constant length.
</t>
</list>
-
+ </t>
<t>Please note: The possible temporal resolution of the presentation-
and basetime is on the order of 2^-64. For example, the time formats
in use for media that are described in this document range from
@@ -350,6 +351,7 @@
<t>The fields in a skeleton secondary header packet have the
following meaning:
</t>
+ <t>
<list style="numbers">
<t>Identifier: a 8 Byte field that identifies this packet
as a skeleton secondary header for identifying other
@@ -372,7 +374,7 @@
field accommodates future changes to the skeleton
bitstream allowing to parse message header fields even if
more fields get inserted before them.</t>
- <t>Serial number: 4 Byte unsigned integer containing the
+ <t>Serial number: 4 Byte signed integer containing the
bitstream_serial_number of the Ogg logical bitstream described
by this skeleton secondary header packet and thus connecting
it to the logical bitstream.</t>
@@ -415,6 +417,7 @@
preferred. Header fields can be extended over multiple lines
by preceding each extra line with at least one SP or HT.</t>
</list>
+ </t>
<t>There is one mandatory Message header field for all of the
logical bitstreams: the "Content-type" header field. For an
@@ -652,18 +655,20 @@
logical bitstream that is mapped as instantaneous information (i.e.
their granuleposition represents the start time and the end time of
the packet data), but actually has a duration associated to it, which
- is provided through a subsequent packet. CMML is such an example.
- The keyindex part of the granule_position is then used to provide
- the temporal position of the reference packet
+ is provided through a subsequent packet. <xref target="CMML">CMML</xref>
+ is such an example. The keyindex part of the granule_position is then used
+ to provide the temporal position of the reference packet
and the keyoffset part provides a counter for the data in between.
</t>
<t>The calculation of the temporal position of an Ogg page using
Skeleton is thus specified through the following formula:
+ </t>
+ <figure>
<artwork><![CDATA[
t_page = basetime + ((keyindex + keyoffset) / granulerate)
]]></artwork>
- </t>
+ </figure>
<t>The basetime provides the time offset used at the beginning of the
logical bitstream for the first data packet and thus MUST be
added for a correct calculation of the temporal position.
@@ -673,10 +678,12 @@
of 44100 (i.e. 44100 samples per 1 sec), a granuleshift of 0,
and starts at 4 sec. When reaching a granule_position of 88200, this
maps to a time position of 6 seconds:
+ </t>
+ <figure>
<artwork><![CDATA[
t_page = 4 + ((88200 + 0) / 44100) = 6
]]></artwork>
- </t>
+ </figure>
<t>This signifies that the bitstream has reached the second sec of the
audio bitstream after the end of decoding this page's packets, but
maps to 6 seconds because of the basetime.
@@ -688,10 +695,12 @@
and starts at 0 sec. When reaching a granule_position of 997, i.e.
a keyindex of 62 and a keyshift of 5, this maps to a fully decodable
time position of 2.68 seconds:
+ </t>
+ <figure>
<artwork><![CDATA[
t_page = 0 + ((62 + 5) / 25) = 2.68 sec
]]></artwork>
- </t>
+ </figure>
<t>The granulerate of a time-instantaneous bitstream such as
a CMML bitstream can be chosen arbitrarily by the bitstream
More information about the commits
mailing list