本文是 IETF 的规范 RFC 6184 的一部分的翻译。
RFC 6184这份规范本身比较长，于是就只是翻译了与编写用 RTP/RTCP 协议传输原始 H.264 码流的代码最为相关的几个部分。
下面的内容都翻译自 RFC 6184。
这份备忘录描述了称为 ITU-T Recommendation H.264 和 ISO/IEC 国际标准 14496-10 （均被称为高级视频编码 (AVC)）的视频编码标准的 RTP 载荷规范。在这份备忘录中，名字 H.264 用于编解码器和标准，但是这个备忘录同样适用于编码标准的 ISO / IEC 对应物。
1.1 H.264 Codec
H.264 视频编解码具有广泛的应用范围，其覆盖了所有形式的数字压缩视频，从低比特率的互联网流应用到 HDTV 广播到几乎无损编码的数字影院应用。对比当前的技术状态，H.264 的总体性能是，据报告比特率节省 50% 或更多。比如据报告，数字卫星 TV 质量，可达到 1.5 Bbit/s，对比当前操作点 MPEG-2 视频在大约 3.5 Mbit/s。
Codec 规范本身在概念上区分视频编码层 (VCL) 和网络抽象层 (NAL)。VCL 包含 codec 的信号处理功能；诸如变换，量化和运动补偿预测的机制；和环路滤波器。它遵循当今大多数视频编解码器的一般概念，这是基于宏块的编码器，一个基于宏块的编码器使用图像预测，其使用具有运动补偿的帧间预测和残差信号的变换编码。VCL 编码器输出 slices：包含整数个宏块的宏块数据的位串和 slice 头部信息（包含 slice 中第一个宏块的空间地址，初始的量化参数，及类似的信息）。Slice 中的宏块以扫描的顺序排列，除非使用 slice 组语法指定了不同的宏块分配。图像预测只被用于 slice 内。更多信息在 Introduction to the special issue on the H.264/AVC video coding standard 中提供。
NAL 编码器把 VCL 编码器的 slice 输出封装进网络抽象层单元（NALUs），其适合于通过分组网络传输，或在面向分组的多种环境下使用。H.264 的附录 B 定义了通过面向流的网络传输这样的 NALU 的封装过程。本备忘录范围内，与附录 B 无关。
在内部，NAL 使用 NAL 单元。NAL 单元由一个字节的头部和载荷字节串组成。头部说明了 NAL 单元的类型，NAL 单元载荷中（潜在地）出现的位错误或语法违规，及对于解码过程而言 NAL 单元的相对重要性的信息。本 RTP 载荷规范被设计为对 NAL 单元载荷中的位串无感知。
H.264 的一个主要属性是完全解耦 slice 和图像的传输时间，解码时间，和采样或呈现时间。H.264 中描述的解码过程对时间无意识，而且 H.264 语法不携带诸如跳过的帧数（像在更早的视频压缩标准中常见的时间参照这样的形式）这样的信息。此外，还有 NAL 单位影响许多图片，因此是本质上是没有时间的。基于采样和呈现时间没有定义，或传输时间未知这些原因，NAL 单元的 RTP 时间戳的处理需要一些特殊的考虑。
1.2 参数集概念
H.264 的一个非常基本的设计概念是生成自包含包，使得不再需要诸如 RFC 4629 的头部复制或 MPEG-4 视觉的头部扩展码 (HEC) 这样的机制。这是通过从媒体流中去除与多个 slice 相关的信息来实现的。这个更高层的 meta 信息应该能够从包含 slice 包的 RTP 包流中被可靠地异步地预先发送出去。（带内发送此信息的规定也适用于不具有为了实现此目的的适当的带外传输通道的应用）。更高层参数的结合称为参数集。H.264 规范包含两种类型的参数机：序列参数集和图像参数集。有效的序列参数集在整个编码的视频序列中保持不变，而有效的图像参数集在一个编码的图像内保持不变。序列和图像参数集结构包含了诸如图像大小，可选的所用的编码模式，和宏块到 slice 组的映射这样的信息。
为了能够修改图像参数（比如图像大小）而无需同步地传输参数集合更新给 slice 包流，编码器和解码器可以维护一个多于一个序列和图像参数集合的列表。每个 slice 头部包含一个编码字，来指示要使用的序列和图像参数集。
这种机制允许将参数集合的传输从包流的传输中解耦出来，并通过外部的方法（比如，作为能力交换的一部分）或通过一个控制协议（可靠的或不可靠的）传输它们。甚至可能不传输它们，但通过应用设计规范来固定。
1.3 网络抽象层单元类型
关于 NAL 设计的教程信息可以在 “H.264/AVC over IP”，“H.26L over IP: The IP.NETwork Adaptation Layer” 和 “H.26L/JVT Coding Network Abstraction Layer and IP-Based Transport” 等几份文档中找到。
所有的 NAL 单元由单个 NAL 单元类型字节组成，其共同作为该 RTP 载荷格式的载荷头部。NAL 单元载荷的描述如下。
NAL 单元类型字节的语法和语义在 ITU-T Recommendation H.264 中描述，但 NAL 单元类型字节的必要属性总结如下。NAL 单元类型字节具有如下的格式：
F：1 位NAL 单元类型字节的组件的语义，如 H.264规范所定，清晰地描述如下：
本备忘录引入了新的 NAL 单元类型，它们在 5.2 节 中说明。本备忘录中定义的 NAL 单元类型被标记为 ITU-T Recommendation H.264 中的 unspecified。此外，本规范扩展了 F 和 NRI 的语义，如 5.3 节 所述。
5.1 RTP Header 用法
RFC 3550 中描述了 RTP Header 的格式，且为了方便在图 1 中再次展示了它。这里的载荷格式使用头部字段的方式与那份规范相同。
当一个 NALU 被封装进每个 RTP 包时，建议采用的 RTP 载荷格式在 5.6 小节 中描述。聚合包和分片单元的 RTP 载荷（及一些 RTP 头部位的设置）分别在 5.7.2 和 5.8 小节描述。
根据本 RTP 载荷格式所需设置的 RTP 头部信息按如下方式设置：图 1. RFC 3550 的 RTP 头部
C++音视频开发学习资料：点击领取→音视频开发（资料文档+视频教程+面试题）（FFmpeg+WebRTC+RTMP+RTSP+HLS+RTP）
5.2 载荷结构
有效载荷格式定义三种不同的基本载荷结构。接收者可以通过 RTP 包载荷的第一个字节识别载荷结构，其共同用作 RTP 有效载荷报头，在某些情况下，作为载荷的第一个字节。这个字节总是被构造为 NAL 单元头。NAL 单元类型字段表示是哪种结构。可能的结构如下。
单个 NAL 单元包：载荷中包含一个单独的 NAL 单元。NAL 头部类型等于原始的 NAL 单元类型，比如，范围在 1 到 23 ，包括 23。在 5.6 小节 中描述。
聚合包：用于将多个 NAL 单元聚合为一个单独的 RTP 载荷的包类型。这个包有四个版本，单时间聚合包类型 A (STAP-A)，单时间聚合包类型 B (STAP-B)，16 位偏移多时间聚合包 (MTAP) (MTAP16)，和 24 位偏移多时间聚合包 (MTAP) (MTAP24)。为 STAP-A，STAP-B，MTAP16 和 MTAP24 分配的数字值分别为 24，25，26，和 27。在 5.7 小节 中描述。
分片单元：用于将一个单独的 NAL 单元分割为多个 RTP 包。有两个版本，FU-A 和 FU-B，分别由 NAL 单元类型数字 28 和 29 标识。在 5.8 小节 中描述。
资料性说明：本规范不限制在单个 NAL 单元包中封装的 NAL 单元和分片单元的大小。在任何聚合包中封装的 NAL 单元的最大大小为 65535 字节。
表 1 总结了当这些 NAL 单元直接被用作一个包载荷时，NAL 单元类型和对应的 RTP 包类型，以及本备忘录中描述这些类型的章节。
表 1. NAL 单元类型和对应的包类型总结
5.3 NAL 单元头部使用
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 聚合包中的单时间聚合包中，多个 NAL 单元的存储结构是什么样的？NAL 单元间是否需要 NAL 单元分割序列 0x00000001？ yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
NAL 单元头部的结构和语义在 1.3 节 中介绍。为了方便，NAL 单元头部的格式重新显示如下：
F：1 位本节根据本规范描述了 F 和 NRI 的语义。
资料性说明：如前面提到的，H.264 强制非参考图像的 NRI 值为 00。
H.264 编码器应该设置冗余的编码参考图像的编码 slice 和 编码 slice 数据分区 NAL 单元的 NRI 的值为 01 （二进制格式）。
NAL 单元类型 24 到 29（包含）的 NRI 值的定义，在本备忘录的 5.7 和 5.8 节中给出。
nal_unit_type 在范围 13 到 23 （包含）内的 NAL 单元的 NRI 值没有建议值，因为这些值为 ITU-T 和 ISO/IEC 所保留。nal_unit_type 等于 0 或在范围 30 到 31 （包含）的 NAL 单元的 NRI 值也没有建议值，因为这些值的语义不在本备忘录中描述。
5.4 打包模式
本备忘录描述打包模式的三种情况：
单 NAL 单元模式针对符合 ITU-T Recommendation H.241 的会话系统（参考 12.1 节）。非交错模式针对不符合 ITU-T Recommendation H.241 的会话系统。在非交错模式中，NAL 单元以 NAL 单元解码的顺序传输。交错模式针对不需要很低的端到端延迟的系统。交错模式允许不以 NAL 单元解码的顺序传输。
使用的打包模式可以通过可选的 packetization-mode 媒体类型参数的值来通知。所用的打包模式管理在 RTP 载荷中允许哪些 NAL 单元类型。表 3 总结了每种打包模式允许的包载荷类型。第 6 节 更详细地解释了打包模式。
表 3. 每种打包模式允许的 NAL 单元类型总结 (yes = allowed, no = disallowed, ig = ignore)
一些 NAL 单元或载荷类型值（如 表 3 中的 reserved 所示）被保留，以用于未来扩展。发送者不应该发送那些类型的 NAL 单元（直接作为包载荷，作为聚合包中的聚合单元，或作为 FU 包中的分片），且接收者必须忽略它们。比如，载荷类型 1-23，具有关联的包类型 “NAL unit”，它可以出现在 “Single NAL Unit Mode” 和 “Non-Interleaved Mode” 中，但不能出现在 “Interleaved Mode” 中。然而，NAL 单元类型 1-23 的 NAL 单元可被用于 “Interleaved Mode”，作为 STAP-B，MTAP16，和 MTAP24 包中的聚合单元，也可以作为 FU-A 和 FU-B 包中的分片单元。类似地，NAL 单元类型 1-23 的 NAL 单元也可被用于 “Non-Interleaved Mode” 作为 STAP-A 包中的聚合单元或 FU-A 包中的分片单元，除了直接被用作包载荷。
在交错打包模式下，NAL 单元的传输顺序允许和其解码顺序不同。解码顺序号（DON）是载荷结构中表示 NAL 单元解码顺序的一个字段或一个派生变量。传输顺序与解码顺序不同的用例的基本原理和实例，以及 DON 的使用在 13 小节 给出。
传输和解码顺序的耦合由可选的 sprop-interleaving-depth 媒体类型参数控制如下。当可选的 sprop-interleaving-depth 媒体类型参数的值为 0 时（明确地或默认的），NAL 单元的传输顺序必须与 NAL 单元的解码顺序一致。当可选的 sprop-interleaving-depth 媒体类型参数的值大于 0 时：
单 NAL 单元包的 RTP 载荷结构，一个 STAP-A 或一个 FU-A 不包含 DON。STAP-B 和 FU-B 结构包含 DON，MTAPs 的结构允许 DON 的继承，如 5.7.2 小节 所述。
资料性说明：当 FU-A 出现在交错模式中时，它总是跟在 FU-B 后面，后者设置它自己的 DON。
资料性说明：如果发送端想要每个包封装一个 NAL 单元并以非解码顺序传输包，则可以使用 STAP-B 包类型。
在单 NAL 单元打包模式中，NAL 单元的传输顺序，由 RTP 序列号决定，必须与它们的 NAL 单元解码顺序相同。在非交错打包模式中，单 NAL 单元包中的 NAL 单元的传输顺序， STAP-As，和 FU-As 必须与它们的 NAL 单元解码顺序相同。STAP 内的 NAL 单元必须以它们解码的顺序出现。这样，首先通过 STAP 内的顺序明确地提供解码顺序，然后通过 STAPs，FUs 和单 NAL 单元包之间的顺序的 RTP 序列号提供。
STAP-B，MTAP，和一系列以 FU-B 开头的分片单元中携带的 NAL 单元的 DON 值的信令分别在 5.7.1，5.7.2 和 5.8 节中描述。传输顺序中第一个 NAL 单元的 DON 值可以被设置为任何值。DON 值的范围为 0 到 65535（包含）。在达到最大值之后，DON 的值环绕到 0。
任何 STAP-B，MTAP，和一系列以 FU-B 开头的分片单元中包含的两个 NAL 单元的解码顺序按如下方式决定。令 DON(i) 为传输序列中索引为 i 的 NAL 单元的解码顺序号。函数 don_diff(m,n) 描述如下：
DON 相关字段（DON，DONB，和 DOND；参考 5.7 节）的值必须使得由上述 DON 值决定的解码顺序符合 NAL 单元解码顺序。正的 don_diff(m,n) 值表示发送顺序索引为 n 的 NAL 单元，其解码顺序在传输顺序索引为 m 的 NAL单元之后。当 don_diff(m,n) 等于 0 时，两个 NAL 单元的 NAL 单元解码顺序可以为任意顺序。负的 don_diff(m,n) 值表示发送顺序索引为 n 的 NAL 单元，其解码顺序在传输顺序索引为 m 的 NAL单元之前。
如果 NAL 单元解码顺序中的两个 NAL 单元顺序切换，且新的顺序与 NAL 单元解码顺序不一致，则 NAL 单元必须不具有相同的 DON。如果 NAL 单元流中两个连续 NAL 单元的顺序被交换，且新的顺序依然符合 NAL 单元解码顺序，则 NAL 单元可以具有相同的 DON 值。比如，所用的视频编码配置允许任意的编码 slice 顺序，编码图片的所有编码 slice NAL 单元允许具有相同的 DON。因此，具有相同 DON 值的 NAL 单元可以以任意顺序解码，而具有不同 DON 值的两个 NAL 单元应该以上面描述的顺序传给解码器。当 NAL 单元解码顺序中的两个连续 NAL 单元具有不同的 DON 值时，解码顺序中第二个 NAL 单元的 DON 值应该是第一个的 DON 值加一。
解包过程恢复 NAL 单元解码顺序的示例在 第 7 节 中描述。
资料性说明：接收者不应该期待 NAL 单元解码顺序中两个连续 NAL 单元的 DON 值的绝对差值等于 1，即使是在可靠传输中。在将 DON 值与 NAL 单元关联时，不要求递增 1，可能不知道所有NAL单元是否被传送到接收器。比如，当分组转发到的网络中存在缺少比特率时，网关可能不转发非参考图像或 SEI NAL 单元的编码 slice NAL 单元 。在另一个例子中，实况广播由预编码的内容（例如商业广告）不时地中断。预先编码剪辑的第一帧图像被预先发送，以确保其在接收机中容易获得。当传输第一帧图像时，在解码顺序中后面的预编码裁剪的第一帧图像之前，发起端不能精确地知道将编码多少 NAL 单元。这样，预编码裁剪的第一帧图像的 NAL 单元的DON 的值必须在它们被传输时评估，则 DON 值的 gaps 可能出现。
5.6 单 NAL 单元包
这里定义的单 NAL 单元包必须只包含一个 ITU-T Recommendation H.264 中定义的类型的 NAL 单元。这意味着聚合包或分片单元都不能用在单 NAL 单元包中。通过以 RTP 序列号顺序对单 NAL 单元包进行解包组合的 NAL 单元流必须符合 NAL 单元解码顺序。单 NAL 单元包的结构如图 2 所示。
资料性说明：NAL 单元的第一个字节共同作为 RTP 载荷头。
图 2. 单 NAL 单元包的 RTP 载荷格式
5.7 聚合包
聚合包是这份载荷规范的 NAL 单元聚合方案。引入该方案以反映两个关键目标网络的显着不同的MTU大小：有线 IP 网络（具有常常由以太网 MTU 大小限制的 MTU 大小，大约 1500 字节）和基于 IP 或非基于 IP（比如，ITU-T H.324/M）的无线通信系统，其优选传输单元为 254 字节或更少。为了防止两个世界间的媒体传输编码，并避免不必要的分组化开销，引入了 NAL 单元聚合方案。
本规范定义了两种聚合包类型：
聚合包中携带的每个 NAL 单元被封装在一个聚合单元中。请参考下文来了解四种不同的聚合单元及其特性。
聚合包的 RTP 载荷格式结构如图 3 所示。
图 3. 聚合包的 RTP 载荷格式
MTAPs 和 STAPs 共享如下的打包规则：
表 4. STAPs 和 MTAPs 的字段类型
RTP 头部中的 marker 位的值被设置为，就像聚合包的最后一个 NAL 单元在其自己的 RTP 包中传输时它的 marker 位一样的值。
聚合包的载荷由一个或多个聚合单元组成。参考 5.7.1 和 5.7.2 节来了解四种不同类型的聚合单元。聚合包可以根据需要携带尽可能多的聚合单元；然而，聚合包中总的数据量明显地必须刚好放入一个 IP 包中，选择的大小应该让最终的 IP 包大小小于 MTU 大小。聚合包必须不包含分片单元，如 5.8 节 所述。聚合包必须不嵌套；即，聚合包必须不包含另一个聚合包。
5.7.1 单时间聚合包（STAP）
所有要聚合的 NAL 单元共享相同的 NALU 时间时应该使用单时间聚合包（STAP）。STAP-A 载荷不包含 DON，且由至少一个单时间聚合单元组成，如图 4 所示。STAP-B 载荷由一个 16 位无符号解码顺序号（DON）（以网络字节序）后跟至少一个单时间聚合单元组成，如图 5. 所示。
图 4. STAP-A 载荷格式
图 5. STAP-B 的 载荷格式
DON 字段描述了 STAP-B 中传输顺序的第一个 NAL 单元的 DON 值。对于 STAP-B 中的每个连续的 NAL 单元，其 DON 值等于 (STAP-B 中前一个 NAL 单元的 DON 值+ 1) % 65536，其中 ‘%’ 表示取模操作。
单时间聚合单元由一个表示下面的 NAL 单元的字节大小（不包含这两个8位位组，但包含 NAL 单元的 NAL 单元类型八位位组）的 16 位无符号大小信息（以网络字节序），后跟 NAL 单元自身，包含它的 NAL 单元类型字节组成。单时间聚合单元是 RTP 载荷内字节对齐的，但它可能不是对齐到 32 位字边界的。图 6 展示了单时间聚合单元的结构。
图 6. 单时间聚合单元的结构
图 7 展示了一个 RTP 包的示例，其包含了一个 STAP-A。STAP 包含两个单时间聚合单元，由图中的 1 和 2 表示。
图 7. 包含一个包含两个单时间聚合单元的 STAP-A 的 RTP 包示例
图 8 展示了一个 RTP 包示例，其包含一个 STAP-B。STAP 包含两个单时间聚合单元，由图中的 1 和 2 标识。
图 8. 包含一个包含两个单时间聚合单元的 STAP-B 的 RTP 包示例
5.7.2 多时间聚合包（MTAPs）
MTAPs 的 NAL 单元载荷由一个 16 位的无符号解码顺序号基数（DONB）（以网络字节序）和一个或多个多时间聚合单元组成，如图 9 所示。DONB 必须是 MTAP 中的 NAL 单元的 NAL 单元解码顺序号中的第一个的 DON 值。
资料性说明：NAL 单元解码顺序号的第一个 NAL 单元不一定是按封装进 MTAP 的顺序来算的第一个 NAL 单元。
图 9. MTAPs 的 NAL 单元载荷格式
本规范定义了两个不同的多时间聚合单元。它们都由后面的 NAL 单元的 16 位无符号大小信息（以网络字节序），一个 8 位无符号解码顺序号差值（DOND），和这个 NAL 单元的 n 位（以网络字节序）时间戳偏移（TS offset）组成，其中 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 时间戳)。
图 10. MTAP16 的多时间聚合单元
图 11. MTAP24 的多时间聚合单元
对于一个 MTAP 中 “最早的” 多时间聚合单元，其时间戳偏移必须是 0。因此，MTAP 自身的 RTP 时间戳与最早的 NALU 时间一样。
资料性说明：如果包含在聚合单元中的 NAL 单元被封装在单个 NAL 单元包中，则“最早”的多时间聚合单元将是 MTAP 的所有聚合单元中具有最小扩展 RTP 时间戳的那个。扩展时间戳是具有超过32位的时间戳，并且能够对时间戳字段的环绕进行计数，因此可以在时间戳环绕时确定最小值。这个 “最早的” 聚合单元可能不是以封装进 MTAP 中的顺序来计算的第一个聚合单元。“最早的” NAL 单元不需要与 NAL 单元解码顺序的第一个 NAL 单元相同。
C++音视频开发学习资料：点击领取→音视频开发（资料文档+视频教程+面试题）（FFmpeg+WebRTC+RTMP+RTSP+HLS+RTP）
图 12 展示了一个 RTP 包的示例，其包含了一个 MTAP16 类型的多时间聚合包，其中包含了两个多时间聚合单元，由图中的 1 和 2 标识。
图 12. 包含一个包含了两个多时间聚合单元的类型 MTAP16 的多时间聚合包的 RTP 包
图 13 展示了一个 RTP 包的示例，其包含了一个 MTAP24 类型的多时间聚合包，其中包含了两个多时间聚合单元，由图中的 1 和 2 标识。
图 13. 包含一个包含了两个多时间聚合单元的类型 MTAP24 的多时间聚合包的 RTP 包
5.8 分片单元（FUs）
这个载荷类型允许把一个 NAL 单元分片为多个 RTP 包。在应用层做这件事，而不是依赖于更底层的分片（比如，通过 IP）具有如下这些优势：
分片只是为单 NAL 单元定义的，而不是为任何聚合包定义的。NAL 单元的片由一个该 NAL 单元的连续八位位组的整数组成。NAL单元的每个八位字节必须是该NAL单元的正好一个片段的一部分。相同 NAL 单元的片段必须连续顺序发送，具有升序的 RTP 序列号（被发送的相同 RTP 包流中第一个和最后一个片段间没有其它 RTP 包）。类似地，NAL 单元必须以 RTP 序列号顺序重新装好。
当 NAL 单元被分片并在分片单元（FUs）中传送时，它被称为一个分片的 NAL 单元。STAPs 和 MTAPs 必须不被分片。FUs 必须不被嵌套；即，FU 必须不包含另一个 FU。
携带一个 FU 的 RTP 包的 RTP 时间戳被设置为被分片的 NAL 单元的 NAL 时间。
图 14 展示了 FU-As 的 RTP 载荷格式。FU-A 由一个八位的分片单元指示器，一个八位的分片单元头，和一个分片单元载荷构成。
图 14. FU-A RTP 载荷格式
图 15 展示了 FU-Bs 的 RTP 载荷格式。FU-B 由一个八位的分片单元指示器，一个八位的分片单元头，一个解码顺序号（DON）（以网络字节序），和一个分片单元载荷构成。换句话说，FU-B 的结构与 FU-A 的结构相同，除了额外的 DON 字段。
图 15. FU-B RTP 载荷格式
NAL 单元类型 FU-B 必须被用在交错打包模式中，被分片的 NAL 单元的第一个分片单元中。NAL 单元类型 FU-B 必须不被用在其它情况下。换句话说，在交错打包模式中，被分片的每个 NALU 单元具有一个 FU-B 作为第一个片段，后面是一个或多个 FU-A 片段。
FU 指示器字节具有如下的格式：
FU 头部具有如下的格式：FU 指示器的类型字段的值 28 和 29 分别标识 FU-A 和 FU-B。F 位的使用如 5.3 节 所述。NRI 字段的值必须根据被分片的 NAL 单元中 NRI 字段的值设置。
FU-Bs 中的 DON 的值的选择如 5.5 节 所描述的那样。
资料性说明：FU-Bs 中的 DON 字段允许网关把 NAL 单元分片为 FU-Bs，而不将传入的 NAL 单元组织到 NAL 单元解码顺序。
被分片的 NAL 单元必须不在一个 FU 中传输：即，Start 位和 End 位必须不在相同的 FU 头中同时设置。
FU 载荷由被分片的 NAL 单元的载荷的片段组成，使得如果连续的 FU 的分片单元载荷被顺序连接，则可以重构分段的 NAL 单元的有载荷。被分片 NAL 单元的 NAL 单元类型字节没有包含分片单元载荷中，而是被分片 NAL 单元的 NAL 单元类型字节的的信息，由分片单元的 FU 指示器字节的 F 和 NRI 字段，以及 FU 头部的类型字段携带。FU 载荷可以具有任何数量的字节且可以是空的。
资料性说明：允许空的 FUs 减少几乎无损环境中某一类发送者的延迟。这些发送者的特征是，它们在 NALU 完全生成之前打包 NALU 片段，因此，在 NALU 大小已知之前。如果不允许零长度 NALU 片段，则发送方必须在可以发送当前片段之前，生成后面的片段的至少一位数据。由于H.264的特点，有时几个宏块占用零个位，这是不希望的，并且可以增加延迟。然而，应该仔细权衡零长度 NALU 片段的（潜在）使用，因为用于传输的附加数据包，NALU 的至少一部分丢失的风险增加了。
如果分片单元丢失了，则接收者应该丢弃以传输顺序对应于相同被分片 NAL 单元的所有后面的分片单元。
一端的接收者或 MANE 中可以聚合 NAL 单元的前面 n - 1 个片段为一个（不完整的）NAL 单元，即使那个 NAL 单元的片段 n 没有收到。在这种情况下，NAL 单元的 forbidden_zero_bit 必须被设置为 1 以表示语法违规。
京公网安备 11010802035086号