H.264视频的RTP有效负载格式 (RFC-3984)

最新推荐文章于 2024-04-30 16:18:23 发布

苍澜如水

最新推荐文章于 2024-04-30 16:18:23 发布

阅读量1.2k

点赞数

分类专栏： RFC 文章标签： rfc

本文链接：https://blog.csdn.net/qq_33743182/article/details/120823445

版权

RFC 专栏收录该内容

10 篇文章 4 订阅

订阅专栏

RFC文档链接

本备忘录的状态

略

摘要

本备忘录描述了ITU-T建议的H.264视频编解码器和技术上相同的ISO/IEC国际标准14496-10视频编解码器的RTP有效载荷格式。RTP有效载荷格式允许在每个RTP有效载荷中对H.264视频编码器产生的一个或多个网络抽象层单元（NALU）进行分组。有效载荷格式具有广泛的适用性，因为它支持从简单的低比特率对话使用到具有交错传输的互联网视频流，再到高比特率视频点播的应用。

1、简介

1.1、H.264编解码器

本备忘录规定了视频编码标准（称为ITU-T建议H.264[1]和ISO/IEC国际标准14496第10部分[2]）（也称为高级视频编码或AVC）的RTP有效载荷规范。建议H.264于2003年5月获得ITU-T批准，批准的规范草案可供公众审查[8]。在本备忘录中，H.264首字母缩略词用于编解码器和标准，但本备忘录同样适用于编码标准的ISO/IEC对应物。

H.264视频编解码器具有非常广泛的应用范围，涵盖了所有形式的数字压缩视频，从低比特率互联网流媒体应用到HDTV广播和几乎无损编码的数字电影应用。据报告，与当前的技术状态相比，H.264的总体性能是，比特率节省了50%或更多。例如，据报道，数字卫星电视质量可以达到1.5 Mbit/s，而MPEG 2视频的当前运行点大约为3.5 Mbit/s[9]。

编解码器规范[1]本身在概念上区分了视频编码层（VCL）和网络抽象层（NAL）。VCL包含编解码器的信号处理功能；变换、量化和运动补偿预测等机制；和一个环路滤波器。它遵循当今大多数视频编解码器的一般概念，一种基于宏块的编码器，使用带运动补偿的帧间预测和残余信号的变换编码。VCL编码器输出片：包含整数个宏块的宏块数据和片头信息（包含片中第一个宏块的空间地址、初始量化参数和类似信息）的位字符串。片中的宏块按照扫描顺序排列，除非使用所谓的灵活宏块排序语法指定了不同的宏块分配。图像内预测仅在切片内使用。更多信息见[9]。

网络抽象层（NAL）编码器将VCL编码器的片输出封装到网络抽象层单元（NAL单元）中，网络抽象层单元适合在分组网络上传输或在面向分组的多路复用环境中使用。H.264的附录B定义了通过面向字节流的网络传输的此类NAL单元的封装过程。在本备忘录范围内，附件B不相关。

在内部，NAL使用NAL单位。NAL单元由一个单字节头和有效负载字节字符串组成。报头指示NAL单元的类型、NAL单元有效载荷中（可能）存在的比特错误或语法冲突，以及关于解码过程中NAL单元的相对重要性的信息。此RTP有效负载规范设计为不知道NAL单元有效负载中的位字符串。

H.264的主要特性之一是传输时间、解码时间以及切片和图片的采样或显示时间的完全解耦。在H.264中指定的解码处理不知道时间，并且H.264语法不携带诸如跳过帧的数目之类的信息（这在早期视频压缩标准中以时间参考的形式常见）。此外，还有影响许多图片的NAL单元，因此，它们本质上是不受时间影响的。因此，对于采样或呈现时间未定义或在传输时未知的NAL单元，RTP时间戳的处理需要一些特殊考虑。

1.2、参数集概念

H.264的一个非常基本的设计概念是生成自包含的数据包，以使诸如RFC2429[10]的报头复制或MPEG-4的报头扩展码（HEC）[11]等机制变得不必要。这是通过从媒体流中分离与多个片段相关的信息来实现的。这种更高层的元信息应该从包含切片数据包的RTP数据包流中可靠地、异步地提前发送。（带内发送此信息的规定也适用于没有适用于此目的的带外传输通道的应用。）高级参数的组合称为参数集。H.264规范包括两种类型的参数集：序列参数集和图片参数集。活动序列参数集在整个编码视频序列中保持不变，并且活动图片参数集在编码图片中保持不变。序列和图片参数集结构包含图片大小、采用的可选编码模式以及宏块到切片组映射等信息。

为了能够改变图片参数（例如图片大小），而不必将参数集更新同步地发送到切片分组流，编码器和解码器可以维护多个序列和图片参数集的列表。每个切片标头包含一个码字，该码字指示要使用的序列和图片参数集。

该机制允许将参数集的传输与数据包流分离，并通过外部手段（例如，作为能力交换的副作用）或通过（可靠或不可靠）控制协议进行传输。甚至可能它们从未被传输，而是由应用程序设计规范固定。

1.3、网络抽象层单元类型

有关NAL设计的教程信息可在[12]、[13]和[14]中找到。

所有NAL单元均由单个NAL单元类型的八位字节组成，该八位字节还共同充当此RTP有效负载格式的有效负载标头。NAL单元的有效载荷立即跟随。

[1]中规定了NAL单元类型八位字节的语法和语义，但NAL单元类型八位字节的基本属性总结如下。NAL单元类型八位字节的格式如下：

下面简要描述H.264规范中指定的NAL单元类型八位字节的组件的语义。

F: 1 bit

禁止零位。H.264规范将值1声明为语法冲突。

NRI: 2 bits

nal_ref_idc。值00表示NAL单元的内容不用于重建用于画面间预测的参考画面。这样的NAL单元可以被丢弃，而不会危及参考图片的完整性。大于00的值表示需要对NAL单元进行解码以保持参考图片的完整性。

Type: 5 bits

nal_单位_类型。该组件指定了[1]表7-1中定义的NAL装置有效载荷类型，以及本备忘录后面的内容。有关所有当前定义的NAL单元类型及其语义的参考，请参考[1]中的第7.4.1节。

本备忘录介绍了新的NAL单元类型，见第5.2节。本备忘录中定义的NAL单元类型在[1]中标记为未指定。此外，本规范扩展了第5.3节所述的F和NRI的语义。

2、惯例

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[3]中的说明进行解释。

本规范使用在处理位字段时设置和清除位的概念。设置位与将该位的值指定为1（On）相同。清除一个位与将该位赋值为0（关闭）相同。

3、范围

此有效负载规范只能用于通过RTP传输“裸”H.264 NAL单元流，而不是H.264附录B中讨论的比特流格式。很可能，本规范的第一个应用将在对话多媒体领域、视频电话或视频会议中，但有效载荷格式也涵盖其他应用，如互联网流媒体和IP电视。

4、定义和缩写

4.1、定义

本文件使用[1]的定义。为了方便起见，对[1]中定义的以下术语进行了总结：

访问单元：一组NAL单元，通常包含一个主编码图片。除了主编码图片之外，访问单元还可以包含一个或多个冗余编码图片或不包含编码图片的切片或切片数据分区的其他NAL单元。访问单元码总是可以解码出图片。

编码视频序列：一种访问单元序列，按解码顺序由瞬时解码刷新（IDR）访问单元和零个或多个非IDR访问单元组成，这些非IDR访问单元包括所有后续访问单元，但不包括任何后续IDR访问单元。

IDR访问单元：一种访问单元，其中主编码图片是IDR图片。

IDR图片：一种编码图片，仅包含I或SI切片类型的切片，在解码过程中导致“复位”。在对IDR图片进行解码之后，可以按照解码顺序对所有后续编码图片进行解码，而无需从在IDR图片之前解码的任何图片进行帧间预测。

主编码图片：对符合H.264的比特流进行解码处理所使用的图片的编码表示。主编码图片包含图片的所有宏块。

冗余编码图片：图片或图片的一部分的编码表示。冗余编码图片的内容不能被用于符合H.264的比特流的解码过程。冗余编码图片的内容可用于包含错误或丢失的比特流的解码过程。

VCL NAL单元：一个集合术语，用于指编码的片和编码的数据分区单元。

此外，以下定义适用：

解码顺序号（DON）：有效载荷结构中的一个字段，或指示NAL单元解码顺序的派生变量。DON的值在0到65535之间（含0到65535）。达到最大值后，DON的值将变为0。

NAL单元解码顺序：符合附录[1]第7.4.1.2节中给出的NAL装置顺序约束的NAL装置顺序。

传输顺序：以RTP序列号升序排列的数据包顺序（在模运算中）。在聚合分组内，NAL单元传输顺序与分组中NAL单元的出现顺序相同。

媒体感知网元（MANE）：一种网络元素，如中间盒或应用层网关，能够解析RTP有效负载头或RTP有效负载的某些方面，并对内容作出反应。

资料性说明：MANE的概念超越了普通路由器或网关，因为MANE必须知道信令（例如，了解媒体流的有效负载类型映射），并且在使用SRTP时必须信任它。使用mane的优点是，它们允许根据媒体编码的需要丢弃数据包。例如，如果MANE由于某一链路上的拥塞而不得不丢弃分组，则它可以识别其丢弃对用户体验的负面影响最小的那些分组，并移除它们以移除拥塞和/或保持低延迟。

缩写

DON: Decoding Order Number
DONB: Decoding Order Number Base
DOND: Decoding Order Number Difference
FEC: Forward Error Correction
FU: Fragmentation Unit
IDR: Instantaneous Decoding Refresh
IEC: International Electrotechnical Commission
ISO: International Organization for Standardization
ITU-T: International Telecommunication Union,
Telecommunication Standardization Sector
MANE: Media Aware Network Element
MTAP: Multi-Time Aggregation Packet
MTAP16: MTAP with 16-bit timestamp offset
MTAP24: MTAP with 24-bit timestamp offset
NAL: Network Abstraction Layer
NALU: NAL Unit
SEI: Supplemental Enhancement Information
STAP: Single-Time Aggregation Packet
STAP-A: STAP type A
STAP-B: STAP type B
TS: Timestamp
VCL: Video Coding Layer

5、RTP有效负载格式

5.1、RTP头使用

RFC 3550 附录[4]中规定了RTP头的格式，为了方便起见，在图1中重新打印了RTP头。此有效负载格式以与该规范一致的方式使用报头的字段。

当每个RTP数据包封装一个NAL单元时，第5.6节规定了推荐的RTP有效负载格式。第5.7节和第5.8节分别规定了聚合数据包和分段单元的RTP有效负载（以及某些RTP报头位的设置）。

要根据此RTP有效负载格式设置的RTP报头信息设置如下：

Marker bit (M): 1 bit

根据视频格式中M位的正常使用，为RTP时间戳指示的接入单元的最后一个分组设置，以允许有效的播放缓冲区处理。对于聚合数据包（STAP和MTAP），RTP报头中的标记位必须设置为聚合数据包最后一个NAL单元的标记位的值，如果它在自己的RTP数据包中传输。解码器可以使用该位作为接入单元的最后一个分组的早期指示，但不得依赖于该属性。

资料性说明：只有一个M位与承载多个NAL单元的聚合数据包相关联。因此，如果网关已将聚合数据包重新打包为多个数据包，则无法可靠地设置这些数据包的M位。

Payload type (PT): 7 bits

此新数据包格式的RTP有效负载类型的分配超出了本文档的范围，此处将不进行指定。有效负载类型的分配必须通过使用的配置文件或以动态方式执行。

Sequence number (SN): 16 bits

按照RFC 3550进行设置和使用。对于单个NALU和非交错分组模式，序列号用于确定NALU的解码顺序。

Timestamp: 32 bits

RTP时间戳设置为内容的采样时间戳。必须使用90 kHz的时钟频率。

如果NAL单元没有自己的定时属性（例如，参数集和SEI-NAL单元），则根据附录[1]的第7.4.1.2节，将RTP时间戳设置为包含NAL单元的接入单元的主编码图片的RTP时间戳。

MTAP的RTP时间戳设置见第5.7.2节。

接收器应忽略仅具有一个显示时间戳的访问单元中包含的任何图片定时SEI消息。相反，接收器应该使用RTP时间戳来同步显示过程。

RTP发送方不应该为不应显示为多个字段的图片发送图片定时SEI消息。

如果一个访问单元在图片定时SEI消息中携带了多个显示时间戳，则SEI消息中的信息应被视为相对于RTP时间戳，最早的事件发生在RTP时间戳给出的时间，随后的事件发生在RTP时间戳之后，由SEI消息图片定时值的差异给出。设tSEI1、tSEI2、…、tSEIn为接入单元的SEI消息中携带的显示时间戳，其中tSEI1是所有此类时间戳中最早的。让tmadjst（）是一个将SEI消息时间刻度调整为90 kHz时间刻度的函数。设TS为RTP时间戳。然后，与tSEI1关联的事件的显示时间是TS。与tSEIx关联的事件的显示时间，其中x是[2..n]是TS+tmadjst（tSEIx-tSEI1）。

资料性说明：在称为3:2下拉的操作中，通常需要将编码帧显示为场，在该操作中，使用隔行扫描在显示器上显示由编码帧组成的胶片内容。图片定时SEI消息允许为同一编码图片传送多个时间戳，因此3:2下拉过程得到完美控制。图片定时SEI消息机制是必要的，因为RTP时间戳中每个编码帧只能传送一个时间戳。

资料性说明：因为H.264允许解码顺序不同于显示顺序，所以RTP时间戳的值不能单调非递减地作为RTP序列号的函数。此外，RTCP报告中报告的到达间隔抖动值可能不是网络性能的可靠指示，因为到达间隔抖动的计算规则（RFC 3550第6.4.1节）认为数据包的RTP时间戳与其传输时间成正比。

5.2、RTP有效负载格式的通用结构

有效载荷格式定义了三种不同的基本有效载荷结构。接收机可以通过RTP有效负载的第一个字节来识别有效负载结构，该字节共同充当RTP有效负载报头，并且在某些情况下充当有效负载的第一个字节。此字节始终被构造为NAL单元头。NAL单元类型字段指示存在的结构。可能的结构如下：

