RFC-3640RTPPayloadFormatforTransportofMPEG-4ElementaryS资源-CSDN文库

需积分: 1 139 浏览量 2023-08-07 10:40:28 上传评论收藏 62KB PDF 举报

资源推荐

资源详情

资源评论

Network Working Group J. van der Meer

Request for Comments: 3640 Philips Electronics

Category: Standards Track D. Mackie

Apple Computer

V. Swaminathan

Sun Microsystems Inc.

D. Singer

Apple Computer

P. Gentric

Philips Electronics

November 2003

RTP Payload Format for Transport of MPEG-4 Elementary Streams

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

The Motion Picture Experts Group (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.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3

2. Carriage of MPEG-4 Elementary Streams Over RTP . . . . . . . . 4

2.1. Signaling by MIME Format Parameters . . . . . . . . . . 4

2.2. MPEG Access Units . . . . . . . . . . . . . . . . . . . 5

2.3. Concatenation of Access Units . . . . . . . . . . . . . 5

2.4. Fragmentation of Access Units . . . . . . . . . . . . . 6

2.5. Interleaving . . . . . . . . . . . . . . . . . . . . . . 6

2.6. Time Stamp Information . . . . . . . . . . . . . . . . . 7

2.7. State Indication of MPEG-4 System Streams . . . . . . . 8

2.8. Random Access Indication . . . . . . . . . . . . . . . . 8

van der Meer, et al. Standards Track [Page 1]

RFC 3640 Transport of MPEG-4 Elementary Streams November 2003

2.9. Carriage of Auxiliary Information . . . . . . . . . . . 8

2.10. MIME Format Parameters and Configuring Conditional Field 8

2.11. Global Structure of Payload Format . . . . . . . . . . . 9

2.12. Modes to Transport MPEG-4 Streams . . . . . . . . . . . 9

2.13. Alignment with RFC 3016 . . . . . . . . . . . . . . . . 10

3. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1. Usage of RTP Header Fields and RTCP . . . . . . . . . . 10

3.2. RTP Payload Structure . . . . . . . . . . . . . . . . . 11

3.2.1. The AU Header Section . . . . . . . . . . . . . 11

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. . . . . . . . . . . . . . . 21

3.3.1. General. . . . . . . . . . . . . . . . . . . . . 21

3.3.2. The Generic Mode . . . . . . . . . . . . . . . . 22

3.3.3. Constant Bit Rate CELP . . . . . . . . . . . . . 22

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 . . . . . . . 33

4.3. Concatenation of Parameters. . . . . . . . . . . . . . . 33

4.4. Usage of SDP . . . . . . . . . . . . . . . . . . . . . . 34

4.4.1. The a=fmtp Keyword . . . . . . . . . . . . . . . 34

5. Security Considerations. . . . . . . . . . . . . . . . . . . . 34

6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35

APPENDIX: Usage of this Payload Format. . . . . . . . . . . . . . 36

Appendix A. Interleave Analysis . . . . . . . . . . . . . . . . . 36

A. Examples of Delay Analysis with Interleave. . . . . . . . . . 36

A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 36

A.2. De-interleaving and Error Concealment . . . . . . . . . 36

A.3. Simple Group Interleave . . . . . . . . . . . . . . . . 36

A.3.1. Introduction . . . . . . . . . . . . . . . . . . 36

A.3.2. Determining the De-interleave Buffer Size . . . 37

A.3.3. Determining the Maximum Displacement . . . . . . 37

A.4. More Subtle Group Interleave . . . . . . . . . . . . . . 38

A.4.1. Introduction . . . . . . . . . . . . . . . . . . 38

A.4.2. Determining the De-interleave Buffer Size. . . . 38

A.4.3. Determining the Maximum Displacement . . . . . . 39

A.5. Continuous Interleave . . . . . . . . . . . . . . . . . 39

A.5.1. Introduction . . . . . . . . . . . . . . . . . . 39

van der Meer, et al. Standards Track [Page 2]

RFC 3640 Transport of MPEG-4 Elementary Streams November 2003

A.5.2. Determining the De-interleave Buffer Size . . . 40

A.5.3. Determining the Maximum Displacement . . . . . . 40

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Normative References . . . . . . . . . . . . . . . . . . . . . . . 41

Informative References . . . . . . . . . . . . . . . . . . . . . . 41

Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42

Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 43

1. 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. However, 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 has been 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, at

a suitable periodicity depending upon the probability of loss, in

order to reduce stream corruption to an acceptable level. An example

is the carousel mechanism as defined by MPEG in ISO/IEC 14496-1 [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]), that must be employed

