观看 IP 摄像机：WebRTC 与 HLS
WebRTC 与 HLS 解决的是同一个任务——把视频流展示给观众——但组织传输的方式不同。WebRTC 面向低延迟，而普通 HLS 依赖分段下载和播放缓冲区。
RTSP.ME 同时支持两种方式，并会自动选择播放方式。用户无需在 WebRTC 和 HLS 之间手动选择。
下面我们来看每种方式如何影响延迟、播放稳定性以及与观众设备的兼容性。
接入 IP 摄像机摄像机的 RTSP 与浏览器播放不是一回事
IP 摄像机可以通过 RTSP 将视频流传入服务。而视频从服务传到浏览器是另一个独立环节，这一环节使用 WebRTC 或 HLS。
摄像机无需自带 WebRTC 支持。重要的是其视频流符合服务的接入要求。仅仅选择向浏览器传输的方式，并不能让摄像机的任意编解码器兼容观众的任意设备。
WebRTC 与 HLS：对比
表格描述的是技术的一般特性，而非某条具体直播的保证参数。除非另有说明，此处的 HLS 指普通的分段传输。
| 参数 | WebRTC | HLS |
|---|---|---|
| 传输方式 | 传输媒体数据以实现实时播放 | 通过 HTTP(S) 下载播放列表和视频分段 |
| 延迟 | 通常低于普通 HLS；取决于整条链路 | 由于生成分段和累积缓冲，通常较高 |
| 典型任务 | 需要快速响应的监控和互动场景 | 允许与事件存在一定延迟的直播观看 |
| 缓冲 | 较小的缓冲有助于降低延迟，但应对网络波动的余量更少 | 缓冲可以平滑短暂的速度波动，代价是延迟增加 |
| 网络 | NAT、防火墙和 UDP 限制可能妨碍连接 | HTTP(S) 传输便于融入 Web 基础设施，但同样受网络限制和质量影响 |
| 大量观众 | 需要用于维护连接和分配负载的基础设施 | 经适当配置后，分段可兼容 HTTP 缓存和 CDN |
| 浏览器与编解码器 | 需要浏览器、设备以及所传输的视频和音频编解码器相互兼容 | 取决于编解码器和播放器；并非所有浏览器都能原生播放 M3U8 |
| 传输保护 | 媒体传输经过加密 | 当播放列表和分段通过 HTTPS 提供时，传输受到保护 |
WebRTC：优势与限制
当低延迟很重要时
WebRTC 面向媒体数据的实时传输。当需要更快看到画面变化，或在聊天中与观众讨论正在发生的事情时，它很有用：视频延迟更小，有助于把消息与屏幕上的事件对应起来。
- 相比需要缓冲分段的普通 HLS，与实际事件的延迟通常更小。
- 无需等待累积一系列完整的 HLS 分段。
- 媒体传输加密是 WebRTC 的组成部分。
哪些因素可能妨碍观看
NAT、防火墙和 UDP 封锁可能使连接建立变得困难。在此类网络中能否工作，取决于媒体服务器的配置和可用的连接方式。如果在企业网络中无法启动播放，应与网络管理员一起检查其限制。
丢包、链路不稳定、服务器或观众设备过载都可能导致画质下降和中断。低延迟不等于零延迟：拍摄、编码、传输、处理和显示画面都需要时间。
HLS：优势与限制
通过常规 Web 基础设施传输
HLS 使用播放列表（通常扩展名为 M3U8）和一系列媒体分段。播放器通过 HTTP 或 HTTPS 下载它们，并形成用于播放的数据储备。
- 分段传输兼容 HTTP 服务器、缓存和 CDN，便于扩展到大量观众。
- 缓冲有助于在下载速度短暂波动时继续播放。
- 适合全景和公开直播——只要与事件的小幅延迟不影响任务。
实际的扩展能力取决于服务器资源、带宽和传输设置：仅选择 HLS 不足以服务大量观众。
延迟与兼容性
生成分段并在缓冲区中累积，通常会使延迟高于 WebRTC。如果下载速度长期低于视频流的码率，缓冲区会耗尽，播放可能停止。HLS 无法让薄弱的网络变得可靠。
并非所有浏览器都能直接打开 M3U8：可能需要借助浏览器能力的 JavaScript 播放器。支持 HLS 本身并不保证能播放任意视频或音频编解码器。
RTSP.ME 如何进行选择
服务支持 WebRTC 和 HLS，并会自动选择播放方式。用户接入摄像机并在播放器中打开直播即可；无需手动选择观看协议。
自动选择让您无需在每次观看前自行比较协议。但它并不取消对源视频流、浏览器和网络的要求。
编解码器、音频与安全性
分别检查视频和音频
播放取决于浏览器、操作系统、设备、摄像机的视频编解码器及其配置，以及服务器和播放器处理视频流的能力。协议名称并不保证兼容性。
对于音频，音频编解码器至关重要。即使音频不兼容，画面也可能正常显示。此外，浏览器可能在用户操作之前阻止带声音的自动播放：没有声音并不总是意味着摄像机故障。
加密不能替代访问控制
WebRTC 使用加密的媒体传输。当播放列表和分段通过 HTTPS 传输时，HLS 会保护传输中的数据；HLS 本身并不意味着必须使用 HTTPS。
服务到浏览器这一环节的保护，并不决定摄像机接入服务的安全性。传输加密同样不能替代观众权限验证、访问限制和摄像机凭据保护。发布前请确认直播仅对目标受众开放。
实用建议
- 明确观看任务。需要快速响应时，实际延迟很重要；全景直播则还需要长期稳定。在 RTSP.ME 中，无需把这些需求转化为手动协议选择。
- 检查源视频流。确认摄像机稳定传输视频，且视频和音频参数符合服务要求。码率过高可能使摄像机侧链路过载。
- 检查观众设备。在电脑和手机的目标浏览器中打开直播。分别检查启动、声音和长时间观看。
- 比较允许的网络。如果在企业网络中无法观看，请与其他可用网络比较结果，并与管理员讨论限制。不要为了直播而关闭网络防护。
- 评估整条链路。延迟和停顿取决于摄像机、到服务的链路、服务器、观众网络和播放器。WebRTC 和 HLS 都无法修复缺失的源视频流。
- 联系技术支持时说明情况。请提供浏览器、设备、问题发生时间和症状。不要公开分享包含密码的 RTSP 链接或其他机密信息。
不应把 WebRTC 和 HLS 分为“好”协议和“坏”协议。它们在延迟、缓冲和传输组织方式上有不同的取舍，最终效果需要在具体直播中验证。