MPEG-4 Elementary Streams的RTP传输负载格式

需积分: 1 103 浏览量更新于2024-06-22 收藏 62KB PDF 举报

"RFC-3640：RTP负载格式用于传输MPEG-4基本流" RFC-3640是一份由网络工作小组（Network Working Group）成员J. van der Meer、Philips Electronics、Apple Computer、Sun Microsystems Inc.、Apple Computer以及Philips Electronics的相关专家共同编写的互联网标准草案。该文档详细规定了互联网社区的标准协议，并欢迎讨论和改进建议。此RFC被收录在"Internet Official Protocol Standards"（STD1）中，明确了该协议的标准化状态和进程。文档的版权归互联网社会所有（2003年），并保留所有权利。其抽象部分指出，运动图像专家组（MPEG）是ISO/IEC JTC1/SC29 WG11下设的工作组，负责制定MPEG-4标准。MPEG定义了一套工具，用于将音频-视频信息压缩成基本流。RFC-3640具体定义了一个简单但通用的RTP（实时传输协议）负载格式，用于传输任何非复用的MPEG-4基本流。文档的主要内容可能包括以下几点： 1. **背景和动机**：解释为何需要一个特定的RTP负载格式来传输MPEG-4基本流，可能涉及到MPEG-4编码技术的特点和现有传输协议的局限性。 2. **MPEG-4基本流介绍**：对MPEG-4编码的基本概念、结构和特点进行概述，以及基本流如何与RTP协议相结合。 3. **RTP协议简介**：简要介绍RTP协议，包括其主要功能、报头结构以及在多媒体传输中的作用。 4. **RTP负载格式定义**：详细描述新的RTP负载格式，包括如何封装MPEG-4基本流，如何处理时间戳、序列号和其他控制信息，以确保数据的正确传输和同步。 5. **传输和恢复机制**：阐述在传输过程中如何处理丢包、乱序等问题，可能包括错误检测和恢复策略，如前向纠错（FEC）或重传请求（ARQ）。 6. **实现和兼容性**：提供实现该RTP负载格式的指导，以及与其他已存在的RTP协议的互操作性考虑。 7. **安全性考虑**：讨论在使用该RTP负载格式时可能遇到的安全问题，如数据完整性、隐私保护等，并给出相应建议。 8. **实例和分析**：可能包含具体的传输场景分析，通过实例展示如何应用该RTP负载格式来有效地传输MPEG-4内容。 9. **IANA（互联网数字分配机构）考虑**：如果涉及到任何需要IANA分配的标识符或参数，这部分会进行详细说明。通过这份RFC，开发者和网络工程师可以获得关于如何在实时网络环境中有效传输MPEG-4媒体内容的详细指南，从而提升多媒体应用的性能和用户体验。

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]

剩余43页未读，继续阅读

毕加索解锁

粉丝: 2665
资源: 24

MPEG-4 Elementary Streams的RTP传输负载格式

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

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

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

keytool -export -rfc -keystore upload-keystore.jks -alias upload -file upload_certificate.pem

RTP在封装MPEG1和MPEG2视频流时，如何设计其payload格式以确保数据的正确顺序和同步？

rfc4588 RTP重传有效载荷格式

在RTP传输中，如何使用RFC4585标准进行丢包检测和重传机制？

rfc viewer

如何根据RFC4585标准实现RTP数据流中的丢包检测与重传机制？请结合实际项目经验进行详细说明。

在利用RTP传输MPEG1和MPEG2视频流时，如何定义payload格式以维护流媒体的时序准确性和包间同步？

最新资源