H.264视频的RTP有效负载格式
Version 10.1
备忘
该文件为因特网社区规定了因特网标准跟踪协议，并提出了改进建议和讨论。Please refer to the current edition of the“Internet official Protocol standards”（STD 1）for the standardization state and status of this Protocol.这个MEMO的分布是无限的。
Copyright Notice
Copyright (C) The Internet Society (2005).
摘要
本备忘录描述了ITU-T建议H.264视频编解码器的RTP有效载荷格式和技术上相同的ISO/IEC国际标准14496-10视频编解码器。RTP有效负载格式允许对每个RTP有效负载中由H.264视频编码器生成的一个或多个网络抽象层单元（NALU）进行打包。有效载荷格式具有广泛的适用性，因为它支持从简单的低比特率会话使用，到Internet视频流与交错传输，到高比特率视频点播的应用。
1. 介绍
1.1. H.264编解码器的
本备忘录规定了称为ITU-T建议H.264[1]和ISO/IEC国际标准14496第10部分[2]的视频编码标准的RTP有效载荷规范（两者都称为高级视频编码或AVC）。建议H.264于2003年5月获得ITU-T的批准，已批准的规范草案可供公众审查[8]。在本备忘录中，H.264首字母缩写用于编解码器和标准，但备忘录同样适用于编码标准的ISO/IEC对应物。
H.264视频编解码器的应用范围非常广泛，涵盖了各种形式的数字压缩视频，从低比特率的互联网流媒体应用到高清晰度电视广播和具有几乎无损编码的数字电影应用。与目前的技术状态相比，H.264的总体性能可以节省50%或更多的比特率。例如，据报道，数字卫星电视的质量可以达到1.5 Mbit/s，而MPEG 2视频的当前操作点大约为3.5 Mbit/s[9]。
编解码器规范[1]本身在概念上区分了视频编码层（VCL）和网络抽象层（NAL）。VCL包含编解码器的信号处理功能、转换、量化和运动补偿指令等机制以及循环滤波器。它遵循了当今大多数视频编解码器的一般概念，这是一种基于宏块的编码器，使用运动补偿和残余信号的变换编码进行图像预测。VCL编码器输出切片：包含整数个宏块的宏块数据和切片头信息（包含切片中第一个宏块的空间地址、初始量化参数和类似信息）的位串。除非使用所谓的灵活宏块排序语法指定了不同的宏块分配，否则宏块inslices按扫描顺序排列。图片内预测仅用于一个切片内。更多信息见[9]。
网络抽象层（NAL）编码器将VCL编码器的片输出封装成网络抽象层单元（NAL单元），适用于分组网络传输或在面向分组的多路复用环境中使用。H.264的附录B定义了一个封装过程，通过面向字节流的网络传输这些NAL单元。在本备忘录范围内，附件B不相关。
在内部，NAL使用NAL单位。NAL单元由一个字节头和有效负载字节字符串组成。报头指示NAL单元的类型、NAL单元有效负载中存在（可能）的位错误或语法冲突，以及有关NAL单元对解码过程的相对重要性的信息。该RTP有效载荷规范旨在不知道NAL单元有效载荷中的位串。
H.264的主要特性之一是传输时间、解码时间以及切片和图片的采样或显示时间的完全解耦。H.264中指定的解码过程不知道时间，H.264语法不携带跳过帧的数量等信息（在早期视频压缩标准中，时间引用的形式很常见）。此外，还有影响许多图片的NAL单元，因此，它们本身是永恒的。因此，RTP时间戳的处理需要对NAL单元进行一些特殊考虑，因为NAL单元没有定义采样或表示时间，或者在传输时未知。
1.2. 参数集的概念
H.264的一个非常基本的设计概念是生成自包含的数据包，使诸如RFC2429[10]或MPEG-4的头扩展代码（HEC）[11]的头复制等机制变得不必要。这是通过从媒体流中分离与多个切片相关的信息来实现的。更高层的元信息应该从包含切片数据包的RTP数据包流中可靠、异步地提前发送。（对于没有适合的带外传输通道的应用程序，也可以在带内发送此信息。）更高级别参数的组合称为参数集。H.264规范包括两种类型的参数集：序列参数集和图片参数集。在编码视频序列中，活动序列参数集保持不变，而在编码图像中，活动图像参数集保持不变。序列和图片参数集结构包含图片大小、使用的可选编码模式以及宏块到切片组映射等信息。
为了能够改变图片参数（如图片大小），而不必将参数集更新同步传输到切片包流，编码器和解码器可以维护一个以上序列和图片参数集的列表。每个切片头包含一个代码字，指示要使用的序列和图片参数集。
该机制允许将参数集与包流的传输分离，并通过外部手段（例如，作为能力交换的副作用）或通过（可靠或不可靠）控制协议进行传输。甚至可能它们从未被传输，而是由应用程序设计规范固定。
1.3. 网络abstraction层单元类型
有关NAL设计的教程信息可以在[12]、[13]和[14]中找到。
所有NAL单元都由一个单一的NAL单元类型octet组成，它也作为这个RTP有效负载格式的有效负载头。NAL装置的有效载荷立即跟随。
Nal单元类型octet的语法和语义在[1]中指定，但Nal单元类型octet的基本属性总结如下。NAL单元类型octet具有以下格式：
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
下文简要介绍了H.264规范中规定的NAL单元类型octet组件的语义。
F:1位
禁止零位。H.264规范将1的值声明为语法冲突。
NRI:2位
国际数据中心。数值00表示NAL单元的内容不用于重建图像间预测的参考图像。这样的NAL单元可以丢弃，而不会危及参考图片的完整性。大于00的值表示需要对NAL单元进行解码，以保持参考图片的完整性。
Type：5位
NAL单元类型。此组件指定了NAL单位有效载荷类型，如[1]表7-1中所定义，稍后在本备忘录中定义。有关当前定义的所有NAL单元类型及其语义的参考，请参考[1]中的第7.4.1节。
本备忘录介绍了第5.2节中介绍的新NAL装置类型。本备忘录中定义的NAL单元类型在[1]中标记为未指定。此外，如第5.3节所述，本规范扩展了F和NRI的语义。
2. Conventions
本文件中的关键词”MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”应按照BCP 14、RFC 2119[3]的说明进行解释。
本规范使用了在处理位字段时设置和清除位的概念。设置位与将该位的值指定为1（开）相同。清除一个位与将该位的值指定为0（关）相同。
3. 范围
本有效载荷规范只能用于在RTP上承载“裸”H.264 NAL单元流，而不能用于H.264附录B中讨论的比特流格式。很可能，本规范的第一个应用是会话多媒体领域、视频电话或视频会议，但有效载荷格式也涵盖其他应用，如互联网流和IP电视。
4. Definitions and Abbreviations
4.1. Definitions
本文件使用了[1]的定义。为了方便起见，总结了[1]中定义的以下术语：
访问单元：一组NAL单元，通常包含一个主编码图片。除了主编码图片外，访问单元还可以包含一个或多个冗余编码图片或其他不包含编码图片切片或切片数据分区的NAL单元。一个存取单元的解码总是产生一个解码的图像。
编码视频序列：按解码顺序，由一个瞬时解码刷新（IDR）接入单元和零个或多个非IDR接入单元组成的接入单元序列，包括所有后续接入单元，但不包括任何后续的IDR接入单元。
IDR访问单元：主要编码图片是IDR图片的访问单元。
IDR图片：一种编码图片，只包含在解码过程中导致“重置”的I或SI切片类型的切片。在对IDR图像进行解码后，可以对解码顺序如下的所有编码图像进行解码，而无需对在IDR图像之前解码的任何图像进行相互预测。
主编码图片：解码过程对符合H.264的比特流使用的图片的编码表示。主编码图片包含图片的所有宏块。
冗余编码图片：图片或部分图片的编码表示。对于符合H.264的比特流，解码过程不得使用冗余编码图像的内容。冗余编码图片的内容可由解码过程用于包含错误或丢失的比特流。
VCL NAL单元：用于指编码切片和编码数据分区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. payload RTP格式
5.1. RTP报头usage
RTP报头的格式在RFC3550[4]中指定，为了方便起见，在图1中重新打印。此有效负载格式以与该规范一致的方式使用头字段。
当每个RTP包封装一个NAL单元时，建议的RTP有效载荷格式在第5.6节中指定。聚合数据包和碎片单元的RTP有效负载（以及某些RTP头位的设置）分别在第5.7节和第5.8节中指定。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X| CC |M| PT | sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| synchronization source (SSRC) identifier |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| contributing source (CSRC) identifiers |
| .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. RTP header according to RFC 3550
要根据此RTP有效负载格式设置的RTP头信息设置如下：
标记位（m）：1位
根据视频格式中M位的正常使用，为RTP时间戳指示的访问单元的最后一个数据包设置，以允许有效的播放缓冲区处理。对于聚合数据包（STAP和MTAP），RTP头中的标记位必须设置为聚合数据包的最后一个NAL单元的标记位如果在自己的RTP数据包中传输时的值。解码器可以使用此位作为访问单元最后一个数据包的早期指示，但不能依赖此属性。
信息提示：只有一个M位与携带多个NAL单元的聚合包相关联。因此，如果一个网关已经将一个聚合数据包重新打包成多个数据包，那么它就不能可靠地设置这些数据包的M位。
有效载荷类型（pt）：7位
此新数据包格式的RTP有效负载类型的分配超出了本文档的范围，将不会在此处指定。有效负载类型的分配必须通过使用的配置文件或以动态方式执行。
序列号（sn）：16位
根据RFC 3550设置和使用。对于单NALU和非交错分组方式，序列号用于确定NALU的解码顺序。
时间戳：32位
RTP时间戳设置为内容的采样时间戳。必须使用90 kHz的时钟频率。
如果NAL单元本身没有时间属性（例如，参数集和序列单元），则根据[1]第7.4.1.2节，RTP时间戳设置为包含NAL单元的访问单元的主要编码图片的RTP时间戳。
MTAP的RTP时间戳设置在第5.7.2节中定义。
接收器应该忽略包含在只有一个显示时间戳的访问单元中的任何图片定时SEI消息。相反，接收器应该使用RTP时间戳来同步显示过程。
对于不应显示为多个字段的图片，RTP发送方不应发送图片定时SEI消息。
如果一个接入单元在一个图像定时SEI报文中携带有多个显示时间戳，那么SEI报文中的信息应被视为相对于RTP时间戳的信息，最早的事件发生在RTP时间戳给出的时间，随后的事件则由SEI报文图像定时V中的差异给出。铝。让tsei1，tsei2，…，tsein作为一个接入单元的SEI报文中携带的显示时间戳，其中tsei1是所有这些时间戳中最早的一个。让tmadjst（）是一个将SEI消息时间刻度调整为90 kHz时间刻度的函数。让ts成为RTP时间戳。然后，与tsei1相关的事件的显示时间为ts。与tseix相关的事件的显示时间，其中x为[2..n]为ts+tmadjst（tseix-tsei1）。
提示性说明：在3:2下拉操作中，通常需要将编码帧显示为字段，在该操作中，由编码帧组成的胶片内容将使用隔行扫描显示在显示器上。picture timing sei消息可以为同一编码图片传输多个时间戳，因此3:2下拉过程是完全控制的。图片定时SEI消息机制是必要的，因为RTP时间戳中每个编码帧只能传递一个时间戳。
提示性说明：由于H.264允许解码顺序与显示顺序不同，RTP时间戳的值不能作为RTP序列号的函数单调地非递减。此外，rtcp报告中报告的时间间隔抖动值可能不是网络性能的可靠指标，因为时间间隔抖动的计算规则（RFC 3550第6.4.1节）假设数据包的rtp时间戳与其传输时间成正比。
5.2. 常见结构的payload RTP格式
有效载荷格式定义了三种不同的基本有效载荷结构。接收器可以通过RTP有效载荷的第一个字节来识别有效载荷结构，该字节co用作RTP有效载荷头，在某些情况下，作为有效载荷的第一个字节。这个字节总是作为NAL单元头结构。“NAL单位类型”字段指示存在的结构。可能的结构如下： 单NAL单元包：有效载荷中只包含一个NAL单元。NAL报头类型字段将等于原始NAL单元类型，即在1到23（包括1和23）范围内。第5.6节规定。 聚合数据包：用于将多个NAL单元聚合为单个RTP负载的数据包类型。此数据包有四个版本：单时间聚合数据包类型A（STAP-A）、单时间聚合数据包类型B（STAP-B）、16位偏移量的多时间聚合数据包（MTAP）和24位偏移量的多时间聚合数据包（MTAP）。分配给STAP-A、STAP-B、MTAP16和MTAP24的NAL单元类型号分别为24、25、26和27。第5.7节规定。 分段单元：用于在多个RTP包上对单个NAL单元进行分段。存在两个版本，fu-a和fu-b，分别用NAL单元类型编号28和29标识。第5.8节规定。Table 1. Summary of NAL unit types and their payload structures
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单元octet usage
第1.3节介绍了NAL单元八位字节的结构和语义。为方便起见，以下重新打印了NAL单元类型octet的格式：
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
本节根据本规范规定了F和NRI的语义。
F:1位
禁止零位。值0表示NAL单元类型octet和有效负载不应包含位错误或其他语法冲突。值1表示NAL单元类型octet和有效负载可能包含位错误或其他语法冲突。
Manes应设置F位以指示NAL单元中检测到的位错误。H.264规范要求F位等于0。设置F位时，建议解码器在有效负载或NAL单元类型octet中可能存在位错误或任何其他语法冲突。译码器对NAL单元的最简单反应是丢弃这样一个NAL单元，并将丢失的数据隐藏在丢弃的NAL单元中。
NRI:2位
国际数据中心。值00和非零值的语义与H.264规范保持不变。换句话说，值为00表示NAL单元的内容不用于重建图像间预测的参考图像。这样的NAL单元可以丢弃，而不会危及参考图片的完整性。大于00的值表示需要对NAL单元进行解码，以保持参考图片的完整性。
除上述规范外，根据本RTP有效载荷规范，NRI大于00的值表示编码器确定的相对传输优先级。鬃毛
可以使用此信息更好地保护更重要的NAL单元，而不是它们所做的不重要的NAL单元。最高的传输优先级是11，其次是10，然后是01；最后，00是最低的。
说明：NRI的任何非零值在H.264解码器中处理相同。因此，在将NAL单元传递给解码器时，接收器不需要操纵NRI的值。
当Nal_Unit_类型的值在1到12（包括1和12）范围内时，H.264编码器必须根据H.264规范（子条款7.4.1）设置NRI的值。特别是，H.264规范要求，对于所有NAL单元（NAL单元类型等于6、9、10、11或12）的NRI值应等于0。
对于Nal_Unit_类型等于7或8（分别表示序列参数集或图片参数集）的Nal单元，H.264编码器应将NRI值设置为11（二进制格式）。对于Nal_Unit_类型等于5（表示属于IDR图片的编码切片）的主编码图片的编码切片Nal单元，H.264编码器应将NRI值设置为11（二进制格式）。
对于剩余的NAL单元类型到NRI值的映射，可以使用以下示例，并且已经证明在特定环境中是有效的[13]。其他映射也可能是可取的，这取决于应用程序和使用中的H.264/AVC附录A概要。
提示性说明：数据分区在某些配置文件中不可用；例如，在主配置文件或基线配置文件中。因此，只有当视频比特流符合允许数据分区的配置文件，而不是符合主配置文件或基线配置文件的流时，才能出现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
说明：如前所述，非参考图片的NRI值为H.264/AVC规定的00。
H.264编码器应将冗余编码参考图片的编码切片和编码切片数据分区NAL单位的NRI值设置为01（二进制格式）。
本备忘录第5.7节和第5.8节给出了NAL装置类型24至29（含）的NRI值定义。
对于NAL-U单元类型在13至23（包括13至23）范围内的NAL单元，没有给出NRI值的建议，因为这些值是为ITU-T和ISO/IEC保留的。由于本备忘录中未规定这些值的语义，因此对于Nal_Unit_类型等于0或在30至31（含30至31）范围内的Nal单元，未给出NRI值的建议。
5.4. 打包模式
本备忘录规定了三种打包模式：
o单NAL单元模式
o非交错模式
o交错模式
单NAL单元模式针对符合ITU-T建议H.241[15]的会话系统（见第12.1节）。非交织模式针对的是可能不符合ITU-T建议H.241的会话系统。在非交织模式下，NAL单元按NAL单元解码顺序传输。交错模式针对的是不需要非常低的端到端延迟的系统。交错模式允许NAL单元的传输超出NAL单元解码顺序。
使用中的打包模式可以通过可选打包模式mime参数的值或通过外部方法发出信号。使用的打包模式控制RTP有效负载中允许哪些NAL单元类型。表3总结了每个打包模式允许的NAL单元类型。一些NAL单位类型值（在表3中表示为未定义）保留用于将来的扩展。这些类型的NAL单元不应该由发送方发送，并且必须被接收方忽略。例如，类型1-23与相关的数据包类型“NAL单元”在“单个NAL单元模式”和“非交错模式”中是允许的，但在“交错模式”中是不允许的。第6节将更详细地解释打包模式。
表3.每个打包模式允许的NAL单元类型摘要（是=允许，否=不允许，ig=忽略）
Type Packet Single NAL Non-Interleaved Interleaved
Unit Mode Mode 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 ig
5.5. 解码顺序号（DON）
在交错打包模式下，允许NAL单元的传输顺序不同于NAL单元的解码顺序。解码顺序号（DON）是有效载荷结构中的一个字段或指示NAL单元解码顺序的派生变量。第13节给出了解码顺序外传输和DON使用用例的基本原理和示例。
传输和解码顺序的耦合由可选的sprop交织深度mime参数控制，如下所示。当可选sprop交织深度mime参数的值等于0（显式或按默认值）或通过外部方式不允许NAL单元超出其解码顺序的传输时，NAL单元的传输顺序必须符合NAL单元解码顺序。当可选sprop交织深度mime参数的值大于0或允许通过外部方式传输非解码顺序的NAL单元时，
o MTAP16和MTAP24中的NAL单元顺序不需要是NAL单元解码顺序，以及
o将两个连续数据包中的stap bs、mtaps和fus解封装后生成的nal单元的顺序不需要是nal单元的解码顺序。
单个NAL单元包、STAP-A和FU-A的RTP有效载荷结构不包括DON。STAP-B和FU-B结构包括DON，MTAPS的结构允许按照第5.7.2节的规定推导DON。
提示：当一个fu-a以交错模式出现时，它总是跟随一个fu-b，它设置了它的don。
提示性说明：如果发送器想要封装每个数据包的单个NAL单元，并按照解码顺序发送数据包，则可以使用STAP-B数据包类型。
在单NAL单元封装模式下，由RTP序列号确定的NAL单元的传输顺序必须与它们的NAL单元解码顺序相同。在非交错分组方式下，NAL单元在单个NAL单元包、STAP AS和FU AS中的传输顺序必须与它们的NAL单元解码顺序相同。STAP中的NAL单元必须按NAL单元解码顺序出现。因此，解码顺序首先通过STAP内的隐式顺序提供，其次通过RTP序列号提供STAP、FUS和单个NAL单元包之间的顺序。
第5.7.1、5.7.2和5.8节分别规定了STAP-B、MTAP和以FU-B开头的一系列碎片单元的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值应为第一个NAL单元的DON值，递增1。
第7节给出了恢复NAL单元解码顺序的去封装过程的示例。
提示性说明：接收器不应期望NAL单元解码顺序中两个连续NAL单元的DON值的绝对差等于1，即使在无错误传输中也是如此。不需要一个增量，因为在将don的值与nal单位关联时，可能不知道是否所有nal单位都已交付给接收者。例如，当数据包转发到的网络中的比特率不足时，网关可能无法转发非参考图片的编码片单元或序列单元。在另一个例子中，实时广播不时被预先编码的内容（如广告）中断。预先编码的片段的第一幅内部图像是预先传输的，以确保它在接收器中随时可用。在传输第一幅内部图像时，发起者并不确切知道在预编码片段的第一幅内部图像按照解码顺序进行编码之前，将编码多少个NAL单元。因此，当预编码片段的第一张内部图像的NAL单位的DON值被传输时，必须对其进行估计，并且DON值可能出现间隙。
5.6. 单NAL单元包
此处定义的单个NAL单元数据包只能包含一个NAL单元，其类型在[1]中定义。这意味着聚合包和碎片单元都不能在单个NAL单元包中使用。由以RTP序列号顺序对单个NAL单元数据包进行去封装构成的NAL单元流必须符合NAL单元解码顺序。单个NAL单元包的结构如图2所示。
提示性说明：NAL单元co的第一个字节用作RTP有效载荷头。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|NRI| type | |
+-+-+-+-+-+-+-+-+ |
| |
| Bytes 2..n of a Single NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图2.单NAL单元包的RTP有效载荷格式
5.7. 聚合数据包
聚合数据包是本有效负载规范的NAL单元聚合方案。引入该方案是为了反映两个关键目标网络的MTU大小显著不同：有线IP网络（MTU大小通常受以太网MTU大小限制；大约1500字节）和基于IP或非IP（例如，ITU-T H.324/M）的无线通信系统，首选传输单元大小为254字节或更小。为了防止媒体在两个世界之间转码，避免不必要的打包开销，引入了一种NAL单元聚合方案。
本规范定义了两种类型的聚合数据包：
o单时间聚合包（STAP）：聚合具有相同NALU时间的NAL单元。定义了两种类型的stap，一种没有don（stap-a），另一种包括don（stap-b）。
o多时间聚合包（MTAP）：聚合具有不同NALU时间的NAL单元。定义了两个不同的MTAP，NAL单位时间戳偏移量的长度不同。
术语NALU时间定义为RTP时间戳的值，如果NAL单元将在其自己的RTP包中传输，则该值将具有。
在聚合包中携带的每个NAL单元封装在聚合单元中。请参阅下面四个不同的聚合单元及其特性。
聚合数据包的RTP有效负载格式的结构如图3所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|NRI| type | |
+-+-+-+-+-+-+-+-+ |
| |
| one or more aggregation units |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图3.聚合数据包的RTP负载格式
MTAP和STAP共享以下打包规则：RTP时间戳必须设置为要聚合的所有NAL单元的NALU时间中最早的一个。NAL单元类型octet的类型字段必须设置为适当的值，如表4所示。如果聚合NAL单元的所有F位都为零，则必须清除F位；否则，必须设置F位。NRI的值必须是聚合数据包中携带的所有NAL单元的最大值。
表4.staps和mtap的类型字段
Type Packet Timestamp offset DON related fields
field length (DON, DONB, DOND)
(in bits) 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. Single-Time Aggregation Packet
每当NAL单元聚合时，都应使用一次性聚合数据包（STAP），所有这些单元共享相同的NALU时间。STAP-A的有效负载不包括DON，并且至少由一个单时间聚合单元组成，如图4所示。STAP-B的有效负载由16位无符号解码顺序号（DON）（按网络字节顺序）和至少一个单时间聚合单元组成，如图5所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: |
+-+-+-+-+-+-+-+-+ |
| |
| single-time aggregation units |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Payload format for STAP-A
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: decoding order number (DON) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| single-time aggregation units |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5. Payload format for STAP-B
DON字段按传输顺序指定STAP-B中第一个NAL单元的DON值。对于STAP-B中外观顺序的每个连续NAL单元，DON值等于（STAP-B中前一个NAL单元的DON值+1）%65536，其中“%”表示模运算。
单个时间聚合单元由16位无符号大小信息（按网络字节顺序）组成，该信息以字节表示以下NAL单元的大小（不包括这两个八位字节，但包括NAL单元的NAL单元类型八位字节），然后是NAL单元本身，包括其NAL单元类型字节。单个时间聚合单元在RTP负载内是字节对齐的，但它可能不会在32位字边界上对齐。图6显示了单时间聚合单元的结构。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: NAL unit size | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. Structure for single-time aggregation unit
图7给出了一个包含STAP-A的RTP包的示例。STAP包含两个单时间聚合单元，图中标记为1和2。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAP-A NAL HDR | NALU 1 Size | NALU 1 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Data |
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | NALU 2 Size | NALU 2 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 Data |
: :
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图7.一个RTP包的例子，包括一个STAP-A和两个单时间聚合单元
图8给出了一个包含STAP-B的RTP包的示例。STAP包含两个单时间聚合单元，图中标记为1和2。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAP-B NAL HDR | DON | NALU 1 Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Size | NALU 1 HDR | NALU 1 Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | NALU 2 Size | NALU 2 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 Data |
: :
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图8.一个RTP包的例子，包括一个STAP-B和两个单时间聚合单元
5.7.2. Multi-Time Aggregation Packets (MTAPs)
MTAPS的NAL单元有效载荷由一个16位无符号解码顺序基数（DONB）（按网络字节顺序）和一个或多个多时间聚合单元组成，如图9所示。DONB必须在MTAP的NAL单元之间包含NAL单元解码顺序中第一个NAL单元的DON值。
提示性说明：NAL单元解码顺序中的第一个NAL单元不一定是NAL单元封装在MTAP中的顺序中的第一个NAL单元。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: decoding order number base | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| multi-time aggregation units |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图9.MTAP的NAL单位有效载荷格式
本规范中定义了两个不同的多时间聚合单元。这两个单元都由以下NAL单元的16位无符号大小信息（按网络字节顺序）、8位无符号解码顺序号差（DOND）和N位（按网络字节顺序）组成，其中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时间小于数据包的RTP时间戳，则时间戳偏移量等于NALU时间+（2^32-数据包的RTP时间戳）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: NAL unit size | DOND | TS offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS offset | |
+-+-+-+-+-+-+-+-+ NAL unit |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图10.MTAP16的多时间聚合单元
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: NALU unit size | DOND | TS offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS offset | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| NAL unit |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图11.用于MTAP24的多时间聚合单元
对于MTAP中的“最早”多时间聚合单元，时间戳偏移量必须为零。因此，mtap本身的rtp时间戳与最早的nalu时间相同。
提示：如果聚合单元封装在单个NAL单元包中，“最早”的多时间聚合单元将在MTAP的所有聚合单元中具有最小的扩展RTP时间戳。扩展时间戳是一个具有超过32位的时间戳，它能够计算时间戳字段的环绕，从而使人能够确定时间戳缠绕时的最小值。这种“最早的”聚合单元可能不是按聚合单元封装在MTAP中的顺序排列的第一个聚合单元。“最早”NAL单元也不需要与NAL单元解码顺序中的第一个NAL单元相同。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MTAP16 NAL HDR | decoding order number base | NALU 1 Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Size | NALU 1 DOND | NALU 1 TS offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 HDR | NALU 1 DATA |
+-+-+-+-+-+-+-+-+ +
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | NALU 2 SIZE | NALU 2 DOND |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 TS offset | NALU 2 HDR | NALU 2 DATA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
: :
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图12显示了一个RTP数据包的示例，该数据包包含一个MTAP16类型的多时间聚合数据包，该数据包包含两个多时间聚合单元，图中标记为1和2。
图12。一种RTP包，包括MTAP16型的多时间聚合包和两个多时间聚合单元。
图13展示了一个RTP数据包的示例，该数据包包含一个MTAP24类型的多时间聚合数据包，该数据包包含两个多时间聚合单元，图中标记为1和2。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MTAP24 NAL HDR | decoding order number base | NALU 1 Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 1 Size | NALU 1 DOND | NALU 1 TS offs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|NALU 1 TS offs | NALU 1 HDR | NALU 1 DATA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
: :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | NALU 2 SIZE | NALU 2 DOND |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 TS offset | NALU 2 HDR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NALU 2 DATA |
: :
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图13。一种RTP包，包括MTAP24型的多时间聚合包和两个多时间聚合单元。
5.8. 碎片单位（fus）
这种有效载荷类型允许将一个NAL单元分割成几个RTP包。在应用层上这样做而不是依赖较低层的碎片（例如，通过IP）具有以下优点：
o有效载荷格式能够通过可能存在于预录视频中的IPv4网络传输大于64千字节的NAL单元，尤其是在高清晰度格式中（每个图片的片数有限制，这导致每个图片的NAL单元数限制，这可能导致NAL单元数大）。
o碎片机制允许对单个图片进行碎片化，并应用第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由一个八位字节的碎片单元指示器、一个八位字节的碎片单元头和一个碎片单元有效载荷组成。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FU indicator | FU header | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| FU payload |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图14.fu-a的rtp有效载荷格式
图15显示了fu bs的rtp有效负载格式。fu-b由一个八位字节的碎片单元指示器、一个八位字节的碎片单元头、解码顺序号（don）（按网络字节顺序）和碎片单元有效载荷组成。换言之，除了附加唐场外，傅B的结构与傅A的结构相同。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FU indicator | FU header | DON |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |
| FU payload |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| :...OPTIONAL RTP padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
图15。fu-b的rtp有效载荷格式
对于分散的NAL单元的第一个分段单元，必须在交错打包模式中使用类型为FU-B的NAL单元。在任何其他情况下，不得使用NAL FU-B型装置。换句话说，在交错打包模式中，每个被分割的NALU都有一个fu-b作为第一个片段，后面跟着一个或多个fu-a片段。
fu指示符八位字节的格式如下：
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|F|NRI| Type |
+---------------+
在fu指示符八位字节的类型字段中，值等于28和29分别标识fu-a和fu-b。第5.3节描述了F位的使用。NRI字段的值必须根据碎片NAL单位中的NRI字段的值进行设置。
fu头的格式如下：
+---------------+
|0|1|2|3|4|5|6|7|
+-+-+-+-+-+-+-+-+
|S|E|R| Type |
+---------------+
S:1位
当设置为1时，起始位表示分段NAL单元的开始。当以下fu有效载荷不是分段NAL单元有效载荷的起始时，起始位设置为零。
E:1位
当设置为1时，结束位表示分段NAL单元的结束，即有效负载的最后一个字节也是分段NAL单元的最后一个字节。当下面的fu有效载荷不是一个分段的nal单元的最后一个片段时，结束位被设置为零。
R:1位
保留位必须等于0，并且必须被接收器忽略。
类型：5位
[1]表7-1中定义的NAL单位有效载荷类型。
根据第5.5节所述，选择Fu Bs中的Don值。
信息提示：fu-bs中的don字段允许网关将NAL单元拆分为fu-bs，而不将传入的NAL单元组织为NAL单元解码顺序。
一个分段的NAL单元不能在一个FU中传输；即，起始位和结束位不能同时设置为同一个FU头中的一个。
FU有效载荷由碎片化NAL单元的有效载荷的碎片组成，因此，如果连续FUS的碎片化单元有效载荷按顺序连接，则可以重建碎片化NAL单元的有效载荷。碎片化NAL单元的NAL单元类型八位字节不包括在碎片化单元有效载荷中，而是碎片化NAL单元的NAL单元类型八位字节的信息在碎片化单元的FU指示八位字节的F和NRI字段以及FU头的类型字段中传送。一个fu负载可以有任意数量的八位字节，并且可以是空的。
信息提示：允许空的fus在几乎无损的环境中减少某类发送者的延迟。这些发送者的特点是，他们在NALU完全生成之前打包NALU片段，因此，在NALU大小已知之前。如果不允许使用零长度的NALU片段，发送方必须生成以下片段的至少一位数据，然后才能发送当前片段。由于H.264的特点，有时
几个宏块占用零位，这是不需要的，可以增加延迟。但是，应仔细权衡零长度NALU的（潜在）使用，以防由于用于其传输的额外数据包而增加NALU丢失的风险。
如果碎片单元丢失，接收器应按照与同一碎片单元对应的传输顺序丢弃以下所有碎片单元。
端点或mane中的接收器可以将NAL单元的第一个n-1片段聚合为（不完整的）NAL单元，即使未接收到该NAL单元的片段n。在这种情况下，NAL单元的禁止零位必须设置为1，以指示语法冲突。
6. 包装规则
第5.2节介绍了包装模式。第6.1节规定了多个打包模式通用的打包规则。单NAL单元模式、非交错模式和交错模式的打包规则分别在第6.2、6.3和6.4节中规定。
6.1. 通用包装规则
无论使用何种打包模式，所有发送方都必须强制执行以下打包规则：
o属于同一编码图片的编码片NAL单元或编码片数据分区NAL单元（因此共享相同的RTP时间戳值）可以按照[1]中定义的适用配置文件允许的任何顺序发送；但是，对于延迟关键系统，应按照其原始编码顺序发送，以尽量减少延迟。注意，编码顺序不一定是扫描顺序，但是NAL包对RTP堆栈可用的顺序。
o参数集按照第8.4节给出的规则和建议进行处理。
o由于本备忘录和H.264规范均未提供识别重复NAL单元的方法，因此，除序列或图片参数设置NAL单元外，Manes不得复制任何NAL单元。序列和图片参数集NAL单元可以被复制，以使其正确接收更为可能，但任何此类复制不得影响任何活动序列或图片参数集的内容。重复应该是
在应用层上执行，而不是通过复制RTP数据包（具有相同的序列号）。
使用非交错模式和交错模式的发件人必须强制执行以下打包规则：
在RTP转换器中，许多人可以将单个NAL单元数据包转换为一个聚合数据包，将聚合数据包转换为多个单个NAL单元数据包，或者混合这两个概念。RTP转换器应至少考虑以下参数：路径MTU大小、不平等的保护机制（例如，根据RFC 2733[18]通过基于包的FEC，尤其是序列和图片参数集NAL单元和编码切片数据分区NAL单元）、系统可承受的延迟和缓冲能力F接收器。
提示性说明：根据RFC3550，需要一个RTP转换器来处理RTCP。
6.2. 单NAL单元模式
当可选打包模式mime参数的值等于0、打包模式不存在或没有其他打包模式通过外部方式发出信号时，将使用此模式。所有接收器必须支持此模式。它主要用于与使用ITU-T建议H.241[15]的系统兼容的低延迟应用（见第12.1节）。此模式中只能使用单个NAL单元数据包。不能使用staps、mtaps和fus。单个NAL单元包的传输顺序必须符合NAL单元解码顺序。
6.3. 非交错模式
当可选打包模式mime参数的值等于1或通过外部方式打开模式时，将使用此模式。应支持此模式。主要用于低延迟应用。此模式中只能使用单个NAL单元包、STAP AS和FU AS。不得使用stap bs、mtaps和fu bs。NAL单元的传输顺序必须符合NAL单元解码顺序。
6.4. 交错模式
当可选打包模式mime参数的值等于2或通过外部方式打开模式时，将使用此模式。有些接收器可能支持此模式。可以使用stap bs、mtaps、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提供/应答模型或任何其他功能交换过程时，接收流的属性应确保不超过接收器的能力。在sdp provide/answer模型中，接收器可以指示其使用deint-buf cap mime参数分配逐行扫描缓冲区的能力。发送方用sprop deint buf req mime参数指示逐行输入缓冲区大小的要求。因此，建议按字节数设置逐行扫描缓冲区大小，等于或大于sprop deint buf req mime参数的值。有关设计buf cap和sprop设计buf req mime参数的更多信息，请参见第8.1节；有关在SDP提供/应答模型中使用这些参数的更多信息，请参见第8.2.2节。
当在会话设置中使用声明性会话描述时，sprop deint buf req mime参数表示需要逐行输入缓冲区大小。因此，建议按字节数设置逐行扫描缓冲区大小，等于或大于sprop deint buf req mime参数的值。
7.2.2. 逐行扫描
接收器中有两种缓冲状态：初始缓冲和播放时缓冲。初始化RTP会话时会发生初始缓冲。初始缓冲后，开始解码和回放，使用播放时缓冲模式。
不管缓冲状态如何，接收器按照接收顺序将传入的NAL单元存储在逐行缓冲区中，如下所示。聚合数据包的NAL单元单独存储在逐行扫描缓冲区中。计算并存储所有NAL单位的DON值。
在以下功能和常量的帮助下，接收器操作描述如下：
o第8.1节规定了ABSDON功能。
o第5.5节中规定了函数don_diff。
o constant n是可选sprop交织深度mime类型参数（见第8.1节）的值，递增1。
初始缓冲持续到满足以下条件之一：
o去隔行缓冲区中有n个VCL NAL单元。
o如果存在sprop max don diff，则don_diff（m，n）大于sprop max don diff的值，其中n对应接收到的NAL单位中absdon值最大的NAL单位，m对应接收到的NAL单位中absdon值最小的NAL单位。
o初始缓冲持续时间等于或大于可选sprop init buf time mime参数的值。
要从逐行扫描缓冲区中删除的NAL单位确定如下：
o如果逐行缓冲区包含至少n个VCL NAL单元，则NAL单元将从逐行缓冲区中删除，并按下面指定的顺序传递给解码器，直到缓冲区包含n-1个VCL NAL单元为止。
o如果存在sprop max don diff，则从逐行扫描缓冲区中删除所有don diff（m，n）大于sprop max don diff的NAL单元m，并按下面指定的顺序传递给解码器。在这里，n对应于接收到的nal单位中absdon值最大的nal单位。
NAL单元传递给解码器的顺序如下：
o让pdon成为在RTP会话开始时初始化为0的变量。
o对于与DON值相关的每个NAL单位，DON距离计算如下。如果NAL单位的don值大于pdon值，则don距离等于don-pdon。否则，don距离等于65535-pdon+don+1。
所有单元按数据距离的升序传送到解码器。如果几个NAL单元共享同一个DON距离值，它们可以以任何顺序传递给解码器。
o当向解码器传递了所需数量的NAL单元时，PDON的值设置为最后一个传递给解码器的NAL单元的DON值。
7.3. 额外的去包装指南
可以使用以下附加的解包规则来实现可操作的H.264解包器：
o智能RTP接收器（例如，在网关中）可以识别丢失的编码切片数据分区A（DPA）。如果发现丢失的DPA，网关可能会决定不发送相应的编码切片数据分区B和C，因为它们的信息对于H.264解码器没有意义。通过这种方式，mane可以通过丢弃无用的数据包而不解析复杂的比特流来减少网络负载。
o智能RTP接收器（例如，在网关中）可识别丢失的保险丝。如果发现丢失的fu，网关可能会决定不发送相同碎片单元的以下fus，因为它们的信息对H.264解码器没有意义。通过这种方式，mane可以通过丢弃无用的数据包而不解析复杂的比特流来减少网络负载。
o必须丢弃数据包或NALU的智能接收器应首先丢弃所有数据包/NALU，其中NAL单元类型八位字节的NRI字段值等于0。这将最小化对用户体验的影响，并保持参考图片的完整性。如果需要丢弃更多的数据包，那么NRI值数值较低的数据包应该在NRI值数值较高的数据包之前丢弃。然而，丢弃任何NRI大于0的数据包很可能导致解码器漂移，应避免。
8. 有效载荷格式参数
本节指定可用于选择有效负载格式的可选功能和位流的某些功能的参数。此处指定的参数是ITU-T H.264_ISO/IEC 14496-10编解码器的mime子类型注册的一部分。还为使用SDP的应用程序提供了会话描述协议（SDP）[5]中参数的映射。可在其他地方定义等效参数，用于不使用mime或sdp的控制协议。
一些参数为接收器提供将要发送的流的属性。所有这些参数的名称都以流属性的“sprop”开头。其中一些“sprop”参数受其他有效负载或编解码器配置参数的限制。例如，sprop参数集参数由profile level id参数约束。媒体发送器选择所有“sprop”参数，而不是接收器。“sprop”参数的这种不常见特性可能与某些信令协议概念不兼容，在这种情况下，应避免使用这些参数。
8.1. MIME注册
ITU-T H.264_ISO/IEC 14496-10编解码器的mime子类型从ietf树中分配。
接收器必须忽略任何未指定的参数。
媒体类型名称：视频
媒体子类型名称：h264
所需参数：无
可选参数：
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）级别_idc。请注意，在[1]中保留的“零位”必须等于0，但ITU-T或ISO/IEC以后可能会指定它的其他值。
如果profile level id参数用于指示NAL单元流的属性，则它指示解码器解码流时必须支持的配置文件和级别，以便符合[1]。profile iop字节指示NAL单元流是否也遵守以下所示配置文件的所有约束。如果剖面IOP的位7（最高有效位）、位6或位5等于1，则NAL单元流中分别遵守基线剖面、主剖面或扩展剖面的所有约束。
如果配置文件级别ID参数用于功能交换或会话设置过程，则表示编解码器支持的配置文件和信号配置文件支持的最高级别。profile iop字节表示编解码器是否有其他限制，因此编解码器仅支持用profile iop字节表示的profile和profile_idc指示的profile的算法特征和限制的公共子集。例如，如果编解码器仅支持基线配置文件和2.1级及以下主配置文件编码工具的公共子集，则配置文件级别ID将变为42e0 15，其中42表示基线配置文件，e0表示仅支持所有配置文件的公共子集，15表示2.1级。
信息提示：功能交换和会话设置过程应提供分别列出每个支持的编解码器配置文件的功能的方法。例如，可以使用SDP提供/应答模型的one-of-n编解码器选择过程（第10.2节，共[7]节）。
如果不存在配置文件级别ID，则必须隐含在级别1没有附加约束的基线配置文件。
max-mbps, max-fs, max-cpb, max-dpb, and max-br:
这些参数可以用来表示接收器实现的能力。这些参数不能用于任何其他目的。配置文件级别ID参数必须存在于包含任何这些参数的同一接收器功能描述中。在配置文件级别ID参数值中传递的级别必须使接收器完全能够支持。max-mbps、max-fs、max-cpb、max-dpb和max-br可用于指示接收器扩展信号电平所需能力的能力，如下所述。
当集合中存在多个参数（max mbps、max fs、max cpb、max dpb、max br）时，接收器必须同时支持所有信号能力。例如，如果同时存在最大Mbps和最大Br，则支持帧速率和比特率扩展的信号电平。也就是说，接收器能够解码NAL单元流，其中宏块处理速率高达最大Mbps（含），比特率高达最大Br（含），编码的图片缓冲区大小根据下面的max Br参数的语义推导，其他属性符合prof值中指定的级别。文件级ID参数。
接收器不得发出满足更高级别要求的最大Mbps、最大fs、最大cpb、最大dpb和最大br的信号值，
这里称为A级，与profile-level id参数值中指定的级别相比，如果接收器可以支持A级的所有属性。
提示性说明：当可选的mime类型参数用于信号NAL单元流的属性时，不存在max mbps、max fs、max cpb、max dpb和max br，并且配置文件级别ID的值必须始终使NAL单元流完全符合指定的配置文件和级别。
max-mbps:
max-mbps的值是一个整数，以每秒宏块的单位表示最大宏块处理速率。max mbps参数表示接收器能够以高于配置文件级别ID参数值中所传输信号级别所需的速率解码视频。当发出最大Mbps信号时，接收器必须能够解码符合信号电平的NAL单元流，除非信号电平的表A-1中的最大Mbps值被最大Mbps值替换。对于[1]的表A-1中给出的级别，max mbps的值必须大于或等于maxmbps的值。发送方可以使用此知识以高于信号级别指示的图片速率发送给定大小的图片。
max-fs：
max-fs的值是一个整数，以宏块为单位表示最大帧大小。max fs参数表示接收器能够解码比配置文件级别id参数值中所传输的信号级别所需的更大的图片大小。当发出max fs信号时，接收器必须能够解码符合信号电平的NAL单元流，除非[1]表A-1中信号电平的maxfs值替换为max fs值。对于[1]的表A-1中给出的级别，max fs的值必须大于或等于maxfs的值。发件人可以使用此知识在
成比例地比信号电平中所示的低帧速率。
最大cpb最大cpb值是一个整数，表示VCL HRD参数的最大编码图片缓冲区大小，单位为1000位（见[1]的A.3.1第i项），NAL HRD参数的单位为1200位（见[1]的A.3.1第j项）。max cpb参数表示接收器的内存大于profile level id参数值中传输的信号级别所需的最小编码图片缓冲内存量。当发出max cpb信号时，接收器必须能够解码符合信号电平的NAL单元流，除非信号电平的表A-1中的maxcpb值被max cpb值替换。对于[1]的表A-1中给出的级别，max cpb的值必须大于或等于maxcpb的值。发送方可以利用这一知识来构造编码视频流，其比特率变化比[1]表A-1中的maxcpb值所能实现的变化大。
说明：编码图片缓冲区用于H.264的假设参考解码器（附录C）。建议在H.264编码器中使用假设的参考解码器，以验证生成的比特流是否符合标准并控制输出比特率。因此，编码图片缓冲区在概念上独立于接收器中的任何其他潜在缓冲区，包括去交织和去抖动缓冲区。编码图片缓冲区不需要按照H.264附录C的规定在解码器中实现，但是，如果符合标准的解码器能够解码符合标准的比特流，那么它们可以有任何缓冲安排。因此，在实际应用中，视频解码器的输入缓冲区可以与接收机的去交织和去抖动缓冲区相结合。
max-dpb：
max-dpb的值是一个整数，表示最大解码图片缓冲区大小，单位为1024字节。max dpb参数表示接收器的内存大于配置文件级别id参数值中传输的信号级别所需的最小解码图像缓冲内存量。当发出max dpb信号时，接收器必须能够解码符合信号电平的NAL单元流，除非信号电平的表A-1中的maxdpb值被max dpb值替换。因此，信号最大dpb的接收器必须能够在其解码图像缓冲区中存储以下数量的解码帧、互补字段对和非配对字段：
最小（1024max dpb/（picWidthinmbsframeHeightinmbs256chromaFormatfor），16）
picwidthinmbs、frameheightinmbs和chromaFormatfort在[1]中定义。
对于[1]的表A-1中给出的级别，max dpb的值必须大于或等于maxdpb的值。发送者可以利用这一知识来构造具有改进压缩的编码视频流。
提示性说明：该参数主要是为了补充ITU-T建议H.245中类似的代码点，以便于信令网关设计。解码后的图片缓冲区存储重建的样本，并且仅为视频解码器的属性。解码图像缓冲区的大小与RTP中使用的缓冲区没有关系，特别是去交织和去抖动缓冲区。
max-br：
max-br的值是一个整数，表示VCL HRD参数的最大视频比特率，单位为每秒1000位（见[1]的A.3.1第i项），单位为1200位。
NAL HRD参数每秒（见[1]的A.3.1第j项）。
max-br参数表示接收器的视频解码器能够以高于profile level id参数值中传输的信号电平所需的比特率解码视频。对于[1]的表A-1中给出的级别，max-br的值必须大于或等于maxbr的值。
当发出max-br信号时，接收器的视频编解码器必须能够解码符合信号电平的NAL单元流，该电平在profile level id参数中传输，但在该电平指定的限值中有以下例外：
o max-br值代替信号电平的maxbr值（见[1]表A-1）。
o当max cpb参数不存在时，以下公式的结果将替换[1]表A-1中maxcpb的值：（信号电平的maxcpb）*信号电平的max br/（maxbr）。
例如，如果1.2级接收器信号能力的最大Br等于1550，则表示VCL hrd参数的最大视频比特率为1550 kbits/sec，NAL hrd参数的最大视频比特率为1860 kbits/sec，CPB大小为4036458位（1550000/38400010001000）。
对于[1]表A-1中给出的信号电平，max-br的值必须大于或等于maxbr。
发送方可以使用此知识发送H.264附录A级别定义中允许的更高比特率视频，以提高视频质量。
提示性说明：该参数主要是为了补充ITU-T建议H.245中类似的代码点，以便于信令网关设计。不能从
网络能够在任何给定时间处理这种比特率的参数。特别是，不能得出在拥塞控制约束下信号比特率是可能的结论。
redundant-pic-cap:
此参数表示接收器实现的能力。当等于0时，该参数表示接收器没有尝试使用冗余编码图片来纠正错误解码的主编码图片。当等于0时，接收器不能使用冗余片；因此，发送方应避免发送冗余片以节省带宽。当等于1时，接收器能够解码覆盖主解码图像中损坏区域的任何冗余片（至少部分），因此发送方可以发送冗余片。当参数不存在时，必须将0值用于冗余PIC CAP。当存在时，冗余pic cap的值必须为0或1。
当配置文件级别ID参数与冗余pic cap参数在相同的能力信令中存在，并且配置文件级别ID中指示的配置文件不允许使用冗余编码图片（例如主配置文件）时，冗余pic cap的值必须等于0。当接收器指示冗余的pic cap等于0时，接收的流不应包含冗余的编码图片。
提示：即使冗余pic cap等于0，解码器也可以忽略冗余的编解码器图片，前提是解码器支持这样一个配置文件（基线、扩展），其中允许冗余的编码图片。
提示性说明：即使冗余pic cap等于1，接收器也可以选择其他错误隐藏策略来
替换或补充冗余片的解码。
sprop-parameter-sets:
此参数可用于传输任何序列和图像参数集NAL单元（此处称为初始参数集NAL单元），该序列和图像参数集NAL单元必须在解码顺序中位于任何其他NAL单元之前。参数不能用于指示任何功能交换过程中的编解码器功能。参数值是初始参数集NAL单位的base64[6]表示，如[1]第7.3.2.1和7.3.2.2节所规定。参数集按解码顺序传输，不发生参数集NAL单元的帧。逗号用于分隔列表中的任何一对参数集。请注意，参数集NAL单元中的字节数通常小于10，但图片参数集NAL单元可以包含数百个字节。
提示性说明：当在SDP提供/应答模型中提供多个有效载荷类型时，每个类型都有自己的sprop参数-集参数，那么接收器不能假定这些参数集不使用冲突的存储位置（即参数集标识符的相同值）。因此，接收器应该对所有sprop参数集进行双重缓冲，并使它们对解码某一负载类型的解码器实例可用。
parameter-add:
此参数可用于指示是否允许此参数的接收器使用sprop参数sets mime参数在其信号响应中添加参数集。此参数的值为0或1。0等于false，即不允许添加参数集。1等于真，即允许增加参数集。如果参数不存在，则其值必须为1。
packetization-mode:
此参数表示RTP有效负载类型的属性或接收器实现的能力。只能指示一个配置点；因此，当声明支持多个打包模式的功能时，必须使用多个配置点（RTP负载类型）。
当打包模式的值等于0或不存在打包模式时，必须使用RFC 3984第6.2节中定义的单一NAL模式。该模式在使用ITU-T建议H.241[15]的标准中使用（见第12.1节）。当打包模式的值等于1时，必须使用RFC 3984第6.3节中定义的非交错模式。当打包模式的值等于2时，必须使用RFC 3984第6.4节中定义的交错模式。打包模式的值必须是0到2（包括0和2）范围内的整数。
sprop-interleaving-depth:
当不存在打包模式或打包模式的值等于0或1时，此参数不能存在。当打包模式的值等于2时，此参数必须存在。
此参数表示NAL单元流的属性。它以传输顺序指定NAL单元流中任何VCL NAL单元之前的VCL NAL单元的最大数目，并按照解码顺序跟随VCL NAL单元。因此，当NAL单元解码顺序恢复的缓冲区大小至少为SPROP-交织深度+1的VCL NAL单元值时，接收机可以重建NAL单元解码顺序。
sprop交织深度的值必须是0到32767（含）范围内的整数。
sprop-deint-buf-req:
当不存在打包模式或打包模式的值等于0或1时，此参数不能存在。当打包模式的值等于2时，它必须存在。
sprop deint buf req向NAL单元流的逐行扫描缓冲区的所需大小发出信号。参数值必须大于或等于RFC 3984第7.2节中规定的这种逐行缓冲区所需的最大缓冲区占用率（以字节为单位）。当逐行缓冲区大小至少为sprop-deint-buf-req的字节值时，保证接收机可以将交错的NAL单元逐行逐行转换为NAL单元解码顺序。
sprop deint buf req的值必须是0到4294967295（含）范围内的整数。
提示性说明：sprop deint buf req仅指示逐行缓冲区的所需大小。当网络抖动可能发生时，还必须为其提供适当大小的抖动缓冲区。
deint-buf-cap:
此参数表示接收器实现的能力，并指示接收器可用于重建NAL单元解码顺序的以字节为单位的逐行输入缓冲区空间量。接收器能够处理sprop deint buf req参数值小于或等于此参数的任何流。
如果参数不存在，则必须将值0用于除盐缓冲罐盖。Deint Buf Cap的值必须是0到4294967295（含）范围内的整数。
提示性说明：Deint Buf Cap仅指示接收器的逐行缓冲区的最大可能大小。
当网络抖动可能发生时，还必须为其提供适当大小的抖动缓冲区。
sprop-init-buf-time:
此参数可用于向NAL单元流的属性发送信号。如果打包模式的值等于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。
该参数被编码为非负的base10整数表示，以90-kHz时钟的时钟周期为单位。如果参数不存在，则不定义初始缓冲时间值。否则，sprop init-buf time的值必须是0到4294967295（包括0和4294967295）之间的整数。
除了发出信号的sprop init buf时间外，接收器还应考虑传输延迟抖动缓冲，包括混音器、翻译器、网关、代理、流量整形器和其他网络元素引起的延迟抖动的缓冲。
sprop-max-don-diff:
此参数可用于向NAL单元流的属性发送信号。它不能用于信号发送器或接收器或编解码器功能。如果打包模式的值等于0或1，则参数不能存在。sprop max don diff是一个介于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。
最大Rcmd Nalu大小的值必须是0到4294967295（含）范围内的整数。如果未指定此参数，则不存在对NALU大小的已知限制。发送方仍然必须考虑发送方和接收方之间可用的MTU大小，并为此目的运行MTU发现。
例如，这个参数的动机是IP到H.223视频电话网关，其中Nalus小于H.223传输数据。
单位效率会更高。网关可能会终止IP；因此，MTU发现通常不会在网关之外工作。
提示性说明：将此参数设置为低于必要值可能会产生负面影响。
Encoding considerations:
此类型仅为通过RTP（RFC 3550）传输而定义。
[29]中定义了H.264/AVC视频的文件格式。此定义由其他文件格式使用，例如3gpp多媒体文件格式（mime-type-video/3gpp）[30]或mp4文件格式（mime-type-video/mp4）。
Security considerations:
See section 9 of RFC 3984.
Public specification:
Please refer to RFC 3984 and its section 15.
Additional information:
None
File extensions: none
Macintosh file type code: none
Object identifier or OID: none
Person & email address to contact for further information: stewe@stewe.org
Intended usage: COMMON
Author: stewe@stewe.org
Change controller: IETF Audio/Video Transport working group delegated from the IESG.
8.2. SDP参数
8.2.1. 将mime参数映射到sdp
mime media type video/h264字符串映射到会话描述协议（sdp）[5]中的字段，如下所示：
o SDP“m=”行中的媒体名称必须是视频。
o sdp的“a=rtpmap”行中的编码名称必须是h264（mime子类型）。
o“a=rtpmap”行中的时钟速率必须为90000。
o可选参数”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提供/应答模型
当H.264通过使用SDP在提供/应答模型[7]中的RTP提供用于协商单播使用时，以下限制和规则适用
o标识H.264媒体格式配置的参数为“配置文件级别ID”、“打包模式”，如果“打包模式”有要求，“sprop deint buf req”。这三个参数必须对称使用；即，如果一个或多个参数值不受支持，应答器必须维护所有配置参数或完全删除媒体格式（有效负载类型）。
提示性说明：对称使用的要求仅适用于上述三个参数，而不适用于其他流属性和能力参数。
为了简化这些配置的处理和匹配，如[7]中所述，应答中还应使用报价中使用的相同RTP有效负载类型号。除非配置（“配置文件级别ID”、“打包模式”，如果存在，“sprop deint buf req”）与报价中的配置相同，否则答案不得包含报价中使用的有效负载类型号。
提示性说明：报价人在收到答复时，必须根据媒体类型（即视频/H264）和上述三个参数，将报价中未声明的有效载荷类型与报价中已声明的任何有效载荷类型进行比较，以确定所讨论的配置是新配置还是与已提供的配置等效。
o参数”sprop-parameter-sets”, “sprop-deint-buf-req”, “sprop-interleaving-depth”, “sprop-max-don-diff”, and “sprop-init-buf-time”描述了提供方或应答方为该介质格式配置发送的NAL单元流的属性。这与通常使用的offer/answer参数不同：通常，这些参数声明提供方或应答方能够接收的流的属性。在处理H.264时，提供方假设应答方能够接收使用所提供配置编码的媒体。
提示性说明：上述参数适用于由具有相同配置的声明实体发送的任何流，即它们依赖于它们的源。这些值在发送时可能必须应用于另一种有效负载类型，而不是绑定到有效负载类型，因为它们适用于配置。
o能力参数（”max-mbps”, “max-fs”, “max-cpb”, “max-dpb”, “max-br”, ,”redundant-pic-cap”, “max-rcmd-nalu-size”)可用于声明进一步的能力。它们的解释取决于方向属性。当direction属性为sendOnly时，参数描述了RTP包和发送方能够生成的NAL单元流的限制。当direction属性为sendrecv或recvoonly时，参数描述了接收器接受的限制。
o如上所述，对于交错的H.264流，提供程序必须在提供中包含逐行缓冲区的大小。为了使报价人和应答人相互了解他们的逐行缓冲能力，建议双方都包括“逐行缓冲容量”。当在第二轮报价和应答中选择了“sprop deint buf req”的值时，可以使用此信息。对于交错流，还建议在接收器的能力未知时，考虑提供具有不同缓冲要求的多个有效负载类型。
o如上文所述，使用“sprop参数集”参数。此外，应答者必须在应答中维护报价中收到的所有参数集。根据“参数添加”参数的值，应用不同的规则：如果“参数-添加”为假（0），则答案不得添加任何其他参数集。如果“参数添加”为真（1），则应答器在其答案中可以向“sprop-参数集”参数添加其他参数集。回答者还必须接受使用答案中声明的sprop参数集接收视频流，而不受“参数添加”值的影响。
提示性说明：添加参数集时必须小心，不要使用冲突的参数集标识符覆盖已传输的参数集。
对于通过多播传递的流，还应用以下规则：
o流属性参数(“sprop-parameter-sets”, “sprop-deint-buf-req”, “sprop-interleaving-depth”, “sprop-max-don-diff”,and “sprop-init-buf-time”)不得由应答器更改。因此，一个有效载荷类型既可以被接受，也可以被删除。
o对于声明为sendrecv或recvoonly的所有流，应答器必须支持接收器功能参数”max-mbps”, “max-fs”, “max-cpb”, “max-dpb”, “max-br”, and “max-rcmd-nalu-size”；否则，必须执行以下操作之一：删除媒体格式或拒绝会话。
o对于声明为sendrecv或recvoonly的所有流，应答器应支持接收能力参数冗余pic cap，如下所示：如果提供程序指示冗余pic cap等于0，应答器不应在传输流中包含冗余编码图片。否则（当冗余图片上限等于1时），建议回答者如何使用冗余编码图片超出本备忘录的范围。
以下是在不同的报价或回答和方向属性组合中如何解释不同参数的完整列表。
o在使用“a=sendrecv”或“no direction”属性的报价和应答中，或在使用“a=recvoonly”的报价和应答中，必须使用以下参数解释。
声明接收的实际配置或属性：
profile-level-id
packetization-mode
声明要发送的流的实际属性（适用仅当“a=sendrecv”或不使用direction属性时）：
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
宣布如何进行报价/应答谈判：
- parameter-add
o在媒体流包含方向属性“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
宣布如何进行报价/应答谈判：
- parameter-add
此外，还需要考虑以下因素：
o用于声明接收器功能的参数通常是可降级的；即，它们表示发送者可能行为的上限。因此，发送方可以选择仅使用这些参数的较低/较小或相等值来设置其编码器。”sprop参数集“不能在发送方的能力声明中使用，因为参数集内携带的值的限制与使用的配置文件和级别是隐式的。
o声明配置点的参数不可降级，但“profile level id”参数的级别部分除外。这表示接收者期望使用的值，并且必须在发送方逐字使用。
o当一个发送者的能力被声明，并且在这个声明中使用了不可降级的参数时，这些参数表示一个可接受的配置。为了实现高互操作性级别，通常建议提供多种可选配置，例如，对于打包模式。在一种有效载荷类型中不可能提供多种配置。因此，当进行多个配置提供时，每个提供都需要与其相关联的RTP有效负载类型。
o接收器应该理解所有的mime参数，即使它只支持有效负载格式功能的一个子集。这确保了接收者能够理解何时一个接收介质的提议可以被降级到该提议的接收者所支持的内容。
o回答者可以通过附加的媒体格式配置扩展报价。但是，为了实现它们的使用，在大多数情况下，需要从提供方提供第二个提供，以提供媒体发送方将使用的流属性参数。这也影响到报价人必须能够接收这种媒体格式配置，而不仅仅是发送它。
o如果要约人希望在发送和接收之间具有非对称能力，要约人必须提供不同的RTP会话，即分别声明为“recvoonly”和“sendOnly”的不同媒体行。这可能对系统有进一步的影响。
8.2.3. 声明性会话描述中的用法
当H.264 over RTP以声明性的方式与SDP一起提供时，如RTSP[27]或SAP[28]中所述，需要考虑以下因素。
o所有能够指示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
Not usable:
max-mbps
max-fs
max-cpb
max-dpb
max-br
redundant-pic-cap
max-rcmd-nalu-size
parameter-add
deint-buf-cap
o要求SDP的接收者支持所提供参数的所有参数和值；否则，接收者必须拒绝（RTSP）或不参与（SAP）会话。它取决于会话的创建者使用接收应用程序预期支持的值。
8.3. 示例
预期双方同时发送和接收的SIP提供/应答交换如下所示。仅显示SDP的媒体编解码器特定部分。由于文本约束，某些行被换行。
报价人->应答SDP消息：
上面提供了三种不同的打包格式中相同的编解码器配置。pt 98表示单NALU模式，pt 99表示非交织模式；pt 100表示交织模式。在交错模式的情况下，如果答案表明支持Pt100，报价人将使用的交错参数也包括在内。在这三种情况下，参数“sprop parameter sets”表示当从提供方接收流时，应答方需要的初始参数集。
（配置文件级别ID和打包模式）被接受。请注意，“sprop参数集”的值尽管在上面的示例中相同，但对于每种有效载荷类型可能不同。
answer->offer sdp消息：
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
由于要约/应答协商包括发送流和接收流，因此要约表示要约人愿意接收的确切参数，而应答表示应答人接受接收的相同参数。在这种情况下，报价人声明愿意接受98型有效载荷。应答器通过声明等效的有效负载类型97来接受这一点；即，它对于三个参数“profile level id”、“packetization mode”和“sprop deint buf req”具有相同的值。这对要约人和回答人都具有以下关于声明属性的参数的含义。报价人最初在pt=98的有效载荷定义中声明了“sprop参数集”的某个值。然而，由于应答者接受此为pt=97，当报价人发送pt=97时，必须使用pt=98中“sprop参数集”的值。同样，当应答者向报价者发送pt=98时，它必须使用pt=97中声明的属性参数。
应答器还接受负载类型99和100表示的两种配置的接收。它为应答器提供初始参数集，以提供应答器方向，并缓冲相关参数，以用于发送有效负载类型。它还通过提供一个“deint buf cap”参数，向提供方提供其逐行操作的内存限制。只有当发盘人决定第二次发盘时，这一点才有用，因为它可以考虑到新的价值。“最大RCMD NALU-尺寸”表示应答器可以有效地处理NALU多达
大小为3980字节。但是，不能保证网络支持这种大小。
请注意，上面示例中的参数集并不代表H.264编解码器的合法操作点。base64字符串仅用于说明。
8.4. 参数设置注意事项
H.264参数集是视频编解码器的基本组成部分，对其操作至关重要；请参见第1.2节。由于它们的特点和对解码过程的重要性，丢失或错误传输的参数集很难在接收机本地隐藏。对损坏参数集的引用通常会对解码过程产生致命的结果。例如，由于参数集数据结构的错误传输或丢失，以及由于参数集更新的不及时传输，可能会发生损坏。因此，以下建议是为RTP发送方的实施者提供的指南。
参数集Nalus可以使用三种不同的原则进行传输：
a.在实际RTP会话之前使用会话控制协议（带外）。
b.在正在进行的RTP会话期间使用会话控制协议（带外）。
c.在正在进行的RTP会话期间，在有效负载（带内）中的RTP流中。
有必要在会话控制协议中实现原则A和原则B。SIP和SDP可按照SDP提供/应答模型和本备忘录前几节中的描述使用。本节包含如何在会话控制协议中实现原则A和原则B的指南。它独立于所使用的特定协议。原则C由本规范中定义的RTP有效负载格式支持。
除非为RTP提供可靠的传输，否则不应在RTP负载中传输图片和序列参数集NALU，因为任何一种类型的参数集丢失都可能会阻止对相应RTP流的相当一部分进行解码。因此，建议使用可靠的会话控制协议（即使用上述原理A或B）传输参数集。
在本节的其余部分，假设带外信令提供参数集NALU的可靠传输，而带内信令则不提供。如果使用参数集的带内信令，发送方应考虑到错误特性，并使用机制为正确传递参数集提供高概率。提高正确接收概率的机制包括包重复、FEC和重传。使用不可靠的带外控制协议与带内信令（可能丢失）有相似的缺点，此外，还可能导致同步困难（见下文）。因此，不建议这样做。
在会话的生命周期内，可以使用原则B和C添加或更新参数集。要求参数集在引用它们的NAL单元之前存在于解码器中。更新或添加参数集可能会导致进一步的问题，因此应考虑以下建议。
-当添加或更新参数集时，原则C容易受到上述传输错误的影响，因此建议采用原则B。
-在添加或更新参数集时，应注意确保在使用任何参数集之前传递该参数集。带外信令和带内信令之间通常不存在同步。如果使用带外信令，建议发送方在确认信令协议的发送之前，不要开始发送需要更新参数集的NALU。
-更新参数集时，应考虑以下同步问题。当覆盖接收器上的参数集时，发送方必须确保网络或接收器缓冲区中的任何NALU都不需要有问题的参数集。否则，可能会使用错误的参数集进行解码。为了减少这个问题，建议只覆盖那些没有使用足够长时间的参数集（以确保所有相关的Nalus已被消耗），或者添加一个新的参数集（这可能会对视频编码的效率产生负面影响）。
-添加新参数集时，将使用以前未使用的参数集标识符。这样就避免了上一段中指出的问题。但是，在多方会话中，除非使用同步控制协议，否则多个实体可能会尝试为同一标识符添加不同的参数集，这是必须避免的。
-在同一个RTP会话中同时使用B和C原则添加或修改参数集可能会导致参数集不一致，因为控件和RTP通道之间缺乏同步。因此，除非能够提供足够的同步，否则原则B和C不能在同一会话中同时使用。
在某些情况下（例如，只有该有效载荷格式规范的子集对应
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有效负载类型来实现。
Manes可以遵循第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的设计中，使用RFC 2429打包[10]。已经实施，取得了良好的效果[12]。
VCL编码器对源图片进行编码，以便将一个MB行的所有宏块（MBS）分配给一个切片。所有具有偶数MB行地址的切片合并到一个stap中，所有具有奇数MB行地址的切片合并到另一个stap中。这些STAP以RTP包的形式传输。如上文所述，建立参数集。
请注意，在这里使用staps是非常重要的，因为大量的单个切片（对于CIF图片为18）将导致不可接受的高IP/UDP/RTP头开销（除非使用了源代码工具fmo，这在本场景中没有假设）。此外，一些无线视频传输系统，如H.324M和3GPP中指定的基于IP的视频电话，可能使用相对较小的传输包大小。例如，H.223 AL3 SDU的典型MTU大小约为100字节[17]。根据这种打包方案对单个片进行编码，在有线和无线网络之间的通信中提供了进一步的优势，因为单个片可能小于无线系统的首选最大包大小。因此，网关可以将有线网络中使用的STAP转换为只有一个NAL单元的多个RTP数据包，这在无线网络中是首选的，反之亦然。
12.4. 带数据分区的视频电话
该方案已得到实施，并显示出良好的性能，尤其是在较高的包丢失率下[12]。
只有在某种形式的不平等错误保护可用时，数据分区才是有用的。通常，在单会话RTP环境中，甚至假定错误特征；即，会话中所有数据包的数据包丢失概率在统计上是相同的。但是，有一些方法可以降低RTP会话中单个数据包的数据包丢失概率。例如，根据RFC2733[18]的一个fec包指定了哪些媒体包与fec包相关联。
在所有情况下，产生的开销都是巨大的，但其数量级与用于内部信息的位的数量相同。但是，这种机制不会给系统增加任何延迟。
再次，通过控制协议手段完成参数集的建立。
12.5. 视频电话或带fus的流媒体和转发错误更正
该方案已得到实施，并已证明具有良好的性能，尤其是在较高的包丢失率下[19]。
在重传不适用的情况下，最有效的方法是前向纠错（FEC）。尽管应用层，FEC的端到端使用通常比基于FEC的单个链路保护效率低（尤其是当不同特性的链路位于传输路径中时），但应用层、端到端FEC在某些情况下是不可避免的。RFC2733[18]提供了在丢包环境中使用通用应用层端到端FEC的方法。二进制前向纠错码是通过将XOR操作应用于不同数据包中相同位位置的位而产生的。二进制代码可以由参数（n，k）指定，其中k是连接中使用的信息包数，n是为k信息包生成的数据包总数；即，为k信息包生成n-k奇偶校验包。
当代码与RFC2733框架内的参数（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的情况下结合H.264基线编码视频应用RFC2733，可以考虑以下几个选项：
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，一个更好的代码，例如（n=24，k=12），可以在每个帧的NAL单元序列上使用。与上面的2）相比，延迟可以减少，但有几个缺点是显而易见的。首先，编码视频的编码效率显著降低，因为片结构编码降低了帧内预测，需要额外的片开销。第二，预先编码的内容，或者在网关上操作时，通常不使用k片对视频进行适当编码，这样就可以应用fec。最后，产生等长k片的视频的编码并不简单，可能需要一个以上的编码过程。
通过将fus与fec结合使用，可以避免上述许多缺点。每个NAL单元可以分割成任意数量的基本相等长度的fus；因此，即使编码器不努力生产相同长度的切片，也可以应用具有合理k和n的fec。例如，包含一个完整帧的编码片NAL单元可以拆分为K fus，并且可以应用奇偶校验码（n=k+1，k）。但是，这样做的缺点是，除非所有创建的片段都可以恢复，否则整个切片将丢失。因此，如果将帧分割成多个切片，则会丢失一个更大的部分。
该技术使得即使不存在额外的源编码层冗余（如周期帧内），也能获得良好的传输误差容限。因此，相同的编码视频序列可用于在无差错传输和在易出错网络上传输时实现最大的压缩效率和质量。此外，该技术允许在不增加延迟的情况下将FEC应用于预编码序列。在这种情况下，没有为易出错网络编码的预编码序列仍然可以几乎可靠地传输，而不会增加大量的延迟。此外，相同长度的fus导致了RFC2733的比特率有效使用。
如果错误概率取决于传输数据包的长度（例如，在移动传输的情况下[14]），那么将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的备选方案，并解释了为何根据该RTP有效载荷规范选择DON。
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丢失，则接收到空间上相邻和时间上共同定位的宏块，并可用于有效地隐藏丢失。如果其中一个staps丢失，则丢失的效果不会暂时传播。
13.3. 鲁棒分组调度示例
下面是一个健壮的包调度示例。本例中使用的通信系统由以下组件组成，按照视频从源到接收的顺序进行处理：
o camera and capturing
o pre-encoding buffer
o encoder
o encoded picture buffer
o transmitter
o transmission channel
o receiver
o receiver buffer
o decoder
o decoded picture buffer
o display
示例中使用的视频通信系统操作如下。请注意，在系统的所有组件中，视频流的处理都是逐步进行的，同时进行的。源视频序列被拍摄并捕获到预编码缓冲区。例如，预编码缓冲区可用于将图片从采样顺序排序到编码顺序，或分析多个未压缩帧以进行比特率控制。在某些情况下，预编码缓冲区可能不存在，而是立即对采样图片进行编码。编码器对来自预编码缓冲区的图片进行编码，并将输出（即编码图片）存储到编码图片缓冲区。发送器将编码后的图片从编码后的图片缓冲区封装到传输包中，并通过传输通道发送给接收器。接收器将接收到的数据包存储到接收器缓冲区。接收器缓冲过程通常包括传输延迟抖动的缓冲。接收缓冲器还可用于恢复编码数据的正确解码顺序。解码器从接收缓冲区读取编码数据，并将解码后的图片作为输出输出输出到解码后的图片缓冲区。解码后的图片缓冲区用于恢复图片的输出（或显示）顺序。最后，显示图片。
在下面的示例图中，i表示IDR图片，r表示参考图片，n表示非参考图片，i、r或n之后的数字表示相对于前一个IDR图片的解码顺序的采样时间。图片序列下方的值表示按比例缩放的系统时钟时间戳。在这个例子中，系统时钟是任意初始化的，时间从左到右运行。与上一个处理步骤（如果有）相比，每个I、R和N图片都映射到相同的时间线上，假设编码、传输和解码不需要时间。因此，在所有示例图中，同时发生的事件都位于同一列中。
下面以采样顺序描述了一系列编码图片的子集。
... N58 N59 I00 N01 N02 R03 N04 N05 R06 ... N58 N59 I00 N01 ...
... --|---|---|---|---|---|---|---|---|- ... -|---|---|---|- ...
... 58 59 60 61 62 63 64 65 66 ... 128 129 130 131 ...
图16。按采样顺序排列的图片序列
采样图像在预编码缓冲区中进行缓冲，以按编码顺序排列。在本例中，我们假设非参考图片是按照输出顺序从上一个和下一个参考图片预测出来的，除了紧接着在IDR图片之前的非参考图片，这些图片是按照输出顺序从上一个参考图片预测出来的。因此，预编码缓冲区必须包含至少两张图片，并且缓冲导致两个图片间隔的延迟。预编码缓冲过程的输出和图片的编码（解码）顺序如下：
... N58 N59 I00 R03 N01 N02 R06 N04 N05 ...
... -|---|---|---|---|---|---|---|---|- ...
... 60 61 62 63 64 65 66 67 68 ...
图17。在预编码缓冲区中重新排序图片
编码器或发送器可以按解码顺序将每张图片的don值设置为前一张图片的don值加上一张。
为了简单起见，我们假设：
o序列的帧速率是恒定的，
o每张图片仅由一个切片组成，
o每个切片封装在一个NAL单元包中，
o无传输延迟，以及
o图像以恒定的间隔传输（即1/帧率）。
当图像按解码顺序传输时，接收如下：
... N58 N59 I00 R03 N01 N02 R06 N04 N05 ...
... -|---|---|---|---|---|---|---|---|- ...
... 60 61 62 63 64 65 66 67 68 ...
图18。按解码顺序接收的图片
可选的sprop交织深度mime类型参数设置为0，因为传输（或接收）顺序与解码顺序相同。
解码器必须在其解码后的图片缓冲区中缓冲一个图片间隔，以组织从解码顺序到输出顺序的图片，如下所示：
... N58 N59 I00 N01 N02 R03 N04 N05 R06 ...
... -|---|---|---|---|---|---|---|---|- ...
... 61 62 63 64 65 66 67 68 69 ...
图19。输出顺序
解码后的图片缓冲区中所需的初始缓冲量可在缓冲期SEI消息或H.264视频可用性信息的num_reorder_frames语法元素中发出信号。num_reorder_frames表示序列中任何帧、互补字段对或非成对字段之前的最大帧数、互补字段对或非成对字段数，按解码顺序排列，然后按输出顺序排列。为了简单起见，我们假设num_reorder_frames用于指示解码图片缓冲区中的初始缓冲区。在本例中，num_reorder_frames等于1。
可以观察到，如果在传输过程中IDR图像I00丢失，并且在系统时钟值为62时发出重新传输请求，则有一个图像时间间隔（直到系统时钟达到时间戳63）来接收重新传输的IDR图像I00。
然后我们假设IDR图像比其解码位置提前两个帧间隔发送，即图像按如下方式发送：
... I00 N58 N59 R03 N01 N02 R06 N04 N05 ... ... --|---|---|---|---|---|---|---|---|- ... ... 62 63 64 65 66 67 68 69 70 ...
图20。交错：早期IDR图片发送顺序
可选的sprop交织深度mime类型参数根据其定义设置为1。（本例中sprop-交织深度的值可推导如下：图I00是传输顺序中图N58或N59之前和解码顺序中的唯一图片。除图片I00、N58和N59外，传输顺序与图片解码顺序相同。由于编码图片被封装到一个NAL单元中，sprop交织深度的值等于传输顺序中任何图片前面和解码顺序中图片后面的最大图片数。）
接收器缓冲过程根据sprop交织深度参数的值一次包含两张图片，并根据与每个图片相关联的don值将图片从接收顺序排序到正确的解码顺序。接收器缓冲过程的输出如下：
... N58 N59 I00 R03 N01 N02 R06 N04 N05 ...
... -|---|---|---|---|---|---|---|---|- ...
... 63 64 65 66 67 68 69 70 71 ...
图21。交错：接收缓冲器
同样，需要一个图片间隔的初始缓冲延迟来组织从解码顺序到输出顺序的图片，如下所示：
... N58 N59 I00 N01 N02 R03 N04 N05 ... ... -|---|---|---|---|---|---|---|- ... ... 64 65 66 67 68 69 70 71 ...
图22.交错：重新排序后的接收器缓冲区
请注意，IDR图片在传输过程中可能经历的最大延迟，包括可能的应用、传输或链路层重传，等于三个图片间隔。因此，与按解码顺序传输图像的情况相比，支持重传的系统提高了IDR图像的抗丢失能力。
13.4. 冗余编码片的鲁棒传输调度
冗余编码图片是在相应的主编码图片正确解码的情况下，在解码过程中不使用的图片或图片的一部分的编码表示。对同一接入单元中的任何冗余图片应用H.264解码过程，解码后的主图片的任何区域与相应区域之间不应存在明显差异。冗余编码片是冗余编码图片的一部分。
冗余编码图像可以在容易出错的视频传输中提供不均匀的错误保护。如果图像的主要编码表示被错误地解码，则可以解码相应的冗余编码图像。使用冗余编解码器图片功能的应用程序和编码技术示例包括视频冗余编码[23]和多播流中的“关键图片”保护[24]。
许多容易出错的视频通信系统的一个特点是传输错误经常是突发性的。因此，它们可能以传输顺序影响多个连续的传输包。在低比特率视频通信中，将整个编码图像封装到一个传输包中是比较常见的。因此，主编码图像和相应的冗余编码图像可以按传输顺序连续分组传输。为了提高传输方案对突发传输错误的容忍度，有利于传输由多个数据包分隔的主编码图像和冗余编码图像。Don概念实现了这一点。
13.5. 其他设计可能性说明
H.264编码标准的切片头语法结构包含一个frame_num语法元素，可以指示编码帧的解码顺序。但是，由于以下原因，使用frame_num语法元素不可行或不希望恢复解码顺序：
o接收器需要对每个编码图片至少分析一个切片头（在将编码数据传递给解码器之前）。
来自多个编码视频序列的O编码切片不能交错，因为帧编号语法元素在每个IDR图片中重置为0。
o互补字段对的编码字段共享frame_num语法元素的相同值。因此，不能基于H.264编码语法的frame_num syntax元素或任何其他语法元素恢复互补字段对编码字段的解码顺序。
用于传输MPEG-4基本流[25]的RTP有效负载格式允许在同一个RTP包中交错访问单元和传输多个访问单元。H.264编码标准中规定了一个访问单元，根据[1]的子条款7.4.1.2，它包括与主编码图片相关联的所有NAL单元。因此，不同图片的切片不能交错，并且不能使用多图片切片交错技术（见第12.6节）来提高错误恢复能力。
14. Acknowledgements
作者感谢Roni Even、Dave Lindbergh、Philippe Gentric、Gonzalo Camarillo、Gary Sullivan、Joerg Ott和Colin Perkins对本文进行了仔细的回顾。
15. 参考文献
15.1. 规范性引用文件
[1] ITU-T Recommendation H.264, "Advanced video coding for generic audiovisual services", May 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. 资料性引用
…