HarmonyOS鸿蒙Next中OH_VideoEncoder surface输入模式下低延迟配置与sync mode均开启后，编码器内部仍稳定约80ms延迟，是否有降低surface pipeline缓冲的方法

HarmonyOS鸿蒙Next中OH_VideoEncoder surface输入模式下低延迟配置与sync mode均开启后，编码器内部仍稳定约80ms延迟，是否有降低surface pipeline缓冲的方法

问题背景

我们在做鸿蒙端屏幕投屏/录屏编码场景，目标是实时投屏，期望尽量降低画面更新延迟。

当前主要链路如下：

OH_AVScreenCapture
  -> OH_AVScreenCapture_StartScreenCaptureWithSurface
  -> NativeImage / GLES scaler
  -> OH_VideoEncoder_GetSurface() 得到的 encoder input surface
  -> H.264 编码输出
  -> 网络发送

现在遇到的问题是：在 surface 输入模式下，帧已经提交到 encoder input surface 之后，到编码器输出 buffer ready 之间存在稳定约 70-90ms 的延迟。这个延迟看起来不是 GLES 渲染、业务线程转发、网络发送造成的，而更像编码器 surface pipeline 内部缓存了一帧或多帧。

环境信息

• 设备 1：HUAWEI Mate 60
• 设备 2：HUAWEI Mate 60 Pro
• 编码格式：H.264 / AVC
• 输入模式：surface input
• 分辨率示例：976x2160
• 业务场景：实时屏幕投屏 / 录屏编码

已配置的编码参数

目前已经尝试设置低延迟相关参数：

OH_MD_KEY_FRAME_RATE
OH_MD_KEY_PIXEL_FORMAT = AV_PIXEL_FORMAT_SURFACE_FORMAT
OH_MD_KEY_BITRATE
OH_MD_KEY_VIDEO_ENCODE_BITRATE_MODE
OH_MD_KEY_PROFILE = AVC_PROFILE_BASELINE
OH_MD_KEY_I_FRAME_INTERVAL

OH_MD_KEY_VIDEO_ENABLE_LOW_LATENCY = 1
OH_MD_KEY_VIDEO_ENCODER_ENABLE_TEMPORAL_SCALABILITY = 0
OH_MD_KEY_VIDEO_ENCODER_ENABLE_B_FRAME = 0
OH_MD_KEY_VIDEO_ENCODER_ENABLE_PTS_BASED_RATECONTROL = 1

也尝试过 sync mode：

OH_MD_KEY_ENABLE_SYNC_MODE = 1
OH_VideoEncoder_QueryOutputBuffer(...)
OH_VideoEncoder_GetOutputBuffer(...)

延迟统计口径

我们在每帧上记录了几个阶段耗时：

sourceToEncoderInputMs: 采集帧可用到提交 encoder input surface
sourceToPacingMs: 采集帧可用到进入 pacing
pacingWaitMs: pacing 等待耗时
renderToSwapMs: GLES 渲染到 swap 的耗时
swapToEncoderInputMs: swap 后到记录 encoder input submitted 的耗时
encoderPipelineMs: encoder input submitted 到 encoder output buffer ready 的耗时
encoderOutputToWorkerMs: output ready 到业务线程处理的耗时
workerToSharedSinkMs: 编码输出进入业务 sink 的耗时
packetizeMs: 分包耗时
sendQueueWaitMs: 网络发送队列等待耗时
sendElapsedMs: 实际发送耗时

这里最关注的是：

encoderPipelineMs = encoder input submitted -> encoder output buffer ready

日志现象

设备 1：callback 输出模式

统计结果大致如下：

frames=698
encoderPipelineMs count=697 avg=74.0 min=64 p50=73 p90=80 p95=82 max=97
swapToEncoderInputMs count=697 avg=3.9 min=0 p50=4 p90=6 p95=7 max=24
sendQueueWaitMs count=698 avg=1.2 min=0 p50=1 p90=3 p95=6 max=17
sendElapsedMs count=698 avg=0.0 min=0 p50=0 p90=0 p95=0 max=0

