RFC 3640：MPEG-4 elementary stream RTP payload format标准

需积分: 9 68 浏览量更新于2024-07-17 收藏 137KB PDF 举报

"RFC3640.pdf" 是一份关于实时传输协议(RTP)承载MPEG-4基本流的规范，由Network Working Group J. van der Meer等多位专家联合制定，于2003年11月发布。该文档属于互联网标准跟踪类别，旨在为互联网社区提供一种简单但通用的RTP承载方法，用于非多路复用的MPEG-4基本流传输。 MPEG-4是国际标准化组织ISO/IEC JTC1/SC29/WG11的一个工作组，负责音频和视频内容压缩技术的标准制定。MPEG-4标准提供了丰富的工具，用于压缩多媒体数据，包括音频和视觉信息，将其打包成基本流。RFC3640的目标是解决在实时网络环境中如何有效地将这些基本流通过RTP进行传输的问题。该文档详细描述了RTP封装MPEG-4基本流的过程，包括定义了必要的头部字段和数据段结构，以便于网络设备和应用能够正确解析和处理这些流。它强调了在诸如VoIP（Voice over IP）和在线视频会议等应用场景中的重要性，因为这些场景对实时性和数据完整性有很高的要求。 RFC3640的目的是为了创建一个标准化的框架，使得不同厂商开发的MPEG-4解码器和客户端能够无障碍地通信，无需复杂的协议转换。这有助于简化网络部署和维护，提高系统的兼容性和互操作性。此外，文档还指出了其在互联网标准中的地位，并提醒读者查阅当前版的“互联网官方协议标准”(STD1)来获取该协议的最新标准化状态和建议改进的地方。版权方面，所有权利归互联网协会所有。 RFC3640为MPEG-4基本流的RTP传输提供了一个关键的指导，它不仅提升了多媒体内容在网络上的传输效率，还促进了不同系统之间的无缝集成，对于现代通信技术和多媒体服务的发展具有重要意义。

RFC 3640

Transport of MPEG-4 Elementary Streams November 2003

2.7. State Indication of MPEG-4 System Streams

ISO/IEC 14496-1 defines states for MPEG-4 system streams. So as to

convey state information when transporting MPEG-4 system streams,

this payload format allows for the optional carriage in the RTP

payload of the stream state for each contained Access Unit. Stream

states are used to signal "crucial" AUs that carry information whose

loss cannot be tolerated and are also useful when repeating AUs

according to the carousel mechanism defined in ISO/IEC 14496-1.

2.8. Random Access Indication

Random access to the content of MPEG-4 elementary streams may be

possible at some but not all Access Units. To signal Access Units

where random access is possible, a random access point flag can

optionally be carried in the RTP payload for each contained Access

Unit. Carriage of random access points is particularly useful for

MPEG-4 system streams in combination with the stream state.

2.9. Carriage of Auxiliary Information

This payload format defines a specific field to carry auxiliary data.

The auxiliary data field is preceded by a field that specifies the

length of the auxiliary data, so as to facilitate the skipping of

data without parsing it. The coding of the auxiliary data is not

defined in this document; instead, the format, meaning and signaling

of auxiliary information is expected to be specified in one or more

future RFCs. Auxiliary information MUST NOT be transmitted until its

format, meaning and signaling have been specified and its use has

been signaled. Receivers that have knowledge of the auxiliary data

MAY decode the auxiliary data, but receivers without knowledge of

such data MUST skip the auxiliary data field.

2.10. MIME Format Parameters and Configuring Conditional Fields

To support the features described in the previous sections, several

fields are defined for carriage in the RTP payload. However, their

use strongly depends on the type of MPEG-4 elementary stream that is

carried. Sometimes a specific field is needed with a certain length,

while in other cases such a field is not needed. To be efficient in

either case, the fields to support these features are configurable by

means of MIME format parameters. In general, a MIME format parameter

defines the presence and length of the associated field. A length of

zero indicates absence of the field. As a consequence, parsing of

the payload requires knowledge of MIME format parameters. The MIME

format parameters are conveyed to the receiver via SDP [

5] messages,

as specified in

section 4.4.1, or through other means.

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

RFC 3640

Transport of MPEG-4 Elementary Streams November 2003

2.11. Global Structure of Payload Format

The RTP payload following the RTP header, contains three octet-

aligned data sections, of which the first two MAY be empty, see

Figure 1.

+---------+-----------+-----------+---------------+

+---------+-----------+-----------+---------------+

<----------RTP Packet Payload----------->

Figure 1: Data sections within an RTP packet

The first data section is the AU (Access Unit) Header Section, that

contains one or more AU-headers; however, each AU-header MAY be

empty, in which case the entire AU Header Section is empty. The

second section is the Auxiliary Section, containing auxiliary data;

this section MAY also be configured empty. The third section is the

Access Unit Data Section, containing either a single fragment of one

Access Unit or one or more complete Access Units. The Access Unit

Data Section MUST NOT be empty.

2.12. Modes to Transport MPEG-4 Streams

While it is possible to build fully configurable receivers capable of

receiving any MPEG-4 stream, this specification also allows for the

design of simplified, but dedicated receivers, that are for example,

capable of receiving only one type of MPEG-4 stream. This is

achieved by requiring that specific modes be defined in order to use

this specification. Each mode may define constraints for transport

of one or more types of MPEG-4 streams, for instance on the payload

configuration.

The applied mode MUST be signaled. Signaling the mode is

particularly important for receivers that are only capable of

decoding one or more specific modes. Such receivers need to

determine whether the applied mode is supported, so as to avoid

problems with processing of payloads that are beyond the capabilities

of the receiver.

In this document several modes are defined for the transportation of

MPEG-4 CELP and AAC streams, as well as a generic mode that can be

used for any MPEG-4 stream. In the future, new RFCs may specify

other modes of using this specification. However, each mode MUST be

in full compliance with this specification (see

section 3.3.7).

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

剩余42页未读，继续阅读

bingbaobei

粉丝: 6

RFC 3640：MPEG-4 elementary stream RTP payload format标准

网络工程师必备：RFC标准文档全集8000套

安全超文本传输协议(SHTTP)详解

HTTP协议详解：RFC2616标准PDF版

RFC3501.rar_RFC3501_rfc 3501_rfc35_rfc3501 pdf_rfc3501.pdf

rfc2616.pdf

rfc2630.pdf

rfc3549.pdf

rfc6550.pdf

rfc5416.pdf

rfc2665.pdf

最新资源