这是一个创建于 1635 天前的主题，其中的信息可能已经有所发展或是发生改变。
如果用 H.265 标准压片
都知道 GPU 相对 CPU 的速度是有显著增益的
但搜了下有说 GPU 出来的画质差 CPU 画质很多
也有说差异不大的
说画质差异大的：把码率稍微调高点，两者画质差异就不大了
所以画质上，上面的理论哪个更准？
还有就是 N 卡阵营里，1650Ti 和 2060，压片速度有多大差异？
都知道 GPU 相对 CPU 的速度是有显著增益的
但搜了下有说 GPU 出来的画质差 CPU 画质很多
也有说差异不大的
说画质差异大的：把码率稍微调高点，两者画质差异就不大了
所以画质上，上面的理论哪个更准？
还有就是 N 卡阵营里，1650Ti 和 2060，压片速度有多大差异？
 |
1
May725 2020-07-02 13:58:35 +08:00 via iPhone  20
是的，不仅如此，用电也有讲究，风电柔，火电画面燥点就比较多，用水电就比较中性了，通常以三峡水电站的为佳。狗头
|
 |
2
zhangsimon OP 10
@May725 这个梗已经一点意思都没有了…
|
 |
3
Cavolo 2020-07-02 14:12:14 +08:00
这问题似乎也没什么意义
|
|
4
zhangsimon OP @Cavolo 什么意思？
|
 |
5
woodensail 2020-07-02 14:23:49 +08:00
https://www.zhihu.com/question/303525717
搜索引擎是个好东西。 |
 |
6
across 2020-07-02 14:28:30 +08:00 via iPhone
那是性能差异。
标准都一样，参数一样，出来的不同，不是 bug 么.... |
 |
8
kop1989 2020-07-02 14:33:16 +08:00 2
@across #6 还真不是，一开始我和 1L 的想法一样，以为是玄学。
后来一想可能有道理，因为 CPU 和 GPU 的架构设计不同，算法不同。相同码率出来的视频确实可能不一样，一搜还真是如此。 |
|
9
zhangsimon OP @azh7138m N 卡哪款现在压片性价比比较高啊 0，0 看什么参数？
Nvdia 倒是给了 Video Encode 的性能列表，但我不清楚该对比哪个数据… https://developer.nvidia.com/video-encode-decode-gpu-support-matrix#Encoder |
 |
10
libook 2020-07-02 14:49:32 +08:00 1
画质和转码参数有关，和用什么硬件没关系。
要选择什么硬件搭配，要看你压片用的软件用了哪些硬件的接口，这方面去问软件的开发者，或者看官方文档就行了。 |
|
11
libook 2020-07-02 15:13:40 +08:00
补充一下，很多视频转码软件对 GPU 的利用非常有限，很多都是完全依赖 CPU 来做转码的，用上了 GPU 也仅仅是借用部分功能来适当提升性能。
如果你的软件能利用硬件编码、解码器的话，不出意外的话是新出的硬件会好，相比于旧硬件做了优化以及修复缺陷，硬件编码、解码器通常因为算法固化在硬件上了所以通常无法通过打补丁的方式改进。 我司的产品主要就是视频，压片常年就是 FFMPEG+i7 4790k，没有用任何 GPU 。选型这方面理论只是给你一个大概的方向，实际还是得看文档、问开发者、做压测。 |
 |
12
futou 2020-07-02 15:36:57 +08:00 1
如果问的是软编码和硬编码哪个在相同码率下能得到更高的质量，在不考虑加特技的条件下，[当前]一定是软编码更好。因为硬编码一定会阉割掉一些高计算复杂度的技术。而且当前的视频编码框架天生不适合 gpu 这种多核架构，gpu 那么多 cuda 核心也就在 memc 这种地方有用武之地，还很难用。不过英伟达是个 bug，有 nvenc，过两年一切都很难说了。利益相关：软编算法...
如果问的是 intel 的 QuickSync 和英伟达的 nvenc 的话，我不懂...不过要比画质的话，只要是在相同码率下对比就行。 |
|
13
zhangsimon OP @futou 就是看中了 N 的 nvenc ；
上面 Nvida 参数列表里给出了 number OF NVDEC/CHIP 参数，那就看这个数量来衡量显卡的 H.265 转码效率吗？ |
 |
