HEVC 的画质和压缩率的优势仅在超高清分辨率时才凸显,而 QSV 的画质和压缩率能和 AVC 持平,全高清及以下的分辨率, HEVC 基本上得不偿失

2020-08-25 20:40:50 +08:00
 ungrown

今天有(mo)空(yu)闲搞了个小实验,想看看 2K 以下的分辨率,包括 FHD(1920x1080)和 HD(1280x720)甚至更低分辨率时,HEVC 的画质和压缩率相比 AVC 到底有多少提升。

之前给家里影音资源大量二压的过程就隐约觉得,在 FHD 、HD 甚至更低分辨率的场景下,HEVC 似乎很得不偿失。

本来还想着通过实验找到个比较均衡的 CRF 参数供以后使用,但是结果让我大跌眼镜,很想放弃 HEVC 。

本文的 hevc 专指 ffmpeg 自带 x265 编码器,avc 专指 ffmpeg 自带 x264 编码器,qsv 专指 ffmpeg 自带 h264_qsv 编码器

[先放结论] [ 1 ] 如果画面细节是可以舍弃的,那么采用较高的 crf,25 以上甚至 28 以上,此时的 hevc 编码虽然很费时间,但是体积可以缩得很小,而且虽然细节丢失后的画面涂抹感严重,但是轮廓色块却能比较好得保留下来,相比之下此时的 avc 早已变成马赛克(实际上 avc 在默认的 crf=23 时轮廓线条已经开始轻微碎片化)。 [ 2 ] avc 的缺点随着分辨率的升高而被放大,到 4K 甚至更高的分辨率时,avc 将被 hevc 碾压,这同时符合 hevc 的设计目标和现实中的应用场景。 [ 3 ] 在 FHD 全高清乃至更低分辨率的条件下,hevc 在码率利用率上的优势不太明显,尤其在使用低 crf 压制时,hevc 相比于 avc 最多只能减小 30%左右的码率,而且相比于 avc 依然有轻微的涂抹感,会丢失一些细微细节,然而这却是耗费了几倍的编码时间换来的。

实验素材是个高码率 MMD,因为是 CG 动画,代表性还是不够广泛,但权且作为这类视频的典型例子。

软件全都是 FFmpeg,版本 4.0.2 。

codec   res     crf     ratio
+-------+-------+-------+----
hevc    x       16      .343
avc     x       16      .447
hevc    x       19      .226
avc     x       19      .322
hevc    x       22      .147
avc     x       22      .222
hevc    x       25      .099
avc     x       25      .154
hevc    x       28      .068
avc     x       28      .109
hevc    fhd     16      .257
qsv     fhd     16      .319
avc     fhd     16      .358
hevc    fhd     19      .165
qsv     fhd     19      .219
avc     fhd     19      .236
hevc    fhd     22      .109
avc     fhd     22      .159
hevc    fhd     25      .075
avc     fhd     25      .112
hevc    hd      16      .123
qsv     hd      16      .171
avc     hd      16      .176
hevc    hd      19      .083
qsv     hd      19      .12
avc     hd      19      .117
hevc    hd      22      .057
avc     hd      22      .08
hevc    hd      25      .04
avc     hd      25      .057

codec:编码器,qsv 专指 h264_qsv,我的 CPU 旧,不支持 hevc_qsv

res:输出分辨率,x 指原分辨率,fhd 指缩小到内切 1920x1080,hd 指缩小到内切 1280x720

crf:就是 crf 参数,顺便一提实验中除了 crf 和缩放没有其他参数

ratio:压缩比,输出文件相比源文件的体积比值,小数点前面的 0 省略了

有经验的人知道,avc 的 crf=23 和 hevc 的 crf=28 有点接近

但这并不代表 avc 和 hevc 输出相同画质对应的 crf 总是相差 5

crf 越小,这俩的输出画质越接近

实际上 23 以下的相同 crf 时,这俩的输出画质就已经不能一眼看出来了,得暂停、靠近、放大、截图……

但真实情况还要更复杂,因为 hevc 针对超高清优化,像素块涂抹感很严重

对于全高清以下的分辨率,hevc 细节其实丢得很多

但在 crf=16 时,hevc 、avc 、qsv 三者的画质非常接近

硬要说的话,avc 依然最佳,但与其他两个的差距可以忽略

但此时,这三者体积也很接近,hevc 顶多也就节约 20%-30%的码率

虽然对视频平台服务商来讲可以剩下很多成本

但在本地存储时,节约的空间不明显,而压制的时间却是成倍增加

所以说 hevc 得不偿失撒(对个人、家用)

如果增大 crf,19 也还行,22 算是个分水岭

再往上,细节的丢失可以被轻易地感知,但很多时候用户就是不需要保留这些细节

