在文章 什么是WHIP？中，我们讨论了 WebRTC 和为帮助我们使用它摄取数据而开发的新标准，称为 WHIP。但是，对于摄取的数据，可能需要在某个时候传出或分发相同的数据，因此引入 WebRTC-HTTP egress protocol 或 WHEP。抽象地说，摄取是涵盖将数据上传到服务器的部分，而输出则是处理下载到终端用户的问题。我们从WHIP获得的好处，如低延迟和端到端加密，也适用于此： WHEP在内容交付管道的另一端实现了WebRTC通信；WHEP协助向观看者提供内容。
在这篇文章中，我们将了解 WHEP，这是一种 IETF 协议，其开发目的是让我们使用 WebRTC 将内容输出到其他目的地，作为一种从以前的标准通过网络实现内容交付现代化的方式。
为什么 WHEP 有用？
如上所述，在使用基于 WebRTC 的内容交付时，WHIP 只解决了方程式的一半。虽然您可以阅读 官方 IETF 文档，但我们将在此处进行更简单的总结。WHEP 旨在解决基于 WebRTC 的内容的分发方面，请参见下图，以使用 Dolby.io 实时流媒体 API 为例，直观地了解这如何协同工作：
让 WHEP 补充广播 WebRTC 基础设施出口的好处类似于 WHIP 的好处，即标准化。与 WHIP 允许广播公司专注于基础设施及其扩展而无需担心物流一样，WHEP 允许分销商专注于最终用户体验，因为他们确切地知道数据将如何接收和处理。最终目标是通过标准化优化各方的时间和资源。
WHIP 和 WHEP 对实时视频的作用类似于 RTMP 对 Flash 视频的作用或 SRT 对传输流的作用。它规范了媒体服务器之间的对话方式（协议），就像一种语言，因此，任何 WHIP 编码器都可以与任何 WHIP 服务器对话，任何 WHEP 服务都可以与任何 WHEP 播放器对话，而不需要任何其他设置。无论使用哪种环境，使用 WHIP/WHEP URL 都应该简单地工作。
在许多情况下，通过 WebRTC 进行流媒体消费的标准协议会有所帮助。一些选项或示例包括：
- WebRTC 服务、媒体服务器、发布者和播放器之间的互操作性
- 在不支持自定义 JavaScript 脚本的电视和其他智能设备上播放 WebRTC 流
- 为媒体播放器创建模块化、可重复使用的软件
- 与DASH集成 ，DASH 是当前流行的自适应比特率流媒体标准
它与仅仅是“WHIP 规范但相反”的不同之处在于协议的细节。虽然在大多数情况下它的行为与 WHIP 相同，使用带有 Bearer Tokens 的 HTTP 请求进行身份验证，但它在 SDP 通信中更加灵活。WHEP 允许在同一个 HTTP 请求中立即发送 SDP 提议，或者发送一个 POST 请求以接收返回的提议。这根据用例和环境提供了更大的灵活性，可以在上面提供的白皮书中了解更多信息。例如，业界使用的旧标准 RTSP 不支持此模型。
作者：Griffin Solot-Kehl
原文：https://dolby.io/blog/what-is-whep-intro-to-webrtc-streaming-part-2/
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/jishu/webrtc/25937.html
