如何在符合 RFC3984 的 RTP 中对 H264 数据包进行分段答案

【问题标题】：How to fragment H264 Packets in RTP compliant with RFC3984如何在符合 RFC3984 的 RTP 中对 H264 数据包进行分段
【发布时间】：2011-04-01 10:49:46
【问题描述】：

我有 FFMPEG 流基线 h264 视频，我必须将其封装在 RTP 中并发送到 SIP 电话进行解码。我正在将 Linphone 与适用于 Windows 的 h264 插件和 Miria 一起用于解码进度。但是，有时我会从 FFMPEG 获得巨大的帧大小（3Kb ~ 9Kb），这显然不适合 MTU。

如果我“按原样”发送这些帧并信任 IP 分段功能，则某些手机可以很好地播放它，但其他手机会窒息并且无法解码流。我认为这是因为流不符合 RFC 3984，该 RFC 3984 规定不适合 MTU 的数据包必须分离到不同的 NALU 中，并使用 RTP 的标记功能标记帧的结尾。

我怎么知道我可以在哪里“剪切”I 或 P 框架？我注意到分段的 h264 数据包（没有标记标签的数据包）有时以 0xF8 结束，但无法完全得到模式，并且在描述如何通过 RTP 发送这些数据包的 RFC 3984 中没有指定如何执行此操作。

更新：有谁知道如何告诉 X264 库如何生成最大尺寸的 NALU？这样我应该能够避免这个问题。谢谢大家

【问题讨论】：

标签： video sip h.264 rtp rfc

【解决方案1】：

作为 RFC 3984bis（将成为 RFC 6184）的作者，它详细说明了如何将 H.264 NAL 转换为 RFC 3984 数据包。有 3 种模式：0（单 NAL）、1（允许对 NAL 进行分段和组合）和 2（允许您分段、组合和交错传输顺序以更改突发丢失对流的影响等））。请参阅 SDP 打包模式。只需要模式 0。

模式 0（单 NAL）要求您使用 UDP 分段（不鼓励）或告诉编码器不要生成大于 MTU-X 的 NAL。您应该能够告诉编码器这一点。

模式 1 可让您分段。有关如何设置 FU-A 数据包的信息，请参阅 RFC。碎片信息在前面。您还可以使用 STAP 聚合小型 NAL，例如在 IDR 之前发送的 SPS 和 PPS 数据包（通常）。每个数据包都需要带有递增序列号（但时间戳相同）的普通 RTP 标头。

在一个帧（不是片段或 NAL）的最后一个 RTP 数据包上进行标记是预期的，但您不应该指望它。

【讨论】：

@jesusp 感谢您的回复！但是，我使用 X264 作为编码器层，我不知道如何告诉编码器生成最高 1500 字节的 NALU。谷歌搜索让我来到这里：link。但是，它似乎尚未合并到库中。有人知道使用 X264 的方法吗？否则我将不得不实现打包模式=1。谢谢大家
@jesup 你能解释一下为什么 UDP 分片不好？据我了解，UDP 分片（或更好的 IP 分片）应该会减少网络流量，因为您不必为每个数据包编码 RTP（分别为 UDP）标头（因此每个数据包可以获得 12 到 20 个字节） .
在这方面有很多废话......有些路由器根本不支持分片。各种操作系统和其他中间盒可能需要重新组装分段的数据包，并且所有这些都对重新组装的大小有限制 - 通常远低于 65535 字节的最大 UDP 大小（通常约为 4K）。没有标准的最大尺寸。碎片使您更容易受到数据包丢失的影响（尽管如果数据在单个数据包中无法使用，则可能无济于事）。也许应该重新审视这一点，但缺乏有用的标准尺寸是一个大问题。

【解决方案2】：

在x264中，我相信x264_param_t中的int i_slice_max_size可以用来控制大小。看看x264.h我不记得在哪里读到了，但是帖子说这个结构成员可以用来控制NAL大小，但我自己没有尝试过。

int i_slice_max_size; /* 每个切片的最大大小（以字节为单位）；包括估计的 NAL 开销。 */

编辑：我找到了来源

http://mailman.videolan.org/pipermail/x264-devel/2011-February/008263.html

【讨论】：

谢谢！我今天下午开始讨论它，但我已经检查过了，应用这些更改不会有问题。非常感谢您的帮助！