RFC文档链接

摘要

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

本备忘录废除RFC 3984。第14节总结了RFC 3984的变更。第15节讨论了RFC 3984的向后兼容性问题。

1、简介

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

本备忘录废除RFC 3984。第14节总结了RFC 3984的变更。第15节讨论了RFC 3984的向后兼容性问题。

1.1、H.264编解码器

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

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

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

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

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

1.3、网络抽象层单元类型

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

所有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装置顺序。

NALU 时间：如果NAL单元将在其自己的RTP数据包中传输，则RTP时间戳将具有的值。

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

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

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

静态宏块：视频流中一定数量的宏块可以定义为静态的，如附录[3]中第8.3.2.8节所定义。静态宏块为处理非静态宏块释放了额外的处理周期。基于给定数量的视频处理资源和给定的分辨率，更高数量的静态宏块能够实现相应更高的帧速率。

默认子配置文件：profile-level-id参数表示的编码工具子集，可以是一个profile的所有编码工具，也可以是多个profile的公共编码工具子集。

默认级别：profile-level-id 参数指示的级别，它由三个八位字节组成，profile_idc、profile-iop 和 level_idc。 在大多数情况下，默认级别由 level_idc 指示，在某些情况下，另外由 profile-iop 指示。

4.2、缩写

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
SAR:         Sample Aspect Ratio
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
VUI:         Video Usability Information

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时间戳中每个编码帧只能传送一个时间戳。

5.2、有效载荷结构

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

单个NAL单元数据包：在有效负载中仅包含单个NAL单元。NAL标头类型字段将等于原始NAL单位类型；即范围为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节中规定。

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

表1总结了NAL单元类型和当每个NAL单元直接用作数据包有效负载时的相应RTP数据包类型，这些类型在本备忘录中进行了描述。

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

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配置文件，也可能需要其他映射。

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

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

资料性说明：如前所述，根据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 附录[3]（见第12.1节）的会话系统。非交织模式针对可能不符合ITU-T建议H.241的会话系统。在非交织模式中，NAL单元以NAL单元解码顺序传输。交织模式的目标是不需要非常低的端到端延迟的系统。交织模式允许在NAL单元解码顺序之外传输NAL单元。

正在使用的打包模式可以通过可选packetization-mode MIME参数的值或通过外部方式发出信号。使用的打包模式控制RTP有效负载中允许的NAL单元类型。表3总结了每个打包模式允许的NAL单元类型。第6节将更详细地解释打包模式。

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

一些 NAL 单元或有效载荷类型值（在表 3 中表示为保留）保留用于将来的扩展。 这些类型的 NAL 单元不应由发送方发送（直接作为数据包有效载荷，作为聚合数据包中的聚合单元，或作为 FU 数据包中的分段单元）并且必须被接收方忽略。例如，在“单NAL单元模式”和“非交织模式”中允许具有相关分组类型“NAL单元”的有效负载类型1-23，但在“交织模式”中不允许。然而，NAL 单元类型 1-23 的 NAL 单元可以在“交错模式”中用作 STAP-B、MTAP16 和 MTAP24 数据包中的聚合单元以及 FU-A 和 FU-B 数据包中的分段单元。类似地，NAL单元类型1-23的NAL单元除了直接用作分组有效载荷之外，还可以在“非交织模式”中用作STAP-A分组中的聚合单元或FU-A分组中的分段单元。

5.5、解码顺序号（DON）

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

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

• 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 单元时间戳偏移的长度。

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

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

MTAP 和 STAP 共享以下打包规则：

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

表4 STAP 和 MTAP 的type字段

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

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

5.7.1、单时间聚合数据包（STAP）

每当聚合所有共享相同 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 必须包含 MTAP 的 NAL 单元中 NAL 单元解码顺序中第一个 NAL 单元的 DON 值。

资料性说明：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 附录[3]的系统兼容的低延迟应用（见第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、解包过程

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

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

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

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

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

7.2、交织模式

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

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

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

7.2.1、解交织缓冲区的大小

在 Offer/Answer 或声明性会话描述协议 (SDP) 使用中，sprop-deint-buf-req 媒体类型参数表示对去交织缓冲区大小的要求。 因此，建议将解交织缓冲区大小（以字节数表示）设置为等于或大于 sprop-deint-buf-req 媒体类型参数的值。

当会话设置中使用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节。

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）附录[6]的映射。可以在其他地方定义等效参数，以便与不使用SDP的控制协议一起使用。

一些参数向接收器提供将要发送的流的属性。对于流属性，所有这些参数的名称都以“sprop”开头。其中一些“sprop”参数受到其他有效负载或编解码器配置参数的限制。例如，sprop-parameter-sets 参数受profile-level-id 参数的约束。

8.1、媒体类型注册

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

媒体类型名称：video

媒体子类型名称：H264

必需参数：none

可选参数：

profile-level-id:

附录[1]中指定了序列参数集NAL单元中以下三个字节的base16 附录[7]（十六进制）表示：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 参数指示默认子配置文件（即，可能已用于生成流或接收器支持的编码工具的子集）和流或接收器支持的默认级别。

默认子配置文件由 profile_idc 字节和 profile-iop 字节中的一些字段共同指示。 根据 profile-iop 字节中字段的值，默认子配置文件可能是一个配置文件支持的一组编码工具，也可能是多个配置文件的编码工具的公共子集，如附录[1]中的第7.4.2.1.1章节。 默认级别由level_idc字节表示，当profile_idc等于66、77或88（基线、主配置文件或扩展配置文件）且level_idc等于11时，另外由profile-iop字节的第4位（constraint_set3_flag）表示。 当profile_idc等于66、77或88（Baseline、Main或Extended profile）时，level_idc等于11，profile-iop字节的第4位（constraint_set3_flag）等于1，默认级别为Level 1b。

表 5 列出了 附录[1] 的附件 A 中定义的所有配置文件，以及对于每个配置文件，代表相同子配置文件的 profile_idc 和 profile-iop 的可能组合。

表5. profile_idc 和 profile-iop 的组合代表相同的子配置文件，对应于一个配置文件支持的全套编码工具。 下文中，x 可以为 0 或 1，而配置文件名称如下所示。 CB：约束基线剖面，B：基线剖面，M：主要剖面，E：扩展剖面，H：高剖面，H10：高 10 剖面，H42：高 4:2:2 剖面，H44：高 4:4:4 预测配置文件，H10I：高 10 内配置文件，H42I：高 4:2:2 内配置文件，H44I：高 4:4:4 内配置文件，以及 C44I：CAVLC 4:4:4 内配置文件。

例如，在上表中，profile_idc 等于 58（扩展）且 profile-iop 等于 11xx0000 表示与 profile_idc 等于 42（基线）且 profile-iop 等于 x1xx0000 对应的相同子配置文件。 请注意，profile_idc 和 profile-iop 的其他组合（未在表 5 中列出）可能代表一个子配置文件，该子配置文件等效于用于多个配置文件的编码工具的公共子集。 还要注意，符合某个配置文件的解码器可能能够解码符合其他配置文件的比特流。

如果 profile-level-id 参数用于指示 NAL 单元流的属性，则表示要对流进行解码，解码器必须支持的编码工具的最小子集是默认子配置文件，并且解码器必须支持的最低级别是默认级别。

如果 profile-level-id 参数用于能力交换或会话建立，则它指示编解码器支持接收和发送的编码工具子集，它等于默认子配置文件。 如果 max-recv-level 不存在，则 profile-level-id 中的默认级别表示编解码器希望支持的最高级别。 如果存在 max-recv-level，则表示编解码器支持接收的最高级别。 无论是接收还是发送，都必须支持低于支持的最高级别的所有级别。

资料性说明：能力交换和会话设置程序应提供单独列出每个受支持子概要文件的能力的方法。例如，可以使用SDP Offer/Answer模型的one-of-N编解码器选择过程（见附录[8]第10.2节）。one-of-N编解码器选择过程还可用于提供表示相同子配置文件的 profile_idc 和 profile-iop 的不同组合。当存在代表同一子配置文件的多个不同profile_idc和profile-iop组合时，使用one-of-N编解码器选择过程可能会产生相当大的SDP消息。因此，接收者应该理解代表相同子配置文件的 profile_idc 和 profile-iop 的不同等价组合，并准备好接受使用任何等价组合的请求。

如果不存在 profile-level-id，则必须推断出在级别 1 没有附加约束的基线配置文件。

max-recv-level:

