WebRTC 和 HLS 有什么区别？

流媒体技术在实现实时通信方面发挥着至关重要的作用，了解它们的差异至关重要。如今，有很多视频会议平台利用不同的流媒体传输协议来实现实时通信和高质量的视频流，选择最好的平台可能具有挑战性。

在本文中，我们将比较两种流行的流媒体协议：HLS 和 WebRTC。我们将深入研究延迟、交付方法、灵活性、视频质量、安全性、可扩展性和成本等各个方面。让我们深入了解 HLS 和 WebRTC 的世界，以做出明智的决定。

什么是HLS？

HLS（即 HTTP Live Streaming）是一种广泛采用的流媒体协议，旨在通过互联网传输媒体内容。HLS 由 Apple 于 2009 年推出，通过实现自适应流媒体和广泛的设备兼容性，彻底改变了流媒体领域。

在 HLS 工作流程中，媒体内容被编码为多种质量变体，从而创建具有不同比特率和分辨率的多种变体。每个变体都分为小段，通常持续时间为 2-10 秒，并托管在内容交付网络 (CDN) 上。然后，这些片段通过 HTTP 传送到客户端设备。

HLS 的主要优势之一是自适应流式传输，也称为 ABR（自适应比特率流式传输）。这使得客户端设备能够根据网络状况和可用带宽动态调整流的质量，即使在网络状况波动的情况下也能确保流畅的播放。

由于其与多种设备和浏览器的兼容性，HSL 在过去十年中得到了普及。如今，HLS 已广泛应用于直播、视频点播和在线活动等应用中。

HLS 与低延迟 HLS

HLS 最初设计时注重可靠性而非速度，因此在 6 – 30 秒的延迟下，它可能不是最快的协议。这种设计流程提出了延迟流媒体的问题以及对低延迟的需求，从而导致了 WebRTC 和通用媒体应用格式等协议的开发。

为了解决此缺陷，Apple 引入了低延迟 HLS (LL-HLS)。LL-HLS 本身并不是一个协议，而是 HSL 的优化变体，您可以将其视为 HLS 的扩展。它的主要开发目的是帮助最大限度地减少视频捕获和传输之间的延迟（减少延迟。）

那么LL-HSL是如何实现低延迟的呢？LL-HLS 通过采用较小的块大小、减少的缓冲以及更快的编码和解码过程等技术来实现低延迟并实现播放。

虽然大多数组织将 HLS 和 LL-HLS 视为两种解决方案，但值得注意的是，这两者基本上是相同的。但是，大多数组织仍然将它们视为不同的解决方案，以帮助其供应商在选择协议时做出更好的决策。

什么是WebRTC？

WebRTC 是 Web Real-Time Communication（Web实时通信）的简称，是一种无需第三方插件或外部即可直接在 Web 浏览器内实现实时通信的技术。它提供了一组协议和 API，使开发人员能够将实时视频、音频和数据共享功能合并到 Web 应用程序中。

WebRTC 的核心由三个关键组件组成：getUserMedia、RTCPeerConnection 和 RTCDataChannel。getUserMedia 允许访问用户的摄像头和麦克风，从而实现实时视频和音频捕获。RTCPeerConnection 促进点对点通信，在浏览器之间建立直接连接以实现无缝数据传输。RTCDataChannel 支持浏览器之间的实时、双向数据交换。

WebRTC 为用户提供原生且无忧的体验。其点对点性质可确保低延迟通信并最大限度地减少服务器依赖性。

HLS 与 WebRTC 全面比较

延迟

从历史上看，由于分段和缓冲，HLS 的延迟范围为 10 到 30 秒。然而，随着 2019 年 Apple 全球开发者大会 (WWDC) 期间引入 LL-HLS，情况发生了变化。最初，HLS 和 LL-HLS 被视为独立的协议，直到 Roger Panton 将它们统一为同一解决方案的两个部分。LL-HLS 现在是 HLS 的一个组成部分，可提供低于 3 秒的延迟。

虽然不到 3 秒的延迟对于大多数应用程序来说已经足够，但某些场景需要更低的延迟。拍卖和远程医疗等交互式直播需要更接近实时的体验。对于超低延迟流媒体，WebRTC 延迟处于领先地位。然而，重要的是要考虑随之而来的权衡。

传输方法

在传输方式方面，HLS 和 WebRTC 采用了不同的方法。

首先，HLS 利用标准 Web 协议和现有网络基础设施进行基于 HTTP 的传输。这使得它与各种服务器和 CDN 高度兼容，提供高效的内容分发。

另一方面，WebRTC 采用更多 P2P 方法，利用实时协议 (RTP) 和实时控制协议 (RTCP) 等实时协议在浏览器之间建立点对点连接。更重要的是，WebRTC 在 UDP 上运行，允许它在客户端和服务器之间无需握手即可建立连接。这使得参与者之间可以进行实时通信，而无需中间服务器。

那么到底哪一方更占上风呢？WebRTC 专为 P2P 双向实时通信而设计，而 HLS 则依赖于 TCP 等其他协议。因此，WebRTC 固有的速度优势使其在交付方式上占据上风。但它也有代价，那就是更容易受到网络波动的影响。

灵活性和兼容性

实际上，HSL 是最灵活、最容易适应的协议，但当我们考虑到它的扩展 LL-HSL 时，事情就变得有点棘手。

作为人们的选择，HSL 得到了多种设备、浏览器和平台的广泛支持，并且与 CDN 完全兼容。此外，它与播放器无缝集成，并支持隐藏式字幕和字幕、元数据、数据权限管理和插入等令人兴奋的功能。

然而，当我们转向 LL-HSL 时，情况就变得有点复杂了。目前，LL-HSL 已经完成。有多种用户真正需要的功能目前不支持，这使得主流采用成为一个挑战。另外，它只支持苹果的原生播放器。然而，由于它支持浏览器，您根本不能忽视 LL-HSL。

WebRTC 怎么样？WebRTC 与大多数浏览器兼容，不需要额外的插件。它可以适应联播和可扩展视频编码 (SVC) 等工作流程，但实施可能需要努力和技术专业知识。

就灵活性和兼容性而言，没有明显的赢家。HLS 提供广泛的兼容性，LL-HLS 正在不断发展，WebRTC 提供本机浏览器支持。做出决定时请考虑延迟和实施要求。

视频质量

当谈到专业流媒体和会议时，自适应比特率 (ABR) 功能是协议可以拥有的最佳工具。它为观众提供一流的用户体验和视频质量，无论其设备或网络状况如何。

就视频质量而言，HLS（包括 LL-HSL）是目前最好的协议。正如我们上面提到的，单个视频的多个再现允许播放器通过自动调整视频流的质量来在不同带宽上提供高质量的视频播放。

另一方面，WebRTC 主要是为了实时延迟而构建的，因此视频质量并不是其首要任务。然而，这并不意味着它不提供高质量的视频。尽管它不提供 ABR 流，但 WebRTC 采用联播和选择性视频编码 (SFU) 来提高视频质量。与典型的联播不同，WebRTC 联播使用选择性转发单元，用于为每个播放设备选择最佳比特率选项。

WebRTC 还参与选择性视频编码 (SVC)，这通常意味着它分层准备媒体文件。简单来说，每当比特率降低时，WebRTC 就会使用 SFU 来分层–可以把它想象成随着比特率的降低而剥洋葱。

虽然 HLS 是获得最佳视频质量的首选，但 WebRTC 提供了提高质量的方法并不断发展，使其成为更好的选择。