实时视频服务架构探索

直播场景

主播端：它是产生视频流的源头，由一系列流程组成：第一，通过一定的设备来采集数据；第二，将采集的这些视频进行一系列的处理，比如水印、美颜和特效滤镜等处理；第三，将处理后的结果视频编码压缩成可观看可传输的视频流；第四，分发推流，即将压缩后的视频流通过网络通道传输出去。
观众端：观众需求功能可以分成两个层面，第一个层面是关键性的需求，另一层面是业务层面的。先看第一个层面，它涉及到一些非常关键的指标，比如秒开、延迟，在很多场景当中都有这样的要求，然后是对于一些内容的进行审核。为了达到更好的效果，我们还需要配合服务端做智能解析，这在某些场景下也是关键性需求。第二个层面也即业务层面的功能，主播以及其他观众产生一定的互动，因此它可能包含一些像点赞、聊天和弹幕这样的功能，以及礼物这样更高级的道具。
直播服务器端：提供的最核心功能是收集主播端的视频推流，并将其放大后推送给所有观众端。除了这个核心功能，还有很多运营级别的诉求，比如鉴权认证，视频连线和实时转码，自动鉴黄，多屏合一，以及云端录制存储等功能。

基本概念

视频直播使用过程中遇到的常用名词的基本概念和简要描述。

推流

推流是把采集阶段封装好的音视频直播流推送到音视频服务中心的过程。

拉流

即直播播放，用指定地址将实时视频服务的视频源和音频源拉取播放的过程。

转码

直播转码是将视频码流转换成另一个视频码流功能。通过转码，可以改变原始码流的编码格式、分辨率和码率等参数，从而适应不同终端和网络环境的播放。使用转码功能可以实现：

适配更多终端：将原始视频转码成拥有更强终端适配能力的格式，使视频资源能够在更多设备上播放。
适配不同带宽：将视频转换成流畅、标清、高清或超清输出，用户可根据当前网络环境选择合适码率的视频播放。
节省带宽：采用更先进的编码方式转码，在不损失原始画质的情况下显著降低码率，节省播放带宽。

直播地址

直播地址包含推流地址和播放地址，由域名、AppName、StreamName和鉴权串（可选）组成，每个域名下可以创建多个应用，每个应用下可以创建多个直播流。控制台提供地址生成器功能，支持快速生成推流地址和播放地址，可用于第三方软件（如OBS）推流。

StreamName

StreamName表示直播流名称，是一路流的标识符，通常与某个域名一起唯一标识一路流。

Edge

所谓边缘edge服务器，就是边缘直播缓存服务器，配置时指定为remote模式和origin（指定一个或多个源站IP），这个边缘edge服务器就是源站的缓存了。详情了解

VHOST

详情了解

Forward

直播服务器，其中一项重要的功能是forward，即将服务器的流转发到其他服务器。详情了解

Backup

Backup是热备的意思。主要实现是主集群和子集群通过互相forward，实现故障热备的功能，构建强容错系统。

实时视频服务开源选型

开源音视频服务器的介绍：

序列	项目名称	star	介绍
1	nginx-module	\	nginx-module是nginx下的多个子模块，该模块主要作用是可以建一个直播服务器。nginx-rtmp/nginx-flv/nginx-ts
2	SRS	19.7k	SRS是一个简单高效的实时视频服务器，支持RTMP/WebRTC/HLS/HTTP-FLV/SRT/GB28181。
3	livego	8.4k	纯 Golang 编写，性能高，跨平台,简单高效的直播服务器。
4	lal	1.7k	lalserver是纯Golang开发的流媒体（直播音视频网络传输）服务器。目前已支持RTMP, RTSP(RTP/RTCP), HLS, HTTP[S]/WebSocket[S]-FLV/TS, GB28181协议。并支持通过插件形式进行二次开发扩展。
5	janus-gateway	6.8k	Janus WebRTC Server. 做会议(WebRTC)的服务器。

开源音视频服务器的对比：

选型时主要考虑如下几个方面，对不同的开源框架的优劣势进行对比分析，得出选型结论。

功能满足度

分析业务应用的各种场景，各种业务场景的满足度如何。
性能满足度如何。

协议对比：

\	nginx-module	SRS	livego	lal	janus-gateway
RTMP	√	√	√	√	x
HTTP-FLV	√	√	√	√	x
HLS	√	√	√	√	x
DASH	√	√	x	x	x
WebRTC	x	√	x	x	√

结论：
nginx-module虽然支持大多数协议，但是每个协议都是不同的项目，运维成本较高。
SRS支持协议是最全的，所有都是同一个项目，运维成本相对低一些。
livego和lal支持些常规协议。
janus-gateway只支持WebRTC，所以此项目一般用于视频会议、视频通话场景。

功能对比：

\	nginx-module	SRS	livego	lal	janus-gateway
GUI	x	√	x	x	\
DVR	√	√	√	√	\
Transcode	x	√	x	x	\
HTTP API	√	√	√	√	\
HTTP hooks	x	√	x	√	\
GopCache	x	√	√	√	\
Security	√	√	√	√	\

janus-gateway因缺少我们要用的协议，优先排除我们的选择范围内

性能测试：
SRS：https://ossrs.net/lts/zh-cn/docs/v4/doc/performance
LAL：https://pengrl.com/lal/#/Test

实测与文档相差无几。

学习成本分析

API参考、开发指南等资料文档是否齐全。
开源社区活跃度如何。

文档资料对比：

