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

FHD 及以下场景建议调低 x265 的块大小，调成和 x264 默认的一致（最大 16x16 ），否则大块的 DCT 会极大破坏画面。
吐槽：x265 代码实现感觉没有 x264 那么好

@minami #1 我就猜是这方面原因，但这样的话 hevc 彻底没有优势了吧？

楼主跑 QSV 的 GPU 是哪代，Skylake/Kaby Lake/Coffee Lake/Comet Lake 的 Gen9(.5)还是 Icelake 的 Gen11，后者的 HEVC 编码比前者有很大的提升

@aliofwind #3 四代酷睿……
qsv 的 hevc 再强也不会比 CPU 编码好，我没打算用 hevc 硬编码
既然在低分辨率高画质因数的设定下，h264_qsv 约等于 x264 且都比 hevc 更优，那就够了

hevc/vp9 design for 4k

h.266/av1 design for 8k

mark，我关心视频通话哪个实在合适点

@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 已经正式接纳了这些时域压缩算法，压缩效果非常好，可以参见油管

@minami #7 很多东西第一次听说，油管的 av1 编码我应该是从未体验过，我猜那玩意不会用到 1080 以下的吧，毕竟油管 1080 以下只有 avc 和 vp9

@OneMan #6 这方面跟着业内技术方向走就行，我这应用场景仅限于小体积影音收藏

@ungrown #8 新上传的视频慢慢也都是 AV1 了，你可以右键看详细信息，Codecs 那一栏写着 av01 就是了。AV1 编码器现在没有好的开源实现，谷歌、奈飞这种估计用的是私有实现。个人想自己体验 AV1 的话，目前只能用 SVT-AV1 编码，dav1d 解码，但 SVT-AV1 设计的实在不好用

@ungrown 1080p 的情况下 Icelake 的 QSV 已经接近 x265 medium 预设的质量了，而且编码速度还能保持 50fps，就效率来说已经超过 6 核 skylake/Zen 架构桌面 CPU 跑 x265 fast 了，在 github 开源 IAN 三家 GPU 硬件编码的 rigaya 做了对比测试
我放不了外链，可以去他 github 首页链接里的 fc2 blog 筛选エンコド查看
---------
油管最初测试 av1 编码就是拿的 144p 做的大面积测试

@ungrown #9 小体积影音收藏可以参考字幕组大佬的参数，比如 VCB-S

@minami #7 我查了一下 ibc 和 palette，果然太阳底下无新事，又是旧技术旧思路的全新改良应用，帧内运动补偿其实算是个早就该实现的特性，颜色索引这玩意的思路其实 gif 和 png 也都用过了。

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

这次实验的结果指向这样的思路，低分辨率高画质用 h264_qsv 速度快效果好体积不会比 hevc 大多少，低分辨率低画质用 hevc 舍细节保轮廓码率体积非常小。

@minami #12 vcb-s 的体积不小呀，我有些源文件也是从他们组下的，略有印象

@ungrown #14 他们有出过 x265 和 x264 的调参教程
# 所以其实思路都是那样。。所谓的标准就是把各种算法都定义好，编码器自由选择合适的算法来编码，编码出符合规范的码流。正所谓复合算法>单一算法，代价决策才是编码器核心

@aliofwind #11 qsv 编码器速度超过 cpu 质量接近 cpu 并不让我意外，毕竟四代酷睿的 h264_qsv 就已经如此了，新 U 在 hevc 上也如此不奇怪。

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

av1 实验的资料我有看过，里面的素材就是极低分辨率，我只是说平常看视频我大概率是看不到了（目前）。

@minami #15 那系列教程我当初看过的说，虽然现在不记得多少了，但是他们组是面向广大受众的，他们能接受的高画质和低画质，和我所期望的，应该不是一回事……

我就奇怪了难道真有人把视频都自己重压一遍再保存？现在硬盘很贵吗？而且你就这么自信你比压制组的人还懂调参？

@ungrown #17 哈哈没毛病。。那你只能自己慢慢调参摸索了。。。然后发现还是买硬盘 /BD 机 /磁带机香，doge