当最高级别高于默认级别（由profile-level-id指示的级别）时，此参数可用于指示接收器支持的最高级别。max-recv-level 的值是  附录[1] 中指定的序列参数集 NAL 单元中的语法元素 profile_idc 之后的两个字节的 base16（十六进制）表示：profile-iop（如上定义）和 level_idc。如果 max-recv-level 的 level_idc 字节等于 11 并且 max-recv-level 的 profile-iop 字节的第 4 位等于 1 或者如果 max-recv-level 的 level_idc 字节等于 9 并且 max-recv-level 的 profile-iop 字节的第 4 位等于 0，接收者支持的最高级别为Level 1b。 否则，接收器支持的最高级别等于 max-recv-level 的 level_idc 字节除以 10。

如果接收器支持的最高级别不高于默认级别，则不能出现 max-recv-level。

max-mbps, max-smbps, max-fs, max-cpb, max-dpb, and max-br:

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

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

如果接收器可以支持级别 A 的所有属性，则 profile-level-id 参数或 max-recv-level 参数的值中指定的最高级别必须是级别 A（即，不得低于级别 A） . 换句话说，与profile-level-id 参数或 max-recv-level 参数值中指定的最高级别相比，接收器不得发出 max-mbps、max-fs、max-cpb、max-dpb 和 max-br 的一起满足更高级别的要求的信号值 。

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

max-mbps:        max-mbps 的值是一个整数，表示以每秒宏块为单位的最大宏块处理速率。 max-mbps 参数表示接收器能够以比在 profile-level-id 参数或 max-recv-level 参数的值中传达的信号最高级别所需的更高的速率解码视频。

当指明max-mbps时，接收器必须能够解码符合信号等级的NAL unit流，但附录[1]表A-1中用于信号等级的MaxMBPS值被max-mbps值替换的情况除外。max-mbps 的值必须大于或等于 附录[1] 的表 A-1 中给出的级别对应的MaxMBPS 的值。发送方可以根据这点以比信号等级中指示的更高的图像速率发送给定大小的图像。

max-smbps:        max-smbps 的值是一个整数，表示在假设所有宏块都是静态宏块的情况下，以每秒静态宏块为单位的最大静态宏块处理速率。 当指明max-mbps时，附录[1] 的表 A-1 中的 MaxMBPS 值应替换为以下计算的结果：

• 如果参数 max-mbps 已指明，则将变量 MaxMacroblocksPerSecond 设置为 max-mbps 的值。 否则，将 MaxMacroblocksPerSecond 设置为等于 附录[1]中 表 A-1 中 MaxMBPS 的值，用于在 profile-level-id 参数或 max-recv-level 参数的值中传达的信号最高级别。
• 设置变量P_non-static 为图片n 中非静态宏块的比例。
• 设置变量P_static 为图片n 中静态宏块的比例。
• 编码器应认为 附录[1] 的表 A-1 中 MaxMBPS 的值等于：

MaxMacroblocksPerSecond * max-smbps / (P_non-static * max-smbps + P_static * MaxMacroblocksPerSecond)

编码器应该为每张图片重新计算这个值。 max-smbps 的值必须大于或等于 MaxMBPS 的值，MaxMBPS 的值作为 max-mbps 参数的值显式给出或在 附录[1] 的表 A-1 中隐式给出，用于信号最高级别。 发送者可以根据这点以比信号最高级别中指示的更高的图像速率发送给定大小的图像。

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

max-cpb:        max-cpb的值是一个整数，表示VCL HRD参数以1000比特为单位，NAL HRD参数以1200比特为单位表示最大编码图片缓冲区大小。请注意，此参数不使用 cpbBrVclFactor 和 cpbBrNALFactor 的单位（参见 附录[1] 的表 A-1）。 max-cpb 参数表示接收器具有比在 profile-level-id 参数或 max-recv-level 参数的值中传达的信号最高级别所需的最小编码图片缓冲内存量更多的内存。当 max-cpb 指明时，接收器必须能够解码符合信号最高级别的 NAL 单元流，除了 附录[1] 表 A-1 中用于信号最高级别的 MaxCPB 值被替换为max-cpb 的值（在需要时考虑 cpbBrVclFactor 和 cpbBrNALFactor 之后）。 max-cpb 的值（在需要时考虑 cpbBrVclFactor 和 cpbBrNALFactor 之后）必须大于或等于 [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 的值是一个整数，表示以 8/3 宏块为单位的最大解码图片缓冲区大小。 max-dpb 参数表示接收器具有比在 profile-level-id 参数或 max-recv-level 参数的值中传达的信号最高级别所需的最小解码图片缓冲内存更多的内存。 当 max-dpb 指明时，接收器必须能够解码符合信号最高级别的 NAL 单元流，除了 附录[1] 表 A-1 中信号最高级别的 MaxDpbMbs 值被替换为 max-dpb * 3 / 8 的值。因此，指明max-dpb的接收器必须能够在其解码图片缓冲区中存储以下数量的解码帧、互补场对和非配对场：

Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), 16)

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

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

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

资料性说明：在本文档已废弃的 RFC 3984 中，该参数的单位为 1024 字节。 本文档中的单位已更改为 8/3 宏块。 发生这种变化的原因是由于从 RFC 3984 引用的 H.264 规范的 2003 版到本文档引用的 H.264 规范的 2010 版的变化，特别是 H. .264 规范由于添加了早期不支持的颜色格式和位深度。 此参数更改后的语义保持与 RFC 3984 的向后兼容性，并支持 H.264 规范 2010 版中定义的所有配置文件。

max-br:        max-br 的值是一个整数，表示对于 VCL HRD 参数以每秒 1000 比特为单位，对于 NAL HRD 参数以每秒 1200 比特为单位表示最大视频比特率。 请注意，此参数不使用 cpbBrVclFactor 和 cpbBrNALFactor 的单位（参见 附录[1] 的表 A-1）。

max-br 参数表示接收器的视频解码器能够以比在 profile-level-id 参数或 max-recv-level 参数的值中传达的信号最高级别所需的比特率更高的比特率解码视频。

当指明max-br时，接收器的视频编解码器必须能够解码符合信号最高级别的 NAL 单元流，但最高级别指定的限制中的以下例外情况：

• max-br 的值（在需要时考虑 cpbBrVclFactor 和 cpbBrNALFactor 后）替换了 附录[1] 表 A-1 中的 MaxBR 值作为最高级别。
• 当 max-cpb 参数不存在时，以下公式的结果将替换 附录[1] 表 A-1 中 MaxCPB 的值：(MaxCPB of the signaled level) * max-br / (MaxBR of the signaled highest level).。

例如，如果接收器用 max-br 等于 1550 表示 Main profile Level 1.2 的能力，这表示 VCL HRD 参数的最大视频比特率为 1550 kbits/sec，NAL HRD 参数的最大视频比特率为 1860 kbits/sec ，以及 4036458 位（1550000 / 384000 * 1000 * 1000）的 CPB 大小。