\	nginx-module	SRS	livego	lal	janus-gateway
Docs	√	√	x	√	\
Demos	x	√	x	√	\

活跃程度:
不更新的项目就是坑了，没有哪个开源项目拿来就能用的，一般开源项目都是会遇到问题的，有人在更新维护就很重要。

曾经直播大火时知名的开源服务器，目前Star也挺可观的。虽然项目已经停止更新很多年，但是Star还是在平稳增长，所以这是做开源不能过分在乎Star的原因，躺平也能涨Star。
https://github.com/arut/nginx-rtmp-module/issues/605

SRS的Star是音视频服务器中最多的，但是它的更新不稳定，活跃度断断续续的。最近2年活跃度还不错，如何持续10年是至关重要，也是非常大的挑战。

livego很明显已经走在停滞的边缘，文档指南资料也是少的可怜。

lal是近几年出现的开源服务器，一直都有在积极的维护开发，文档资料也比较的齐全。

维护成本

是否支持分布式以便进行伸缩。
日志是否丰富，是否有性能统计日志等方便在网维护。

集群对比：

\	nginx-module	SRS	livego	lal	janus-gateway
Edge	x	√	x	x	\
Backup	x	√	x	√	\
VHOST	x	√	x	√	\
Forward	x	√	x	√	\
Docker	x	√	√	√	\

日志：
目前只有SRS有相关详细文档描述,其余都没找到文档描述。

总体结论

nginx-module：协议和功能可以支撑业务需求，博客里文档资料齐全，但是作者已经停止了维护，暂不考虑。
SRS：协议和功能是可以完全支撑业务需求，文档和demo比较多，项目维护、社区交流比较活跃，支持边缘及原站集群化部署。
livego:协议和功能可以支撑业务需求，缺少文档指南资料，项目活跃度也已经处于停滞的边缘，暂不考虑。
lal：协议和功能可以支撑业务需求，文档资料也比较的齐全，项目维护、社区交流比较活跃，集群化部署需要自己实现。
janus-gateway：因缺少我们要用的协议，优先排除我们的选择范围内。

参考

自搭与云厂商服务的选择

主要从功能满足度、费用成本优劣势进行对比分析，得出结论。

功能对比

主要对比自搭与云厂商服务能否满足现有业务需求，实现方案是什么。

以阿里云为例：

\	阿里云	自搭(SRS)	备注
推流协议（RTMP）	√	√	基本要求
拉流协议（RTMP、HTTP-FLV、HLS）	√	√	基本要求
防盗链	√	√	基本要求
API流管理	√	√	基本要求
API回调	√	√	基本要求
直播录制	√	√	云厂商收费；自搭需要磁盘费用，建议直接Forward到云厂商就行
直播截图	√	√	云厂商收费；自搭有截图http hooks
直播时移	√	-	云厂商收费；自搭可通过直播录像自己实现
直播轮播	√	-	云厂商导播台收费；自搭可通过直播录像自己实现
直播水印	√	√	云厂商收费；自搭自带内置ffmpge实现

费用成本对比

先获取历史用量数据，以历史数据计算出自搭和上云的费用进行对比。

历史用量数据

带宽

2022-07-01 ~ 2022-07-31

2022-08-01 ~ 2022-08-31

2022-09-01 ~ 2022-09-30

2022-10-01 ~ 2022-10-31

==从历史数据可以看得出平时直播的下行带宽浮动基本在 300 ~ 800Mbps, 8月份是有麦当劳和金沙两个专场，所以带宽来到了 2.2Gbps。==

流量

2022-07-01 ~ 2022-07-31

2022-08-01 ~ 2022-08-31

2022-09-01 ~ 2022-09-30

2022-10-01 ~ 2022-10-31

==从历史数据可以看得出9、10月份没专场的情况下月流量基本在 4TB 上下, 7、8月份有专场的情况下月流量是来到了 8 ~ 10TB。==

计算云厂商费用

以阿里云为例，按官网价，不是按优惠，目前我们优惠价是官网的 65% 左右

带宽费用

流量费用(非低延迟价格)

大约算一下价格
7月份

带宽费用：31 天 x 2.860 元/天 = 88.66
流量费用：8.84 TB x 1024 x 0.58 元/GB = 5250.2528
总费用: 5338.9128 元

8月份

带宽费用：31 天 x 2.860 元/天 = 88.66
流量费用：8.66 TB x 1024 x 0.58 元/GB = 5143.3472
总费用: 5232.0072 元

9月份

带宽费用：30 天 x 2.860 元/天 = 85.8
流量费用：3.95 TB x 1024 x 0.58 元/GB = 2345.984
总费用: 2431.784 元

10月份

带宽费用：31 天 x 2.860 元/天 = 88.66
流量费用：3.78 TB x 1024 x 0.58 元/GB = 2245.0176
总费用: 2333.6776 元

计算自搭费用

按历史用量数据，以SRS集群方式部署，非专场情况下大概需要以下规格的Pod

序号	节点	CPU	内存	带宽	数量
1	源站	4 Core	4 Gb	10 Mbps	2
2	边缘	2 Core	2 Gb	100 Mbps	7~8

专场情况下可以把源站节点提高到3个，边缘节点数量可以按[巅峰带宽/100 Mb]进行伸缩。

示例：

场景：以麦当劳专场历史用量数据，2022-08-19 20:00 ~ 2022-08-20 00:00 的巅峰带宽为 2.2Gbps 。
结果：2.2 Gbps x 1024 / 100 Mbps ≈ 23 个边缘节点

大约算一下价格