最近有接近 30T 的小姐姐的要转码,PC 是 5600X 感觉速度有点慢,我看一些 CPU 评测好像核心越多对转码速度的提升越快是这样子吗? 所以打算组一台志强的洋垃圾去做这个工作,请问这样能加快效率吗?
1
also24 2022-11-04 23:58:02 +08:00
“单核性能接近的情况下” ,核心越多,转码速度越快
志强洋垃圾,大概率不满足 “单核性能接近” |
2
cest 2022-11-05 00:15:35 +08:00
要是就纯转码+电费自己出,不考虑 a380 吗?
还能转 av1 |
3
chonger 2022-11-05 00:19:33 +08:00
如果本身就是 h264 ,再 2 次转码的意义不大吧,有这个功夫还不如添块硬盘
|
4
mortal 2022-11-05 00:21:45 +08:00
为什么不用 GPU 转
|
5
Lunatic1 OP |
8
msg7086 2022-11-05 01:09:36 +08:00
|
11
gdyong 2022-11-05 01:26:03 +08:00 via Android
感觉整个 nas 实际点吧,不是商业用,这么转劳心劳力
|
12
ZRS 2022-11-05 01:56:43 +08:00 via iPhone
建议 GPU
|
13
Aloento 2022-11-05 02:25:51 +08:00
AV1 + GPU 加速
|
14
ryd994 2022-11-05 05:43:52 +08:00 via Android
你折腾这些的时间已经够买双倍的硬盘了
而且这些东西源源不断有新的,再下就是了,没必要长期保持 |
15
msg7086 2022-11-05 06:24:50 +08:00
|
16
billytom 2022-11-05 06:53:46 +08:00 via Android
买块 Intel Arc A380 显卡,压成 AV1 来存放吧,目前唯一支持硬件编码的 GPU
|
18
litguy 2022-11-05 09:18:22 +08:00
16TB 企业级硬盘 1.5K 就能搞定,别折腾了
|
19
Lunatic1 OP @gdyong 已经有 nas 了用的是 4130,因为刷的黑裙 617 显卡不能直通,直接用 cpu 转码性能也太慢了...之前也尝试过。
|
20
mortal 2022-11-05 09:24:06 +08:00 via iPhone
@msg7086
不是杠,楼主是压小姐姐,看着导管的罢了,质量那么重要吗?相信楼主在线看也能导的吧…毕竟不是收藏电影,质量太差他自己也会接受不了然后不压缩吧。 当然,最省心的是买硬盘,非要压缩那肯定选 GPU ,CPU 猴年马月去了?质量没你想象那么差。我字幕组搞压制的都用 GPU 。 |
21
chutsetien 2022-11-05 09:55:21 +08:00 3
@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 之间慢慢压、慢慢等。 |
22
XIU2 2022-11-05 10:27:39 +08:00 1
我以前也研究过,一些偏老偏冷门的美剧资源,没人压缩 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 压制了一遍。。。 |
23
joynvda 2022-11-05 11:17:30 +08:00
个人感觉,最好挑有 AVX 指令集的。
|
24
mortal 2022-11-05 11:55:10 +08:00
@chutsetien #21
你的经验当然是非常有用的,本站也有了很多编码相关的讨论,没有什么值得争论的点。 楼主如果决定为了质量采用 CPU 软压,他大概是要换一块 5900x 然后花费大量的时间,然而这价格都已经可以买 32T 的矿盘了。 压制这件事没有对和错,无非是不同的目的去取舍,去采用适合自己的硬件和参数。 我认为在有 3070 的情况下,采用 2-Pass VBR + HEVC B frame 就行了。 |
25
Licsber 2022-11-05 12:19:47 +08:00
分享一下我的参数
ffmpeg -y -threads auto -i "$1" -c:v libx265 -vtag hvc1 -bf 4 -crf 23 -preset slow -qmin 10 -qmax 52 "${1%.*}.enc.mp4" |
28
L4Linux 2022-11-05 13:24:36 +08:00 via Android
|
29
msg7086 2022-11-05 14:47:50 +08:00
@L4Linux 找了很久才找到出处 https://www.tomshardware.com/reviews/intel-arc-a380-review/5 。
但是这帖子我没看到哪里写了用了什么 x265 的参数。如果用了默认参数,也就是 medium 质量的话,被 av1 超过也正常。但我们压片,没事真不会用 medium 。至少也是从 slow 开始跑,好一点的组会用到 slower 或者 very slow 。 另外你之前提到了图灵上改进过的 h.264 编码器。这个之前已经有人测试过了,比不上 x265 slow 。 不管是哪种编码格式,硬件编码归根结底还是常用于串流,不管是主播串流也好还是 plex 家用移动设备串流也好。真正想要花时间精力去做「收藏」或者「发布」的时候是不会去用的。 |
31
L4Linux 2022-11-05 16:03:00 +08:00
@msg7086 你说 x264 有 slow 那 oneVPL 和 NVENC 也有 slow 啊。这个评测设的是 bitrate 不是 quality 。设 quality 之后 bitrate 是变的,这怎么比?同码率质量比 x264 高还说明不了质量?
|
32
kokutou 2022-11-05 16:15:08 +08:00 via Android
你搜下洋垃圾志强的跑分。。。说不定还比不过你的 5600x 呢。。。
AMD 降价了,买个 7950x 支持下苏妈吧。 |
33
chutsetien 2022-11-05 16:48:21 +08:00
@L4Linux NVENC 的 slow 一点用都没有。实际上,hevc_nvenc 把所有能调的参数都调到最佳,也仍然差的要命。不是差一点半点,而是差的要命,真的很要命。转换后的结果是转换前的两倍大,画质反而还下降了。就这么渣。
|
34
msg7086 2022-11-05 17:00:08 +08:00 via Android
|
35
YAFEIML 2022-11-05 17:06:01 +08:00
ShanaEncoder 吧,hevc(nvenc),量化器 24 ,音频 acc 128 ,你可以先压一部测试下,我这边也是时间换空间压了不少。
|
36
7qbsx2kl 2022-11-05 19:56:05 +08:00 via Android
大批轉碼壓縮可以試試 Tdarr
|
37
mortal 2022-11-05 20:22:51 +08:00
@msg7086 #26
我所在的字幕组是个很小的用爱发电的组,只有一台托管在机房的服务器兼压片和做种,CPU 只有八核,不用 NVENC 硬编根本无法及时处理掉压制队列。大部分用户还是用百度盘在线看二压的呢,都能忍受画质,没有那么多火眼金睛的,他们只在乎第一时间看到。国外压蓝光原盘的 Ripper 也有用 Staxrip 去硬编的。存在即合理。 你 CPU 强大是你的优势,楼主这个现状是我们压根都不知道片源是个什么情况,也不知道他自己到底是什么需求、看不看得出来区别,所以辩论是没有太多意义的。更何况最终结论都一致认为不如直接买硬盘了,而且 @L4Linux 也提供了一些硬编至少没有你说的那么不堪的证据。 |