比如说,我之前一直把家里的电影统一缩小到内切 1280x720,用 crf=25 压制成 hevc

“看电影看的是故事不是像素点”

一些值得收藏的视频则会用 crf=28,当然也是 hevc

“以后重看时大概看个意思就行了”

这么看来,hevc 虽然非常耗时,但能用低码率牺牲细节保留轮廓,也是个很不错的应用面

那如果要保留细节、输出高画质、又要二压减小体积呢?

我以前一直采用 crf<22 的 hevc,但通过这次实验,我觉得该换思路

既然此时 hevc 画质没有优势,体积没有优势,耗时劣势拉满,那为什么不用 avc 呢

既既然此时 qsv 无论是画质、体积都和 avc 相差无几甚至偶有反超,而速度却数倍于 avc,那为什么不用 qsv 呢

全文完

9088 次点击
所在节点    FFmpeg
86 条回复
minami
2020-08-25 20:44:36 +08:00
FHD 及以下场景建议调低 x265 的块大小,调成和 x264 默认的一致(最大 16x16 ),否则大块的 DCT 会极大破坏画面。
吐槽:x265 代码实现感觉没有 x264 那么好
ungrown
2020-08-25 20:47:41 +08:00
@minami #1 我就猜是这方面原因,但这样的话 hevc 彻底没有优势了吧?
aliofwind
2020-08-25 20:49:51 +08:00
楼主跑 QSV 的 GPU 是哪代,Skylake/Kaby Lake/Coffee Lake/Comet Lake 的 Gen9(.5)还是 Icelake 的 Gen11,后者的 HEVC 编码比前者有很大的提升
ungrown
2020-08-25 20:54:36 +08:00
@aliofwind #3 四代酷睿……
qsv 的 hevc 再强也不会比 CPU 编码好,我没打算用 hevc 硬编码
既然在低分辨率高画质因数的设定下,h264_qsv 约等于 x264 且都比 hevc 更优,那就够了
matolv
2020-08-25 20:56:19 +08:00
hevc/vp9 design for 4k

h.266/av1 design for 8k
OneMan
2020-08-25 20:56:32 +08:00
mark,我关心视频通话哪个实在合适点
minami
2020-08-25 20:56:39 +08:00
@ungrown #2 你可以调到 ctu=16,min-cu=8,max-tu=4 或 8,这样就和 x264 默认一致了。HEVC 是针对高分辨率设计的,所以 x265 默认参数是那样的。HEVC 比 AVC 标准复杂很多,可调参数非常多,想要出好效果很难。我记得以前番组都不太喜欢 HEVC,直到后来逐渐试出好参数后才转型。不过确实基于块压缩+DCT 的方法也快走到头了,块效应、蚊式噪声等问题没法解决。所以 HEVC 之后的标准除了继续搞块压缩,也逐渐引入时域压缩算法,以提升屏幕图像、动漫等场景的压缩效果。时域压缩就是 IBC 、调色板之类的算法,其实 HEVC-SCC 补充标准已经有了相关提案,但是 x265 没有跟进,所以只能在参考软件里体验 HEVC-SCC 。现在我看好 AV1,因为 AV1 已经正式接纳了这些时域压缩算法,压缩效果非常好,可以参见油管
ungrown
2020-08-25 20:59:18 +08:00
@minami #7 很多东西第一次听说,油管的 av1 编码我应该是从未体验过,我猜那玩意不会用到 1080 以下的吧,毕竟油管 1080 以下只有 avc 和 vp9
ungrown
2020-08-25 21:04:32 +08:00
@OneMan #6 这方面跟着业内技术方向走就行,我这应用场景仅限于小体积影音收藏
minami
2020-08-25 21:09:24 +08:00
@ungrown #8 新上传的视频慢慢也都是 AV1 了,你可以右键看详细信息,Codecs 那一栏写着 av01 就是了。AV1 编码器现在没有好的开源实现,谷歌、奈飞这种估计用的是私有实现。个人想自己体验 AV1 的话,目前只能用 SVT-AV1 编码,dav1d 解码,但 SVT-AV1 设计的实在不好用
aliofwind
2020-08-25 21:10:48 +08:00
@ungrown 1080p 的情况下 Icelake 的 QSV 已经接近 x265 medium 预设的质量了,而且编码速度还能保持 50fps,就效率来说已经超过 6 核 skylake/Zen 架构桌面 CPU 跑 x265 fast 了,在 github 开源 IAN 三家 GPU 硬件编码的 rigaya 做了对比测试
我放不了外链,可以去他 github 首页链接里的 fc2 blog 筛选エンコード查看
---------
油管最初测试 av1 编码就是拿的 144p 做的大面积测试
minami
2020-08-25 21:10:54 +08:00
@ungrown #9 小体积影音收藏可以参考字幕组大佬的参数,比如 VCB-S
ungrown
2020-08-25 21:11:08 +08:00
@minami #7 我查了一下 ibc 和 palette,果然太阳底下无新事,又是旧技术旧思路的全新改良应用,帧内运动补偿其实算是个早就该实现的特性,颜色索引这玩意的思路其实 gif 和 png 也都用过了。