@mxalbert1996 #18 你猜测的流程，没有我实际使用的流程的三分之一复杂。

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

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

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

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

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

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

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

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

@mxalbert1996 #18 我一直以为，那些收藏的人都存的是原盘，至少都是 remux，想不到还会转成小体积文件。

@minami #19 还行，这次实验，以及跟你和另外几位的交流，已经帮我把方案定下来了，我上面也说过了，就是分两种情况：
低分辨率高画质，低 crf 值，qsv，速度极快，体积只比 hevc 高 20%-30%，画质细节保留得还比 hevc 多（当然 hevc 调参数应该也能追上来，但是 hevc 太慢了）；
低分辨率低画质，高 crf 值，hevc，速度慢，但是体积很小，非常小，真正意义上同等画面比 avc 少了一半（甚至更少），画面涂抹感比较明显，丢了不少细节，但是轮廓线条清晰（此时如果用 avc 已经成了马赛克了）。

@mxalbert1996 #18 还有忘了说，我可能一直都没说得足够清楚画质是可以牺牲的，画质是永远都可以牺牲的，所以“更懂调参”这是你自我代入脑补了。
用 500kbps 码率就能清楚表达的故事，为什么我要浪费几千 kbps 的码率？
720p@800kbps 的画质会丢失暗场、丢失每一滴雨水、丢失一小部分衣服纹理皮肤褶皱，然而这些细节难道不是本来就是多余的吗？
动画的高离散特性导致它需要更高的码率保留画面的锐利感，但是适当提高足矣。
现在最让我不服的就是收藏的 mmd，码率实在是降不到 2000kbps 以下，我考虑降低此类视频的分辨率档次，以后全部二压成 720p 试试看。

@ouqihang #21 原盘和 bd-rip 的唯一价值是作为高清晰度的“源”，为二压提供基准

我就不会去二压，要么就下 bdrip 大概一个半小时的 1080P 15GB 左右，要么还是下 bdrip，但是 70GB 左右的 hevc 的 4K HDR 版，比如小丑 /1917 这种。

x265 关一下 sao 试试
（--no-sao ）

@ungrown 我猜测你什么流程了？你打这么多字也许是想炫耀一下你有多会节省空间，但在我和其他很多人看来这不过就是花几百块钱买几块硬盘的事。能用钱解决的事情何必花时间？至于高清和细节是不是伪需求，你先去问问内容创作者是怎么想的吧。

@zhuangku556 #25 我这一部电影基本不超过一个 G，动作场景少的片不超过 500M

@mxalbert1996 #27 压片花我什么时间了？编码器需要我去帮它跑吗？我整套流程操作一下只占用几十秒到一两分钟的事情，我还至少展现了智慧和勤劳，你买了一堆硬盘除了空耗电能存些这辈子都不一定看几遍的东西，显得你有能耐？你那些高清动辄几十个 G，我耗费要少于你的资源消耗远少于你的能量依赖要少于你的设备零部件占据远少于你的空间却获得原超于你的体验，在你这种不动脑子不动手只会空口叫嚣花钱实则送钱的人面前我不显摆显摆对得起你的花出去的冤枉钱的吗？

另外创作者是最明白高清纯属伪需求的人群，各大平台哪个不二压？哪个二压码率能喂饱？平台商怂恿创作者配合他们坑用户呢，他们说的话他们自己都不信，你作为被骗的小白鼠你起什么劲？

@darer #26 多谢，我看看

压片对厂商来说是一次性成本，而带宽是每天都要花钱的

@ungrown #29 你开心就好

个人用户没必要压片,直接 PT 上下 4K 原盘（ 60G-90G ）就可以了，硬盘现在很便宜。 看 4K 图的就是高清+ATMOS 音效。

@ayconanw #31 还有另外一个前提：厂商提供的视频画质都是中等，对应到实验数据的表格中，就是分辨率高，但是 crf 也比较高，这个时候，hevc 相比 avc 可以获得 30%-50%的码率降低，厂商就很开心，编码方案商就更开心了

