在发布SDK内测的时候，我们发现在切换视频分辨率的时候有低概率出现VPSS模块跑飞的情况，概率低于1%，试个两三百次，能出1~2次。切换视频分辨率这个功能在安防产品上也确实存在需求，网络带宽不大好的地方分辨率可以适当下调一点降低负载，真正在产品端切换视频分辨率这个功能也不会切换那么频繁，但是从技术上有这个1%的风险，从长远考虑还是得花力气来解决一下。
VPSS模块的概念来源于海思平台，后面大家都这样学习，实际上就是一个视频中间处理的一个模块，比如分辨率的动态调整、多通道输出（比如一个sensor输出多个分辨率的视频，有点像是分频器一样）、还有一些图像格式转换（比如输出yuv，还是rgb都可以设置）、叠加OSD（显示时间、品牌logo等）。
产品背景是采用自研的安防类的芯片，采用linux操作系统，框架上采用自研的多媒体框架，概念学习海思平台，大致也就是那么就给打快，VI, VPSS, VENC, NPU,VDEC,AENC,ADEC等等。这种安防的产品，是无屏幕的，通过网络连到服务器，在手机上开发了一个APP来实现互联互通。
/*****************************************************************************************************/
声明：本博内容均由http://blog.csdn.net/edsam49原创，转载请注明出处，谢谢！
/*****************************************************************************************************/
切换视频分辨率的时候，叠加在视频上的OSD也会做相应调整，比如300w的视频用个的LOGO图片跟720P视频用的图片大小肯定是不一样的，显示的时间戳这些字号的大小要跟视频成一定比例，不然看起来就不协调了，因此就会有osd删除和再叠加的过程。先看看出问题的打印：
出现这种 fifo overflow 就没法恢复，串口也没法输入了，只能重新上电。没有图像帧数据往后传递，编码也不会有数据，这种情况跟死机一样，后果很严重。从品质控制的来说，虽然你的概率很低，但是你的后果已经是顶级的严重，两者关系相乘得出的品质控制参数RPN值也还是不容忽视的，那就彻查吧。
从出现的概率很低，复现一次不容易，因此得做足调试的功课，把能想到的可疑点都加上一些关键打印，不然也只是复现问题，对真正解决问题推动不大。从前面跑飞的前后打印来看，我们分析应该是出在osd部分。先从驱动入手，分析VPSS什么情况下可能会overflow，跟ic设计的人沟通，前面osd位置、大小超过图像的范围会导致overflow。但是从流程上我们切换之前已经把osd都拿下了，为啥还会有呢？我们再在VPSS的中间hal层增加和删除osd的必经之路上加满打印，同时对增加和删除不成功的时候增加了重试机制，多试几次。有了这些信息后，我们就继续跑呗。这种要操作手机APP很多次的，会累死个人，重复、枯燥，真是苦了测试的兄弟。为了减少这种疲劳，在应用上我开发了不通过手机APP也能在本地实现重复反复设置的切换视频分辨率的功能，循环执行，高频高压执行。方法如下，通过后门来控制：
通过反复调试，测试，抓到一次很有意义的突破口：
发现正常的时候，删除OSD都是清一色的del信息，出问题前，有遇到一次osd_update，跟SDK hal层同事分析，osd_update就是直接增加了一个osd进去。为啥在退出的时候还会有增加一个osd进来呢？
有了重要线索，就继续查吧！
往最上面就是应用的处理.先看应用的处理,我们时间刷新有一个线程定时刷.看代码流程上,有先停刷新操作,再删除osd. 从理论上看也是没问题的. 那就再看看SDK接口的实现吧! 果然找到了一点信息.
就是说删除OSD和update canvas的接口是共用的一把锁。出问题的时候大致是这种情况，先执行到了删除，就拿到这把锁了，还没删除完之前，update canvas就调用了，这时候handle这些是有效的，就跑到了等锁这里，等删除完成归还锁了后，update就呼噜呼噜的跑下去了。这是明显有漏洞的，调过了handle的有效性检查。如果把这把锁位置提前，就完全可以避免出问题。
同时，HAL层处理也是有问题的，在刚执行完删除后，没有做状态标记，又能update执行下去，而且是跟掉叠加osd的接口是一样的，这也是不合理的。你相当于有两条路走到驱动上去，没有管控状态，上面失控的时候，你没有防范啊。
所以说，从根本原因上分析，接口层和HAL层都有问题。为了快速解决问题，我们就把接口层的锁的位置提前一点，HAL层的问题等HAL层的同事后面来补强吧！至少现在跑起来是没有问题了的。
修改完后，跑了，差不多跑了切换视频分辨率接近4800次没有复现问题。再提交到测试同步手动操作APP又测试了上千次，没有再复现问题，算解决了吧！后面再遇到再分析。
总结起来，解决这种疑难杂症，需要耐心，需要多方位考虑，把不大可能发生的地方也当成可能发生的地方，不放过死角，问题最终解决之前，都有嫌疑，丰富一下调试手段，提高解决问题的效率。