单个NAL单元数据包：在有效负载中仅包含单个NAL单元。NAL标头类型字段将等于原始NAL单位类型；i、 e.范围为1至23（含1至23）。第5.6节中规定。

聚合数据包：用于将多个NAL单元聚合为单个RTP有效负载的数据包类型。此数据包有四个版本，即单次聚合数据包类型A（STAP-A）、单次聚合数据包类型B（STAP-B）、具有16位偏移量的多时间聚合数据包（MTAP）（MTAP16）和具有24位偏移量的多时间聚合数据包（MTAP）（MTAP24）。为STAP-A、STAP-B、MTAP16和MTAP24分配的NAL单元类型号分别为24、25、26和27。第5.7节中规定。

分段单元：用于在多个RTP数据包上对单个NAL单元进行分段。存在两个版本，FU-A和FU-B，分别用NAL装置类型编号28和29标识。第5.8节中规定。

表1 NAL单元类型及其有效载荷结构概述

Type	Packet	Type name	Section
0	undefined		-
1-23	NAL unit	Single NAL unit packet per H.264	5.6
24	STAP-A	Single-time aggregation packet	5.7.1
25	STAP-B	Single-time aggregation packet	5.7.1
26	MTAP16	Multi-time aggregation packet	5.7.2
27	MTAP24	Multi-time aggregation packet	5.7.2
28	FU-A	Fragmentation unit	5.8
29	FU-B	Fragmentation unit	5.8
30-31	undefined		-

资料性说明：本规范不限制封装在单个NAL单元数据包和碎片单元中的NAL单元的大小。封装在任何聚合数据包中的NAL单元的最大大小为65535字节。

5.3、NAL单元八位字节用法

第1.3节介绍了NAL单位八位元的结构和语义。为方便起见，NAL单元类型八位字节的格式如下所示：

本节根据本规范规定了F和NRI的语义。

F: 1 bit

forbidden_zero_bit. 值0表示NAL单元类型八位字节和有效负载不应包含位错误或其他语法冲突。值1表示NAL单元类型八位字节和有效负载可能包含位错误或其他语法冲突。

MANE应设置F位，以指示NAL单元中检测到的位错误。H.264规范要求F位等于0。当设置F位时，解码器在有效载荷或NAL单元类型八位字节中可能存在位错误或任何其他语法冲突。对于F位等于1的NAL单元，解码器最简单的反应是丢弃这样的NAL单元，并在丢弃的NAL单元中隐藏丢失的数据。

NRI: 2 bits

nal_ref_idc. 值00和非零值的语义与H.264规范保持不变。换言之，值00表示NAL单元的内容不用于重建画面间预测的参考画面。这样的NAL单元可以被丢弃，而不会危及参考图片的完整性。大于00的值表示需要对NAL单元进行解码以保持参考图片的完整性。

除上述规范外，根据该RTP有效载荷规范，大于00的NRI值表示编码器确定的相对传输优先级。与不太重要的NAL单元相比，MANE可以利用这些信息更好地保护更重要的NAL单元。最高传输优先级是11，其次是10，然后是01；最后，00是最低的。

资料性说明：NRI的任何非零值在H.264解码器中的处理方式相同。因此，当将NAL单元传递给解码器时，接收机不需要操纵NRI的值。

H.264编码器必须根据H.264规范（第7.4.1款）设置NRI值，当nal_单位_类型的值在1到12范围内（包括1到12）时。特别是，H.264规范要求，对于NAL_单元类型等于6、9、10、11或12的所有NAL单元，NRI的值应等于0。

对于NAL_unit_type等于7或8（分别表示序列参数集或图片参数集）的NAL单元，H.264编码器应将NRI的值设置为11（二进制格式）。对于NAL_unit_type等于5的主编码图片的编码片段NAL单元（表示属于IDR图片的编码片段），H.264编码器应将NRI的值设置为11（二进制格式）。

对于剩余的nal_单位_类型到NRI值的映射，可以使用以下示例，并且已经证明在特定环境中是有效的[13]。根据所使用的应用和H.264/AVC附录A配置文件，也可能需要其他映射。

资料性说明：数据分区在某些配置文件中不可用；e、例如，在主配置文件或基线配置文件中。因此，当符合允许数据分区的配置文件的视频比特流，而不是主配置文件或基线配置文件的流时，才可以出现nal单元类型2、3和4。

表2 主编码参考图片的编码切片和编码切片数据分区的NRI值示例

NAL Unit Type	Content of NAL unit	NRI (binary)
1	non-IDR coded slice	10
2	Coded slice data partition A	10
3	Coded slice data partition B	01
4	Coded slice data partition C	01

资料性说明：如前所述，根据H.264/AVC的规定，非参考图片的NRI值为00。

H.264编码器应将冗余编码参考图片的编码片段和编码片段数据分区NAL单元的NRI值设置为等于01（二进制格式）。

本备忘录第5.7节和第5.8节给出了24至29型NAL单元的NRI值定义。

对于NAL_unit_类型在13到23（包括13到23）范围内的NAL单元，没有给出NRI值的建议，因为这些值是为ITU-T和ISO/IEC保留的。对于NAL_unit_type等于0或在30到31（含30到31）范围内的NAL单元，未给出NRI值的建议，因为本备忘录中未规定这些值的语义。

5.4、打包方式

本备忘录规定了三种打包模式：

单NAL单元模式
非交织模式
交织模式

单NAL单元模式适用于符合ITU-T建议H.241[15]（见第12.1节）的会话系统。非交织模式针对可能不符合ITU-T建议H.241的会话系统。在非交织模式中，NAL单元以NAL单元解码顺序传输。交织模式的目标是不需要非常低的端到端延迟的系统。交织模式允许在NAL单元解码顺序之外传输NAL单元。

正在使用的打包模式可以通过可选packetization-mode MIME参数的值或通过外部方式发出信号。使用的打包模式控制RTP有效负载中允许的NAL单元类型。表3总结了每个打包模式允许的NAL单元类型。一些NAL单元类型值（表3中未定义）保留供将来扩展。这些类型的NAL单元不应由发送方发送，接收方必须忽略。例如，在“单个NAL单元模式”和“非交织模式”中允许具有相关分组类型“NAL单元”的类型1-23，但在“交织模式”中不允许。第6节将更详细地解释打包模式。

表3 每个打包模式允许的NAL单元类型汇总（是=允许，否=不允许，ig=忽略）

Type	Packet	Single NAL Unit Mode	Non-Interleaved Mode	Interleaved Mode
0	undefined	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	undefined	ig	ig	no

5.5、解码顺序号（DON）

在交织打包模式中，允许NAL单元的传输顺序不同于NAL单元的解码顺序。解码顺序号（DON）是有效负载结构中的一个字段，或指示NAL单元解码顺序的派生变量。第13节给出了非解码顺序传输和DON使用的基本原理和用例示例。

传输和解码顺序的耦合由可选的sprop-interleaving-depth MIME参数控制，如下所示。当可选sprop-interleaving-depth MIME参数的值等于0（显式或默认值）或外部方式不允许传输超出其解码顺序的NAL单元时，NAL单元的传输顺序必须符合NAL单元解码顺序。当可选sprop-interleaving-depth MIME参数的值大于0或允许通过外部方式传输超出其解码顺序的NAL单元时，

MTAP16和MTAP24中NAL单元的顺序不要求是NAL单元解码顺序
通过在两个连续数据包中解封装STAP Bs、MTAP和FU而生成的NAL单元的顺序不需要是NAL单元解码顺序。

单个NAL单元分组、STAP-a和FU-a的RTP有效载荷结构不包括DON。STAP-B和FU-B结构包括DON，MTAP的结构允许按照第5节的规定推导DON。

资料性说明：当FU-A以交错模式出现时，它始终跟随FU-B，FU-B将设置其DON。

资料性说明：如果发送器希望每个数据包封装一个NAL单元，并按照解码顺序发送数据包，则可以使用STAP-B数据包类型。

在单NAL单元分组模式中，由RTP序列号确定的NAL单元的传输顺序必须与其NAL单元解码顺序相同。在非交织分组模式中，单个NAL单元分组、STAP As和FU As中NAL单元的传输顺序必须与其NAL单元解码顺序相同。STAP中的NAL单元必须以NAL单元解码顺序出现。因此，解码顺序首先通过STAP内的隐式顺序提供，其次通过RTP序列号提供STAP、FUs和单个NAL单元分组之间的顺序。

第5.7.1节、第5.7.2节和第5.8节分别规定了STAP-B、MTAP和以FU-B开头的一系列碎片单元中NAL单元的DON值的信令。传输顺序中的第一NAL单元的DON值可以设置为任何值。DON的值在0到65535之间（含0到65535）。达到最大值后，DON的值将变为0。

包含在任何STAP-B、MTAP或以FU-B开头的一系列分段单元中的两个NAL单元的解码顺序确定如下。假设DON（i）是在传输顺序中具有索引i的NAL单元的解码顺序号。函数don_diff（m，n）指定如下：

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

don_diff（m，n）的正值表示具有传输顺序索引n的NAL单元按照解码顺序跟随具有传输顺序索引m的NAL单元。当don_diff（m，n）等于0时，两个NAL单元的NAL单元解码顺序可以是任意顺序。don_diff（m，n）的负值表示具有传输顺序索引n的NAL单元按照解码顺序先于具有传输顺序索引m的NAL单元。

DON 相关字段（DON、DONB 和 DOND；参见第 5.7 节）的值必须使得由 DON 的值确定的解码顺序（如上所述）符合 NAL 单元解码顺序。如果两个 NAL 单元在 NAL 单元解码顺序中的顺序发生了交换，并且新的顺序不符合 NAL 单元解码顺序，则 NAL 单元不得具有相同的 DON 值。如果 NAL 单元流中两个连续的 NAL 单元的顺序发生了切换，并且新的顺序仍然符合 NAL 单元解码顺序，则 NAL 单元可以具有相同的 DON 值。例如，当使用中的视频编码配置文件允许任意切片顺序时，允许编码图片的所有编码切片 NAL 单元具有相同的 DON 值。因此，具有相同 DON 值的 NAL 单元可以以任何顺序进行解码，并且具有不同 DON 值的两个 NAL 单元应该按照上面指定的顺序传递给解码器。当 NAL 单元解码顺序中的两个连续 NAL 单元具有不同的 DON 值时，解码顺序中第二个 NAL 单元的 DON 值应该是第一个的 DON 值加一。

第 7 节给出了恢复 NAL 单元解码顺序的解封装过程的示例。

资料性说明：接收器不应期望 NAL 单元解码顺序中两个连续 NAL 单元的 DON 值的绝对差将等于 1，即使在无差错传输中也是如此。不需要增加 1，因为在将 DON 的值与 NAL 单元相关联时，可能不知道是否所有 NAL 单元都被传送到接收器。例如，当数据包转发到的网络中比特率不足时，网关可能不会转发非参考图片的编码切片 NAL 单元或 SEI NAL 单元。在另一个示例中，现场广播不时被预编码的内容（例如商业广告）中断。预先传输预编码剪辑的第一个内部图片以确保它在接收器中随时可用。当传输第一个内部图片时，在按照解码顺序的预编码剪辑的第一个内部图片之前，发起者并不确切的知道将编码多少 NAL 单元。因此，当传输预编码片段的第一帧内图片的NAL单元时，必须估计它们的DON值，并且DON值中可能出现间隙。

5.6、单NAL单元数据包

此处定义的单个 NAL 单元数据包必须仅包含一个 NAL 单元，属于附录 [1] 中定义的类型。这意味着在单个 NAL 单元数据包中不能使用聚合数据包和分段单元。通过按 RTP 序列号顺序解封装单个 NAL 单元数据包组成的 NAL 单元流必须符合 NAL 单元解码顺序。单个NAL单元包的结构如图2所示。

资料性说明：NAL单元co-serves的第一个字节用作RTP有效负载报头。

5.7、聚合数据包

聚合数据包是此有效负载规范的 NAL 单元聚合方案。引入该方案是为了反映两个关键目标网络显着不同的 MTU 大小：有线 IP 网络（MTU 大小通常受以太网 MTU 大小限制；大约 1500 字节）和 IP 或非 IP（例如，ITU -T H.324/M) 的无线通信系统，具有 254 字节或更少的首选传输单元大小。为了防止两个网络之间的媒体转码，并避免不需要的打包开销，引入了 NAL 单元聚合方案。

本规范定义了两种类型的聚合包：

单次聚合包 (STAP)：聚合具有相同 NALU 时间的 NAL 单元。定义了两种类型的 STAP，一种不带 DON (STAP-A)，另一种包括 DON (STAP-B)。
多次聚合数据包 (MTAP)：聚合具有潜在不同 NALU 时间的 NAL 单元。定义了两种不同的 MTAP，它们的不同之处在于 NAL 单元时间戳偏移的长度。

术语 NALU 时间被定义为 RTP 时间戳的值，如果该 NAL 单元在其自己的 RTP 数据包中传输。

聚合包中要携带的每个NAL单元都封装在一个聚合单元中。请参阅下文了解四种不同的聚合单位及其特征。

聚合数据包的 RTP 有效载荷格式的结构如图 3 所示。

MTAP 和 STAP 共享以下打包规则： RTP 时间戳必须设置为要聚合的所有 NAL 单元的最早 NALU 时间。 NAL 单元类型八位字节的类型字段必须设置为适当的值，如表 4 所示。如果聚合的 NAL 单元的所有 F 位都为零，则必须清除 F 位；否则，它必须被设置。 NRI 的值必须是聚合包中携带的所有 NAL 单元的最大值。

表4 STAP 和 MTAP 的type字段

Type	Packet	Timestamp offset field length(in bits)	DON related fields (DON, DONB, DOND) present
24	STAP-A	0	no
25	STAP-B	0	yes
26	MTAP16	16	yes
27	MTAP24	24	yes

RTP 报头中的标记位被设置为聚合数据包的最后一个 NAL 单元的标记位的值，如果它是在它自己的 RTP 数据包中传输的。

