实时直播的最佳策略是什么

Question

我并不是指哪种传输技术（例如 WebRTC、Web Socket、标准 HTTP 等）最适合网络摄像头等的实时直播流媒体，而是一般策略（in编程本身的条款）。

在我的测试中，我发现最好的方法是：

1. 至少以 30 毫秒/帧的速度逐帧流式传输（直接流式传输 JPEG 图像），但是这非常占用带宽。 （假设每帧平均为 50kb，对于 1 秒的视频，即 500kb，即每分钟大约 30MB，因此在一小时内将有 1.8GB 的​​大小），解决方案可能不是使用 JPEG，而是使用类似 AVIF image compression 的东西当我测试时，尺寸和质量非常理想。它可能会降低逐帧实时流传输的带宽问题。 这种方法的总结是它确实实时、快速且流畅，但会占用带宽。
2. 我还使用 MJPEG 进行了测试（先编码帧然后以块的形式发送）——容器是 AVI，但里面的图像是压缩的 JPEG 图像。帧率是平滑的，但本地回送已经有 1 秒的延迟，所以如果这要通过网络发送（通过 UDP、TCP/HTTP/Websocket 等），还没有测试，但我认为它会增加额外的延迟，比如说1秒。我研究了现有的流媒体，发现总延迟为 3 秒，这就是我现在所拥有的。 MJPEG的总结，我认为它根本不会节省带宽，因为毕竟在AVI容器内它仍然是JPEG图像，保存的是网络请求的数量（不确定这是否是一个加号）强>
3. 最后，类似于 MJPEG 方法，但使用 MPEG1、MPEG4、WEBM 等编码器/解码器肯定会由于更好的压缩算法而节省带宽，但肯定会增加延迟，因为 MJPEG 只是 JPEG 的原始打包在容器内，这种方法会增加额外的 CPU 工作负载来处理进一步的压缩。 因此，这种方法的总结是它节省了带宽，但增加了更多的延迟。

鉴于上述 3 种情况，我认为实时流式传输的最佳策略是根本不压缩，至少是以 JPEG 压缩并将 JPEG 打包到一个容器中（例如每包 3-4 帧) 在 100 毫秒，并将该字节流式传输到网络中。 但是对于实时流媒体专家来说，实时直播流媒体的最佳策略是什么？

Answer 1

需要考虑的一个重要概念是拥塞控制。您的网络会波动，您需要能够对其做出响应。对于您提出的所有建议，您无法测量背压，然后对其做出响应。

Web Socket，标准 HTTP 的运行方式非常相似，但如果使用得当，WebRTC 的性能会显着提高。 WebRTC 并没有做任何新的事情来解决这个问题，但是它使用了现有的技术 RTP/RTCP，它允许发送者和接收者就媒体传输的状态进行通信。发送方可以即时调整比特率，甚至在接收方请求时更改编码复杂度。

我没有一个很好的单一文档来说明这一切，但rmcat requirements 很好地解释了这一点！

您在上面提出的所有这些解决方案都可以在 RTP 上运行，您只需要评估您的需求和可用的资源（带宽、延迟等）。但我认为最终任何强大的解决方案都需要接收器反馈。