max-br 的值（在需要时考虑 cpbBrVclFactor 和 cpbBrNALFactor 之后）必须大于或等于 附录[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 单元可以放置在 NAL 单元流中以在解码顺序中位于任何其他 NAL 单元之前。 该参数不得用于指示任何能力交换过程中的编解码能力。 该参数的值是以逗号分隔的 (',') 列表，其中包含 附录[1] 的第 7.3.2.1 和 7.3.2.2 节中指定的参数集 NAL 单元的 base64 附录[7] 表示形式。 请注意，参数集 NAL 单元中的字节数通常小于 10，但图片参数集 NAL 单元可以包含数百个字节。

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

sprop-parameter-sets 参数必须只包含符合 profile-level-id 的参数集，即任何参数集指示的编码工具子集必须等于默认的 sub-profile，并且级别 由任何参数集指示必须等于默认级别。

sprop-level-parameter-sets:

此参数可用于传达任何序列和图片参数集 NAL 单元（此处称为初始参数集 NAL 单元），这些 NAL 单元可以放置在 NAL 单元流中，以解码顺序在任何其他 NAL 单元之前，并且与 与默认级别不同的一个或多个级别。 该参数不得用于指示任何能力交换过程中的编解码器能力。

sprop-level-parameter-sets 参数包含一个或多个与默认级别不同的级别的参数集。 与一个级别关联的所有参数集都被聚集在一起，并以一个三字节字段为前缀，该字段与 profile-level-id 具有相同的语法。 这使接收器能够安装一个级别的参数集并丢弃其余的。 三字节字段命名为 PLId，与一个级别关联的所有参数集命名为 PSL，其语法与 sprop-parameter-sets 相同。 每个级别的参数集以 PLId:PSL 的形式表示，即 PLId 后跟冒号 (':') 和级别的初始参数集 NAL 单元的 base64 附录[7] 表示。 每对 PLId:PSL 也用冒号分隔。 请注意，PSL 可以包含该级别的多个参数集，以逗号 (',') 分隔。

每个 PLId 字段指示的编码工具子集必须等于默认子配置文件，并且每个 PLId 字段指示的级别必须不同于默认级别。 每个 PSL 中包含的所有序列参数集必须具有从 profile_idc 到 level_idc 的三个字节，包括在内，等于前面的 PLId。

资料性说明：此参数允许在 SDP Offer/Answer 和参数集的带外传输中进行有效的级别降级或升级。

use-level-src-parameter-sets:

该参数可用于指示接收器能力。 该值可以等于 0 或 1。当该参数不存在时，该值必须被推断为等于 0。值 0 表示接收者不理解 sprop-level-parameter-sets 参数，不理解 附录[9] 的第 6.3 节中指定的“fmtp”源属性，当sprop-level-parameter-sets存在时将忽略它 ，并且在使用“fmtp”源属性传送时将忽略 sprop-parameter-sets。 值 1 表示接收者理解 sprop-level-parameter-sets 参数，理解 附录[9] 的第 6.3 节中指定的“fmtp”源属性，并且能够使用包含在 sprop-level-parameter 中的参数集或包含在使用“fmtp”源属性传送的 sprop-参数集中。

资料性说明：RFC 3984接收器不理解sprop-level-parameter-sets、use-level-src-parameter-sets或 附录[9]第6.3节中规定的“fmtp”源属性。因此，在SDP Offer/Answer过程中，RFC 3984接收方作为应答方，将忽略在请求中存在的sprop-level-parameter-sets以及按照 附录[9]第6.3节的规定，使用“fmtp”源属性传送的sprop-parameter-sets。假设提供的有效负载类型在低于默认级别的级别上被接受。如果请求的有效载荷类型包括sprop-level-parameter-sets或使用“fmtp”源属性传送的包括的sprop-parameter-sets，并且如果offerer发现answerer在应答中没有包括等于1的use-level-src-parameter-sets，则报价人知道需要参数集的带内传输。

in-band-parameter-sets:

此参数可用于指示接收器能力。该值可以等于0或1。值1表示接收器丢弃sprop参数集和sprop级别参数集中的带外参数集；因此，发送方必须在带内传输所有参数集。值0表示接收器使用sprop-  parameter-sets或sprop-level-parameter-sets中包含的带外参数集。然而，在这种情况下，发送方仍然可以选择在带内发送参数集。当in-band-parameter-sets等于1时，use-level-src-parameter-sets不得存在或必须等于0。当该参数不存在时，不指定此接收器功能，因此发送方可以仅发送带外参数集，也可以仅发送带内参数集，或者同时发送这两种参数集。

level-asymmetry-allowed:

此参数可在SDP Offer/Answer中使用，以指示是否允许级别不对称，即发送在offerer-to-answerer方向上编码的媒体的级别与在answerer-to-offerer方向上编码的媒体的级别不同。该值可以等于0或1。当参数不存在时，必须将该值推断为等于0。offer和answer中的值1表示允许级别不对称。offer或answer中的值0表示不允许级别不对称。

如果offer或answer中允许的level-asymmetry-allowed等于0（或不存在），则不允许级别不对称。在这种情况下，从offerer到answerer的方向上使用的级别必须与在相反方向上使用的级别相同。

packetization-mode:

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

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

sprop-interleaving-depth:

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

此参数表示RTP数据包流的属性。它指定以传输顺序在RTP数据包流中任何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 表示 RTP数据包流所需的解交织缓冲区大小。该参数的值必须大于或等于第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:

该参数可用于表示RTP数据包流的属性。不得将其用于信号发送器或接收器或编解码器功能。如果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单元的解码顺序号。第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发现通常不会在网关之外工作。

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

sar-understood:

此参数可用于指示接收器能力，而不是其他。该参数表示接收器理解的小于255的aspect_ratio_idc（在 附录[1]中指定）的最大值。附录[1]的表E-1规定aspect_ratio_idc等于0为“未指定”；1至16（含），作为特定Sample Aspect Ratios（SARs）；17至254，包括在内，为“保留”；255作为扩展SAR，其SAR宽度和SAR高度均明确表示。因此，具有根据 附录[1]的解码器的接收机理解aspect_ratio_idc在1到16（含）的范围内，并且aspect_ratio_idc等于255，这意味着接收机确切地知道SAR是什么。对于这样的接收机，sar-understood 的值为16。将来，如果扩展了附录[1]的表E-1，例如，aspect_ratio_idc等于17的SAR，则对于具有理解扩展的解码器的接收机，sar-understood 的值为17。对于具有根据附录[1]的2003版本的解码器的接收机，sar-understood的值是13，因为其中的最小保留aspect_ratio_idc是14。

当 sar-understood 不存在时，必须推断该值等于 13。

sar-supported:

该参数可用于指示接收器能力，仅此而已。 该参数取值范围为1到sar-understood（含）的整数，还有255。sar-supported的值等于N(小于255)表示接收端支持H.264 aspect_ratio_idc对应的所有SAR 值（参见 附录[1] 的表 E-1）在 1 到 N（含） 的范围内，没有几何失真。 sar-supported 的值等于 255 表示接收器支持使用两个 16 位整数值作为分子和分母可表示的所有样本纵横比，即使用 H.264 aspect_ratio_idc 值 255 ( Extended_SAR，参见 附录[1] 的表 E-1），没有几何失真。

符合 H.264 的编码器不应发送等于 0 的 aspect_ratio_idc 或大于 sar-understood 且小于 255 的 aspect_ratio_idc。符合 H.264 的编码器应发送接收器能够在没有几何失真的情况下显示的 aspect_ratio_idc。 但是，符合 H.264 的编码器可以选择使用任何 SAR 发送图片。

请注意，流的实际样本纵横比或扩展样本纵横比（如果存在）在序列参数集的视频可用性信息 (VUI) 部分中传达。

编码注意事项：

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

安全考虑：

参见RFC 6184第9节。

公共规范：

请参考RFC 6184及其第17节。

补充资料：

无。

文件扩展名：

无。

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、有效负载类型参数到 SDP 的映射

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

• SDP的“m=”行中的媒体名称必须是video。
• SDP的“a=rtpmap”行中的编码名称必须是H264（MIME子类型）。
• “a=rtpmap”行中的时钟频率必须为90000。
• 可选参数profile-level-id, max-recv-level, max- mbps, max-smbps, max-fs, max-cpb, max-dpb, max-br, redundant-pic-cap, use-level-src-parameter-sets, in-band-parameter-sets, level-asymmetry-allowed, packetization-mode, sprop-interleaving-depth,  sprop-deint-buf-req, deint-buf-cap, sprop-init-buf-time, sprop-max-don-diff, max-rcmd-nalu-size, sar-understood, and sar-supported,（如果存在），必须包含在SDP的“a=fmtp”行中。这些参数表示为MIME媒体类型字符串，以分号分隔的参数=值对列表的形式。
• 可选参数 sprop-parameter-sets 和 sprop-level-parameter-sets，如果存在，必须包含在 SDP 的“a=fmtp”行中或使用 附录[9] 的第 6.3 节中指定的“fmtp”源属性传送。 对于特定的媒体格式（即 RTP 有效负载类型），sprop-parameter-sets 或 sprop-level-parameter-sets 不得同时包含在 SDP 的“a=fmtp”行中且使用“fmtp”源传送属性。 当包含在 SDP 的“a=fmtp”行中时，这些参数表示为媒体类型字符串，以分号分隔的参数=值对列表的形式。 当使用“fmtp”源属性传送时，这些参数仅与作为“fmtp”源属性的一部分的给定源和有效负载类型相关联。

资料性说明：使用“fmtp”源属性传输 sprop-parameter-sets 和 sprop-level-parameter-sets 允许在 Topo-Video-switch-MCU 附录[29] 等拓扑中进行参数集的带外传输。

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

m=video 49170 RTP/AVP 98
a=rtpmap:98 H264/90000
a=fmtp:98 profile-level-id=42A01E; packetization-mode=1; sprop-parameter-sets=<parameter sets data>

8.2.2、SDP Offer/Answer模式的使用

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

• 标识 H.264 媒体格式配置的参数是profile-level-id、packetization-mode。这些媒体格式配置参数（除了 profile-level-id 的 level 部分）必须对称使用； 即，如果一个或多个参数值不受支持，则应答者必须要么维护所有配置参数，要么完全删除媒体格式（有效载荷类型）。请注意，profile-level-id 的级别部分包括 level_idc，并且，当 profile_idc 等于 66、77 或 88 时，用于指示级别 1b，profile-iop 的第 4 位（constraint_set3_flag）。 profile-level-id 的级别部分是可变的。

资料性说明：对称使用的要求不适用于 profile-level-id 的级别部分，也不适用于其他流属性和能力参数。

资料性说明：在 H.264 附录[1] 中，除了 Level 1b 之外的所有级别都等于 level_idc 的值除以 10。Level 1b 是高于 Level 1.0 但低于 Level 1.1 的级别，并且以 特设方式指明，因为该级别是在Level 1.0和Level 1.1之后指定的。对于 Baseline、Main 和 Extended 配置文件（profile_idc 分别等于 66、77 和 88），Level 1b 由 level_idc 等于 11（即，与Level 1.1 相同）和 constraint_set3_flag 等于 1 表示。对于其他配置文件，Level 1b 由 level_idc 等于 9 表示（但请注意，这些配置文件的Level 1b 仍然高于Level 1（level_idc 等于10） 并低于级别 1.1）。在 SDP Offer/Answer 中，对请求的应答可能表示等于或低于请求中指示的级别。由于 Level 1b 的特殊指示，当 profile_idc 等于 66、77 或 88 且 level_idc 为等于 11。

为了简化这些配置的处理和匹配，在请求中使用的相同 RTP 有效负载类型编号也应该在应答中使用，如 附录[8] 中所述。 除非配置与请求中的配置完全相同，否则应答不得包含请求中使用的有效负载类型编号。

资料性说明：当一个offerer收到一个应答时，它必须根据媒体类型（即视频/H264）和上述媒体配置参数将请求中未声明的有效负载类型与它已经声明的任何有效负载类型进行比较。 这将使它能够确定所讨论的配置是否是新的，或者它是否等同于已经提供的配置，因为应答中可能会使用不同的有效负载类型编号。

• 如果存在，参数 max-recv-level 声明支持接收的最高级别。 如果 max-recv-level 不存在，则支持接收的最高级别等于 profile-level-id 的 level 部分指示的默认级别。 如果存在，max-recv-level 必须高于默认级别。
• 参数 level-asymmetry-allowed 表示是否允许级别不对称。

如果提议或答案中的 level-asymmetry-allowed 等于 0（或不存在），则不允许级别不对称。 在这种情况下，从 offerer 到 answerer 的方向上使用的 level 必须与在相反方向上使用的 level 相同，并且 使用的通用级别等于请求中的默认级别和应答中的默认级别的较低值。

否则，请求和应答中的 level-asymmetry-allowed 都等于 1，并且允许级别不对称。 在这种情况下，offer-to-answerer 方向使用的级别必须等于 answerer 支持接收的最高级别，并且 answerer-to-offerer 方向使用的 级别必须等于提供者支持接收的最高级别。

不允许级别不对称时，不允许级别升级，即应答中的默认级别必须等于或低于请求中的默认级别。

• 参数sprop-deint-buf-req、sprop-interleaving-depth、sprop-max-don-diff 和 sprop-init-buf-time描述了offerer或answerer为媒体格式配置发送的RTP数据包流的属性。这与Offer/Answer参数的正常用法不同：通常这些参数声明了offerer或answerer能够接收的流的属性。在处理H.264时，offerer假设answerer将能够接收使用请求的配置编码的媒体。

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

• 能力参数max-mbps, max-smbps, max-fs, max-cpb, max-dpb, max-br, redundant-pic-cap, max-rcmd-nalu-size, sar-understood和sar-supported可用于声明offerer或answerer的进一步接收能力。当方向属性为“sendonly”且参数描述了offerer或answerer接受接收流的限制时，这些参数不得出现。
• offerer必须在交织H.264流的请求中包括解交织缓冲区的大小，即sprop-deint-buf-req。为了使offerer和answerer能够相互告知其在接收流中解交错缓冲的能力，建议双方包括deint-buf-cap。对于交错流，还建议考虑当接收机的能力未知时，提供具有不同缓冲要求的多个有效载荷类型。
• sprop-parameter-sets 或 sprop-level-parameter-sets 参数，如果存在（包含在 SDP 的“a=fmtp”行中或使用 附录[9] 的第 6.3 节中指定的“fmtp”源属性传送）， 用于参数集的带外传输。 然而，当使用参数集的带外传输时，参数集仍可以在带内额外传输。

answerer可以为它正在发送的流使用带外或带内参数集传输，无论是否在offerer到answerer的方向上使用了带外参数集传输。 应答中包含的参数集独立于请求中包含的参数集，因为它们用于解码两个不同的视频流，一个从answerer到offerer，另一个在相反方向。

以下规则适用于在offerer到answerer方向上的参数集传输。

• ~~~~
  • 请求可能包括 sprop-parameter-sets 和 sprop-level-parameter-sets 中的一个或两个。 如果报价中既不存在 sprop-parameter-sets 也不存在 sprop-level-parameter-sets，则仅使用参数集的带内传输。
  • 如果应答包括等于1的in-band-parameter-sets，那么offerer必须在带内传输参数集。 否则，以下适用。
    • 如果在offerer到answerer方向上使用的级别等于请求中的默认级别，则适用以下内容。
      • 当请求的“a=fmtp”行中包含 sprop-parameter-sets 时，answerer必须准备使用 sprop-parameter-sets 中包含的参数集来解码传入的 NAL 单元流。
      • 当在请求中使用“fmtp”源属性传送 sprop-parameter-sets 时，以下适用。 如果应答包含等于1的use-level-src-parameter-sets或“fmtp”源属性，则answerer必须准备使用 sprop-parameter-sets 中包含的参数集来解码传入的 NAL 单元流； 否则，offerer必须在带内传输参数集。
      • 当请求中不存在 sprop-parameter-sets 时，提议者必须在带内传输参数集。
      • 回答者必须忽略请求中存在的sprop-level-parameter-sets（包括在“a=fmtp”行中或使用“fmtp”源属性传达）。
    • 否则，在offerer到answerer方向中使用的级别不等于提议中的默认级别，以下适用。
      • answerer必须忽略请求中存在的sprop-parameter-sets（包括在“a=fmtp”行中或使用“fmtp”源属性传达）。
      • 当应答中use-level-src-parameter-sets 不等于1且不存在“fmtp”源属性时，answerer必须忽略存在请求中的sprop-level-parameter-sets，并且offerer必须 带内传输参数集。
      • 当应答中use-level-src-parameter-sets 等于1或存在“fmtp”源属性时，answerer必须准备使用存在请求中的sprop-level-parameter-sets 中包含的可接受级别（即答案中的默认级别）的参数集，用于解码传入的 NAL 单元流，并忽略 sprop-level-parameter-sets 中包含的所有其他参数集。
      • 当在请求中的sprop-level-parameter-sets中不存在要在offerer到answerer方向使用的级别的参数集时，offerer必须在带内传输参数集。

以下规则适用于在answerer到offerer方向上的参数集传输。

• ~~~~
  • 应答中可能包括 sprop-parameter-sets 或 sprop-level-parameter-sets 但不能同时包括两者。 如果应答中既不存在 sprop-parameter-sets 也不存在 sprop-level-parameter-sets，则仅使用参数集的带内传输。
  • 如果请求包含等于1的in-band-parameter-sets，则answerer不得在答案中包含 sprop-parameter-sets 或 sprop-level-parameter-sets，并且必须在带内传输参数集。 否则，以下适用。
    • 如果在answerer到offerer方向上使用的级别等于应答中的默认级别，则适用以下内容。
      • 当应答中的“a=fmtp”行中包含 sprop-parameter-sets 时，offerer必须准备使用 sprop-parameter-sets 中包含的参数集来解码传入的 NAL 单元流。
      • 当应答中存在使用“fmtp”源属性传达的sprop-parameter-sets 时，以下适用。 如果请求中包含等于1的 use-level-src-parameter-sets 或“fmtp”源属性，则offerer必须准备使用sprop-parameter-sets中包含的参数集来解码传入的 NAL 单元流； 否则，answerer必须在带内传输参数集。
      • 当应答中不存在 sprop-parameter-sets 时，answerer必须在带内传输参数集。
      • offerer必须忽略存在于应答中的sprop-level-parameter-sets（包括在“a=fmtp”行中或使用“fmtp”源属性传达）。
    • 否则，在answerer到offerer方向上使用的级别不等于应答中的默认级别，以下适用。
      • offerer必须忽略应答中存在的sprop-parameter-sets（包括在 SDP 的“a=fmtp”行中或使用“fmtp”源属性传送）。
      • 当请求中use-level-src-parameter-sets不等于1且不存在“fmtp”源属性时，offerer 必须忽略存在的sprop-level-parameter-sets，并且 answerer 必须传输参数集 带内。
      • 当请求中use-level-src-parameter-sets等于1或存在“fmtp”源属性时，offerer必须准备好使用存在于应答中的sprop-level-parameter-sets中包含的在answerer-to-offerer 方向上使用的级别的参数集 ，用于解码传入的 NAL 单元流，并忽略应答中 sprop-level-parameter-sets 中包含的所有其他参数集。
      • 当应答中的sprop-level-parameter-sets中不存在用于在 answerer-to-offerer 方向上使用的级别的参数集时， answerer必须在带内传输参数集。

当sprop-parameter-sets或sprop-level-parameter-sets使用 附录[9] 的第 6.3 节中指定的“fmtp”源属性传送时，参数的接收者必须存储包含在可接受级别的sprop-parameter-sets或sprop-level-parameter-sets的参数集，并将它们与作为“fmtp”源属性的一部分给出的源相关联。 与一个源相关的参数集必须仅用于解码来自同一源的RTP数据包中传送的 NAL 单元。 当使用此机制时，必须按照 附录[9]中的规定执行SSRC冲突检测和解决。

资料性说明：使用“fmtp”源属性的sprop-parameter-sets和sprop-level-parameter-sets的传输可用于 Topo-Video-switch-MCU 附录[29] 等拓扑结构，以实现参数集的带外传输。

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

• 媒体格式配置由“profile-level-id”标识，包括level部分和packetization-mode。 这些媒体格式配置参数（包括profile-level-id的level部分）必须对称使用； 也就是说，answerer必须要么维护所有配置参数，要么完全删除媒体格式（有效负载类型）。 请注意，这意味着多播中 Offer/Answer 的 profile-level-id 的 level 部分是不可更改的。

为了简化这些配置的处理和匹配，在请求中使用的相同RTP有效负载类型编号也应该在应答中使用，如 附录[8] 中所述。 除非配置与请求中的配置相同，否则应答中不得包含请求中使用的有效负载类型编号。

• 接收到的参数集必须与原始源关联，并且只能用于解码来自同一源的传入NAL单元流。
• 只要遵守上述规则，其他参数的规则与单播相同。

表6列出了必须用于不同方向属性的所有介质类型参数的解释。

表6 不同方向属性的参数解释

说明：

C：发送和接收流的配置

O：offer/answer 模式

P：要发送的流的属性

R：接收机能力

S：带外参数集

-：不可用（如果存在，应忽略）

用于声明接收器功能的参数通常是可降级的；也就是说，它们表示发送者可能行为的上限。因此，发送方可以选择仅使用这些参数的较低/较少或相等值来设置其编码器。

声明配置点的参数不可更改，但用于单播使用的profile-level-id参数的级别部分除外。

当声明发送者的能力并且在此声明中使用不可降级的参数时，这些参数表示发送者接收流可接受的配置。 为了实现高互操作性水平，通常建议提供多种替代配置，例如，用于分组模式。 在单一的有效载荷类型中提供多种配置是不可能的。 因此，当做出多个配置请求时，每个请求都需要与请求相关联自己的 RTP 有效负载类型。

接收者应该理解所有的媒体类型参数，即使它只支持有效载荷格式功能的一个子集。 这确保接收者能够理解何时可以将接收媒体的请求降级为请求的接收者所支持的内容。

answerer可以通过额外的媒体格式配置来扩展请求。 但是，为了启用它们的使用，在大多数情况下，需要offerer提供第二个请求，以提供媒体发送者将使用的流属性参数。 这还具有offerer必须能够接收此媒体格式配置的效果，而不仅仅是发送它。

如果offerer希望在发送和接收之间具有非对称能力，则offerer可以通过 level-asymmetry-allowed 等于 1 来允许非对称级别。或者，offerer可以提供不同的 RTP 会话，即分别声明为“ recvonly”和“sendonly”。 这可能对系统有进一步的影响，并且可能需要额外的外部语义来关联两个媒体行。

8.2.3、声明式会话描述中的用法

当在RTP中的H.264与 SDP 一起以声明式方式提供时，如实时流协议 (RTSP) 附录[27] 或会话公告协议 (SAP) 附录[28] 中，以下考虑是必要的。

• 所有能够指示流属性和接收器能力的参数仅用于指示流属性。 例如，在这种情况下，参数 profile-level-id 仅声明流使用的值，而不声明接收流的能力。 其结果是必须使用以下参数解释：

声明实际配置或流属性：

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

参数集的带外传输：

- sprop-parameter-sets
        - sprop-level-parameter-sets

不可用（如果存在，它们应该被忽略）：

- max-mbps
        - max-smbps
        - max-fs
        - max-cpb
        - max-dpb
        - max-br
        - max-recv-level
        - redundant-pic-cap
        - max-rcmd-nalu-size
        - deint-buf-cap
        - sar-understood
        - sar-supported
        - in-band-parameter-sets
        - level-asymmetry-allowed
        - use-level-src-parameter-sets

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

8.3、示例

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

Offerer -> Answerer 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=<parameter sets data#0>
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=42A01E; packetization-mode=1;
    sprop-parameter-sets=<parameter sets data#1>
a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=42A01E; packetization-mode=2;
    sprop-parameter-sets=<parameter sets data#2>;
    sprop-interleaving-depth=45; sprop-deint-buf-req=64000;
    sprop-init-buf-time=102478; deint-buf-cap=128000

上述报价以三种不同的分组格式呈现相同的编解码器配置。 有效载荷类型98表示单NALU模式，有效载荷类型99表示非交织模式，有效载荷类型100表示交织模式。 在交织模式的情况下，如果应答表明支持有效负载类型 100，offerer将使用的交织参数也包括在内。 在所有这三种情况下，参数sprop-parameter-sets传递answerer在接受此配置时从offerer接收流时所需的初始参数集。 请注意，对于每种有效负载类型，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=<parameter sets data#3>
a=rtpmap:99 H264/90000
a=fmtp:99 profile-level-id=42A01E; packetization-mode=1;
    sprop-parameter-sets=<parameter sets data#4>;
    max-rcmd-nalu-size=3980
a=rtpmap:100 H264/90000
a=fmtp:100 profile-level-id=42A01E; packetization-mode=2;
    sprop-parameter-sets=<parameter sets data#5>;
    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 具有相同的值（因为 packetization-mode 等于 0 并且 spropdeint-buf-req 不存在）。由于提供的有效载荷类型 98 被接受，answerer需要存储包含在 sprop-parameter-sets=<parameter sets data#0> 中的参数集，以防请求最终决定使用此配置。在应答中，answerer在 sprop-parameter-sets=<parameter sets data#3> 中包含参数集，如果最终使用此配置，answerer将在从answerer发送的流中使用这些参数集。

answerer还接受有效载荷类型 99 和 100 表示的两种配置的接收。同样，answerer需要存储包含在 sprop-parameter-sets=<parameter sets data#1> 和 sprop-parameter-sets=<parameter sets data#2> 中的参数集，以防请求最终决定使用这两者中的任何一个配置。 answerer提供 answerer-to-offerer方向的初始参数集，即 sprop-parameter-sets=<parameter sets data#4> 和 sprop-parameter-sets=<parameter sets data#5> 中的参数集，分别用于有效载荷类型 99 和 100，它将用于发送有效载荷类型。answerer还通过提供 deint-buf-cap 参数为offerer提供去交错操作的内存限制。这仅在offerer决定提出第二个请求时才有用，它可以考虑新的价值。 max-rcmd-nalu-size 表示answerer可以有效地处理最大 3980 字节的 NALU。但是，不能保证网络支持此大小。

在以下示例中，请求被接受而没有级别降级（即，默认级别 3.0 被接受），并且 sprop-parameter-sets 和 sprop-level-parameter-sets 都存在于请求中。 answerer必须忽略 sprop-level-parameter-sets=<parameter sets data#1> 并存储在 sprop-parameter-sets=<parameter sets data#0>中的参数集以解码传入的 NAL 单元流。 offerer必须存储在答案中的 sprop-parameter-sets=<parameter sets data#2>中的参数集，以解码传入的 NAL 单元流。 请注意，在此示例中，sprop-parameter-sets=<parameter sets data#2> 中的参数集必须与级别 3.0 关联。

Offer SDP:

m=video 49170 RTP/AVP 98
        a=rtpmap:98 H264/90000
        a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0
            packetization-mode=1;
            sprop-parameter-sets=<parameter sets data#0>;
            sprop-level-parameter-sets=<parameter sets data#1>

Answer SDP:

m=video 49170 RTP/AVP 98        
        a=rtpmap:98 H264/90000
        a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0
            packetization-mode=1;
            sprop-parameter-sets=<parameter sets data#2>

在以下示例中，请求（基线配置文件，级别 1.1）被接受并降低级别（接受的级别为级别 1b），并且请求中同时存在 sprop-parameter-sets 和 sprop-level-parameter-sets。 answerer必须忽略 sprop-parameter-sets=<parameter sets data#0> 和所有不在 sprop-level-parameter-sets=<parameter sets data#1> 中接受的级别（级别 1b）的参数集，并且必须存储在 sprop-level-parameter-sets=<parameter sets data#1>中接受级别（级别 1b）的参数集，用于解码传入的 NAL 单元流。 offerer必须存储在应答中的 sprop-parameter-sets=<parameter sets data#2>中的参数集，以解码传入的 NAL 单元流。 请注意，在此示例中，sprop-parameter-sets=<parameter sets data#2> 中的参数集必须与级别 1b 关联。

Offer SDP:

m=video 49170 RTP/AVP 98
        a=rtpmap:98 H264/90000
        a=fmtp:98 profile-level-id=42A00B; //Baseline profile, Level 1.1
            packetization-mode=1;
            sprop-parameter-sets=<parameter sets data#0>;
            sprop-level-parameter-sets=<parameter sets data#1>

Answer SDP:

m=video 49170 RTP/AVP 98
        a=rtpmap:98 H264/90000
        a=fmtp:98 profile-level-id=42B00B; //Baseline profile, Level 1b
            packetization-mode=1;
            sprop-parameter-sets=<parameter sets data#2>;
            use-level-src-parameter-sets=1

在以下示例中，请求（基线配置文件，级别 1.1）被接受并降低级别（接受的级别为级别 1b），并且请求中同时存在 sprop-parameter-sets 和 sprop-level-parameter-sets。 然而，answerer是一个遗留的 RFC 3984 实现并且不理解 sprop-level-parameter-sets； 因此，它在应答中不包括 use-level-src-parameter-sets（answerer也不理解）。 因此，answerer必须同时忽略 sprop-parameter-sets=<parameter sets data#0> 和 sprop-level-parameter-sets=<parameter sets data#1>，并且offerer必须在带内传输参数集。

Offer SDP:

m=video 49170 RTP/AVP 98
        a=rtpmap:98 H264/90000
        a=fmtp:98 profile-level-id=42A00B; //Baseline profile, Level 1.1
            packetization-mode=1;
            sprop-parameter-sets=<parameter sets data#0>;
            sprop-level-parameter-sets=<parameter sets data#1>

Answer SDP:

m=video 49170 RTP/AVP 98
        a=rtpmap:98 H264/90000
        a=fmtp:98 profile-level-id=42B00B; //Baseline profile, Level 1b
            packetization-mode=1

在下面的示例中，请求被接受而没有降级，并且 sprop-parameter-sets 存在于请求中。 sprop-parameter-sets=<parameter sets data#0>中的参数集必须存储，被offerer的编码器和answerer的解码器使用，sprop-parameter-sets=<parameter sets data#1>中的参数集必须由 answerer 的编码器和 offerer 的解码器使用。 请注意，sprop-parameter-sets=<parameter sets data#0> 基本上独立于 sprop-parameter-sets=<parameter sets data#1>。

Offer SDP:

m=video 49170 RTP/AVP 98
        a=rtpmap:98 H264/90000
        a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0
            packetization-mode=1;
            sprop-parameter-sets=<parameter sets data#0>

Answer SDP:

m=video 49170 RTP/AVP 98
        a=rtpmap:98 H264/90000
        a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0
            packetization-mode=1;
            sprop-parameter-sets=<parameter sets data#1>

在下面的示例中，请求在没有降级的情况下被接受，并且在请求中既不存在 sprop-parameter-sets 也不存在 sprop-level-parameter-sets，这意味着没有参数集的带外传输，即必须在带内传输。

Offer SDP:

m=video 49170 RTP/AVP 98
        a=rtpmap:98 H264/90000
        a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0
            packetization-mode=1

Answer SDP:

m=video 49170 RTP/AVP 98
        a=rtpmap:98 H264/90000
        a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0
            packetization-mode=1

在以下示例中，请求在降级时被接受，并且 sprop-parameter-sets 存在于请求中。 由于 sprop-parameter-sets=<parameter sets data#0> 包含 level_idc 表示 Level 3.0，因此不能使用，因为 answerer想要 Level 2.0，必须被answerer忽略，必须使用带内参数集 。

Offer SDP:

m=video 49170 RTP/AVP 98
        a=rtpmap:98 H264/90000
        a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0
            packetization-mode=1;
            sprop-parameter-sets=<parameter sets data#0>

Answer SDP:

m=video 49170 RTP/AVP 98
        a=rtpmap:98 H264/90000
        a=fmtp:98 profile-level-id=42A014; //Baseline profile, Level 2.0
            packetization-mode=1

在下面的示例中，请求也接受了级别降级，并且在请求中既不存在 sprop-parameter-sets 也不存在 sprop-level-parameter-sets，这意味着没有参数集的带外传输，必须在带内传输。

Offer SDP:

m=video 49170 RTP/AVP 98
        a=rtpmap:98 H264/90000
        a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0
            packetization-mode=1

Answer SDP:

m=video 49170 RTP/AVP 98
        a=rtpmap:98 H264/90000
        a=fmtp:98 profile-level-id=42A014; //Baseline profile, Level 2.0
            packetization-mode=1

在下面的例子中，请求是接受level升级的，并且在请求和应答中都没有 sprop-parameter-sets 和 sprop-level-parameter-sets，这意味着没有参数的带外传输 集，然后必须在带内传输。 在offerer-to-answerer方向上使用的级别是 3.0 级，在answerer-to-offerer方向上使用的级别是 2.0 级。 answerer被允许在任何级别发送至 2.0 级（含），offerer被允许以任何级别发送至 3.0 级（含）。

Offer SDP:

m=video 49170 RTP/AVP 98
        a=rtpmap:98 H264/90000
        a=fmtp:98 profile-level-id=42A014; //Baseline profile, Level 2.0
            packetization-mode=1; level-asymmetry-allowed=1

Answer SDP:

m=video 49170 RTP/AVP 98
        a=rtpmap:98 H264/90000
        a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0
            packetization-mode=1; level-asymmetry-allowed=1

在以下示例中，offerer是拓扑中的多点控制单元 (MCU)，如 Topo-Video-switch-MCU 附录[29]，提供从其他三个参与者（B、C和D）接收的参数集（使用带外传输），以及接收从作为应答者的参与者A的参数集。参与者由他们的规范名称 (CNAME) 值标识，这些值映射到不同的 SSRC 值。所有四个参与者都使用相同的编解码器配置。参与者A将<parameter sets data#B>、<parameter sets data#C>和<parameter sets data#D>中包含的参数集分别存储并关联到参与者B、C和D，并使用<parameter sets data#B> 用于解码仅来自参与者 B 的 RTP 数据包中携带的 NAL 单元，使用 <parameter sets data#C> 用于解码仅来自参与者 C 的 RTP 数据包中携带的 NAL 单元，并使用 <parameter sets data#D>仅用于解码来自参与者 D 的 RTP 数据包中携带的 NAL 单元。

Offer SDP:

m=video 49170 RTP/AVP 98
        a=ssrc:SSRC-B cname:CNAME-B
        a=ssrc:SSRC-C cname:CNAME-C
        a=ssrc:SSRC-D cname:CNAME-D
        a=ssrc:SSRC-B fmtp:98
            sprop-parameter-sets=<parameter sets data#B>
        a=ssrc:SSRC-C fmtp:98
            sprop-parameter-sets=<parameter sets data#C>
        a=ssrc:SSRC-D fmtp:98
            sprop-parameter-sets=<parameter sets data#D>
        a=rtpmap:98 H264/90000
        a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0
            packetization-mode=1

Answer SDP:

m=video 49170 RTP/AVP 98
        a=ssrc:SSRC-A cname:CNAME-A
        a=ssrc:SSRC-A fmtp:98
            sprop-parameter-sets=<parameter sets data#A>
        a=rtpmap:98 H264/90000
        a=fmtp:98 profile-level-id=42A01E; //Baseline profile, Level 3.0
            packetization-mode=1

8.4、参数集注意事项

H.264 参数集是视频编解码器的基本部分，对其操作至关重要（参见第 1.2 节）。 由于它们的特性及其对解码过程的重要性，丢失或错误传输的参数集很难在接收器本地隐藏。 对损坏的参数集的引用通常会对解码过程产生致命的影响。 例如，由于参数集 NAL 单元的错误传输或丢失，以及由于参数集更新的不及时传输，都可能发生损坏。 参数集更新是指图片参数集或序列参数集中的至少一个参数的改变，图片参数集或序列参数集标识保持不变。 因此，提供以下建议作为 RTP 发送器实施者的指南。

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

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

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

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

建议在会话控制协议中实现原则A和B。 SIP和SDP可以按照 SDP Offer/Answer模型和本备忘录前面部分中的说明使用。 第8.2.2节详细讨论了在带内或者SDP Offer/Answer的带外，使用媒体类型参数sprop-parameter-sets, sprop-level-parameter-sets, use-level-src-parameter-sets和in-band-parameter-sets的参数集的传输。 本节包含关于如何在会话控制协议中实现原则A和B的指南。 它独立于所使用的特定协议。 本规范中定义的RTP有效载荷格式支持原则C。 有像 Topo-Video-switch-MCU 附录[29] 这样的拓扑，可能需要使用原则C。

如果使用参数集的带内信令，则应该使用可靠的 RTP 传递方法（见下文）在 RTP 有效载荷中传输图片和序列参数集 NALUs，因为任何一种类型的参数集的丢失都可能会阻止对相应 RTP 数据包流的相当一部分进行解码。

如果使用参数集的带内信令，发送者应该考虑错误特征并使用机制来提供正确传递参数集的高概率。 增加正确接收概率的机制包括数据包重复、FEC 和重传。 使用不可靠的带外控制协议具有与带内信令类似的缺点（可能丢失），此外，还可能导致同步困难（见下文）。 因此，不建议这样做。

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

——  添加或更新参数集时，应注意确保任何参数集在使用之前交付。 添加新参数集时，将使用以前未使用的参数集标识符。 带外信令和带内业务之间不存在同步是很常见的。 如果使用带外信令，建议发送方在确认来自信令协议的传递之前不要开始发送需要添加或更新参数集的 NALU。

——  更新参数集时，应考虑以下同步问题。 在接收方覆盖参数集时，发送方必须确保网络或接收缓冲区中存在的任何 NALU 都不需要所讨论的参数集。 否则，可能会出现使用错误的参数集进行解码。 为了减轻这个问题，建议要么只覆盖那些长时间未使用的参数集（以确保所有相关的 NALU 都已被消耗），要么添加一个新的参数集（这可能对视频编码产生负面影响）。

资料性说明：在一些拓扑中，如 Topo-Video-switch-MCU 附录[29]，整个参数集的来源可能来自多个可能使用非唯一参数集标识符的来源。 在这种情况下，如果不存在使带外通道中的参数集具有唯一性的其他机制，则请求可能会覆盖现有参数集。

——  在多方会话中，一个参与者必须尽可能将来自不同源的参数集与源标识相关联，例如，通过传送带外传输的参数集，因为不同的源通常使用独立的参数集标识符值空间。

——  在同一个RTP会话中同时使用原则B和C来增加或修改参数集可能会因为控制和RTP通道之间缺乏同步而导致参数集不一致。 因此，原则B和C不得在同一会话中同时使用，除非可以提供足够的同步。

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

应该使用上面讨论的机制来降低丢失概率。 在检测到参数集丢失的情况下，可以使用解码器刷新点过程来实现恢复，例如，使用 RTCP 反馈全帧内请求 (FIR) 附录[30]。 说明性的第 8.5 节提供了两个示例解码器刷新点程序。

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

8.5、使用参数集的带内传输的解码器刷新点过程（资料性）

当具有根据 附录[1] 的视频编码器的发送器接收到对解码器刷新点的请求时，编码器应使用第 8.5.1 节或第 8.5.2 节中指定的程序之一进入快速更新模式。 第 8.5.1 节中的过程是无损传输环境中的首选响应。 这两个程序都满足了进入 H.264 视频编码的快速更新模式的要求。

8.5.1、响应解码器刷新点请求的 IDR 程序

本节提供了一种响应解码器刷新点请求的可能方式。

编码器应按此处介绍的顺序：

1、立即准备发送 IDR 图片。

2、发送要发送的 IDR 图片使用的序列参数集。 编码器还可以选择性地发送其他序列参数集。

3、发送要发送的IDR图片使用的图片参数集。 编码器还可以可选地发送其他图片参数集。

4、发送 IDR 图片。

5、从该时间点向前，在任何NAL单元引用之前，发送在此过程中尚未发送的任何其他序列或图片参数集，无论此类参数集是否在接收解码器刷新点请求之前发送。根据需要，这样的参数集可以批量发送，一次发送一个，或者以这两种方法的任意组合发送。 可以随时重新发送参数集以实现冗余。 如上文第 8.4 节所述，当存在参数集更新时应小心。

8.5.2、响应解码器刷新点请求的逐步恢复过程

本节提供了另一种响应解码器刷新点请求的可能方式。

编码器应按此处介绍的顺序：

1、发送恢复点 SEI 消息（参见 附录[1] 的 D.1.7 和 D.2.7 节）。

2、在NAL单元引用它们之前，重复在恢复点 SEI 消息之前发送的任何序列和图片参数集。

编码器应确保解码器能够访问所有参考图片，以便按照输出顺序在恢复点处或之后对图片进行帧间预测，这由恢复点SEI消息指示，假设从现在开始的传输是无错误的。

恢复点 SEI 消息中的recovery_frame_cnt syntax元素的值应该足够小以确保快速恢复。

根据需要，可以分批、一次一个或以这两种方法的任意组合重新发送此类参数集。 可以随时重新发送参数集以实现冗余。 如上文第 8.4 节所述，当存在参数集更新时应小心。

9、安全注意事项

使用本规范中定义的有效载荷格式的 RTP 数据包受 RTP 规范 附录[5] 和任何适当的 RTP 配置文件（例如 附录[16]）中讨论的安全考虑的约束。这意味着媒体流的机密性是通过加密来实现的，例如，通过应用 SRTP 附录[26]。因为这种有效载荷格式使用的数据压缩是端到端应用的，所以任何加密都需要在压缩后执行。使用具有非均匀接收端计算负载的压缩技术的数据编码存在潜在的拒绝服务威胁。攻击者可以将病态数据报注入到流中，这些数据报难以解码并导致接收器过载。 H.264 特别容易受到此类攻击，因为生成包含影响许多未来 NAL 单元解码过程的 NAL 单元的数据报非常简单。因此，建议至少使用 RTP 数据包的数据源认证和数据完整性保护，例如，使用 SRTP 附录[26]。

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

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

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

10、拥塞控制

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

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

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

11、IANA 考虑事项

RFC 3984 指定的 H264 媒体子类型名称已按照本备忘录第 8.1 节中的定义进行了更新。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

同样，通过控制协议手段执行完整的参数集建立。

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

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

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

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

a、如果应用于一个RTP数据包，RFC 5109只提供数据包重复。

b、如果XOR连接的数据包长度相等，RFC 5109的比特率效率最高。

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，残余错误率约为0.01%。

要在不使用FUs的情况下将RFC 5109与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 fu，并且可以应用奇偶校验码（n＝k+1，k）。然而，这样做的缺点是，除非所有创建的片段都可以恢复，否则整个片段都将丢失。因此，与将帧分割为多个切片相比，丢失的部分更大。

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

如果错误概率取决于传输数据包的长度（例如，在移动传输 附录[15]的情况下），则将FUs与FEC结合使用的好处更为明显。基本上，FUs大小的灵活性允许对每个NAL单元应用适当的FEC，并对NAL单元进行不等的错误保护。

当使用FUs和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

为了简单起见，我们假设一个切片组的所有宏块都包含在一个切片中。三个MTAP由三个连续的参考图片构成，因此每个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图片被映射到与先前处理步骤（如果有的话）相比的相同时间线中。因此，在所有示例图中，同时发生的事件位于同一列中。

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

在以下示例图中，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、RFC3984的变更

以下是RFC3984的技术更改列表（包括错误修复）。除此技术变更清单外，还进行了许多编辑性变更，但本节未记录这些变更。请注意，第8.2.2节是本备忘录中许多重要更改的地方，值得特别注意。

1、在第5.4节、第5.5节、第6.2节、第6.3节和第6.4节中，删除了使用中的打包模式可通过外部方式发出信号的规定。

2、在第7.2.2节中，更改了句子 “解交织缓冲区中有N个VCL NAL单元。” 为 “解交织缓冲器中有N个或更多VCL NAL单元。”。

3、在第 8.1 节中，sprop-init-buf-time 的语义（第 2 段），更改了句子 “该参数是（NAL单元的传输时间-NAL单元的解码时间）的最大值，假设可靠且瞬时传输，传输和解码的时间线相同，并且解码在第一个数据包到达时开始。” 为 “该参数是（NAL单元的解码时间-NAL单元的传输时间）的最大值，假设可靠且瞬时传输，传输和解码的时间线相同，并且解码在第一个数据包到达时开始。”。

4、添加了媒体类型参数 max-smbps、sprop-level-parameter-sets、use-level-src-parameter-sets、in-band-parameter-sets、sar-understood 和 sar-supported。

5、在第 8.1 节中，删除了参数添加的规范。 参数添加的其他描述（在第 8.2 节和第 8.4 节中）也被删除。

6、在第 8.1 节中，为 sprop-parameter-sets 添加了一个约束，使其只能包含与 profile-level-id 指示的相同配置文件和级别的参数集。

7、在第 8.2.1 节中，添加了 sprop-parameter-sets 和 sprop-level-parameter-sets 可以包含在 SDP 的“a=fmtp”行中，也可以使用第 6.3 节中指定的“fmtp”源属性传送  附录[9]。

8、在第 8.2.2 节中，将 sprop-deint-buf-req 从与 SDP Offer/Answer 模型一起使用的媒体格式配置中删除。

9、在 8.2.2 节中，明确了 SDP Offer/Answer 模型中的 level 是可降级的，即 profile-level-id 的 level 部分的使用不需要是对称的（answer 中包含的 level 可以是 低于或等于报价中包含的水平）。

10、在第 8.2.2 节中，删除了功能参数可用于声明编码功能。

11、在第 8.2.2 节中，添加了有关如何使用 sprop-parameter-sets 和 sprop-level-parameter-sets 进行带外传输参数集的规则，无论是否有级别降级。

12、在第 8.2.2 节中，阐明了将媒体类型参数与 SDP Offer/Answer 一起用于多播的规则。

13、在第 8.2.2 节中，完成并更正了如何在提供或回答和方向属性的不同组合中解释不同媒体类型参数的列表。

14、在第 8.4 节中，更改了文本，允许参数集的带外和带内传输，既不推荐也不要求。

15、添加了第 8.5 节（信息性），提供了解码器刷新处理参数集丢失的示例方法。

16、添加了媒体类型参数 max-recv-level 和 level-asymmetry-allowed 并调整了关联文本和级别升级和不对称的示例。

15、向后兼容 RFC 3984

当前文档是 RFC3984 的修订版，并废弃RFC3984。 第 14 节列出了与 RFC 3984 相关的技术更改。本节解决了向后兼容性问题。

应该注意的是，在大多数情况下，按照 RFC 3984 的旧实现和按照本文档的新实现互通不会存在兼容性问题。 仅当以下两个条件都为真时，才会出现兼容性问题：1) 旧实现和新实现互通，2) 参数集在带外传输。 当出现此类兼容性问题时，通过以下分析，很容易调试并找到不兼容的原因。

