展厅视频编码与封装怎么选（H.264 / H.265 / HAP）

选择展厅编码应从目标播放器与硬件支持开始，再比较同一内容的画质、峰值负载和完整运行结果。MP4、MOV是容器，H.264、H.265、HAP是编码家族；文件后缀不能证明解码路径、透明通道或同步能力。

先把旧的简单判断改成可验证条件

CPU占用低不等于硬解已生效，GPU的Video Decode曲线有活动也不能单独证明这一条流正走预期路径。HAP的纹理处理与常规视频解码引擎不同，不能要求它必须表现为Video Decode抬升。应结合播放器日志、实际选中的解码器、GPU引擎与输出帧时间核对。

同画质下H.265可能节省数据量，但收益受画面、编码器、参数和主观质量目标影响；不能保证每个文件都减半。HAP面向图形硬件高效处理的纹理格式，CPU仍可能参与数据解包、上传和调度。文件变大也不自动带来严格同步，编码选择与时钟、调度及刷新是不同问题。

把格式对照改成待验证矩阵

候选	适合拿来验证的问题	必须填写的条件	本轮目标硬件结果
H.264	通用交付候选是否满足画质与解码要求	profile、level、位深、像素格式、分辨率、帧率	未测
H.265	在相同审阅目标下能否减少数据量	同上，另确认实际软硬解实现与并发能力	未测
HAP及其变体	纹理路径、多层或透明工作流能否受益	变体、容器、分块、存储吞吐、播放器实现	未测

这里没有测试某型号GPU，也没有给出通用推荐电脑。本地工具为FFmpeg 8.0.1和Python 3.12.4，仅生成原创短样片并完成软件解码；目标机CPU、GPU、驱动、播放器版本与输出模式需另填。十秒样片能验证初步兼容，不能代替完整片和长时间循环。

实际导出与验收顺序

1. 保留制作母版，登记摘要和全部流信息。先核宽高、时间基、声道、范围、色域和方向，不要先批量转码掩盖异常。
2. 为目标机导出两种候选，固定内容、帧率与画质审阅点，记录编码器完整参数；比较不是只看文件大小。
3. 用软件完整解码检查损坏、警告与末端读取。通过后才做目标机实时回放，记录实际解码路径和帧时间。
4. 覆盖最重场景、并发路数、循环边界与声音路径。任何转换后都重算摘要，不用改后缀冒充转换。

具体时间戳问题按VFR与CFR证据核对处理；发灰或暗部丢失按全范围与有限范围测试隔离；中途卡住先做完整解码预检。透明输出另见Alpha播放实现，不能从容器名推断。

如何保留原始证据

下载本地原创样片完整解码回执。它含FFmpeg命令、退出码、帧数和摘要，证明本轮仅对原创短片完成本地软件读取；不证明正式影片、硬解、四路4K或显示端通过。实际测试应填素材摘要、版本、解码器、音频路径、总时长和异常点，并保留日志原件。

若候选离线通过但现场卡顿，继续查实时负载而非宣布文件损坏；若只某账号失败，查依赖与路径；若透明区黑块，检查Alpha是否存在以及合成方式，不把所有异常归咎于格式。CPU超过某一固定百分比也不是通用不合格门槛。

一级来源

核对日期2026-10-23：FFmpeg ffprobe文档说明流与帧字段；HAP官方主页与HAP格式草案说明格式及实现背景。厂商的格式定位与本项目实测结果必须分别登记。