低延迟流媒体对高速的大量需求(四)

对WebRTC的错误认知

WebRTC最初是作为Google Hangouts的基础迭代技术而面世的。当时这种技术给大众的惯常印象是低质量的视频。这导致了之后WebRTC被谣传成无法规模化、不可用于ABR以及其视频都是低分辨率和低质量的技术。

确实,WebRTC需要在服务器和播放器之间建立持久连接才能保证其可扩展性。但大型流媒体商店在自己的交付基础架构中已经解决了这一问题。这就是为何要吸引成千上万的观众,就需要使用他们的CDN基础架构或在自己的CDN上部署他们的架构。据CoSMo Software公司的Alexandre Gouaillard称,基于WebRTC的Millicast系统已为一次苏富比拍卖提供了多达5万汇合用户。Nanocosmos公司的Oliver Lietz称在公司最近的一次活动10万多名观众是通过WebSockets参与进来的。因此,我们应该把可扩展性视为潜在成本问题,而不是能力问题。

ABR和流质量问题同上。WebRTC方案可以并行合并多个流(不是所有WebRTC方案都支持此功能)。有些浏览器会限制分辨率或流带宽,这不是WebRTC造成的。

并非所有基于WebRTC的服务都可以提供所有上述这些功能,因此我们在几种候选服务种选择时需要自行检查(是否具备这些功能)。但是可扩展性、ABR和质量并不是不选择WebRTC的硬性条件。这几项的总成本是否等同于HAS系统是另一回事。

有趣的新方案

除了上述三类产品之外,流媒体生态系统中还有来自一些来自不同公司的创新产品。其中一项是THEO Technologies公司的高效流协议(HESP),该协议基于一项新的HAS协议。根据THEO Technologies公司的网站介绍,这项协议可提供不到一秒的延迟。到第一帧的时间大约为100毫秒,并且查看器的带宽优化高达20%。此外,它还与HTTP CDN兼容。

专有技术肯定会面临各种挑战,对HESP来说,此协议似乎通过HAS解决方案的可扩展性来解决WebRTC的延迟问题。如果你在寻找亚秒级的延迟技术,HESP值得一试。

谨慎选择服务提供商

Nanocosmos公司的Lietz说,他的客户不关注要使用哪种技术去解决问题。他们要的是一个功能强大且价格合理的端到端平台,且延迟要尽可能短。因此,文章最后我将提供一些思路以解决这个问题。感谢Phenix的首席产品官Bill Wishon。他确定了以下思路中的大部分要点。需要强调的是:这些思路并非适用于所有情况。

有关低延迟技术技术的问题:

  1. 这个技术有被采用过吗?如果答案是肯定的,那么其中包含多少个流?是否有相关的比特率或分辨率限制?
  2. 有什么质量限制吗?有的话,具体要求是什么?有没有B帧或先行缓冲区?
  3. 是否需要下载?(大多数系统不需要下载,但问一下总是好的。)
  4. 系统可以将所有观众同步到流中的同一点吗?(信息流可能会在位置和设备上来回移动。如果没有此功能,连接较快的用户在拍卖或赌博时更占优势。)
  5. 此技术是否可以穿透防火墙? (基于HTTP的系统使用可穿透防火墙的HTTP协议,其他使用用户数据报协议的系统可能不支持穿透防火墙。)如果使用的是用户数据报协议(User Datagram Protocol),是否有任何反向通道可以将信息传递给被阻止的用户?
  6. 有哪些内容保护可用?
  7. 系统可以扩展至你要求的用户数量吗?CDN基础设施是私有的吗?如果是,它可以传递到所有相关市场中的所有相关用户吗?
  8. 你是否可以使用自己的播放器,还是必须使用系统的播放器呢?如果支持使用自己的播放器,则需要进行哪些更改,这将花费多少钱呢?
  9. 移动播放需要哪些支持?是在浏览器中播放?还是需要一个应用程序来播放?
  10. 此技术还支持哪些其他平台(机顶盒,dongles,OTT设备,智能电视)?
  11. 你可接受的广播延迟时长范围是多少?
  12. 项目的总费用是多少?
  13. 内容可以重新用于VOD还是需要重新编码?
  14. 有哪些冗余选项?
  15. 有字幕吗?
  16. 支持广告插入吗?
  17. 支持DVR呢?
  18. 系统可以使用哪些编码器?

(本文刊登于《流媒体杂志》2019年10月期。题目为《速度的重要性》。)

文章来源:https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=134873

原文作者:Jan Ozer

填写常用邮箱,接收社区更新

WebRTC 中文社区由

运营