HarmonyOS Hardware Decode Research

1. 关键发现

截至 FFmpeg 官方 master 3acec0a1af2dda0a0838689b8b8649e7deb080a0（2026-08-28），upstream 已包含 OpenHarmony Codec：

configure：--enable-ohcodec
hw device：AV_HWDEVICE_TYPE_OHCODEC
pixel format：AV_PIX_FMT_OHCODEC
public device context：AVOHCodecDeviceContext.native_window
decoder/encoder：h264_oh、hevc_oh
SDK linkage：native_media_vdec、native_media_venc、native_media_codecbase、native_media_core、native_window

其 surface 路径把 OHNativeWindow * 放入 hw device，FFmpeg 配置 AV_PIXEL_FORMAT_SURFACE_FORMAT，并在 AVFrame release 时调用 OH_VideoDecoder_RenderOutputBuffer()。因此“不存在 FFmpeg Harmony hwcontext”已不是事实；当前缺口主要转移到 MPV 对 OHCODEC 的识别、Surface 所有权和呈现同步。

2. Codec 矩阵

Codec	Harmony Native Support	FFmpeg Support	MPV Support	Surface Decode	Pixel Format	Copy	Zero Copy Feasibility	10-bit / HDR	Known Limitation	Complexity
H.264	Native decoder API 存在；具体 profile/4K 由设备 capability 查询	`h264_oh` 已在 upstream master	无 OHCODEC 映射/backend	已实现	`AV_PIX_FMT_OHCODEC` / surface format	解码器到 Surface 可避免 CPU frame；是否经过系统内部 copy 不可见	高，但直出播放 Surface 与 MPV shader/字幕合成冲突	设备查询；H.264 10-bit 通常不作为首要目标，不能猜	FFmpeg 实现新、MPV 未接入、字幕/OSD 合成路径未解决	高
HEVC	Native decoder API 存在；profile/level/10-bit 待设备查询	`hevc_oh` 已在 upstream master	无 OHCODEC 映射/backend	已实现	同上	同上	高	Main10/HDR 必须按真机 capability + 实际流验证	HDR metadata 传递和 Surface colorspace 未证明	高
AV1	SDK API 可按 MIME 查询，不代表设备必有硬件	当前 OHCodec backend 未声明 `av1_oh`	无	FFmpeg OH 路径无	无	未定	未定	未定	upstream FFmpeg 尚未接 OH AV1	很高
VP9	SDK API可查询，不代表设备必有硬件	当前 OHCodec backend 未声明 `vp9_oh`	无	FFmpeg OH 路径无	无	未定	未定	未定	upstream FFmpeg 尚未接 OH VP9	很高

3. MPV 缺口

video/fmt-conversion.c 没有 IMGFMT_OHCODEC <-> AV_PIX_FMT_OHCODEC。
video/decode/vd_lavc.c 尚无 OHCODEC device/backend 选择。
GPU interop driver 列表没有 Harmony/OHNativeBuffer 路径。
libmpv OpenGL Render API的目标 Surface与 OHCodec 直接输出 Surface存在所有权冲突：同一个播放画面若让 decoder 直接呈现，MPV 的 shader、OSD、ASS 字幕、色彩管理无法自然叠加。
FFmpeg 当前 OHCodec surface frame 在 AVFrame release 时触发呈现，呈现时钟、drop/late frame 与 MPV VO 调度需要逐帧语义验证。

4. 推荐路线

Stage 1：软件解码基线

先以 FFmpeg software decode + libmpv GLES Render API 跑通首帧、Seek、字幕、网络和稳定性。该基线用于证明其后优化收益。

Stage 2：FFmpeg OHCodec 可用性验证

独立验证官方 h264_oh / hevc_oh：创建 decoder、Flush/Seek、Surface destroy/recreate、4K、高码率、Main10；记录设备 capability。此阶段不修改 MPV 大量代码。

Stage 3：选择合成架构

路线 3A，直接 Surface decode：最快接通、copy 少，但 MPV GPU shader/ASS/OSD 不能直接叠加。只适合验证硬解吞吐，不直接定为正式架构。
路线 3B，OHNativeBuffer/GPU import：decoder 输出可导入 GLES/Vulkan，再由 MPV/libplacebo 合成。最符合最终产品，但 FFmpeg 当前 OHCodec API是否暴露可导入 buffer 尚需源码和真机证明。
路线 3C，双 Surface/system overlay：视频与字幕分层，由系统合成。同步、HDR、截图和滤镜语义复杂，仅作备选。

正式路线优先研究 3B；在其不可行证据充分前，不宣称零拷贝。

5. Patch 边界

如进入实现，优先局限在：

video/fmt-conversion.c / image format 定义
video/decode/vd_lavc.c 的 hw device 选择
video/out/hwdec/hwdec_ohcodec.c 或明确命名的 Harmony interop driver
meson.build Harmony feature gate

任何不支持格式明确返回 unsupported；不得以 CPU 黑帧、fake success 或注释掉检查伪装完成。

6. 当前判定

不创建 Velix-FFmpeg-Harmony。 官方 FFmpeg 已有关键 OHCodec 基础，Phase 1 应固定官方 commit 并先编译；只有真实 blocker 证明需要 patch 且无法快速 upstream 后，才建立独立 FFmpeg fork。AV1、VP9、buffer import、HDR metadata 仍为 NEED VERIFY。

4.6 KiB Raw Blame History Unescape Escape