问题描述
最近，我试图通过udp流化网络摄像头捕获的实时视频。我采取的方法是读取一帧，通过udp发送，并在接收器一侧读取数据并显示。
现在，我知道通过udp / tcp发送数据会导致碎片，这种碎片会以任意随机的方式发生，具体取决于传输层的MTU和基础IP协议并不能保证将要传输的帧数。据说任何数据层的最小MTU为1500字节。
但是，我的每一帧都是1MB（〜1048576字节）。因此，考虑到1500字节的数据分段，单个帧可能会分段，然后接收方将获得约700个数据包（1048576/1500）。现在，接收器只需要在一帧中累积所有这700个数据包的数据，就需要进行额外的处理。 这是正常的，仅一帧数据700个数据包！！如果我想将帧率保持在24fps，这意味着接收器必须处理700 * 24 = 16800个数据包/秒，这似乎不可行。
我想了解另一个流媒体网站如何工作，它们绝对不每秒处理16800个数据包。他们将使用其他流协议，例如RTSP，但是这些协议建立在UDP / TCP之上，这意味着这些协议也需要处理碎片。如今，流媒体网站可以提供4k视频，每个帧的大小都将大于1MB，但MTU仍为1500字节。他们还必须进行数据压缩，但是要压缩到什么程度。即使他们设法以某种方式将帧大小减小了50％（这也需要在接收器端进行解压缩，这意味着需要进行额外的处理），对于低质量的24fps视频，他们仍然需要每秒处理8000个数据包。 他们如何处理这些数据，如何在这些规模上管理数据碎片。
解决方法
未压缩的数据很少通过网络发送。当前采用的视频编解码器，例如H.264 AVC，H.265 HEVC，H.266 VVC，VP8，VP9，AV1，其压缩率取决于数字参数，包括分辨率，帧速率，目标比特率，保真度要求，实时要求以及存储或交付网络容量等。
您所指的流媒体网站都使用压缩，不仅用于传输视频，而且还将内容存储在不同的容器中，例如avi，mp4或mkv文件。
流协议的选择还取决于实时要求（毫秒与秒），基础结构要求，可伸缩性要求和解决方案的复杂性以及目标客户端设备和功能（例如计算机，平板电脑，电话）。例如，基于HTTP的流协议允许重复使用经过良好测试和理解的HTTP基础结构和软件，并包括诸如缓存之类的优势，这对于扩展可服务请求的数量很有用。
用于低延迟用例（例如，视频通信（例如WebRTC））的实时流传输通常需要通过RTP / UDP进行，延迟需要保持在150ms以下。对于信令，请查看RTSP，SIP和WebRTC。其他协议（非IETF）还包括Adobe开发的RTMP，但几年来一直在下降（AFAIR）。
根据您的陈述，即使压缩帧的大小也可以是数千字节。 当通过RTP / UDP流式传输时，较大的编码帧使用RTP有效负载格式（例如， RFC6184，RFC7741，RFC7798，它们指定如何分割帧。
基于HTTP的自适应流式传输对延迟的要求不那么严格，这里HTTP管理着您的消息帧。协议包括HTTP Live Streaming，MPEG DASH等。
即使它们设法以某种方式将帧大小减小了50％（这也需要在接收方进行解压缩，这意味着需要进行额外的处理）
提到的编解码器可以实现更好的压缩率，而附加处理可以忽略不计，并且对于广泛使用的编解码器，通常由硬件支持编码/解码。您的手机很可能具有可以非常高效地解码H.264的硬件。