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 呢

全文完

9288 次点击
所在节点    FFmpeg
86 条回复
ungrown
2020-08-26 11:57:32 +08:00
@mikeven #59 没记错的 x265 是目前最好的 hevc 编码器?
我倒也没觉得有什么反常识,厂商再怎么吹牛一般也只承诺节省 20%~30%左右码率,夸张点的也无非是说“最多”可以节省一半。
低码率优势明显符合我的实验数据和结论的,低码率对应高 crf,你看表格里面高 crf 时是不是 hevc 优势很大嘛
ungrown
2020-08-26 12:00:23 +08:00
@ungrown #61 删就删呗,一个小众论坛还整文字狱各种杂七杂八的规矩,大不了我新建个小号呗。
imn1
2020-08-26 12:11:13 +08:00
@ungrown #57
我是相反,能留最原始版本就留,不缺硬盘,而且很少使用移动设备观影,没必要压缩和省空间 /字节流

@mikeven #59
同意第一句,不同意第二句,AVC 和 HEVC 方向是有点不同的,后者更适合网络播放,不能说全部秒杀
另外,将来不知道怎样,目前来说只有较新的设备硬解 HEVC 比较轻松,前几代的话,还是吃资源的
ungrown
2020-08-26 12:20:02 +08:00
@imn1 #63 如果是分辨率不超过 FHD 帧率不超过 60 的 8bit HEVC,问题不大。
哪怕两三年前的主流移动端芯片内置解码器基本都支持,现在的更不用说,客厅端更更不用说,低端产品都内置了基本的 hevc 硬解码,而桌面端就不存在这个问题了。
ungrown
2020-08-26 12:30:26 +08:00
@imn1 #63 我现有的收藏,电视剧算它 50 季每季 12 集共 600 集就算它折合 200 部电影吧,再加上真的电影大约 300 部,一共 500 部长片。假设每部长片原盘 50G,一共 25T,如果用 4T 硬盘需要 7 个,6T 硬盘需要 5 个。
我现在能把这些收藏塞进半个 2T 的移动硬盘。
分享给别人的时候,硬盘对拷每部按秒计,走互联网比如奶牛快传按分钟计,这样的便捷性和便携性说不羡慕是假的。
imn1
2020-08-26 13:24:17 +08:00
@ungrown #65
各人取舍不同吧
我有十多个硬盘存放视频,最小 3T,最大 8T,约 2W 个视频文件,已整理 1.3W (数据库管理),不含小姐姐(已戒)
但原盘不多,主要是来源不可得,原盘多数要 pt,耗时、注册门槛等等
除去 pt 外,能找到更高质量的,就会把原来保存的低质量文件替换掉,但前提还是“有”,所以有些老旧的 rmvb 没找到更好的情况下还留着

我习惯被动慢分享,emule,好处是挂上硬盘就行,bt 难以整盘分享(不可能全盘做一个大种子吧)
另外不使用网盘分享,一来身份安全考虑,二来不喜欢主动上传
tankren
2020-08-26 13:29:51 +08:00
这帖子技术讨论是不错 但是从场景上看 闲的蛋疼 有啥转的必要?
bai82384173
2020-08-26 13:39:24 +08:00
居然在 V2EX 上看到了 QSV
ungrown
2020-08-26 13:50:15 +08:00
@imn1 #66 懂的懂的,就是想勾引你嘛,“来玩嘛~换换口味嘛~”
EasyProgramming
2020-08-26 14:41:32 +08:00
这位大兄弟貌似我见过,之前有个帖子吵的火热,好像是关于 B 站视频的????但为啥我没翻到相关记录呢???
aero99
2020-08-26 14:49:18 +08:00
有没有比较一下 ios 上的 HEVC,我现在基本都用 ipad 生成 HEVC,体积减少不少,画质肉眼看不出变化
shinko
2020-08-26 14:55:03 +08:00
@imn1 数据库管理是自己搞的?我都是用 tinyMediaManager 整理
imn1
2020-08-26 15:06:57 +08:00
@shinko #72
自己写的 PyQT5
ungrown
2020-08-26 15:18:41 +08:00
@EasyProgramming #70 你点我 ID 进主题找呗,反正帖子原样保留。
ungrown
2020-08-26 15:20:06 +08:00
@imn1 #73 用的哪种格式?兼容 kodi 吗?
imn1
2020-08-26 15:48:49 +08:00
@ungrown #75
就是 python+Qt5(pyqt5),kodi 没用过,不晓得
black11black
2020-08-27 03:05:09 +08:00
1 、本身 x265 发展快十年了,可调性非常大,你这么测其实没有任何意义。

