181、无人机航拍图传链路的系统级优化——从sensor曝光到编码输出的端到端延迟预算与码率自适应策略去年夏天在西北某戈壁滩试飞，客户报了个邪门问题：飞机悬停时图传画面一切正常，一旦推杆猛飞，画面就开始“果冻化”——不是单纯的卡顿，是那种整个画面像果冻一样颤巍巍地扭动，伴随间歇性花屏。当时我们第一反应是射频干扰，换了5.8G频段、调了发射功率，屁用没有。后来把黑匣子里的sensor曝光时间、ISP帧率、编码器码率、链路RTT全部拉出来对齐时间戳，才看出门道：问题根本不在无线侧，而在sensor曝光与编码器输入帧率之间的“节奏错位”。无人机航拍图传链路，从光子打到sensor到屏幕点亮，中间要过曝光、读出、ISP处理、编码、射频发送、地面接收解码、显示渲染，这七八个环节每个都有自己独立的时钟域。sensor曝光由快门控制，ISP按帧中断工作，编码器按输入buffer的填充水位启动，射频模块按802.11或私有协议的时隙发包——四个时钟域互相之间没有任何同步机制，全靠“运气”对齐。飞手猛推杆时，云台姿态剧烈变化，sensor为了防拖影会自动缩短曝光时间，帧率从30fps跳到60fps，但ISP和编码器还按30fps的节奏在跑，于是编码器每两帧才拿到一帧新数据，另一帧是ISP重复输出的旧帧——这就是果冻感的直接来源。端到端延迟预算这事，很多人以为就是“sensor曝光时间+ISP处理时间+编码时间+传输时间”的简单加法。实际量产调试中，这个加法根本算不准，因为每个环节的延迟不是固定值，而是随场景动态变化的。sensor曝光时间在强光下可能只有1ms，暗光下能拉到30ms；ISP的3A统计窗口要等整帧数据收完才开始算，这个等待时间等于曝光时间+读出时间；编码器的H.264