以前的录制的老 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:
科普一下逐行扫描、隔行扫描、反交错。视频处理源头祖宗是以前的电视节目。电视节目在制作和传播过程中,为了对抗最大的由交流电产生的电磁干扰,要选择和交流电相同的刷新频率,欧洲和我国就是 50hz ,美国日本就是 60hz 。但这个刷新率太高,对电视传输的带宽要求很高,于是把一帧画面,切成 2 场,隔行交错扫描,比如第一场奇数行,第二场偶数行,这样大幅降低了每场的传输数据,画面上回显则刷新 2 场才能显示一帧完整画面。这就是隔行扫描。但是胶片电影是一帧一帧完整画面拍摄的,随着技术进步,画质要求的提高,高清视频中逐行扫描成为主流。这时候原先用于兼容电视的视频设备播放或拍摄的视频就要“反交错”,实现隔行扫描到逐行扫描的转变。但这个过程其实挺麻烦,有各种历史的技术包袱、视频转录、传输过程的信息丢失。但是自己录制的 DVD ,隔行扫描的结果是一手源头,反交错还是很容易的。
avisynth 是个神奇的软件,当初接触它的概念的时候觉得很惊艳。不过自己也就偶尔压个片存档,普通功能代替的方案也很多,后来就基本不用了。它是一个 Frameserver ,顾名思义就是纯后台提供画面帧的服务器,加载视频,处理后直接提供给播放器或编码器,而不产生临时文件。它以脚本的方式工作,提供大量滤镜,而且形成一定的生态。你要加个反交错,切边、加字幕啥的,写几行命令放在脚本里就行,然后交由编码器处理。但是这个软件原始作者不维护后,一直发展不太顺利,各种 mod,最后才慢慢由 avisynth+接替,成为后续版本。而且 Frameserver 这个概念,一听就很契合 linux 的感觉,其实它是 windows 平台上发展起来的。个人感觉原因是音视频真的是微软、苹果领先,linux 那时还在玩泥巴。所以直到现在,avisynth+虽然支持 linux ,arch 上的 ffmpeg 也默认编译了 avisynth 的支持,但是试用了几下,问题还是不少的。linux 下插件也不多。另一个 Frameserver 的替代品是 vapoursynth ,它是后来的更现代的软件,跨平台性更好,用 python 做脚本语言。但我不是很喜欢,为编码还整个 python ,更没兴趣去学。
1
shawndev 2023-10-20 11:26:14 +08:00
感谢,学到了
|
2
milzero 2023-10-20 15:51:33 +08:00
“尝试调整码率,2-pass 、crf 、控制最小码率” 这些和使用交织编码不冲突的!
|
3
atuocn OP 是不冲突的。但是不做 “反交错” ,转码后的效果就是很差,而且调整码率几乎无效。反交错之后,不需要调整参数,直接产生质的飞跃。
不太清楚 ffmpeg 编码时如何处理隔行视频,是按场来压缩的还是按帧来压缩的。我猜是“反交错”后一帧画面完整,h265/h264 在做画面的运动预测和压缩量化时信息更准确。而我原始的视频品质比较差,加剧损害了编码器做运动预测和压缩量化评估。 |