七牛直播云服务技术揭秘-阿里云开发者社区

以下根据七牛云首席布道师何李石现场演讲内容整理。

直播模型及其实现

一个通用的直播模型一般包括三个模块：主播方、服务器端和播放端。

首先是主播方，它是产生视频流的源头，由一系列流程组成：

第一，通过一定的设备来采集数据；
第二，将采集的这些视频进行一系列的处理，比如水印、美颜和特效滤镜等处理；
第三，将处理后的结果视频编码压缩成可观看可传输的视频流；
第四，分发推流，即将压缩后的视频流通过网络通道传输出去。

其次是播放端，播放端功能有两个层面，第一个层面是关键性的需求；另一层面是业务层面的。

先看第一个层面，它涉及到一些非常关键的指标，比如秒开，在很多场景当中都有这样的要求，然后是对于一些重要内容的版权保护。为了达到更好的效果，我们还需要配合服务端做智能解析，这在某些场景下也是关键性需求。再来看第二个层面也即业务层面的功能，对于一个社交直播产品来说，在播放端，观众希望能够实时的看到主播端推过来的视频流，并且和主播以及其他观众产生一定的互动，因此它可能包含一些像点赞、聊天和弹幕这样的功能，以及礼物这样更高级的道具。

我们知道，内容产生方和消费方一般都不是一一对应的。对于一个直播产品来讲，最直观的体现就是一个主播可能会有很多粉丝。因此，我们不能直接让主播端和所有播放端进行点对点通信，这在技术上是做不到或者很有难度。主播方播出的视频到达播放端之前，需要经过一系列的中间环节，也就是我们这里讲的直播服务器端。

直播服务器端提供的最核心功能是收集主播端的视频推流，并将其放大后推送给所有观众端。除了这个核心功能，还有很多运营级别的诉求，比如鉴权认证，视频连线和实时转码，自动鉴黄，多屏合一，以及云端录制存储等功能。另外，对于一个主播端推出的视频流，中间需要经过一些环节才能到达播放端，因此对中间环节的质量进行监控，以及根据这些监控来进行智能调度，也是非常重要的诉求。

实际上无论是主播端还是播放端，他们的诉求都不会仅仅是拍摄视频和播放视频这么简单。在这个核心诉求被满足之后，还有很多关键诉求需要被满足。比如，对于一个消费级的直播产品来说，除了这三大模块之外，还需要实现一个业务服务端来进行推流和播放控制，以及所有用户状态的维持。如此，就构成了一个消费级可用的直播产品。

但是正如刚才所说的直播通用模型一样，实际上这里很多功能都可以抽象成一个通用功能，也就是说各家直播产品的需求和实现方式都类似。我们再来看，如果把这些抽象出来的需求交给七牛这样的第三方去实现，会有多大的差异。

七牛直播云解决方案

首先，对于推流端的功能，我们可以用一个 SDK 去覆盖所有功能点，包括采集、处理、编码和推流等工作，若有一些功能无法通过官方提供的 SDK 来满足，可以通过自定义扩展的形式来实现。

其次，对于播放端，我们可以将其功能分类，和视频播放相关的功能可以通过一个播放器 SDK 去实现。而其它功能如实时聊天，可以直接使用其它第三方服务。

在直播服务器端，几乎所有的工作都集中于如何更好的处理、分发视频流，比如出于审核的目的对视频进行自动鉴黄，为了更好的适配客户端的网络需要对视频进行实时转码。

我们发现，对于这三个模块，几乎所有直播产品的诉求都是类似的。因此七牛提供了一个这样覆盖主播端到播放端的直播云解决方案，它包括推流端 SDK 和播放端 SDK，以及一个强大的直播网络，它既能满足推流端和播放端在拍摄和播放方面的体验诉求，也能够通过定制化的方式来满足在产品运营方面的诉求，比如给播放器加上弹幕和点赞等功能。

七牛直播云平台主要包含直播云 API、推流端 SDK 和播放端 SDK 等三大模块。接下来重点介绍七牛在推流端和播放端 SDK 方面的功能特性，以及它们在性能方面的表现。

SDK 功能特性

1）SDK 处理流程

如果把一个完整的直播流程用一个流水线来表达，它应该是这样子的，如下图所示。

七牛 SDK 的开放性表现为两点：

数据采集源的开放性。我们提供了一个开放式的采集接口来进行视频内容的采集，目前主要的采集源有手机屏幕采集和摄像头采集。
可插拔的数据处理模块。对于视频内容的处理，目前我们提供了美颜、水印和基本的滤镜功能，但它其实也提供了一个开放式的处理接口。

除了开放性，七牛也支持了 H.264 和 H.265 等多种编码标准。H.265 是一种更为高效的编码标准，能够在同等画质效果下将内容的体积压缩得更小，传输时更快更省带宽。

视频流编码完成后，则进入另一个常规的流程，进行推流、分发和播放。这样，我们就完成了一个完整的直播流程，它包含采集、处理、编码、推流、分发和播放等子流程。其中每一个子流程都是可插拔可替换的，而所有流程的子模块也都具有灵活开放的输入输出接口，子模块可以被任意的扩展或者替换。

2）SDK 功能点对比

直播流程里面的模块化处理方式中，每个子流程都包含一系列开放可扩展的子模块，这些子模块对应多组不同的功能，以满足各阶段的需求。我们汇总了一些当前主播、观众以及 App 实现者最关注的功能，大概有 36 种。从这张图可以看出，目前七牛的推流端和直播端 SDK 中实现了多达 32 种功能。

3）SDK 包大小对比

但是，对于七牛直播服务来说，要做到这么开放，又具备这么多功能点，需要一个多大的 SDK 呢？我们统计了一下，iOS 端的推流和播放 SDK 加起来，大概需要 5MB 左右，而业界的平均值则是 11MB。Android 端由于需要适配的硬件设备和软件系统太多，SDK 的大小大概在 18MB 左右，业界的均值则在 42MB。

SDK 性能对比

我们提供了一个开放的 SDK 处理流程，在这个流程中每个环节都提供了非常丰富的关键功能，能够满足大部分场景下的需求，同时又保证了包含所有这些功能特性的 SDK 不会太大。那么，它在性能方面的表现如何呢？

1）资源占比

除了程序 Bug 导致的主动崩溃之外，一个 App 的稳定性主要由两方面影响：内存和 CPU，因此第三方 SDK 在这两方面的表现将直接影响 App 的稳定性。而对于一个视频推流和播放 App 来说，CPU 是其最重要的资源之一。

我们先来看一下七牛 SDK 在 CPU 占比方面的情况。上下两张图分别是推流和播放 SDK 在经过多次反复测试后得出的 CPU 占比均值曲线图。从图中可以看出，无论是推流端还是播放端，七牛 SDK 在 CPU 使用率方面都占比最少。

我们再来看一下内存占比，上下两图也分别给出了推流和播放 SDK 在多次反复测试后得出的内存占比均值曲线图，从图中可以看出，我们 SDK 在推流和播放的时候内存使用情况表现非常平稳，而内存的使用量也在业界均值之下，接近于最好的值。这个数据之所以没有达到最好值，是因为我们经过反复测试发现频繁的对内存进行回收（Android）会导致编码的不稳定，实际上这个指标确实可以优化到最好，只不过可能会导致内存和 CPU 波动较大，进而影响整个过程的编码效率。对于这样的权衡，我们大多数客户也非常认可，这也是他们选择我们的 SDK 原因之一，这点从我们 Github 库上的关注度就可以看出。