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