2021年12月8日 06:40

1、问题背景
客户使用F133进行一体广告机项目开发过程中,测试到附件中的片源《少女时代OhMVFullHD1080(播放花屏).mp4》播放时会出现花屏现象。但在之前的C800相同项目中该片源测试正常。

2、问题描述
出错第一帧标号为17(标号从0开始),如下图所示:

da9c3adc58f84f8eb9b1e7d5cb3d0ec4.jfif

抓取该帧花屏图像,现象如下:

3d51e88c16464edf8ba651a6cf3c4a0b.jfif

花掉的图像帧数据如下:

7db8c1e56dfc4ca2a4210e43e89395db.jfif

3、问题分析
(1)关掉cache,花屏现象仍旧,排除漏刷cache影响;
(2)64位系统(tina/melis)播放均花屏,32位系统正常;
(3)寄存器对比,未发现异常;
(4)在FbmRequestBuffer中将请求到的buffer清零,图像仍会花掉,但是花屏现象如下:
aa75881faf5e4df188b7155423c7be2c.jfif

3611d291672040c18324116b11f523d2.jfif

推测在视频播放的过程中,该部分未有数据写出,仍然保留该buffer中上一帧的数据。(未修改代码前出错第一帧下半部分之所以是黑色的,是因为该视频前面的12帧均为黑色图像帧,所以该buffer中残留有上一帧的数据)

daf70c99de2f4e0b83f821cf7c086999.jfif

最后,通过添加打印发现,正常情况(R528平台),在未解码完一帧时,会通过检查同步标记函数而进入下一个packet的解码 ,但是现在异常(F133/D1)情况下跑到了else里面,导致一帧图像没有解码完,就解下一帧了。 正好前面抓图的现象也是第一帧出错的图像,下半部分是前面图像的数据残余。

经分析,该问题的根本原因是在64位编译器中,i>>32 都等于i;而在32位编译器中,i>>32 都等于0。所以此发现也正好解释了之前的测试结果 “64位系统(tina/melis)播放均花屏,32位系统正常”。

4、解决办法
对出现右移32位的情况做判断,即return (rbit-n)<0?0:((rbit-n)>=32?0:(ld->bit_a & (0xFFFFFFFF >> (ld->bitcnt))) >> (rbit-n));

对应的库文件见附件。
library.7z