企业官网建设流程全解析

同一相机画面同时推直播和录高清：HarmonyOS 7 一入二出编码怎么避免两路互相拖慢

先把现象说清楚

相机预览要同时生成一条低码率直播流和一条高清本地录制流。最直观的做法是复制每一帧给两个编码器，但复制开销、时间戳漂移和背压很快出现。HarmonyOS 7 的一入二出能力允许同一份视频输入驱动两个独立编码器，产生两路不同码流。真正需要设计的是两路输出各自的队列、失败与结束语义，而不是把它们当成一个编码任务的两个文件名。

写代码前先核对官方边界

问题为什么会发生

互相拖慢通常来自应用把两个输出放进同一个串行消费循环：直播网络写入阻塞时，本地录制也拿不到下一个输出；或者两个回调共用同一可变缓冲区，慢支路读取到已被覆盖的数据。输入可以共享，输出所有权、队列和完成条件必须分离。

下面的纯 TypeScript 代码是应用侧决策模型，用来验证分支和状态，不是对平台 Native API 的替代：

type Branch='stream'|'record'; type BranchState={queued:number;dropped:number;failed:boolean}; function admit(branch:Branch,s:BranchState):'push'|'drop'|'stop'{ if(s.failed)return 'stop'; if(branch==='stream'&&s.queued>3)return 'drop'; if(branch==='record'&&s.queued>8)return 'stop'; return 'push'; } if(admit('stream',{queued:5,dropped:0,failed:false})!=='drop')throw new Error('直播背压未生效');

案例一：直播允许丢非关键帧，录制不允许静默缺口

直播追求实时性，积压后可以按策略丢弃可丢帧并请求后续关键帧；本地录制追求文件连续性，队列超过预算应显式停止并上报，而不是悄悄丢帧。两路输出使用不同阈值，统计中分别记录丢帧、编码错误和写入错误。

案例二：直播提前结束，录制继续完成尾段

用户关闭直播但仍要保留本地录像时，只关闭直播输出及其网络资源，输入和录制输出继续。总任务只有在两路都进入终态后才释放共享输入；若先释放输入，录制尾段会损坏。页面显示也要区分“直播已结束”和“录制已保存”。

平台接入骨架

下面代码只保留与本文问题直接相关的调用顺序。实际工程要按当前官方头文件、错误码和设备能力补齐，不把示意函数当成已经在本机 API 26 编译通过的产物。

struct OutputState { bool active; int queued; int64_t lastPts; }; struct DualOutputState { OutputState stream; OutputState record; bool inputActive; }; void stopBranch(DualOutputState& s, bool stream) { OutputState& branch = stream ? s.stream : s.record; branch.active = false; if (!s.stream.active && !s.record.active) s.inputActive = false; }

为什么选择这套方案

一入二出减少应用重复组织输入的复杂度，但不等于两个输出没有独立成本。若设备能力不足，应优先降低直播规格或退回单路录制；不要承诺“零拷贝”或“性能翻倍”，这些必须由目标设备数据证明。

验证矩阵

• 两路正常：PTS 单调且来自同一输入时钟
• 直播网络阻塞：录制文件仍连续
• 直播停止：录制继续并正确收尾
• 录制写盘失败：直播根据产品策略继续或提示
• 页面退出：等待两路终态后只释放一次输入

以后如何避免同类问题

以后把每路输出当成独立状态机，输入只负责产生带版本和时间戳的帧。任何共享缓冲区都写清所有权与归还时机，禁止两个异步消费者同时修改。

验证范围与证据边界

本文先以华为开发者官网当前文档确认能力范围、起始版本、设备差异和资源释放要求，再用纯 TypeScript 状态模型验证参数、状态转移和失败回退。状态模型能证明应用侧分支是否自洽，不能替代 HarmonyOS 7 / API 26 编译、设备能力查询、Native 链路运行或双真机协同。

当前本机 SDK 为 API 24，且没有已连接的 HDC 设备。因此文中的 API 26 平台代码属于按官方接口整理的接入骨架，不写成“本地已编译”或“真机已经跑通”。真正验收时需要记录 DevEco Studio 与 SDK 版本、设备型号、系统版本、输入文件或网络条件、接口返回值、关键日志、前后台切换、异常注入、资源释放和结果截图。涉及画质、帧率、时延、功耗或跨设备连接的结论，还要在支持该能力的设备上重复测量。

示例不会把预期结果冒充观测结果。宿主断言、API 26 编译、模拟器、云真机和实体设备分别记录；其中任一层没有证据，就明确保留为待验证项。

可复用的工程边界

页面只提交业务意图，不直接维护 Native 句柄、编码器、ImageSource、相机会话、跨设备 sessionId 或 ArkWeb 性能采样器。能力适配层负责系统接口和错误码，编排层维护状态机、超时、取消、资源预算与降级，页面订阅只读状态。这样做的价值不是多包一层，而是让重复点击、页面销毁、设备能力不同和半途失败都能回到同一套收口逻辑。

所有日志只记录阶段、配置摘要、耗时和错误码，不记录原始图片、视频帧、跨设备消息正文或用户页面内容。生产环境还需要采样、脱敏和容量限制。

上线前检查表

• 先确认官方文档更新时间、起始 API、设备类型和系统能力，不用接口存在代替运行支持。
• 两个案例必须覆盖不同失败机制，一个验证主链路，一个验证资源、并发、生命周期或设备差异。
• 每个异步阶段都能取消，页面退出后不会继续回调旧页面，资源释放顺序可重复执行。
• 失败时保留阶段和错误码，增强能力失败能回到可用基础路径，不让页面卡死或黑屏。
• 文章中的代码、图和结论使用同一组状态名，避免示意图与实现逻辑相互矛盾。
• 真机验收记录输入、操作、观测和环境，不用“看起来正常”作为唯一结果。

参考资料

1. 视频编码一入二出

2. 视频编码典型场景配置

3. 2026 年 6 月开发者月刊