如何构建可扩展的低延迟流解决方案

在本文中，我将研究大规模的低延迟直播, 以及使之成为可能的标准和工具. 作为一名玩家开发者, 我对低延迟直播和交互性的概念特别感兴趣. 太久了, 我们将流媒体播放器限制在与VCR相同的控制:播放, 暂停, 倒带, 快进, 等等......。. 但低延迟和交互性扩展了视频播放器的意义.

图1(下面) 展示了一些融入互动元素的玩家例子. 用潜望镜, 你有一个想法，在他们的手机上直播，他们的粉丝观看并点击小心形按钮. 主播可以看到这些，并对反馈做出反应. 有了Twitch，你就有了一个视频游戏主播. 他们的粉丝正在和直播聊天, 玩家可以对聊天中发生的事情做出回应, 观众会得到反馈. HQ是一款很受欢迎的问答应用，在那里你会有一个主持人来提问, 观众也在回应, 回答这些问题，主持人就会宣读结果. 你需要Q的快速反馈 & A.

图1. 交互式流媒体应用 

何时低延迟很重要(以及为什么)

传统的广播媒体不需要这种互动性. 对于像超级碗或奥运会这样的比赛，这更像是一种背靠椅背的体验. 你可能有一个推特，但它意味着坐下来. 你没有和球场上的人或新闻里的人互动. 你只是在消费流.

当然, 延迟也会降低这些体验, 当你在家看比赛时，在你自己看到进球前10秒，你听到你的邻居为你的进球欢呼. 这破坏了气氛. 这是广播媒体的一个真正问题, 但我认为延迟并不像交互式视频那样是个大问题.

比如超级碗或者世界杯, 制作方打算在流媒体离开会场之前引入多达30秒的延迟. 他们在那里会有一些延迟，这样如果评论员开始偏离轨道并滔滔不绝地说一些疯狂的话，导演就可以切到一个商业广告.

在某些情况下，低延迟不值得这么麻烦. 以获得更低的延迟, 不管你在做什么, 你在网络中引入了一定程度的成本和不稳定性, 从场地到玩家. 在大型活动中，制作方不愿冒这么大的风险或承担额外的成本. 你会选择一些你知道是稳定的、持续的、可靠的东西.

最后，流媒体观众比延迟更讨厌的是重新缓冲. 我们都有过这样的经历, 当一名球员准备射门时，他必须重新缓冲.

大多数时候, 当这种情况发生时, 更低延迟的概念正在向链中引入更多的再缓冲. 减少延迟降低了玩家为了保护自己免受进一步的重新缓冲而保留的缓冲区. 当你这么做的时候, 你很有可能会向更广泛的受众介绍更多的“再缓冲”.

没有人会尝试这样的低延迟流，除非他们确信不会通过降低延迟来引入更多的再缓冲. 避免重新缓冲是更高的优先级.

也, 当我说“互动直播”时,“我说的不是实时, 双向音频通信应用，比如Google Hangouts, Skype, 或放大. 有了这些，你的目标是0.3秒或更短的延迟. 你会得到大于0的值.在这种情况下只有3秒，说话者开始互相交谈.

有了互动直播，我们不会把Google Hangouts的房间扩大到1000人. 它不是用来做这个的. 我们在说什么, 低延迟直播, 有规模, 这很有趣, 因为它正好在这两者之间, 同时也接受了双方的挑战.

构建一个交互式流媒体应用程序

当构建涉及查看器交互和低延迟流的应用程序时, 你需要一些东西. 首先, 你需要一个实时数据框架, 基于成熟的技术，如web sockets和WebRTC数据通道. 许多现成的专有服务，如Firebase, 推杆式, 或者HubNub可以帮助你构建一个应用程序，它足够快速和可靠，当参与者发送聊天消息时, 其他观众几乎可以马上看到它. 今天，实时数据是一个相对解决的问题.

在另一边, 我们有大规模的低延迟视频, 对此我们并没有明确的解决方案, 尽管可行的标准和解决方案开始出现.

流媒体视频的低延迟有多低?

中所示的图表 图2(下面) 说明了什么是视频的低延迟. 左侧显示高延迟，30-60秒. 这是相对常见的，特别是在网页或iOS设备上. 当苹果首次推出HLS时, 他们建议你首先把视频剪成10秒的片段, 玩家应该在游戏开始前缓冲3秒. 所以，3秒乘以10秒等于30秒. 这只存在于玩家本身, 这还不包括从镜头到玩家的延迟.

 

图2. 直播延迟频谱

在过去的几年里, 人们已经开始将片段的长度减少到2-6秒，以便玩家更快地开始游戏，并将延迟减少到6-18秒. 如前所述，您引入了更多的重新缓冲. 但如果你采用这种方法，你的玩家和网络是可靠的, 低延迟变得更容易实现. 

有很多低延迟的一秒片段直播流的演示. 问题是，这些演示在演示环境之外并不总是能很好地工作. 一旦你进入现实世界的网络, 当您每秒请求一次数据时，就会出现问题. The requests themselves can have as much as half a second of overhead; even just starting to receive the data for those segments can have overhead. 所以你实际上是在向那些请求中引入空气，这将使它更难跟上这股流, 而且很难不进入再缓冲状态.

当我们缩小到一秒钟的片段时, 他们开始更快地倒下, 特别是在移动网络和更困难的网络上. 我不建议你这么做. 当然欢迎您来测试一下, 但是当你在看演示展示如何通过一秒钟的片段达到这个水平, 只是在生产中要小心, 这可能不太管用.

对于两秒的片段，我们可以开始了解低延迟的概念. 如果你把时间缩短到6秒——假设你从镜头到玩家的延迟时间少于4秒——那么你就在10秒的范围内了. 这些数字并不完美，但它们在现实世界中是有效的. 最近，我与一位正在制作Twitch克隆游戏的开发者进行了交谈. 他们在窗口旁边聊天，今天他们对10秒钟的片段很满意. 当然, 最好没有延迟, 但对于所涉及的交互类型和与聊天的反应能力, 10秒以下是人们, 根据我的经验, 我要求.

Twitch刚开始的时候, 他们有长达20秒的片段, 用户开始习惯从发起聊天到收到回复之间有20秒的延迟. 现在推奇的频率降到了6秒以下, 随着人们越来越习惯这一点，期望可能会发生变化.

但是今天, 当我与构建这些应用程序的开发人员交谈时, 知道挑战在于降低延迟, 我听到有人要求给这些申请10秒钟. 当你进入类似总部的琐事应用程序时, 主持人的主要工作就是回应观众的反应, 这时候我就会听到4秒或更短的请求.

至于亚秒级的延迟，那是webbrtc的领域. RTMP也适用于这个领域. 这些协议对于实现实时音频通信非常有用, 但它们的规模化成本相对较高. 相比之下, HTTP——包括图2中亚秒级以下的所有内容——扩展起来很便宜, 但这使得降低延迟变得困难.

在这个超低延迟范围内, 两种不同的机制正在竞争成为每个人在扩展WebRTC时都使用的低延迟协议, 使用一堆媒体服务器, 而不是试图找出如何以某种方式破解清单，以便尽快将这些大块内容呈现给玩家.