低延迟（＆lt; 2s）直播视频流HTML5解决方案？

Question

Chrome很快就会禁用Flash，我需要开始研究flash / rtmp html5替代解决方案。

目前使用Flash + RTMP我有一个实时视频流＆lt; 1-2秒延迟。

我已经尝试过MPEG-DASH，这似乎是流媒体的新行业标准，但是我认为5秒延迟是我可以从中获得的最佳延迟。

对于上下文，我试图允许用户控制他们可以在流上看到的物理对象，因此任何超过几秒延迟的事情都会导致令人沮丧的体验。

是否还有其他技术，或者实际上没有用于实时流媒体的低延迟html5解决方案？

Answer 1

技术和要求

WebRTC是唯一真正面向低延迟的基于Web的技术集。它专为视频会议而构建。编解码器针对低质量延迟进行了调整。比特率通常是可变的，选择稳定的连接而不是质量。

但是，您并不一定需要为所有用户提供此低延迟优化。事实上，从我可以收集的要求来看，每个人的低延迟都会损害用户体验。虽然控制机器人的用户肯定需要低延迟视频，因此他们可以合理地控制它，但不受控制的用户不具备此要求，而是可以选择可靠的高质量视频。

如何设置

In-Control用户到机器人连接

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

凸轮/控制服务器还需要通过WebRTC连接。老实说，最简单的方法是使您的控制应用程序在某种程度上基于Web。由于您已经在使用Node.js，请查看NW.js或Electron。两者都可以利用WebKit中已经内置的WebRTC功能，同时仍然可以灵活地为Node.js做任何你喜欢的事情。

控制中用户和凸轮/控制服务器将通过WebRTC（或TURN服务器，如果需要）建立对等连接。从那里，您将要打开媒体渠道和数据渠道。数据端可用于发送机器人命令。当然，媒体频道将用于将低延迟视频流发送回控制中用户。

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

查看用户的视频

只是查看流而不是控制机器人的用户可以使用普通的视频分发方法。使用现有的CDN和转码服务实际上非常重要，因为您将有10k-15k的人观看流。有了这么多用户，你可能会想要在几个不同的编解码器中使用你的视频，当然还有一大堆比特率。使用DASH或HLS进行分发最容易使用，并且可以解除Flash要求。

您可能还希望将自己的信息流发送到社交媒体服务。这是开始使用高质量HD流的重要原因的另一个原因。这些服务会再次转码您的视频，从而降低质量。如果你先从优质开始，最终你的质量会更好。

元数据（聊天，控制信号等）

根据您的要求，您无需清楚所需的元数据类型，但对于基于消息的小型数据，您可以使用Web套接字库，例如Socket.IO。在将其扩展到几个实例时，您可以使用pub / sub（例如Redis）在整个服务器中进行分发消息传递。

将元数据同步到视频取决于该元数据中的内容以及具体的同步要求。一般来说，您可以假设源视频和客户端之间存在合理但不可预测的延迟。毕竟，你无法控制缓冲时间。每个设备都是不同的，每个连接变量。您可以假设回放将从客户端下载的第一个段开始。换句话说，如果客户端开始缓冲视频并在2秒后开始播放，则视频比第一次请求时间落后2秒。

检测播放何时实际开始客户端 是可能的。由于服务器知道视频被发送到客户端的时间戳，因此它可以通知客户端其相对于视频回放开始的偏移量。由于您可能正在使用DASH或HLS，并且您需要使用MCE和AJAX来获取数据，因此您可以use the response headers in the segment response指示段开始的时间戳。然后客户端可以自己同步。让我一步一步地解决这个问题：

1. 客户端开始从应用程序服务器接收元数据消息。
2. 客户从CDN请求第一个视频片段。
3. CDN服务器回复视频片段。在响应标头中，Date:标头可以指示段开始的确切日期/时间。
4. 客户端会阅读回复Date:标题（让我们说2016-06-01 20:31:00）。客户端继续缓冲段。
5. 客户端正常开始缓冲/播放。
6. 开始播放。客户可以在播放器上检测到此状态更改，并且知道视频播放器上的00:00:00是实际的2016-06-01 20:31:00。
7. 客户端显示与视频同步的元数据，丢弃以前的所有消息，并在将来缓冲任何消息。

