video - H.264 实时流实际上是如何压缩和传输的？

Question

这更像是一个概念问题而不是技术问题。我对 H.264 的理解是它依赖于过去和未来的帧来压缩视频数据。获取完全压缩的 H.264 视频文件并通过 RTP 或您选择的任何其他协议流式传输它是微不足道的，但是，这将如何处理实时视频？在实时视频中，您只能访问过去和当前帧并且不知道视频的完整长度，那么 H.264 编解码器如何实际压缩视频并将其准备为 RTP 有效负载？它是否只是将视频缓冲并分块为任意大小的较小视频并对其进行压缩？我能想到的唯一方法是将视频分成 1 秒的块，将它们压缩为单独的视频，并将它们作为 RTP 有效负载。这是它的完成方式还是还有更多“

Answer 1

首先，存在三种类型的框架。

I（内部）帧或关键帧。这些框架不引用任何其他框架。它们是独立的，可以在没有任何其他帧数据的情况下进行解码。像JPEG一样。

P（预判）帧。可以参考过去的框架。

B（双向）可以参考过去或未来的帧。

选项 1. 仅使用 I 和 P 帧。这会导致文件大约大 10-15%（或在相同文件大小下质量降低 10-15%）。这用于延迟非常明显的交互式系统，例如视频会议和屏幕共享。

选项2，等待未来发生。以每秒 30 帧的速度，未来将在 33 毫秒内出现。

h.264 具体只能参考最多 16 个相邻帧。然而，大多数人将其限制在 4 左右。因此等待 4 帧只有大约 133 毫秒的延迟。