@jones2000 #33 看电影看的是故事是剧情不是像素点，听的是台词是配乐不是声道和音效，反正我是不愿意为了这些额外的修饰多付出哪怕 100kbps，更别提几十 GB 的空间了

@redeemer1001 #32 怎么了你不开心吗

不懂就问，行车记录仪 2k 分辨率视频怎么压参数怎么设最好？至少得能看清楚前面车牌号为准

@ungrown 对于你这种一副众人皆醉我独醒的心态并且通过人身攻击来满足自尊的人我是没什么可说的了，毕竟很多事也是主观的。不过还是要提醒你压片的功耗可比硬盘的功耗高得多了，这可是客观事实哦。

@mxalbert1996 #39 这点你错得离谱，硬盘功率虽然比 CPU 满载功率低，但转码是一次性工作，硬盘是 365x24 小时不停，一部电影转码三四个小时耗的电，相比其在硬盘上一直呆着耗的电，简直杯水车薪，多么简单的计算题。这还只是考虑单硬盘的情况，像你们那样硬盘位恨不得插满的，总硬盘功耗都接近我笔记本的 CPU 满载功耗了，硬盘全年空转耗费的电能就为了里面那些几乎不会再去看一眼的“收藏”？众人皆醉我独醒这话原封不动送给你，为了面子连算术题都不会做的人，居然还有脸来“攻击”我说我“攻击”你？

@est #38 你是要二压存档吗？在乎时间的话，x264 或者硬件加速（比如 qsv ），不在乎时间 hevc，为了看清车牌，crf 不能太高但也不需要太低，以 crf=22 为起点尝试，另外可以试着降低分辨率看看能否在满足需要的同时减少总信息量。尝试过程不需要全片压缩，找些有前面车牌的画面的片段，两三秒钟的，切出来实验就行。

@ungrown 那你可以直接下 1-2GB 左右的压制版本，这种很多啊

@zhuangku556 以前是主流，现在搜索结果中这档资源越来越靠后。以前人人搞出的 hr-hdtv 用 1024x576 分辨率来降低体积，码率其实给足了。现在的一两 GB 的资源往往是枪版、0day 版、抢首发版，空有高分辨率但码率欠的过分不说，还往往压进了翻译质量差的硬字幕。另外就是，因为是脚本批量二压，所以就算下载的是一两 G 的版本，也逃不过再被二压的命运。

@ungrown 对。我是要二压。行车记录仪那个默认的 h264 baseline 体积巨大。。几分钟就好几个 G 了。。有些时候想想保存一些行车视频。

@ungrown 你的算数真厉害，毕竟硬盘休眠这种东西根本就不存在呢，而且仓库盘一定要一直插着电呢。

说起来有人测试过 bilibili 切换到 HEVC 后的画质变化吗？
不知什么时候开始 HTML5 播放器在 Safari 上已经默认播放 HEVC 视频流了。相同分辨率等级下提供的视频流码率都有不同程度的降低，大概在 30% - 50% 之间。

@SF 变化不明显，体积如你所说省了接近一半，原因还是可以从正文表格中找到端倪：高分辨率、中等偏高的 crf，就对应着四成左右的体积减小。

画质细细对比的话，还是 hevc 的老毛病，有比 avc 更强的涂抹感，但都局限在很小的像素块上，不逐帧反复对比是看不出的。

我拿自己修改的 you-get 从 B 站拖了大量视频，新上传的视频基本都默认下载 hevc 源。

@ungrown 你可以去毛子网站 yts 看看，电影都是 1-2GB 左右而且没有硬字幕。

@est #44 那就参考我的回复自己做一下实验，切几秒钟的片段出来，很快的

