[xiph-commits] r13558 - trunk/vorbis/doc

lu_zero at svn.xiph.org lu_zero at svn.xiph.org
Thu Aug 16 01:54:30 PDT 2007


Author: lu_zero
Date: 2007-08-16 01:54:30 -0700 (Thu, 16 Aug 2007)
New Revision: 13558

Modified:
   trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-06.txt
   trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-06.xml
Log:
Simplify configuration-uri handling

Modified: trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-06.txt
===================================================================
--- trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-06.txt	2007-08-16 08:34:22 UTC (rev 13557)
+++ trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-06.txt	2007-08-16 08:54:30 UTC (rev 13558)
@@ -83,12 +83,12 @@
      5.1.  Example Fragmented Vorbis Packet . . . . . . . . . . . . . 14
      5.2.  Packet Loss  . . . . . . . . . . . . . . . . . . . . . . . 16
    6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
-     6.1.  Packed Headers IANA Considerations . . . . . . . . . . . . 19
+     6.1.  Packed Headers IANA Considerations . . . . . . . . . . . . 18
    7.  SDP related considerations . . . . . . . . . . . . . . . . . . 20
      7.1.  Mapping Media Type Parameters into SDP . . . . . . . . . . 20
        7.1.1.  SDP Example  . . . . . . . . . . . . . . . . . . . . . 21
      7.2.  Usage with the SDP Offer/Answer Model  . . . . . . . . . . 21
-   8.  Congestion Control . . . . . . . . . . . . . . . . . . . . . . 22
+   8.  Congestion Control . . . . . . . . . . . . . . . . . . . . . . 21
    9.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
      9.1.  Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 22
    10. Security Considerations  . . . . . . . . . . . . . . . . . . . 23
@@ -125,7 +125,7 @@
    quadraphonic, 5.1, ambisonic, or up to 255 discrete channels).
 
    Vorbis encoded audio is generally encapsulated within an Ogg format
-   bitstream [14], which provides framing and synchronization.  For the
+   bitstream [11], which provides framing and synchronization.  For the
    purposes of RTP transport, this layer is unnecessary, and so raw
    Vorbis packets are used in the payload.
 
@@ -209,7 +209,7 @@
    Marker (M): 1 bit
 
    Set to zero.  Audio silence suppression not used.  This conforms to
-   section 4.1 of [12].
+   section 4.1 of [10].
 
    Payload Type (PT): 7 bits
 
@@ -304,7 +304,7 @@
    Raw Vorbis packets are currently unbounded in length, application
    profiles will likely define a practical limit.  Typical Vorbis packet
    sizes range from very small (2-3 bytes) to quite large (8-12
-   kilobytes).  The reference implementation [15] typically produces
+   kilobytes).  The reference implementation [12] typically produces
    packets less than ~800 bytes, except for the setup header packets
    which are ~4-12 kilobytes.  Within an RTP context, to avoid
    fragmentation, the Vorbis data packet size SHOULD be kept
@@ -322,7 +322,7 @@
    Each Vorbis payload packet starts with a two octet length header,
    which is used to represent the size in bytes of the following data
    payload, followed by the raw Vorbis data padded to the nearest byte
-   boundary, as explained by the vorbis specification [12].  The length
+   boundary, as explained by the vorbis specification [10].  The length
    value is stored as network byte order integer.
 
    For payloads which consist of multiple Vorbis packets the payload
@@ -346,7 +346,7 @@
    in temporal order.
 
    Channel mapping of the audio is in accordance with the Vorbis I
-   Specification [12].
+   Specification [10].
 
 2.4.  Example RTP Packet
 
@@ -410,7 +410,7 @@
    blocks of information are often referred to collectively as the
    "codebooks" for a Vorbis stream, and are nominally included as
    special "header" packets at the start of the compressed data.  In
-   addition, the Vorbis I specification [12] requires the presence of a
+   addition, the Vorbis I specification [10] requires the presence of a
    comment header packet which gives simple metadata about the stream,
    but this information is not required for decoding the frame sequence.
 
@@ -457,13 +457,13 @@
    The Packed Configuration (Section 3.1.1) Payload is sent in-band with
    the packet type bits set to match the Vorbis Data Type.  Clients MUST
    be capable of dealing with fragmentation and periodic re-transmission
-   of [17] the configuration headers.
+   of [14] the configuration headers.
 
 3.1.1.  Packed Configuration
 
    A Vorbis Packed Configuration is indicated with the Vorbis Data Type
    field set to 1.  Of the three headers defined in the Vorbis I
-   specification [12], the identification and the setup MUST be packed
+   specification [10], the identification and the setup MUST be packed
    as they are, while the comment header MAY be replaced with a dummy
    one.  The packed configuration follows a generic way to store xiph
    codec configurations: The first field stores the number of the
@@ -664,7 +664,7 @@
    and so on.  These metadata messages are not intended to be fully
    descriptive but to offer basic track/song information.  Clients MAY
    ignore it completely.  The details on the format of the comments can
-   be found in the Vorbis documentation [12].
+   be found in the Vorbis documentation [10].
 
 
 
