014、运动相机低功耗低延迟架构：从Sensor到WiFi图传的功耗优化实战

014、运动相机低功耗低延迟架构从Sensor到WiFi图传的功耗优化实战昨晚在实验室调一块基于瑞芯微RV1126的运动相机板子客户反馈一个诡异现象4K30录像WiFi预览时整机电流从标称的680mA一路飙到1.2A而且图传延迟从80ms劣化到300ms以上。用热成像一扫WiFi模组附近直接烫到能煎鸡蛋。这不是个案运动相机这种形态电池就那么大功耗和延迟永远是一对死对头。今天把这几年在安霸、海思、瑞芯微平台上折腾低功耗图传的笔记翻出来挑几个最要命的点说说。先说Sensor侧。很多人一上来就盯着ISP和CPU降频其实功耗大头往往在Sensor的MIPI速率和输出格式上。运动相机常用索尼IMX377、IMX577这类背照式Sensor默认输出是10bit RAW但如果你只是做图传预览根本不需要10bit。把Sensor配置成8bit RAW输出MIPI lane数从4lane降到2lane这一下就能省掉30-50mA。别小看这几十毫安在整机680mA的预算里这就是5%以上的收益。但这里有个坑Sensor的8bit模式往往和10bit模式在HDR合成、坏点校正上有差异你得在ISP端把对应的处理链路切过来否则画面会出现奇怪的banding。我见过有工程师直接改dts里的lane数结果预览画面全是横条纹查了一下午才发现是Sensor端没同步切bit depth。再往ISP走。瑞芯微的RKISP1/RKISP2海思的VI-VPSS安霸的A12/A15各家都有个“低功耗预览模式”的概念。本质上是把ISP的pipeline拆成两路一路走全尺寸拍照/录像一路走缩小的预览图。但很多人的做法是直接复用主链路只是把输出分辨率改小这等于让ISP全速跑然后丢数据。正确做法是让ISP进入“裁剪缩放”的旁路模式跳过3A统计、跳过HDR合成、跳过降噪模块只做最基础的Bayer到YUV转换。以海思Hi3559为例VPSS的GROUP里有个“USER_FRAME”模式可以只跑缩放通道不跑增强通道这个模式下ISP功耗能降40%。但代价是预览画面的噪声会明显所以你得在WiFi编码前加一层轻量级的时域降噪别用空域降噪那个在低功耗模式下计算量反而更大。编码器这块是重灾区。运动相机的图传通常用H.264 Baseline Profile分辨率720p或1080p帧率30fps。很多人图省事直接调用硬件编码器但没注意编码器的“码率控制模式”对功耗的影响。VBR模式可变码率在画面复杂时码率飙升编码器频率跟着拉高功耗直接翻倍。CBR模式恒定码率虽然码率稳定但编码器为了维持码率在复杂场景下会强制提高QP画质变差而且功耗也不低。我现在的做法是图传链路用“低延迟CBR固定QP”的混合模式把码率上限卡死在4MbpsQP固定在28-32之间这样编码器始终工作在低负载区间功耗稳定。安霸平台上有专门的“Low Latency Encoder”配置瑞芯微的MPP库里有“ENC_CTRL_LOW_DELAY”标志海思的VENC有“H264E_PROFILE_LOW_DELAY”这些都是为图传场景准备的但默认都是关闭的你得手动打开。WiFi图传的功耗和延迟是整个链路里最玄学的部分。很多人以为WiFi模块的功耗只跟发射功率有关其实跟“发包策略”关系更大。运动相机用的是WiFi模块比如瑞昱RTL8811、乐鑫ESP32-WROOM这些模块在TCP/IP协议栈上的处理方式直接决定了功耗。默认情况下模块会启用“TCP_NODELAY”和“Nagle算法”的折中但图传数据是UDP流根本不需要TCP的确认机制。你把WiFi模块切到“UDP直通模式”绕过TCP/IP协议栈让视频流直接走MAC层封装延迟能从150ms降到60ms功耗能省20%。但这么做有个风险UDP丢包后没有重传画面会花屏。所以你得在编码器端做“关键帧间隔”控制比如每30帧插一个I帧这样即使丢包最多花1秒就能恢复。另外WiFi模块的“省电模式”要慎用——默认的PSM模式Power Save Mode会在空闲时休眠但图传是持续发包休眠反而导致频繁唤醒功耗比不休眠还高。正确做法是关闭PSM但把DTIM间隔调大让模块在无数据时自动降频。还有一个容易被忽略的功耗点DDR带宽。运动相机的Sensor数据、ISP处理、编码器读取、WiFi DMA全都要过DDR。如果DDR频率跑在最高档功耗直接占整机的15%以上。但DDR频率又不能随便降降了带宽不够ISP和编码器会互相抢带宽导致卡顿。我的经验是用瑞芯微的“DVFS”和“DDR QoS”机制把Sensor写入DDR的带宽优先级设为最高编码器读取设为次高WiFi DMA设为最低。这样即使DDR频率降一档关键数据流也不会被阻塞。海思平台上有“DDRC_PERF_CTRL”寄存器可以设置不同Master的优先级安霸的“MemGuard”工具也能做类似的事。但要注意这个优先级设置不能一刀切得根据实际分辨率、帧率、码率动态调整否则在4K录像图传同时跑时DDR带宽会爆。最后说一个系统级的坑CPU调频策略。运动相机的图传链路CPU负载其实不高主要工作在中断处理和协议栈。但默认的Linux内核调频器如ondemand、interactive会把CPU频率拉到最高然后发现没活干再降下来这个“拉高-降下”的过程本身就费电。正确做法是把图传相关的CPU核心固定在中等频率比如1.2GHz然后关闭其他核心的自动调频。瑞芯微平台上有“cpufreq”的“userspace”模式你可以自己写一个简单的调频脚本根据WiFi模块的FIFO水位来动态调整频率。海思的“hisi_thermal”框架里也有类似机制。但别用“performance”模式那个会让CPU一直跑最高频功耗直接多100mA。总结一下这几年的实战经验运动相机低功耗图传的核心不是某一个模块的极致优化而是“Sensor输出格式、ISP旁路模式、编码器码率控制、WiFi发包策略、DDR优先级、CPU调频”这六个环节的协同。每个环节单独优化可能只省20-30mA但串起来就能从1.2A降到700mA以内延迟也能稳定在80ms以下。另外量产时一定要做“功耗-温度-延迟”的联合测试因为WiFi模块在高温下会自动降功率导致延迟飙升这个在实验室里很难复现得放到高温箱里跑。最后给个建议别迷信芯片原厂的“低功耗参考设计”那些方案往往只针对单一场景运动相机的“录像图传传感器融合”这种复合场景必须自己动手调。而且每次改完一个参数都要用电流探头和网络分析仪同时抓数据别只看电流表——有时候电流降了但延迟劣化了这种“假优化”在量产时会被客户骂死。