今天看到这个项目的时候还是挺兴奋的,一直以来都想尝试基于分布式哈希表的支持大量peer的直播流。不过随着了解深入,发现它只是简单的将本地视频录下来之后使用WebTorrent下载传输下去。作者解释是由于WebTorrent本身的限制,理论上是应该直接使用流的方式实现的。
这里我们不讨论直接使用流的方式,只涉及nile.js中p2p视频直播的原理。
简介
大家知道WebRTC所建立的p2p网络是十分原始的,假设我(x)要连接接到网络中的另外三个节点abc,那我就要分别与他们都建立连接(x, a), (x, b), (x, c)。
然后我要直播给他们看的时候,我就要给这三个连接都发送视频流,假设我的视频流折算成网速是100k/s,那么我跟他们仨传,流出流量就是300k/s。人越多我流出的流量就更多,这当然是不可扩展的。而且WebRTC的连接还不一定连得上。
然而p2p网络发展到现在早已不是你链接我这种原始的方式了,基于中心节点的、去中心化的、基于分布式哈希表等的p2p网络方案,现在都有了广泛的应用(不然各种下载神器、种子哪来的)。
nile.js
就主要通过WebTorrent
使用一种类似于BT种子下载的方式实现了实时视频直播的方案。
原理
主要分三部分:
- Broadcaster (WebTorrent)
- Viewer (WebRTC & WebTorrent)
- Server (Socket.io)
首先讲一下这里涉及到的两个工具WebTorrent
和Socket.io
的作用。
WebTorrent
在这里主要的作用有两个:
- 把文件做种成磁力链接(可以看成下载视频的种子文件,大家懂的)
- 通过磁力链接获取到文件(这里的下载过程对用户来说是透明的,就是去中心化的纯分布式的下载,类似BT种子)。
而建立WebRTC
的PeerConnection
需要交换信息,因此要搭建信令服务器,这里Socket.io
的主要作用就是这个,不过它还起到下发磁力链接的作用。
然后讲一下工作原理:
- Broadcaster也就是直播者,将直播视频流录制成7秒时间间隔的短视频片段。
- 将短视频片段通过
WebTorrent
制作成磁力链接,共享到p2p网络中 - Viewer也就是观众,得到这些短视频片段的磁力链接之后通过
WebTorrent
构成的p2p网络下载这些片段,并且按照顺序进行播放。
是不是很简单,它主要依靠了WebTorrent
的强大能力来保证视频文件传输的正确性和速度,而且理论上可以支持无限多的观众来观看直播的,并且不消耗额外的服务器资源。
然而上面似乎都没有用到WebRTC,WebRTC在这里起到了什么作用?
有一点比较明显的作用是获取视频流,然后通过MediaRecorder
录制成视频文件的buffer
或者blob
。
附加优化
WebRTC在这里还有一个用处就是使用DataChannel分发磁力地址,减小服务器负担。这块的负担并不是指视频,二是指长连接Socket.io
连接数。
刚刚说到Broadcaster把录制好的视频片段生成一个磁力链接之后,Viewer都会得到这个磁力链接,我们默认得到方式是通过Server中的Socket.io
来分发,这样的话所有的Viewer就都会链接到这个长连接服务器,那这块就又不是Scalable的了。
所以nile.js
聪明的地方在于:
只有有限的节点会通过
socket.io
获得磁力链接,其他的节点的磁力链接都是通过这些根节点通过DataChannel
的p2p的方式得到的。
问题与不足
- 因为有录制发送下载的过程,因此延迟较高。Demo里大概有10秒以上。
- 项目很多坑,可用性较差。
更进一步
- 可以去了解一下WebTorrent
- 原理很简单,而且可以扩展到任意平台,手机app理论上也可以
- 直接使用流