一个聚合包的有效载荷由一个或多个聚合单元组成。四种不同类型的聚合单元见 5.7.1 和 5.7.2 节。一个聚合包可以根据需要携带多少个聚合单元；然而，聚合数据包中的数据总量显然必须适合一个 IP 数据包，并且大小应该选择为使得结果 IP 数据包小于 MTU 大小。聚合包不得包含第 5.8 节中指定的分段单元。聚合数据包不得嵌套；即，一个聚合包不得包含另一个聚合包。

5.7.1、单时间聚合数据包

每当聚合所有共享相同 NALU 时间的 NAL 单元时，都应使用单次聚合数据包 (STAP)。 STAP-A 的有效载荷不包括 DON，并且至少由一个单次聚合单元组成，如图 4 所示。 STAP-B 的有效载荷由 16 位无符号解码顺序号 (DON) 组成（以网络字节顺序）后跟至少一个单次聚合单元，如图 5 所示。

DON 字段指定 STAP-B 中按传输顺序的第一个 NAL 单元的 DON 值。对于STAP-B中出现顺序的每个连续NAL单元，DON的值等于（STAP-B中前一个NAL单元的DON值+1）%65536，其中'%'代表模运算。

一个单次聚合单元由16位无符号大小信息（按网络字节顺序）组成，以字节为单位指示后面的NAL单元的大小（不包括这两个八位字节，但包括NAL单元的NAL单元类型八位字节），后跟 NAL 单元本身，包括其 NAL 单元类型字节。单次聚合单元在 RTP 负载内按字节对齐，但它可能不会在 32 位字边界上对齐。图 6 展示了单次聚合单元的结构。

图 7 显示了一个包含 STAP-A 的 RTP 数据包示例。 STAP 包含两个单次聚合单元，在图中标记为 1 和 2。

图 8 显示了一个包含 STAP-B 的 RTP 数据包示例。 STAP 包含两个单次聚合单元，在图中标记为 1 和 2。

5.7.2、多时间聚合数据包（MTAP）

MTAP 的 NAL 单元有效载荷由 16 位无符号解码顺序号基 (DONB)（按网络字节顺序）和一个或多个多时间聚合单元组成，如图 9 所示。DONB 必须包含 DON 的值，用于 MTAP 的 NAL 单元中 NAL 单元解码顺序中的第一个 NAL 单元。

资料性说明：NAL单元解码顺序中的第一个NAL单元不一定是NAL单元封装在MTAP中的顺序中的第一个NAL单元。

本规范中定义了两种不同的多时间聚合单元。两者都由以下NAL单元的16位无符号大小信息（按网络字节顺序）、8位无符号解码顺序号差（DOND）和n位（按网络字节顺序）的时间戳偏移（TS偏移）组成 ) 对于这个 NAL 单元，其中 n 可以是 16 或 24。不同 MTAP 类型（MTAP16 和 MTAP24）之间的选择取决于应用程序：时间戳偏移越大，MTAP 的灵活性越高，但开销也越大。

MTAP16 和 MTAP24 的多时间聚合单元的结构分别如图 10 和 11 所示。数据包内聚合单元的开始或结束位置不需要在 32 位字边界上。下面的NAL单元的DON等于(DONB + DOND) % 65536，其中%表示取模运算。本备忘录未指定 MTAP 中的 NAL 单元如何排序，但在大多数情况下，应使用 NAL 单元解码顺序。

时间戳偏移字段必须设置为等于以下公式的值：如果 NALU 时间大于或等于数据包的 RTP 时间戳，则时间戳偏移等于（NAL 单元的 NALU 时间 - 数据包的 RTP 时间戳）。如果 NALU-time 小于数据包的 RTP 时间戳，则时间戳偏移等于 NALU-time +（2^32 - 数据包的 RTP 时间戳）。

对于 MTAP 中“最早的”多时间聚合单元，时间戳偏移必须为零。因此，MTAP 本身的 RTP 时间戳与最早的 NALU 时间相同。

资料性说明：如果聚合单元封装在单个 NAL 单元数据包中，则“最早的”多时间聚合单元是在 MTAP 的所有聚合单元中具有最小扩展 RTP 时间戳的单元。扩展时间戳是超过 32 位的时间戳，并且能够对时间戳字段的回绕进行计数，从而使人们能够在时间戳回绕时确定最小值。这种“最早”的聚合单元可能不是MTAP中聚合单元封装顺序中的第一个聚合单元。“最早的”NAL单元也不必与NAL单元解码顺序中的第一个NAL单元相同。

图12显示了一个RTP数据包示例，其中包含MTAP16类型的多时间聚合数据包，该数据包包含两个多次聚合单元，在图中标记为1和2。

图13显示了一个RTP数据包的示例，其中包含MTAP24类型的多时间聚合数据包，该数据包包含两个多次聚合单元，在图中标记为1和2。

5.8、分片单位（FUs）

这种有效负载类型允许将 NAL 单元分段为多个 RTP 数据包。在应用层这样做而不是依赖于较低层的分片（例如，通过 IP）具有以下优点：

有效载荷格式能够通过 IPv4 网络传输大于 64 KB 的 NAL 单元，这些单元可能存在于预先录制的视频中，尤其是高清格式（每张图片的切片数量有限制，这会导致限制每张图片的 NAL 单元数量，这可能会导致较大的 NAL 单元）。
分段机制允许将单个图片分段并应用通用前向纠错，如第 12.5 节所述。

分段仅针对单个 NAL 单元定义，而不针对任何聚合数据包。 NAL 单元的片段由该 NAL 单元的整数个连续八位字节组成。 NAL 单元的每个八位字节必须恰好是该 NAL 单元的一个片段的一部分。同一 NAL 单元的片段必须以升序 RTP 序列号的连续顺序发送（在第一个和最后一个片段之间没有发送同一 RTP 数据包流中的其他 RTP 数据包）。类似地，NAL 单元必须按 RTP 序列号顺序重新组装。

当 NAL 单元被分段并在分段单元 (FUs) 内传送时，它被称为分段 NAL 单元。 STAP 和 MTAP 不得分段。 FUs 不能嵌套；即，一个 FU 不得包含另一个 FU。

携带FU的RTP包的RTP时间戳被设置为分片的NAL单元的NALU时间。

图 14 显示了 FU-As 的 RTP 有效载荷格式。一个FU-A由一个八位字节的分片单元指示符、一个八位字节的分片单元头和一个分片单元净荷组成。

图 15 展示了 FU-B 的 RTP 有效载荷格式。一个FU-B由一个八位字节的分片单元指示符、一个八位字节的分片单元头、一个解码顺序号（DON）（按网络字节顺序）和一个分片单元有效载荷组成。换句话说，FU-B 的结构与 FU-A 的结构相同，只是多了一个 DON 字段。

NAL 单元类型 FU-B 必须在交错打包模式中用于分段 NAL 单元的第一个分段单元。 NAL 单元类型 FU-B 不得用于任何其他情况。换句话说，在interleaved packetization模式下，每个分片的NALU都有一个FU-B作为第一个分片，后面跟着一个或多个FU-A分片。

FU 指示符八位字节具有以下格式：

FU 指示符八位字节的类型字段中等于 28 和 29 的值分别标识 FU-A 和 FU-B。 F 位的使用在 5.3 节中描述。 NRI 字段的值必须根据分片 NAL 单元中的 NRI 字段的值设置。

FU 标头具有以下格式：

S: 1 bit

当设置为 1 时，Start 位指示分段 NAL 单元的开始。当后面的 FU 有效载荷不是分片 NAL 单元有效载荷的开始时，起始位设置为零。

E: 1 bit

当设置为 1 时，End 位表示分片 NAL 单元的结束，即有效载荷的最后一个字节也是分片 NAL 单元的最后一个字节。当后面的 FU 负载不是分片 NAL 单元的最后一个片段时，End 位设置为零。

R: 1 bit

保留位必须等于 0 并且必须被接收器忽略。

Type: 5 bits

附录[1] 的表 7-1 中定义的 NAL 单元有效载荷类型。

FU-Bs 中 DON 的值选择如 5.5 节所述。

资料性说明：FU Bs中的DON字段允许网关将NAL单元分段到FU Bs，而无需将传入的NAL单元组织到NAL单元解码顺序。

一个分段的 NAL 单元不得在一个 FU 中传输；即，起始位和结束位不得在同一个 FU 标头中都设置为 1。

FU有效载荷由分片NAL单元的有效载荷的分片组成，因此如果连续FU的分片单元有效载荷顺序连接，则可以重构分片NAL单元的有效载荷。分片 NAL 单元的 NAL 单元类型八位字节不包括在分片单元有效载荷中，反而分片 NAL 单元的 NAL 单元类型八位字节的信息在分片单元的FU 指示符八位字节的 F 和 NRI 字段和 FU 头的类型字段中。 FU 有效载荷可以有任意数量的八位字节并且可以为空。

资料性说明：在几乎无损的环境中，允许使用空FU来减少某类发送方的延迟。这些发送器的特征在于，它们在NALU完全生成之前（因此在NALU大小已知之前）打包NALU片段。如果不允许使用长度为零的NALU片段，则发送方必须生成后续片段的至少一位数据，然后才能发送当前片段。由于H.264的特点，有时几个宏块占用零个bit位，这是不可取的，并且可能增加延迟。但是，应仔细权衡零长度NALU的（潜在）使用与NALU丢失风险的增加，因为其传输使用了额外的数据包。

如果碎片单元丢失，则接收器应按照与相同碎片NAL单元对应的传输顺序丢弃所有后续碎片单元。

端点或MANE中的接收器可以将NAL单元的前n-1个片段聚合为（不完整的）NAL单元，即使没有接收到该NAL单元的片段n。在这种情况下，NAL单元的forbidden_zero_bit位必须设置为1，以指示语法冲突。

6、打包规则

第5.2节介绍了打包模式。第6.1节规定了一种以上包装模式通用的包装规则。第6.2、6.3和6.4节分别规定了单NAL单元模式、非交织模式和交织模式的分组规则。

6.1、通用的打包规则

无论使用何种打包模式，所有发送方都必须强制执行以下打包规则：

属于同一编码图片（因此共享相同的 RTP 时间戳值）的编码切片 NAL 单元或编码切片数据分区 NAL 单元可以按附录[1] 中定义的适用配置文件允许的任何顺序发送；然而，对于延迟关键系统，它们应该以它们的原始编码顺序发送以最小化延迟。请注意，编码顺序不一定是扫描顺序，而是 NAL 数据包可用于 RTP 堆栈的顺序。
参数集按照第 8.4 节中给出的规则和建议进行处理。
除序列或图片参数集 NAL 单元外，MANE 不得重复任何 NAL 单元，因为本备忘录和 H.264 规范均未提供识别重复 NAL 单元的方法。序列和图片参数集 NAL 单元可以重复以使其更可能正确接收，但任何此类重复不得影响任何活动序列或图片参数集的内容。重复应该在应用层执行，而不是通过复制 RTP 数据包（具有相同的序列号）来执行。

使用非交错模式和交错模式的发送者必须强制执行以下打包规则：

在RTP转换器中，MANE可以将单个NAL单元分组转换为一个聚合分组，将聚合分组转换为多个单个NAL单元分组，或者混合这两个概念。RTP转换器应至少考虑以下参数：路径MTU大小、非均匀保护机制（例如，根据RFC 2733[18]，通过基于分组的FEC，尤其是序列和图片参数集NAL单元和编码切片数据分区NAL单元）、系统的可承受延迟，以及接收器的缓冲能力。

资料性说明：根据RFC 3550，需要RTP转换器来处理RTCP。

6.2、单NAL单元模式

当可选packetization-mode MIME参数的值等于0、packetization-mode不存在或没有其他打包模式通过外部方式发出信号时，使用此模式。所有接收器必须支持此模式。它主要用于与使用ITU-T建议H.241[15]的系统兼容的低延迟应用（见第12.1节）。在此模式中只能使用单个NAL单元数据包。不得使用STAP、MTAP和FUs。单个NAL单元数据包的传输顺序必须符合NAL单元解码顺序。

6.3、非交织模式

当可选packetization-mode MIME参数的值等于1或通过外部方式打开模式时，将使用此模式。应支持此模式。它主要用于低延迟应用。在此模式中只能使用单个NAL单元数据包、STAP As和FU As。不得使用STAP Bs、MTAP和FU Bs。NAL单元的传输顺序必须符合NAL单元解码顺序。

6.4、交织模式

当可选packetization-mode MIME参数的值等于2或通过外部方式打开模式时，使用此模式。一些接收机可能支持这种模式。可以使用STAP Bs、MTAP、FU As和FU Bs。不得使用STAP As和单个NAL单元数据包。数据包和NAL单元的传输顺序受第5.5节规定的约束。

7、解包过程（信息性）

解包过程取决于实现。因此，应将以下描述视为适当实现的示例。也可以使用其他方案。与所述算法相关的优化是可能的。第7.1节介绍了单个NAL单元和非交织分组模式的解分组过程，而第7.2节介绍了交织模式的过程。第7.3节包括智能接收器的附加去封装指南。

所有与缓冲区管理相关的正常RTP机制都适用。特别地，删除重复的或过时的RTP分组（如RTP序列号和RTP时间戳所示）。为了确定解码的确切时间，必须考虑一些因素，例如允许适当的流间同步的可能故意延迟。

7.1、单NAL单元和非交织模式

接收机包括用于补偿传输延迟抖动的接收机缓冲器。接收机按接收顺序将传入的数据包存储到接收机缓冲器中。数据包按RTP序列号顺序被解封。如果解除封装的分组是单个NAL单元分组，则分组中包含的NAL单元直接传递给解码器。如果解除封装的分组是STAP-A，则分组中包含的NAL单元按照封装在分组中的顺序传递给解码器。如果解除封装的分组是FU-A，则将分段NAL单元的所有片段串联并传递给解码器。

资料性说明：如果解码器支持任意切片顺序，则图片的编码切片可以以任何顺序传递给解码器，而不管它们的接收和传输顺序如何。

7.2、交织模式

