花屏和丢帧问题解决思路.doc

IP摄像头播放 Uestc Computer 当前版本 V 密级 文档编号 总页数 正文页数 附录页数 编制人 评审人 鲁晓军 批准人 编制日期 评审日期 批准日期 修改履历 序号 状态 版本 修改内容 修改位置 修改人 日期 评审人 日期 批准人 日期 1 1.0 全文完成 张占忠 2015/06/27 2 3 4 5 6 7 评阅意见 状态：C—创建文档，A—增加内容，M—修改内容，D—删除内容BufQue[head] = numcount 0xff;//FirstBit; head = (head+1)%BUF_SZIE; BufQue[head] = (numcount8) 0xff;//SecondBit; head = (head+1)%BUF_SZIE; BufQue[head] =(numcount16) 0xff; head = (head+1)%BUF_SZIE; BufQue[head] = (numcount24) 0xff; head = (head+1)%BUF_SZIE; BUF_SZIE为缓冲区的大小。切记：由于缓冲区为循环队列，因此必须有求余操作。 检查缓冲区代码是否正确与是否丢帧的思路： 缓冲区代码写好以后并不能立即确定缓冲区代码是否正确，并且由于是一帧帧的得到数据，用单步调试太过复杂繁琐并且一不错就得重新调试，并且由于码流在不停发送并不能确定是否丢帧。解决办法就是将调试信息写到文件中去。 解决思路： First ：发送端发送数据是发送一个时间戳，也就是帧发送的顺序。接受端接受到的数据也有一个时间戳，如果接收端接收到的时间戳不连续，即是丢帧。 Second：接收端接受到数据以后在将数据写入缓冲区以前将H264码流保存到文件中设该文件为RecH264.h264. Third ：将从缓冲区里面读出来的数据也保存到文件中。设该文件为DecBuf.h264 Forth：用VLC播放器播放RecH264.h264.，如果没有花屏则证明接收到的数据无误。如果播放RecH264.h264.不花屏而播放DecBuf.h264花屏说明缓冲区代码错误。 Fifth：如果用VLC播放器播放RecH264.h264花屏，检查数据是否发送和发送的每一帧数据是都正确。 注意：如果写文件的时候以a+，ab+，w+等方式打开文件，在写文件的时候会自动将0A转化为0D0A，这时就算发送端发送数据无误，写文件的时候也会出错。解决方式很简单。以wb+方式打开文件，这样0A就不会转化为0D0A了。 花屏问题解决思路： 1：检查解码方式是否正确。 遇到花屏问题首先考虑的是是否丢帧。而丢帧问题的解决办法为增加缓冲区。增加缓冲区以后，如果还是出现花屏，这时候解决问题主要从以下方面着手。 第一：检查缓冲区，方法如上。 第二：解码是否正确。无论是采用FFmpeg解码还是用海思解码还是别的方式解码，必须确定解码是都正确。验证解码是否正确的方式如下： 将解码以后的YUV数据保存，可以自己编写YUV文件播放器也可以用现有软件播放。当然也可以将现有的YUV数据转码成RGB数据进行播放。如果此时不能正常播放则说明是解码出错。 2：针对缓冲区的访问机制。（事件遇到问题，信号量可以完美解决缓冲区互斥访问的问题） 对于缓冲区我们必须保持互斥访问，然而互斥访问就有一个问题那就是读和写会占据一定的时间，不能同时访问。不用mutex那么采用event会怎么样呢？会缓冲区爆掉，原因也很简单，因为如果解码一个很大的帧，解码需要花相当多的时间，这是同时到来2个event，然而传给解码进程的只有后面一个event，也就是说缓冲区里面有一帧数据没有进行解码，这样越积累愈多，缓冲区就会爆掉。 信号量semaphor可以完美解决以上问题。每往缓冲区里面存一个数据，semaphor就加1.每取一个数据semaphor就减一，只要有数据取进程就可以一直取，没有数据，那么取数据进程就阻塞等待，这样可以解决有的数据没有取走的问题。 3：SDL显示的控制。（每一帧应该怎么播放） SDL显示的时候如果用SDL_delay（）函数，不是说不行，而是相对不好，因为每帧的解码时间不确定，delay时间不好确定，并且如果帧率