多媒体相关

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 2seconds、Rfull、IMI 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。