This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DM365用UDP接收的方式做TS流或H264裸流解码可行吗?



         各位老师和朋友好,我想用DM365做TS流的网络硬解码。以前用DM365的Encode Demo程序改造成了一个TS流的发送端,用UDP传输,是参考移植了VLC的相关代码。后来在电脑上用VLC UDP接收能正常解码显示。现在想做一个与之配套的硬解码器,替代电脑上的VLC软解码软件。刚看了Decode的Demo程序,感觉很复杂很乱,比Encode的代码要繁杂很多。一时间无从下手。本来解码就是要比编码难做。

        我现在的想法是一步一步来,暂不考虑TS流的解码,也不考虑音频。先直接解DM365编的H264裸流,用UDP接收。因为Demo程序是用Loader模块来实现文件流的读取和管理。如果我想改造成UDP接收数据,该如何下手。感觉Demo程序读取文件很严格也很死板,MS只能从开头读,也不判断帧头,读取的一帧肯定是正常开始的一帧。而如果UDP网络接收,由于编码端后来有其它处理,不是一帧一帧的输出,而是有组合成一个固定长度输出,所以接收这边肯定不会是一个H264帧一帧的读取。所以感觉弄起来有点麻烦。特别是看了Decode的Demo程序,各种FIFO,各种Buffer之间的关系很乱。读文件还要先搞一个Loader_prime读第一帧。感觉读静态文件可行。弄成网络接收数据实时解码有点麻烦。

        还请各位老师,朋友,高手们指点一下思路。谢谢!

  • 我觉得不管是读文件,还是udp流,其实都是解码器之前的操作,这个你可以自行设计

    你只需要注意送往解码器,不是有个api的嘛,你把一帧数据送进去就可以了。

    至于usp怎么parse出一帧,这个应该很容易找到一些开源代码的,如ffmpeg。

  • 谢谢你的回答。

    我的思路是参考一下Loader模块的设计,改造它,或者干脆不用它。建立一个UDP接收的线程,将数据缓存,然后去解析其中的NAL帧,然后送入解码的FIFO。改觉思路应该就是这个思路,但实现起来可能会碰到各种各样的问题。。DEMO程序缓冲区管理和FIFO之间的管理感觉有点复杂。。

     

  • 送给decoder的第一帧必须要是I帧,否则decoder可能会乱掉

    请参考codec engine API,Loader是DMAI的封装,你可以直接用codec engine来实现你要的功能

  • 谢谢您的回复。

    “送给decoder的第一帧必须要是I帧”,这个第一帧应该怎么理解?指的是程序运行以后解码器收到的第一帧吗?结合DEMO程序看的话,就是Loader_prime函数那块吧。

    这个我试过,确实。如果我把encode出来的测试文件test.264直接decode的话,没有问题。但如果我用二进制编辑工具将这个文件的开头去掉几个字节的话再decode直接就出错退出了。

    那假如说我能保证送给decoder的第一帧是一个I帧。此后送给decoder的帧如果不完全,或者开头几个字节丢掉,decoder会出错。换句话说,我直接读取N个字节,并不保证是一个帧的开始。如此这段数据扔给decoder会不会出问题?