一个人孤军奋战：打造一个开源直播平台（累计300+⭐️）的艰辛历程

生态

以上数据统计截止至2023年9月11号

缘起

自从去年年底（2022年十月底）入职了新公司（也就是现在这家）后，我接触的业务里使用到了 WebRTC，确切的说是代码里面有 WebRTC 的相关代码。

但是因为业务缠身，一开始我并没有注意它，只知道它是用来做即时通讯的，偶尔遇到了一些问题（比如兼容性问题，需要引入webrtc-adapter），才会去网上找怎么解决，并没有多少时间系统的了解 WebRTC。直到今年年初的时候，各方面都基本稳定了，于是乎便开始还旧债。

我有个习惯：在每一家公司上班，都会尽量将公司里接触到的有意思的东西，自己实现一遍，转化成自己的。

初探WebRTC

不了解不知道，了解后感觉发现了新世界。webrtc主要是做p2p相关的，简单的有在线会议，文件传输等；高级点的可以做pcdn等。此时我脑子里第一个就想到的就是直播，这和我以往接触的业务都不一样（以前接触的都是普通的toc业务和一些前端工程化的业务），我对直播业务有种莫名的兴趣。至此，命运的齿轮开始转动。

项目启动

有了想法后，第一时间当然是新建仓库啦，其次的话还得有一个响应的名字，按照我个人以往的命名方式（以billd开头，billd是彼尔德的英文名，它是我很喜欢的表情包哈哈哈），这个项目毫无悬念当然就叫 billd-live 了，于是乎，billd-live 的第一次提交定格在了2023年3月20号。

项目经历

回顾 billd-live 的过去，可以简单的分为以下四个阶段：

webrtc阶段（痛苦面具）
SRS阶段（痛苦面具）
前端混流阶段（调试b站直播间）

3.1 雏形（多个音视频轨）

3.2 完善（Canvas混流）

3.3 扩展（Web Audio混流、Web Worker优化推流）
直播后台

billd-live 的开发都是在业余时间进行。

webrtc阶段

在一开始的时候，我的目标就是搭建一个直播间，于是打开b站搜webrtc直播，好家伙，搜到的全是c++的，没办法，只能自己慢慢摸索。在前前后后经历了差不多一个多月后，billd-live 的第一个版本终于成型：

首页：

开直播：

看直播：

其实可以看到当时的版本非常的朴素哈哈哈

SRS阶段

在有了webrtc的直播功能后，确切的说其实是在线会议功能，因为webrtc的局限性，比如在多对多情况下直播时（mesh模型），对客户端的上行带宽压力大，还有就是p2p对网络的稳定性要求高（属于是看天吃饭）等问题，因此一般直播也不会用webrtc来做，通常都会使用流媒体服务器，通过流媒体服务器来接收和转发直播流。

在了解了一些流媒体服务器相关的开源项目后，从node-media-server、SRS 、ZLMediaKit 中选择了 SRS 作为billd-live的流媒体服务器，原因很简单，SRS的官网文档看起来对新人比较友好，相对好上手（就和他的名字一样Simple Realtime Server）。但后面发现，其实 ZLMediaKit 也非常不错~

首页：

开直播：

看直播：

前端混流阶段

在引入了SRS后，基本可以实现简单的直播需求了，但是当前只能获取屏幕或者摄像头二者中的一个，如果我希望获取多个的话是做不到的，因此就有了前端混流的需求。

雏形

在一开始的时候，我主要是在webrtc开播的时候支持混流，因为webrtc直播的时候，添加track会触发对应的track回调，从而进行重新协商等一系列操作，从而实现混流（确切的说其实是多个track）

首页：

看直播（左）、开直播（右）：

此时的页面UI有了很明显的改善

完善

然而，在srs开播的时候，它是不能像webrtc那样重新重新协商的，因为srs正在推流的时候，如果你的track变了，就得重新断开当前推流再继续推流，那么意味着不管看直播还是开直播，添加了新的track都会导致断开当前直播然后开启一个新的直播，很明显这是不合常理的。在经历了一段时间的摸索后，最终决定使用canvas混流视频轨。

首页：