49 lines
2.5 KiB
Markdown
49 lines
2.5 KiB
Markdown
# python-ffmpeg-hevc-crf18
|
||
正如其名，按照固定配置（HEVC CRF 18）压制视频，“以尽可能不影响画面的情况下压缩体积”。
|
||
|
||
## 依赖
|
||
|
||
唯一不可或缺的只有`ffmpeg`。无论 Windows 还是 Linux，获取这个软件包并不难。
|
||
|
||
可选第三方 Python 库：`tqdm`和`colorlog`，让终端输出更“摩登”一些。
|
||
|
||
<details>
|
||
|
||
<summary>fallback</summary>
|
||
|
||
我的模块旨在作为脚本\*单文件运行\*，随意加第三方依赖自然意味着没办法开箱即用。因此，哪怕是部署上我的 Ubuntu Server，我也得考虑 ImportError 时的回滚方案。
|
||
|
||
- `colorlog`：其仓库文档就介绍了跟标准库组合使用的案例。仔细读就不难发现：传入不同`Formatter`即可。
|
||
- `tqdm`：那自然是手撕一个`RawProgressBar`了。毕竟使用场景简单，我撕出来的进度条只实现了用到的方法和`__init__`参数。
|
||
|
||
</details>
|
||
|
||
## 背景
|
||
最初看到类似的实践其实是在某个涩涩论坛上。原帖将近 180GB 的原始资源压制到 30+GB 且几乎不怎么影响画质，巨大的体积差引起了我的兴趣。
|
||
|
||
后来在 QQ 群里有人给出了这么个命令行：
|
||
```sh
|
||
ffmpeg -i input.mp4 -c:v libx265 -crf 18 -preset medium -c:a copy -tag:v hvc1 output.mp4
|
||
```
|
||
这一行命令参数就是窝脚本的核心逻辑了。和大多数在 Python 里封装 ffmpeg 调用的第三方库一样，我也只是包装一下。
|
||
|
||
## 后记
|
||
前身也是个 Bash 脚本。奈何在 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，值得参考。
|