多媒体相关


1. 花屏问题分析


1.1. 判断ISP输出是否正常

正常情况frame cnt 和Done Cnt 最多相差一个,如果有累计很多,说明isp这边只收到vsync 并没有实际data。

如上图。

如果isp 输出cnt 足够,再通过scl pattern判断isp 输出data 内容是否正常。

echo 2 > /sys/class/mstar/mscl/ptgen

pattern 会将isp 输出数据换成pattern 数据, 如果pattern 正常, 那说明isp输出内容有问题。


1.2. 判断Vif输出是否正常

如果Vif 是frame mode

echo dump chnid portid /path > /proc/mi_modules/mi_vif/mi_vif0

如果是bayer 10/12 bit格式需要通过转换工具专成16bit 通过7 yuv观察画面。

如果vif这边也是整张frame 都是花的,怀疑vif 这边没有收到sensor 数据。

如果这里出现有为0的情况说明vif 这边也没有收到data。


1.3. 判断sensor数据是否正常

echo devid > /sys/class/mstar/csi0/csi_dbg_mask
cat /sys/class/mstar/csi0/csi_ints

正常情况下都为0, 这里反映数据协议是否有问题, 如果有累加请sensor driver和硬件一起量一下信号质量或者clock是否有问题。


2. 常见的丢帧问题定位及解决方法


2.1. 常见丢帧原因

  1. 应用调用MI_VENC_GetStream()取流不及时,比如设置30fps,每秒却只调用20次取流接口。

  2. scl设置depth不够,output buffer轮循不过来,比如子码流设置20fps,depth却只设置1张。

  3. 硬件Scale或者venc工作异常,出现Rfull或者venc hung导致丢了几帧数据。

  4. 应用调用MI_VENC_SetSuperFrameCfg()开启超大帧丢帧或者重编机制,当出现size过大的帧会被丢弃。


2.2. 出现帧率不够或者断流时,定位过程

  1. 留意串口和/proc/kmsg有没有异常打印(mi_sys和mi_venc的debug_leve不能设置小于2)

    类似process exceed timeout MillsecAfterTaskEnqueued

    或者[MI WRN ]: _MI_SYS_Try_DequeueInputTaskNoLock[8674]: [thread:venc0_P0_MAIN] module id[2] dev id[0] pass id[0] inputtask is not finished more than 2secondsRfullIMI OFlow[CMDQ]cmdq(1) ERR: WAIT_TRIG_TIMEOUT

  2. 如果多路流都有帧率不够的问题,查看sensor帧率是否足够:

    1. Frame_interval: 略小于sensor帧率的倒数,并且保持稳定不会跳动很大。否则是sensor驱动问题。

    2. ISP_FIFO_FULL:表示isp统计的,从MIPI接收丢了几帧。正常应该为0,或者保持某个值不动。

    3. 如果ISP_FIFO_FULL值异常,大概率是isp出现了回挡(OSD叠加、scale异常、ring mode rfull和imi mode OFlow都有可能导致回档)。

    4. 如果ISP_FIFO_FULL值正常,Frame_interval和帧率不符合,可能是驱动问题,或者应用下给sensor帧率下错。

  3. 检查sensor帧率设置:

  4. 如果是单路流帧率不够,其他路流帧率正常,检查scl output framerate 和 venc output framerate

    BufCntQuota:应用设置的scl port buffer块数,如果是port1的fps不够,大概率是depth不够,output buffer轮循不过来。可以给port1的depth增加1块试试。

    Fps: output port的实际输出帧率,如果不够,尝试该通道上所有RGN关闭。(RGN如果画太多,当它的带宽优化级较高时有可能出现scl port帧率不够)。

    Inputport DropCnt:如果应用取流不及时,venc output buffer占满,encoder就开始drop yuv frame。因此这个值一直增加表示应用有取流不及时的行为。

    OutputPort DropCnt:如果开启超大帧丢帧或者重编机制,或者encoder编出一帧size过大放不下Output buffer,该帧会被丢帧,这个值就会增加。

  5. 举例

    我们的venc ring buffer是长*宽*50%,里面最多能同时缓存MaxSteamCnt 默认这个值是6张。用户设置码率是6M。venc outputbuffer里偶尔出现要塞第6张的时候,剩余空间不够放第6张了,就会被丢掉,output dropCnt就会+1。解决output drop的方式是增加output buffer size,或者减少码率让每帧体积变小,或者减少MaxStreamCnt,但是减少MaxStreamCnt 意味用户取流要更快。


