最近我试图通过 udp 流式传输网络摄像头捕获的实时视频。我采用的方法是读取一帧，通过 udp 发送它并在接收方读取数据并显示它。
现在，我了解到通过 udp/tcp 发送数据会导致碎片，碎片以任何随机方式发生，具体取决于传输层的 MTU，并且底层 IP 协议(protocol)不能保证将交付的帧数。任何数据层的最小 MTU 据说是 1500 字节。
但是，我的每一帧都是 1MB(~1048576 字节)。因此，考虑到 1500 字节的数据碎片，单个帧可能会碎片化，然后接收方将获得约 700 个数据包 (1048576/1500)。现在接收器需要为一帧累积所有这 700 个数据包的数据，这涉及额外的处理。 这是正常的吗，700 个数据包仅用于 1 帧数据!如果我想让帧率保持在 24fps，这意味着接收器必须处理 700*24 = 16800 个数据包/秒，这似乎不可行。
我想了解另一个流媒体网站是如何工作的，他们肯定不会处理 16800 个数据包/秒。他们会使用其他流媒体协议(protocol)，如 RTSP，但这些协议(protocol)建立在 UDP/TCP 之上，这意味着这些协议(protocol)也需要处理碎片。现在流媒体网站可以提供 4k 视频，每个帧大小将远大于 1MB，但 MTU 仍然是 1500 字节。他们还必须进行数据压缩，但压缩到什么程度。即使他们以某种方式设法将帧大小减少 50%(这也需要在接收端解压缩，这意味着额外的处理)，他们仍然需要处理大约 8000 个数据包/秒来处理低质量的 24fps 视频。 他们如何处理它，如何管理这些规模的数据碎片。
最佳答案
未压缩的数据很少通过网络发送。目前采用的视频编解码器如H.264 AVC , H.265 HEVC , H.266 VVC , VP8 , VP9 , AV1实现惊人的压缩率，这取决于许多参数，包括分辨率、帧率、目标比特率、保真度要求、实时要求和存储或传输网络容量等等。
您所指的流媒体网站都使用压缩，不仅用于传输视频，还用于将内容存储在不同的容器中，例如 avi、mp4 或 mkv 文件。
流媒体协议(protocol)的选择还取决于实时要求(毫秒与秒)、基础设施要求、可扩展性要求和解决方案的复杂性以及目标客户端设备和功能(例如计算机、平板电脑、手机)。例如，基于 HTTP 的流协议(protocol)允许重用经过良好测试和理解的 HTTP 基础设施和软件，并包括缓存等优势，这有助于扩展可服务的请求数量。
用于低延迟用例的实时流式传输，例如视频通信(例如 WebRTC)，其中延迟需要保持在 ~150 毫秒以下，通常在 RTP 上完成。/UDP。对于信令，请查看 RTSP、SIP 和 WebRTC。其他协议(protocol)(非 IETF)包括由 Adobe 开发但多年来一直在下降的 RTMP (AFAIR)。
如您所述，即使压缩帧的大小也可能达到数千字节。 当通过 RTP/UDP 流式传输时，较大的编码帧使用 RTP 有效负载格式拆分为多个数据包/数据报，例如RFC6184 , RFC7741 , RFC7798它指定了一个框架如何被分割。
基于 HTTP 的自适应流式传输对延迟的要求不那么严格，这里 HTTP 管理您的消息框架。协议(protocol)包括 HTTP Live Streaming , MPEG DASH仅举几例。
Even if they somehow manage to reduce frame size by 50% (which also needs to be de-compressed at receiver side which means additional processing)
提到的编解码器实现了更好的压缩率，额外的处理可以忽略不计，对于广泛使用的编解码器，编码/解码通常由硬件支持。您的手机很可能具有非常有效地解码 H.264 的硬件。
关于tcp - 视频流协议(protocol)——处理碎片，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/64400558/