视频转码是否是核心/多线程越多速度越快消耗时间越小？

[Lunatic1]

最近有接近 30T 的小姐姐的要转码，PC 是 5600X 感觉速度有点慢，我看一些 CPU 评测好像核心越多对转码速度的提升越快是这样子吗？ 所以打算组一台志强的洋垃圾去做这个工作，请问这样能加快效率吗？

[also24]

“单核性能接近的情况下” ，核心越多，转码速度越快

志强洋垃圾，大概率不满足 “单核性能接近”

[cest]

要是就纯转码+电费自己出，不考虑 a380 吗？
还能转 av1

[chonger]

如果本身就是 h264 ，再 2 次转码的意义不大吧，有这个功夫还不如添块硬盘

[mortal]

为什么不用 GPU 转

[Lunatic1]

@chonger 主要是想做压缩的动作，毕竟 30T 的内容还是太多了
@mortal 现在在用 HandBrake 去做压缩，还没有找到可以硬解压缩的方式....

[mortal]

@Lunatic1 #5 研究一下吧，Handbrake 支持硬件编解码的。你的 GPU 是什么？

[Lunatic1]

@mortal 3070 ，之前研究过设置之后还是 cpu 在跑，应该配置有问题

[msg7086]

@cest @mortal GPU 转完质量爆跌，还不如不转。要是保持同等质量，说不定容量还会涨。
GPU 转码都是给你串流直播用的，谁拿来做长期存储啊。

@Lunatic1 30T 真不多，这点硬盘钱比你转码便宜多了。

[L4Linux]

@msg7086 Turing 和 Ampere 质量和 CPU 差不多，Arc 比 CPU 好。

[tool2d]

@msg7086 低码率下 CPU 完胜，高码率下 GPU 和 CPU 画质半斤八两，没特别大的区别。

[gdyong]

感觉整个 nas 实际点吧，不是商业用，这么转劳心劳力

[ZRS]

建议 GPU

[Aloento]

AV1 + GPU 加速

[ryd994]

你折腾这些的时间已经够买双倍的硬盘了
而且这些东西源源不断有新的，再下就是了，没必要长期保持

[msg7086]

@tool2d 高码率下码率过剩，当然差不多了。但楼主是要把片压小啊。

@L4Linux Arc 是要用了 av1 才比 x264 好吧，2022 年的格式勉强胜过 2005 年的编码器……

[billytom]

买块 Intel Arc A380 显卡，压成 AV1 来存放吧，目前唯一支持硬件编码的 GPU

[L4Linux]

@msg7086 还有 x265 啊

[litguy]

16TB 企业级硬盘 1.5K 就能搞定，别折腾了

[Lunatic1]

@gdyong 已经有 nas 了用的是 4130,因为刷的黑裙 617 显卡不能直通，直接用 cpu 转码性能也太慢了...之前也尝试过。

[mortal]

@msg7086
不是杠，楼主是压小姐姐，看着导管的罢了，质量那么重要吗？相信楼主在线看也能导的吧…毕竟不是收藏电影，质量太差他自己也会接受不了然后不压缩吧。
当然，最省心的是买硬盘，非要压缩那肯定选 GPU ，CPU 猴年马月去了？质量没你想象那么差。我字幕组搞压制的都用 GPU 。

[chutsetien]

@mortal 用 hevc_nvenc 压，将 4K 源压 1080p, 参数设为

-vf scale=-1:1080:flags=lanczos+accurate_rnd+full_chroma_inp+full_chroma_int [-pix_fmt yuv444p16le -c:v hevc_nvenc -preset slow -rc vbr -cq 0 -qmin 2 -qmax 23 -spatial-aq 1 -aq-strength 15 -bufsize 20M -rc-lookahead 64 -refs 16 -bf 3 -b_ref_mode middle] -c:a libfdk_aac -ac 2 -b:a 320k

得到的结果基本上是原 4K 文件的 70% 到 80% 左右（原 4K 文件是 35Mbps 的恒定码率录像）；

其质量还不如用 libx265 压，其他参数相同，仅替换上方中括号中的部分为

… -pix_fmt yuv444p10le -c:v libx265 -preset veryslow -crf 27 …

的画面质量，而后者的文件大小在原 4K 文件的 25% 左右。

其实我还是有做一些其他的压码试验的，hevc_nvenc 将 4K 压往 1080p, 得将 -qmax 调到 20 左右画面才勉强看不出画质减退（尽管仔细比较还是能看到的），此时得到的 1080p 的文件大小已经是原 4K 文件的 120% 到 130% 左右了，也即，用 GPU 压码，如果不是将画幅缩小到 ¼ 的话，那压出来的文件至少得是原始大小的 5 倍，才能勉强维持一个可看的画质。

CPU 压码，除了慢之外，没有任何毛病。上面说的这些是自己的录像，没有经过后期处理，因此要保证质量的话得到的结果比较大。如果是网上那些 REMUX 的蓝光片源，用 libx265 去压，即使 -crf 设到 20, 1080p 压 1080p, 也能将 20+GB 的文件缩小到 2 到 3 GB 左右，压缩效率可以说是非常高了，而且画质真心不错，我一般压蓝光片源都是将 -crf 设到 20 就足矣，这样得到的结果在文件大小和画质上正好都合意。

另，目前 libsvtav1 压出来的质量很差，根本无法跟 libx265 相比。我使用最新的 libsvtav1 试着压制了一下，使用 -preset 3 -crf 33, 结果用着比 -preset veryslow -crf 20 的 libx265 还要久的编码时间，得到了一个大概近似于 -crf 25 的 libx265 压制出来的文件大小，结果停帧对比发现画质比 -crf 26 的 libx265 压出来的还要差，画面上可以看出明显的画质差异，甚至一些细节被完全抹除，这还是在开启了 -svtav1-params tune=0 去 sharpening 的前提下。

