这与其说是技术问题，不如说是概念问题。我对 H.264 的理解是它依赖于过去和 future 的帧来压缩视频数据。获取完全压缩的 H.264 视频文件并通过 RTP 或您选择的任何其他协议(protocol)进行流式传输是微不足道的，但是，这如何与实时视频一起工作？在实时视频中，您只能访问过去和当前的帧，并且不知道视频的完整长度，那么 H.264 编解码器如何实际压缩视频并将其准备为 RTP 负载？它是否只是将视频缓冲并分块成任意大小的较小视频并进行压缩？我能想到的唯一方法是将视频分成 1 秒的 block ，将它们压缩为单独的视频，并使它们成为 RTP 有效负载。它是这样做的，还是发生了比我怀疑的更多的“魔法”？
最佳答案
首先，框架分为三种。
I(帧内)帧或关键帧。这些框架不引用任何其他框架。它们是独立的，可以在没有任何其他帧数据的情况下解码。像 JPEG。
P(预测)框架。可以引用过去的帧。
B(双向)可以引用过去或 future 的帧。
选项 1. 仅使用 I 和 P 帧。这会导致文件大大约 10-15%(或在相同文件大小下质量降低 10-15%)。这用于视频 session 和屏幕共享等延迟非常明显的交互式系统。
选项 2，等待 future 发生。以每秒 30 帧的速度， future 将在 33 毫秒后到来。
h.264 具体来说最多只能引用 16 个相邻帧。然而，大多数人将其限制在 4 左右。因此等待 4 帧只有大约 133 毫秒的延迟。
关于video - H.264 实时流实际上是如何压缩和传输的？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19033655/