14
msg7086 2020-07-02 15:44:35 +08:00 4
@across 是标准又不是实现。
现代视频编码很大一部分实现在于动态预测，换句话说就是在画面里找出「动了的部分」，这样就可以重用之前编码过的数据，提高编码效率。 比如，第 1 帧的时候画面上有一只手，第 2 帧的时候这只手往右移了 2cm 。 可能 x265 编码器在跑第 2 帧搜索的时候找到了这只手，于是重用了第 1 帧里的这只手来编码，节约了不少码率。 而 nvenc 在跑的时候可能这只手他没找到，就只能老老实实把手重新画一遍。 这两个流跑出来的画面结果是相同的，但是因为 x265 节约了一只手的码率，所以同样画质下容量小了很多。 差异主要来自这里。 |
 |
15
LiYanHong 2020-07-02 15:45:11 +08:00
KBr 压片比较常见，不过我们现在的仪器可以直接测固体粉末了
|
|
16
futou 2020-07-02 15:45:57 +08:00
@zhangsimon 不好意思，应用上建议参照#10 #11，以及 b 站油管搜一搜，我外行不懂
|
|
17
zhangsimon OP @msg7086 喵喵喵 那 N 卡 转码效率 看 nvenc 核心数就可以了吗？ 我看 Nvidia 官网给的 1650 到 2080 里，nvenc 都是数字 1… 所以他们跑起来速度差异不大？
|
|
18
msg7086 2020-07-02 15:48:50 +08:00
@zhangsimon 视频编码的核心问题是：
如何让（画质 / 大小）的值尽可能高。 单看画质没有意义，因为只要你把码率逼近到无穷大，画质可以做到无损。但是显然无穷大没有意义。 单看大小也没意义，只要把画质压烂，文件自然能变小。 所以视频编码的效率就是单位大小上的画质。 比如同样给 1000kbps，谁更保真？或者同样画面保真度的情况下，谁能压得更小？ |
|
19
zhangsimon OP @msg7086 -- 我理解画质和码率直接的关系。我意思是我想选用 N 卡的加速的话，选显卡时看显卡的哪个参数…
|
|
20
msg7086 2020-07-02 15:51:57 +08:00
@zhangsimon #17
我们一般把速度叫做编码速度，画质大小比值叫做编码效率。 速度的话我倒是不太清楚，因为我不用 nvenc 的。你可以找找各种显卡的测评，有些可能会测 nvenc 速度，可以给你一定的参考。 |
 |
21
ohao 2020-07-02 15:54:46 +08:00 via iPhone 4
这问题很复杂
我们相关研究有好几年，大概有几百篇内部文档了 从前从 cpu 开始测试，e3 e5 系列，一直到 i7 i9 系列 后来因为效率，又开始测 gpu，从 1080，2070s，2080ti 最近开始测了最新的 e2288 处理器的核显 测试 cpu 的 cbr vbr crf 各种模式 测试 gpu 的 n 卡 cuda 和 intel 的 qsv 各种工况下的处理效率 帧 质量 有无花屏容错等等 这个效果取决于你的需求 视频处理速度 /视频文件输出大小 /处理适配的规则 还有很多外在因素 比如源视频是什么编码器输出的，音频什么编码器和码率 你重新转码的时候，选择的模式是恒定还是可变，还是指定清晰度，这个主要是靠参数来调， 实际上我们现在调到测试 gpu 和 cpu 视频质量一致（肉眼无法区分）的时候，输出文件大小也相差不大 所以这个问题本身是没正确答案的 还是靠参数和需求来定 |
|
22
zhangsimon OP @ohao 哭了，我就想压 h.265 的视频，对画质和文件大小要求一般，就是希望速度快点。
我就是看 GPU 在压制速度上这一块是优势，所以在考虑下一台硬件把 GPU 预算上加强； 但我搜了下文章好像说 2060 对比 1060 这种看上去其他参数差异很大的显卡，在压片上差异又不大， 所以在求证压片时，选显卡的话应该看显卡的哪个硬件参数… |
|
24
msg7086 2020-07-02 16:29:39 +08:00
@zhangsimon Turing 的编码器相比之前几代又有提升了，据说和 x265 的 ultrafast 有得一拼。
不知道你具体的使用场景是什么。通常不考虑画质和大小的硬件编码主要是用在串流上，比如直播，还有比如串流到移动设备上观看等等。如果是要收藏存储的话，应该不会考虑用这么低的参数来压制，我觉得至少也要到 x265 medium 的级别才有使用的价值。 |
|
26
ohao 2020-07-02 17:07:45 +08:00 1
|
 |
27
wangsd 2020-07-02 17:08:43 +08:00
压制出来的体积会差不少
|
 |
29
zhs227 2020-07-02 17:24:18 +08:00 1
在 AVC 时代，x264 在很长一段时间内被公认为画质最好的编码器。但是 HEVC 时代 x265 并没有压倒性的优势。同样压缩率的情况下，先编几个场景用肉眼评估一下，如果区别不大就选那个快的。
|
|
30
zhangsimon OP @ohao 收到👌 多谢
|
|
31
zhangsimon OP @zhs227 -。-手上如果有测试环境我肯定直接跑了，现在是想升级硬件，想看升级哪款显卡压片价值更高些…
|
 |
32
edius 2020-07-02 18:16:29 +08:00
可以肯定的是 GPU 的编码质量要差一些。FCPX 下如果直接输出 H264，输出速度非常快，在活动监视器里能看到 GPU 能工作到满载，CPU 不怎么工作，如果调用 compressor 输出，GPU 基本不怎么工作，CPU 压制。265 格式不确定，在 DVD 时代，专业的视频编码卡输出画面质量一定高于 CPU 压缩。
|
|
33
edius 2020-07-02 18:19:12 +08:00
如果 GPU 压缩质量高，苹果就不会再单独开发一个编码软件 compressor 了。ADOBE 编码也有单独的软件 encoder.而 canopus，matrox 都有专业编码卡。
|
 |
34
happinessnch 2020-07-02 18:33:23 +08:00
和 11 楼想法一样，
和硬件没有关系，用 CPU 计算出来的结果为什么 GPU 算出来的不一样？ 如果是不一样肯定是 BUG， 如果算法或者参数不一样， 那也和 CPU 、GPU 没关系啊。 换一个好 GPU 算出来的数值会有变化？ |
 |
35
ayconanw 2020-07-02 18:35:05 +08:00 12
希望不懂的人，不要随便抖机灵回帖，更不要想当然的进行误导。
比如 6 楼的看法，很显然是错的。cpu 和 gpu 压视频，用的完全是两套不同的算法。 回复下楼主，目前的编码模式，cpu 在同码率（非严重溢出）的情况下，画质一定是比 gpu 更好的，但是压片速度也会相应的比显卡慢一些。静态场景还好，激烈运动场景，gpu 压出来的会比较差。 如果一定要用显卡压，注意两点，首先码率要给足够，在码率非常足的情况下，二者画质差距就比较小了。高参数极限小码率的情况下，cpu 会好很多。 n 卡尽量用图灵卡压，无论速度和画质都会比 10 系有提升。 |
 |
36
love 2020-07-02 19:00:27 +08:00
@happinessnch 这不是一个问题好吧，这不是算 hash，压视频软件和硬件算法差别大了去了。
|
|
37
happinessnch 2020-07-02 19:19:52 +08:00
@love
我从头到尾读了一遍， 你看我理解的对不对， 是不是意思是说， 由于在大部分拥有编码软件上，CPU 编码和 GPU 编码都不会使用相同的算法， 所以，就直接省略算法，可以直接讲“CPU 编码一般情况下比 GPU 编码质量好”？ 而如果这句话要完整的说，应该是“CPU 编码使用的算法比 GPU 编码使用的算法质量好”。 我理解的对吗？ |
|
38
love 2020-07-02 19:25:32 +08:00
@happinessnch 别说复杂的视频压缩了，就是简单的 zip，都有一大堆压缩库，都有不同的压缩率和速度，虽然出来的都是标准的 zip 。
|
 |
39
Semidio 2020-07-02 19:31:31 +08:00 1
编码速度优先，GPU 编码，单纯 NVENC 性能，从 1650S 到 2080TI 都一样
编码质量优先，CPU 编码，一分价钱一分性能 |
|
40
happinessnch 2020-07-02 19:32:53 +08:00
@love
12 年做过一个项目，为一家海外老牌的视频公司做硬件加速，我们用 OpenCL 重新实现其公司算法，要求就是 GPU 计算出来的编码要与现在 CPU 的计算完全相同。 “CPU 编码一般情况下比 GPU 编码质量好”，当时我们绝对不会有这样的说法，这个说法有明显的语义歧义，当然，可能是我过时了，已经快 8 年没碰过视频处理相关的内容了。 |
|
41
zhangsimon OP @ayconanw 嗯嗯，多谢对提问者的尊重哈🙏
我确实是因为看中速度才偏向于咨询下显卡性能的 但我目前搜出来的资料好像 1060 和 2060 差异不大 😂 N 卡其他参数性能差异在价格上反映还挺明显的，但在转码上好像并不和价格一致 https://www.chiphell.com/forum.php?mod=viewthread&tid=2188140 这个帖子参数里，1080 比 2080 的转码核心都多… 但我不清楚是不是只看这个数据就行了-。- 所以才来求证下 想看看哪一款是性价比较高的 |
|
42
zhangsimon OP |
 |
43
yujiang 2020-07-02 19:50:17 +08:00 via Android
CPU 和 GPU 用的显然不是同一套算法。。。架构都不一样。
目前来看如果注重质量，我偏向用 CPU 压 速度这种东西是相对的，硬件好速度就快。像 9900kx 和 gt1030 压，我说 CPU 快也没问题吧？ 非要计较速度的话，你应该去算哪个性价比高。 |
|
44
Semidio 2020-07-02 19:51:07 +08:00 1
@zhangsimon #40 Pascal 和 Turing 卡的 NVENC 版本不一样
|
|
45
zhangsimon OP @Semidio 呜呜-，- 差异在质量还是速度上…
我看官网上列的参数里，Pascal 的好像都不支持 HEVC B Frame support… Turing 的卡倒是基本都支持（除了 1650 ） 但 1080 多一个核心会有优势加成吗… -，- 好像越问越多了… |
 |
46
0ZXYDDu796nVCFxq 2020-07-02 20:00:45 +08:00 via Android
GPU 编码通常是为了实时吧，所以目标是达到 30fps 的速度？
在此前提下，压缩 |
|
47
zhangsimon OP @gstqc 囧 比这个速度高多了…
|
|
48
0ZXYDDu796nVCFxq 2020-07-02 20:03:11 +08:00 via Android
在此前提下，压缩质量不会很高
而软件可以用参数控制不同算法 软件还可以升级 我觉得还是看用途来选吧，编码量不多就只用 CPU 好了 |
|
49
0ZXYDDu796nVCFxq 2020-07-02 20:04:45 +08:00 via Android
@zhangsimon 速度高多了的分辨率、码率是多少啊
|
|
50
Semidio 2020-07-02 20:31:15 +08:00 1
@zhangsimon #43 1080 多一个核心可以同时 encode 两份文件，当然压制的画质 Turing 要比 Pascal 好一些
|
 |
52
mumujun 2020-07-02 20:51:36 +08:00 1
剪过视频就应该知道 cpu 和 gpu 压制视频的质量是存在肉眼可见的差异的，cpu 压制的明显好于 gpu 压制的。据说 rtx20xx 系显卡对此有改善，但我没试过。 @May725 你这属于无用的误导他人的发言，为了抖机灵而抖机灵不应该。
|
 |
53
luny 2020-07-02 21:08:11 +08:00
本质还是 x265 没有做 cuda 的适配吧，如果做了提升会很大
|
 |
54
gggxxxx 2020-07-02 21:09:38 +08:00
这个问题很简单。
所谓 gpu 编码，一般指的是硬件编码，严格来说有些系统并不是用的 gpu 。只不过大家叫习惯了。 所谓 cpu 编码，一般指的是纯软件编码。 从压缩算法上来说，硬件编码和软件编码理论上参数一致的话，编出来的效果一样。 但是现实中市面上几乎所有的系统，偏偏硬编和软编的参数根本不一样，所以两者出来的效果差别很大。 一般来说软编的效果比硬编好一些，主要是软编可以设置固定码率，而现在大多硬件编码只能动态码率。 再说简单点，现在 h264 或者 265 这些编码 spec 太繁杂了，一般硬件编码只实现了 spec 里的少部分，而软件编码实现了大部分。 |
 |
55
aureole999 2020-07-02 21:15:58 +08:00
有区别。如果你硬编码为了得到和软编码一样的画质而提高参数，那大小又不行了。
|
 |
56
mortal 2020-07-02 23:29:19 +08:00 via iPhone
我打算买个 1650s
|
 |
