协议-WebRTC-HLS

是什么？

WebRTC（Web Real-Time Communication）

• 实现 Web 浏览器和移动应用程序之间通过互联网直接进行实时通信。
• 允许点对点音频、视频和数据共享，而无需任何插件或其他软件。
• WebRTC 广泛用于构建视频会议、语音通话、直播、在线游戏等应用程序

HLS （HTTP Live Streaming）

• HLS协议由苹果公司提出，解决RTMP协议不使用标准的HTTP接口传输数据，可能被防火墙屏蔽掉等问题

---

为什么？

说到 WebRTC，我们不得不提到 Gobal IP Solutions，简称 GIPS。这是一家 1990 年成立于瑞典斯德哥尔摩的 VoIP 软件开发商，提供了可以说是世界上最好的语音引擎。

Skype、腾讯 QQ、WebEx、Vidyo 等都使用了它的音频处理引擎，包含了受专利保护的回声消除算法，适应网络抖动和丢包的低延迟算法，以及先进的音频编解码器。

Google 在 Gtalk 中也使用了 GIPS 的授权。Google 在 2011 年收购了 GIPS，并将其源代码开源，加上在 2010 年收购的 On2 获取到的 VPx 系列视频编解码器，WebRTC 开源项目应运而生，即 GIPS 音视频引擎 + 替换掉 H.264 的 VPx 视频编解码器。

在此之后，Google 又将在 Gtalk 中用于 P2P 打洞的开源项目 libjingle 融合进了 WebRTC。所以目前 WebRTC 提供了在 Web、iOS、Android、Mac、Windows、Linux 在内的所有平台的 API，保证了 API 在所有平台的一致性。使用 WebRTC 的好处主要有以下几个方面：

1. 免费的使用 GIPS 先进的音视频引擎，在此之前都需要付费授权。
2. 由于音视频传输是基于点对点传输的，所以实现简单的 1 对 1 通话场景，需要较少的服务器资源，借助免费的 STUN/TURN 服务器可以大大节约成本开销。
3. 开发 Web 版本的应用非常方便，使用简单的 JS 接口，无需安装任何插件，即可实现音视频互通。

WebRTC诞生纯粹就是Google的一个收购行为，并非像H.264是需求主动研发推动

• 定义就是集各家所长的结合体
• GIPS 音视频引擎 + 替换掉 H.264 的 VPx 视频编解码器 + Gtalk 中用于 P2P（Peer-to-Peer） 打洞的开源项目 libjingle

直播业务增长使得更多人选择WebRTC

• RTMP 完全可以满足直播产品的需求，但由于其相对延时较高，不能满足视频互通的产品需求
• 自研一套符合视频互通要求的通信系统相对复杂，对开发者的技术栈要求很高，所以越来越多的人选择 WebRTC

---

怎么做？

• 流媒体服务软件可以使用SRS
  • SRS是国内研发的一个比较流行的开源流媒体服务软件
  • 囊括了RTMP、HLS、WebRTC、HTTP-FLV等主流协议

Live Streaming

docker run --rm -it -p 1935:1935 -p 1985:1985 -p 8080:8080 registry.cn-hangzhou.aliyuncs.com/ossrs/srs:5

ffmpeg -re -i ./doc/source.flv -c copy -f flv rtmp://localhost/live/livestream

• 打开下面的页面播放流
  • RTMP (by VLC): rtmp://localhost/live/livestream
  • H5(HTTP-FLV): http://localhost:8080/live/livestream.flv
  • H5(HLS): http://localhost:8080/live/livestream.m3u8

SRS支持WebRTC，可以做会议或视频聊天

CANDIDATE="192.168.1.10"
docker run --rm -it -p 1935:1935 -p 1985:1985 -p 8080:8080 -p 1990:1990 -p 8088:8088 \--env CANDIDATE=$CANDIDATE -p 8000:8000/udp \registry.cn-hangzhou.aliyuncs.com/ossrs/srs:5

• 使用WebRTC推流到SRS：WebRTC: Publish
• 打开页面观看WebRTC流：WebRTC: Play