这些解封装规则的一般概念是将NAL单元从传输顺序重新排序为NAL单元解码顺序。

接收机包括接收机缓冲器，其用于补偿传输延迟抖动并将分组从传输顺序重新排序到NAL单元解码顺序。在本节中，在没有传输延迟抖动的假设下描述接收机操作。为了与也用于补偿传输延迟抖动的实际接收器缓冲区区分开，本节中的接收器缓冲区在此后称为解交织缓冲区。接收机还应为传输延迟抖动做好准备；例如，为传输延迟抖动缓冲和解交织缓冲保留单独的缓冲器，或者为传输延迟抖动和解交织使用接收器缓冲器。此外，接收机应在缓冲操作中考虑传输延迟抖动；例如，在开始解码和回放之前，通过额外的初始缓冲。

本节组织如下：第7.2.1小节介绍了如何计算解交织缓冲区的大小。第7.2.2小节规定了接收机处理如何将接收到的NAL单元组织到NAL单元解码顺序。

7.2.1、解交织缓冲区的大小

当会话设置中使用SDP Offer/Answer模型或任何其他能力交换过程时，接收流的属性应确保不会超过接收器的能力。在SDP Offer/Answer模型中，接收方可以使用deint-buf-cap MIME参数指示其分配解交织缓冲区的能力。发送方使用sprop-deint-buf-req MIME参数指示对解交织缓冲区大小的要求。因此，建议按字节数将解交织缓冲区大小设置为等于或大于sprop-deint-buf-req MIME参数的值。有关deint-buf-cap和sprop-deint-buf-req MIME参数的更多信息，请参见第8.1节；有关SDP Offer/Answer模型中使用这些参数的更多信息，请参见第8.2.2节。

在会话设置中使用声明性会话描述时，sprop-deint-buf-req MIME参数表示对解交织缓冲区大小的要求。因此，建议按字节数将解交织缓冲区大小设置为等于或大于sprop-deint-buf-req MIME参数的值。

7.2.2、解交织过程

接收器中有两种缓冲状态：初始缓冲和播放时缓冲。初始缓冲发生在初始化RTP会话。在初始缓冲后，开始解码和播放，并使用buffering-while-playing模式。

不管缓冲状态如何，接收机都按照接收顺序将传入的NAL单元存储在解交织缓冲器中，如下所示。聚合数据包的NAL单元分别存储在解交织缓冲区中。计算并存储所有NAL单位的DON值。

在以下函数和常数的帮助下，接收器操作如下所述：

函数AbsDON在第8.1节有规定。
函数don_diff在第5.5节中有规定。
常数N是可选的sprop-interleaving-depth MIME类型参数（参见第8.1节）的值加1。

初始缓冲持续到满足以下条件之一：

解交织缓冲区中有N个VCL NAL单元。
如果存在sprop-max-don-diff，则don_diff（m，n）大于sprop-max-don-diff的值，其中n对应于接收到的NAL单元中AbsDON值最大的NAL单元，m对应于接收到的NAL单元中AbsDON值最小的NAL单元。
初始缓冲的持续时间等于或大于可选sprop-init-buf-time MIME参数的值。

要从解交织缓冲器中移除的NAL单元规定如下：

如果解交织缓冲区包含至少N个VCL NAL单元，则NAL单元将从解交织缓冲区中移除，并按照下面指定的顺序传递给解码器，直到缓冲区包含N-1个VCL NAL单元。
如果存在sprop-max-don-diff，则don_diff（m，n）大于sprop-max-don-diff的所有NAL单元m将从解交织缓冲区中移除，并按照下面指定的顺序传递给解码器。在此，n对应于接收到的NAL单元中具有最大AbsDON值的NAL单元。

NAL单元传递给解码器的顺序规定如下：

设PDON为在RTP会话开始时初始化为0的变量。
对于与DON值相关联的每个NAL单元，DON距离计算如下。如果NAL单元的DON值大于PDON值，则DON距离等于DON-PDON。否则，DON距离等于65535-PDON+DON+1。
NAL单元按DON距离的升序传送到解码器。如果多个NAL单元共享相同的DON距离值，则可以按任意顺序将它们传递给解码器。
当已将所需数量的NAL单元传递给解码器时，PDON的值被设置为传递给解码器的最后一个NAL单元的DON值。

7.3、附加的解包指南

以下附加解包规则可用于实现可操作的H.264解包器：

智能RTP接收器（例如，在网关中）可识别丢失的编码片数据分区A（DPAs）。如果发现丢失的DPA，网关可以决定不发送相应的编码片数据分区B和C，因为它们的信息对于H.264解码器来说是没有意义的。通过这种方式，MANE可以通过丢弃无用的数据包而不解析复杂的比特流来减少网络负载。
智能RTP接收器（例如，在网关中）可以识别丢失的FUs。如果发现丢失的FU，网关可能会决定不发送相同分段NAL单元的后续FU，因为它们的信息对于H.264解码器没有意义。通过这种方式，MANE可以通过丢弃无用的数据包而不解析复杂的比特流来减少网络负载。
必须丢弃数据包或NALU的智能接收器应首先丢弃NAL单元类型八位字节的NRI字段值等于0的所有数据包/NALU。这将最大限度地减少对用户体验的影响，并保持参考图片的完整性。如果必须丢弃更多的数据包，则在丢弃具有较高NRI值的数据包之前，应丢弃具有较低NRI值的数据包。然而，丢弃NRI大于0的任何数据包很可能会导致解码器漂移，应该避免。

8、有效载荷格式参数

本节规定了可用于选择有效负载格式的可选特征和比特流的某些特征的参数。此处指定的参数是ITU-T H.264 | ISO/IEC 14496-10编解码器MIME子类型注册的一部分。还为使用SDP的应用程序提供了参数到会话描述协议（SDP）附录[5]的映射。可以在其他地方定义等效参数，以便与不使用MIME或SDP的控制协议一起使用。

一些参数向接收器提供将要发送的流的属性。对于流属性，所有这些参数的名称都以“sprop”开头。其中一些“sprop”参数受到其他有效负载或编解码器配置参数的限制。例如，sprop-parameter-sets 参数受profile-level-id 参数的约束。媒体发送方选择所有“sprop”参数，而不是接收方。“sprop”参数的这种不常见特征可能与某些信令协议概念不兼容，在这种情况下，应避免使用这些参数。

8.1、MIME注册

ITU-T H.264 | ISO/IEC 14496-10编解码器的MIME子类型是从IETF树中分配的。

接收器必须忽略任何未指定的参数。

媒体类型名称：video

媒体子类型名称：H264

必需参数：none

可选参数：

profile-level-id：

附录[1]中指定的序列参数集NAL单元中以下三个字节的base16附录[6]（十六进制）表示形式：1）profile_idc；2）此处称为profile iop的字节，从最高有效位开始，由constraint_set0_flag、constraint_set1_flag、constraint_set2_flag和reserved_zero_5bits的值按位重要性顺序组成；3）level_idc。请注意，在附录[1]中，reserved_zero_5bits必须等于0，但将来ITU-T或ISO/IEC可能会指定其其他值。

如果profile-level-id参数用于指示NAL单元流的属性，则它指示解码器在解码流时为了遵守附录[1]而必须支持的配置文件和级别。profile-iop字节指示NAL单元流是否也遵守所示配置文件的所有约束，如下所示。如果profile-iop的位7（最高有效位）、位6或位5等于1，则在NAL单元流中分别遵守基线配置文件、主配置文件或扩展配置文件的所有约束。

如果profile-level-id参数用于功能交换或会话设置过程，则它指示编解码器支持的配置文件以及信号配置文件支持的最高级别。profile-iop字节表示编解码器是否具有其他限制，因此编解码器仅支持算法功能的公共子集，以及使用profile-iop字节指明的配置文件和profile_idc指示的配置文件的限制。例如，如果一个编解码器只支持2.1及以下级别的Baseline profile和Main profile的编码工具的公共子集，profile-level-id变为42E015，其中42代表Baseline profile，E0表示仅支持所有配置文件的公共子集，15 表示级别 2.1。

资料性说明：功能交换和会话设置过程应提供单独列出每个支持的编解码器配置文件的功能的方法。例如，可以使用SDP Offer/Answer模型的N选一编解码器选择过程（见[7]第10.2节）。

如果不存在profile-level-id，则必须暗示在级别1没有附加约束的Baseline profile。

max-mbps, max-fs, max-cpb, max-dpb, and max-br：

这些参数可以用来表示接收器实现的能力。这些参数不得用于任何其他目的。profile-level-id 参数必须出现在包含任何这些参数的相同接收器能力描述中。profile-level-id 参数值中传达的级别必须是接收器完全能够支持的级别。 max-mbps、max-fs、max-cpb、max-dpb 和 max-br 可用于指示接收器的能力，这些能力扩展了信号级别所需的能力，如下所述。

当存在一个以上的参数（max-mbps、max-fs、max-cpb、max-dpb、max-br）时，接收器必须同时支持所有信号能力。例如，如果 max-mbps 和 max-br 都存在，则支持扩展帧率和比特率的信号等级。也就是说，接收器能够解码 NAL 单元流，其中宏块处理速率高达 max-mbps（包含），比特率高达 max-br（包含），编码的图片缓冲区大小是根据下面max br参数的语义中指定的方式得到的，其他属性符合 profile-level-id 参数值中指定的级别。

如果接收器能够支持级别A的所有属性，则接收器不得表示满足更高级别（此处称为级别A）要求的max-mbps、max-fs、max-cpb、max-dpb和max-br的值，与profile-level-id 参数值中指定的级别相比。

资料性说明：当使用可选MIME类型参数来表示NAL单元流的属性时，max mbps、max fs、max cpb、max dpb和max br不存在，并且profile-level-id的值必须始终确保NAL单元流完全符合指定的配置文件和级别。

max-mbps：

max mbps的值是一个整数，表示以每秒宏块为单位的最大宏块处理速率。max mbps参数表示接收器能够以高于在profile-level-id参数的值中传送的信号等级所要求的速率解码视频。当指明max-mbps时，接收器必须能够解码符合信号等级的NAL unit流，但附录[1]表A-1中用于信号等级的MaxMBPS值被max-mbps值替换的情况除外。max-mbps 的值必须大于或等于附录[1] 的表 A-1 中给出的级别对应的MaxMBPS 的值。发送方可以根据这点以比信号等级中指示的更高的图像速率发送给定大小的图像。

max-fs：

max-fs的值是一个整数，表示以宏块为单位的最大帧大小。max-fs参数表示接收器能够解码大于在profile-level-id参数的值中传送的信号等级所需的图像大小。当指明max-fs时，接收器必须能够解码符合信号等级的NAL单位流，但附录[1]表A-1中用于信号等级的MaxFS值被max-fs值替换的情况除外。max-fs的值必须大于或等于附录[1]表A-1中给出的等级对应的MaxFS值。发送方可以根据这点以比信号级别中指示的更低的帧速率发送更大的图片。

max-cpb：

max-cpb的值是一个整数，表示VCL HRD参数的最大编码图片缓冲区大小（以1000bits为单位）（见附录[1]的A.3.1 item i）和NAL HRD参数的最大编码图片缓冲区大小（以1200bits为单位）（见附录[1]的A.3.1 item j）。max-cpb参数表示接收器的内存大于在profile-level-id参数的值中传送的信号等级所需的最小编码图片缓冲内存量。当指明max-cpb时，接收机必须能够解码符合信号等级的NAL unit流，但附录[1]表A-1中用于信号等级的MaxCPB值被max-cpb值替换的情况除外。max-cpb值必须大于或等于附录[1]中的表A-1中给出的级别对应的MaxCPB值。发送方可以根据这点来构建编码视频流，其比特率的变化比附录[1]表A-1中的MaxCPB值更大。

资料性说明：编码图片缓冲器用于H.264的理想参考解码器（附录C）。建议在H.264编码器中使用假设参考解码器，以验证生成的比特流是否符合标准并控制输出比特率。因此，编码图片缓冲器在概念上独立于接收机中的任何其他潜在缓冲器，包括de-interleaving和de-jitter缓冲器。编码图片缓冲器不需要在H.264附录C中规定的解码器中实现，但是，符合标准的解码器可以具有任何缓冲安排，只要它们能够解码符合标准的比特流。因此，在实践中，视频解码器的输入缓冲器可以与接收机的de-interleaving和de-jitter缓冲器集成。

max-dpb：

max-dpb的值是一个整数，表示以1024bytes为单位的最大解码图片缓冲区大小。max-dpb参数表示接收器的内存大于在profile-level-id参数的值中传送的信号级别所需的解码图片缓冲内存的最小量。当指明max-dpb时，接收机必须能够解码符合信号级别的NAL unit流，但附录[1]表A-1中用于信号等级的MaxDPB值被max-dpb值替换的情况除外。因此，指明max-dpb的接收器必须能够在其解码图片缓冲器中存储以下数量的解码帧、互补场对和非成对场：

Min(1024 * max-dpb / ( PicWidthInMbs * FrameHeightInMbs * 256 * ChromaFormatFactor ),16)

PicWidthInMbs、FrameHeightInMbs和ChromaFormatFactor在附录[1]中定义。

max-dpb值必须大于或等于附录[1]中的表A-1中给出的级别对应的MaxDPB值。发送者可以根据这点构造具有改进压缩的编码视频流。

资料性说明：添加此参数主要是为了补充ITU-T建议H.245中的类似代码点，以便于信令网关设计。解码图像缓冲器存储重构样本，并且仅是视频解码器的属性。解码图片缓冲区的大小与RTP中使用的缓冲区之间没有关系，尤其是de-interleaving和de-jitter缓冲区。

max-br：

max-br的值是一个整数，表示VCL HRD参数的最大视频比特率，单位为1000bits/s（见附录[1]的A.3.1 item i），NAL HRD参数的最大视频比特率单位为1200bits/s（见附录[1]的A.3.1 item j）。

max-br参数表示接收器的视频解码器能够以高于在profile-level-id参数的值中传送的信号级别所要求的比特率解码视频。max-br值必须大于或等于附录[1]中的表A-1中给出的级别对应的MaxBR值。

