190、安霸CV25在8K30视频编码下的ISP裁剪与缩放流水线——如何避免DDR带宽瓶颈
去年做一款8K运动相机，主控是安霸CV25，传感器是索尼IMX585，输出8K30。方案评审时大家觉得CV25的ISP标称支持8K30，应该没问题。结果样机一出来，编码器一开，DDR带宽直接爆了，系统卡成幻灯片，连UI都拖不动。查了三天，最后发现根本不是编码器的问题，是ISP裁剪和缩放流水线在偷偷吃带宽。
先说结论：CV25这颗芯片的ISP处理能力是够的，但它的DDR带宽预算非常紧张，尤其是8K分辨率下，任何一次多余的全幅面读写都是在自杀。我们最初的设计是传感器输出8K全幅面，ISP先做3A统计，然后做裁剪到4K，再缩放输出给编码器。听起来很合理对吧？问题就出在这个“先裁剪再缩放”的顺序上。
CV25的ISP流水线里，裁剪和缩放是分级的。裁剪模块在RAW域，缩放模块在RGB或YUV域。如果你在RAW域裁剪，那没问题，因为裁剪后的数据量变小了，后续处理带宽自然降低。但如果你在RAW域不做裁剪，直接全幅面送进缩放模块，那缩放模块就要对8K全幅面做一次完整的读写——这还没完，缩放模块的输出如果还是8K（比如你要做电子防抖的裁切预留），那又是一次全幅面读写。两次8K全幅面读写，加上编码器的参考帧读写，DDR带宽直接超了CV25的极限。
我们当时犯的错就是：传感器输出8K，ISP的裁剪模块设成了8K全幅面（因为要保留电子防抖的裁切余量），然后缩放模块把8K缩到4K给编码器。结果就是RAW域全幅面读一次，RGB域全幅面读一次写一次，YUV域再全幅面读一次写一次。三次全幅面读写，每次8K30，带宽直接爆表。
正确的做法是把裁剪和缩放合并到同一个流
