H.264视频的RTP负载格式

需积分: 10 148 浏览量更新于2024-07-24 收藏 148KB PDF 举报

"RTP Payload Format for H.264 Video" 本文档描述了用于传输ITU-T建议H.264视频编码和与其技术上相同的ISO/IEC国际标准14496-10视频编码（不包括可扩展视频编码（SVC）和多视图视频编码（MVC）扩展）的RTP（Real-time Transport Protocol）负载格式。这些扩展的RTP负载格式在其他地方定义。H.264视频编码器产生的一个或多个网络抽象层单元（NALUs）可以在每个RTP负载中进行打包。这种负载格式具有广泛的应用性，能够支持从低比特率的简单对话使用，到互联网交织视频流，再到高比特率的点播视频。该文档取代了RFC3984，其中对与RFC3984的更改进行了总结，并在第14节中详细说明。第15节讨论了与RFC3684向后兼容的问题。 RTP是互联网工程任务组（IETF）制定的一种协议，用于实时传输音频、视频和其他数据。H.264是一种高效视频编码标准，用于压缩和解压缩数字视频，以减少带宽需求，同时保持高质量的视频传输。RTP负载格式是将H.264编码的视频数据封装在RTP包中的规范，它允许在不同网络环境下有效地传输视频流。该RTP负载格式的关键特性包括： 1. **NALU打包**：H.264编码器生成的NALUs可以被合并到单个RTP包中，或者分散到多个包中，这取决于NALU的大小和网络条件。这种灵活性有助于优化传输效率。 2. **头信息**：RTP包头包含时间戳和序列号，用于同步和重传丢失的数据包，确保视频流的连续性和质量。 3. **分段传输**：对于较大的NALUs，可以使用分段传输，即将一个NALU分成多个较小的部分，每个部分在一个单独的RTP包中发送。 4. **错误检测与恢复**：通过在负载中添加额外的校验和或冗余数据，可以检测和恢复传输错误，提高视频流的鲁棒性。 5. **适应性**：该格式支持根据网络状况动态调整视频质量，例如通过丢弃某些非关键NALUs来应对网络拥塞。 6. **兼容性**：虽然RFC3984已被本文档取代，但为了确保与旧系统的兼容，文档中讨论了如何处理向后兼容性问题。 7. **应用范围**：这种RTP负载格式适用于各种应用场景，包括VoIP、视频会议、在线教育、直播流媒体和点播服务等。通过理解这个RTP负载格式，开发者和网络工程师能够更有效地实现和优化H.264视频在互联网上的传输，确保用户能够获得流畅、无中断的视频体验。

RFC 6184 RTP Payload Format for H.264 Video May 2011

5.4. Packetization Modes

This memo specifies three cases of packetization modes:

o Single NAL unit mode

o Non-interleaved mode

o Interleaved mode

The single NAL unit mode is targeted for conversational systems that

comply with ITU-T Recommendation H.241 [3] (see Section 12.1). The

non-interleaved mode is targeted for conversational systems that may

not comply with ITU-T Recommendation H.241. In the non-interleaved

mode, NAL units are transmitted in NAL unit decoding order. The

interleaved mode is targeted for systems that do not require very low

end-to-end latency. The interleaved mode allows transmission of NAL

units out of NAL unit decoding order.

The packetization mode in use MAY be signaled by the value of the

OPTIONAL packetization-mode media type parameter. The used

packetization mode governs which NAL unit types are allowed in RTP

payloads. Table 3 summarizes the allowed packet payload types for

each packetization mode. Packetization modes are explained in more

detail in Section 6.

Table 3. Summary of allowed NAL unit types for each packetization

mode (yes = allowed, no = disallowed, ig = ignore)

Payload Packet Single NAL Non-Interleaved Interleaved

Type Type Unit Mode Mode Mode

-------------------------------------------------------------

0 reserved ig ig ig

1-23 NAL unit yes yes no

24 STAP-A no yes no

25 STAP-B no no yes

26 MTAP16 no no yes

27 MTAP24 no no yes

28 FU-A no yes yes

29 FU-B no no yes

30-31 reserved ig ig ig

Some NAL unit or payload type values (indicated as reserved in Table

3) are reserved for future extensions. NAL units of those types

SHOULD NOT be sent by a sender (direct as packet payloads, as

aggregation units in aggregation packets, or as fragmented units in

FU packets) and MUST be ignored by a receiver. For example, the

payload types 1-23, with the associated packet type "NAL unit", are

Wang, et al. Standards Track [Page 16]

RFC 6184 RTP Payload Format for H.264 Video May 2011

