PHP仅调用ffmpeg实现视频转换，保持画质关键在于合理使用-c:v copy -c:a copy流拷贝、必要时用-crf 18等参数重编码，并确保路径、权限、输入源质量等基础环节无误。
PHP 本身不直接转视频，ffmpeg 才是真正干活的工具；PHP 只负责调用它。想“不损坏画质”，关键不是 PHP 写得多漂亮，而是 ffmpeg 命令参数是否合理、输入源是否足够干净、是否绕过了不必要的重编码。
为什么直接用 PHP 的 exec() 调 ffmpeg 是唯一靠谱路径
PHP 没有内置视频编解码能力，所有号称“纯 PHP 视频转换”的库（如某些 GD 或 FFmpeg 扩展封装）最终都得调 ffmpeg 二进制或依赖系统命令。自己拼命令最可控，也最容易排查问题。
- 避免用
shell_exec()直接拼接用户上传的文件名——必须用escapeshellarg()过滤 - 确保 Web 服务用户（如
www-data或nginx）对输入/输出目录有读写权限 -
ffmpeg必须已安装且在$PATH中，可用which ffmpeg验证 - 超大文件建议设
set_time_limit(0)和ini_set('memory_limit', '-1')（但更推荐异步处理）
保持画质的核心：优先“流拷贝”而非重编码
如果源文件容器格式不是 MP4（比如是 .mov、.avi、.mkv），而内部视频流已经是 H.264 + AAC，那根本不需要重新压缩——用 -c:v copy -c:a copy 就能秒转，画质 0 损失。
ffmpeg -i input.mov -c:v copy -c:a copy output.mp4
- 用
ffprobe input.mov查看流信息：Stream #0:0(eng): Video: h264和Stream #0:1(eng): Audio: aac同时存在，才适合流拷贝 - 若音频是
mp3或视频是vp9，则必须转码，此时画质损失不可避免，只能尽量控制 - 别加
-qscale:v或-crf等参数做流拷贝，会强制触发重编码，反而毁画质
必须重编码时，用 -crf 控制质量比固定码率更稳
当源流不兼容 MP4（如 ProRes、DV、无音频等），就得重编码。此时用恒定质量模式（CRF）比固定码率（-b:v）更能兼顾清晰度和体积。
立即学习“PHP免费学习笔记（深入）”；
ffmpeg -i input.avi -c:v libx264 -crf 18 -preset slow -c:a aac -b:a 128k output.mp4
-
-crf 18是视觉无损起点（范围 0–51，越小越好；18–23 是常用平衡点） -
-preset slow比fast或ultrafast编码更准、压缩更优，但耗时增加——别为省几秒牺牲质量 - 别用
-q:v（老参数），它和-crf行为不一致，容易误判 - 如果源是高帧率（如 60fps）或 HDR，记得加
-vf "fps=30"或-colorspace bt709 -color_primaries bt709 -color_trc bt709避免色彩异常
常见翻车点：路径、权限、静音、元数据
很多“转完花屏/无声/黑屏”根本不是画质问题，而是基础配置漏掉：
- 输出路径不存在？先
mkdir -p dirname($output)再执行ffmpeg - 转完没声音？检查源音频是否存在：
ffprobe -v quiet -show_entries stream=codec_type -of csv=p=0 input.mp4 | grep audio - 时间戳错乱？加
-vsync vfr或-copyts（视需求） - 封面图丢失？加
-map_metadata 0保留原始元数据 - PHP 返回空结果？用
exec($cmd, $output, $return_code)检查$return_code !== 0，再读$output看报错
画质不丢的前提，是整个链路没出低级错误——参数对了，路径对了，权限对了，日志看了，才能谈“怎么更好”。否则再精细的 -crf 16 也救不回一个被截断的输出文件。