这应该可以满足您的需求，并且可以灵活地为您的视频提供所需的一切。

为什么不[魔术技术 - 这里]？

• 当您选择低延迟时，您会失去质量。质量来自可用带宽。带宽效率来自于在编码时能够缓冲和优化整个图像序列。如果你想要完美的质量（每个图像无损），你需要一吨（每个观众千兆位）的带宽。这就是我们开始使用这些有损编解码器的原因。
• 由于您实际上 需要大多数观看者的延迟，因此优化它们的质量会更好。
• 对于15,000个需要低延迟的2个用户，我们可以优化它们的低延迟。他们的视频质量会不合标准，但能够主动控制机器人，这太棒了！
• 永远记住，互联网是一个充满敌意的地方，没有任何东西可以正常运作。系统资源和带宽不断变化。这就是为什么WebRTC会自动调整（尽可能合理）改变条件的原因。
• 并非所有连接都能满足低延迟要求。这就是为什么每个低延迟连接都会遇到辍学的原因。互联网是分组交换的，而不是电路交换的。没有真正的专用带宽。
• 拥有一个大缓冲区（几秒钟），使客户能够在短暂的连接丢失中幸存下来。这就是为什么创建具有反跳过缓冲区的CD播放器并且销售得非常好的原因。如果视频正常工作，那15,000个用户可以获得更好的用户体验。他们不必知道他们比主流落后5-10秒，但他们肯定会知道视频是否会每隔一秒就会消失。

每种方法都有权衡。我认为我在此概述的内容将这些问题分开，并为您提供每个领域的最佳权衡。请随时在评论中要求澄清或提出后续问题。

Answer 2

尚未准备就绪（希望今年下半年），但DASH over Full Duplex HTTP-based Protocols将允许您在websockets上使用MPEG DASH，提供DASH的好处（开源，ABR，兼容性......） ，以及其他格式的低延迟（例如WebRTC，which doesnt work on safari btw）。

所以任何人都要考虑几个月后的低延迟视频格式，试着留意这一点。

Answer 3

转到WebRTC，因为：

WebRTC是支持基于浏览器的实时通信的标准。最初由Google开发，该标准现在由W3C管理。 WebRTC支持语音呼叫，视频聊天和文件共享的浏览器到浏览器应用程序，而不需要任何外部插件，而不是兼容的浏览器。

好处：

• WebRTC解决方案可以帮助将实时统一通信（UC）扩展到企业范围之外 - 通过支持WebRTC的浏览器向任何客户，合作伙伴或供应商提供。
• 支持WebRTC的技术使移动网络运营商能够在移动设备上创造更具吸引力的客户体验。例如，将语音或视频功能添加到移动运营商提供的应用程序中将允许订户联系客户服务代表以获得更加个性化的支持。
• WebRTC消除了用户打开统一通信客户端的需求，从而降低了企业IT部署和支持成本。与此同时，WebRTC允许电信公司和开发人员使用有限/基本的开发资源创建支持WebRTC的通信和协作应用程序。
• 通过使用开放标准和浏览器，WebRTC消除了对复杂系统的需求，以便跨防火墙扩展用户以进行视频协作和共享。在某些情况下，WebRTC实际上可以通过快速帮助客户和潜在客户获取所需信息来缩短整体销售周期。

WebRTC Testing.

Answer 4

您是否查看过Ant Media Server超低延迟流媒体解决方案？他们在产品中使用WebRTC Tech。另外，AMS是开源媒体服务器。

Ant Media Server能够通过WebRTC技术实现超低延迟的流传输，其典型值为0.5秒

任何类型的实时流都可以通过云上的可伸缩群集基础结构交付给广泛的客户端。提供Android，iOS和JavaScript SDK。

此外，您可以测试以下链接；

WebRTC发布者：https://test.antmedia.io:5443/WebRTCAppEE/

WebRTC播放：https://test.antmedia.io:5443/WebRTCAppEE/player.html

WebRTC实时演示：https://antmedia.io/livedemo/

Ant Media Server Github页面：https://github.com/ant-media/Ant-Media-Server

Ant Media Server Google网上论坛：https://groups.google.com/forum/m/#!forum/ant-media-server

也请查看网站：https://antmedia.io