一条 FFmpeg 命令在终端执行成功，与一个转码服务可靠地交付结果之间，还隔着输入验证、资源管理、进程生命周期、产物检查和发布顺序。最典型的问题是：进程退出码为零，但播放器无法切换清晰度；任务已经超时，旧进程却继续写输出。
本篇沿用基础篇的六十秒测试图和音频，生成 360p、540p、720p 三档 HLS，并把媒体处理过程接入一个 Java 21 最小执行器。它展示一个本地任务的管理边界，分布式调度和幂等由可靠性篇继续展开。
先定义输出契约，再组合命令
“高清、标清、流畅”是产品名称，无法直接约束编码器。输出契约应明确分辨率、帧率、编码、目标码率、音频策略、封装以及目标播放器能力。配置需要版本号，否则同一个档位名称在参数调整后会代表不同产物，缓存和任务去重都可能混淆。
本实验固定 H.264、AAC、30 fps、两秒关键帧间隔和四秒分片目标；三档视频目标码率分别为 600、1,200、2,400 kbps。它们用于构造可比较的教学样例，不代表针对所有视频内容优化过的生产码率阶梯。音频独立使用 96 kbps，估算带宽时不能漏掉。
| 档位 | 分辨率 | 视频目标码率 | 峰值约束 | 音频 |
|---|---|---|---|---|
| 360p | 640×360 | 600 kbps | 660 kbps | AAC 96 kbps |
| 540p | 960×540 | 1,200 kbps | 1,320 kbps | AAC 96 kbps |
| 720p | 1280×720 | 2,400 kbps | 2,640 kbps | AAC 96 kbps |
实际输入可能有竖屏、旋转元数据、非方形像素、奇数宽高或多音轨。教学脚本只接受自己生成的固定素材；生产服务必须先探测，决定保持宽高比、补边、旋转和轨道选择方式。把固定的横屏缩放命令直接套到所有输入，会产生拉伸或方向错误。
一次媒体处理经过哪些组件
FFmpeg 先解封装，得到编码包；需要改画面时再解码为帧，经滤镜缩放后重新编码，最后交给封装器输出。-c copy 绕过解码和编码，适合编码已经满足目标要求、只需要换封装的情形。缩放滤镜和对应轨道的 stream copy 不能同时完成同一目标。
本实验在滤镜图中把同一视频帧流分为三路，分别缩放；每路输出都配一条音频。这样可以统一时间线，并减少重复读取输入的工作。它不保证比所有“每档一个进程”方案都省资源：吞吐、隔离和重试粒度仍需要根据硬件与工作负载评估。
多档共用进程时，一路错误可能影响整个任务；多进程则需要额外保证各档起点和关键帧对齐。直播优先级较高时，也可能让基础档先独立就绪，再补高档。架构选择应说明故障域，不能只比较命令数量。
明确轨道选择，避免自动猜测
FFmpeg 可以自动选择轨道，但后端服务应显式描述需要哪条视频、哪条音频。输入中的封面图、备用音轨和字幕可能影响自动选择结果。-map 0:v:0 表示第一个输入的第一条视频轨道，-map 0:a:0? 中的问号表示音轨缺失时允许继续。
允许没有音频是一个业务决定。若直播产品要求同时有声音，就不应该用问号悄悄生成无声结果。多语言内容还要考虑语言标签、默认音轨和用户选择；这些属于输出清单契约，不是事后随意挑一条轨道就能解决。
同样需要区分“输入序号”和“输出轨道序号”。三档命令重复映射音频后，-b:v:1 指第二条输出视频；它不是输入的第二个视频文件。复杂命令应把滤镜标签、映射顺序和 var_stream_map 放在一起检查，否则很容易生成清单可读、轨道配错的结果。
生成三档 HLS
完整命令位于生成脚本，使用 FFmpeg 7.1 实测。将配套文件下载到本地，在独立目录运行脚本。产物目录包含原始 MP4、转封装 MKV、主清单和三组媒体清单；这些大体积媒体文件由读者生成，不随博客部署。
bash generate.sh "$PWD/output"
cat output/master.m3u8
cat output/360/index.m3u8
node server.mjs "$PWD/output"
# 浏览器打开 http://127.0.0.1:18890/player.html
脚本通过 split=3、三次 scale 和三组 -map 构造输出，用 -var_stream_map 把每条视频和对应音频组合成一个变体。-master_pl_name 指定主清单，%v 根据变体名称生成不同子目录，避免三个编码输出争抢同一组分片文件。
关键帧配置包括 -g 60、-keyint_min 60 和关闭额外场景切换关键帧。固定帧率下，这给出约两秒间隔；-hls_time 4 请求约四秒切片。实际边界仍由可用关键帧和输入时间线决定，因此分片目标时长不是任意输入下的精确承诺。
independent_segments 会在清单里声明分片独立性，它不是一个修复坏分片的算法。只有实际确认分片首帧和参考关系满足要求时，声明才有依据。复制已有编码流时尤其需要检查，不能靠增加清单标签让缺少参考帧的片段变得可解码。
编码速度、质量与资源成本怎样取舍
脚本使用软件编码器的 veryfast 预设，目的是让普通开发机能完成实验。预设主要影响编码器搜索复杂度和压缩效率，并不直接等于输出清晰度。换成更慢的预设可能用更多计算换取某些质量或码率收益，但具体幅度依赖输入，必须在同一素材、输出约束和测量方法下比较。
硬件编码还会改变可用参数、驱动依赖、并发上限与画质特征。不能把软件编码实测耗时直接作为 GPU 容量依据，也不能根据设备标称能力推断整条服务吞吐。真实容量测试应包括读写存储、输入探测、编码、封装和结果校验，记录排队时间与失败任务，而不仅是成功编码的速度。
对于需要“接近实时”完成的任务，可以观察处理媒体时长与消耗墙钟时间的比例，但这仍是处理速度，不是观众看到画面的端到端延迟。两者的起点、终点和等待阶段都不同。在实验中先把口径写清楚，后续接入队列和直播链路时才不会把局部优化误读为整体提升。
主清单与媒体清单承担不同责任
主清单告诉播放器有哪些档位，包括带宽、分辨率和编码信息；媒体清单列出某个档位的具体分片、时长和顺序。播放器需要先根据能力和网络选择档位，再沿媒体清单取得数据。任何一层中的相对路径错误都会变成后续请求失败。
清单中的带宽需要反映完整表示的传输需求，不能机械复制视频编码参数。音频和封装占用同样会被下载，实际分片峰值也值得检查。若清单显著低估需求，播放器可能选择超出网络能力的档位，然后以为发生了不可解释的卡顿。
本实验是 VOD，多档全部完成后才打开播放器；直播清单则随输入推进。直播环境应先写完整分片，再让清单引用它；已经发布且可能被缓存的分片应视为不可变对象。更新版本时使用新目录或新对象名，避免同一地址先后对应不同媒体。
多档发布也不必等待所有高成本结果。基础档已校验通过时，可以先发布只包含基础档的清单，高档完成后更新主清单。但新增档位仍要与原时间线兼容，且播放器是否动态发现新变体需要实测，不能假设所有客户端都会自动重新加载。
Java 如何管理一个外部编码进程
配套的TranscodeRunner.java使用 ProcessBuilder 参数列表，直接启动 FFmpeg，不经过 Shell 字符串解释。示例只接受本地输入与输出路径，使用固定编码模板。生产接口还应限制路径根目录、允许的协议、参数组合和资源预算。
日志重定向到文件，避免标准输出或标准错误管道写满后阻塞子进程。等待使用明确的时间上限；超时后先请求结束，再强制终止并等待退出。进程非零退出抛出异常，日志路径保留给排查。日志文件也需要生产级轮转和大小约束，示例没有把本地日志当成无限容量存储。
javac -encoding UTF-8 -d out TranscodeRunner.java StreamState.java LabTest.java
java -cp out TranscodeRunner output/source.mp4 output/java-360.mp4
java -cp out LabTest
这里要求 Java 21，不能只看到机器上存在 java 就执行；本机默认 Java 与实际选用的 JDK 可能不同。示例使用 -n 避免覆盖已有输出，因此第二次运行要更换输出文件名。一次执行对应一个独立目录，会让清理和结果归属更明确。
该执行器直接启动 FFmpeg，因此清理的是受控的直接子进程；若改成 Shell、脚本或会派生进程的包装器，就必须重新处理进程树与孤儿进程。超时不等于进程已经停止，只有确认退出后，资源槽位才可以安全交还。
退出码之后，还需要检查什么
本次对三个档位共四十五个分片检查了首帧关键帧标记、分辨率、跨档起点和完整解码；转封装前后解码视频摘要一致。检查针对这份合成素材与锁定工具版本，不构成任意输入都正确的证明。实验结果和复现步骤集中保存在实验说明中。
如果只检查文件存在，零字节文件、只含文件头的结果或上一次残留都可能被误判成功。至少要确认结果属于本次任务，轨道与输出契约一致，时长合理，清单中每个引用都可读取，且媒体能解码。关键业务还需要目标播放器探测。
对于输出时长，不宜把浮点数完全相等作为要求。音频编码延迟、分片边界和时间基转换可能造成小差异；容差应结合帧率和采样率解释。另一方面，几十秒输入只输出几秒不能被宽泛容差掩盖，必须作为截断或执行异常处理。
失败处理与任务系统怎样分工
输入不存在、无法解码或参数不支持，通常需要修改输入或配置；临时存储错误、容量不足或执行器失联，才可能适合有限重试。把所有非零退出都标记为“稍后重试”，会反复消耗资源，也会把确定性坏输入变成持续积压。
任务系统负责记录尝试次数、错误分类、输出目录和配置版本，执行器负责把一次尝试清晰结束。重试使用新尝试目录，完成后通过版本或 fencing token 选择唯一有效结果。旧进程即使晚些完成，也不能把新结果的清单覆盖掉。
并发限制要按资源成本计算。一个高清长视频与一个低清短片对 CPU、内存和磁盘的占用不同，简单以任务数量扩容可能误判负载。最小示例只证明进程边界；真实平台可以进一步引入配额、任务权重、独立资源池和队列等待预算。
到这里，转码成功有了可操作的定义：受控进程结束，结果经过结构与解码校验，发布只引用本次有效产物。下一篇将从这些正确产物出发，解释为什么播放器仍可能卡顿，以及怎样把问题定位到缓冲、网络或分发层。
可下载完整实验包，按说明在本地复现。