第 1、2、3、7、9、10、12 和 13 项是错误修复类型的更改，不会产生任何向后兼容性问题。

第 4 项（添加六个新的媒体类型参数）不会对基于 SDP Offer/Answer 的应用程序产生任何向后兼容性问题，因为旧版 RFC 3984 接收器会忽略这些参数，并且旧版 RFC 3984 发送器可以不使用这些参数，因为它们是可选的。 但是，基于声明性使用的应用程序存在向后兼容性问题（仅适用于参数 sprop-level-parameter-sets，因为其他五个参数在声明性使用中不可用）。 例如，使用 RTSP 和 SAP 的基于声明性使用的应用程序存在向后兼容性问题，因为根据 RFC 3984 的 SDP 接收器无法接受 SDP 包含无法识别参数的会话。 因此，RTSP 或 SAP 服务器可能必须准备两组流，一组用于传统 RFC 3984 接收器，另一组用于根据本备忘录的接收器。

第 5、6 和 11 项与参数集的带外传输有关。 存在以下向后兼容性问题。

1、当根据 RFC 3984 的传统发送方包含不同于 profile-level-id 向 sprop-parameter-sets 指示的默认级别的级别的参数集时，根据本备忘录，sprop-parameter-sets 的参数值对接收方无效； 因此，会话可能会被拒绝。