当指明max-br时，接收器的视频编解码器必须能够解码符合在profile-level-id参数中传输的信号级别的NAL uint流，在级别指定的限制内有以下情况例外：

max-br值替换了附录[1]表A-1中用于信号等级的MaxBR值。
当 max-cpb 参数不存在时，以下公式的结果将替换附录[1] 的表 A-1 中的 MaxCPB 值：(MaxCPB of the signaled level) * max-br / (MaxBR of the signaled level)。

例如，如果接收器指明级别1.2的max-br等于1550的能力，则表示VCL HRD参数的最大视频比特率为1550 kbits/sec，NAL HRD参数的最大视频比特率为1860 kbits/sec，CPB大小为4036458比特（1550000/384000*1000*1000）。

max-br值必须大于或等于附录[1]中的表A-1中给出的级别对应的MaxBR值。发送者可以根据这点发送H.264附件A的级别定义中允许的更高比特率视频，以实现改进的视频质量。

资料性说明：添加此参数主要是为了补充ITU-T建议H.245中的类似代码点，以便于信令网关设计。根据该参数的值不能假设网络能够在任何给定时间处理这样的比特率。特别是，不能得出在拥塞控制约束下信号比特率是可能的结论。

redundant-pic-cap：

此参数表示接收器实现的功能。当等于0时，该参数表示接收器不尝试使用冗余编码图片来纠正未正确解码的主编码图片。当等于0时，接收器不能使用冗余片；因此，发送方应避免发送冗余片以节省带宽。当等于1时，接收器能够解码覆盖主解码图片中损坏区域的任何此类冗余片（至少部分），因此发送器可以发送冗余片。当参数不存在时，redundant-pic-cap必须使用0值。存在时，redundant-pic-cap的值必须为0或1。

当profile-level-id参数与redundant-pic-cap参数存在于相同的能力信令中，并且profile-level-id中指示的配置文件不允许使用冗余编码图片（例如，主配置文件）时，redundant-pic-cap的值必须等于0。当接收器指示redundant-pic-cap等于0时，接收的流不应包含冗余编码图片。

资料性说明：即使redundant-pic-cap等于0，只要解码器支持允许冗余编码图片的配置文件（基线、扩展），解码器也可以忽略冗余编解码器图片。

资料性说明：即使redundant-pic-cap等于1，接收机也可以选择其他错误隐藏策略来替换或补充冗余切片的解码。

sprop-parameter-sets：

该参数可用于传送在解码顺序中必须先于任何其他NAL单元的任何序列和图片参数集NAL单元（本文称为初始参数集NAL单元）。在任何能力交换过程中，该参数不得用于指示编解码器功能。该参数的值是附录[1] 的第 7.3.2.1 和 7.3.2.2 节中指定的初始参数集 NAL 单元的 base64 附录[6] 表示。参数集按解码顺序传送，并且不会发生参数集 NAL 单元的成帧。请注意，参数集 NAL 单元中的字节数通常小于 10，但图片参数集 NAL 单元可以包含数百个字节。

资料性说明：当SDP Offer/Answer模型中提供了几种有效负载类型，每种类型都有自己的sprop-parameter-sets参数时，接收方不能假设这些参数集没有使用冲突的存储位置（即参数集标识符的相同值）。因此，接收器应加倍缓冲所有sprop-parameter-sets，并使其可用于解码特定有效负载类型的解码器实例。

parameter-add：

此参数可用于指示是否允许此参数的接收器使用sprop-parameter-sets MIME参数在其信令响应中添加参数集。此参数的值为0或1。0等于false，不允许添加参数集。1等于true，允许添加参数集。如果参数不存在，则其值必须为1。

packetization-mode：

此参数表示RTP有效负载类型的属性或接收器实现的能力。只能指示一个配置点；因此，当声明支持多个打包模式的能力时，必须使用多个配置点（RTP有效负载类型）。

当packetization-mode的值等于0或packetization-mode不存在时，必须使用RFC 3984第6.2节中定义的单NAL单元模式。该模式在使用ITU-T建议H.241附录[15]的标准中使用（见第12.1节）。当packetization-mode的值等于1时，必须使用RFC 3984第6.3节中定义的非交织模式。当packetization-mode的值等于2时，必须使用RFC 3984第6.4节中定义的交织模式。packetization-mode的值必须是0到2（包括0到2）范围内的整数。

sprop-interleaving-depth：

当packetization-mode不存在或packetization-mode的值等于0或1时，此参数不得存在。当packetization-mode的值等于2时，此参数必须存在。

此参数表示NAL unit 流的属性。它指定以传输顺序在NAL单元流中任何VCL NAL单元之前，以解码顺序在VCL NAL单元之后的VCL NAL单元的最大数量。因此，当用于NAL单元解码顺序恢复的缓冲器大小至少是相对于VCL NAL单元的sprop-interleaving-depth+1的值时，保证接收机能够重构NAL单元解码顺序。

sprop-interleaving-depth的值必须是0到32767（包括0到32767）范围内的整数。

sprop-deint-buf-req：

当packetization-mode不存在或packetization-mode的值等于0或1时，此参数不得存在。当packetization-mode的值等于2时，此参数必须存在。

sprop-deint-buf-req 表示 NAL 单元流所需的解交织缓冲区大小。该参数的值必须大于或等于RFC 3984第7.2节中规定的此类解交织缓冲区所需的最大缓冲区占用率（以字节为单位）。当解交织缓冲区大小至少是以字节为单位的sprop-deint-buf-req的值时，可以保证接收机能够将交织的NAL单元解交织成NAL单元解码顺序。

sprop-deint-buf-req的值必须是0到4294967295（包括0到4294967295）范围内的整数。

资料性说明：sprop-deint-buf-req仅表示所需的解交织缓冲区大小。当网络抖动可能发生时，还必须为其配置适当大小的抖动缓冲区。

deint-buf-cap：

此参数表示接收器实现的能力，并指示接收器可用于重建NAL单元解码顺序的以字节为单位的解交织缓冲区空间量。接收器能够处理sprop-deint-buf-req参数值小于或等于此参数的任何流。

如果参数不存在，则deint-buf-cap必须使用0值。deint-buf-cap的值必须是0到4294967295（包括0到4294967295）范围内的整数。

资料性说明：deint-buf-cap仅表示接收器的解交织缓冲区的最大可能大小。当网络抖动可能发生时，还必须为其配置适当大小的抖动缓冲区。

sprop-init-buf-time：

该参数可用于表示NAL单元流的属性。如果packetization-mode的值等于0或1，则该参数不得存在。

该参数表示接收器在开始解码之前必须缓冲的初始缓冲时间，以从传输顺序恢复NAL单元解码顺序。该参数是（NAL单元的传输时间-NAL单元的解码时间）的最大值，假设传输可靠且瞬时，传输和解码的时间线相同，并且在第一个数据包到达时开始解码。

下面是指定 sprop-init-buf-time 值的示例。一个NAL单元流按照以下交错顺序发送，其中值对应解码时间，传输顺序为从左到右：

0 2 1 3 5 4 6 8 7 ...

假设NAL单元的传输速率稳定，传输时间为：

0 1 2 3 4 5 6 7 8 ...

从逐列传输时间中减去解码时间得到以下系列：

0 -1 1 0 -1 1 0 -1 1 ...

因此，就NAL单位发送时间的间隔而言，本示例中的sprop-init-buf-time的值为1。

该参数被编码为90-kHz时钟的时钟信号中的非负base10整数表示。如果参数不存在，则不定义初始缓冲时间值。否则，sprop-init-buf-time的值必须是0到4294967295（包括0到4294967295）范围内的整数。

除了声明sprop-init-buf-time外，接收器还应考虑传输延迟抖动缓冲，包括混频器、转换器、网关、代理、流量整形器和其他网络元件引起的延迟抖动缓冲。

sprop-max-don-diff：

该参数可用于表示NAL单元流的属性。不得将其用于信号发送器或接收器或编解码器功能。如果packetization-mode的值等于0或1，则该参数不得存在。 sprop-max-don-diff是一个介于0到32767（包括0到32767）之间的整数。如果 sprop-max-don-diff不存在，则该参数的值未指定。 sprop-max-don-diff的计算如下：

sprop-max-don-diff = max{AbsDON(i) - AbsDON(j)},

对于任意 i 和任意 j>i，其中 i 和 j 表示 NAL 单元在传输顺序中的索引，AbsDON 表示 NAL 单元的解码顺序号，在 65535 之后不回绕到 0。换句话说，AbsDON的计算如下：设m和n是传输顺序上的连续NAL单元。对于传输顺序中的第一个NAL单元（其索引为0），AbsDON（0）=DON（0）。对于其他NAL装置，AbsDON的计算如下：

If DON(m) == DON(n), AbsDON(n) = AbsDON(m)

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

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

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

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

其中DON（i）是在传输顺序中具有索引i的NAL单元的解码顺序号。RFC 3984第5.5节规定了解码顺序号。

资料性说明：接收机可使用sprop-max-don-diff触发接收机缓冲区中哪些NAL单元可传递给解码器。

max-rcmd-nalu-size：

该参数可以用于表示接收器的能力。该参数不得用于任何其他目的。该参数的值表示接收器可以有效处理的最大NALU大小（以字节为单位）。参数值是建议值，而不是严格的上限。发送方可以创建更大的NALU，但必须注意，处理这些NALU的成本可能高于符合限制的NALU。

max-rcmd-nalu-size的值必须是介于0到4294967295（包括0和4294967295）之间的整数。如果未指定此参数，则NALU大小不存在已知限制。发送方仍然必须考虑发送方和接收方之间可用的 MTU 大小，并且应该为此运行 MTU 发现。

例如，该参数由到H.223视频电话网关的IP驱动，其中小于H.223传输数据单元的NALU将更高效。网关可以终止IP；因此，MTU发现通常不会在网关之外工作。

资料性说明：将此参数设置为低于必要值可能会产生负值影响。

编码注意事项：

此类型仅定义为通过RTP（RFC 3550）传输。

附录[29]中定义了H.264/AVC视频的文件格式。此定义由其他文件格式使用，例如3GPP多媒体文件格式（MIME类型视频/3GPP）附录[30]或MP4文件格式（MIME类型视频/MP4）。

安全考虑：

参见RFC 3984第9节。

公共规范：

请参考RFC 3984及其第15节。

补充资料：

无。

文件扩展名：

无。

Macintosh文件类型代码：

无。

对象标识符或OID：

无。

联系人和电子邮件地址，以获取更多信息：

stewe@stewe.org

预期用途：

COMMON

作者：

stewe@stewe.org

更改控制器：

IETF Audio/Video Transport working group delegated from the IESG.

8.2、SDP参数

8.2.1、MIME参数到SDP的映射

MIME媒体类型video/H264字符串映射到会话描述协议（SDP）附录[5]中的字段，如下所示：

SDP的“m=”行中的媒体名称必须是video。
SDP的“a=rtpmap”行中的编码名称必须是H264（MIME子类型）。
“a=rtpmap”行中的时钟频率必须为90000。
可选参数"profile-level-id", "max-mbps", "max-fs", "max-cpb", "max-dpb", "max-br", "redundant-pic-cap", "sprop- parameter-sets", "parameter-add", "packetization-mode", "sprop- interleaving-depth", "deint-buf-cap", "sprop-deint-buf-req", "sprop-init-buf-time", "sprop-max-don-diff", and "max-rcmd-nalu- size"（如果存在），必须包含在SDP的“a=fmtp”行中。这些参数表示为MIME媒体类型字符串，以分号分隔的参数=值对列表的形式。

SDP中的媒体表示示例如下（基线配置文件，3.0级，可能不遵守主配置文件的某些约束）：

m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==

8.2.2、SDP Offer/Answer模式的使用

当H.264在Offer/Answer模型附录[7]中使用SDP通过RTP提供以协商单播使用时，以下限制和规则适用：

标识 H.264 媒体格式配置的参数是“profile-level-id”、“packetization-mode”，如果“packetization-mode”需要的话，还有“sprop-deint-buf-req”。这三个参数必须对称使用；即，如果一个或多个参数值不受支持，则应答者必须要么维护所有配置参数，要么完全删除媒体格式（有效载荷类型）。

资料性说明：对称使用要求仅适用于上述三个参数，而不适用于其他流属性和能力参数。

为了简化这些配置的处理和匹配，如附录 [7] 中所指定的，在offer中使用的相同 RTP 有效负载类型编号也应该在answer中使用。 answer不得包含offer中使用的有效负载类型编号，除非配置（“profile-level-id”、“packetization-mode”，如果存在“sprop-deint-buf-req”）与offer中的配置相同。

资料性说明：offerer在收到答复时，必须根据媒体类型（即视频/h264）和上述三个参数，将offer中未声明的有效负载类型与其已声明的任何有效负载类型进行比较，以确定所述配置是新的还是与已提供的配置等效。

参数“sprop-parameter-sets”、“sprop-deint-buf-req”、“sprop-interleaving-depth”、“sprop-max-don-diff”和“sprop-init-buf-time”描述了offerer或answerer为此媒体格式配置发送的 NAL 单元流的属性。这与 Offer/Answer 参数的正常使用不同：通常这些参数声明offerer或offerer能够接收的流的属性。在处理 H.264 时，假定offerer将能够接收使用提供的配置编码的媒体。

资料性说明：上述参数适用于声明实体以相同配置发送的任何流；即它们依赖于它们的来源。这些值在发送时可能必须应用于另一个有效负载类型，而不是绑定到有效负载类型，因为它们适用于配置。