@mxalbert1996 #45 你的妄想更厉害
毕竟在你想象的场景里，我那多年积累的几百收藏是必须要全年 365 天 24 小时不间断 CPU 满载压制一遍又一遍的
毕竟在你的想象里，我是不能在开着笔记本工作或者娱乐时，顺便在后台开低优先级 ffmpeg 充分利用时间和设备算力的
毕竟在你的想象里，在笔记本低负载就已经二三十 W 功耗的基础上，加个压制任务到满载的四五十 W 功耗，是远超过你那些不管是在带电跑还是吃灰的硬盘所消耗的生产资源和电力能源的
毕竟在你的想象里，花三小时左右压制一部电影所消耗的资源，是远超过你为了下高清圆盘几十个 GB 不得不长时间开机跑硬盘所消耗的资源的
毕竟在你的想象里，你那些花了大量时间金钱下载收藏却难得看一次甚至一次都不一定会去看的高清资源所耗费的时间精力金钱资源，是不可能会超过我优选、量少、体积小这些策略的

@zhuangku556 #48 谢谢提供的信息，以后要新增收藏我去那里看看，如果满足需求可以减少一部分二压工作

@zhuangku556 #48 我搜了一下 wiki，这个组真的有意思，相见恨晚啊

@ungrown 是的，清晰度和体积平衡的不错，要求不高足够了。

楼主这一套流程太牛了。
我是重度松鼠症， 下下来的片几乎没有删的。不够空间就加硬盘， 片大概只看了 30%吧。

多谢，楼主的实验还是很有参考意义的，工作上经常需要压视频，又没时间研究各种参数组合。

不过对于楼主说“看电影不看像素点，不听音效”实在是难以认同，照这个思路，直接听机器语音读剧本岂不更妙？
盲猜楼主只是单纯的享受研究压制的乐趣罢了，这也挺好的。

@minami #7 调了 ctu 、cu 、tu 的参数后，hevc 本身就已经很慢的速度又慢了几倍，2333

@Dukewill #55 啊不，家里电影电视剧都是二压成不超过 720p 的 hevc 了，电影 crf=25，电视剧视情况 22~28 （有些年代久远的低分辨率文件得用 22 压不然全糊了），观感很好，体积很小（动作场景不多的电影压到 500M 以下，大点的基本在 800M 左右）

@darer #26
@minami #7
我组合尝试了 ctu 和 sao 的参数

单纯禁用 sao 会丢失涂抹细节，码率和不禁用一样，但是画质变得稍微更差了

```python
In [29]: c.config_hevc(crf=19)
In [30]: c.estimate_overwrite()
[I][mylib.ffmpeg.FFmpegCaller] ffmpeg -hide_banner -loglevel warning -y -i "i-0\29.mkv" -crf 19 -vcodec hevc -x265-params log-level=error "o-0\29.mkv"
[I][mylib.ffmpeg.FFmpegCaller] ffmpeg -hide_banner -loglevel warning -y -i "i-0\2.mkv" -crf 19 -vcodec hevc -x265-params log-level=error "o-0\2.mkv"
[h264 @ 000001fd7594f180] Increasing reorder buffer to 1
Out[30]: {'0': 0.226}

In [47]: c.config_hevc(crf=19,no_sao=1)
In [48]: c.estimate_overwrite()
[I][mylib.ffmpeg.FFmpegCaller] ffmpeg -hide_banner -loglevel warning -y -i "i-0\29.mkv" -crf 19 -vcodec hevc -x265-params log-level=error:no-sao=1 "o-0\29.mkv"
[I][mylib.ffmpeg.FFmpegCaller] ffmpeg -hide_banner -loglevel warning -y -i "i-0\2.mkv" -crf 19 -vcodec hevc -x265-params log-level=error:no-sao=1 "o-0\2.mkv"
[h264 @ 0000017a35d7f140] Increasing reorder buffer to 1
Out[48]: {'0': 0.222}
```

单纯调整 ctu 、cu 、tu 码率有略微上升，速度速度进一步降低，但是截图对比又看不出有保留更多细节，似乎和没调这些参数之前一样