3. Sensor出图异常


3.1. I2C 不通

I2C不通时,请确认:

  1. 工作电压是否正确

  2. MCLK 是否正常

  3. Power on 时序是否与spec 相同

  4. 上拉电阻是否正常

(上拉不够)


3.2. MIPI CLK计算

Spec是24MHZ mclk ,420Mbps/lane, MIPI信号进入HS mode,clock 上升沿跟下降沿都可以接收数据,若使用MCLK = 21.6M所以420/ 2 X(21.6M/24M) = 189M


3.3. 画面紫色/红蓝颠倒

Bayer ID不对


3.4. MIPI garbage接收不到数据

  1. LP->HS 的LP00过长

  2. MIPI swing: LP 1.2V,HS 200mv左右


3.5. Parallel sensor 粉色条状线

Connector 接触不良


3.6. CLK 不足导致sensor 数据接收不全

ISP clock > sensor clk

3.7. ISP 无法frame done

可能的原因如下:

  1. 误判HS 信号

  2. Data 收不全/有瑕疵,加大window output size,再crop

  3. 频宽不够 FIFOfull

  4. 其他


3.8. 影像有dummy pixel/ ob data line


3.9. Gain/shutter 生效不同步

Gain/shutter 要确保在同一个frame 生效必需使用group hold latch方法并确保shutter/gain都在n+3帧生效。

判断shutter/gain在第几帧生效可以设置manual AE,改变shutter/gain收AE log,看curY在第几帧变化。


3.10. PCLK 极性不对

32X系列只能改sensor极性,31X可以驱动改主控端


3.11. Parallel sensor Vsync / hsync 极性不对

数据接收不全


3.12. 高亮出现彩色

Sensor pad 设置不对,导致高位data bit 丢失


3.13. 高亮粉色

  1. SC sensor 亮区发紫异常gain, Coarse gain( 16’h3E08)bit[4:2],将低位置1,data|0x03

  2. 高位溢出,改SENSOR_DATAPREC


4. venc output buffer的行为说明

以output buffer size(u32BufSize)为1M,u32MaxStrmCnt=4为例:

  1. Create venc的时候,output buffer(venc-ring-mem)即从mma里被申请好并且整块被映射成连续的虚拟地址。

  2. Encoder从output buffer的起始位置填编码帧,假设放完第4帧,output buffer尾部还剩余空间,encoder也不会接着第5帧,而会从起始位置放第5帧。

  3. 假设放完第1or2or3帧,output buffer尾部剩余的size < output buffer size /MaxStrmCnt即250K的时候,encoder也不会在尾部接着放,而会从起始位置放。

  4. 假设放完第1or2or3帧,output buffer尾部剩余size大于250K(假设是300K),但是接下来encoder编出了一帧大于300K的帧,那就会出现pack=2的情况,即将这一帧300K放在尾部,剩余放不下的继续从起始位置放。

以上几种情况,当需要继续从起始位置放,但是用户一直没有取流或者取流慢导致第1帧还没有被取走,则encoder会停止编码,直到空间被腾出来。


5. 抓yuv图数据大小异常

  • 现象描述

    在一些版本的sdk系统下,通过api tool抓yuv图,发现yuv图像大小为理论值的2倍,无法通过工具查看。

    假如input分辨率为1920*1080,那么抓出来的YUV为YUV420的话,图像大小应该为1920*1080*2Byte,但是实际大小为1920*1080*2*2Byte。

  • 解决办法

    这些版本的sdk抓出来的YUV数据是YUV444规格,所以导致图片大小为理论值的两倍,但是YUV有效数据如果按照YUV444去排列,即无效位都用0填补,就会导致工具查看异常。

    需要通过YUV444_conv.7z去转换。

    用notepad++打开execute文件,如图修改需要转换的yuv文件后保存,再双击execute即可,生产的文件名为YUV444.bin,改成***.yuv。然后用7yuv打开,注意格式要选择YUV444。