如何在符合 RFC3984 的 RTP 中对 H264 数据包进行分段
我有 FFMPEG 流基线 h264 视频，我必须将其封装在 RTP 中并发送到 SIP 电话进行解码。我使用 Linphone 和适用于 Windows 的 h264 插件以及 Mirial 来获取解码进度。然而，有时我从 FFMPEG 中得到一个巨大的帧大小（3Kb ~ 9Kb），这显然不适合 MTU。
如果我“按原样”发送这些帧并信任 IP 分段功能，某些手机能够很好地播放它，但其他手机会卡住并且无法解码流。我认为这是因为该流不符合 RFC 3984，该 RFC 3984 规定必须将不适合 MTU 的数据包分成不同的 NALU，并使用 RTP 的标记功能标记帧的结尾。
我如何知道在哪里可以“剪切”I 或 P 帧？我注意到分段的 h264 数据包（没有 Mark 标签的数据包）有时会以 0xF8 结束，但无法完全获得模式，并且在描述如何通过 RTP 发送这些数据包的 RFC 3984 中没有指定如何执行此操作。
更新：有谁知道如何告诉 X264 库如何生成最大大小的 NALU？这样我应该能够避免这个问题。谢谢大家
I have the FFMPEG streaming baseline h264 video, which I have to encapsulate in RTP and send to SIP phones for their decoding. I am using Linphone with the h264 plugin for Windows and Mirial for the decoding progress. However, sometimes I get a huge frame size (3Kb ~ 9Kb) from the FFMPEG, which obviously doesn't fit in the MTU.
If I send these frames "as is" and trusting IP fragmentation feature, some phones are able to play it well enough, but others choke and can't decode the stream. I think this is because the stream is not compliant with the RFC 3984 that specifies that packets that don't fit in the MTU have to be separated into different NALUs and mark the end of a Frame with the Mark feature of RTP.
How do I know where I can "cut" the I or P frame? I noticed that fragmented h264 packets (the ones without the Mark label) sometimes finish in 0xF8 but couldn't quite get a pattern and in the RFC 3984 which describes how to send these packets over RTP doesn't specify how to do it.
UPDATE: Does anyone know how to tell the X264 library how to generate NALUs of a Max Size? that way i should be able to avoid this problem. Thanks everyone
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
作为 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 数据包上进行标记，但您不应指望它。
As an author to RFC 3984bis (to be RFC 6184), it details exactly how to convert H.264 NALs into RFC 3984 packets. There are 3 modes: 0 (single-NAL), 1 (allows for fragmenting and combining NALs), and 2 (lets you fragment, combine, and interleave the transmission order to change how a burst loss will affect a stream, among other things). See SDP packetization-mode. Only mode 0 is required.
Mode 0 (Single-NAL) requires you either use UDP fragmentation (discouraged) or tell the encoder don't generate NALs larger than MTU-X. You should be able to tell the encoder this.
Mode 1 lets you fragment. See the RFC for how you set up an FU-A packet. The fragmentation info is on the front. You can also use STAPs to aggregate small NALs like SPS and PPS packets sent before IDRs (normally). Each packet requires normal RTP headers with incremented sequence numbers (but the same timestamp).
Mark on the last RTP packet of a frame (not of a fragment or NAL) is expected but you shouldn't count on it.
在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
In x264, I believe the int i_slice_max_size in x264_param_t can be used to control the size. Have a look in x264.h I can't remember where I read this, but the post said this structure member can be used to control the NAL size, but I haven't tried it myself.
int i_slice_max_size; /* Max size per slice in bytes; includes estimated NAL overhead. */
EDIT: I found the source
http://mailman.videolan.org/pipermail/x264-devel/2011-February/008263.html