鸿蒙直播推流延迟压到 300ms 以内：采集流类型、GOP 和码控模式的联合调优

团队在做一款连麦直播应用，鸿蒙端推流上线后，观众端反馈“主播说句话，弹幕要过一会儿才跟上”。端到端延迟实测在 800ms~1.2s 之间波动，离“可连麦互动”的体验标准差得很远。排查了一周，发现问题不在网络，而在采集侧的流类型选错、编码侧的 GOP 和码控模式没有按低延迟场景配，以及推流前的一级缓冲没有收窄。调整之后端到端延迟稳定在 280ms~350ms，记录一下完整的调优路径。

一、采集侧：OHAudio 的流类型决定了延迟下限

鸿蒙的音频采集走 OHAudio 接口时，OH_AudioStream_SourceType 的选择直接影响采集链路的处理深度。我们最初用的是常规录音 AUDIOSTREAM_SOURCE_TYPE_MIC，它支持 48kHz 双声道，但不具备回声消除等 3A 能力，所以为了连麦场景的 AEC，又在应用层串了一套软件 3A，白白增加了处理延迟。后来切到直播录音专用的 AUDIOSTREAM_SOURCE_TYPE_LIVE，它在保持 48kHz 高保真的同时内置了适配直播场景的前处理，采集到编码的链路缩短了一截。如果业务是纯单向直播、不需要 AEC，MIC 类型反而更轻；但连麦场景下流类型选错，后面再怎么调编码都补不回来。

二、编码侧：GOP 不是越大越省，码控模式决定延迟形态

视频编码原来用的是默认的 VBR 码控，GOP 设了 60 帧。VBR 在画面平稳时码率低、画面复杂时码率飙升，网络缓冲随之膨胀，延迟跟着抖动。低延迟直播场景的推荐做法是固定码率 CBR 配合短 GOP。鸿蒙 AVCodec 的典型低延迟配置中，720p/30fps 的场景接入帧间隔（GOP 时长）推荐在 1 秒以内，1080p 同样是 1 秒量级，码控模式统一选 CBR。我们把 GOP 从 60 帧压到 30 帧（1 秒），码控切到 CBR，码率按 720p 档位锁在 1Mbps 左右，推流端的发送节奏立刻变得均匀，网络缓冲不再忽大忽小。

还有一个容易忽略的点：GOP 间隔在 AVCodec 中不支持运行时动态修改，OH_MD_KEY_I_FRAME_INTERVAL 只能在 Configure 阶段设定。所以如果业务需要根据网络状态动态调整关键帧密度，正确姿势是初始化时把自动插入设为关闭，运行中通过 OH_MD_KEY_REQUEST_I_FRAME 在需要时主动请求 IDR 帧，而不是试图去改 GOP 参数。

三、推流前的一级缓冲：收窄而不是取消

推流模块初始版本为了抗网络抖动，在编码输出和 RTMP 发送之间加了一个 200ms 的固定缓冲队列。这个缓冲在弱网下确实有用，但在正常网络下是纯粹的延迟累加。改成动态缓冲：基线 60ms，根据 RTMP 发送队列的积压深度在 40ms~200ms 之间浮动，网络平稳时贴近下限，检测到 RTT 上升或发送队列持续积压时才逐步放大。这一刀又砍掉了约 140ms 的常态延迟。

四、结果与总结

三条线叠加之后，端到端延迟从 800ms~1.2s 稳定到 280ms~350ms。总结下来：连麦场景音频流类型首选 LIVE，视频编码用 CBR + 1 秒级 GOP，推流缓冲做成动态而非固定。鸿蒙 AVCodec 的硬件编码能力本身没有问题，延迟往往藏在“默认配置”和“过度保护”里。