我已经看到了以下问题的非常好的答案：
> How to process raw UDP packets so that they can be decoded by a decoder filter in a directshow source filter
> Problem to Decode H264 video over RTP with ffmpeg (libavcodec)
两者都有一些令人困惑的小差异(见下文).
但首先让我们看看容易的部分.正如我从相机中看到的那样,发送了SPS和PPS数据包.所有剩余的数据包都是索引或未索引的碎片帧.
对于没有帧的所有数据包(在我的情况下只有NALUnitType 7和8)我剥离RTP报头(12字节)并在前面添加起始字节3 x 0字节和1 x 1(00 00 00 01).
对于所有分段的帧包,我根据答案1的描述重建它们.所以详细地说这意味着：
剥离RTP标头(仅用于数据验证).
然后从有效载荷中解码片段信息：
第一个字节：[3 NAL UNIT BITS | 5碎片类型位]第二个字节：[START BIT |结束位|保留位| 5个NAL单位]
如果设置了起始位,则会有一个新的有效负载头,如下所示：[3 NAL UNIT BITS(从第一个字节开始)| 5个NAL单位(从第二个字节开始)]
这为非idr切片提供了NALUnitType 1,为idr切片提供了5.这是根据规范.
我使用这个新的有效负载头(1个字节)并将没有2个字节头的有效负载附加到新的包中.以相同的方式添加所有连续片段(12字节RTP标题的条带,2字节单元类型信息的条带),直到看到结束位信息.当看到结束时,我将开始字节(00 00 00 01)放在此数据包的前面并将其写入流.
问题是由于未知原因无法解码.我读过的答案的答案2的不同之处在于,有效载荷头的第二个字节也可能被放入翻译的数据包中.但我尝试了两个,但仍然没有运气.
可能在新构建的流中还有其他缺失的东西？或者我在碎片整理中犯了错误？
解决方法
我试图自己理解这一切.在我看来,它看起来是：How to process raw UDP packets so that they can be decoded by a decoder filter in a directshow source filter你的“起始字节”是一个字节.我认为这是3个字节,而不是4个……如：00 00 01
也许这就是它遇到麻烦的地方.
