为什么低延迟在视频编码中这么重要
直播打游戏、远程会议、在线教育，这些场景对实时性要求极高。你说话的瞬间，对方如果要等半秒才听到，体验就大打折扣。核心问题往往出在视频编码环节——数据从摄像头采集到网络传输之间，处理越慢，延迟越高。
降低视频编码延迟不是简单调个参数就行，得从编码策略、硬件利用和协议配合多方面下手。
关键：减少帧排队和处理时间
传统编码为了压缩率，会把多个视频帧放在一起分析，比如B帧依赖前后帧做预测。这虽然省带宽，但必须等后续帧到了才能编码当前帧，自然拖慢速度。想要低延迟，第一件事就是关掉B帧，改用全I帧或I+P帧结构。
比如你在做实时连麦，开启B帧可能让延迟增加50ms以上。而设置为I/P-only模式，每一帧都能独立编码发出，处理链路更短。
编码参数调优示例
x264 --keyint 30 --bframes 0 --no-scenecut --preset ultrafast input.yuv output.h264这里 bframes=0 禁用了B帧，preset 设为 ultrafast 让编码器优先速度而非压缩效率，虽然文件稍大，但延迟明显下降。
使用硬件加速编码
CPU软编虽然灵活，但在高分辨率下处理压力大，容易堆积帧。现代GPU都内置专用编码单元，比如NVIDIA的NVENC、Intel的Quick Sync、AMD的VCE，能并行处理多路视频而不占用太多CPU资源。
拿OBS直播举例，默认用x264软编，1080p 60fps可能吃掉一半CPU；换成NVENC后，CPU占用降到10%以内，编码延迟也从40ms降到15ms左右，画面更跟手。
FFmpeg调用GPU编码示例
ffmpeg -i input.mp4 -c:v h264_nvenc -preset llhq -profile:v high -b:v 5M -f flv rtmp://live.example.com/stream其中 llhq（low latency high quality）是NVENC提供的低延迟模式，专为实时推流优化。
减小GOP长度和启用实时打包
GOP（Group of Pictures）是一组连续帧的集合。GOP越长，压缩率越高，但首帧等待时间也越久。直播通常设为1秒内的GOP，比如25帧/s就设keyint=25，确保每秒至少一个I帧。
同时，封装格式也要配合。MP4这类文件格式需要写头信息，不适合实时流；改用FLV或MPEG-TS，边编码边推送，几乎无额外延迟。
选择适合的编码标准和协议组合
H.264普及度高，兼容性强，是目前低延迟场景的主流选择。H.265压缩更好，但编码耗时更长，除非带宽特别紧张，否则不推荐用于实时互动。
传输协议也很关键。RTMP虽然常见，但默认有几秒缓存；WebRTC才是真正的毫秒级选手，端到端延迟可控制在200ms内，适合远程控制、云游戏这类极端场景。
比如你在开发一个远程维修指导系统，工人戴AR眼镜，专家通过手机查看现场画面。用WebRTC传H.264流，配合I帧优先编码，整个链路延迟能压到300ms以内，指点动作基本同步。
合理控制分辨率与帧率
不是所有场景都需要4K 60fps。移动端会议看1080p没问题，但如果是无人机图传，720p 30fps足够，还能大幅降低编码负载。
动态调整码率也是一种手段。网络差时自动降清晰度，避免缓冲积压，保持流畅性比画质更重要。很多SDK如libyuv、Medooze都支持运行时参数调整。