在发布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又测试了上千次,没有再复现问题,算解决了吧!后面再遇到再分析。
总结起来,解决这种疑难杂症,需要耐心,需要多方位考虑,把不大可能发生的地方也当成可能发生的地方,不放过死角,问题最终解决之前,都有嫌疑,丰富一下调试手段,提高解决问题的效率。