-
AVT Working Group L. Barbato
Internet-Draft Xiph.Org
Expires: April 18, 2006 October 15, 2005
2.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Example RTP Packet . . . . . . . . . . . . . . . . . . . . 7
- 3. Frame Packetizing . . . . . . . . . . . . . . . . . . . . . . 8
- 3.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 8
- 3.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 11
- 4. Configuration Headers . . . . . . . . . . . . . . . . . . . . 12
- 4.1. In-band Header Transmission . . . . . . . . . . . . . . . 12
- 4.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 13
- 4.1.2. Configuration CRC32 Generation . . . . . . . . . . . . 13
- 4.2. Packed Headers Delivery . . . . . . . . . . . . . . . . . 14
- 4.2.1. Packed Headers IANA Considerations . . . . . . . . . . 15
- 4.3. Configuration Caching . . . . . . . . . . . . . . . . . . 16
- 4.4. Loss of Configuration Headers . . . . . . . . . . . . . . 16
- 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
- 5.1. Mapping MIME Parameters into SDP . . . . . . . . . . . . . 18
- 6. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 19
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
- 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
- 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
- 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
- 9.2. Informative References . . . . . . . . . . . . . . . . . . 21
+ 3. Configuration Headers . . . . . . . . . . . . . . . . . . . . 8
+ 3.1. In-band Header Transmission . . . . . . . . . . . . . . . 8
+ 3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 9
+ 3.2. Packed Headers Delivery . . . . . . . . . . . . . . . . . 10
+ 3.2.1. Packed Headers IANA Considerations . . . . . . . . . . 11
+ 3.3. Configuration Caching . . . . . . . . . . . . . . . . . . 12
+ 3.4. Loss of Configuration Headers . . . . . . . . . . . . . . 12
+ 4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 12
+ 5. Frame Packetizing . . . . . . . . . . . . . . . . . . . . . . 13
+ 5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 14
+ 5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 16
+ 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
+ 6.1. Mapping MIME Parameters into SDP . . . . . . . . . . . . . 18
+ 7. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 19
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
+ 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
2. Payload Format
For RTP based transportation of Vorbis encoded audio the standard RTP
- header is followed by a 5 octet payload header, then the payload
+ header is followed by a 4 octet payload header, then the payload
data. The payload headers are used to associate the Vorbis data with
its associated decoding codebooks as well as indicating if the
following packet contains fragmented Vorbis data and/or the the
2.1. RTP Header
The format of the RTP header is specified in [3] and shown in Figure
- 1. This payload format uses the fields of the header in a manner
- consistent with that specification.
+ Figure 1. This payload format uses the fields of the header in a
+ manner consistent with that specification.
2.2. Payload Header
- After the RTP Header section the following five octets are the
- Payload Header. This header is split into a number of bitfields
- detailing the format of the following payload data packets.
+ After the RTP Header section the following 4 octets are the Payload
+ Header. This header is split into a number of bitfields detailing
+ the format of the following payload data packets.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident |
+ | Ident | F |VDT|# pkts.|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | F |VDT|# pkts.|
- +-+-+-+-+-+-+-+-+
Figure 2: Payload Header
- Ident: 32 bits
+ Ident: 24 bits
- This 32 bit field is used to associate the Vorbis data to a decoding
- Configuration. It is created by making a CRC32 checksum of the
- Packed Configuration (Section 4.1.1) required to decode the
- particular Vorbis audio stream.
+ This 24 bit field is used to associate the Vorbis data to a decoding
+ Configuration.
Fragment type (F): 2 bit
This field is set accordingly the following list
0 = Not Fragmented
+ 1 = Start Fragment
+ 2 = Continuation Fragment
+ 3 = End Fragment
+ Vorbis Data Type (VDT): 2 bits
Internet-Draft draft-ietf-avt-vorbis-rtp-01 October 2005
- 1 = Start Fragment
- 2 = Continuation Fragment
- 3 = End Fragment
-
- Vorbis Data Type (VDT): 2 bits
-
This field sets the packet payload type for the Vorbis data. There
- are currently two type of Vorbis payloads.
+ are currently three type of Vorbis payloads.
0 = Raw Vorbis payload
1 = Vorbis Packed Configuration payload
- 2 = Reserved
+ 2 = Legacy Vorbis Comment payload
3 = Reserved
The last 4 bits are the number of complete packets in this payload.
The Vorbis packet length header is the length of the Vorbis data
block only and does not count the length field.
+ The payload packing of the Vorbis data packets SHOULD follow the
+ guidelines set-out in [4] where the oldest packet occurs immediately
+ after the RTP packet header.
+
+ Channel mapping of the audio is in accordance with BS. 775-1 ITU-R
+
Barbato Expires April 18, 2006 [Page 6]
Internet-Draft draft-ietf-avt-vorbis-rtp-01 October 2005
- The payload packing of the Vorbis data packets SHOULD follow the
- guidelines set-out in [4] where the oldest packet occurs immediately
- after the RTP packet header.
-
- Channel mapping of the audio is in accordance with BS. 775-1 ITU-R
[14].
2.4. Example RTP Packet
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident |
+ | Ident | 0 | 0 | 2 pks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 0 | 0 | 2 pks | length | vorbis data ..
+ | length | vorbis data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.. vorbis data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Example Packet (Payload Data)
- The payload data section of the RTP packet starts with the 32 bit
+ The payload data section of the RTP packet starts with the 24 bit
Ident field followed by the one octet bitfield header, which has the
+ number of Vorbis frames set to 2. Each of the Vorbis data frames is
+ prefixed by the two octet length field. The Packet Type and Fragment
+ Type are set to 0. The decode Configuration that will be used to
+ decode the packets is the one indexed by the ident value.
+
Internet-Draft draft-ietf-avt-vorbis-rtp-01 October 2005
- number of Vorbis frames set to 2. Each of the Vorbis data frames is
- prefixed by the two octet length field.
-
-
-3. Frame Packetizing
-
- Each RTP packet contains either one Vorbis packet fragment, or an
- integer number of complete Vorbis packets (up to a max of 15 packets,
- since the number of packets is defined by a 4 bit value).
-
- Any Vorbis data packet that is less than path MTU SHOULD be bundled
- in the RTP packet with as many Vorbis packets as will fit, up to a
- maximum of 15. Path MTU is detailed in [6] and [7].
-
- If a Vorbis packet is larger than 65535 octets it MUST be fragmented.
- A fragmented packet has a zero in the last four bits of the payload
- header. The first fragment will set the Fragment type to 1. Each
- fragment after the first will set the Fragment type to 2 in the
- payload header. The RTP packet containing the last fragment of the
- Vorbis packet will have the Fragment type set to 3. To maintain the
- correct sequence for fragmented packet reception the timestamp field
- of fragmented packets MUST be the same as the first packet sent, with
- the sequence number incremented as normal for the subsequent RTP
- packets.
-
-3.1. Example Fragmented Vorbis Packet
-
- Here is an example fragmented Vorbis packet split over three RTP
- packets. Each packet contains the standard RTP headers as well as
- the 5 octet Vorbis headers.
-
-
-
-
-
-
-
-
-
+3. Configuration Headers
+ Unlike other mainstream audio codecs Vorbis has no statically
+ configured probability model, instead it packs all entropy decoding
+ configuration, VQ and Huffman models into a self-contained codebook.
+ This codebook block also requires additional identification
+ information detailing the number of audio channels, bitrates and
+ other information used to initialise the Vorbis stream.
+ To decode a Vorbis stream, three configuration header blocks are
+ needed. The first header, named identification, indicates the sample
+ and bitrates, the number of channels and the version of the Vorbis
+ encoder used. The second header, named comment, details stream
+ comments and the third header, named setup, contains the decoders
+ probability model, or codebook. Further details are available in the
+ Vorbis I specification [12]
+ As the RTP stream may change certain configuration data mid-session
+ there are different methods for delivering this configuration data to
+ a client, both in-band and out-of-band which is detailed below. SDP
+ delivery is used to setup an initial state for the client
+ application. The changes may be due to different codebooks as well
+ as different bitrates of the stream.
+ The delivery vectors in use are specified by an SDP attribute to
+ indicate the method and the optional URI where the Vorbis Packed
+ Configuration (Section 3.1.1) Packets could be fetched. Different
+ delivery methods MAY be advertised for the same session. The in-band
+ Configuration delivery SHOULD be considered as baseline, out-of-band
+ delivery methods that don't use RTP will not be described in this
+ document. For non chained streams, the Configuration delivery method
+ RECOMMENDED is inline the Packed Configuration (Section 3.1.1) in the
+ SDP as explained in the IANA considerations (Section 6.1) section.
+ The 24 bit Ident field is used to indicate when a change in the
+ stream has taken place. The client application MUST have in advance
+ the correct configuration and if the client detects a change in the
+ Ident value and does not have this information it MUST NOT decode the
+ raw Vorbis data.
+3.1. In-band Header Transmission
+ The Packed Configuration (Section 3.1.1) Payload is sent in-band with
+ the packet type bits set to match the payload type. Clients MUST be
+ capable of dealing with fragmentation and periodic re-transmission of
+ the configuration headers.
Internet-Draft draft-ietf-avt-vorbis-rtp-01 October 2005
- Packet 1:
+3.1.1. Packed Configuration
+
+ A Vorbis Packed Configuration is indicated with the payload type
+ field set to 1. Of the three headers, defined in the Vorbis I
+ specification [12], the identification and the setup will be packed
+ together, the comment header is completely suppressed. Is up to the
+ client provide a minimal size comment header to the decoder if
+ required by the implementation.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |V=2|P|X| CC |M| PT | 1000 |
+ |V=2|P|X| CC |M| PT | xxxx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| xxxxx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident |
+ | Ident | 0 | 1 | 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 1 | 0 | 0| length | vorbis data ..
+ | Setup length | Identification ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. vorbis data |
+ .. Identification ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Identification ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Identification ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. | Setup ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Setup ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Setup |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Figure 6: Example Fragmented Packet (Packet 1)
-
- In this packet the initial sequence number is 1000 and the timestamp
- is xxxxx. The Fragment type is set to 1, the number of packets field
- is set to 0, and as the payload is raw Vorbis data the VDT field is
- set to 0.
-
+ Figure 6: Packed Configuration Figure
+ The Ident field is set with the value that will be used by the Raw
+ Payload Packets to address this Configuration. The Fragment type is
+ set to 0 since the packet bears the full Packed configuration, the
+ number of packet is set to 1
+Barbato Expires April 18, 2006 [Page 9]
+\f
+Internet-Draft draft-ietf-avt-vorbis-rtp-01 October 2005
+3.2. Packed Headers Delivery
+ As mentioned above the RECOMMENDED delivery vector for Vorbis
+ configuration data is via a retrieval method that can be performed
+ using a reliable transport protocol. As the RTP headers are not
+ required for this method of delivery the structure of the
+ configuration data is slightly different. The packed header starts
+ with a 32 bit count field which details the number of packed headers
+ that are contained in the bundle. Next is the Packed header payload
+ for each chained Vorbis stream.
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Number of packed headers |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Packed header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Packed header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Figure 7: Packed Headers Overview
+ Since the Configuration Ident and the Identification Header are fixed
+ length there is only a 2 byte Setup Length tag to define the length
+ of the Setup header.
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Length | Identification Header ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Identification Header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Setup Header ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. Setup Header |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Figure 8: Packed Headers Detail
+ The key difference between the in-band format is there is no need for
+ the payload header octet.
-Barbato Expires April 18, 2006 [Page 9]
+Barbato Expires April 18, 2006 [Page 10]
\f
Internet-Draft draft-ietf-avt-vorbis-rtp-01 October 2005
- Packet 2:
+3.2.1. Packed Headers IANA Considerations
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |V=2|P|X| CC |M| PT | 1001 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | xxxxx |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | synchronization source (SSRC) identifier |
- +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
- | contributing source (CSRC) identifiers |
- | ... |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 2 | 0 | 0| length | vorbis data ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. vorbis data |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ The following IANA considerations MUST only be applied to the packed
+ headers.
- Figure 7: Example Fragmented Packet (Packet 2)
+ MIME media type name: audio
- The Fragment type field is set to 2 and the number of packets field
- is set to 0. For large Vorbis fragments there can be several of
- these type of payload packets. The maximum packet size SHOULD be no
- greater than the path MTU, including all RTP and payload headers.
- The sequence number has been incremented by one but the timestamp
- field remains the same as the initial packet.
+ MIME subtype: vorbis-config
+
+ Required Parameters:
+ None.
+ Optional Parameters:
+
+ None.
+ Encoding considerations:
+ This type is only defined for transfer via non RTP protocols as
+ specified in RFC XXXX.
+ Security Considerations:
+ See Section 6 of RFC 3047.
+ Interoperability considerations: none
+ Published specification:
+ See RFC XXXX for details.
+ Applications which use this media type:
+ Vorbis encoded audio, configuration data.
+ Additional information: none
+ Person & email address to contact for further information:
+ Luca Barbato: <lu_zero@gentoo.org>
+ Intended usage: COMMON
+ Author/Change controller:
+ Author: Luca Barbato
-Barbato Expires April 18, 2006 [Page 10]
+Barbato Expires April 18, 2006 [Page 11]
\f
Internet-Draft draft-ietf-avt-vorbis-rtp-01 October 2005
- Packet 3:
+ Change controller: IETF AVT Working Group
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |V=2|P|X| CC |M| PT | 1002 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | xxxxx |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | synchronization source (SSRC) identifier |
- +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
- | contributing source (CSRC) identifiers |
- | ... |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | 3 | 0 | 0| length | vorbis data ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. vorbis data |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+3.3. Configuration Caching
- Figure 8: Example Fragmented Packet (Packet 3)
+ Configuration caching allows clients that have previously connected
+ to a stream to re-use the associated configuration data. When a
+ client receives a Packed Configuration packet it may store it locally
+ and can compare the Ident key with that of the new stream and begin
+ decoding before it has received any of the headers.
- This is the last Vorbis fragment packet. The Fragment type is set to
- 3 and the packet count remains set to 0. As in the previous packets
- the timestamp remains set to the first packet in the sequence and the
- sequence number has been incremented.
+3.4. Loss of Configuration Headers
-3.2. Packet Loss
+ Unlike the loss of raw Vorbis payload data, loss of a configuration
+ header can lead to a situation where it will not be possible to
+ successfully decode the stream.
- As there is no error correction within the Vorbis stream, packet loss
- will result in a loss of signal. Packet loss is more of an issue for
- fragmented Vorbis packets as the client will have to cope with the
- handling of the Fragment Type. In case of loss of fragments the
- client MUST discard all of them. If we use the fragmented Vorbis
- packet example above and the first packet is lost the client MUST
- detect that the next packet has the packet count field set to 0 and
- the Fragment type 2 and MUST drop it. The next packet, which is the
- final fragmented packet, MUST be dropped in the same manner.
- Feedback reports on lost and dropped packets MUST be sent back via
- RTCP.
+ Loss of Configuration Packet results in the halting of stream
+ decoding and SHOULD be reported to the client as well as a loss
+ report sent via RTCP.
- If a particular multicast session has a large number of participants
- care must be taken to prevent an RTCP feedback implosion, [10], in
- the event of packet loss from a large number of participants.
- Loss of any of the configuration headers, detailed below, is dealt
+4. Comment Headers
+ With the payload type flag set to 2, this indicates that the packet
+ contain the comment metadata, such as artist name, track title and so
+ on. These metadata messages are not intended to be fully descriptive
+ but to offer basic track/song information. This packet SHOULD NOT be
+ sent and clients MAY ignore it completely. During a session the
+ Details on the format of the comments can be found in the Vorbis
+ documentation [12].
-Barbato Expires April 18, 2006 [Page 11]
-\f
-Internet-Draft draft-ietf-avt-vorbis-rtp-01 October 2005
- with in the Loss of Configuration Headers Section later.
-4. Configuration Headers
- Unlike other mainstream audio codecs Vorbis has no statically
- configured probability model, instead it packs all entropy decoding
- configuration, VQ and Huffman models into a self-contained codebook.
- This codebook block also requires additional identification
- information detailing the number of audio channels, bitrates and
- other information used to initialise the Vorbis stream.
- To decode a Vorbis stream, three configuration header blocks are
- needed. The first header, named identification, indicates the sample
- and bitrates, the number of channels and the version of the Vorbis
- encoder used. The second header, named comment, details stream
- comments and the third header, named setup, contains the decoders
- probability model, or codebook. Further details are available in the
- Vorbis I specification [12]
- As the RTP stream may change certain configuration data mid-session
- there are different methods for delivering this configuration data to
- a client, both in-band and out-of-band which is detailed below. SDP
- delivery is used to set-up an initial state for the client
- application. The changes may be due to different codebooks as well
- as different bitrates of the stream.
- The delivery vectors in use are specified by an SDP attribute to
- indicate the method and the optional URI where the Vorbis Packed
- Configuration (Section 4.1.1) Packets could be fetched. Different
- delivery methodsMAY be advertised for the same session. The in-band
- Configuration delivery SHOULD be considered as baseline, out-of-band
- delivery methods that don't use RTP will not be described in this
- document. For streams that do not change, the Configuration delivery
- method RECOMMENDED is inline the Packed Configuration (Section 4.1.1)
- in the SDP as explained in the IANA considerations (Section 5.1)
- The 32 bit Ident field is used to indicate when a change in the
- stream has taken place. The client application MUST have in advance
- the correct configuration and if the client detects a change in the
- Ident value and does not have this information it MUST NOT decode the
- raw Vorbis data.
-4.1. In-band Header Transmission
- The Packed Configuration (Section 4.1.1) Payload is sent in-band with
- the packet type bits set to match the payload type. Clients MUST be
- capable of dealing with periodic re-transmission of the configuration
-Barbato Expires April 18, 2006 [Page 12]
-\f
-Internet-Draft draft-ietf-avt-vorbis-rtp-01 October 2005
- headers.
-4.1.1. Packed Configuration
- A Vorbis Packed Configuration is indicated with the payload type
- field set to 1. Of the three headers, defined in the Vorbis I
- specification [12], the identification and the setup will be packed
- together, the comment header is completely suppressed. Is up to the
- client provide a minimal size comment header to the decoder if
- required by the implementation. The 4 byte Ident field is produced
- by making a CRC32 checksum of the Packed Configuration.
+
+Barbato Expires April 18, 2006 [Page 12]
+\f
+Internet-Draft draft-ietf-avt-vorbis-rtp-01 October 2005
+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ident |
+ | Ident | 0 | 2 | 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- |0|1| 1 | 1| Identification ..
+ | length | Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Identification ..
+ .. Comment ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Identification ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Identification |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Setup length | Setup ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Setup ..
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Setup |
+ .. Comment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Figure 9: Setup Header
+ Figure 9: Comment Packet
+
+ The 2 bytes length field is necessary since this packet could be
+ fragmented.
-4.1.2. Configuration CRC32 Generation
- In order for different implementations of Vorbis RTP clients and
- servers to interoperate with each other a common format for the
+5. Frame Packetizing
+
+ Each RTP packet contains either one Vorbis packet fragment, or an
+ integer number of complete Vorbis packets (up to a max of 15 packets,
+ since the number of packets is defined by a 4 bit value).
+
+ Any Vorbis data packet that is less than path MTU SHOULD be bundled
+ in the RTP packet with as many Vorbis packets as will fit, up to a
+ maximum of 15. Path MTU is detailed in [6] and [7].
+
+ If a Vorbis packet is larger than 65535 octets it MUST be fragmented.
+ A fragmented packet has a zero in the last four bits of the payload
+ header. The first fragment will set the Fragment type to 1. Each
+ fragment after the first will set the Fragment type to 2 in the
+ payload header. The RTP packet containing the last fragment of the
+ Vorbis packet will have the Fragment type set to 3. To maintain the
+ correct sequence for fragmented packet reception the timestamp field
+ of fragmented packets MUST be the same as the first packet sent, with
+ the sequence number incremented as normal for the subsequent RTP
+ packets.
Internet-Draft draft-ietf-avt-vorbis-rtp-01 October 2005
- production of the CRC32 hash is required. The polynomial is X^32+
- X^26+X^23+X^22+X^16+X^12+X^11+X^10+X^8+X^7+X^5+X^4+X^2+X^1+X^0. (See
- also ISO 3309 [16] or ITU-T V42 [15] for a formal specification.)
+5.1. Example Fragmented Vorbis Packet
+
+ Here is an example fragmented Vorbis packet split over three RTP
+ packets. Each packet contains the standard RTP headers as well as
+ the 4 octet Vorbis headers.
+
+ Packet 1:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | 1000 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | xxxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 1 | 0 | 0|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | vorbis data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 10: Example Fragmented Packet (Packet 1)
- The following C code function gives a straightforward, but
- inefficient implementation of CRC32. It MAY be used by
- implementations, if not then the code responsible for generating the
- CRC32 value MUST use the polynomial function above.
+ In this packet the initial sequence number is 1000 and the timestamp
+ is xxxxx. The Fragment type is set to 1, the number of packets field
+ is set to 0, and as the payload is raw Vorbis data the VDT field is
+ set to 0.
- unsigned int crc32 (int length, unsigned char *crcdata)
- {
- int index, loop;
- unsigned int byte, crc, mask;
- index = 0;
- crc = 0xFFFFFFFF;
- while (index < length) {
- byte = crcdata [index];
- crc = crc ^ byte;
- for (loop = 7; loop >= 0; loop--) {
- mask = -(crc & 1);
- crc = (crc >> 1) ^ (0xEDB88320 & mask);
- }
- index++;
- }
- return ~crc;
- }
-4.2. Packed Headers Delivery
- As mentioned above the RECOMMENDED delivery vector for Vorbis
- configuration data is via a retrieval method that can be performed
- using a reliable transport protocol. As the RTP headers are not
- required for this method of delivery the structure of the
- configuration data is slightly different. The packed header starts
- with a 32 bit count field which details the number of packed headers
- that are contained in the bundle. Next is the Packed header payload
- for each chained Vorbis stream.
Internet-Draft draft-ietf-avt-vorbis-rtp-01 October 2005
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Number of packed headers |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Packed header |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Packed header |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- Figure 10: Packed Headers Overview
-
- Since the Configuration Ident and the Identification Header are fixed
- lenght there is only a 2 byte Setup Lenght tag to define the lenght
- of the Setup header.
+ Packet 2:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Identification Header ..
+ |V=2|P|X| CC |M| PT | 1001 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | xxxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Identification Header | Lenght ..
+ | Ident | 2 | 0 | 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Lenght | Setup Header ..
+ | length | vorbis data ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- .. Setup Header |
+ .. vorbis data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Figure 11: Packed Headers Detail
-
- The key difference between the in-band format is there is no need for
- the payload header octet and Configuration Ident field.
-
-4.2.1. Packed Headers IANA Considerations
+ Figure 11: Example Fragmented Packet (Packet 2)
- The following IANA considerations MUST only be applied to the packed
- headers.
-
- MIME media type name: audio
+ The Fragment type field is set to 2 and the number of packets field
+ is set to 0. For large Vorbis fragments there can be several of
+ these type of payload packets. The maximum packet size SHOULD be no
+ greater than the path MTU, including all RTP and payload headers.
+ The sequence number has been incremented by one but the timestamp
+ field remains the same as the initial packet.
- MIME subtype: vorbis-config
- Required Parameters:
- None.
- Optional Parameters:
-Barbato Expires April 18, 2006 [Page 15]
-\f
-Internet-Draft draft-ietf-avt-vorbis-rtp-01 October 2005
- None.
- Encoding considerations:
- This type is only defined for transfer via non RTP protocols as
- specified in RFC XXXX.
- Security Considerations:
- See Section 6 of RFC 3047.
- Interoperability considerations: none
- Published specification:
- See RFC XXXX for details.
- Applications which use this media type:
- Vorbis encoded audio, configuration data.
- Additional information: none
- Person & email address to contact for further information:
+Barbato Expires April 18, 2006 [Page 15]
+\f
+Internet-Draft draft-ietf-avt-vorbis-rtp-01 October 2005
- Luca Barbato: <lu_zero@gentoo.org>
- Intended usage: COMMON
+ Packet 3:
- Author/Change controller:
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |V=2|P|X| CC |M| PT | 1002 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | xxxxx |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | synchronization source (SSRC) identifier |
+ +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
+ | contributing source (CSRC) identifiers |
+ | ... |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Ident | 3 | 0 | 0|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | length | vorbis data ..
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ .. vorbis data |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- Author: Luca Barbato
+ Figure 12: Example Fragmented Packet (Packet 3)
- Change controller: IETF AVT Working Group
+ This is the last Vorbis fragment packet. The Fragment type is set to
+ 3 and the packet count remains set to 0. As in the previous packets
+ the timestamp remains set to the first packet in the sequence and the
+ sequence number has been incremented.
-4.3. Configuration Caching
+5.2. Packet Loss
- Configuration caching allows clients that have previously connected
- to a stream to re-use the associated configuration data. When a
- client receives a Packed Configuration packet it may store it locally
- and can compare the CRC32 key with that of the new stream and begin
- decoding before it has received any of the headers.
+ As there is no error correction within the Vorbis stream, packet loss
+ will result in a loss of signal. Packet loss is more of an issue for
+ fragmented Vorbis packets as the client will have to cope with the
+ handling of the Fragment Type. In case of loss of fragments the
+ client MUST discard all of them. If we use the fragmented Vorbis
+ packet example above and the first packet is lost the client MUST
+ detect that the next packet has the packet count field set to 0 and
+ the Fragment type 2 and MUST drop it. The next packet, which is the
+ final fragmented packet, MUST be dropped in the same manner.
+ Feedback reports on lost and dropped packets MUST be sent back via
+ RTCP.
-4.4. Loss of Configuration Headers
+ If a particular multicast session has a large number of participants
+ care must be taken to prevent an RTCP feedback implosion, [10], in
+ the event of packet loss from a large number of participants.
- Unlike the loss of raw Vorbis payload data, loss of a configuration
- header can lead to a situation where it will not be possible to
- successfully decode the stream.
+ Loss of any of the configuration headers, detailed below, is dealt
Internet-Draft draft-ietf-avt-vorbis-rtp-01 October 2005
- Loss of Configuration Packet results in the halting of stream
- decoding and SHOULD be reported to the client as well as a loss
- report sent via RTCP.
+ with in the Loss of Configuration Headers Section later.
-5. IANA Considerations
+6. IANA Considerations
MIME media type name: audio
values are:inline, in_band, out_band
configuration: the base16 [9] (hexadecimal) representation of the
- Packed Headers (Section 4.2).
+ Packed Headers (Section 3.2).
Optional Parameters:
configuration-uri: the URI of the configuration headers in case of
- out of band transmission.
+ out of band transmission. In the form of
+ proto://path/to/resource/Ident
Encoding considerations:
+
Barbato Expires April 18, 2006 [Page 17]
\f
Internet-Draft draft-ietf-avt-vorbis-rtp-01 October 2005
Change controller: IETF AVT Working Group
-5.1. Mapping MIME Parameters into SDP
+6.1. Mapping MIME Parameters into SDP
The information carried in the MIME media type specification has a
specific mapping to fields in the Session Description Protocol (SDP)
a=delivery:out_band/http
a=fmtp:98 delivery-method:inline,out_band/http;
configuration=base16string1;
- configuration-uri=http://path/to/the/headers
+ configuration-uri=http://path/to/the/resource/159
Note that the payload format (encoding) names are commonly shown in
upper case. MIME subtypes are commonly shown in lower case. These
the configuration-uri attribute.
-6. Congestion Control
+7. Congestion Control
Vorbis clients SHOULD send regular receiver reports detailing
congestion. A mechanism for dynamically downgrading the stream,
the event of congestion.
-7. Security Considerations
+8. Security Considerations
RTP packets using this payload format are subject to the security
considerations discussed in the RTP specification [3]. This implies
taken to prevent buffer overflows in the client applications.
-8. Acknowledgments
+9. Acknowledgments
This document is a continuation of draft-moffitt-vorbis-rtp-00.txt
and draft-kerr-avt-vorbis-rtp-04.txt. The MIME type section is a
Martin.
-9. References
+10. References
-9.1. Normative References
+10.1. Normative References
[1] Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
RFC 3533.
Internet-Draft draft-ietf-avt-vorbis-rtp-01 October 2005
-9.2. Informative References
+10.2. Informative References
[11] "libvorbis: Available from the Xiph website,
http://www.xiph.org".
picture. International Telecommunications Union. Available from
the ITU website, http://www.itu.int".
- [15] "ITU-T Recommendation V.42, 1994, Rev. 1. Error-correcting
- Procedures for DCEs Using Asynchronous-to-Synchronous
- Conversion. International Telecommunications Union. Available
- from the ITU website, http://www.itu.int".
- [16] "ISO 3309, October 1984, 3rd Edition. Information Processing
- Systems--Data Communication High-Level Data Link Control
- Procedure--Frame Structure. International Organization for
- Standardization.".
+
+
+
+
+
+
+
+
Barbato Expires April 18, 2006 [Page 23]
\f
-
projects / platform / upstream / libvorbis.git / commitdiff