调试经验总结

1. log 打印过多导致视频解码性能下降： 采用gettimeofday()这种方式去测量运行的瓶颈，会发现瓶颈出现的地方随机变化。一般这种情况就要怀疑是因为log输出造成的。因为所有IO操作都是可以被中断的，进程就需要放弃处理器，等待下次再被调度执行，这个时间是随机的。 

解决方案：在正式的版本中log的输出需要进行严格的控制，只有异常分支才需要进行log的输出用于定位错误发生的位置需要添加行号、所使用的参数。

2. 在公司工作和在学校实验室很不同，尤其是在一些业务比较繁忙，管理不规范，基础设施不健全的公司更是如此。他们更关心的是快速解决问题，至于解决问题的方式方法和效率他们是不关注的。我在学校养成了深究原因的习惯。

3. 接手一个bug第一件事情就是要确定发生bug的模块。比如视频播放出现花屏可能的情况有：视频数据有问题、video codec driver 解码出现错误、后端数据处理(解码后的数据所做的格式转换、缩放)出现异常、叠图出现异常。为了能够理清问题在设计的时候一个模块对它所处理的数据一定要有动态dump的功能：dump 本模块的input output。

4. 视频播放出现卡顿这种类型的bug比较难解决，故障出现的场景不同虽然是相同的现象但背后的原因是千差万别。如果是正个视频从头到尾卡顿，就要怀疑视频解码器性能、源端数据推送是否流畅。如果是只在seek时卡顿对于HEVC就要判断seek后的decoder丢帧是否合理，HEVC新增加的CRA随机起播点用于提高编码效率引入RASL类型的帧在随机起播时候可以丢弃。但是要避免紧邻CRA序列的下一个CRA序列中的RASL被丢弃。不恰当的丢弃会导致seek的时候视频不连续。

5. 按照HEVC SPEC DPB size 是包含 the current decoding picture. 现在遇到一支码流它在SPS中指定了DPB size = 5，但是随后帧中的slice header 所parse 出来的RPS信息显示参考帧的数目也是5，这就不符合SPEC了，当解码器严格按照SPEC去实现的时候这个码流就会解花。这就是在解决问题的时候需要支持这种不符合SPEC的码流的情况。

6. 现在有一支码流其中只有IDR TRAIL_N两种NAL并且全部都是I帧，按照现有的SPEC 该码流的POC计算可能会发生错误。下图为None IRAP NAL type in HEVC spec.

POC 的计算方法：

前一张图片的选择和prevPicOrderCntLsb   prevPicOrderCntMsb 的计算过程：

7. 视频卡顿问题的原因会比较多：解码超时导致AV Sync的模块丢帧这种情况会比较容易检查。如果解码时间是正常的要检查这个问题最有效的方式就是以 display order dump解码后的图片、转换成YUV格式、使用工具播放查看效果。如过做不到这一点在调试的时候将每次ouput pic的 POC 打印出来也能够确认问题。因为HEVC中IDR会重置POC,而且有些图片可能不会输出所以会导致POC不连续。用这一种方式排查问题不是太直观。完备的调试手段是高效解决问题的基础，如果team在这一块做的不充分，工作起来就会比较痛苦。