```python
In [43]: c.config_hevc(crf=19,ctu=32,max_tu_size=4,min_cu_size=8)
In [44]: c.estimate_overwrite()
[I][mylib.ffmpeg.FFmpegCaller] ffmpeg -hide_banner -loglevel warning -y -i "i-0\29.mkv" -crf 19 -vcodec hevc -x265-params log-level=error:ctu=32:max-tu-size=4:min-cu-size=8 "o-0\29.mkv"
[I][mylib.ffmpeg.FFmpegCaller] ffmpeg -hide_banner -loglevel warning -y -i "i-0\2.mkv" -crf 19 -vcodec hevc -x265-params log-level=error:ctu=32:max-tu-size=4:min-cu-size=8 "o-0\2.mkv"
[h264 @ 0000022faaa9f1c0] Increasing reorder buffer to 1
Out[44]: {'0': 0.282}
```

然后我把这俩参数一起用，既调小块又禁用 sao，输出画质好像比默认参数时保留了更多的细节，好像有所改善，但又不明显，我也不知道是不是心理作用

```python
In [45]: c.config_hevc(crf=19,ctu=32,max_tu_size=4,min_cu_size=8,no_sao=1)
In [46]: c.estimate_overwrite()
[I][mylib.ffmpeg.FFmpegCaller] ffmpeg -hide_banner -loglevel warning -y -i "i-0\29.mkv" -crf 19 -vcodec hevc -x265-params log-level=error:ctu=32:max-tu-size=4:min-cu-size=8:no-sao=1 "o-0\29.mkv"
[I][mylib.ffmpeg.FFmpegCaller] ffmpeg -hide_banner -loglevel warning -y -i "i-0\2.mkv" -crf 19 -vcodec hevc -x265-params log-level=error:ctu=32:max-tu-size=4:min-cu-size=8:no-sao=1 "o-0\2.mkv"
[h264 @ 000001e7e3eaf1c0] Increasing reorder buffer to 1
Out[46]: {'0': 0.274}
```

我觉得不是 hevc 问题，而是 x265 编码器一般，以及参数设置问题。理论上 hevc 全码率秒杀 avc 的，cpu 编码也>=显卡编码，低码率优势更明显，你这些结论都很反常识啊。

这个附言足够 ban id 了……可惜 LZ 不能自己删帖

@mikeven #59 没记错的 x265 是目前最好的 hevc 编码器？
我倒也没觉得有什么反常识，厂商再怎么吹牛一般也只承诺节省 20%~30%左右码率，夸张点的也无非是说“最多”可以节省一半。
低码率优势明显符合我的实验数据和结论的，低码率对应高 crf，你看表格里面高 crf 时是不是 hevc 优势很大嘛

@ungrown #61 删就删呗，一个小众论坛还整文字狱各种杂七杂八的规矩，大不了我新建个小号呗。

@ungrown #57
我是相反，能留最原始版本就留，不缺硬盘，而且很少使用移动设备观影，没必要压缩和省空间 /字节流

@mikeven #59
同意第一句，不同意第二句，AVC 和 HEVC 方向是有点不同的，后者更适合网络播放，不能说全部秒杀
另外，将来不知道怎样，目前来说只有较新的设备硬解 HEVC 比较轻松，前几代的话，还是吃资源的

@imn1 #63 如果是分辨率不超过 FHD 帧率不超过 60 的 8bit HEVC，问题不大。
哪怕两三年前的主流移动端芯片内置解码器基本都支持，现在的更不用说，客厅端更更不用说，低端产品都内置了基本的 hevc 硬解码，而桌面端就不存在这个问题了。

@imn1 #63 我现有的收藏，电视剧算它 50 季每季 12 集共 600 集就算它折合 200 部电影吧，再加上真的电影大约 300 部，一共 500 部长片。假设每部长片原盘 50G，一共 25T，如果用 4T 硬盘需要 7 个，6T 硬盘需要 5 个。
我现在能把这些收藏塞进半个 2T 的移动硬盘。
分享给别人的时候，硬盘对拷每部按秒计，走互联网比如奶牛快传按分钟计，这样的便捷性和便携性说不羡慕是假的。