@@ -928,43 +928,31 @@
          "protocol://path/to/resource/", depending on the specific
          method, a single configuration packet could be retrived by its
          Ident number, or multiple packets could be aggregated in a
-         single stream.  Such aggregates MAY be compressed using either
-         bzip2 [11] or gzip [13].  A sha1 [10] checksum MAY be provided
-         for aggregates.  In this latter case the URI will end with the
-         aggregate name, followed by its compressed extension if
-         applies, a "!" and the base64 [9] representation of the
-         sha1hash of the above mentioned compressed aggregated as in:
-         "protocol://path/to/resource/aggregated.bz2!sha1hash".  The
-         trailing '/' discriminates which of two methods are in use.
-         The configuration-uri MUST follow the associated delivery
-         method parameter ("out_band").  Non hierarchical protocols and
-         protocols using for special purposes the '!' separator MAY
-         point just to a resource aggregate using their specific syntax.
+         single stream.  Non hierarchical protocols MAY point to a
+         resource using their specific syntax.
 
+   Encoding considerations:
 
+      This media type is framed and contains binary data.
 
+   Security considerations:
 
+      See Section 10 of RFC XXXX.
 
+   Interoperability considerations:
 
+      None
 
 
-Barbato                 Expires December 27, 2007              [Page 17]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 2007
 
 
-   Encoding considerations:
 
-      This media type is framed and contains binary data.
 
-   Security considerations:
+Barbato                 Expires December 27, 2007              [Page 17]
+
+Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 2007
 
-      See Section 10 of RFC XXXX.
 
