直播
成熟的直播业务，诸如抖音、快手、斗鱼，多采用自研推流端或者OBS，由于公司人才匮乏和与业务融合的需求，所以使用web端推流的方式。
webRTC
WebRTC，名称源自网页即时通信（英语：Web Real-Time Communication）的缩写，是一个支持网页浏览器进行实时语音对话或视频对话的API。它于2011年6月1日开源并在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准。
在我看来，低延迟是webRTC最大的优点，相对来说，图像质量不会太高。当然对于现在的我来说，是最好入门的，只需要通过一系列简单的API就可以实现点对点通信。
通信和直播
通信和直播是两个不同的场景。
用webRTC实现可用的通信应用，是非常简单的。一般情况下，你只需要一个webRTC信令服务器（本质上就是握手服务器）。信令服务器的作用就是转发各个端的媒体流。
对于小公司来说，想要开发信令服务器并且部署节点，是不太现实的，建议使用云服务商，比如阿里云或者声网。
想要用webRTC做到更多，比如录音，你就还需要一个多媒体服务器。毕竟两种资源不是一个协议和规范，你需要这个媒体服务器来处理（编解码、封装等处理）。
而基于webRTC的直播，正是基于媒体服务器。让独立的媒体服务器处理成各种协议（RTMB，FLV，m3u8等）的播流，再分发给用户。
使用阿里云服务
阿里云webRTC可以实现直播。
手绘流程图：
推流
推流的实现是采用webRTC采集本地媒体流，推给阿里云webRTC服务，经由旁路转推服务（媒体处理），推给直播服务。
播流
播流正常使用阿里云的直播服务。
保存
保存、回放功能采用阿里云视频点播服务的剪辑和转码存储功能。
延迟
延迟问题，是直播中最敏感的存在。如果按照上述架构，直播延迟将达到20s以上（怀疑是阿里云故意的，哈哈哈）。测试倒是可以容忍，但是在生产上是不行的。
阿里云提供了低延迟服务，播流采用artc协议。使用之后，延迟会降到3s左右。
弊端
媒体处理能力
最大的弊端就是推流端使用webRTC，媒体处理能力基本没有。
比如，摄像头和屏幕分享组合，屏幕分享时分享指定区域。这在webRTC上，基本是不可能实现的！
OBS 虚拟摄像头
OBS，免费且开源的用于视频录制以及直播串流的软件。有着强大的本地多媒体处理能力。
最新版本的OBS已经将虚拟摄像头作为内置功能（之前是插件），使用此功能，可为电脑新增一个摄像头设备（驱动安装），并可以将OBS的舞台画面传输给该摄像头。开启后你看到电脑上多了一个摄像头：
通过该方式，可以充分调用OBS的能力。
obs-studio-node
OBS有node的库obs-studio-node，再结合一些跨平台技术，开发一个推流客户端。比如成熟的 Streamlabs OBS，基于electron + vue + obs-studio-node 开发的一个推流客户端。