@ungrown #65
各人取舍不同吧
我有十多个硬盘存放视频，最小 3T，最大 8T，约 2W 个视频文件，已整理 1.3W （数据库管理），不含小姐姐（已戒）
但原盘不多，主要是来源不可得，原盘多数要 pt，耗时、注册门槛等等
除去 pt 外，能找到更高质量的，就会把原来保存的低质量文件替换掉，但前提还是“有”，所以有些老旧的 rmvb 没找到更好的情况下还留着

我习惯被动慢分享，emule，好处是挂上硬盘就行，bt 难以整盘分享（不可能全盘做一个大种子吧）
另外不使用网盘分享，一来身份安全考虑，二来不喜欢主动上传

这帖子技术讨论是不错 但是从场景上看 闲的蛋疼 有啥转的必要？

居然在 V2EX 上看到了 QSV

@imn1 #66 懂的懂的，就是想勾引你嘛，“来玩嘛~换换口味嘛~”

这位大兄弟貌似我见过，之前有个帖子吵的火热，好像是关于 B 站视频的？？？？但为啥我没翻到相关记录呢？？？

有没有比较一下 ios 上的 HEVC，我现在基本都用 ipad 生成 HEVC，体积减少不少，画质肉眼看不出变化

@imn1 数据库管理是自己搞的？我都是用 tinyMediaManager 整理

@shinko #72
自己写的 PyQT5

@EasyProgramming #70 你点我 ID 进主题找呗，反正帖子原样保留。

@imn1 #73 用的哪种格式？兼容 kodi 吗？

@ungrown #75
就是 python+Qt5(pyqt5)，kodi 没用过，不晓得

1 、本身 x265 发展快十年了，可调性非常大，你这么测其实没有任何意义。

2 、0202 年了，现代的画质对比就是要用放大镜看的，没意识到这点说明你还没有悟。你若关注 av1 项目，再跟 x265 全高（概念）设置对比，恨不得画面要放大到 x20 来看区别

任何参数调整都是在速度、体积、画质三者之间取舍，而这三者从来不可兼顾，最终也是按需选取一个并不平衡的“平衡点”。
默认参数正是那个三者正中间、最平衡、但反而不一定符合某些需求和场景的点，但默认参数的结果也自然成为整个参数空间函数输出值域的一个基准点，手动调参后在速度、体积、画质上呈现出来的变动都将以默认参数为中点辐射开来。
而 hevc 和 avc 的区别是系统性的而非局部的，它们默认参数的导致的结果本身就是是两个相距甚远的平衡点，它们进行调参后各自辐射开来的值域空间也将各自独立，也许会有部分相交，但不相交的部分才是大头。
最直观的，再怎么调参也不会缩小速度上的差别，再怎么调参也不会让 hevc 在小色块上的涂抹感降低到 avc 的水平。这就是系统差异。

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

综上，结论有没有意义我不知道，讨论其意义本身才是意义，数据是实打实的价值，有表可查是莫大的幸福。至于悟，我悟不悟我不知道，也没人能自己说自己悟的这没法证伪，你在猪鼻子插葱，装悟，这倒是能切实体会出来。

再怎么说 1G 的电影太细了 你压制会飞也没用 还有讨论一直没说音频的问题 我觉得好体验 音频占一半 还有各种标准一直变化 自己维护成本太高了 你充值破站让他把所有片买下比较好

@101992315 #79 云端播放体验永远没有桌面端好
音频我万年雷打不动 AAC 128kbps 封顶，如果是以人声为主的音频码率上限还会继续下降到 64
找不到好方法就是再多硬件软件加持也让人头大，找到好方法设计好流程无非是闲暇之时后台跑个脚本点两下鼠标敲几下键盘的事情
另外我愿意花 10 倍大会员求 B 站把以前盗版时代的番剧、影视等等资源连通原有的丰富弹幕统统恢复
谁要看他买来的？当年我没自己压制自己传，跟优酷新浪土豆斗智斗勇，观众积极热情地在弹幕里营造气氛提供背景知识充当旁白，那几年的 B 站体验不比现在的正版化歌舞化后的小破站好一万倍？你别提什么狗屁正版化，正版化光惦记着赚钱体验反而大退步它不怪自己还有理了？