WebRTC for Live Streaming

CANDIDATE="192.168.1.10"
docker run --rm -it -p 1935:1935 -p 1985:1985 -p 8080:8080 \--env CANDIDATE=$CANDIDATE -p 8000:8000/udp \registry.cn-hangzhou.aliyuncs.com/ossrs/srs:5 ./objs/srs -c conf/rtmp2rtc.conf

• 如果RTMP转WebRTC流播放，必须使用配置文件rtmp2rtc.conf

ffmpeg -re -i ./doc/source.flv -c copy -f flv rtmp://localhost/live/livestream

• 打开下面的页面播放流（若SRS不在本机，请将localhost更换成服务器IP）
  • WebRTC: http://localhost:1985/rtc/v1/whep/?app=live&stream=livestream
  • H5(HTTP-FLV): http://localhost:8080/live/livestream.flv
  • H5(HLS): http://localhost:8080/live/livestream.m3u8

使用 ffmpeg-webrtc

git clone  https://github.com/ossrs/ffmpeg-webrtc.git
./configure --enable-muxer=whip --enable-openssl --enable-version3 --enable-libx264 --enable-gpl --enable-libopus
make -j10

• x264
• libopus
• openssl
• whip-muxer

ffmpeg -re -i source.flv \
-c:v libx264 -profile:v baseline \
-c:a libopus -ar 48000 -ac 2 -ab 32k \
-f whip "http://192.168.1.100:1985/rtc/v1/whip/?app=live&stream=livestream"

WebRTC using HTTPS

• 非本机推拉流，也就是不能用localhost访问SRS时，浏览器限制必须HTTPS才能推拉流

CANDIDATE="192.168.1.10"
docker run --rm -it -p 1935:1935 -p 1985:1985 -p 8080:8080 -p 1990:1990 -p 8088:8088 \--env CANDIDATE=$CANDIDATE -p 8000:8000/udp \registry.cn-hangzhou.aliyuncs.com/ossrs/srs:5 ./objs/srs -c conf/https.docker.conf

---

核心本质

WebRTC本质就三个名词 ,这是协商机制

• ICE
• STUN
• TURN

WebRTC数据封装就两个名词

• RTP
• RTCP

HLS本质就两个后缀

• .m3u8
• .ts

---

WebRTC详解

• WebRTC虽然是点对点的协议，应用在直播场景的话需要搭建WebRTC服务器作为流媒体服务

ICE（Interactive Connectivity Establishment）

• 允许你的浏览器和对端浏览器建立连接的协议框架

为什么需要ICE协议

• 在实际的网络当中，从 A 端到 B 端直连不能直接连接。
  • 需要绕过阻止建立连接的防火墙，给你的设备分配一个唯一可见的地址
  • 通常情况下我们的大部分设备没有一个固定的公网地址
  • 如果路由器不允许主机直连，还得通过一台服务器转发数据

NAT（Network Address Translation）

• 给私网设备映射一个公网的 IP 地址和唯一的端口，以便被外网设备发现

STUN（Session Traversal Utilities for NAT）

• 在两个用户通信前，首先会向公网的 STUN 服务发送请求获取自己的公网地址，然后通过服务器将各自的公网地址转发给对等端，这样双方就知道了对方的公网地址，根据这个公网地址就可以直接点对点通信了。

为什么需要TRUN协议

• 一些路由器使用一种“对称型 NAT”的 NAT 模型，不同设备会产生不同端口
• 无法通过STUN 服务器识别的该内网设备的公网 IP 和端口 传递给 要连接服务器，因为端口会改变

什么是对称NAT （Symmetric NAT），是如何运作的？

• 同一个内部设备在与不同的外部设备通信时，可能会使用同一外部IP地址和不同的端口
• 对称NAT对每个连接都进行严格管理，外部设备无法主动发起连接，只能由内部设备主动发起连接
• 设备A与S1通信时使用的是（203.0.113.1:12345），而与S2通信时使用的是（203.0.113.1:12346）

TURN (Traversal Using Relays around NAT)

