H.264视频的RTP负载格式标准更新

需积分: 9 189 浏览量更新于2024-07-19 收藏 278KB PDF 举报

"RTPPayloadFormatforH.264Video" 本文档是关于RTP（Real-timeTransportProtocol）传输H.264视频的IETF标准规范，由Y.-K.Wang、R.Even、T.Kristensen、R.Jesup等人撰写，并于2011年由华为技术和Tandberg等机构提出，取代了之前的RFC3984。该文档详细描述了如何在RTP包中封装H.264视频编码器产生的一个或多个网络抽象层单元（NALUs），适用于从低带宽对话到高带宽视频点播等多种应用场景。 H.264是一种高效的视频编码标准，由国际电信联盟（ITU-T）推荐G.722委员会的建议H.264和国际标准化组织/国际电工委员会（ISO/IEC）的国际标准14496-10共同定义。尽管本规范不包含可扩展视频编码（SVC）和多视图视频编码（MVC）的扩展，但它们有单独的RTP负载格式定义。 RTP负载格式的主要目标是在保持高效传输的同时，适应不同复杂度和带宽需求的H.264视频流。它允许在一个RTP数据包中封装多个NALUs，这些NALUs可以是解码所需的独立视频帧或者是解码过程中的其他关键数据。这种设计使得RTP能够处理实时性和丢包恢复，同时支持交错传输和高比特率视频内容。文档的第14节总结了与RFC3984相比的更改，而第15节讨论了与前一版本的向后兼容性问题。这表明，随着技术的发展，RTP对H.264视频的传输规范也在不断优化和改进，以适应互联网视频流媒体服务的日益增长的需求和挑战。 RTP的这种负载格式对于互联网工程任务组（IETF）来说具有标准地位，意味着它被广泛接受并应用于实际的网络通信中，包括VoIP、视频会议、在线教育和流媒体服务等领域。通过使用该标准，开发者可以确保他们的H.264视频内容能够在不同的网络环境下顺利传输和播放，同时保证了良好的用户体验。 "RTPPayloadFormatforH.264Video"是一个关于如何在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]

剩余100页未读，继续阅读

hanpfei

粉丝: 615
资源: 10

H.264视频的RTP负载格式标准更新

RTP_Payload_Format_for_H.264_Video

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

RTP_PAYLOAD_TYPE_H264和RTP_PAYLOAD_TYPE_H265

ffmpeg5.0解码rtp协议传输的h264码流

wireshark分析h.264码流

java解包RTP提取h264

Android HWComposer将屏幕视频流以H.264编码通过RTP发送出去demo

(UDP 通信，同时具有H.264/H.265网络视频输出能力，传输协议包括 RTP，RTSP， ONVIF)输出H264/265的码流

h264和h265封装rtp的区别

linux ffmpeg接收ffmpeg -re -i test.h264 -c:a copy -c:v copy -f rtp rtp://192.168.22.34:5656推流的数据C完整代码

最新资源