前言：

大家好，在上篇文章里面，详细给大家介绍了single nalu和STAP-B和STAP-A和FU-A、FU-B等rtp载荷结构具体构造和打包模式，有了这个基础之后，我们今天来分享如果根据这些对h264如何打包传输，又会哪些策略和规则？

Packetization Rules(组包规则)：

所有发送端必须遵循以下打包规则，无论使用哪种打包模式：

● 对于属于同一编码图像（coded picture）的编码切片 NAL 单元（coded slice NAL units）或编码切片数据分区 NAL 单元（coded slice data partition NAL units）（即它们共享相同的 RTP 时间戳）， 可以（MAY）以任意顺序发送；

但是，对于延迟敏感（delay-critical）系统，应当按照原始解码顺序（decoding order）发送，以最小化播放延迟。

注意，这里的解码顺序指的是 NAL 单元在码流（bitstream）中的排列顺序。

● 参数集（parameter sets）的处理应遵循本文档的第 8.4 节中的规则和建议。

● 媒体感知网络元素（MANEs，Media-Aware Network Elements）不 得（MUST NOT）复制除以下之外的任何 NAL 单元：

○ 序列参数集（sequence parameter set, SPS）

○ 图像参数集（picture parameter set, PPS）

因为无论是本规范，还是 H.264 标准，都没有提供识别重复 NAL 单元的方法。

序列参数集和图像参数集的 NAL 单元可以被复制，以提高其正确接收的概率，但是，这种复制绝不能改变任何活动参数集的内容。此外，复制应该在应用层（application layer）进行，而不应通过发送拥有相同 RTP 序列号的 RTP 包来实现。

使用非交错模式（non-interleaved mode）和交错模式（interleaved mode）的发送端，还必须遵循以下额外的打包规则：

● 在RTP 转换器（RTP translator）中，MANEs 可以：

○ 将多个单一 NAL 单元包（single NAL unit packets）组合成一个聚合包（aggregation packet）；

○ 或将一个聚合包拆分为多个单一 NAL 单元包；

○ 或混合使用这两种方式（部分组合，部分拆分）。

在执行上述操作时，RTP 转换器（translator）应当考虑至少以下参数：

○ 路径最大传输单元（path MTU）大小；

○ 不等保护机制（unequal protection mechanisms），例如：

■ 基于包的前向纠错（packet-based FEC），参见 RFC 5109，特别是用于保护：

  ● 序列参数集（SPS）

  ● 图像参数集（PPS）

  ● 编码切片数据分区 A NAL 单元（coded slice data partition A NAL units）

○ 系统可以容忍的延迟（bearable latency of the system）；

○ 接收端的缓冲能力（buffering capabilities of the receiver）。

补充说明（Informative note）：

一个 RTP 转换器必须处理 RTP 控制协议（RTCP），参考 RFC 3550 的规定。 总结一下：、

【输入阶段】

多个 Single NAL Unit Packets （单NAL单元包）
    ↓
    ↓（送入 RTP Translator）

【处理阶段】

    ┌───────────────────────┐
    │       RTP Translator        │
    └───────────────────────┘
                ↓
        判断处理策略：
            ├──► 聚合（Aggregation）
            │       - 将多个 Single NAL Unit Packets
            │       - 合并为 1 个 Aggregation Packet (如 STAP-A)
            │       - （适合 MTU 充足，减少包数，提高效率）
            │
            └──► 拆分（De-aggregation）
                    - 将 1 个 Aggregation Packet
                    - 拆分成多个 Single NAL Unit Packets
                    - （适合 MTU较小，需要单独处理的场景）

【输出阶段】

发送：
    - 聚合后的 Aggregation Packet
    - 或 拆分后的多个 Single NAL Unit Packets

single NAL Unit Mode:

当 packetization-mode 媒体类型参数的值等于 0，或者 packetization-mode 参数未出现时，使用此模式。所有接收端 必须 支持此模式。该模式主要用于与 ITU-T 推荐标准 H.241（见第 12.1 节）兼容的、低延迟应用场景。在此模式下，只能使用单一 NAL 单元包（Single NAL Unit Packets）。禁止使用 STAP（单时间聚合包）、MTAP（多时间聚合包）和 FU（分片单元）。发送时，单一 NAL 单元包的传输顺序必须遵循 NAL 单元的解码顺序。

non-interleaved mode:

当 packetization-mode（分包模式）这个可选的媒体类型参数的值为 1 时，使用此模式。此模式建议被支持。它主要面向低延迟应用场景。 在该模式下，允许使用以下类型的数据包：

● 单一 NAL 单元包（Single NAL Unit Packets）

● STAP-A（单时间聚合包 A）

● FU-A（分片单元 A）

而禁止使用以下类型的数据包：

● STAP-B（单时间聚合包 B）

● MTAP（多时间聚合包，包括 MTAP16 和 MTAP24）

● FU-B（分片单元 B）

同时，NAL 单元的发送顺序必须遵循 NAL 单元的解码顺序。

Interleaved Mode:

当 packetization-mode（分包模式）这个可选的媒体类型参数的值为 2 时，使用此模式。

部分接收端可以选择（MAY）支持此模式。

在该模式下，允许使用：

● STAP-B（单时间聚合包 B）

● MTAP（多时间聚合包，包括 MTAP16 和 MTAP24）

● FU-A（分片单元 A）

● FU-B（分片单元 B）

而禁止使用：

● STAP-A（单时间聚合包 A）

● 单一 NAL 单元包（Single NAL Unit Packets）

同时，数据包和 NAL 单元的传输顺序必须遵循第 5.5 节中的约束要求。

总结：

拆分包时，RTP 头（Header）怎么变化？

当 RTP Translator 拆分一个 Aggregation 包（比如 STAP-A）成多个 RTP 包（单NAL包）时：

拆分出来的小包，除了 Sequence Number 自增，其他头基本复制原来聚合包的头信息。

聚合/拆分时，如何处理 Sequence Number 连续性？

要求很严格：

● 聚合（Aggregation）时：

○ 多个单NAL单元聚成一个 STAP-A。

○ 只用一个序列号，即：多个 NAL 单元聚合成一个 RTP 包，只产生一条序号，序列号不增加。

● 拆分（De-aggregation）时：

○ 一个 STAP-A 包拆成多个单NAL包。

○ 每个新的单NAL RTP包，Sequence Number 递增 1。

■ 第一个 NAL 单元：用原STAP-A的 Sequence Number

■ 第二个 NAL 单元：Sequence Number +1

■ 第三个 NAL 单元：Sequence Number +2

■ ……以此类推

举个实际拆分例子： 假设原来 RTP Packet： 

● STAP-A，Sequence Number = 1010 包含三个 NAL 单元。 拆分后生成：

 每个包自增1，保证序列连续。

参考： 

https://www.rfc-editor.org/rfc/rfc6184#section-6.1