总结来说，如果追求最佳的画质和文件大小，还是得用 libx265, preset 上 veryslow 或者至少 slow, 然后 crf 设在 18 到 22 之间慢慢压、慢慢等。

[XIU2]

我以前也研究过，一些偏老偏冷门的美剧资源，没人压缩 x265 版本的，我只能尝试自己压缩，可惜我的 CPU 、GPU 都太差了。。。
CPU 压缩质量稳定，速度偏慢，GPU 压缩质量肉眼可见的下降，但速度快很多（即使我的是低端显卡）


因为我平时都是在 RARBG 下载美剧的，所以我也尽力参考 RARBG 压制的 x265 效果。
查询后发现 RARBG 的应该用的是 二次编码（ Two-Pass Encoding ），来指定最终文件码率为固定的 2000kbps 整，我也尝试过，但速度太慢，相当于耗时翻倍。。。


最后经过取舍，选择 -crf 23 来把 x264 压制成 x265 的，并且音频压制为 224k （听不出来），这样文件大小合适（三分之一）且画面损失很小（只有一些脸部特写的皮肤纹理能看出差异），可惜我的 CPU 太弱了，压制速度基本上稳定在 1.0 ，即压制 40 分钟的视频大概需要 40 分钟，压制一季美剧就要花费 10 个小时。。。


所以我每隔一段时间，就要去 RARBG 瞅一瞅，说不定 RARBG 就帮我压制好了，我记得当初 小谢尔顿 我花了好几天才压制完了 4 季半，结果第 5 季完结的时候，RARBG 直接全都给 x265 压制了一遍。。。

[joynvda]

个人感觉，最好挑有 AVX 指令集的。

[mortal]

@chutsetien #21

你的经验当然是非常有用的，本站也有了很多编码相关的讨论，没有什么值得争论的点。
楼主如果决定为了质量采用 CPU 软压，他大概是要换一块 5900x 然后花费大量的时间，然而这价格都已经可以买 32T 的矿盘了。
压制这件事没有对和错，无非是不同的目的去取舍，去采用适合自己的硬件和参数。

我认为在有 3070 的情况下，采用 2-Pass VBR + HEVC B frame 就行了。

[Licsber]

分享一下我的参数
ffmpeg -y -threads auto -i "$1" -c:v libx265 -vtag hvc1 -bf 4 -crf 23 -preset slow -qmin 10 -qmax 52 "${1%.*}.enc.mp4"

[msg7086]

@mortal 请问阁下是哪个字幕组的？

[msg7086]

@L4Linux av1 硬件压缩干不过同码率 x265 。

[L4Linux]

@msg7086
https://cdn.mos.cms.futurecdn.net/hGy9QffWHov4rY6XwKQTmM.png

[msg7086]

@L4Linux 找了很久才找到出处 https://www.tomshardware.com/reviews/intel-arc-a380-review/5 。
但是这帖子我没看到哪里写了用了什么 x265 的参数。如果用了默认参数，也就是 medium 质量的话，被 av1 超过也正常。但我们压片，没事真不会用 medium 。至少也是从 slow 开始跑，好一点的组会用到 slower 或者 very slow 。

另外你之前提到了图灵上改进过的 h.264 编码器。这个之前已经有人测试过了，比不上 x265 slow 。

不管是哪种编码格式，硬件编码归根结底还是常用于串流，不管是主播串流也好还是 plex 家用移动设备串流也好。真正想要花时间精力去做「收藏」或者「发布」的时候是不会去用的。

[msg7086]

@msg7086 图灵上改进过的 h.265* 编码器

[L4Linux]

@msg7086 你说 x264 有 slow 那 oneVPL 和 NVENC 也有 slow 啊。这个评测设的是 bitrate 不是 quality 。设 quality 之后 bitrate 是变的，这怎么比？同码率质量比 x264 高还说明不了质量？

[kokutou]

你搜下洋垃圾志强的跑分。。。说不定还比不过你的 5600x 呢。。。

AMD 降价了，买个 7950x 支持下苏妈吧。

[chutsetien]

@L4Linux NVENC 的 slow 一点用都没有。实际上，hevc_nvenc 把所有能调的参数都调到最佳，也仍然差的要命。不是差一点半点，而是差的要命，真的很要命。转换后的结果是转换前的两倍大，画质反而还下降了。就这么渣。

[msg7086]

@L4Linux 道理我都懂，但我说的是 preset 不是 quality……而且我说了，同码率质量是可能比默认的低参数要好，但是正经人谁会开低参数。

还是说你不知道质量和预设这两个东西的区别？

[YAFEIML]

ShanaEncoder 吧，hevc(nvenc)，量化器 24 ，音频 acc 128 ，你可以先压一部测试下，我这边也是时间换空间压了不少。

[7qbsx2kl]

大批轉碼壓縮可以試試 Tdarr

[mortal]

@msg7086 #26

我所在的字幕组是个很小的用爱发电的组，只有一台托管在机房的服务器兼压片和做种，CPU 只有八核，不用 NVENC 硬编根本无法及时处理掉压制队列。大部分用户还是用百度盘在线看二压的呢，都能忍受画质，没有那么多火眼金睛的，他们只在乎第一时间看到。国外压蓝光原盘的 Ripper 也有用 Staxrip 去硬编的。存在即合理。

你 CPU 强大是你的优势，楼主这个现状是我们压根都不知道片源是个什么情况，也不知道他自己到底是什么需求、看不看得出来区别，所以辩论是没有太多意义的。更何况最终结论都一致认为不如直接买硬盘了，而且 @L4Linux 也提供了一些硬编至少没有你说的那么不堪的证据。