@101992315 #79 另外，“太小不好”、“自己压没意义”之类的论调，真的只在国内互联网看到，我也不知道他们是真心这么想，还是为了给自己的不作为找借口、找合理化的理由。

国外小体积高清的压制、发布非常火热，我也是本楼里受到某位网友指引了解到 yts(yify)后才逐步打开这个“新世界”的大门，并顺藤摸瓜发现了更多的小体积高清压制组。原来国外这么多愿意在小体积高清这个领域耕耘的人，原来国外的压制组不会带着鄙夷去嘲讽大硬盘时代对小体积需求的用户群、反而是积极地拥抱这个群体、为他们贡献劳动和想法。

yts(yify)的小体积略有缺憾，因为仍然不采用 hevc 编码，不得不对音频质量进一步压制，以至于其发布的 720p 的音频只有 80kpbs，总体积约 1GB 。
另一个组 HETeam(crazy4tv)发布的电影剧集清一色 720p hevc，但音频有两个版本，2.1 和 5.1 的，也算是兼顾了你这样对立体声有需求的人群，2.1 版本的单部电影体积在 500~900MB 。
讲真，我很庆幸发了此贴，因为最大的收获就是了解到 yts 站并找到更多类似的压制组，我试了几个种子，速度飞快资源数很多，国外巨量用户对这类资源颇为青睐，以后我确实几乎不再需要自己压制电影和剧集了，除非是找不到现成的。

@zhuangku556 #53
yts(yify)的小体积略有缺憾，因为仍然不采用 hevc 编码，不得不对音频质量进一步压制，以至于其发布的 720p 的音频只有 80kpbs，总体积约 1GB 。
另一个组 HETeam(crazy4tv)发布的电影剧集清一色 720p hevc，但音频有两个版本，2.1 和 5.1 的，兼顾了对立体声有需求的人群（我没有），2.1 版本的单部电影体积在 500~900MB 。

@black11black #77 这是本来想回复你的，但是当时忘了 at 你，今天翻旧帖找别人留的网站地址发现了，补上：

任何参数调整都是在速度、体积、画质三者之间取舍，而这三者从来不可兼顾，最终也是按需选取一个并不平衡的“平衡点”。
默认参数正是那个三者正中间、最平衡、但反而不一定符合某些需求和场景的点，但默认参数的结果也自然成为整个参数空间函数输出值域的一个基准点，手动调参后在速度、体积、画质上呈现出来的变动都将以默认参数为中点辐射开来。
而 hevc 和 avc 的区别是系统性的而非局部的，它们默认参数的导致的结果本身就是是两个相距甚远的平衡点，它们进行调参后各自辐射开来的值域空间也将各自独立，也许会有部分相交，但不相交的部分才是大头。
最直观的，再怎么调参也不会缩小速度上的差别，再怎么调参也不会让 hevc 在小色块上的涂抹感降低到 avc 的水平。这就是系统差异。

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

综上，结论有没有意义我不知道，讨论其意义本身才是意义，数据是实打实的价值，有表可查是莫大的幸福。至于悟，我悟不悟我不知道，也没人能自己说自己悟的这没法证伪，你在猪鼻子插葱，装悟，这倒是能切实体会出来。

@black11black #77 为了方便你查看上下文，把你先前回复我的评论复制如下：

1 、本身 x265 发展快十年了，可调性非常大，你这么测其实没有任何意义。

2 、0202 年了，现代的画质对比就是要用放大镜看的，没意识到这点说明你还没有悟。你若关注 av1 项目，再跟 x265 全高（概念）设置对比，恨不得画面要放大到 x20 来看区别

@ungrown 写这么长也不嫌累，压制圈真是人傻 B 事多....你要真懂，也不会用 hevc 和 avc 来形容，hevc 就一容器，编码器本身就千变万化，别提参数，当初 x2652.0 动画压制圈为了测平衡点做了多少测试，像你这种找个编码器找个默认参数然后奉为圭臬的也是逗。不用回了，block 了