可以看到 encoderPipelineMs 稳定在 70-80ms 左右，而提交 encoder surface 前后的耗时、发送队列耗时和实际发送耗时都很低。

设备 2：sync mode 确认启用

日志确认 sync mode 已经启用：

video encoder latency test config: singleInFlight=0, syncMode=1, dataBufferInput=0, frameDuplication=0, maxInputBuffers=0, maxOutputBuffers=0
video encoder sync-mode options: requested=1, keyAvailable=1, queryOutputAvailable=1, getOutputAvailable=1, enabled=1
video encoder sync-mode configured: setOn=1, queryTimeoutUs=50000
video encoder sync output queried: ...

过滤掉一次 1071ms 离群值后，encoderPipelineMs 仍然没有明显下降：

encoderPipelineMs count=72 avg=82.2 min=15 p50=83 p90=87 p95=89 max=93
sourceToEncoderInputMs count=73 avg=5.2 min=3 p50=5 p90=7 p95=8 max=13
swapToEncoderInputMs count=73 avg=1.9 min=0 p50=2 p90=3 p95=4 max=5
encoderOutputToWorkerMs count=73 avg=2.6 min=0 p50=0 p90=2 p95=14 max=45
sendElapsedMs count=74 avg=0.0 min=0 p50=0 p90=0 p95=0 max=0

也就是说，sync mode 确实让 output ready 后的取帧和线程转发更快了，但没有降低 encoder input surface -> output buffer ready 这段内部延迟。

已尝试和排查过的方案

1. 开启低延迟参数：OH_MD_KEY_VIDEO_ENABLE_LOW_LATENCY = 1。
2. 禁用 B 帧：OH_MD_KEY_VIDEO_ENCODER_ENABLE_B_FRAME = 0。
3. 使用 H.264 baseline profile。
4. 禁用 temporal scalability。
5. 开启 PTS based rate control。
6. 尝试 sync mode，用 QueryOutputBuffer/GetOutputBuffer 主动 drain 输出。
7. 上游限制 in-flight frame，避免应用层继续堆旧帧。
8. 排查发送队列和网络发送耗时，确认不是网络层造成。

当前判断

从日志看，主要延迟集中在编码器内部：

encoder input surface submitted -> encoder output buffer ready

sync mode 只改变 output buffer 获取方式，能降低 output ready 之后的取帧/分发等待，但没有改变 surface 输入到编码输出 ready 的内部 pipeline latency。

因此目前怀疑 surface input 模式下，硬编内部可能存在固定 pipeline 缓冲深度，或者低延迟参数没有完全影响 surface input 的内部排队策略。

想请教的问题

1. OH_VideoEncoder 在 surface input 模式下，是否存在固定的内部 pipeline 缓冲深度？例如必须缓存 1-2 帧后才输出？
2. OH_MD_KEY_VIDEO_ENABLE_LOW_LATENCY 对 surface input 模式是否一定生效？是否有额外前置条件？
3. sync mode 是否只影响 output buffer 获取方式，而不改变编码器内部输入到输出的排队深度？
4. 是否有官方推荐的参数组合，用于实时投屏/录屏编码低延迟场景？
5. OH_MD_MAX_INPUT_BUFFER_COUNT / OH_MD_MAX_OUTPUT_BUFFER_COUNT 是否支持用于降低 surface 模式下的内部缓冲？如果支持，推荐值是多少？
6. 如果目标是实时投屏，是否建议从 surface input 改为 data buffer input？两者在编码延迟上是否有已知差异？
7. 有没有方法可以强制 encoder 在 surface 输入模式下“收到一帧尽快输出一帧”，避免稳定 80ms 左右的 pipeline latency？

期望

希望确认这是否是当前鸿蒙硬编 surface 模式的预期行为，还是我们的参数使用方式不完整。如果有推荐的低延迟配置、设备能力查询方式或最小复现写法，也希望能提供建议。