能力参数（“max-mbps”、“max-fs”、“max-cpb”、“max-dpb”、“max-br”、“redundant-pic-cap”、“max-rcmd-nalu- size") 可用于声明进一步的功能。它们的解释取决于方向属性。当方向属性为sendonly时，参数描述发送方能够产生的RTP包和NAL单元流的限制。当方向属性为sendrecv或recvonly时，参数描述接收方接受的限制。
如上所述，offerer必须在交织的H.264流的请求中包括解交织缓冲器的大小。为了使offerer和answerer能够相互告知其解交织缓冲能力，建议双方都包含“deint-buf-cap”。当在第二轮请求和应答中选择“sprop-deint-buf-req”值时，可使用此信息。对于交错流，还建议考虑当接收机的能力未知时，提供具有不同缓冲要求的多个有效载荷类型。
如上所述使用“sprop-parameter-sets”参数。此外，answerer必须在其应答中维护在请求中收到的所有参数集。根据“parameter-add”参数的值，应用不同的规则：如果“parameter-add”为假（0），则answerer不得添加任何附加参数集。如果“parameter-add”为真（1），则answerer在其应答中可以向“sprop-parameter-sets”参数添加额外的参数集。独立于“parameter-add”的值的应答者还必须接受它在应大众声明的sprop-parameter-sets来接收视频流。

资料性说明：添加参数集时必须小心，以免使用冲突的参数集标识符覆盖已传输的参数集。

对于通过多播传送的流，还应适用以下规则：

流属性参数（“sprop-parameter-sets”、“sprop-deint-buf-req”、“sprop-interleaving-depth”、“sprop-max-don-diff”和“sprop-init-buf-time” ") answerer不得更改。因此，有效载荷类型可以原封不动地被接受，也可以被删除。
对于所有声明为 sendrecv 或 recvonly 的流，answerer必须支持接收器能力参数“max-mbps”、“max-fs”、“max-cpb”、“max-dpb”、“max-br”和“max-rcmd-nalu-size”；否则，必须执行以下操作之一：删除媒体格式，或拒绝会话。
对于声明为 sendrecv 或 recvonly 的所有流，answerer应该支持接收器能力参数redundant-pic-cap，如下所示：如果offerer指示redundant-pic-cap等于 0，answerer不应该在传输的流中包含冗余编码图片 . 否则（当redundant_pic_cap等于1时），推荐answerer如何使用冗余编码图片，这超出了本备忘录的范围。

以下是在不同的请求或应答和方向属性组合中如何解释不同参数的完整列表。

在使用“a=sendrecv”或未使用方向属性的请求和应答中，或在使用“a=recvonly”的请求和应答中，必须使用以下参数解释。

声明要接收的实际配置或属性：

- profile-level-id
- packetization-mode

声明要发送的流的实际属性（仅当“a=sendrecv”或未使用方向属性时适用）：

        - sprop-deint-buf-req
        - sprop-interleaving-depth
        - sprop-parameter-sets
        - sprop-max-don-diff
        - sprop-init-buf-time

声明接收器实现功能：

        - max-mbps
        - max-fs
        - max-cpb
        - max-dpb
        - max-br
        - redundant-pic-cap
        - deint-buf-cap
        - max-rcmd-nalu-size

声明如何进行Offer/Answer协商：

- parameter-add

在媒体流包含方向属性“a=sendonly”的请求或应答中，必须使用以下参数解释：

声明建议发送的流的实际配置和属性：

        - profile-level-id
        - packetization-mode
        - sprop-deint-buf-req

         - sprop-max-don-diff
        - sprop-init-buf-time
        - sprop-parameter-sets
        - sprop-interleaving-depth

在接收流时声明发送方的功能：

        - max-mbps
        - max-fs
        - max-cpb
        - max-dpb
        - max-br
        - redundant-pic-cap
        - deint-buf-cap
        - max-rcmd-nalu-size

声明如何进行Offer/Answer协商：

- parameter-add

此外，有必要考虑以下因素：

用于声明接收器能力的参数通常是可降级的；即，它们表达了发送者可能行为的上限。因此，发送方可以选择仅使用这些参数的较低/较小或相等值来设置其编码器。“sprop-parameter-sets”不得在发送方对其能力的声明中使用，因为参数集内携带的值的限制对于所使用的配置文件和级别是隐含的。
声明配置点的参数不可降级，“profile-level-id”参数的级别部分除外。这表示接收者希望使用的值，并且必须在发送者端逐字使用。
当声明发送方的功能，并且在此声明中使用不可降级的参数时，这些参数表示可接受的配置。为了实现高互操作性水平，通常建议提供多种替代配置；例如，对于打包模式。不可能在一种有效负载类型中提供多种配置。因此，当做出多个配置请求时，每个请求都需要与请求关联的自己的RTP有效负载类型。
接收器应该理解所有MIME参数，即使它只支持有效负载格式功能的一个子集。这确保接收者能够理解接收媒体的请求何时可以降级为请求的接收者所支持的内容。
应答者可以通过附加媒体格式配置来扩展请求。然而，为了能够使用它们，在大多数情况下，需要提供方提供第二次请求，以提供媒体发送方将使用的流属性参数。这也意味着，报价人必须能够接收此媒体格式配置，而不仅仅是发送它。
如果提议者希望在发送和接收之间具有非对称能力，则提议者必须提供不同的 RTP 会话；即，不同的媒体行分别声明为“recvonly”和“sendonly”。这可能会对系统产生进一步的影响。

8.2.3、在声明性会话描述中的使用

当H.264 over RTP使用SDP以声明式风格提供时，如在RTSP 附录[27]或SAP 附录[28]中，以下注意事项是必要的。

所有能够指示 NAL 单元流和接收器两者属性的参数用于指示 NAL 单元流的属性。例如，在本例中，参数“profile-level-id”声明流使用的值，而不是发送方的功能。这导致必须使用以下参数解释：

声明实际配置或属性：

        - profile-level-id
        - sprop-parameter-sets
        - packetization-mode
        - sprop-interleaving-depth
        - sprop-deint-buf-req
        - sprop-max-don-diff
        - sprop-init-buf-time

不可用：

        - max-mbps
        - max-fs
        - max-cpb
        - max-dpb
        - max-br
        - redundant-pic-cap
        - max-rcmd-nalu-size
        - parameter-add
        - deint-buf-cap

SDP接收器需要支持提供的所有参数和参数值；否则，接收方必须拒绝（RTSP）或不参与（SAP）会话。会话的创建者需要使用接收应用程序预期支持的值。

8.3、示例

预期双方都发送和接收的 SIP Offer/Answer 交换可能如下所示。仅显示了 SDP 的媒体编解码器特定部分。由于文本限制，一些行被换行。

Offerer -> Answer SDP message:

        m=video 49170 RTP/AVP 100 99 98
        a=rtpmap:98 H264/90000
        a=fmtp:98 profile-level-id=42A01E; packetization-mode=0;
                         sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
        a=rtpmap:99 H264/90000
        a=fmtp:99 profile-level-id=42A01E; packetization-mode=1;
                         sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
        a=rtpmap:100 H264/90000
        a=fmtp:100 profile-level-id=42A01E; packetization-mode=2;
                           sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==;
                           sprop-interleaving-depth=45; sprop-deint-buf-req=64000;
                           sprop-init-buf-time=102478; deint-buf-cap=128000

上述请求以三种不同的打包格式呈现相同的编解码器配置。 PT 98代表单NALU模式，PT 99代表非交错模式； PT 100 表示交错模式。在交织模式的情况下，如果应答表明支持 PT 100，则offerer将使用的交织参数也包括在内。在所有三种情况下，当从提供者接收流时，接受此配置（profile-level-id和packetization-mode）的参数“sprop-parameter-sets”都传达了answerer所需的初始参数集。请注意，“sprop-parameter-sets”的值虽然在上面的示例中相同，但对于每种有效负载类型可能不同。

Answerer -> Offerer SDP message:

        m=video 49170 RTP/AVP 100 99 97
        a=rtpmap:97 H264/90000
        a=fmtp:97 profile-level-id=42A01E; packetization-mode=0;
                         sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==,As0DEWlsIOp==,KyzFGleR
        a=rtpmap:99 H264/90000
        a=fmtp:99 profile-level-id=42A01E; packetization-mode=1;
                         sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==,As0DEWlsIOp==,KyzFGleR;                          max-rcmd-nalu-size=3980
        a=rtpmap:100 H264/90000
        a=fmtp:100 profile-level-id=42A01E; packetization-mode=2;
                           sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==,As0DEWlsIOp==,KyzFGleR;                            sprop-interleaving-depth=60;
                           sprop-deint-buf-req=86000; sprop-init-buf-time=156320;
                           deint-buf-cap=128000; max-rcmd-nalu-size=3980

由于Offer/Answer协商包括发送流和接收流，请求表示offerer愿意接收的确切参数，而应答表示answerer接受接收的确切参数。在这种情况下，offerer声明它愿意接收有效载荷类型 98。answerer通过声明等效的有效载荷类型 97 来接受这一点；即，它对于三个参数“profile-level-id”、packetization-mode 和“sprop-deint-buf-req”具有相同的值。这对于offerer和answerer关于声明属性的参数具有以下含义。offerer最初在 PT=98 的有效载荷定义中声明了“sprop-parameter-sets”的某个值。然而，由于answerer将其接受为 PT=97，当offerer发送 PT=97 时，现在必须改用 PT=98 中的“sprop-parameter-sets”值。类似地，当answerer向offerer发送 PT=98 时，它必须使用它在 PT=97 中声明的属性参数。

answerer还接受有效载荷类型 99 和 100 代表的两种配置的接收。它为answerer-to-offerer的方向提供初始参数集，以及将用于发送有效载荷类型的缓冲相关参数。它还通过提供“deint-buf-cap”参数为offerer提供了用于解交织操作的内存限制。这仅在offerer决定进行第二次请求时有用，它可以将新值考虑在内。“max-rcmd-nalu-size”表示answerer可以有效地处理最大为 3980 字节的 NALU。但是，不能保证网络支持此大小。

请注意，上例中的参数集不代表H.264编解码器的合法操作点。 base64 字符串仅用于说明。

8.4、参数集注意事项

H.264参数集是视频编解码器的基本组成部分，对其运行至关重要；见第1.2节。由于其特性及其对解码过程的重要性，丢失或错误传输的参数集很难在接收器处被本地隐藏。对损坏参数集的引用通常会对解码过程产生致命的结果。例如，由于参数集数据结构的错误传输或丢失，以及参数集更新的不及时传输，可能会发生损坏。因此，以下建议作为RTP发送器实现者的指南提供。

可以使用三种不同的原则传输参数集NALUs：

A、在实际RTP会话之前使用会话控制协议（带外）。

B、在正在进行的RTP会话期间使用会话控制协议（带外）。

C、在正在进行的RTP会话期间，在有效负载（带内）中的RTP流内。

有必要在会话控制协议中实现原则 A 和 B。 SIP 和 SDP 可以按照 SDP Offer/Answer 模型和本备忘录前面部分中的描述使用。本节包含如何在会话控制协议中实现原则A和原则B的指南。它独立于所使用的特定协议。原则C由本规范中定义的RTP有效负载格式支持。

除非为RTP提供了可靠的传输，否则图片和序列参数集NALUs不应在RTP有效载荷中传输，因为任一类型的参数集的丢失可能会阻止相应RTP流的相当大一部分的解码。因此，建议使用可靠的会话控制协议（即，使用上述原则a或原则B）传输参数集。

在本节的其余部分中，假定带外信令提供参数集NALUs的可靠传输，而带内传输不提供。如果使用参数集的带内信令，发送方应考虑错误特性，并使用机制提供正确交付参数集的高概率。增加正确接收概率的机制包括分组重复、FEC和重传。使用不可靠的带外控制协议与带内信令（可能丢失）具有类似的缺点，此外，还可能导致同步困难（见下文）。因此，不建议这样做。

可以使用原则B和C在会话的生存期内添加或更新参数集。要求参数集在引用它们的NAL单元之前出现在解码器中。更新或添加参数集可能会导致进一步的问题，因此应考虑以下建议。

当添加或更新参数集时，原则C容易出现如上所述的传输错误，因此建议使用原则B。
添加或更新参数集时，应注意确保任何参数集在使用前交付。带外信令和带内业务之间通常不存在同步。如果使用带外信令，建议发送方在确认信令协议的发送之前，不要开始发送需要更新参数集的NALUs。
更新参数集时，应考虑以下同步问题。当覆盖接收器上的参数集时，发送方必须确保网络或接收器缓冲区中的任何NALU都不需要有问题的参数集。否则，可能会使用错误的参数集进行解码。为了减少这个问题，建议只覆盖那些在足够长的时间内没有使用的参数集（以确保所有相关的NALU都已使用），或者添加一个新的参数集（这可能会对视频编码的效率产生负面影响）。
添加新参数集时，将使用以前未使用的参数集标识符。这避免了上一段中确定的问题。但是，在多方会话中，除非使用同步控制协议，否则存在多个实体试图为同一标识符添加不同参数集的风险，这必须避免。
在同一RTP会话中使用原则B和原则C添加或修改参数集可能会导致参数集不一致，因为控件和RTP通道之间缺乏同步。因此，除非能够提供足够的同步，否则原则B和C不得同时用于同一会话。

在某些情况下（例如，当仅使用与H.241对应的有效载荷格式规范的子集时），不可能采用带外参数集传输。在这种情况下，参数集必须在带内传输。这里，与比特流中的非参数集数据的同步是隐式的，但是必须考虑丢失的可能性。应使用上述机制降低损失概率。

当最初使用原则 A 提供参数集，然后在带内添加或更新（原则 C）时，存在与更新带外传递的参数集相关联的风险。如果接收机错过了一些带内更新（例如，由于丢失或延迟），这些接收机将尝试使用过时的参数解码比特流。建议在带外和带内参数集之间划分参数集ID。

为了使H.264编码器具有最大的灵活性和最佳性能，如果可能的话，建议允许任何发送方添加其自己的参数集以在会话中使用。只有在会话拓扑阻止参与者添加自己的参数集的情况下，才能将“parameter-add”参数设置为false。

9、安全考虑

使用本规范中定义的有效负载格式的RTP数据包受RTP规范附录[4]和任何适当RTP配置文件（例如附录[16]）中讨论的安全注意事项的约束。这意味着媒体流的机密性是通过加密实现的；例如，通过应用SRTP附录[26]。由于与此有效负载格式一起使用的数据压缩是端到端应用的，因此任何加密都需要在压缩后执行。

