2.5 KiB
python-ffmpeg-hevc-crf18
正如其名，按照固定配置（HEVC CRF 18）压制视频，“以尽可能不影响画面的情况下压缩体积”。
依赖
唯一不可或缺的只有ffmpeg。无论 Windows 还是 Linux，获取这个软件包并不难。
可选第三方 Python 库：tqdm和colorlog，让终端输出更“摩登”一些。
fallback
我的模块旨在作为脚本*单文件运行*，随意加第三方依赖自然意味着没办法开箱即用。因此，哪怕是部署上我的 Ubuntu Server，我也得考虑 ImportError 时的回滚方案。
colorlog：其仓库文档就介绍了跟标准库组合使用的案例。仔细读就不难发现：传入不同Formatter即可。tqdm：那自然是手撕一个RawProgressBar了。毕竟使用场景简单，我撕出来的进度条只实现了用到的方法和__init__参数。
背景
最初看到类似的实践其实是在某个涩涩论坛上。原帖将近 180GB 的原始资源压制到 30+GB 且几乎不怎么影响画质，巨大的体积差引起了我的兴趣。
后来在 QQ 群里有人给出了这么个命令行：
ffmpeg -i input.mp4 -c:v libx265 -crf 18 -preset medium -c:a copy -tag:v hvc1 output.mp4
这一行命令参数就是窝脚本的核心逻辑了。和大多数在 Python 里封装 ffmpeg 调用的第三方库一样，我也只是包装一下。
后记
前身也是个 Bash 脚本。奈何在 Bash 里折腾路径实在是有些疲累。有一次出现了我没考虑到的边界情况：
abs_src="/home/agxcoy/Downloads/blabla"
out_dir="~/Videos/blabla"
relpath="subdir/sub.mp4"
# => mkdir -p "/home/agxcoy/Videos//home/agxcoy/Downloads/blabla/subdir/"
气笑了。
然后最初是打算os.walk，但问了下 Google AI、VSCode Copilot，发现pathlib还真挺好用，就整个“翻译”完替换掉 Bash 版了。
已知问题
事实上边界情况还没测试完全，现在也不过能正常走完我的基本流程罢了。
除此之外，进度条本身也有点问题。我应该先在外面四舍五入current_time total_time再丢进进度条里显示的。因为在tqdm那看到了327.099...9/660.377007这么长的文字。
再者就是性能问题了。我处理的视频文件基本以 GB 计。同时跑太多 ffmpeg 进程，内存不够分（我在 Server 上tmux挂后台，似乎日志写多了还出现了掉盘）。逐个逐个跑吧，性能使用率不高。我看有些 ffmpeg 封装库利用了线程池和 asyncio，值得参考。