是什么？
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 的好处主要有以下几个方面：
- 免费的使用 GIPS 先进的音视频引擎，在此之前都需要付费授权。
- 由于音视频传输是基于点对点传输的，所以实现简单的 1 对 1 通话场景，需要较少的服务器资源，借助免费的 STUN/TURN 服务器可以大大节约成本开销。
- 开发 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
SHELL
docker run --rm -it -p 1935:1935 -p 1985:1985 -p 8080:8080 registry.cn-hangzhou.aliyuncs.com/ossrs/srs:5
SHELL
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
- RTMP (by VLC):
SRS支持WebRTC，可以做会议或视频聊天
SHELL
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
SHELL
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
SHELL
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
- WebRTC:
使用 ffmpeg-webrtc
shell
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
c
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才能推拉流
shell
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索引文件支持二级索引，高清、标清、流畅等多个观看地址可以整合到一个索引文件。播放器可以根据当前带宽自动切换不同的观看地址