ffmpeg-linux

Network Working Group L. Barbato Request for Comments: 5215 Xiph Category: Standards Track August 2008 RTP Payload Format for Vorbis Encoded Audio Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This document describes an RTP payload format for transporting Vorbis encoded audio. It details the RTP encapsulation mechanism for raw Vorbis data and the delivery mechanisms for the decoder probability model (referred to as a codebook), as well as other setup information. Also included within this memo are media type registrations and the details necessary for the use of Vorbis with the Session Description Protocol (SDP). Barbato Standards Track [Page 1]  RFC 5215 Vorbis RTP Payload Format August 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conformance and Document Conventions . . . . . . . . . . . 3 2. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Example RTP Packet . . . . . . . . . . . . . . . . . . . . 8 3. Configuration Headers . . . . . . . . . . . . . . . . . . . . 8 3.1. In-band Header Transmission . . . . . . . . . . . . . . . 9 3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 10 3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 12 3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 12 3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 13 4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 13 5. Frame Packetization . . . . . . . . . . . . . . . . . . . . . 14 5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 15 5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6.1. Packed Headers IANA Considerations . . . . . . . . . . . . 19 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 . . . . . . . . . . 22 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 22 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 11. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 23 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24 13.2. Informative References . . . . . . . . . . . . . . . . . . 25 Barbato Standards Track [Page 2]  RFC 5215 Vorbis RTP Payload Format August 2008 1. Introduction Vorbis is a general purpose perceptual audio codec intended to allow maximum encoder flexibility, thus allowing it to scale competitively over an exceptionally wide range of bit rates. At the high quality/ bitrate end of the scale (CD or DAT rate stereo, 16/24 bits), it is in the same league as MPEG-4 AAC. Vorbis is also intended for lower and higher sample rates (from 8kHz telephony to 192kHz digital masters) and a range of channel representations (monaural, polyphonic, stereo, quadraphonic, 5.1, ambisonic, or up to 255 discrete channels). Vorbis encoded audio is generally encapsulated within an Ogg format bitstream [RFC3533], 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. 1.1. Conformance and Document Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119] and indicate requirement levels for compliant implementations. Requirements apply to all implementations unless otherwise stated. An implementation is a software module that supports one of the media types defined in this document. Software modules may support multiple media types, but conformance is considered individually for each type. Implementations that fail to satisfy one or more "MUST" requirements are considered non-compliant. Implementations that satisfy all "MUST" requirements, but fail to satisfy one or more "SHOULD" requirements, are said to be "conditionally compliant". All other implementations are "unconditionally compliant". 2. Payload Format For RTP-based transport of Vorbis-encoded audio, the standard RTP header is followed by a 4-octet payload header, and then the payload data. The payload headers are used to associate the Vorbis data with its associated decoding codebooks as well as indicate if the following packet contains fragmented Vorbis data and/or the number of whole Vorbis data frames. The payload data contains the raw Vorbis bitstream information. There are 3 types of Vorbis data; an RTP payload MUST contain just one of them at a time. Barbato Standards Track [Page 3]  RFC 5215 Vorbis RTP Payload Format August 2008 2.1. RTP Header The format of the RTP header is specified in [RFC3550] and shown in Figure 1. This payload format uses the fields of the header in a manner consistent with that specification. 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 | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifiers | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: RTP Header The RTP header begins with an octet of fields (V, P, X, and CC) to support specialized RTP uses (see [RFC3550] and [RFC3551] for details). For Vorbis RTP, the following values are used. Version (V): 2 bits This field identifies the version of RTP. The version used by this specification is two (2). Padding (P): 1 bit Padding MAY be used with this payload format according to Section 5.1 of [RFC3550]. Extension (X): 1 bit The Extension bit is used in accordance with [RFC3550]. CSRC count (CC): 4 bits