PPIO 网络和大规模流媒体视频直播

​PPIO 是为开发者打造的去中心化存储与分发平台，让数据更便宜、更高速、更隐私。官方网站是https://pp.io。

我的前面几篇文章讲解了部分 PPIO 的智能合约和证明机制，已经有一段时间没有讲解 PPIO的商业场景落地的实现了。所以，我这次专门讲解一下 PPIO 对直播的支持。

关于商业场景的讲解，前面写了《为何专注流媒体领域？PPIO技术揭秘》，在文中提到了文件下载和流媒体点播的支持，而直播和文件下载和点播场景不同，有些区别，但流媒体直播设计的整体框架是相似的，所以我们使用了一套代码来支持文件下载，点播，和直播。

首先，我们回顾一下 PPIO 的商业化层次架构，找到直播在 PPIO 商业化架构中的位置，更具体的信息见文章《PPIO的商业化架构解析》

图：PPIO 的商业化架构图

然后，我们回顾一下 PPIO 的 PCDN 整体架构，见文章 《为何专注流媒体领域？PPIO技术揭秘》

 

图：PPIO 的 PCDN逻辑示意图

直播的场景分为2种：

1. 大规模直播：这类直播可能会有很多很多人观看，但是直播方和观众的互动不多。这类直播由于观看的人太多了，所以对互动没有太多要求。这类直播的场景很多，比如电视台直播，大型球赛直播，大型演唱会直播等。这类直播在乎的是规模，但对时延，同时性没有太多的要求。

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 群组，和我们一起创造精彩。

 

想了解更多有关 PPIO 的信息，可以移步官网：pp.io

如果你想更进一步了解项目，欢迎加入我们的微信讨论群，后台回复“PPIO讨论群” 获取入群二维码