099、3D降噪在车载与安防平台上的策略选择——基于瑞芯微RK3588与海思Hi3519A的对比调优去年年底接了个活儿，给一家做行车记录仪的公司调3D降噪，主控从海思Hi3519A换到瑞芯微RK3588，客户反馈晚上等红灯时前车尾灯拖影严重，而且车身两侧的路灯杆子有“鬼影”晃动。当时我第一反应是时域滤波强度拉太高了，结果把3519A上的那套参数直接搬过去，发现RK3588上画面不仅没干净，反而出现了一堆类似“水波纹”的闪烁，尤其是暗部区域，噪点像呼吸一样一涨一缩。后来查了芯片手册才发现，这两颗芯片的3D降噪硬件架构压根不是一回事，策略必须跟着平台走。先说说海思Hi3519A的3D降噪。这颗芯片的时域降噪走的是“运动检测+像素级混合”的老路子，内部有一块专门的DDR带宽预留区，用来缓存前一帧的整幅图像，然后通过运动估计模块算出每个像素点的运动矢量，再根据运动量做帧间混合。它的特点是运动检测粒度很细，可以做到4x4像素块级别的运动判断，所以对于慢速运动的物体，比如行人、缓慢转弯的车辆，降噪强度可以开得比较高而不容易产生拖影。但代价是，它对场景切换的响应比较迟钝——如果画面里突然闯入一个快速移动的物体，比如对面车道飞驰而过的车，3519A的时域滤波需要大概8到10帧才能完全“跟上”这个运动，期间就会在物体边缘留下明显的残影。我当时在3519A上调夜间城市道路，把时域强度开到60%左右，配合空域降噪的弱档，效果已经很干净了，运动物体的拖影控制在两个像素以内，客户验收通过了。但换到RK3588上，问题就来了。瑞芯微这颗芯片的3D降噪走的是“多级金字塔+运动补偿”的路线，它内部不是简单做帧间混合，而是先把当前帧和参考帧都下采样成多层金字塔，然后在每一层上做运