都是很务实很有前景的应用,但是应该都还是针对超高分辨率超高帧率的优化,都是未来的业界走向,但并不会帮我减小个人收藏视频的体积。

这次实验的结果指向这样的思路,低分辨率高画质用 h264_qsv 速度快效果好体积不会比 hevc 大多少,低分辨率低画质用 hevc 舍细节保轮廓码率体积非常小。
ungrown
2020-08-25 21:12:05 +08:00
@minami #12 vcb-s 的体积不小呀,我有些源文件也是从他们组下的,略有印象
minami
2020-08-25 21:15:21 +08:00
@ungrown #14 他们有出过 x265 和 x264 的调参教程
# 所以其实思路都是那样。。所谓的标准就是把各种算法都定义好,编码器自由选择合适的算法来编码,编码出符合规范的码流。正所谓复合算法>单一算法,代价决策才是编码器核心
ungrown
2020-08-25 21:18:42 +08:00
@aliofwind #11 qsv 编码器速度超过 cpu 质量接近 cpu 并不让我意外,毕竟四代酷睿的 h264_qsv 就已经如此了,新 U 在 hevc 上也如此不奇怪。

只是低分辨率高画质用 avc 编码结果比 hevc 更好,无论画质(细节)还是速度。
而地分辨低画质用 hevc 编码结果比 hevc 更好,无论画质(轮廓)还是体积。

av1 实验的资料我有看过,里面的素材就是极低分辨率,我只是说平常看视频我大概率是看不到了(目前)。
ungrown
2020-08-25 21:20:47 +08:00
@minami #15 那系列教程我当初看过的说,虽然现在不记得多少了,但是他们组是面向广大受众的,他们能接受的高画质和低画质,和我所期望的,应该不是一回事……
mxalbert1996
2020-08-25 21:21:47 +08:00
我就奇怪了难道真有人把视频都自己重压一遍再保存?现在硬盘很贵吗?而且你就这么自信你比压制组的人还懂调参?
minami
2020-08-25 21:24:12 +08:00
@ungrown #17 哈哈没毛病。。那你只能自己慢慢调参摸索了。。。然后发现还是买硬盘 /BD 机 /磁带机香,doge
ungrown
2020-08-25 21:46:20 +08:00
@mxalbert1996 #18 你猜测的流程,没有我实际使用的流程的三分之一复杂。

首先不管是电影电视剧动漫,只要是没看过的,下载之前要翻介绍评论,如果是大路货就把念头掐灭,不管它有多火热,坚决不下!

下载完了可能会先看一遍,比方说正好有空正好有兴致,一遍的过程中发现不行就删掉,不管是看到中间还是完整的一遍。

存活下来的文件会进一台作为 nas 的自攒低功耗 x86,用 tmm 爬取电影电视数据并固化(半自动过程,点几下鼠标的事情),后续家里电视盒子开 kodi 就能浏览观看了。

过了一段时间(几个星期或者几个月),那些已经看过但是发现明显不值得继续收藏的文件会被毫不留情地删除,有 tmm 作为库管理,打字搜索可以迅速找到目标,当然不需要点开文件夹逐个找。

相对应地,看过,且决定收藏的,移动至收藏用的路径下,有空了就在后台开脚本批量处理,脚本会根据文件名副后缀判断是否是已经二压收藏的,参数是固化的。

顺便一提普通影音库和收藏库虽然是两个路径,但这俩通过 mergerfs 合并成一个虚拟挂载点,并通过 samba 共享,所以不管文件在哪个路径下,在电视盒子里看来都是同一个路径下。

四五年前买的希捷 3T 机械盘,因为设定成 20 分钟无读写自动停转,所以每天的实际负载时间极少极少,以至于这个老盘的 smart 看上去像是刚用了一两年。3TB 全部 zfs,按日周月自动快照,过期快照自动删除,这样既不担心误删除文件,也不担心快照占用太多空间,现如今还有 500 多 GB 的空间,以及比这更多的快照空间,不到 2TB 的实际数据中,将近 300 部电影和二三十季的电视剧或者动漫其实只占了一小半。

我跟你说个人用家庭存储,非工作室非生产环境,高清是伪需求,多盘是伪需求。这世上伪需求多得淹没了所有人的脑子、眼界和话语,养活了无数尸位素餐的企业。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/701397

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX