为什么处理器比GPU编码“更好”？

我在阅读本文时，发现CPU在视频压缩方面比GPU更好。

这篇文章只是说发生这种情况是因为处理器可以处理比GPU更复杂的算法，但是我想要更多的技术解释，我在互联网上进行了一些搜索，但没有找到任何东西。

那么，有人知道要解释一个站点或将其链接到我时对此有更深入的解释吗？

您链接的文章不是很好。

通常，单程比特率编码会将您的比特率转换为具有最大比特率限制的RF值，然后从那里获取该值。

x264的单次ABR速率控制未实现为CRF +限制。他说对了，尽管到目前为止2pass是达到目标比特率的最佳方法。

而且他显然没有意识到他可以使用threads = 3之类的东西来启动x264，从而为其他任务留出一些CPU时间。或将x264的优先级设置为非常低，这样它只会获得其他任务不需要的CPU时间。

他还使用CUDA或其他方法将线程= 1混合在一起。难怪你有问题，因为该文章有一个可怕的解释。整篇文章基本上可以归结为：使用x264 --preset veryslow --tune film --crf 26 in.m2ts --out out.mkv，或者对输入的AviSynth脚本使用一些滤光。他实际上推荐“安慰剂”。那真好笑。我从未见过用安慰剂编码的盗版文件。（您可以从me=esa或进行判断me=tesa，而不是me=umh针对所有高质量的预设，直到为止veryslow。

他也没有提到使用10位色深。编码和解码速度较慢，但​​是即使下变频回8位，您也可以获得更好的8位SSIM。运动矢量具有更高的精度显然会有所帮助。同样，不必四舍五入到整个8位值也有帮助。您可以将每个组件的8位视为一种速攻。在频域中进行量化，然后用CABAC进行压缩意味着更高的位深系数不必占用更多空间。

（顺便说一句，h.265从8位视频的10位编码中获得的好处较少，因为它已经具有更高的运动矢量精度。如果对8位视频输入使用10位x265有好处，则它小于x264。因此，速度损失值得的可能性较小。）

要回答您的实际问题：

编辑：doom9现在再次启动，因此我将整理链接。转到它以正确引用谁在说什么。

http://forum.doom9.org/showthread.php?p=1135399#post1135399

Google只缓存没有正确显示报价的愚蠢打印版本。我不太确定这些消息中的哪些部分是引号，哪些部分归因于此人。

高度不规则的分支模式（跳过模式）和位操作（量化/熵编码）不适合当前的GPU。IMO目前唯一真正好的应用程序是全搜索ME算法，尽管最终加速的全搜索仍然很慢，即使它比CPU上的速度还要快。
-外交部

实际上，除了CABAC以外，基本上所有事情都可以在GPU上合理地完成（可以做到，只是无法并行化）。

x264 CUDA最初将实现全象素和子象素ME算法；稍后，我们可以做一些类似RDO的事情，而不是使用CABAC进行位成本估算。

因为它必须在单精度浮点数上做所有事情
-MfA

错误的，CUDA支持整数数学。

-黑暗的Shikari

Dark Shikari是x264的维护者，并且是2007年左右以来大多数功能的开发者。

AFAIK，这个CUDA项目没有成功。支持使用OpenCL从前瞻线程中卸载某些工作（快速的I / P / B决策，而不是帧的高质量最终编码）。

我的理解是，用于视频编码的搜索空间是如此之大，以至于用于尽早终止CPU上搜索路径的智能试探法击败了GPU带来的强力GPU（至少对于高质量编码而言）。仅与-preset ultrafast您可能会合理选择在x264上，特别是在x264上进行硬件编码的地方相比。如果您的CPU速度较慢（例如具有双核且没有超线程的笔记本电脑）。在快速CPU（具有超线程功能的i7四核）上，x264 superfast可能会变得同样快，并且看起来更好（在相同的比特率下）。

如果您要进行编码，而编码率失真（每文件大小的质量）则很重要，则应使用x264 -preset medium或更慢的编码。如果您要存档，那么现在花更多的CPU时间将节省字节，只要您保留该文件即可。

旁注，如果您在视频论坛上看到来自Deadrats的消息，那将无济于事。在我见过的每个话题中，他谈论的大多数内容都是错误的。他的帖子出现在我用Google搜寻有关x264 GPU编码的几个主题中。显然他不明白为什么这并不容易，并且已经发了好几遍告诉x264开发人员为什么他们愚蠢...

2017年更新：

ffmpeg支持h264和h265 NVENC GPU加速的视频编码。您可以为hevc_nvenc或h264_nvenc进行选择的质量的1遍或2遍编码，甚至使用入门级GPU，它也比非加速编码和Intel Quick Sync加速编码快得多。

2次高质量编码：

ffmpeg -i in.mp4 -vcodec h264_nvenc -preset slow out.mp4

1遍默认编码：

ffmpeg -i in.mp4 -vcodec h264_nvenc out.mp4

NVENC ffmpeg帮助和选项：

ffmpeg -h encoder=nvenc

使用它，它比CPU编码快得多。

如果没有GPU，则可以使用Intel Quick Sync编解码器，h264_qsv，hevc_qsv或mpeg2_qsv，它们也比非加速编码快得多。

为了进一步详细说明Peter所说的话，通常，在您有多个需要独立完成但彼此不依赖的独立任务或执行相同任务的一项任务中，使用多个处理器通常会有所帮助大量数据的数学运算。

但是，如果您需要将计算A的输出作为计算B的输入，而将计算B的输出作为计算C的输入，则无法通过在每个任务上使用不同的核心工作来加快速度（ A，B或C），因为一个要等到另一个完成后才能开始。

但是，即使在上述情况下，您也可以使用其他方式并行化它。如果您可以将输入数据分成多个块，则可能需要一个核心数据来处理A，然后是B，然后是C，要处理一个数据块，而另一个核心是要处理A，然后是B，然后是C来处理另一个数据块。 。

也有其他考虑。也许您可以找到一种并行化计算的方法，但是仅从磁盘，通过网络或通过网络读取数据，或者将其发送到GPU所需的时间要比进行计算所需的时间长。在这种情况下，将其并行化是没有意义的，因为仅将数据存入内存所花费的时间比并行执行计算所节省的时间长。

换句话说，它既是一门艺术，又是一门科学。