2 、0202 年了,现代的画质对比就是要用放大镜看的,没意识到这点说明你还没有悟。你若关注 av1 项目,再跟 x265 全高(概念)设置对比,恨不得画面要放大到 x20 来看区别
ungrown
2020-08-27 08:48:46 +08:00
任何参数调整都是在速度、体积、画质三者之间取舍,而这三者从来不可兼顾,最终也是按需选取一个并不平衡的“平衡点”。
默认参数正是那个三者正中间、最平衡、但反而不一定符合某些需求和场景的点,但默认参数的结果也自然成为整个参数空间函数输出值域的一个基准点,手动调参后在速度、体积、画质上呈现出来的变动都将以默认参数为中点辐射开来。
而 hevc 和 avc 的区别是系统性的而非局部的,它们默认参数的导致的结果本身就是是两个相距甚远的平衡点,它们进行调参后各自辐射开来的值域空间也将各自独立,也许会有部分相交,但不相交的部分才是大头。
最直观的,再怎么调参也不会缩小速度上的差别,再怎么调参也不会让 hevc 在小色块上的涂抹感降低到 avc 的水平。这就是系统差异。

至于逐帧逐像素对比这件事,如果你非要将理论验证和技术迭代过程中所采用的实验方法与评判标准,来强行替代日常使用中人们所依赖的视觉感官体验和重整体轻细节的取舍策略,并且还恬不知耻地指望别人在看到你这些脱离应用场景、偏离讨论重点、单纯否定却无法给出替代方案且毫无建设性的发言后,居然不会将之看作捣乱、挑衅、思维干扰和思想攻击,那你要么摘下道貌岸然的面具放声嘶吼,要么把面具戴好默不作声维持住这好不容易经营起来的伪装。

综上,结论有没有意义我不知道,讨论其意义本身才是意义,数据是实打实的价值,有表可查是莫大的幸福。至于悟,我悟不悟我不知道,也没人能自己说自己悟的这没法证伪,你在猪鼻子插葱,装悟,这倒是能切实体会出来。
101992315
2020-08-28 09:09:13 +08:00
再怎么说 1G 的电影太细了 你压制会飞也没用 还有讨论一直没说音频的问题 我觉得好体验 音频占一半 还有各种标准一直变化 自己维护成本太高了 你充值破站让他把所有片买下比较好
ungrown
2020-08-28 09:21:42 +08:00
@101992315 #79 云端播放体验永远没有桌面端好
音频我万年雷打不动 AAC 128kbps 封顶,如果是以人声为主的音频码率上限还会继续下降到 64
找不到好方法就是再多硬件软件加持也让人头大,找到好方法设计好流程无非是闲暇之时后台跑个脚本点两下鼠标敲几下键盘的事情
另外我愿意花 10 倍大会员求 B 站把以前盗版时代的番剧、影视等等资源连通原有的丰富弹幕统统恢复
谁要看他买来的?当年我没自己压制自己传,跟优酷新浪土豆斗智斗勇,观众积极热情地在弹幕里营造气氛提供背景知识充当旁白,那几年的 B 站体验不比现在的正版化歌舞化后的小破站好一万倍?你别提什么狗屁正版化,正版化光惦记着赚钱体验反而大退步它不怪自己还有理了?

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

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

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

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

© 2021 V2EX