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毫秒的延迟。