video - 并行化和 H.264(或者可能是任何压缩编解码器)？为什么这么难？

Question

我对视频压缩的有限(可能是错误的？)理解是帧内是完全独立的。换句话说，帧内帧(关键帧)的所有图片数据都针对该帧完整存储。正是以下帧间帧(我认为是 H.264 中的 P 和 B 帧)依赖于其他帧中的数据来“绘制”。

如果这些内部帧是完全独立的，为什么编码不是一个令人尴尬的并行问题？如果你有 N 个处理器和 X 个 I 帧，你可以只给每个处理器 X/N 个源代码块进行独立编码，然后在最后将它们全部拼接在一起，对吗？但似乎情况并非如此——或者至少，我还没有看到任何编码器具有能够做到这一点的那种并行化。我有什么不明白的？

Answer 1

首先要考虑的是您要放置帧内帧的位置。为了获得最佳压缩效果，您需要明智地选择它，例如，更喜欢将场景更改到静态序列的中间。要找到您需要分析原始视频的最佳位置，这可以在额外的 channel 中完成(昂贵)，也可以在编码时即时决定。

因此，要将流分成多个 block ，您要么需要进行额外的传递以对其进行分析，要么只是任意划分它并损失一些压缩效率。

然后您必须考虑如何获得要编码的原始视频。它要么从某个地方流入您的压缩程序，要么整个东西都在磁盘上可用。

如果是流式传输，那么您就不走运了，因为您无法随机访问流的不同部分。是的，您可以缓冲它，但快速计算表明这要么需要大量内存，要么必须缓冲到磁盘，这导致下一点:

如果您将整个原始文件存储在本地，那么您可以将部分文件分配给不同的进程或线程。除了您的问题现在是磁盘访问!考虑到原始 1080p、24fps 视频的数据速率约为每分钟 4 GB。使用单个进程对其进行编码，磁盘将被大量占用以提供原始数据。它甚至可能是该过程中最慢的部分(尽管可能不会，除非您的硬盘非常碎片化!)

现在考虑让 4 个进程访问同一个文件，都试图以极高的速率获取原始数据。这个硬盘驱动器将无法为编码器提供数据——薄弱环节不是处理器速度慢，而是数据访问速度慢。

因此，除非您有一些非常专业的工具包来存储未压缩的视频，否则将不同的部分打包进行并行编码是不切实际的。