• 通过 TURN 服务器中继所有数据的方式来绕过“对称型 NAT”。你需要在 TURN 服务器上创建一个连接，然后告诉所有对端设备发包到服务器上，TURN 服务器再把包转发给你。
• 很显然这种方式是开销很大的，所以只有在没得选择的情况下采用。

SDP（Session Description Protocol)

• 描述多媒体连接内容的协议，例如分辨率，格式，编码，加密算法等
• SDP 由一行或多行 UTF-8 文本组成，每行以一个字符的类型开头，后跟等号（“ =”），然后是包含值或描述的结构化文本，其格式取决于类型

具体通讯流程

信令服务器 Signal Channel(图中) 实际应是 Signal Server

• 信令服务器收到本地浏览器的 SDP 请求，它就会将其转发到远程浏览器
• 然后远程浏览器生成其 SDP 应答并通过信令服务器将其发送回本地浏览器
• 您可以使用各种技术来实现信令服务器，例如 WebSockets、HTTP 或任何其他合适的通信协议

ICE Candidate

• Candidate 是 WebRTC 用来描述它可以连接的远端的基本信息， Candidate 是至少包括 IP 地址、端口号、协议的一个信息集。

ICE Candidate 有几种？

• 主机候选者：网卡自己的 IP 地址及端口。通过设备网卡获取，优先级最高。
  • 在 WebRTC 底层首先会尝试本地局域网内建立连接。
• 反射候选者：经过 NAT 之后的外网 IP 地址和端口，由 ICE（STUN）服务器获取
  • 其优先级低于主机候选者，当 WebRTC 尝试本地连接不通时，会尝试通过反射候选者获得的 IP 地址和端口进行连接。
• 中继候选者：表示的是中继(TURN)服务器的转发 IP 地址与端口，由 ICE 中继服务器提供。
  • 优先级最低，前两个都不行则会按该种方式。

---

HLS协议详解

• HLS协议的文件由两部分组成
  • 多个只有几秒长度的.ts碎片视频文件
  • 记录这些视频文件地址的.m3u8索引文件
  • 这些静态文件都是直接写入磁盘的

直播的场景下

• 转码软件可以直接生成HLS相关文件到磁盘，客户端通过HTTP服务下载文件即可

直播场景下HLS不同

• 在直播的场景下，客户端需要不断定时重新获取.m3u8索引文件
  • 每几秒打包成一个以.ts为后缀的碎片视频文件都会同步更新.m3u8索引文件
  • 碎片视频文件的个数是有上限的 ,默认会将最旧的视频文件删除且更新.m3u8索引文件

HLS劣势

• 直播延迟很大，大概在5-30秒左右
• 长时间且多个直播流同时处理，会造成磁盘写入压力过大，机械磁盘，固态硬盘的寿命会加速衰减

HLS优势

• 直播转点播，点播转直播的场景， 理论上只需要修改索引文件就可以
• HLS协议的.m3u8索引文件支持二级索引，高清、标清、流畅等多个观看地址可以整合到一个索引文件。播放器可以根据当前带宽自动切换不同的观看地址

---

文档链接说明

• 参考文档
  [【音视频处理】RTMP、HLS、HTTP-FLV、WebRTC、RTSP的区别？直播协议详解_rtsp hls-CSDN博客

• 参考文档
  WebRTC 入门：带有示例代码的实用指南-CSDN博客
  一文详解 WebRTC 基础 - 个人文章 - SegmentFault 思否

• 参考文档
  进击的WebRTC：我们为什么需要它？_语言 & 开发_毛玉杰_InfoQ精选文章

• 参考文档
  HLS直播取流协议及实现原理详解_hls直播流-CSDN博客

• 参考文档
  Docker | SRS

• 参考文档
  ubuntu22.10 ffmpeg-webrtc推拉流srs环境搭建_ffmpeg能推webrtc吗-CSDN博客

• 参考文档
  NAT的四种分类：全锥形NAT,地址受限锥形NAT,端口受限锥形NAT,对称NAT-CSDN博客