协议-WebRTC-HLS

是什么？

WebRTC（Web Real-Time Communication）

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

![[Pasted image 20250207215319.png]]

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等主流协议

![[Pasted image 20250208005311.png]]

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服务器作为流媒体服务

![[Pasted image 20250208085518.png]]

ICE（Interactive Connectivity Establishment）

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

为什么需要ICE协议

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

NAT（Network Address Translation）

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

![[Pasted image 20250208121822.png]]

STUN（Session Traversal Utilities for NAT）

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

![[Pasted image 20250208101620.png]]

为什么需要TRUN协议

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

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

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

![[Pasted image 20250208124214.png]]

TURN (Traversal Using Relays around NAT)

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

![[Pasted image 20250208110559.png]]

SDP（Session Description Protocol)

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

![[Pasted image 20250208130018.png]]

具体通讯流程

![[Pasted image 20250208112337.png]]

信令服务器 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 中继服务器提供。
- 优先级最低，前两个都不行则会按该种方式。