allowed in "Single NAL Unit Mode" and in "Non-Interleaved Mode" but

disallowed in "Interleaved Mode". However, NAL units of NAL unit

types 1-23 can be used in "Interleaved Mode" as aggregation units in

STAP-B, MTAP16, and MTAP24 packets as well as fragmented units in FU-

A and FU-B packets. Similarly, NAL units of NAL unit types 1-23 can

also be used in the "Non-Interleaved Mode" as aggregation units in

STAP-A packets or fragmented units in FU-A packets, in addition to

being directly used as packet payloads.

5.5. Decoding Order Number (DON)

In the interleaved packetization mode, the transmission order of NAL

units is allowed to differ from the decoding order of the NAL units.

Decoding order number (DON) is a field in the payload structure or a

derived variable that indicates the NAL unit decoding order.

Rationale and examples of use cases for transmission out of decoding

order and for the use of DON are given in Section 13.

The coupling of transmission and decoding order is controlled by the

OPTIONAL sprop-interleaving-depth media type parameter as follows.

When the value of the OPTIONAL sprop-interleaving-depth media type

parameter is equal to 0 (explicitly or per default), the transmission

order of NAL units MUST conform to the NAL unit decoding order. When

the value of the OPTIONAL sprop-interleaving-depth media type

parameter is greater than 0:

o the order of NAL units in an MTAP16 and an MTAP24 is not required

to be the NAL unit decoding order, and

o the order of NAL units generated by de-packetizing STAP-Bs, MTAPs,

and FUs in two consecutive packets is not required to be the NAL

unit decoding order.

The RTP payload structures for a single NAL unit packet, an STAP-A,

and an FU-A do not include DON. STAP-B and FU-B structures include

DON, and the structure of MTAPs enables derivation of DON, as

specified in Section 5.7.2.

Informative note: When an FU-A occurs in interleaved mode, it

always follows an FU-B, which sets its DON.

Informative note: If a transmitter wants to encapsulate a single

NAL unit per packet and transmit packets out of their decoding

order, STAP-B packet type can be used.

In the single NAL unit packetization mode, the transmission order of

NAL units, determined by the RTP sequence number, MUST be the same as

their NAL unit decoding order. In the non-interleaved packetization

Wang, et al. Standards Track [Page 17]

RFC 6184 RTP Payload Format for H.264 Video May 2011

mode, the transmission order of NAL units in single NAL unit packets,

STAP-As, and FU-As MUST be the same as their NAL unit decoding order.

The NAL units within an STAP MUST appear in the NAL unit decoding

order. Thus, the decoding order is first provided through the

implicit order within an STAP and then provided through the RTP

sequence number for the order between STAPs, FUs, and single NAL unit

packets.

The signaling of the value of DON for NAL units carried in STAP-B,

MTAP, and a series of fragmentation units starting with an FU-B is

specified in Sections 5.7.1, 5.7.2, and 5.8, respectively. The DON

value of the first NAL unit in transmission order MAY be set to any

value. Values of DON are in the range of 0 to 65535, inclusive.

After reaching the maximum value, the value of DON wraps around to 0.

The decoding order of two NAL units contained in any STAP-B, MTAP, or

a series of fragmentation units starting with an FU-B is determined

as follows. Let DON(i) be the decoding order number of the NAL unit

having index i in the transmission order. Function don_diff(m,n) is

specified as follows:

If DON(m) == DON(n), don_diff(m,n) = 0

If (DON(m) < DON(n) and DON(n) - DON(m) < 32768),

don_diff(m,n) = DON(n) - DON(m)

If (DON(m) > DON(n) and DON(m) - DON(n) >= 32768),

don_diff(m,n) = 65536 - DON(m) + DON(n)

If (DON(m) < DON(n) and DON(n) - DON(m) >= 32768),

don_diff(m,n) = - (DON(m) + 65536 - DON(n))

If (DON(m) > DON(n) and DON(m) - DON(n) < 32768),

don_diff(m,n) = - (DON(m) - DON(n))

A positive value of don_diff(m,n) indicates that the NAL unit having

transmission order index n follows, in decoding order, the NAL unit

having transmission order index m. When don_diff(m,n) is equal to 0,

the NAL unit decoding order of the two NAL units can be in either

order. A negative value of don_diff(m,n) indicates that the NAL unit

having transmission order index n precedes, in decoding order, the

NAL unit having transmission order index m.

Values of DON-related fields (DON, DONB, and DOND; see Section 5.7)

MUST be such that the decoding order determined by the values of DON,

as specified above, conforms to the NAL unit decoding order.

