2

最近我试图通过 udp 流式传输由网络摄像头捕获的实时视频。我采用的方法是读取一帧，通过 udp 发送并在接收端读取数据并显示它。

现在，我知道通过 udp/tcp 发送数据会导致碎片化，这种碎片化会以任何随机方式发生，具体取决于传输层的 MTU，并且底层 IP 协议并不能保证将交付的帧数。任何数据层的最小 MTU 被称为 1500 字节。

但是，我的每一帧都是 1MB（~1048576 字节）。因此，考虑到 1500 字节的数据碎片，单个帧可能会被碎片化，然后接收器将获得约 700 个数据包 (1048576/1500)。现在接收器需要为一帧累积所有这 700 个数据包的数据，这涉及到额外的处理。这是正常的吗，仅 1 帧数据 700 个数据包！如果我想将帧速率保持在 24fps，这意味着接收器必须处理 700*24 = 16800 个数据包/秒，这似乎不可行。

我想了解另一个流媒体网站是如何工作的，它们绝对不会处理 16800 个数据包/秒。他们将使用其他流协议，如 RTSP，但是这些协议是建立在 UDP/TCP 之上的，这意味着这些协议也需要处理碎片。现在流媒体网站可以提供 4k 视频，每个帧大小将远大于 1MB，但 MTU 仍然是 1500 字节。他们还必须进行数据压缩，但压缩到什么程度。即使他们设法将帧大小减少了 50%（这也需要在接收端进行解压缩，这意味着额外的处理），对于低质量的 24fps 视频，他们仍然需要每秒处理约 8000 个数据包。他们如何处理它，他们如何管理这些规模的数据碎片。

4

1 回答 1

4

未压缩的数据很少通过网络发送。目前采用的视频编解码器如H.264 AVC、H.265 HEVC、H.266 VVC、VP8、VP9、AV1可实现惊人的压缩率，这取决于包括分辨率、帧率、目标比特率、保真度要求、真实时间要求和存储或交付网络容量仅举几例。

您所指的流媒体网站都使用压缩，不仅用于传输视频，还用于将内容存储在不同的容器中，例如 avi、mp4 或 mkv 文件。

流协议的选择还取决于实时要求（毫秒与秒）、基础设施要求、可扩展性要求和解决方案的复杂性以及目标客户端设备和功能（例如计算机、平板电脑、电话）。例如，基于 HTTP 的流协议允许重复使用经过充分测试和理解的 HTTP 基础设施和软件，并包括诸如缓存之类的优点，这对于扩展可以服务的请求数量很有用。

用于低延迟用例的实时流传输，例如视频通信（例如 WebRTC），其中延迟需要保持在 ~150 毫秒以下，通常通过RTP /UDP 完成。对于信令查看 RTSP、SIP 和 WebRTC。其他协议（非 IETF）包括由 Adob​​e 开发的 RTMP，但多年来一直在下降（AFA​​IR）。

正如您所说，即使压缩帧的大小也可能有数千字节。当通过 RTP/UDP 流式传输更大的编码帧时，使用 RTP 有效负载格式（例如RFC6184、RFC7741、RFC7798 ）将更大的编码帧拆分为多个数据包/数据报，这些格式指定了如何对帧进行分段。

基于 HTTP 的自适应流的延迟要求不那么严格，在这里 HTTP 管理您的消息帧。协议包括HTTP Live Streaming、MPEG DASH等等。

即使他们以某种方式设法将帧大小减少了 50%（这也需要在接收端解压缩，这意味着额外的处理）

提到的编解码器实现了更好的压缩率，额外的处理可以忽略不计，并且对于广泛使用的编解码器编码/解码通常由硬件支持。您的手机很可能具有非常有效地解码 H.264 的硬件。

于 2020-10-17T13:42:34.973 回答