@black11black 屏蔽完还特意告诉我别回了难道就能显得你大度机智吗？难道就能掩盖你的理亏愚钝吗？难道就能让你的观点自动变成正确的吗？

我要懂什么才能用 hevc 和 avc 这两个词？这俩词都指代压缩标准，你不懂的话可以去看 wiki 。而现实语境中，hevc 经常拿来指代 h265 编码或者编码器本身，avc 倒是在语境中用的不多，但是只要有人讲大家就能听懂是什么。

当初测试 x265 编码器的不只是国内动画压制圈，全世界压制组有闲的都多多少少参与了，因为当初大家不知道什么样的参数能达到什么样的结果。

压制组压片讲究具体片源具体调参。片源质量好的话可以省不少精力，否则就要加滤镜、跑 avs，分片段分场景调整参数，因为一套参数不适合全片。

压制组付出这么多，是因为他们最后发布的成品必须是高品质的，因为不乏高清收藏党们对画质音质有着颇高的要求。

但也不乏就听个响、看个故事的人，这样的人实际上非常多，所以压制组也不是每个都追求质量、花大功夫去调参，那些 0day 组、为了让看客尽快看上片的速发型字幕组，都是用简单参数快速压一遍，力求尽快发布。当然这些组的作品质量是入不了高清收藏者的法眼的，但它们自有受众。

那么，像我这种找个编码器简单设置几个参数的到底逗在哪里呢？逗在不会装逼？逗在践踏了你心目中复杂参数模式的优越性？还是因为你自己心虚理亏又不知道如何反驳又不敢撕毁自己伪君子的面具对我恶言相向，所以不得已用了“逗”这个字，来指望我会因为这个字就被你吓住，然后妄自菲薄自惭形愧？

难怪你还要结尾来个拉黑通知勿回的无脑三连，原来你是真的心中憋了气但拳头无处挥。

然后最为可笑的一点是，本文意图实验在相似画质时这几个编码器输出的文件大小和所需时间的差异关系。你自以为是自行脑补的“圭臬”是从哪里看出来的？

写到这里我好像有点明白你一直念叨的这么测没意义是什么意思了，合着你以为编码器默认参数压根发挥不出它的效能？

假如你真的这么认为的话，那真的是要让人笑掉大牙了。因为默认参数固然是不能达到最期望的输出，要想输出符合自己需求是必然要调参的。但是你无论怎么调参，你都逃不了必须在画质、体积、速度里面取舍，这在我前面回复你的时候就重点讲了。

同一个编码器，你可以通过细调参数来获得更精致的画面，但是压制所需的时间就会变长，文件体积也会变大，因为需要更多的运算来分析图像，描述图像中的细节也需要更多的数据量。

此外，同画质 hevc 编码所需要的时间是 avc 的几倍，文件体积则可以下降 30 ％左右最多可以减一半，这不需要我做这个实验，业界早已有了大量的实验数据来支持这个结论。

那么请问你能通过调参，让 avc 的码率利用率反超 hevc 吗？不能。
你能通过调参让 hevc 的压制速度超过 avc 吗，不能。
你能通过调参让 avc 变得像 hevc 一样适合超高清分辨率但同时对像素块的涂抹现象更严重吗？不能。

所以将变量控制为只有 crf 一个参数，才能使这样的实验变得有意义，因为只有一个参数变化，所以实验结果反应的是各个编码器的平均表现随着这个参数变化而发生的变化。

连这点都看不出来，说明你是缺乏实操经验的人。也难怪你不停地拿我跟压制组比，合着你是想借压制组的模式来打压我的方法，因为你自己没有能拿得出手的经验。这一招贼喊捉贼用得也太显眼了。

最后，总有人辩不过别人就嘲笑别人“写这么多累不累”，以此来妄图给自己挽回点颜面。殊不知这一招纯属自损，在原有的理亏愚钝的短板上，又加了两块：人懒、笔弱。不然也不至于会灰溜溜拉黑逃跑，是不是？