-   Interoperability considerations:
-
-      None
-
    Published specification:
 
       RFC XXXX [RFC Editor: please replace by the RFC number of this
@@ -999,26 +987,28 @@
 
       Luca Barbato
 
+   Change controller:
 
+      IETF AVT Working Group delegated from the IESG
 
 
+6.1.  Packed Headers IANA Considerations
 
+   The following IANA considerations MUST only be applied to the packed
+   headers.
 
-Barbato                 Expires December 27, 2007              [Page 18]
-
-Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 2007
 
 
-   Change controller:
 
-      IETF AVT Working Group delegated from the IESG
 
 
-6.1.  Packed Headers IANA Considerations
 
-   The following IANA considerations MUST only be applied to the packed
-   headers.
 
+Barbato                 Expires December 27, 2007              [Page 18]
+
+Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 2007
+
+
    Type name:  audio
 
    Subtype name:  vorbis-config
@@ -1056,22 +1046,25 @@
 
       None
 
+   Person & email address to contact for further information:
 
+      Luca Barbato: <lu_zero at gentoo.org>
+      IETF Audio/Video Transport Working Group
 
+   Intended usage:  COMMON
 
 
+
+
+
+
+
+
 Barbato                 Expires December 27, 2007              [Page 19]
 
 Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 2007
 
 
-   Person & email address to contact for further information:
-
-      Luca Barbato: <lu_zero at gentoo.org>
-      IETF Audio/Video Transport Working Group
-
-   Intended usage:  COMMON
-
    Restriction on usage:
 
       This media type doesn't depend on the transport.
@@ -1114,19 +1107,20 @@
       included in the SDP "a=fmtp" attribute and MUST follow the
       delivery-method that applies.
 
+   If the stream comprises chained Vorbis files and all of them are
+   known in advance, the Configuration Packet for each file SHOULD be
+   passed to the client using the configuration attribute.
 
+   The URI specified in the configuration-uri attribute MUST point to a
+   location where all of the Configuration Packets needed for the life
 
+
+
 Barbato                 Expires December 27, 2007              [Page 20]
 
 Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 2007
 
 
-   If the stream comprises chained Vorbis files and all of them are
-   known in advance, the Configuration Packet for each file SHOULD be
-   passed to the client using the configuration attribute.
-
-   The URI specified in the configuration-uri attribute MUST point to a
-   location where all of the Configuration Packets needed for the life
    of the session reside.
 
    The port value is specified by the server application bound to the
@@ -1171,16 +1165,18 @@
    parameters MUST not be altered on answer otherwise.
 
 
+8.  Congestion Control
 
+   Vorbis clients SHOULD send regular receiver reports detailing
+   congestion.  A mechanism for dynamically downgrading the stream,
+
+
+
 Barbato                 Expires December 27, 2007              [Page 21]
 
 Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 2007
 
 
-8.  Congestion Control
-
-   Vorbis clients SHOULD send regular receiver reports detailing
-   congestion.  A mechanism for dynamically downgrading the stream,
    known as bitrate peeling, will allow for a graceful backing off of
    the stream bitrate.  This feature is not available at present so an
    alternative would be to redirect the client to a lower bitrate stream
@@ -1215,7 +1211,7 @@
 
    The client could choose to fetch the Configuration from the alternate
    source as soon as it discovers a Configuration packet got lost in-
-   band or use selective retransmission [16], if the server supports the
+   band or use selective retransmission [13], if the server supports the
    feature.
 
    A serverside optimization would be to keep an hash list of the
@@ -1228,6 +1224,10 @@
 
 
 
+
+
+
+
 Barbato                 Expires December 27, 2007              [Page 22]
 
 Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 2007
@@ -1303,29 +1303,21 @@
    [9]   Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
          RFC 3548.
 
-   [10]  National Institute of Standards and Technology, "Secure Hash
-         Standard", May 1993.
-
-   [11]  Seward, J., "libbz2 and bzip2".
-
-   [12]  "Ogg Vorbis I specification:  Codec setup and packet decode.
+   [10]  "Ogg Vorbis I specification:  Codec setup and packet decode.
          Available from the Xiph website, http://www.xiph.org".
 
-   [13]  Deutsch, P., "GZIP file format specification version 4.3",
-         RFC 1952.
-
 12.2.  Informative References
 
-   [14]  Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
+   [11]  Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
          RFC 3533.
 
-   [15]  "libvorbis: Available from the Xiph website,
+   [12]  "libvorbis: Available from the Xiph website,
          http://www.xiph.org".
 
-   [16]  Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
+   [13]  Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
          Extended Reports (RTCP XR)", RFC 3611, November 2003.
 
-   [17]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg,
+   [14]  Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg,
          "RTP Retransmission Payload Format", RFC 4588, July 2006.
 
 
@@ -1340,6 +1332,14 @@
 
 
 
+
+
+
+
+
+
+
+
 Barbato                 Expires December 27, 2007              [Page 24]
 
 Internet-Draft        draft-ietf-avt-rtp-vorbis-06              Jun 2007

Modified: trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-06.xml
===================================================================
--- trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-06.xml	2007-08-16 08:34:22 UTC (rev 13557)
+++ trunk/vorbis/doc/draft-ietf-avt-rtp-vorbis-06.xml	2007-08-16 08:54:30 UTC (rev 13558)
@@ -826,15 +826,8 @@
 In the form of "protocol://path/to/resource/", depending on the specific
 method, a single configuration packet could be retrived by its Ident number, or
 multiple packets could be aggregated in a single stream. 
-Such aggregates MAY be compressed using either
-<xref target="BZ2">bzip2</xref> or <xref target="rfc1952">gzip</xref>.
-A <xref target="FIPS180">sha1</xref> checksum MAY be provided for aggregates.
-In this latter case the URI will end with the aggregate name, followed by its
-compressed extension if applies, a "!" and the <xref target="rfc3548">base64</xref> representation of the sha1hash of the above mentioned compressed aggregated
-as in: "protocol://path/to/resource/aggregated.bz2!sha1hash".
-The trailing '/' discriminates which of two methods are in use.
-The configuration-uri MUST follow the associated delivery method parameter ("out_band").
-Non hierarchical protocols and protocols using for special purposes the '!' separator MAY point just to a resource aggregate using their specific syntax.
+Non hierarchical protocols MAY point to a resource using their specific
+syntax.
 </t>
 </list>
 </t>
@@ -1266,7 +1259,6 @@
 </reference>
 
 <reference anchor='rfc4566'>
-
 <front>
 <title>SDP: Session Description Protocol</title>
 <author initials='M.' surname='Handley' fullname='M. Handley'>
@@ -1277,13 +1269,11 @@
 <organization /></author>
 <date year='2006' month='July' />
 </front>
-
 <seriesInfo name='RFC' value='4566' />
 <format type='TXT' octets='108820' target='ftp://ftp.isi.edu/in-notes/rfc4566.txt' />
 </reference>
 
 <reference anchor='rfc1191'>
-
 <front>
 <title>Path MTU discovery</title>
 <author initials='J.' surname='Mogul' fullname='Jeffrey Mogul'>
@@ -1296,7 +1286,6 @@
 <email>deering at xerox.com</email></address></author>
 <date year='1990' day='1' month='November' />
 </front>
-
 <seriesInfo name='RFC' value='1191' />
 <format type='TXT' octets='47936' target='ftp://ftp.isi.edu/in-notes/rfc1191.txt' />
 </reference>
@@ -1325,34 +1314,13 @@
 </front>
 <seriesInfo name="RFC" value="3548" />
 </reference>
-<reference anchor="FIPS180">
-<front>
-<title>Secure Hash Standard</title>
-<author>
-<organization>National Institute of Standards and Technology</organization>
-</author>
-<date month="May" year="1993"/>
-</front>
-</reference>
-<reference anchor="BZ2">
-<front>
-<title>libbz2 and bzip2</title>
-<author initials="J" surname="Seward" fullname="Julian Seward" />
-</front>
-</reference>
+
 <reference anchor="vorbis-spec-ref">
 <front>
 <title>Ogg Vorbis I specification:  Codec setup and packet decode.  Available from the Xiph website, http://www.xiph.org</title>
 </front>
-</reference>   
-
-<reference anchor="rfc1952">
-<front>
-<title>GZIP file format specification version 4.3</title>
-<author initials="P" surname="Deutsch" fullname="L. Peter Deutsch"></author>
-</front>
-<seriesInfo name="RFC" value="1952" />
 </reference>
+
 </references>
 
 <references title="Informative References">



More information about the commits mailing list