我对视频压缩的有限（并且可能是错误的？）理解是帧内是完全独立的。换言之，内帧（关键帧）的所有图片数据都被完整地存储在该帧中。以下帧间帧（我认为 H.264 中的 P 和 B 帧）依赖于要“绘制”的其他帧中的数据。
如果这些帧内帧是完全独立的，为什么编码不是一个令人尴尬的并行问题？如果您有 N 个处理器和 X 个 I 帧，您可以将 X/N 个源块分配给每个处理器进行独立编码，然后在最后将它们全部修补在一起，对吗？但似乎情况并非如此——或者至少，我还没有看到任何具有能够做到这一点的并行化的编码器。我不明白什么？
首先要考虑的是您要放置帧内帧的位置。为了获得最佳压缩效果，您需要明智地选择此选项，例如，更喜欢场景更改而不是静态序列的中间。要找到需要分析原始视频的最佳位置，这可以通过额外的通道（昂贵）完成，也可以在编码时即时决定。
因此，要将流打包成块，您要么需要进行额外的传递以对其进行分析，要么只是将其任意划分并失去一些压缩效率。
然后你必须考虑如何对这个原始视频进行编码。要么它从某个地方流入你的压缩程序，要么整个东西都在磁盘上可用。
如果它正在流式传输，那么您就不走运了，因为您无法随机访问流的不同部分。是的，你可以缓冲它，但快速计算表明这要么需要大量内存，要么你必须缓冲到磁盘，这导致了下一点：
如果您将整个原始文件存储在本地，那么您可以将部分分配给不同的进程或线程。除了您的问题现在是磁盘访问！考虑原始 1080p、24fps 视频的数据速率约为每分钟 4 GB。使用单个进程对其进行编码，磁盘将被大量占用以提供原始数据。它甚至可能是该过程中最慢的部分（尽管可能不是，除非您的硬盘驱动器非常碎片化！）
现在考虑让 4 个进程访问同一个文件，所有进程都试图以极高的速率获取原始数据。该硬盘驱动器将无法为编码器提供数据 - 薄弱环节不会是缓慢的处理器，而是缓慢的数据访问。
因此，除非您有一些真正专业的工具包来存储未压缩的视频，否则将不同的部分打包以进行并行编码是不切实际的。