我有 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？这样我应该能够避免这个问题。谢谢大家
作为 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 数据包是预期的，但您不应该指望它。
在 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