视频编解码项目经验

http://wangwenbingood1988.blog.163.com/blog/static/351545932011613103232491/

  用纸记录的经验东西，并不是可以走到哪儿就能带到哪儿的，总有一天会丢失。所以我现在记录经验和总结都是写在博客上了，并没有额外的意思。

音频延迟的分析与解决

问题：在联机测试的音视频实时编解码时，音频总有延时现象

分析过程：王老师领着小组成员做了如下分析：

1.       音视频编码都经历了相同的采集、编码、发送一整个线程；而解码都经历了相同的接收、解码、播放一整个线程；

2.       着重的分析了如何避免线程的不间歇的死跑问题：一是通过让线程沉睡和唤醒来解决；二是通过中断机制来终止；此次应用中，收发包的send() 和receive()函数具有阻塞功能，而像视频中的addCallback()和setPreviewCallback()回调函数保证了线程的中断；

3.       针对延时的根本问题和现象，分析到在采集过后底层的缓冲区、解码前底层的缓冲区以及播放时底层的缓冲区大小对音视频延时的影响程度问题；

4.       根据侯博提出的症状现象：在两部手机对发的实时编解码中，总是只有一路音频有延迟，且总是先接入网络的那部手机在接听时有延迟；比如：利用HTC Desire（称之为A） 和 Motorola ME525（称之为B）做测试时，A先接入网络，B后接入，则B能实时的听见A的声音，而A听B的声音时就有1~2秒的延迟；

分析此问题可能性：由于A手机接入网络的同时，其音频的编解码器都同时打开了；提前打开的编码器编出的数据由于B方未接入网络直接丢失，只要B方接入网络即可实时收听；而提前打开的解码器的缓冲区被系统默认的缓冲了很多未知不可听见的数据（比如置0的）而导致了A方真正需要解码数据时，先得处理被填充的数据而导致了延时；

解决办法：解码器总是在收到的语音时才打开，不提前打开以避免系统默认的填充；

5.       问题拓展：按前述分析的话，如果是A先接入网络，B后接入网络，如果是B听到的有延迟的话，则可能是编码端的缓冲区过大，保存了提前接入的信息；

 

 

解码端马赛克问题的分析与初步方法

问题：解码端视频初始马赛克现象严重

分析过程：由于是局域网wifi收发，虽然有丢包，但是肯定比3G网络要好很多，所以即使导致马赛克问题，也不应该有那么严重的现象，而解码库本身可以正常的播放文件码流，说明所以将问题定位在我们的编码库配置上面，

1.       解码库可以正确的播放文件码流，说明解码库是正确的，至少对于完整的码流是正确的；即使出错也是由于丢包引起的错误，那是解码库不够健壮，错误隐藏功能不够好。这应该也是导致马赛克的问题，但是这个解决方法有点难，也不是一时半会能够做好的，所以解决问题时，暂放了下。

2.       另一个可能出现解码马赛克严重现象的问题就是编码端的配置问题，这也是对解码段错误隐藏功能的一个间接解决，既然解码端错误隐藏功能不够好，那么就尽量让编码端编出来的码流犯错误的概率更小。

3.       去除解码有马赛克问题的一段码流B和编码端同时记录的该段码流A进行比较，发现编码端录像时记录下的码流是可以正常解码的，而解码端的是有马赛克的。侯博分析是由于P帧间的相互参考引起的，于是将码流B进行了几种解码实验（去IDR帧，去I帧，挨个去P帧，去对应的码流段其实是一种模拟丢包），去IDR帧是全部不能正确解码，因为I帧参考IDR，而P参考I，所以全部解码不正常。如果去了I帧这块码流的话，那么IDR可以正确解出来，但是I帧之后的P帧全部不能正确解码，因为少了参考帧I。如果去了第一个P帧，那么之后的P帧都不能正确解码，而且是越往后P帧马赛克越严重，说明P帧之间在相互参考，没有I帧的刷新，进行了错误积累。因此解决办法是将编码端的IPPPP间隔调的更小，从每15一个I帧调到了每4帧一个I帧可以一定程度上减小马赛克现象。

 

 

 

解码段图像播放时的快速闪动问题

问题：实时采集视频的码流经过手机编码端编码后发送到解码端，再经过解码器播放，视觉效果明显加快

1.       编码器的编码速度问题。因为摄像头的采集率25f/s，但是编码器，尤其是手机端根本没法达到每秒25帧，那么这就意味这编码端肯定会每秒都会有好些帧丢失了，那么这显然就会导致解码端的解码流看上去不连续，也就是快速闪动的问题。解决办法有两点：一是增加编码端的效率，进行算法优化和汇编优化以及代码结构优化等；二是增加一个缓冲队列，这样让编码器从缓冲队列中取。但是提高编码器的效率才是解决问题的根本方法，如果编码器效率跟不上，缓冲队列会越来越大，直到满队列溢出。并且队列的添加也会导致实时采集及解码的破坏。

2.       另一点解码端码流的快速播放问题，是由于此时是纯码流直接播放。换句话说：平时我们见到的播放器（比如迅雷看看，VLC，暴风影音等）为什么播放起来的速度人眼睛可以接受?那是因为播放器里面有时间控制，每个多少秒播放一帧，而不是解出来一帧立刻播放，也就是我们手机解码器解出来的图像是没有加时间等格式控制的，是一种即解即播的，所以看上去即使每帧都编码发过来了，我们仍然会觉得播的挺快的原因。解决办法：加上时间控制。

 

 

关于C语言代码结构优化的认识

1.       可以修改参数值，但是不能删除参数；

2.       修改原则：从大往小，从里往外，从主到次；

3.       注意每次修改后的运行验证与备份保存

分析：

①因为从代码开始处进行修改参数和结构优化时，我们首先能够通过修改配置参数值，使得很多方法从大方向上进行决定。简单分析并修改编码器的参数配置可以提高编码器3个1~3个fps；

②从深层次注释往外改，因为很多变量，并不知道更深层次有没有用到这个变量，如果用到了的话，这一注释或修改使得该变量或该语句里的其他变量的消失直接会导致程序的崩溃。所以从深层此往外改，是可以避免这个情况的。

③一个项目工程一般都很大，不可能直接找到最里层的那个函数，那么，个人觉得，就是找到项目主要功能实现处的主要几个函数，然后由这几个函数分别进到各自里层去进行修改。

④同时，没修改一步，注意运行验证和保存，不见得每一步都是正确的，所以随时可能要返回到刚才的正确版本。