低延迟(<2s)实时视频流HTML5解决方案？

Question

由于Chrome很快就会禁用Flash,我需要开始研究flash/rtmp html5替换解决方案.

目前使用Flash + RTMP,我有一个实时视频流,延迟时间<1-2秒.

我已经尝试过MPEG-DASH,这似乎是流媒体的新行业标准,但是我认为5秒延迟是我能从中榨取的最好的延迟.

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

有没有其他技术,或者是否真的没有低延迟的html5解决方案用于直播？

Answer 1

技术和要求

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

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

如何设置它

控制用户到机器人连接

控制机器人的用户将加载一个页面,该页面利用一些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要求.

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

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

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

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

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

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秒,但他们肯定会知道视频是否会每隔一秒就消失一次.

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