这更多是一个概念问题，而不是技术问题。我对 H.264 的理解是，它依赖于过去和未来的帧来压缩视频数据。获取完全压缩的 H.264 视频文件并通过 RTP 或您选择的任何其他协议进行流式传输很简单，但是，这如何与实时视频一起使用呢？在实时视频中，您只能访问过去和当前的帧，并且不知道视频的完整长度，那么 H.264 编解码器如何实际压缩视频并将其准备为 RTP 有效负载？它是否只是简单地将视频缓冲并分块成任意大小的较小视频并对其进行压缩？我能想到的唯一方法是将视频分割成类似 1 秒的块，将它们压缩为单独的视频，并使它们成为 RTP 有效负载。这就是它的完成方式还是发生了比我想象的更多的“魔法”？
首先，框架分为三种类型。
I（帧内）帧或关键帧。这些框架不引用任何其他框架。它们是独立的，无需任何其他帧数据即可解码。就像 JPEG 一样。
P（预测）框架。可以参考过去的框架。
B（双向）可以参考过去或未来的框架。
选项 1. 仅使用 I 和 P 帧。这会导致文件增大约 10 - 15%（或在相同文件大小下质量降低 10-15%）。这用于视频会议和屏幕共享等延迟非常明显的交互式系统。
选项2，等待未来发生。以每秒 30 帧的速度，未来将在 33 毫秒内到来。
h.264 具体只能引用最多 16 个相邻帧。然而大多数人将其限制在 4 左右。因此等待 4 帧仅延迟约 133 毫秒。
我不是专家，但我昨天才涉足它，今天系统以 5 帧块调用 ffmpeg，它很慢，但只是实时，大约 1.5 spf。
我认为我做错的事情（除了进行系统调用和直接在语言中没有适当的库之外。）是我在每个新帧中回忆它并压缩 5 个新帧。
我认为如果你确实说 10 帧，然后仅每 5 帧而不是每帧重叠调用，然后你只重复压缩每帧一次，而不是 5 次，如果我每帧调用 5 帧。