TI中文支持网各位老师和朋友好，我想用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读第一帧。感觉读静态文件可行。弄成网络接收数据实时解码有点麻烦。
还请各位老师，朋友，高手们指点一下思路。谢谢！
JUN ZHU1：
回复 bin li2:
谢谢你的回答。
我的思路是参考一下Loader模块的设计，改造它，或者干脆不用它。建立一个UDP接收的线程，将数据缓存，然后去解析其中的NAL帧，然后送入解码的FIFO。改觉思路应该就是这个思路，但实现起来可能会碰到各种各样的问题。。DEMO程序缓冲区管理和FIFO之间的管理感觉有点复杂。。
JUN ZHU1：
回复 Tuff Li:
谢谢您的回复。
“送给decoder的第一帧必须要是I帧”，这个第一帧应该怎么理解？指的是程序运行以后解码器收到的第一帧吗？结合DEMO程序看的话，就是Loader_prime函数那块吧。
这个我试过，确实。如果我把encode出来的测试文件test.264直接decode的话，没有问题。但如果我用二进制编辑工具将这个文件的开头去掉几个字节的话再decode直接就出错退出了。
那假如说我能保证送给decoder的第一帧是一个I帧。此后送给decoder的帧如果不完全，或者开头几个字节丢掉，decoder会出错。换句话说，我直接读取N个字节，并不保证是一个帧的开始。如此这段数据扔给decoder会不会出问题？
