📄 draft-ietf-avt-mpeg4-simple-06.txt
字号:
Internet Engineering Task Force J. van der MeerInternet Draft Philips Electronics D. Mackie Apple Computer V. Swaminathan Sun Microsystems Inc. D. Singer Apple Computer P. Gentric Philips Electronics December 2002 Expires June 2003 Document: draft-ietf-avt-mpeg4-simple-06.txt Transport of MPEG-4 Elementary StreamsStatus of this Memo This document is an Internet-Draft and is in full conformance with all provisions of section 10 of RFC 2026. 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 specification is a product of the Audio/Video Transport working group within the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at avt@ietf.org and/or the authors. << Note for the RFC editor: xxxx should be replaced with the RFC number that will be assigned. >> Abstract The MPEG Committee (ISO/IEC JTC1/SC29 WG11) is a working group in ISO that produced the MPEG-4 standard. MPEG defines tools to compress content such as audio-visual information into elementary streams. This specification defines a simple, but generic RTP payload format for transport of any non-multiplexed MPEG-4 elementary stream. van der Meer et al. Expires June 2003 [Page 1]RFC xxxx Transport of MPEG-4 Elementary Streams December 2002Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Carriage of MPEG-4 elementary streams over RTP . . . . . . . 6 2.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. MPEG Access Units . . . . . . . . . . . . . . . . . . . . 6 2.3. Concatenation of Access Units . . . . . . . . . . . . . . 6 2.4. Fragmentation of Access Units . . . . . . . . . . . . . . 7 2.5. Interleaving . . . . . . . . . . . . . . . . . . . . . . . 7 2.6. Time stamp information . . . . . . . . . . . . . . . . . . 8 2.7. State indication of MPEG-4 system streams . . . . . . . . 8 2.8. Random Access Indication . . . . . . . . . . . . . . . . . 8 2.9. Carriage of auxiliary information . . . . . . . . . . . . 9 2.10. MIME format parameters and configuring conditional field . 9 2.11. Global structure of payload format . . . . . . . . . . . . 9 2.12. Modes to transport MPEG-4 streams . . . . . . . . . . . . 10 2.13. Alignment with RFC 3016 . . . . . . . . . . . . . . . . . 10 3. Payload format . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Usage of RTP header fields and RTCP . . . . . . . . . . . 11 3.2. RTP payload structure . . . . . . . . . . . . . . . . . . 12 3.2.1. The AU Header Section . . . . . . . . . . . . . . . . . 12 3.2.1.1. The AU-header . . . . . . . . . . . . . . . . . . . . 12 3.2.2. The Auxiliary Section . . . . . . . . . . . . . . . . . 14 3.2.3. The Access Unit Data Section . . . . . . . . . . . . . . 15 3.2.3.1. Fragmentation . . . . . . . . . . . . . . . . . . . . 16 3.2.3.2. Interleaving . . . . . . . . . . . . . . . . . . . . . 16 3.2.3.3. Constraints for interleaving . . . . . . . . . . . . . 17 3.2.3.4. Crucial and non-crucial AUs with MPEG-4 System data . 20 3.3. Usage of this specification . . . . . . . . . . . . . . . 22 3.3.1. General . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3.2. The generic mode . . . . . . . . . . . . . . . . . . . . 22 3.3.3. Constant bit rate CELP . . . . . . . . . . . . . . . . . 23 3.3.4. Variable bit rate CELP . . . . . . . . . . . . . . . . . 23 3.3.5. Low bit rate AAC . . . . . . . . . . . . . . . . . . . . 24 3.3.6. High bit rate AAC . . . . . . . . . . . . . . . . . . . 25 3.3.7. Additional modes . . . . . . . . . . . . . . . . . . . . 26 4. IANA considerations . . . . . . . . . . . . . . . . . . . . 27 4.1. MIME type registration . . . . . . . . . . . . . . . . . . 27 4.2. Registration of mode definitions with IANA . . . . . . . . 32 4.3. Concatenation of parameters . . . . . . . . . . . . . . . 32 4.4. Usage of SDP . . . . . . . . . . . . . . . . . . . . . . . 33 4.4.1. The a=fmtp keyword . . . . . . . . . . . . . . . . . . . 33 5. Security considerations . . . . . . . . . . . . . . . . . . 33 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 7.1 Normative references . . . . . . . . . . . . . . . . . . . . 34 7.2 Informative references . . . . . . . . . . . . . . . . . . . 34 8. Author addresses . . . . . . . . . . . . . . . . . . . . . . 35van der Meer et al. Expires June 2003 [Page 2]RFC xxxx Transport of MPEG-4 Elementary Streams December 2002 APPENDIX: Usage of this payload format . . . . . . . . . . . 37 A. Examples of delay analysis with interleave . . . . . . . 37 A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . 37 A.2 De-interleaving and error concealment . . . . . . . . . 37 A.3 Simple Group interleave . . . . . . . . . . . . . . . . 37 A.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . 37 A.3.2 Determining the de-interleave buffer size . . . . . . 38 A.3.3 Determining the maximum displacement . . . . . . . . . 38 A.4 More subtle group interleave . . . . . . . . . . . . . . 38 A.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . 38 A.4.2 Determining the de-interleave buffer size . . . . . . 39 A.4.3 Determining the maximum displacement . . . . . . . . . 39 A.5 Continuous interleave . . . . . . . . . . . . . . . . . 39 A.5.1 Introduction . . . . . . . . . . . . . . . . . . . . . 39 A.5.2 Determining the de-interleave buffer size . . . . . . 40 A.5.3 Determining the maximum displacement . . . . . . . . . 41van der Meer et al. Expires June 2003 [Page 3]RFC xxxx Transport of MPEG-4 Elementary Streams December 20021. Introduction The MPEG Committee is Working Group 11 (WG11) in ISO/IEC JTC1 SC29 that specified the MPEG-1, MPEG-2 and, more recently, the MPEG-4 standards [1]. The MPEG-4 standard specifies compression of audio-visual data into for example an audio or video elementary stream. In the MPEG-4 standard, these streams take the form of audio-visual objects that may be arranged into an audio-visual scene by means of a scene description. Each MPEG-4 elementary stream consists of a sequence of Access Units; examples of an Access Unit (AU) are an audio frame and a video picture. This specification defines a general and configurable payload structure to transport MPEG-4 elementary streams, in particular MPEG-4 audio (including speech) streams, MPEG-4 video streams and also MPEG-4 systems streams, such as BIFS (BInary Format for Scenes), OCI (Object Content Information), OD (Object Descriptor) and IPMP (Intellectual Property Management and Protection) streams. The RTP payload defined in this document is simple to implement and reasonably efficient. It allows for optional interleaving of Access Units (such as audio frames) to increase error resiliency in packet loss. Some types of MPEG-4 elementary streams include "crucial" information whose loss cannot be tolerated, but RTP does not provide reliable transmission so receipt of that crucial information is not assured. Section 3.2.3.4 specifies how stream state is conveyed so that the receiver can detect the loss of crucial information and cease decoding until the next random access point is received. Applications transmitting streams that include crucial information, such as OD commands, BIFS commands, or programmatic content such as MPEG-J (Java) and ECMAScript, should include random access points sufficiently often, depending upon the probability of loss, to reduce stream corruption to an acceptable level. An example is the carousel mechanism as defined by MPEG in ISO/IEC 14496-1. Such applications may also employ additional protocols or services to reduce the probability of loss. At the RTP layer, these measures include payload formats and profiles for retransmission or forward error correction (such as in RFC 2733 [10]), which must be employed with due consideration to congestion control. Another solution that may be appropriate for some applications is to carry RTP over TCP (such as in RFC 2326 [8], section 10.12). At the network layer, resource allocation or preferential service may be available to reduce the probability of loss. For a general description of methods to repair streaming media see RFC 2354 [9].van der Meer et al. Expires June 2003 [Page 4]RFC xxxx Transport of MPEG-4 Elementary Streams December 2002 Though the RTP payload format defined in this document is capable of transporting any MPEG-4 stream, other, more specific, formats may exist, such as RFC 3016 [12] for transport of MPEG-4 video (ISO/IEC 14496 [1] part 2). Configuration of the payload is provided to accommodate transport of any MPEG-4 stream at any possible bit rate. However, for a specific MPEG-4 elementary stream typically only very few configurations are needed. So as to allow for the design of simplified, but dedicated receivers, this specification requires that specific modes are defined for transport of MPEG-4 streams. This document defines modes for MPEG-4 CELP and AAC streams, as well as a generic mode that can be used to transport any MPEG-4 stream. In the future new RFCs are expected to specify additional modes for transport of MPEG-4 streams. The RTP payload format defined in this document specifies carriage of system-related information that is often equivalent to the information that may be contained in the MPEG-4 Sync Layer (SL) as defined in MPEG-4 Systems [1]. This document does not prescribe how to transcode or map information from the SL to fields defined in the RTP payload format. Such processing, if any, is left to the discretion of the application. However, to anticipate the need for transport of any additional system-related information in future, an auxiliary field can be configured that may carry any such data. 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 [4].van der Meer et al. Expires June 2003 [Page 5]RFC xxxx Transport of MPEG-4 Elementary Streams December 20022. Carriage of MPEG-4 elementary streams over RTP 2.1 Introduction With this payload format a single MPEG-4 elementary stream can be transported. Information on the type of MPEG-4 stream carried in the payload is conveyed by MIME format parameters, for example in an SDP [5] message or by other means (see section 4). These MIME format parameters specify the configuration of the payload. To allow for simplified and dedicated receivers, a MIME format parameter is available to signal a specific mode of using this payload. A mode definition MAY include the type of MPEG-4 elementary stream as well as the applied configuration, so as to avoid the need in receivers to parse all MIME format parameters. The applied mode MUST be signaled.2.2 MPEG Access Units For carriage of compressed audio-visual data MPEG defines Access
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -