Tho*_*mas 5 java udp rtp h.264 sdp
在将SDP会话的UDP流转换为可解码的H.264流时,我遗漏了一些基本的东西.我正在使用支持H.264的摄像头进行测试,可以直接与播放器一起播放流.当我尝试播放翻译的流时,播放器将无法识别(缺少标题错误).但是,我必须解码UDP流才能将其集成到Java应用程序中,其中有一些解码器.
我已经看到了以下问题的非常好的答案:
两者都有一些令人困惑的小差异(见下文).
但首先让我们看看容易的部分.正如我从相机中看到的那样,发送了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 UNIT BITS(来自第二个字节)]
这为非idr切片提供了NALUnitType 1,为idr切片提供了5.这是根据规范.
我使用这个新的有效负载头(1个字节)并将没有2个字节头的有效负载附加到新的包中.以相同的方式添加所有连续片段(12字节RTP标题的条带,2字节单元类型信息的条带),直到看到结束位信息.当看到结束时,我将开始字节(00 00 00 01)放在此数据包的前面并将其写入流.
问题是由于未知原因无法解码.我读过的答案的答案2的不同之处在于,有效载荷头的第二个字节也可能被放入翻译的数据包中.但我尝试了两个,但仍然没有运气.
可能在新构建的流中还有其他缺失的东西？或者我在碎片整理中犯了错误？
托马斯，
我自己正在尝试理解这一切。在我看来，通过阅读这篇文章：如何处理原始 UDP 数据包，以便它们可以由 directshow 源过滤器中的解码器过滤器进行解码，您的“起始字节”关闭了一个字节。我认为它是 3 个字节，而不是 4 个...如：00 00 01
也许这就是它遇到麻烦的地方。
| 归档时间： |
|
| 查看次数： |
3594 次 |
| 最近记录： |