PHP本身不能压缩视频，必须调用ffmpeg重编码；盲目使用gzencode等函数会损坏文件。有效压缩需设-vcodec libx264、crf 23–26、scale=1280:-2、preset medium、-c:a aac -b:a 128k及+faststart，并严格校验输入输出与错误处理。
必须用 ffmpeg 重编码，别碰 PHP 原生函数
像 gzencode()、file_put_contents() 或 base64 处理视频文件，只会生成损坏的二进制，浏览器无法识别，上传后报错“invalid file format”。视频是封装格式（如 MP4），内部含编码帧、音频流、元数据，通用压缩算法对它基本无效，甚至让文件更大。
批量压缩的核心参数组合（兼顾体积与观感）
这些参数已在生产环境验证，适用于 720P–1080P 主流视频，压缩率通常达 50%–70%，肉眼难辨画质下降：
- -vcodec libx264：兼容性最好，所有设备都能播
- -crf 23–26：恒定质量模式，23 偏高清，26 更省空间；低于 18 体积激增，高于 28 开始出现色块/模糊
- -vf "scale=1280:-2"：宽度限制为 1280px，高度自动适配，避免拉伸变形；4K 视频压到 1080P 级别，体积直降约 60%
- -preset medium：编码速度与压缩率平衡；fast 太糙，slow 太慢，medium 是批量处理的合理选择
- -c:a aac -b:a 128k：音频用 AAC 编码，128k 足够清晰，再高对整体体积影响小但无必要
- -movflags +faststart：把播放头信息移到文件开头，网页点开即播，不卡顿
PHP 批量调用的安全写法
不能直接拼接用户传入的文件名，也不能忽略错误。一个健壮的批量脚本要包含：
- 对每个输入路径用 escapeshellarg() 过滤，防命令注入
- 用 proc_open() 替代 exec()，可设超时（如 300 秒），避免大视频卡死进程
- 捕获 stderr 输出：2>&1，统一检查日志
- 检查返回码是否为 0；非零则记录错误并跳过该文件，不停止整个批次
- 压缩完成后，用 getimagesize() 或 ffprobe 验证输出文件是否有效（大小 > 100KB、能读出时长）
- 临时文件及时 unlink()，防止磁盘占满
别信“压缩90%还不损画质”的宣传
真实场景中，压缩率超过 70%（比如从 500MB 压到 50MB），几乎必然伴随可见画质损失：暗部噪点增多、文字边缘发虚、快速运动拖影加重。如果业务真要求极致体积，可考虑：
立即学习“PHP免费学习笔记（深入）”；
- 先抽帧检测关键画面，对静态片段用更高 CRF（如 28），动态片段用更低 CRF（如 22）——需自定义逻辑，ffmpeg 不原生支持
- 改用 H.265（libx265）：同画质下比 H.264 小 30%–50%，但编码慢 2–3 倍，且老安卓机/微信内嵌播放器可能不支持
- 分离音频单独压缩：用 -c:a libopus -b:a 64k，Opus 比 AAC 在低码率下更通透
