【开源软件Tracker】下载及详解

AVT Working Group L. Barbato Internet-Draft Xiph.Org Expires: December 27, 2007 Jun 25, 2007 draft-ietf-avt-rtp-vorbis-06 RTP Payload Format for Vorbis Encoded Audio Status of this Memo 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 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 27, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document describes an RTP payload format for transporting Vorbis encoded audio. It details the RTP encapsulation mechanism for raw Vorbis data and details the delivery mechanisms for the decoder probability model, referred to as a codebook and 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 Expires December 27, 2007 [Page 1]  Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007 Editors Note All references to RFC XXXX are to be replaced by references to the RFC number of this memo, when published. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Payload Header . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Example RTP Packet . . . . . . . . . . . . . . . . . . . . 7 3. Configuration Headers . . . . . . . . . . . . . . . . . . . . 8 3.1. In-band Header Transmission . . . . . . . . . . . . . . . 9 3.1.1. Packed Configuration . . . . . . . . . . . . . . . . . 9 3.2. Out of Band Transmission . . . . . . . . . . . . . . . . . 11 3.2.1. Packed Headers . . . . . . . . . . . . . . . . . . . . 11 3.3. Loss of Configuration Headers . . . . . . . . . . . . . . 12 4. Comment Headers . . . . . . . . . . . . . . . . . . . . . . . 12 5. Frame Packetization . . . . . . . . . . . . . . . . . . . . . 13 5.1. Example Fragmented Vorbis Packet . . . . . . . . . . . . . 14 5.2. Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . 21 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 22 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Stream Radio . . . . . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 25 Barbato Expires December 27, 2007 [Page 2]  Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007 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 bitrates. At the high quality/ bitrate end of the scale (CD or DAT rate stereo, 16/24 bits), it is in the same league as 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 [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. 1.1. Terminology 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 RFC 2119 [1]. 2. Payload Format For RTP based transport of Vorbis encoded audio the standard RTP header is followed by a 4 octets 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 number of whole Vorbis data frames. The payload data contains the raw Vorbis bitstream information. There are 3 types of Vorbis payload data, an RTP packet MUST contain just one of them at a time. 2.1. RTP Header The format of the RTP header is specified in [2] and shown in Figure Figure 1. This payload format uses the fields of the header in a manner consistent with that specification. Barbato Expires December 27, 2007 [Page 3]  Internet-Draft draft-ietf-avt-rtp-vorbis-06 Jun 2007 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 [2] and [3] 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