2、在根据 RFC 3984 的旧offerer 和根据本备忘录的answerer之间的 SDP Offer/Answer中，当answerer在应答参数集中包含不是请求中包含的参数集的超集时，参数值 sprop-parameter-sets 对 offerer 无效，会话可能无法正确启动（与变更项 11 相关）。

3、当根据本备忘录的一个端点 A 包括等于 1 的带内参数集时，根据 RFC 3984 的另一端 B 不理解它必须在带内传输参数集，并且 B 仍可以排除带内参数集。 它正在发送的波段流。 因此，端点 A 无法解码它接收到的流。

第 7 项（允许使用 附录[9] 的第 6.3 节中指定的“fmtp”源属性传输 sprop-parameter-sets 和 sprop-level-parameter-sets）与第 4 项类似。它不会产生任何向后兼容性问题，对于基于 SDP Offer/Answer 的应用程序，因为传统 RFC 3984 接收器忽略“fmtp”源属性，并且传统 RFC 3984 发送器不使用“fmtp”源属性是可以的，因为它是可选的。 但是，对于基于 SDP 声明式使用的应用程序（例如使用 RTSP 和 SAP “源属性）。 因此，RTSP 或 SAP 服务器可能必须准备两组流，一组用于传统 RFC 3984 接收器，另一组用于根据本备忘录的接收器。

