199、车载摄像头冻结帧检测的硬件实现——基于海思Hi3519的ISP帧间一致性校验与报警机制
去年冬天在南方某车厂做AVM环视项目，客户反馈一个诡异现象：倒车影像偶尔会“卡住”半秒钟，但车机系统日志里没有任何报错。一开始怀疑是传输链路丢包，抓了MIPI和USB的波形都没问题。后来把录像导出来一帧一帧看，发现画面不是卡住，而是某一路摄像头输出的帧内容完全重复——典型的冻结帧（Freeze Frame）。这种问题在行车记录仪上可能只是漏录几秒，但在倒车或自动泊车场景下，可能直接导致碰撞。更麻烦的是，它不像坏点或偏色那样肉眼可见，属于间歇性故障，产线抽检根本测不出来。
车载摄像头冻结帧的根因五花八门：传感器端PLL失锁导致VSYNC异常、ISP的DDR带宽被抢占导致写回失败、甚至电源纹波过大引起MIPI时钟抖动。但不管源头在哪，系统层面必须有一个“最后防线”——在ISP硬件流水线里实时检测帧间一致性，一旦发现异常立刻报警并触发降级策略。海思Hi3519的ISP里恰好有相关的硬件模块，但文档写得极其简略，寄存器描述就几行字，不踩几次坑根本用不起来。
先明确检测原理。冻结帧的本质是当前帧与前一帧的像素内容几乎完全一致，但注意“几乎”——因为传感器噪声和ISP的时域降噪会让两帧有微小差异，哪怕场景完全静止。所以不能做逐像素比较，得用统计特征。Hi3519的ISP里有一个叫“帧间差分统计”的模块，它把画面分成若干块（比如16x16的网格），对每个块计算当前帧与参考帧的SAD（绝对差值和）或MAD（平均绝对差）。硬件会输出每个块的统计值，以及超过阈值的块数量。我们只需要配置阈值和检测区域，然后定时读取结果。
这里有个关键设计决策：参考帧怎么选？海思的文档建议用上