Wang, et al. Standards Track [Page 18]

RFC 6184 RTP Payload Format for H.264 Video May 2011

If the order of two NAL units in NAL unit decoding order is switched

and the new order does not conform to the NAL unit decoding order,

the NAL units MUST NOT have the same value of DON. If the order of

two consecutive NAL units in the NAL unit stream is switched and the

new order still conforms to the NAL unit decoding order, the NAL

units MAY have the same value of DON. For example, when arbitrary

slice order is allowed by the video coding profile in use, all the

coded slice NAL units of a coded picture are allowed to have the same

value of DON. Consequently, NAL units having the same value of DON

can be decoded in any order, and two NAL units having a different

value of DON should be passed to the decoder in the order specified

above. When two consecutive NAL units in the NAL unit decoding order

have a different value of DON, the value of DON for the second NAL

unit in decoding order SHOULD be the value of DON for the first,

incremented by one.

An example of the de-packetization process to recover the NAL unit

decoding order is given in Section 7.

Informative note: Receivers should not expect that the absolute

difference of values of DON for two consecutive NAL units in the

NAL unit decoding order will be equal to one, even in error-free

transmission. An increment by one is not required, as at the time

of associating values of DON to NAL units, it may not be known

whether all NAL units are delivered to the receiver. For example,

a gateway may not forward coded slice NAL units of non-reference

pictures or SEI NAL units when there is a shortage of bitrate in

the network to which the packets are forwarded. In another

example, a live broadcast is interrupted by pre-encoded content,

such as commercials, from time to time. The first intra picture

of a pre-encoded clip is transmitted in advance to ensure that it

is readily available in the receiver. When transmitting the first

intra picture, the originator does not exactly know how many NAL

units will be encoded before the first intra picture of the pre-

encoded clip follows in decoding order. Thus, the values of DON

for the NAL units of the first intra picture of the pre-encoded

clip have to be estimated when they are transmitted, and gaps in

values of DON may occur.

5.6. Single NAL Unit Packet

The single NAL unit packet defined here MUST contain only one NAL

unit of the types defined in [1]. This means that neither an

aggregation packet nor a fragmentation unit can be used within a

single NAL unit packet. A NAL unit stream composed by de-packetizing

single NAL unit packets in RTP sequence number order MUST conform to

the NAL unit decoding order. The structure of the single NAL unit

packet is shown in Figure 2.

Wang, et al. Standards Track [Page 19]

RFC 6184 RTP Payload Format for H.264 Video May 2011

Informative note: The first byte of a NAL unit co-serves as the

RTP payload header.

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

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

|F|NRI| Type | |

+-+-+-+-+-+-+-+-+ |

| |

| Bytes 2..n of a single NAL unit |

| |

| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| :...OPTIONAL RTP padding |

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

Figure 2. RTP payload format for single NAL unit packet

5.7. Aggregation Packets

Aggregation packets are the NAL unit aggregation scheme of this

payload specification. The scheme is introduced to reflect the

dramatically different MTU sizes of two key target networks: wireline

IP networks (with an MTU size that is often limited by the Ethernet

MTU size, roughly 1500 bytes) and IP-based or non-IP-based (e.g.,

ITU-T H.324/M) wireless communication systems with preferred

transmission unit sizes of 254 bytes or less. To prevent media

transcoding between the two worlds, and to avoid undesirable

packetization overhead, a NAL unit aggregation scheme is introduced.

Two types of aggregation packets are defined by this specification:

o Single-time aggregation packet (STAP): aggregates NAL units with

identical NALU-times. Two types of STAPs are defined, one without

DON (STAP-A) and another including DON (STAP-B).

o Multi-time aggregation packet (MTAP): aggregates NAL units with

potentially differing NALU-times. Two different MTAPs are

defined, differing in the length of the NAL unit timestamp offset.

Each NAL unit to be carried in an aggregation packet is encapsulated

in an aggregation unit. Please see below for the four different

aggregation units and their characteristics.

Wang, et al. Standards Track [Page 20]

剩余101页未读，继续阅读

marbleapple

粉丝: 0
资源: 1

H.264视频的RTP负载格式

H.264视频编码的RTP Payload格式标准

H.264视频的RTP负载格式规范

RFC-6184：H.264视频RTP封装标准

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

RTP Payload Format for H.264&H.265 Video

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

RFC 3984 - RTP Payload Format for H_264 Video

RFC3984 RTP Payload Format for H264 Video

RTP_Payload_Format_for_H.264_Video

RTP Payload Format for Scalable Video Coding

最新资源