第 14 项不会引起任何向后兼容性问题，因为仍然允许参数集的带外传输。

第 15 项不会引起任何向后兼容性问题，因为添加的第 8.5 节提供了信息。

第 16 项不会产生任何向后兼容性问题，因为如果任一端符合 RFC 3984，则默认级别的处理是相同的，此外，符合 RFC-3984 的端将简单地忽略新的媒体类型参数（如果存在）。

16、致谢

略。

17、参考

17.1、规范性引用文件

[1]    ITU-T Recommendation H.264, "Advanced video coding for generic audiovisual services", March 2010.

[2]    ISO/IEC International Standard 14496-10:2008.

[3]    ITU-T Recommendation H.241, "Extended video procedures and control signals for H.300-series terminals", May 2006.

[4]    Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[5]    Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.

[6]    Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.

[7]    Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.

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

[9]    Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009.

17.2、资料性引用

[10]    Luthra, A., Sullivan, G.J., and T. Wiegand (eds.), "Introduction to the special issue on the H.264/AVC video coding standard", IEEE Transactions on Circuits and Systems for Video Technology, Vol. 13, No. 7, July 2003.

[11]    Ott, J., Bormann, C., Sullivan, G., Wenger, S., and R. Even, Ed., "RTP Payload Format for ITU-T Rec. H.263 Video", RFC 4629, January 2007.

[12]    ISO/IEC International Standard 14496-2:2004.

[13]    Wenger, S., "H.264/AVC over IP", IEEE Transaction on Circuits and Systems for Video Technology, Vol. 13, No. 7, July 2003.

[14]    Wenger, S., "H.26L over IP: The IP-Network Adaptation Layer", Proceedings Packet Video Workshop, April 2002.

[15]    Stockhammer, T., Hannuksela, M.M., and S. Wenger, "H.26L/JVT Coding Network Abstraction Layer and IP-Based Transport", IEEE International Conference on Image Processing (ICIP 2002), Rochester, NY, September 2002.

[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]    Li, A., Ed., "RTP Payload Format for Generic Forward Error Correction", RFC 5109, December 2007.

[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", 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)", RFC 3711, 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]    Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117, January 2008.

[30]    Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, February 2008.