视频编码时反交错真是威力巨大

[atuocn]

以前的录制的老 DVD 视频，录制的品质比较差。翻出来后准备重新压缩成 mp4 存档。但是用 ffmpeg 压制后，无论是 h264,还是 h265, 画面上快速运动的物体，都出现晶块化。尝试调整码率，2-pass 、crf 、控制最小码率都没啥用处。

最后想起以前 DVD rip 时，一般会用 avisynth 做反交错，deblock 。但是现在 ffmpeg 自身也带 filter ，所以没必要使用 avisynth, 直接使用 ffmpeg 自身的一个反交错滤镜，yadif (Yet Another DeInterlacing Filter ）。

ffmpeg -i VTS_01_1.VOB -vf yadif -c:v libx265 VTS_01_1.mp4

奇迹出现了，晶块化立即消失。并且码率大幅下降，在默认压缩参数下比没有反交错前的文件小了约 1/3 。画面品质和原始 DVD 视频没什么差别，从 4.5G 直接压缩到 600M 。当然这个奇迹般的压缩率和原始画面品质差也有关系。

这个总结就是，对于 h264, h265 这样的高级视频压缩编码，隔行扫描的输入视频逐行化是很重要的一步，直接影响编码品质。

Note:

1. 科普一下逐行扫描、隔行扫描、反交错。视频处理源头祖宗是以前的电视节目。电视节目在制作和传播过程中，为了对抗最大的由交流电产生的电磁干扰，要选择和交流电相同的刷新频率，欧洲和我国就是 50hz ，美国日本就是 60hz 。但这个刷新率太高，对电视传输的带宽要求很高，于是把一帧画面，切成 2 场，隔行交错扫描，比如第一场奇数行，第二场偶数行，这样大幅降低了每场的传输数据，画面上回显则刷新 2 场才能显示一帧完整画面。这就是隔行扫描。但是胶片电影是一帧一帧完整画面拍摄的，随着技术进步，画质要求的提高，高清视频中逐行扫描成为主流。这时候原先用于兼容电视的视频设备播放或拍摄的视频就要“反交错”，实现隔行扫描到逐行扫描的转变。但这个过程其实挺麻烦，有各种历史的技术包袱、视频转录、传输过程的信息丢失。但是自己录制的 DVD ，隔行扫描的结果是一手源头，反交错还是很容易的。

2. avisynth 是个神奇的软件，当初接触它的概念的时候觉得很惊艳。不过自己也就偶尔压个片存档，普通功能代替的方案也很多，后来就基本不用了。它是一个 Frameserver ，顾名思义就是纯后台提供画面帧的服务器，加载视频，处理后直接提供给播放器或编码器，而不产生临时文件。它以脚本的方式工作，提供大量滤镜，而且形成一定的生态。你要加个反交错，切边、加字幕啥的，写几行命令放在脚本里就行，然后交由编码器处理。但是这个软件原始作者不维护后，一直发展不太顺利，各种 mod,最后才慢慢由 avisynth+接替，成为后续版本。而且 Frameserver 这个概念，一听就很契合 linux 的感觉，其实它是 windows 平台上发展起来的。个人感觉原因是音视频真的是微软、苹果领先，linux 那时还在玩泥巴。所以直到现在，avisynth+虽然支持 linux ，arch 上的 ffmpeg 也默认编译了 avisynth 的支持，但是试用了几下，问题还是不少的。linux 下插件也不多。另一个 Frameserver 的替代品是 vapoursynth ，它是后来的更现代的软件，跨平台性更好，用 python 做脚本语言。但我不是很喜欢，为编码还整个 python ，更没兴趣去学。

[shawndev]

感谢，学到了

[milzero]

“尝试调整码率，2-pass 、crf 、控制最小码率” 这些和使用交织编码不冲突的！

[atuocn]

是不冲突的。但是不做 “反交错” ，转码后的效果就是很差，而且调整码率几乎无效。反交错之后，不需要调整参数，直接产生质的飞跃。

不太清楚 ffmpeg 编码时如何处理隔行视频，是按场来压缩的还是按帧来压缩的。我猜是“反交错”后一帧画面完整，h265/h264 在做画面的运动预测和压缩量化时信息更准确。而我原始的视频品质比较差，加剧损害了编码器做运动预测和压缩量化评估。