如何在符合RFC3984的RTP中对H264数据包进行分段 [英] How to fragment H264 Packets in RTP compliant with RFC3984

查看:276
本文介绍了如何在符合RFC3984的RTP中对H264数据包进行分段的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有FFMPEG流基准h264视频,我必须将其封装在RTP中并发送到SIP电话以对其进行解码.我在Windows和Mirial的h264插件中使用Linphone以获得解码进度.但是,有时我从FFMPEG中获得了巨大的帧大小(3Kb〜9Kb),这显然不适用于MTU.

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.

如果我按原样发送这些帧并信任IP分段功能,则某些电话能够播放得很好,但是其他电话会阻塞并且无法解码流.我认为这是因为流不符合RFC 3984的规定,该RFC 3984规定必须将不适合MTU的数据包分成不同的NALU,并使用RTP的标记功能标记帧的结尾.

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.

我怎么知道在哪里可以切割" I或P框架?我注意到,碎片化的h264数据包(不带有标记标签的数据包)有时会在0xF8中完成,但无法完全得到一种模式,而在RFC 3984中,它描述了如何通过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.

更新:有人知道如何告诉X264库如何生成最大大小的NALU吗?这样,我应该能够避免这个问题.谢谢大家

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

推荐答案

作为RFC 3984bis(即RFC 6184)的作者,它详细介绍了如何将H.264 NAL转换为RFC 3984数据包.共有3种模式:0(单NAL),1(允许对NAL进行分段和组合)和2(让您分段,组合和交织传输顺序以更改突发丢失将如何影响流的方式) ).请参阅SDP打包模式.只需模式0.

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.

模式0(Single-NAL)要求您要么使用UDP分段(不推荐使用),要么告诉编码器不要生成大于MTU-X的NAL.您应该能够告诉编码器.

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.

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

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).

应该在帧的最后一个RTP数据包(不是片段或NAL)上标记,但是您不应指望它.

Mark on the last RTP packet of a frame (not of a fragment or NAL) is expected but you shouldn't count on it.

这篇关于如何在符合RFC3984的RTP中对H264数据包进行分段的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