57
mxalbert1996 2020-07-02 23:40:54 +08:00 via Android
想看 N 卡的硬编码能力的话就查这里：
https://developer.nvidia.com/video-encode-decode-gpu-support-matrix 表里所有项目都一样的话编码性能不会有太大区别，因为都是用的独立的专用硬件单元而不是通用的流处理器。 |
|
58
zhangsimon OP @mortal
为啥选这款？ 1650s 支持 HEVC B Frame 吗？ N 卡官网的这个列表没有列 1650s，但是 1650 是 Turning 构架里为一个不支持的😂 还有就是 NVENC 那一栏，官网写的是 1*，而不是完整数字，这个*是什么意思啊？ |
 |
59
RicardoY 2020-07-03 00:23:10 +08:00 via iPhone
硬编码同等质量情况下文件体积会比软编码大不少...
|
 |
60
longbye0 2020-07-03 00:30:48 +08:00
@May725 硬编大体可以说质量比软编差，不是玄学，nvenc 支持的编码参数明显更少。
回楼主，RTX 系列硬编据说变好了，斗鱼开播指南： https://www.douyu.com/cms/zhibo/201903/18/9971.shtml |
 |
61
sugarsalt 2020-07-03 00:48:04 +08:00
是骡子是马拉出来溜溜呗，差异是有的，有多大，值不值，你自己各压一遍比比就知道了
|
 |
62
helloworld000 2020-07-03 05:21:20 +08:00
这种帖子都能讨论这么多也是醉了
压缩居然还讨论硬件而不是具体代码 api 实现 v2ex 现在是主流是电脑城小哥? |
 |
63
ungrown 2020-07-03 08:14:26 +08:00
首先又到了小马过河的环节，这种时候我一向主张都是优先注重自己实践的结果。
但楼主是来为选型求信息的，那我把个人经验说一说。 不太严谨地说，你可以把任何硬件编码器当成一个阉割版的编码器。区别是，阉割到什么程度，尤其是在它的目标工作场景中，相比它的工作所需要的特性，它被阉割到什么程度。 所以硬件编码器、或者硬件加速编码器，一定是牺牲一些特性的。而软件编码器中的诸多特性，都是为了提高编码效率，用尽可能小的码率实现尽可能高的画质。 硬件编码器每被阉割一个特性，就缺失了相应的算法，同码率下画质就更差，或者同画质下码率就更高。 很多年前尝试过 N 卡的硬件编码，速度快到怀疑人生，画质糊到怀疑眼睛，码率高到怀疑它是不是真的在做“压缩”而不是“扩大”。 平时不会考虑硬件编码（指 PC 上的任务，手机上由不得我选择，基本都是硬件加速），因为我压片给自己收藏是为了减小体积。但如果一定要用的话，我基本只选 intel 的 qsv 。 qsv 对于个人用户、单任务场景而言，相当优秀，画质相当凑合（一眼看去不会骂娘），码率相当凑合，速度贼快。 但如果你需要大批量多任务加速，可能 qsv 不太行。但目前 AN 两家硬件加速编码我没有经验，你得问别人，或者问其他地方。（英文互联网这类信息不会缺少，建议 Google 搜） |
 |
64
fnscar 2020-07-03 08:44:09 +08:00 1
1650super 是内置 turing nvenc chip 的显卡里最便宜的。
1650 的 gpu 是 turing 但 nvenc 是 volta 。注意别买错了。 1070/1080 虽然有 2 片 nvenc chip，从 nvidia 论坛里的反馈来看速度是只有 1 片 chip 的 turing 卡的两倍，但不支持 B 帧，压缩效率不如新的 turing 卡。 软件直接用 rigaya 的 nvencC，参数最丰富，比 ffmpeg 的 libnvenc 好用。 rigaya 的博客里也有 nvenc 、qsv 、vce 、x264 、x265 的对比。 |
 |
65
stoneabc 2020-07-03 08:58:02 +08:00 via Android
@helloworld000 那就请教一下，nvenc 的具体代码实现在哪？
|
 |
66
newmlp 2020-07-03 09:29:06 +08:00
如果参数一样效果理论上一样，但是 GPU 压片可调参数有限，所以 CPU 压片质量高很多
|
 |
