031、无人机图传低延迟架构——联发科Imagiq的ISP低延迟模式与MIPI传输优先级控制去年夏天在南方某无人机客户现场我们被一个“幽灵延迟”问题折磨了整整两周。飞手打杆图传画面大概滞后了120毫秒穿越机玩家根本没法飞。更诡异的是这个延迟不是固定的时大时小偶尔还会突然卡顿一下。我们用示波器量了MIPI的LP/HS切换用串口打了每个模块的时间戳最后发现罪魁祸首根本不是ISP处理速度不够而是Imagiq的帧调度器在“偷懒”——它把ISP的帧率锁在了30fps但sensor实际输出是60fps导致每一帧都在缓冲区里多等了半个帧周期。这就是典型的“平台默认策略”和“应用场景需求”打架的案例。联发科Imagiq的ISP架构和高通Spectra有个本质区别——它把很多控制逻辑做成了“策略引擎”而不是硬编码的寄存器序列。这意味着你可以在运行时动态调整ISP的行为模式但代价是如果你不主动告诉它你要什么它就按最保守的默认策略跑。对于手机拍照这个默认策略没问题甚至很聪明但对于无人机图传这个“聪明”恰恰是延迟的根源。先说Imagiq的低延迟模式。在MTK的ISP驱动里有个叫isp_latency_mode的接口接受三个值LATENCY_NORMAL、LATENCY_LOW、LATENCY_ULTRA。NORMAL模式就是默认的ISP会做完整的3A统计、多帧降噪、HDR合成等所有处理帧率完全由sensor的VSYNC驱动。LOW模式会跳过一些非必要的统计计算比如把AWB的统计窗口从全画面缩减到中心区域把AE的收敛速度调快——这些改动对画质影响不大但能省出大概3-4ms的处理时间。ULTRA模式更激进它会直接关闭部分ISP硬件模块的时钟门控比如关闭色彩校正矩阵的实时更新用上一帧的参数同时把降噪强度降到最低档。这个模式能再省5-6ms但画质会明显下降噪点会变多色彩也会偏一点。这里踩过坑——别在ULTRA模式下还开着HDR。我们当时为了追求极致低延迟把HDR和ULTRA同时打开了结果Imagiq的HDR合成模块和低延迟模式有冲突导致输出画面出现撕裂。查了半天最后发现是MTK的驱动代码里有个隐藏的依赖关系HDR合成需要至少两帧的缓冲而ULTRA模式把帧缓冲压缩到了一帧。这个坑在文档里完全没写是我们在抓MIPI的帧间隔时发现的。再说MIPI传输优先级控制。这是Imagiq比较有特色的地方——它的MIPI TX控制器支持多通道优先级调度。默认情况下所有数据通道是轮询调度的也就是round-robin每个通道轮流发送。但对于图传场景我们需要把ISP输出的YUV数据通道设为最高优先级把统计数据的通道比如3A的AE/AWB统计降为低优先级。这样做的原因是统计数据晚到几毫秒没关系但YUV数据晚到一帧整个图传链路就多了一帧延迟。具体实现上MTK的MIPI TX寄存器里有个MIPI_TX_PRIORITY_CTRL可以设置每个虚拟通道的优先级权重。我们当时把YUV通道的权重设为15最高把统计通道设为1最低把元数据通道设为8。改完之后延迟又降了大概2ms。但这里有个副作用——统计通道的数据被延迟后3A的收敛速度会变慢特别是在光照快速变化的场景下画面会短暂过曝或欠曝。解决办法是在低延迟模式下把3A的收敛速度调快用算法上的激进策略弥补数据到达的延迟。还有一个容易被忽略的点——MIPI的LP/HS切换时间。在低延迟模式下我们建议把MIPI的LP进入时间设到最短。MTK的MIPI TX有个LP_ENTRY_DELAY参数默认是100us我们把它调到了20us。这个参数影响的是当一帧数据发送完毕后MIPI链路进入低功耗状态LP的等待时间。如果这个时间太长下一帧数据到达时链路还在LP状态需要额外的时间切换回HS状态这个切换时间大约需要30-50us。虽然单次切换时间不长但累积起来一秒钟60帧就是3ms的额外延迟。这个参数在MTK的文档里标注的是“建议不要修改”但我们实测下来调到20us完全没有问题只是功耗会稍微增加一点。再讲一个更隐蔽的坑——sensor的曝光和ISP的帧同步。在低延迟模式下我们建议把sensor的曝光模式从“自动曝光”改成“手动曝光AE算法控制”。为什么因为自动曝光模式下sensor的曝光时间变化会直接导致帧率抖动。比如从暗处飞到亮处sensor的曝光时间从10ms缩短到2ms帧率会突然从60fps跳到70fps这个抖动会打乱ISP的帧调度导致延迟波动。手动曝光模式下曝光时间由AE算法在ISP侧控制sensor只负责输出固定帧率这样整个链路的时序就稳定了。代价是AE算法的响应速度会比sensor内置的慢一些但通过调快Imagiq的AE收敛步长可以弥补这个差距。最后说一个我们踩过的最深的坑——Imagiq的“帧跳过”机制。在低延迟模式下如果ISP的处理时间超过了帧间隔Imagiq会自动跳过下一帧的输入而不是让当前帧延迟输出。这个机制的本意是防止帧堆积但对于图传场景它会导致画面突然跳变。我们当时在测试中发现了这个问题但一开始没意识到是ISP在跳帧还以为是sensor丢帧了。后来在MIPI的抓包中看到sensor确实输出了每一帧但ISP的输出端口少了一帧。解决办法是把Imagiq的FRAME_SKIP_ENABLE寄存器关掉同时确保ISP的处理时间严格小于帧间隔。这需要精细的时序预算——我们当时把ISP的处理时间压到了12ms以内而60fps的帧间隔是16.7ms留了4.7ms的余量才敢关掉跳帧机制。个人经验性建议如果你在做无人机图传别一上来就追求ULTRA模式先把LOW模式调好把MIPI优先级和LP切换时间优化到位通常能拿到60-70%的延迟收益。ULTRA模式是最后的手段而且一定要在画质和延迟之间做权衡测试。另外MTK的Imagiq平台有个好处是它的策略引擎允许你通过调试接口实时调整参数不用重新编译内核——利用这个特性在产线上做动态调优比在开发板上死磕寄存器效率高得多。最后强烈建议在MIPI链路上加一个硬件时间戳模块用FPGA或者MCU记录每一帧的到达时间和输出时间这样在排查延迟问题时能快速定位是sensor、ISP还是传输链路的问题而不是靠猜。 031、无人机图传低延迟架构——联发科Imagiq的ISP低延迟模式与MIPI传输优先级控制
031、无人机图传低延迟架构——联发科Imagiq的ISP低延迟模式与MIPI传输优先级控制去年夏天在南方某无人机客户现场我们被一个“幽灵延迟”问题折磨了整整两周。飞手打杆图传画面大概滞后了120毫秒穿越机玩家根本没法飞。更诡异的是这个延迟不是固定的时大时小偶尔还会突然卡顿一下。我们用示波器量了MIPI的LP/HS切换用串口打了每个模块的时间戳最后发现罪魁祸首根本不是ISP处理速度不够而是Imagiq的帧调度器在“偷懒”——它把ISP的帧率锁在了30fps但sensor实际输出是60fps导致每一帧都在缓冲区里多等了半个帧周期。这就是典型的“平台默认策略”和“应用场景需求”打架的案例。联发科Imagiq的ISP架构和高通Spectra有个本质区别——它把很多控制逻辑做成了“策略引擎”而不是硬编码的寄存器序列。这意味着你可以在运行时动态调整ISP的行为模式但代价是如果你不主动告诉它你要什么它就按最保守的默认策略跑。对于手机拍照这个默认策略没问题甚至很聪明但对于无人机图传这个“聪明”恰恰是延迟的根源。先说Imagiq的低延迟模式。在MTK的ISP驱动里有个叫isp_latency_mode的接口接受三个值LATENCY_NORMAL、LATENCY_LOW、LATENCY_ULTRA。NORMAL模式就是默认的ISP会做完整的3A统计、多帧降噪、HDR合成等所有处理帧率完全由sensor的VSYNC驱动。LOW模式会跳过一些非必要的统计计算比如把AWB的统计窗口从全画面缩减到中心区域把AE的收敛速度调快——这些改动对画质影响不大但能省出大概3-4ms的处理时间。ULTRA模式更激进它会直接关闭部分ISP硬件模块的时钟门控比如关闭色彩校正矩阵的实时更新用上一帧的参数同时把降噪强度降到最低档。这个模式能再省5-6ms但画质会明显下降噪点会变多色彩也会偏一点。这里踩过坑——别在ULTRA模式下还开着HDR。我们当时为了追求极致低延迟把HDR和ULTRA同时打开了结果Imagiq的HDR合成模块和低延迟模式有冲突导致输出画面出现撕裂。查了半天最后发现是MTK的驱动代码里有个隐藏的依赖关系HDR合成需要至少两帧的缓冲而ULTRA模式把帧缓冲压缩到了一帧。这个坑在文档里完全没写是我们在抓MIPI的帧间隔时发现的。再说MIPI传输优先级控制。这是Imagiq比较有特色的地方——它的MIPI TX控制器支持多通道优先级调度。默认情况下所有数据通道是轮询调度的也就是round-robin每个通道轮流发送。但对于图传场景我们需要把ISP输出的YUV数据通道设为最高优先级把统计数据的通道比如3A的AE/AWB统计降为低优先级。这样做的原因是统计数据晚到几毫秒没关系但YUV数据晚到一帧整个图传链路就多了一帧延迟。具体实现上MTK的MIPI TX寄存器里有个MIPI_TX_PRIORITY_CTRL可以设置每个虚拟通道的优先级权重。我们当时把YUV通道的权重设为15最高把统计通道设为1最低把元数据通道设为8。改完之后延迟又降了大概2ms。但这里有个副作用——统计通道的数据被延迟后3A的收敛速度会变慢特别是在光照快速变化的场景下画面会短暂过曝或欠曝。解决办法是在低延迟模式下把3A的收敛速度调快用算法上的激进策略弥补数据到达的延迟。还有一个容易被忽略的点——MIPI的LP/HS切换时间。在低延迟模式下我们建议把MIPI的LP进入时间设到最短。MTK的MIPI TX有个LP_ENTRY_DELAY参数默认是100us我们把它调到了20us。这个参数影响的是当一帧数据发送完毕后MIPI链路进入低功耗状态LP的等待时间。如果这个时间太长下一帧数据到达时链路还在LP状态需要额外的时间切换回HS状态这个切换时间大约需要30-50us。虽然单次切换时间不长但累积起来一秒钟60帧就是3ms的额外延迟。这个参数在MTK的文档里标注的是“建议不要修改”但我们实测下来调到20us完全没有问题只是功耗会稍微增加一点。再讲一个更隐蔽的坑——sensor的曝光和ISP的帧同步。在低延迟模式下我们建议把sensor的曝光模式从“自动曝光”改成“手动曝光AE算法控制”。为什么因为自动曝光模式下sensor的曝光时间变化会直接导致帧率抖动。比如从暗处飞到亮处sensor的曝光时间从10ms缩短到2ms帧率会突然从60fps跳到70fps这个抖动会打乱ISP的帧调度导致延迟波动。手动曝光模式下曝光时间由AE算法在ISP侧控制sensor只负责输出固定帧率这样整个链路的时序就稳定了。代价是AE算法的响应速度会比sensor内置的慢一些但通过调快Imagiq的AE收敛步长可以弥补这个差距。最后说一个我们踩过的最深的坑——Imagiq的“帧跳过”机制。在低延迟模式下如果ISP的处理时间超过了帧间隔Imagiq会自动跳过下一帧的输入而不是让当前帧延迟输出。这个机制的本意是防止帧堆积但对于图传场景它会导致画面突然跳变。我们当时在测试中发现了这个问题但一开始没意识到是ISP在跳帧还以为是sensor丢帧了。后来在MIPI的抓包中看到sensor确实输出了每一帧但ISP的输出端口少了一帧。解决办法是把Imagiq的FRAME_SKIP_ENABLE寄存器关掉同时确保ISP的处理时间严格小于帧间隔。这需要精细的时序预算——我们当时把ISP的处理时间压到了12ms以内而60fps的帧间隔是16.7ms留了4.7ms的余量才敢关掉跳帧机制。个人经验性建议如果你在做无人机图传别一上来就追求ULTRA模式先把LOW模式调好把MIPI优先级和LP切换时间优化到位通常能拿到60-70%的延迟收益。ULTRA模式是最后的手段而且一定要在画质和延迟之间做权衡测试。另外MTK的Imagiq平台有个好处是它的策略引擎允许你通过调试接口实时调整参数不用重新编译内核——利用这个特性在产线上做动态调优比在开发板上死磕寄存器效率高得多。最后强烈建议在MIPI链路上加一个硬件时间戳模块用FPGA或者MCU记录每一帧的到达时间和输出时间这样在排查延迟问题时能快速定位是sensor、ISP还是传输链路的问题而不是靠猜。