对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。他确定了以下思路中的大部分要点。需要强调的是：这些思路并非适用于所有情况。
有关低延迟技术技术的问题：
- 这个技术有被采用过吗？如果答案是肯定的，那么其中包含多少个流？是否有相关的比特率或分辨率限制？
- 有什么质量限制吗？有的话，具体要求是什么？有没有B帧或先行缓冲区？
- 是否需要下载？（大多数系统不需要下载，但问一下总是好的。）
- 系统可以将所有观众同步到流中的同一点吗？（信息流可能会在位置和设备上来回移动。如果没有此功能，连接较快的用户在拍卖或赌博时更占优势。）
- 此技术是否可以穿透防火墙？ （基于HTTP的系统使用可穿透防火墙的HTTP协议，其他使用用户数据报协议的系统可能不支持穿透防火墙。）如果使用的是用户数据报协议（User Datagram Protocol），是否有任何反向通道可以将信息传递给被阻止的用户？
- 有哪些内容保护可用？
- 系统可以扩展至你要求的用户数量吗？CDN基础设施是私有的吗？如果是，它可以传递到所有相关市场中的所有相关用户吗？
- 你是否可以使用自己的播放器，还是必须使用系统的播放器呢？如果支持使用自己的播放器，则需要进行哪些更改，这将花费多少钱呢？
- 移动播放需要哪些支持？是在浏览器中播放？还是需要一个应用程序来播放？
- 此技术还支持哪些其他平台（机顶盒，dongles，OTT设备，智能电视）？
- 你可接受的广播延迟时长范围是多少？
- 项目的总费用是多少？
- 内容可以重新用于VOD还是需要重新编码？
- 有哪些冗余选项？
- 有字幕吗？
- 支持广告插入吗？
- 支持DVR呢？
- 系统可以使用哪些编码器？
（本文刊登于《流媒体杂志》2019年10月期。题目为《速度的重要性》。）
文章来源：https://www.streamingmedia.com/Articles/ReadArticle.aspx?ArticleID=134873
原文作者：Jan Ozer