67
expy 2020-07-03 09:37:50 +08:00
编码好像是用的专用芯片，不是跑在 cuda 上。1650 super 及以上都是一样的图灵版 NVENC 芯片。
"One thing that is great about NVENC on the GeForce RTX 20-series and GeForce GTX 1650 Super and up is that all GPUs have the same NVENC with the same performance and quality, from the RTX 2060 to the RTX 2080 Ti. NVENC also benefits from our own NVIDIA Video Codec SDK, an advanced set of tools that help improve the encoded quality and that we constantly update to help you get the best out of your NVIDIA card." https://www.nvidia.com/en-us/geforce/guides/broadcasting-guide/ |
|
68
expy 2020-07-03 09:42:39 +08:00
这里有游戏直播推流用的各种编码器测试。码率给到 8Mbps，图灵 NVENC 编码 hevc 效果很好。
https://unrealaussies.com/tech/nvenc-x264-quicksync-qsv-vp9-av1/ |
 |
69
supuwoerc 2020-07-03 10:16:12 +08:00
学到了，我也以为一样的参数和方法 ，不同产出者的不会存在差别呢。。
|
 |
71
Jasmine2016 2020-07-03 11:02:05 +08:00
所以。。。楼主你有答案了吗？我看的大家的回复也比较蒙。我也是只想要节省压片速度，画质不过分追求。
|
 |
72
Mark24 2020-07-03 11:05:20 +08:00
哈哈哈，好几个人是不懂装懂，想当然了。
楼主既然得到了有差异的结果——其中必有原因。 等大神分析原理。也是很好奇 |
 |
73
mxT52CRuqR6o5 2020-07-03 11:48:11 +08:00 via Android
显卡硬件编码能控制的参数有限，做不到一样的参数，而且编码的硬件代码在电路造出来后也不可能改了
软件编码可以不断的优化算法，有些编码格式可能还有多个不同组织写的编码器，相同参数不同版本的软件编码器可能出来的文件就不一样哦 |
|
74
mortal 2020-07-03 12:34:07 +08:00 1
@zhangsimon #58
这是有 Turing NVENC 最便宜的卡，是 TU116 核心。1650 Super 和 1650 不一样，后者是 TU117 。另外，没有 1650Ti 这款卡。“1*” 的 * 是注释的意思，表格下面写了： * = Turing GPU with Volta NVENC |
 |
75
realpg 2020-07-03 13:48:42 +08:00
@libook #10
一本正经的胡说八道系列 @libook #11 补充的 胡说八道 PLUS @zhangsimon #17 NVENC 只有一个核心 是一个独立芯片 同核心的不同显卡 转码性能一致，除非同时在做别的任务高负载，显存频率和显存容量拖后腿。 如果你单纯的追求转码速度，那 NVENC 就完事了，最新一代的核心的，注意 16xx 系列好像有一个入门型号用的旧版本 NVENC 专业卡和游戏卡的 NVENC 一样，但是并发任务数不一样。专业卡好像是可以同时压 4 路，游戏卡只能一路。 |
 |
