低延迟（< 2秒）实时视频流HTML5解决方案？

Question

低延迟（< 2秒）实时视频流HTML5解决方案？

htmlvideo-streamingrtmpmpeg-dash

25

随着Chrome很快禁用Flash，我需要开始寻找替代方案来实现Flash/RTMP的HTML5直播流。

目前，通过Flash + RTMP，我可以获得不到1-2秒的延迟的实时视频流。

我尝试使用MPEG-DASH进行实验，似乎这是流媒体的新行业标准，但最好的延迟时间也只有5秒。

为了更好的理解，我正在尝试让用户控制他们在流媒体上看到的物理对象，因此任何超过几秒钟的延迟都会导致令人沮丧的体验。

是否还有其他技术，或者说是否真的没有用于实时直播的低延迟HTML5解决方案？

- Titan

虽然最终项目没有成功，但我们已经确定了https://www.wowza.com/products/capabilities/webrtc-streaming-software。 - Titan

由于MPEG-Dash落后5秒，Phoboslabs MPEG-1约为1秒，但会提供温暖的手感，而WebRTC在服务器端实现时需要自己处理，这可能是一个明智且节省时间的决定 - 感谢Titan。 - A.J.Bauer

MPEG-DASH + H.264 + 0.5秒的GOP长度 = 2-3秒的延迟。 - andreymal

另一个WebRTC低延迟流媒体解决方案是Ant Media Server。请查看https://antmedia.io。 - faraway

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Brad · Accepted Answer

技术和要求

唯一真正面向低延迟的网络技术是WebRTC。它专门用于视频会议。编解码器被调整为低延迟而非高质量。比特率通常是可变的，优先选择稳定的连接而非高质量。

然而，并不是所有用户都需要这种低延迟优化。实际上，根据您的需求，对所有人来说低延迟都会损害用户体验。虽然控制机器人的用户肯定需要低延迟视频，以便他们可以合理地控制它，但不控制的用户并没有这个要求，反而可以选择可靠的高质量视频。

如何设置

控制用户到机器人的连接

控制机器人的用户将加载一个网页，该网页利用一些WebRTC组件连接到摄像头和控制服务器。为了促进WebRTC连接，您需要某种STUN服务器。为了绕过NAT和其他防火墙限制，您可能需要一个TURN服务器。这两者通常都内置在基于Node.js的WebRTC框架中。

摄像头/控制服务器也需要通过WebRTC连接。老实说，最简单的方法是使您的控制应用程序有点类似于基于Web的应用程序。由于您已经在使用Node.js，可以查看NW.js或Electron。这两个都可以利用已经构建在WebKit中的WebRTC功能，同时仍然为您提供了自由使用Node.js进行任何操作的灵活性。

控制用户和摄像头/控制服务器将通过WebRTC（或如果需要，则使用TURN服务器）进行点对点连接。然后，您将要打开一个媒体通道以及一个数据通道。数据通道可用于发送机器人命令。媒体通道当然将用于发送回控制用户的低延迟视频流。

同样重要的是要注意，将发送回的视频将被优化为延迟而非质量。这种连接还确保快速响应您的命令。

查看用户的视频

简单观看流而不控制机器人的用户可以使用常规视频分发方法。由于您将有10k-15k观众观看流，因此使用现有的CDN和转码服务非常重要。使用这么多用户，您可能想将视频编码为几种不同的编解码器，并确定一系列不同的比特率。使用DASH或HLS进行分发目前是最容易处理的，而且可以免除Flash需求。

您可能还希望将流发送到社交媒体服务。这是另一个原因，为什么以高质量的高清流开始非常重要。这些服务将再次转码您的视频，从而降低质量。如果首先使用良好的质量，最终会获得更好的质量。

元数据(聊天、控制信号等)

从您的要求中并不清楚您需要哪种类型的元数据，但对于小型基于消息的数据，您可以使用Web套接字库，例如Socket.IO。当您将其扩展到几个实例时，可以使用pub / sub，例如Redis，将消息分发到服务器中。

将元数据与视频同步取决于元数据中的内容和同步要求。一般来说，您可以假设源视频和客户端之间存在合理但不可预测的延迟。毕竟，您无法控制他们缓冲的时间。每个设备都不同，每个连接都有所不同。您可以假设播放将从客户端下载的第一个片段开始。换句话说，如果客户端开始缓冲视频并在2秒后开始播放它，则视频相对于第一个请求发送的时间滞后2秒。

检测播放实际开始时客户端是可能的。由于服务器知道已发送给客户端的视频的时间戳，因此可以通知客户端其相对于视频播放开始的偏移量。由于您可能会使用DASH或HLS以及需要使用带有AJAX的MCE获取数据，因此可以使用片段响应中的响应标头指示片段开始时间戳。客户端可以自行同步。让我逐步解释一下：

客户端开始从应用服务器接收元数据消息。
客户端从CDN请求第一个视频片段。
CDN服务器回复视频片段。在响应头中，“Date:”头可以指示片段开始的确切日期/时间。
客户端读取响应中的“Date:”头（假设为“2016-06-01 20:31:00”）。客户端继续缓冲片段。
客户端按照正常方式开始缓冲/播放。
播放开始。客户端可以在播放器上检测到状态变化，并知道视频播放器上的“00:00:00”实际上是“2016-06-01 20:31:00”。
客户端同步显示与视频相关的元数据，删除任何早于当前时间的消息并缓冲任何晚于当前时间的消息。

这样可以满足您的需求，并为您以后对视频进行任何操作提供灵活性。

为什么不使用“魔法技术”？

选择低延迟会损失质量。质量来自可用带宽。编码时，整个图像序列的缓冲和优化能够提高带宽效率。如果您想要完美的质量（对于每个图像无损），您需要大量（每个观众几千兆字节）的带宽。这就是为什么我们从一开始就使用有损压缩编解码器的原因。
由于对于大多数观众而言实际上并不需要低延迟，因此最好为他们优化质量。
对于15000个用户中的2个需要低延迟的用户，我们可以为其优化低延迟，但是他们将获得次标准的视频质量，但能够积极地控制一个机器人，这很棒！
始终记住，互联网是一个敌对的环境，在这里，没有任何事情能够像理应如此那样完美地工作。系统资源和带宽是不断变化的。这正是WebRTC自动调整（尽可能合理）适应变化条件的原因。
并非所有连接都能满足低延迟要求。这就是为什么每个低延迟连接都会经历丢失的原因。互联网采用分组交换，而不是电路交换。没有真正的专用带宽可用。
拥有大缓冲区（几秒钟）可以让客户端在短暂的连接中断时保持正常。这就是为什么带有防跳读缓冲器的CD播放器会被创建并且销售得很好的原因。对于这15000个用户来说，如果视频正常工作，则可以获得更好的用户体验。他们不需要知道他们落后于主流5-10秒钟，但是如果视频每隔一秒掉一次，则绝对会感觉到。

每种方法都有取舍。我认为我在这里所概述的分离关注点并为每个领域提供最佳取舍。请随时在评论中要求澄清或提出跟进问题。