MP4/MKV/MOV/WEBM 四种输出的真重新编码

四个输出目标

ZenConverter 的视频格式互转覆盖四种输出容器：

输出容器	默认视频编码	可选编码	默认音频
MP4	H.264 (libx264)	H.265 (libx265)	AAC (LC-AAC)
MKV	H.264 / H.265	同上	AAC
MOV	H.264 / H.265	同上	AAC
WEBM	VP9 (libvpx-vp9)	VP8 (libvpx)	Opus (libopus)

输入覆盖九种容器：MP4 / MKV / MOV / WEBM / AVI / 3GP / 3GPP / TS / MTS。所有路线都是先探测输入文件能提供哪些编码和滤镜，再决定输出参数。

真重新编码 vs stream copy

很多人知道 FFmpeg 有 -c copy（stream copy）模式，直接把视频/音频流从一个容器搬到另一个容器，速度极快、不损失画质。那为什么 ZenConverter 不用它？

因为真重新编码带来了 stream copy 做不到的好处：

容器适配：某些编码器（比如 H.265 + AAC 在 MP4 里可以流复制，但某些源文件的音频 codec 和目标容器不兼容），真重新编码永远输出目标容器原生的编解码器组合；
码率控制：重新编码可以设定目标码率、CRF、分辨率上限，这是压缩预设的基础；
高级滤镜：倒放、淡入淡出、镜像、旋转、画幅适配/裁剪，这些都要求解码 → 滤镜 → 编码的完整管线；
音频处理：音频重新编码可以调整采样率、声道、音量、回音等。

stream copy 只用来做一件事：音频元数据修复路径（MP3、Opus、FLAC 的元数据验证不通过时，可能走一次 metadata-only 的 -c:a copy remux 来修复封面和 ID3）。

每条输出路线的已知边界

MP4 → MP4 自己转自己（输入 MP4，输出也 MP4）也是真重新编码。这是有意的——因为 ZenConverter 要让压缩预设、高级滤镜、码率控制对 MP4 → MP4 生效。其他很多转换器遇到同格式互转时会默认 stream copy，结果是压缩预设和滤镜全被跳过，用户感觉"我设了但没用"。

字幕、附件、额外轨道不复制。只保留第一个视频轨和第一个音频轨。多音轨的电影文件（比如带中英双语音轨）只会保留默认主声轨。这个限制写在 support-matrix 里。

WEBM 的移动端调优。WEBM 输出会开启移动端优化参数：-deadline realtime -cpu-used 4 -b:v 0、多线程。这是因为 VP9 在移动端的编码速度直接影响用户体验——移动端芯片的 GPU 编码 VP9 的支持比 H.264/H.265 差很多。

支持矩阵里的具体路径

输入	输出	状态	引擎	关键行为
MP4	MP4	Stable	FFmpeg	H.264/H.265 + AAC 重新编码
MP4	MKV	Stable	FFmpeg	同上，容器换 Matroska
MP4	MOV	Stable	FFmpeg	同上，容器换 QuickTime
MP4	WEBM	Stable	FFmpeg	VP9/VP8 + Opus
MKV/MOV/WEBM/AVI/…	MP4	Stable	FFmpeg	H.264/H.265 + AAC

还有一个特殊路线：多个视频合并后输出到 MP4/MKV/MOV/WEBM（见视频合并页面）。

编码前的探测

ZenConverter 在导出前会探测当前 APK 内的 FFmpegKitNext AAR 到底包含哪些编码器和滤镜。如果探测到某个选项不存在（比如某些滤镜在 Lite 版 FFmpegKit 里被裁掉了），会在导出前直接报错，而不是跑到一半才失败。

这和很多转换器"默默降级"的做法不同。ZenConverter 的设计哲学是：不支持就明确告诉你不支持，不要给你一个有问题的半成品。