//判断当前帧是否到达了endtime,是则返回false,停止取下一帧
附带几个我自己看过的网站:
OK,今天就这多, O(∩_∩)O哈哈~
现在发现,此程序只有在release模式,而且是直接点击可执行程序时画面比较流畅,有轻微卡顿。
但在调试状态下,Debug模式,图像就很不流畅。感觉是1秒停顿一次,但每秒还是播放25帧画面。
此时我的GOP设置是25.感觉就是遇到一个关键帧就卡一次。
我的延时机制是,不断计算图像的时间戳与当前视频播放已经持续时间的差,并调用Sleep延时一段时间。每两帧图像的时间戳间隔为40毫秒,恒定。
请问这个机制有什么很大的问题吗,谁还有更高效的机制吗。请高手赐教。
不同帧可能解码时间差距比较大,所以问题就出来了,应该是ddraw显示的时候处理,比如ddraw永远都保存了5帧的缓冲,满了decoder就等,少了decoder就解新的帧
我只是用的DirectDraw的Blt函数把解码得到YUV数据进行显示,其他的播放控制都是自己做的。
想LS所说不同帧可能解码时间差距比较大,但我的策略是追赶参考时间(画面播放持续时间),即使差距很大,也应该在一帧之内赶上。
而且我在做的时候加了判断,遇到关键帧我的Sleep时间就稍短一点。但卡的情况依旧很严重。
timeSetEvent我也用了,但windows同时只支持15个timer,我有16个窗口,最后那个窗口显示不了图像。而且我换了之后效果还是那样
我的延时机制是,不断计算图像的时间戳与当前视频播放已经持续时间的差,并调用Sleep延时一段时间。每两帧图像的时间戳间隔为40毫秒,恒定 "
2 找楼主的方式,没有考虑到解码所消耗cpu和所占用的时钟,尽管解码相对于编码来说消耗很少,按照你的方法,遇到关键帧,解码消耗一大,延时就不准确了,所以会在关键帧出现的时候可能卡
为什么一定要延时呢?让播放自己去阻塞不行吗
我的播放是自己做的,不延时图像就是快进。
我的意思是让render去阻塞,render是自己做的?
如果是在source端做的延时,那解码用去的时间就无法保证了
建议在blt之前做时间判断试试,如果早了就等到那个时间再blt,如果晚了就丢弃或者马上blt,其实这样就有些象video renderer的处理方式了
我现在已经做成解码后再延时,但效果还是和之前一样。debug,调试模式就卡,release模式,直接点可执行程序就没问题,图像很流畅。这难道和编译器也有关?
debug模式时执行的东西肯定要比release时要多,消耗的资源也大,另外实时运行的程序你如果去断点调试,肯定也会有问题的
既然release版本可用,为什么还要调试?
我要找到真正的原因呀,刚才又有发现,但我的图像卡的时候,那一秒的帧率只有21帧,事实上不是数据不够,是我有比较连续的4帧解码失败。但这种情况在release模式下似乎不会有。如果是这样的话,我就可以不用再查我的延时机制,因为这个机制在使用上一个解码库时是很正常的。
恭喜你找到卡的真正原因了,呵呵
加了,可上班时间我不聊qq的:)
我现在也想做一个,楼主能告诉我说,视频流的设计流程是怎样的吗,谢谢
我现在手上网络摄像机,可以输出视频流,我上位机如何来设计呢,大概的流程是怎样的,谢谢!
注意:采集出来的图像的是YV12格式的。用YUV格式查看软件看下效果: