quadraphonic, 5.1, ambisonic, or up to 255 discrete channels).
Vorbis encoded audio is generally encapsulated within an Ogg format
- bitstream [11], which provides framing and synchronization. For the
+ bitstream [14], 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.
Marker (M): 1 bit
Set to zero. Audio silence suppression not used. This conforms to
- section 4.1 of [13].
+ section 4.1 of [12].
Payload Type (PT): 7 bits
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 [12] typically produces
+ kilobytes). The reference implementation [15] 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
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 [13]. The length
+ boundary, as explained by the vorbis specification [12]. The length
value is stored as network byte order integer.
For payloads which consist of multiple Vorbis packets the payload
in temporal order.
Channel mapping of the audio is in accordance with the Vorbis I
- Specification [13].
+ Specification [12].
2.4. Example RTP Packet
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 [13] requires the presence of a
+ addition, the Vorbis I specification [12] 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.
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 [16] the configuration headers.
+ of [17] 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 [13], the identification and the setup MUST be packed
+ specification [12], 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
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 [13].
+ be found in the Vorbis documentation [12].
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 [17] or gzip [14]. A sha1 [10] checksum MAY be provided
+ 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
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 [15], if the server supports the
+ band or use selective retransmission [16], if the server supports the
feature.
A serverside optimization would be to keep an hash list of the
[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.
+ 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
- [11] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
+ [14] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
RFC 3533.
- [12] "libvorbis: Available from the Xiph website,
+ [15] "libvorbis: Available from the Xiph website,
http://www.xiph.org".
- [13] "Ogg Vorbis I specification: Codec setup and packet decode.
- Available from the Xiph website, http://www.xiph.org".
-
- [14] Deutsch, P., "GZIP file format specification version 4.3",
- RFC 1952.
-
- [15] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
+ [16] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol
Extended Reports (RTCP XR)", RFC 3611, November 2003.
- [16] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg,
+ [17] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg,
"RTP Retransmission Payload Format", RFC 4588, July 2006.
- [17] Seward, J., "libbz2 and bzip2".
-
Author's Address
<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">
</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>
-
<reference anchor="RFC3611">
<front>
<title>RTP Control Protocol Extended Reports (RTCP XR)</title>
<seriesInfo name='RFC' value='4588' />
<format type='TXT' octets='76630' target='ftp://ftp.isi.edu/in-notes/rfc4588.txt' />
</reference>
-<reference anchor="BZ2">
-<front>
-<title>libbz2 and bzip2</title>
-<author initials="J" surname="Seward" fullname="Julian Seward" />
-</front>
-</reference>
</references>
</back>
</rfc>