使用压缩技术的数据编码存在潜在的拒绝服务威胁，这种压缩技术具有非均匀的接收端计算负载。攻击者可以向流中注入难以解码的病理数据报，从而导致接收器过载。H.264特别容易受到此类攻击，因为生成包含影响许多未来NAL单元解码过程的NAL单元的数据报非常简单。因此，建议使用至少RTP分组的数据源认证和数据完整性保护；例如，使用SRTP 附录[26]。

请注意，确保RTP数据包及其有效负载的机密性和完整性的适当机制非常依赖于应用程序以及所采用的传输和信令协议。因此，尽管上面给出了SRTP作为示例，但存在其他可能的选择。

解码器必须谨慎处理用户数据SEI消息，特别是如果它们包含活动元素，并且必须将其适用范围限制为包含流的表示。

具有身份验证、完整性或机密性保护的端到端安全性将防止MANE执行除丢弃完整数据包以外的媒体感知操作。并且在保密保护的情况下，它甚至将被阻止以媒体感知的方式执行数据包丢弃。为了允许任何MANE执行其操作，它必须是安全上下文建立中包含的受信任实体。

10、拥塞控制

RTP 的拥塞控制应根据 RFC 3550 附录[4] 和任何适用的 RTP 配置文件（例如，RFC 3551 附录[16]）使用。如果使用尽力而为服务，则附加要求是：此有效负载格式的用户必须监控数据包丢失，以确保数据包丢失率在可接受的参数范围内。如果通过相同网络路径并经历相同网络条件的TCP流将实现在合理时间尺度上测量的平均吞吐量，即不小于RTP流所实现的平均吞吐量，则认为丢包是可接受的。可以通过实现拥塞控制机制来适应传输速率（或分层多播会话订阅的层数），或者如果丢失率高得令人无法接受，则通过安排接收机离开会话来满足该条件。

当使用实时编码时，遵守拥塞控制原则所需的比特率自适应很容易实现。然而，当传输预编码内容时，带宽自适应要求以不同比特率提供相同内容的多个编码表示，或者比特流中存在非参考图片或子序列[22]。不同表示之间的切换通常可以在同一RTP会话中执行；例如，通过采用称为扩展配置文件的SI/SP片的概念，或通过在IDR图片边界处切换流。只有当不可降级的参数（例如配置文件/级别 ID 的配置文件部分）需要更改时，才需要终止和重新启动媒体流。这可以通过使用不同的 RTP 负载类型来实现。

MANE可遵循第7.3节中概述的建议，并在数据包流因先前的数据包丢失而损坏时，从数据包流中删除某些不可用的数据包。在某些特殊情况下，这有助于减少网络负载。

11、IANA考虑

IANA注册了一个新的MIME类型；见第8.1节。

12、资料性附录：应用示例

该有效负载规范在使用上非常灵活，以覆盖H.264预期的极其广泛的应用空间。然而，这种巨大的灵活性也使得实现者很难决定一个合理的打包方案。在不久的将来，有关如何将本规范应用于实际场景的一些信息可能会以学术出版物、测试模型软件和描述的形式出现。然而，这里也描述了一些初步的使用场景。

12.1、符合ITU-T建议H.241附录A的视频电话

使用H.264作为可选视频压缩方案的基于H.323的视频电话系统需要支持H.241附录A[15]作为分组方案。该附件中定义的打包机制在技术上与本规范的一小部分相同。

当系统根据 H.241 附件 A 运行时，参数集 NAL 单元在带内发送。仅使用单个 NAL 单元数据包。许多这样的系统不是定期发送IDR图片，而是仅在用户交互或控制协议方式需要时才发送；例如，当在多点控制单元中的视频通道之间切换或用于反馈请求的错误恢复时。

12.2、视频电话，无切片数据分区，无 NAL 单元聚合

该方案的 RTP 部分已实现和测试（尽管不是控制协议部分；见下文）。

在大多数现实世界的视频电话应用程序中，图片参数（如图片大小或可选模式）在连接的生命周期内不会改变。因此，所有必要的参数集（通常只有一个）作为能力交换/公告过程的副作用发送，例如，根据本文件第8.2节规定的SDP语法。由于所有必要的参数集信息都是在RTP会话开始之前建立的，因此不需要发送任何参数集NAL单元。切片数据分区也没有使用。因此，RTP分组流基本上由携带单个编码片段的NAL单元组成。

编码器选择编码片NAL单元的大小，以便它们提供最佳性能。通常，这是通过使编码片大小适应IP网络的MTU大小来实现的。对于较小的图片大小，这可能导致每包一张图片的策略。帧内刷新算法可清除数据包丢失和由此产生的漂移相关伪影。

12.3、视频电话，使用NAL单元聚合的交错分组

该方案允许更好的错误隐藏，并用于基于H.263的设计中，使用RFC2429分组附录[10]。附录[12]已经实施，并报告了良好的结果。

VCL编码器对源图片进行编码，以便将一个MB行的所有宏块（MB）分配给一个切片。具有偶数MB行地址的所有片合并到一个STAP中，具有奇数MB行地址的所有片合并到另一个STAP中。这些STAP作为RTP数据包传输。参数集的建立如上所述。

请注意，在这里使用STAP是至关重要的，因为大量的单个片段（CIF图片为18个）将导致不可接受的高IP/UDP/RTP报头开销（除非使用源代码工具FMO，这在本场景中不被假定）。此外，一些无线视频传输系统，例如H.324M和3GPP中指定的基于IP的视频电话，可能使用相对较小的传输分组大小。例如，H.223 AL3 SDU的典型MTU大小约为100字节附录[17]。根据该分组方案编码各个片段在有线和无线网络之间的通信中提供了进一步的优势，因为各个片段可能小于无线系统的优选最大分组大小。因此，网关可以将有线网络中使用的STAPs转换为仅具有一个NAL单元的多个RTP分组，这在无线网络中是优选的，反之亦然。

12.4、具有数据分区的视频电话

该方案已经实施，并被证明具有良好的性能，特别是在较高的丢包率下附录[12]。

只有当某种形式的非均匀差错保护可用时，数据分区才有用。通常，在单会话 RTP 环境中，甚至会假设错误特征；即会话的所有数据包的丢包概率在统计上是相同的。但是，有一些方法可以降低 RTP 会话中单个数据包的丢包概率。例如，根据RFC 2733 附录[18]的FEC分组指定哪些媒体分组与FEC分组相关联。

在所有情况下，所产生的开销都是巨大的，但与原本用于帧内信息的比特数处于相同的数量级。但是，这种机制不会给系统增加任何延迟。

其次，完整的参数集建立是通过控制协议手段进行的。

12.5、带有 FUs 和前向纠错的视频电话或流媒体

该方案已经实施并已被证明具有良好的性能，尤其是在较高的丢包率下附录[19]。

在不适用重传的情况下，对抗数据包丢失的最有效方法是前向纠错（FEC）。尽管应用层端到端使用FEC的效率通常低于基于FEC的单个链路保护（尤其是在传输路径中具有不同特性的链路时），但在某些情况下，应用层端到端FEC是不可避免的。RFC 2733 附录[18]提供了在丢包环境中使用通用、应用层、端到端FEC的方法。通过对不同数据包中相同位位置的位应用异或操作，生成二进制前向纠错码。二进制代码可以由参数（n，k）指定，其中k是连接中使用的信息分组的数量，n是为k个信息分组生成的分组的总数；即为k个信息分组生成n-k个奇偶校验分组。

当代码与RFC 2733框架内的参数（n，k）一起使用时，以下属性是众所周知的：

a) 如果应用于一个RTP数据包，RFC2733仅提供数据包重复。
b) 如果XOR连接的数据包长度相等，RFC2733的比特率效率最高。
c) 在相同的丢包概率p下，对于固定的k，n的值越大，剩余错误概率越小。例如，对于10%、k＝1和n＝2的分组丢失概率，残余错误概率约为1%，而对于n＝3，残余错误概率约为0.1%。
d) 在相同的分组丢失概率p和固定的码速率k/n下，n的值越大，残余错误概率越小。例如，在p＝10%、k＝1和n＝2的分组丢失概率下，残余错误率约为1%，而对于k＝12和n＝24的扩展Golay码，残余错误率约为0.01%。

为了在不使用FUs的情况下将RFC 2733与H.264基线编码视频结合使用，可以考虑以下几种选项：

1) 视频编码器产生NAL单元，每个视频帧在单个片段中编码。应用FEC，可以使用简单的代码；例如（n=2，k=1）。也就是说，每个NAL单元基本上都是重复的。根据上述d），缺点显而易见，代码性能差，灵活性低，因为只能使用（n，k=1）代码。
2) 视频编码器产生NAL单元，每个视频帧被编码在一个或多个连续片中。应用FEC，可以在NAL单元序列上使用更好的代码，例如（n=24，k=12）。根据每帧 RTP 数据包的数量，丢失可能会导致显着延迟，当每帧使用更多 RTP 数据包时，延迟会减少。也可以连接长度完全不同的数据包，这会降低上述b）所述的比特率效率。然而，在一定程度上，对于1kb或更大的片，可能会产生类似的长度（100-200字节差），这不会灾难性地降低比特效率。
3) 视频编码器产生NAL单元，其中某个帧包含可能几乎相等长度的k个片段。然后，应用FEC，可以在每个帧的NAL单元序列上使用更好的代码，例如（n＝24，k＝12）。与上述2）相比，延迟可能会减少，但有几个缺点是显而易见的。首先，编码视频的编码效率显著降低，因为切片结构化编码减少了帧内预测，并且需要额外的切片开销。第二，预编码内容，或者，当在网关上操作时，视频通常不使用k个片段进行适当编码，以便可以应用FEC。最后，对产生等长k个片段的视频进行编码并不简单，可能需要多次编码。

通过将FUs与FEC结合使用，可以避免上述许多缺点。每个NAL单元可分为任意数量的长度基本相等的FU；因此，可以应用具有合理k和n的FEC，即使编码器不产生等长的切片。例如，包含整个帧的编码片NAL单元可以分割为k FUs，并且可以应用奇偶校验码（n＝k+1，k）。但是，这样做的缺点是，除非所有创建的片段都可以恢复，否则整个片段都将丢失。因此，与将帧分割为多个切片相比，丢失的部分更大。

所提出的技术使得即使不存在额外的信源编码层冗余（例如周期性帧内帧），也能够实现良好的传输容错。因此，相同的编码视频序列可用于在无差错传输上实现最大的压缩效率和质量，并用于在容易出错的网络上传输。此外，该技术允许在不增加延迟的情况下将FEC应用于预编码序列。在这种情况下，对于容易出错的网络，未编码的预编码序列仍然可以在不增加大量延迟的情况下几乎可靠地传输。此外，等长的FUs导致RFC2733的比特率有效使用。

如果错误概率取决于所传输数据包的长度（例如，在移动传输的情况下[14]），则将FUs与FEC结合使用的好处更为明显。基本上，FUs大小的灵活性允许为每个NAL单元应用适当的FEC，并且NAL单元具有非均匀差错保护。

当使用 FU 和 FEC 时，产生的开销很大，但与不应用 FEC 时帧内编码宏块必须花费的比特数处于同一数量级。在附录[19]中，研究表明，当使用相同的误码率和相同的总体比特率（包括开销）时，基于FEC的方法的总体性能提高了质量。

12.6、低比特率流媒体

该方案已在H.263和非标准RTP封装中实现，并取得了良好的效果附录[20]。没有技术上的理由说明H.264无法获得类似的好结果。

在今天的互联网流媒体中，一些提供的比特率相对较低，以便允许带有拨号调制解调器的终端访问内容。在有线IP网络中，相对较大的数据包（例如500-1500字节）比较小且更频繁出现的数据包更可取，以减少网络拥塞。此外，使用大数据包可以减少RTP/UDP/IP报头开销。对于低比特率视频，使用大数据包意味着有时一个数据包中最多应封装几个图片。

然而，丢失包含许多编码图片的数据包将对视觉质量产生严重影响，因为除了重复上一张图片外，几乎没有其他方法可以隐藏整个图片的丢失。构造相对较大的数据包并保持成功隐藏丢失可能性的一种方法是构造包含来自多个图片的交错切片的MTAP。MTAP不应包含来自同一图片的空间相邻切片或来自任何图片的空间重叠切片。如果分组丢失，则丢失的片段很可能被相同图片的空间上相邻的片段以及时间上先前和后续图片的空间上对应的片段包围。因此，隐藏丢失的切片可能比较成功。

12.7、视频流中的鲁棒分组调度

已使用MPEG-4第2部分实现了鲁棒分组调度，并在无线流媒体环境中进行了模拟[21]。对于H.264无法实现类似或更好的结果，没有任何技术原因。

流式客户端通常具有能够存储相对大量数据的接收器缓冲区。最初，当建立流会话时，客户端不会立即开始播放流。相反，它通常会将传入的数据缓冲几秒钟。这种缓冲有助于保持连续播放，因为在偶尔增加传输延迟或网络吞吐量下降的情况下，客户端可以解码和播放缓冲数据。否则，在没有初始缓冲的情况下，客户端必须冻结显示、停止解码并等待传入数据。缓冲对于任何协议级别的自动或选择性重传也是必要的。如果图片的任何部分丢失，可以使用重传机制来重新发送丢失的数据。如果重新传输的数据在其预定解码或回放时间之前被接收，则丢失完全恢复。编码图片可以根据其在解码序列主观质量中的重要性进行排序。例如，非参考图片，例如传统的B图片，在主观上是最不重要的，因为它们的缺失不影响任何其他图片的解码。除了非参考图片外，ITU-T H.264 | ISO/IEC 14496-10标准还包括一种称为子序列的时间可伸缩性方法附录[22]。主观排序也可以基于编码切片数据分区或切片组进行。主观上最重要的编码切片和编码切片数据分区可以比它们的解码顺序指示的更早发送，而主观上最不重要的编码切片和编码切片数据分区可以比它们的自然编码顺序指示的更晚发送。因此，与最不重要的片段和片段数据分区相比，最重要片段和编码片段数据分区的任何重传部分更有可能在其预定解码或回放时间之前被接收。

