PPIO 是为开发者打造的去中心化存储与分发平台,让数据更便宜、更高速、更隐私。官方网站是https://pp.io。
我的前面几篇文章讲解了部分 PPIO 的智能合约和证明机制,已经有一段时间没有讲解 PPIO的商业场景落地的实现了。所以,我这次专门讲解一下 PPIO 对直播的支持。
关于商业场景的讲解,前面写了《为何专注流媒体领域?PPIO技术揭秘》,在文中提到了文件下载和流媒体点播的支持,而直播和文件下载和点播场景不同,有些区别,但流媒体直播设计的整体框架是相似的,所以我们使用了一套代码来支持文件下载,点播,和直播。
首先,我们回顾一下 PPIO 的商业化层次架构,找到直播在 PPIO 商业化架构中的位置,更具体的信息见文章《PPIO的商业化架构解析》
图:PPIO 的商业化架构图
然后,我们回顾一下 PPIO 的 PCDN 整体架构,见文章 《为何专注流媒体领域?PPIO技术揭秘》
图:PPIO 的 PCDN逻辑示意图
直播的场景分为2种:
- 大规模直播:这类直播可能会有很多很多人观看,但是直播方和观众的互动不多。这类直播由于观看的人太多了,所以对互动没有太多要求。这类直播的场景很多,比如电视台直播,大型球赛直播,大型演唱会直播等。这类直播在乎的是规模,但对时延,同时性没有太多的要求。
- 互动低时延直播:这类直播对于观看人数的要求不多,但是对于直播的主播方和观众们的实时互动是有要求的,也就是主播方会随时关注观众的反馈,从而决定下一步直播的内容。例如,主播可能提出一个问题,让观众们回答;如果发现观众很久都没有反馈,那么这样的直播效果就会很差。所以这类直播,低时延和同时性是非常重要的。
如果你不是流媒体领域的人,可能对其中的几个词语不能很好地理解。我解释一下
- 时延:即主播方发生一个动作,观众会在一段时间之后看到这个动作,这段时间的时长就是时延。例如足球比赛,进球了,观众要30s之后,才能看到,这个时延就是30s。
- 同时性:即主播发生一个动作,观众们是同看看到,还是先后不同的时间看到,如果是同时看到的,那么就具有同时性,否则就不具有同时性。不要小看同时性,有同时性的节目能做很多高级的互动,例如抢答。
我们想过,技术上将这2种场景合二为一,用一套技术方案,解决这两种场景的问题,但是我们发现比较难,因为理论上有个问题,就是 P2P 传输的隐形树原理。
那么 P2P 传输的隐形树原理就是即使 P2P 传输设计成了网状模型,但是实际传输的时候,会自然形成层次清晰的类树状结构,所以称为隐形树。那么这颗隐形树是怎么形成的呢?微观的看每个数据分片,也就是 Piece,必然是一个从源分发出去的过程,由源先分发给第一层的 Peer;再由第一层的 Peer 分发给第二层的 Peer;再由第二层的 Peer 分发给第三层的 Peer; … …; 直到分发给所有的 Peer。而每个 Piece 来说,都要经历这个过程,只是,不同的 Piece,分发的路径不用。但是直播本身的 Buffer 持续向前,这就造成了每个 Peer 的 Buffer位置是不同的,有些节点的 Buffer 更靠近最新产生的 Piece,而靠近源节点(Source)的节点,其 Buffer 的位置越靠前;他们最先得到最新的数据,再分发给其他节点,这样渐渐地就分化出了一系列的 Peer,形成了他们距离源节点(Source)的远近。就形成了一个类树状的结构,但不是严格意义上的树,所以称为隐形树。
图:P2P 直播中自然形成的隐形树
其中,传输线路中密集的线路视为主干,但传输中不够密集的线路视为虚干。
理论上,大规模和低时延本身是矛盾的。所以我们最终用这两个不同的策略来实现这两种场景。这篇文章我优先给大家讲解 PPIO 网络对大规模流媒体视频直播的解释。
直播的分片方式
在《为何专注流媒体领域?PPIO技术揭秘》中对分片方式有了详细的介绍。数据分片是 P2P 传输技术的基础,对 P2P 系统来说,分片规则至关重要。
我们回顾一下,在分片这里的专业名词
我这里忽略文件下载点播的分片方案,直接说直播切片方案。
从切片角度来看,直播比起点播来说要复杂。因为直播既没有开始,也没有结束,每个用户开始观看直播的时候,下载的都是中间的数据。并且所有用户的数据要按照同样的分片规则来分片,这里不仅仅要分片,而且还要能够同步。除此之外,一般直播还有回放功能。
这里我重点阐述一下 PPIO 架构针对两种流媒体传输模式的分片的思考。
#1 HTTP 分段流直播
这里,我还是以 HLS 为例,DASH 等其他分段流类似。
HLS 的直播和 HLS 点播的切片方式一样,假设当前直播 m3u8 文件, 播放 TS1,TS2,TS3,TS4,TS5。按照基准时延的设置,直播会从某一个 TS 开始播放,比如说从 TS1 播放,时延最长,因此从 P2P 网络中拿到数据的机会就越多,从而 P2P 利用率就最高;但是如果从 TS5 播放,时延最短,因此从 P2P网络中拿到数据的机会就越少,从而 P2P 利用率就最低;如果从 TS3 播放,就是折中方案。
#2 HTTP 连续流直播
HTTP 连续流的直播,指的是一开始就没有结束的流,这里还是以 HTTP + FLV 为例。
一个 FLV 直播流所划分的 VS 不一定等长,VS 以关键帧为边界开始,以 一个时间单位为最小连续时间来进行切片。切片算法要保证每个 VS 里面的每个帧的数据都是完整的,并且必须包含一个关键帧。
假设当前直播播放 VS1,VS2,VS3,VS4,VS5,按照基准时延的设置,如果从 VS1 播放,时延最长,从 P2P 拿数据的机会就越多,P2P 利用率最高;如果从 VS5 播放,时延最短,从 P2P 拿数据的机会就越少,P2P 利用率最低;因此从 VS3 播放便是折中方案。另外切片时间单位也会影响时延,单位越小,时延越低,但是 P2P 利用率也越低。
PPIO 除了支持 HTTP 分段流和 HTTP 连续流以外,后面还计划逐步支持其他媒体格式和协议。
分片只是建立起了 P2SP 下载的秩序,直播系统还有很多的不同点。
直播频道与唯一标记
PPIO 的文件下载和点播,是以文件为资源唯一单位,因为只要文件确定,其 RID(唯一ID)就是能够计算出来的。但是,直播却不同,直播的数据是源源不断,没有结束,没有采用确定的办法来计算,只能用人为的方式将一个直播信号源标记为一个频道,然后将这个标记作为直播的唯一 ID,然后各个模块都约定并使用这个唯一 ID,才能正确地传输和获取数据。
Buffer 管理
直播的 Buffer 管理和文件下载和点播也是不同的,点播的 Buffer 是固定的,而直播的 Buffer 是一直持续向前的。
图:流媒体的 Buffer 管理示意图
设计 PPIO 的时候,我们根据视频播放位置,在流媒体下载的过程中,将其分为多个区间,越靠近播放位置的区间,下载优先级越高。这四个区间分别是:已过区间,紧急区间,正常下载区间和长远区间。关于这4个区间,想知道更多信息,可参见《为何专注于流媒体领域?PPIO 技术揭秘续篇》
直播的 Buffer 的同样有以上四个状态,只是不同的是
- 点播的已过区间的数据会长期保存,以便于上传给其他人;而直播的已过区间在一段时间之后就会删除,因为直播的历史数据一段时间之后就没有意义了,因为其他 Peer 也不会再请求了。
- 点播的长远区间可能会很长,很远;而直播基本上没有长远区间,因为新的数据在数据源(Source)还没有产生
- 点播的播放位置(play)最终会结束的;而直播的播放位置(play)是可能永远不会结束的。
直播的数据缓存,只需要缓存播放的数据,就可以了,正因为如此,直播的数据缓存不需要写入硬盘,只需要放在内存即可。而点播的缓存要放入设备的存储中。
图:直播中各个 Peer 的 Buffer 示意图
另外,直播在播放的时候,如果发现自己播放进度远远落后于其他 Peer 的时候,可以了考虑断开自己连接,执行 Relocate 重新定位,寻找到一个新的更适合的播放位置。
图:直播中远远落后的情况
发生 Relocate 之后,会跳过一些数据,但是播放器播放是能够跟上整体 P2P 网络的进度。
订阅协议
PPIO 网络在下载和点播的时候,我们设计的协议是 Request--Response 协议。实现的机制是,User 以自己为中心,自己想办法获得信息,并决策要请求的数据。User 非常清楚地知道自己的 Buffer,有哪些 Piece,没有哪些 Piece。User 向其它连上的 Peer 请求一个地图,其它 Peer 的 Buffe 的地图,这个地图标记他们有哪些 Piece,没有哪些 Piece,我们称这个地图为 Bitmap。有了这些的 Peer 的 Bitmap,就清楚地知道了每个 Peer 的资源情况。接来下User 就会根据预先设计的算法,去不同的 Peer 去请求不同的 Piece,Peer 们在收到数据请求之后就会返回数据。我们称这种方式为拉模式。
图:下载和点播的拉模式示意图
在直播中,我们调整了纯拉模式的策略,因为采用纯拉模式的实时性不够,都必须获得最新的 Bitmap,而在直播场景中,每个 Peer 的 Bitmap 变化都很快,每 秒 都可能有很大变化,前面说过,每个 Peer 的 Buffer 都是在往最新的 Piece 赶进度的。
于是,我们设计了一种新的方式,叫做订阅模式。对 User 来说,要对其连上的每个 Peer 进行评估,从资源度,下载速度等维度。一但确定其为优质 Peer,则向其发送订阅申请,那么之后,只要它收到新的数据,就会立即转发给 User。这个优质 Peer 在收到订阅申请的时候,可以同意或者拒绝,因为它自己也要评估自身的服务能力。当 User 后面发现不再需要订阅了,可以向 Peer 发出取消订阅即可。
图:直播的订阅模式的示意图
由于网络传输有不确定性,订阅模式不能保证所有 Piece 都能按时推送到位,所以实际的实现是订阅模式和拉模式结合的方式。当没有收到按时收到的 Piece 会通过拉模式获取,而如果这个 Piece 的位置是在 Buffer 管理的紧急区域,可能会发起多等冗余请求。
我们设计的订阅模式更多也是为了低时延互动直播,关于这个应用场景的详情,我会在后续的文章讲解。
一直以来,PPIO 的实践路线都是以商业落地为目的,希望用技术驱动商业进步,创造社会价值。流媒体一直以来都是 PPIO 极为重视的商业落地场景。今天我们着重分享了 PPIO 网络关于大规模流媒体视频直播设计和考虑,如何通过分片建立 P2SP 下载的秩序,如何进行 Buffer 管理。在协议模块,也分享了直播与下载和点播的不同,如何采用订阅模式和拉模式的结合,更好的支持大规模流媒体视频直播场景。
当然,在文中我们也提到,还有一类直播场景,低时延互动直播。在今后的文章中,会再给大家介绍 PPIO 在这个场景的设计和考虑,请大家敬请期待。如果您想更进一步的和我们一起学习探索,就快来关注 PPIO 公众号,加入 PPIO 开发者社区或 Discord 群组,和我们一起创造精彩。