van der Meer, et al. Standards Track [Page 3]

RFC 3640 Transport of MPEG-4 Elementary Streams November 2003

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].

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 the

transportation 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 be 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 the

transportation 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

the transportation of any additional system-related information in

the 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 BCP 14, RFC 2119 [4].

2. Carriage of MPEG-4 Elementary Streams over RTP

2.1. Signaling by MIME Format Parameters

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, as 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

van der Meer, et al. Standards Track [Page 4]

RFC 3640 Transport of MPEG-4 Elementary Streams November 2003

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 for 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

Units. An MPEG Access Unit (AU) is the smallest data entity to which

timing information is attributed. In the case of audio, an Access

Unit may represent an audio frame and in the case of video, a

picture. MPEG Access Units are octet-aligned by definition. If, for

example, an audio frame is not octet-aligned, up to 7 zero-padding

bits MUST be inserted at the end of the frame to achieve the octet-

aligned Access Units, as required by the MPEG-4 specification.

MPEG-4 decoders MUST be able to decode AUs in which such padding is

applied.

Consistent with the MPEG-4 specification, this document requires that

each MPEG-4 part 2 video Access Unit include all the coded data of a

picture, any video stream headers that may precede the coded picture

data, and any video stream stuffing that may follow it, up to but not

including the startcode indicating the start of a new video stream or

the next Access Unit.

2.3. Concatenation of Access Units

Frequently it is possible to carry multiple Access Units in one RTP

packet. This is particularly useful for audio; for example, when AAC

is used for encoding a stereo signal at 64 kbits/sec, AAC frames

contain on average, approximately 200 octets. On a LAN with a 1500

octet MTU, this would allow an average of 7 complete AAC frames to be

carried per RTP packet.

Access Units may have a fixed size in octets, but a variable size is

also possible. To facilitate parsing in the case of multiple

concatenated AUs in one RTP packet, the size of each AU is made known

to the receiver. When concatenating in the case of a constant AU

size, this size is communicated "out of band" through a MIME format

parameter. When concatenating in case of variable size AUs, the RTP

payload carries "in band" an AU size field for each contained AU.

In combination with the RTP payload length, the size information

allows the RTP payload to be split by the receiver back into the

individual AUs.

van der Meer, et al. Standards Track [Page 5]

剩余43页未读，继续阅读

评论收藏

内容反馈

毕加索解锁

粉丝: 2139
资源: 24

RFC-3640 RTP Payload Format for Transport of MPEG-4 Elementary S

最新资源

RFC-3640 RTP Payload Format for Transport of MPEG-4 Elementary S

RFC-7655 RTP Payload Format for G.711.0 (G.711)

RFC-4749 RTP Payload Format for the G.729.1 Audio Codec (G.729)

RFC-2032 RTP Payload Format for H.261 Video Streams (FIR)

RFC-5404 RTP Payload Format for G.719 (G.719)

RFC-7587 RTP Payload Format for the Opus Speech and Audio Codec

RFC-7798 RTP Payload Format for High Efficiency Video Coding

RFC-7741 RTP Payload Format for VP8 Video (VP8)

RFC-6184 RTP Payload Format for H.264 Video (H.264)

RFC 3984 - RTP Payload Format for H_264 Video

rfc3640.pdf

rfc3640标准文档

RFC3984 RTP Payload Format for H264 Video

RFC-3550 RTP中英文版

RFC-3550 A Transport Protocol for Real-Time Applications (RTP)

RFC-4585 Extended RTP Profile for RTCP - Based Feedback (RTCP-FB

RFC1889-(RTP)-协议中文概要

RFC-8285 A General Mechanism for RTP Header Extensions

rfc3555-MIME Type Registration of RTP Payload Formats

落雪音乐-六音音源 sixyin-music-source-v1.1.0.js

markdown配套文件，使用前先解压

喜马拉雅xm文件解密工具

OCPP协议解析 代码+代码含义详解

mpp_demo.rar

m3u8的下载转换工具

ubuntu下安装ffmpeg必备软件包合集

音频转码，无限制的享受音乐吧！

OPENCV函数手册（中文）.zip

ev4转mp4小工具（无视授权密码）

最新资源

OCPP协议解析代码+代码含义详解