13、资料性附录：解码订单号的基本原理

13.1、简介

引入解码顺序号（DON）概念主要是为了实现高效的多图片片交织（见第12.6节）和鲁棒分组调度（见第12.7节）。在这两种应用中，NAL单元都是按解码顺序传输的。DON表示NAL单元的解码顺序，应在接收器中使用，以恢复解码顺序。第13.2节和第13.3节分别给出了高效多图片片交织和鲁棒分组调度的示例用例。第13.4节描述了DON概念在通过冗余编码图片实现错误恢复能力方面的优势。第13.5节总结了所考虑的DON替代方案，并说明了为什么选择DON符合本RTP有效载荷规范。

13.2、多画面切片交错示例

多图片切片交织的示例如下。下面按输出顺序描述了编码视频序列的子集。 R表示参考图片，N表示非参考图片，数字表示相对输出时间。

... R1 N2 R3 N4 R5 ...

这些图片从左到右的解码顺序如下：

... R1 R3 N2 R5 N4 ...

图片R1、R3、N2、R5和N4的NAL单位分别用等于1、2、3、4和5的DON标记。

每个参考图片由以下三个分散的切片组组成（数字表示QCIF帧中每个宏块的切片组编号）：

        0    1    2    0    1    2    0    1    2    0    1
        2    0    1    2    0    1    2    0    1    2    0
        1    2    0    1    2    0    1    2    0    1    2
        0    1    2    0    1    2    0    1    2    0    1
        2    0    1    2    0    1    2    0    1    2    0
        1    2    0    1    2    0    1    2    0    1    2
        0    1    2    0    1    2    0    1    2    0    1
        2    0    1    2    0    1    2    0    1    2    0
        1    2    0    1    2    0    1    2    0    1    2

为了简单起见，我们假设一个片组的所有宏块都包含在一个片中。三个MTAPs由三个连续的参考图片构成，因此每个MTAP包含三个聚合单元，每个聚合单元包含一个切片组中的所有宏块。第一个MTAP包含图片R1的切片组0、图片R3的切片组1和图片R5的切片组2。第二个MTAP包含图片R1的切片组1、图片R3的切片组2和图片R5的切片组0。第三个MTAP包含图片R1的切片组2、图片R3的切片组0和图片R5的切片组1。每个非参考图片被封装到STAP-B中。

因此，NAL单元的传输顺序如下：

        R1, slice group 0, DON 1, carried in MTAP,     RTP SN: N
        R3, slice group 1, DON 2, carried in MTAP,     RTP SN: N
        R5, slice group 2, DON 4, carried in MTAP,     RTP SN: N
        R1, slice group 1, DON 1, carried in MTAP,     RTP SN: N+1
        R3, slice group 2, DON 2, carried in MTAP,     RTP SN: N+1
        R5, slice group 0, DON 4, carried in MTAP,     RTP SN: N+1
        R1, slice group 2, DON 1, carried in MTAP,     RTP SN: N+2
        R3, slice group 1, DON 2, carried in MTAP,     RTP SN: N+2
        R5, slice group 0, DON 4, carried in MTAP, RTP SN: N+2
        N2,                         DON 3, carried in STAP-B, RTP SN: N+3
        N4,                         DON 5, carried in STAP-B, RTP SN: N+4

接收机能够基于与每个NAL单元相关联的DON的值以解码顺序重新组织NAL单元。

如果 MTAP 之一丢失，则接收空间相邻且时间上位于同一位置的宏块并可用于有效地隐藏丢失。如果其中一个 STAP 丢失，则丢失的影响不会随时间传播。

13.3、鲁棒分组调度示例

下面是一个健壮的数据包调度示例。本示例中使用的通信系统由以下组件组成，按照视频从源到接收器的处理顺序排列：

摄影机和捕捉
预编码缓冲区
编码器
编码图片缓冲器
发射机
传输通道
接收器
接收机缓冲器
译码器
解码图片缓冲器
显示器

本示例中使用的视频通信系统的操作如下。注意，视频流的处理在系统的所有组件中逐渐同时进行。源视频序列被拍摄并捕获到预编码缓冲区。例如，预编码缓冲器可用于从采样顺序到编码顺序对图片进行排序，或用于出于比特率控制目的分析多个未压缩帧。在某些情况下，预编码缓冲区可能不存在；取而代之的是，立即对采样的图片进行编码。编码器对来自预编码缓冲器的图片进行编码并存储输出；即编码图片，发送到编码图片缓冲区。发射机将来自编码图片缓冲器的编码图片封装到传输分组中，并通过传输信道将其发送到接收机。接收器将接收到的数据包存储到接收器缓冲区。接收机缓冲处理通常包括对传输延迟抖动的缓冲。接收机缓冲器还可用于恢复编码数据的正确解码顺序。解码器从接收器缓冲器读取编码数据，并产生解码图片作为输出到解码图片缓冲器中。解码图片缓冲区用于恢复图片的输出（或显示）顺序。最后，显示图片。

在以下示例图中，I表示IDR图片，R表示参考图片，N表示非参考图片，并且I、R或N之后的数字表示相对于解码顺序中的先前IDR图片的采样时间。图片序列下方的值表示缩放的系统时钟时间戳。在本例中，系统时钟任意初始化，时间从左到右运行。假设编码、传输和解码不花费时间，则每个I、R和N图片被映射到与先前处理步骤（如果有的话）相比的相同时间线中。因此，在所有示例图中，同时发生的事件位于同一列中。

下面以采样顺序描述编码图片序列的子集。

采样的图片缓冲在预编码缓冲区中，以按编码顺序排列。在该示例中，我们假设非参考图片是以输出顺序从上一参考图片和下一参考图片预测的，除了IDR图片前面的非参考图片，它们是仅以输出顺序从上一参考图片预测的。因此，预编码缓冲器必须包含至少两个图片，并且该缓冲器导致两个图片间隔的延迟。预编码缓冲处理的输出和图片的编码（和解码）顺序如下：

编码器或发射器可以将每个图片的DON值设置为解码顺序的前一张图片的DON值加1。

为了简单起见，让我们假设：

序列的帧速率是恒定的，
每张图片只包含一个切片，
每个片封装在单个NAL单元数据包中，
没有传输延迟，
图片以恒定的间隔（即1/帧速率）传输。

当以解码顺序发送图片时，它们按如下方式接收：

可选MIME 类型参数sprop-interleaving-depth 设置为 0，因为传输（或接收）顺序与解码顺序相同。

解码器最初必须在其解码图片缓冲区中缓冲一个图片间隔，以将图片从解码顺序组织到输出顺序，如下所示：

解码图片缓冲器中所需的初始缓冲量可以在缓冲周期SEI消息中或使用H.264视频可用性信息的num_reorder_frames语法元素来表示。num_reorder_frames 指示以解码顺序在序列中的任何帧、互补场对或非配对场之前并在输出顺序中紧随其后的帧、互补场对或非配对场的最大数量。为了简单起见，我们假设num_reorder_frames用于指示解码图片缓冲区中的初始缓冲区。在本例中，num_reorder_frames等于1。

可以观察到，如果IDR图片I00在传输期间丢失并且当系统时钟的值为62时发出重发请求，则存在一个图片时间间隔（直到系统时钟达到时间戳63）来接收重发的IDR图片I00。

然后，让我们假设IDR图片的传输间隔早于其解码位置两帧；即图片的传输方式如下：

根据定义，可选MIME 类型参数sprop-interleaving-depth设置为1。（本例中的sprop-interleaving-depth的值可以如下导出：图片I00是传输顺序在图片N58或N59之前和解码顺序在其之后的唯一图片。除了图片I00、N58和N59之外，传输顺序与图片的解码顺序相同。由于编码图片恰好被封装到一个 NAL 单元中，因此 sprop-interleaving-depth 的值等于传输顺序中任何图片之前和解码顺序中图片之后的最大图片数。）

接收器缓冲过程根据 sprop-interleaving-depth 参数的值一次包含两个图片，并根据与每个图片关联的 DON 值将图片从接收顺序排列到正确的解码顺序。接收器缓冲过程的输出如下：

同样，需要一个图片间隔的初始缓冲延迟来将图片从解码顺序组织到输出顺序，如下所示：

请注意，IDR图片在传输期间（包括可能的应用、传输或链路层重传）可经历的最大延迟等于三个图片间隔。因此，与按解码顺序传输图片的情况相比，在支持重传的系统中，IDR 图片的丢失弹性得到了改进。

13.4、冗余编码切片的鲁棒传输调度

冗余编码图片是在相应的主编码图片被正确解码的情况下，未在解码过程中使用的图片或图片的一部分的编码表示。解码后的主图片的任何区域与对同一访问单元中的任何冗余图片应用 H.264 解码过程所导致的相应区域之间不应有明显差异。冗余编码片是作为冗余编码图片的一部分的编码片。

冗余编码图片可用于在易出错的视频传输中提供非均匀差错保护。如果图片的主要编码表示被错误解码，则相应的冗余编码图片可以被解码。使用冗余编解码器图片功能的应用和编码技术的示例包括视频冗余编码附录[23]和多播流中“关键图片”的保护附录[24]。

许多容易出错的视频通信系统的一个特点是传输错误通常是突发的。因此，它们可能影响传输顺序中的多个连续传输分组。在低比特率视频通信中，将整个编码图片封装到一个传输包中是相对常见的。因此，主编码图片和相应的冗余编码图片可以按照传输顺序以连续分组的形式传输。为了使传输方案更能容忍突发传输错误，传输由多个分组分隔的主编码图片和冗余编码图片是有益的。DON概念实现了这一点。

13.5、关于其他设计可能性的评论

H.264编码标准的切片头语法结构包含frame_num语法元素，该元素可以指示编码帧的解码顺序。然而，由于以下原因，使用frame_num语法元素来恢复解码顺序是不可行或不可取的：

接收器需要对每个编码图片至少解析一个切片头（在将编码数据传递给解码器之前）。
来自多个编码视频序列的编码片段不能交错，因为在每个IDR图片中帧编号语法元素重置为0。
互补字段对的编码字段共享frame_num语法元素的相同值。因此，不能基于H.264编码语法的frame_num语法元素或任何其他语法元素来恢复互补字段对的编码字段的解码顺序。

用于传输MPEG-4基本流的RTP有效载荷格式附录[25]支持在同一RTP数据包中交错接入单元和传输多个接入单元。根据附录[1] 的子条款 7.4.1.2，在 H.264 编码标准中指定的访问单元包括与主要编码图片相关联的所有 NAL 单元。因此，不同图片的切片不能交错，并且不能使用用于提高错误恢复能力的多图片切片交错技术（见第12.6节）。

14、致谢

略。

15、参考

15.1、规范性引用文件

[1] ITU-T Recommendation H.264, "Advanced video coding for generic audiovisual services", May 2003.
[2] ISO/IEC International Standard 14496-10:2003.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[6] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.

[7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.

15.2、资料性引用

[8] "Draft ITU-T Recommendation and Final Draft International Standard of Joint Video Specification (ITU-T Rec. H.264 | ISO/IEC 14496-10 AVC)", available from http://ftp3.itu.int/av-
arch/jvt-site/2003_03_Pattaya/JVT-G050r1.zip, May 2003.
[9] Luthra, A., Sullivan, G.J., and T. Wiegand (eds.), Special Issue on H.264/AVC. IEEE Transactions on Circuits and Systems on Video Technology, July 2003.
[10] Bormann, C., Cline, L., Deisher, G., Gardos, T., Maciocco, C., Newell, D., Ott, J., Sullivan, G., Wenger, S., and C. Zhu, "RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)", RFC 2429, October 1998.
[11] ISO/IEC IS 14496-2.
[12] Wenger, S., "H.26L over IP", IEEE Transaction on Circuits and Systems for Video technology, Vol. 13, No. 7, July 2003.
[13] Wenger, S., "H.26L over IP: The IP Network Adaptation Layer", Proceedings Packet Video Workshop 02, April 2002.
[14] Stockhammer, T., Hannuksela, M.M., and S. Wenger, "H.26L/JVT Coding Network Abstraction Layer and IP-based Transport" in Proc. ICIP 2002, Rochester, NY, September 2002.
[15] ITU-T Recommendation H.241, "Extended video procedures and control signals for H.300 series terminals", 2004.
[16] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[17] ITU-T Recommendation H.223, "Multiplexing protocol for low bit rate multimedia communication", July 2001.
[18] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for Generic Forward Error Correction", RFC 2733, December 1999.
[19] Stockhammer, T., Wiegand, T., Oelbaum, T., and F. Obermeier, "Video Coding and Transport Layer Techniques for H.264/AVC-Based Transmission over Packet-Lossy Networks", IEEE International Conference on Image Processing (ICIP 2003), Barcelona, Spain, September 2003.

[20] Varsa, V. and M. Karczewicz, "Slice interleaving in compressed video packetization", Packet Video Workshop 2000.
[21] Kang, S.H. and A. Zakhor, "Packet scheduling algorithm for wireless video streaming," International Packet Video Workshop 2002.
[22] Hannuksela, M.M., "Enhanced concept of GOP", JVT-B042, available http://ftp3.itu.int/av-arch/video-site/0201_Gen/JVT-B042.doc, January 2002.
[23] Wenger, S., "Video Redundancy Coding in H.263+", 1997 International Workshop on Audio-Visual Services over Packet Networks, September 1997.
[24] Wang, Y.-K., Hannuksela, M.M., and M. Gabbouj, "Error Resilient Video Coding Using Unequally Protected Key Pictures", in Proc. International Workshop VLBV03, September 2003.
[25] van der Meer, J., Mackie, D., Swaminathan, V., Singer, D., and P. Gentric, "RTP Payload Format for Transport of MPEG-4 Elementary Streams", RFC 3640, November 2003.
[26] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC3711, March 2004.
[27] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[28] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[29] ISO/IEC 14496-15: "Information technology - Coding of audio-visual objects - Part 15: Advanced Video Coding (AVC) file format".
[30] Castagno, R. and D. Singer, "MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files", RFC3839, July 2004.