76
xsen 2020-07-03 13:52:28 +08:00
拿 h264 来说，若一样的算法，那么 CPU 、GPU 或硬件编解码芯片，参数一致的话画质可以说可以是完全一样的
唯一区别就是体现在对资源的占用——就是时间相关的（如编解码时间、延迟、帧率这些） 但实际上，对于 CPU 、GPU 及编解码芯片算法层面还是有比较大的差异， 1. CPU 软编解码，用的都是比较成熟的、通用的算法。一般是 x264/openh264 2. GPU 如拿 nvidia 的 GPU 来说，实际上支持视频的编解码的时间并不算太长远。因此，因此算法的成熟度这块肯定是不如 x264/openh264 这些。所以一样的参数，画质有不同是正常的情况 GPU 做视频编解码，主要也就是近几年才慢慢普及起来的 3. 专用的视频编解码芯片 一般我们说的手机或机顶盒的硬编、硬解就是指的是这类专用芯片。这类芯片用的算法，都是非常成熟的、商用的算法（专用的）。其整个周期与 x264/openh264 同步发展 基本 h264 标准尚在制定阶段，做视频编解码芯片的厂家就在同步实现算法，或比标准还要早 因此，对于画质来说，专用视频编解码芯片的画质质量与编解码速度是最好的，但不够灵活（支持算法是固定的） 对于软编软解，因为是同步用的最新的算法，所以画质不会太差，但占用 CPU 资源 对于 GPU 做视频编解码，出来时间并不长，所以算法不够成熟（或优化度不够），但好处在于灵活（可以实现各种的算法——音视频、图形、图像等等） |
|
77
zhangsimon OP 1
@Jasmine2016 有答案了
单说显卡压制能力：N 卡选 turning 构架的显卡，转码就看参数里的 nvenc 的数量； https://developer.nvidia.com/video-encode-decode-gpu-support-matrix#Encoder 所以 Geforce 系列里其实 1660 到 2080 的视频转码能力没差异 如果你只做转码，1650S 是最便宜的一款 （ 1650 是 turning 里最便宜的那块，但是 nvenc 没升级； 1650s 的 nvenc 是升级过的） 综上：我准备蹲个联想 R700 的 1660Ti 版 👀 进可打打游戏，退可压压视频 |
|
78
zhangsimon OP @mortal Got，🙏多谢科普
|
|
79
futou 2020-07-03 17:43:30 +08:00 1
看到很多人对编码结果不同有疑惑，实际上我们平时叫 h.264/h.265 为“编码标准”是不严谨的，严格意义上来说这些都是“解码标准”。
解码标准间接限定了块划分结构、帧内帧间预测等编码模式，但限定不了如何在大量候选模式中选出最优的一组进行编码。因此，不同编码器有不同的编码模式优化选择算法，也就产出不同的编码性能（速度、压缩比、质量）。 所以，即使能控制不同编码器使用完全一致的参数进行编码，结果也是不同的。 |
|
80
ungrown 2022-03-01 03:39:43 +08:00 1
@happinessnch #40
你的发言佐证了我一直以来的一种观点：专业人士很容易把自己的知识技能经验外扩到自己的专业之外，而现如今是一个“专业割裂”严重的时代，同领域同场景下看似同专业实则不然的情况太常见了，很反直觉是吧。 我们看看视频编码本质上是个什么运算，在如今仍然主流的基于像素块的编码思路下，无非是在二维矩阵上搜索、跟踪大量的像素群是如何随着时间移动、变化的，并将这些运动用尽量少的数据描述出来。这部分工作就是运动预测、运动补偿，除此之外的工作，诸如量化、采样、宏块切割、滤波、频域转换、熵编码（无损压缩）等等基础计算虽然同样重要但并不是影响最终编码效率的关键因素、或者虽然也是关键因素但影响比重明显小于运动预测。 那么，如何高效、准确地进行运动预测？最理想的情况是，在整个画面上进行搜索跟踪。但这就带来一个“负担”，这么大的矩阵是要占用不小的运行内存空间的。 如果是 CPU 跑编码算法无所谓，大把的内存条，空间管够，反正就一个计算单元，整个图像范围由它承包。一个运算单元负责一整个图像，而且现代 CPU 性能强劲，在强力的分支预测加持下，视频编码算法中大量的分支条件判断压根不算个事。 GPU 就惨了，一堆运算单元，却个个都是残废，光是一个 if-else 就够这些单元跑半天了，这些单元也就只能胜任某几种模式的数值计算罢了，让它们进行复杂逻辑判断真是要了亲命。那么单核心这么弱，是不是得把工作分一分啊，那肯定啊。那咋分呢，每个 GPU 运算单元该复杂多大范围呢？负责的范围太小的话不行，这个单元上一帧还能看到画面上那只手呢，下一帧这手直接移动到它负责的范围外面了，它直接懵逼，顺带它隔壁的单元也跟着懵逼，咋我的工作区里多出来一只手，我之前跟踪着的那只眼镜呢？那么范围大一点行不，要不干脆直接大到一整个画面范围得了，反正一帧画面是大家共用的嘛，又不用多占空间？不行，画面数据是公用的，但每个单元负责的任务数据是独有的，每个单元负责的范围越大，它要分辨的数据量就越大，它能识别并跟踪的目标就越大，目标运动范围、运动模式就更复杂，记录这些数据需要的空间就更更更大，字面意义上的几何式增长。显存一共才多大啊，就算它 8 个 G ？几百几千个核心等着分呢，笑死，根本不够分。 那取个折中行不，也不整个画面范围了，也不弄得范围太小，取个过得去的中间值吧。行，事实上也是这么做的，然而即使如此，一旦跑起来，依然是内存直接拉满，但核心却依然有大量空闲。真没办法了，每个核心负责的单元不能太小，不然动不动丢失跟踪目标，没法玩。就这样，整个画面依然被划分成了不少的范围，一旦动起来，依然频繁出现目标从一个区块跑到另一个的情况，引起巨大的编码浪费，它们要真是直接瞬移过去的还好，关键是一帧一帧慢慢过去，中间的每一帧上，这些区块的边界上充斥了各种不完整的目标碎片，严重的能造成几倍的编码浪费。 所以大家都懂，都会玩，说是 GPU 硬件加速编码，其实负责编码运算的根本不是 GPU 核心，而是另外单独的专用视频编解码电路，核心撑死了帮忙做一些外围辅助工作，视频编码的大头工作全交给专用电路，intel qsv ，nvenc ，诸如此类，概莫如是。 所以，你当初参与的那个项目的那个算法，大概率是一个本来就针对并行计算特性所设计的模式，压根就不能发挥出 CPU 这种能胜任复杂任务的强力运算单元的优势，而更偏向于照顾 GPU 单元这种多而弱的运算架构，而且既然已经是针对并行运算所设计的视频编码算法，毫无疑问逃不开上面所述的“分割画面范围导致跟踪对象丢失引起大量冗余编码”的弱点，那自然是就算用了 CPU 来跑也不会得到更好的画面或者编码效率。 |
|
81
happinessnch 2022-03-01 09:52:01 +08:00
@ungrown
就运动预测来说，通过相位相关算法在参数完全一样的情况下，CPU 会和 GPU 算出来的结果不一样？ 同样的滤波算法，同样的参数，CPU 会和 GPU 算出来的结果不一样？ 如果如果分辨范围不一样，说明参数不一致，如果逻辑判断不一样，那压根就不是一个算法。 你再发我不回了哈，这么久的帖子，就让它沉了吧。 |
|
82
ungrown 2022-03-01 15:25:34 +08:00 1
@happinessnch #81 你回不回的，又如何，at 你的楼层是为了明确上下文，写了又不是只给你一个人看的。就算你不特意说明接下来不回，难不成我还催着你回复吗？我要真那么做了，屏蔽是干嘛用的？虽然我自己坚决不拉黑别人，但并不认为这个功能的存在有何不妥。
为什么总有人要把视频编解码这么复杂的体系看成一个单独的算法？哪怕是这个体系中的每一个环节，也都是由多个不同算法构成的，并且有些算法还不是强制的、固定的，是可增减的、根据条件选择的。选择的根据不仅仅是用户指定的参数，还取决于各个软件、硬件的具体实现，即使严格遵照标准依然有巨大的灵活发挥空间。 再说用户只能指定更改哪些参数，剩下大量参数既然没有被用户指定，那就保持默认值，而这个默认值不同的软硬件实现也可以不一样。至于参数本身，标准体系内的参数也不是非得全部暴露出来，标准之外的参数也不是不可以加进来。 说到底，还是前述的那样，标准体系之下有着巨大的灵活发挥空间，软硬件编码器怎么实现、怎么设计、怎么在标准的基础上取舍、乃至魔改，八仙过海各凭本事。 你心心念念的所谓“一样的算法”“一样的参数”这些前提，从一开始就不存在。除非我们是在讨论同一个软硬件实体的同一个版本，而不是现在这样在讨论众多不同的软硬件实现。 运动预测这方面，标准只规定要按照怎样的“语法”来描述运动，至于这些运动偏移是怎么估算出来的，标准才不管那么多。其他方面也是，标准的存在是为了统一用来描述静态和动态画面的方式及相关的数据结构，只要能保证这方面的统一性，就能保证统一的可解码性，并能保证解码结果的统一性，至于是怎么编码出来的，根本不在乎，反正编码结果数据的语义和数据结构符合标准就行了。 所以编码器在对画面作运动预测时，是以一整个画面为范围，还是划分成 4 个、16 个、64 个小块来提高并行度，这是编码器的自由，也不会违反编码标准，反正不管用何种方式进行预测，只要预测的结果能被其他解码器读懂就行。给 CPU 用的软件编码器有着充足的内存空间和强大的运算单元，不需要再考虑把单帧画面进一步切割。GPU 上的运算单元都是些功能孱弱的弱单元，显存也不够一众核心分，所以在给核心分配任务的同时限定各自的搜索范围，这都是在客观因素制约下的因地制宜的手段。 所以你结尾总算说了一句事实，（同一视频编码标准下的，各种不同的软件编码器实现，和各种硬件编码器）压根就不是一个算法。所以也别拿自己参与过的项目来类比这个项目之外的、更广阔的的、你所不熟悉的领域了。 |
Select Language