gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-11-28 21:41:11 29 4
gpt4 key购买 nike

这与其说是技术问题,不如说是概念问题。我对 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/

29 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com