酷应用

何李石：七牛直播云服务技术详解

技术作者：七牛云 2016-07-11 06:51:14

导读：

通用的直播模型是什么样子？七牛直播云是怎么实现的？SDK 的功能怎样？性能表现如何？在 6.30 七牛直播云发布会上，七牛云首席布道师何李石对七牛直播云服务的关键技术点进行了详细解读。

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

直播模型及其实现

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

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

其次是播放端，播放端功能有两个层面，第一个层面是关键性的需求；另一层面是业务层面的。先看第一个层面，它涉及到一些非常关键的指标，比如秒开，在很多场景当中都有这样的要求，然后是对于一些重要内容的版权保护。为了达到更好的效果，我们还需要配合服务端做智能解析，这在某些场景下也是关键性需求。再来看第二个层面也即业务层面的功能，对于一个社交直播产品来说，在播放端，观众希望能够实时的看到主播端推过来的视频流，并且和主播以及其他观众产生一定的互动，因此它可能包含一些像点赞、聊天和弹幕这样的功能，以及礼物这样更高级的道具。我们知道，内容产生方和消费方一般都不是一一对应的。对于一个直播产品来讲，最直观的体现就是一个主播可能会有很多粉丝。因此，我们不能直接让主播端和所有播放端进行点对点通信，这在技术上是做不到或者很有难度。主播方播出的视频到达播放端之前，需要经过一系列的中间环节，也就是我们这里讲的直播服务器端。直播服务器端提供的最核心功能是收集主播端的视频推流，并将其放大后推送给所有观众端。除了这个核心功能，还有很多运营级别的诉求，比如鉴权认证，视频连线和实时转码，自动鉴黄，多屏合一，以及云端录制存储等功能。另外，对于一个主播端推出的视频流，中间需要经过一些环节才能到达播放端，因此对中间环节的质量进行监控，以及根据这些监控来进行智能调度，也是非常重要的诉求。实际上无论是主播端还是播放端，他们的诉求都不会仅仅是拍摄视频和播放视频这么简单。在这个核心诉求被满足之后，还有很多关键诉求需要被满足。比如，对于一个消费级的直播产品来说，除了这三大模块之外，还需要实现一个业务服务端来进行推流和播放控制，以及所有用户状态的维持。如此，就构成了一个消费级可用的直播产品。但是正如刚才所说的直播通用模型一样，实际上这里很多功能都可以抽象成一个通用功能，也就是说各家直播产品的需求和实现方式都类似。我们再来看，如果把这些抽象出来的需求交给七牛这样的第三方去实现，会有多大的差异。

七牛直播云解决方案

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

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

在直播服务器端，几乎所有的工作都集中于如何更好的处理、分发视频流，比如出于审核的目的对视频进行自动鉴黄，为了更好的适配客户端的网络需要对视频进行实时转码。我们发现，对于这三个模块，几乎所有直播产品的诉求都是类似的。因此七牛提供了一个这样覆盖主播端到播放端的直播云解决方案，它包括推流端 SDK 和播放端 SDK，以及一个强大的直播网络，它既能满足推流端和播放端在拍摄和播放方面的体验诉求，也能够通过定制化的方式来满足在产品运营方面的诉求，比如给播放器加上弹幕和点赞等功能。七牛直播云平台主要包含直播云 API、推流端 SDK 和播放端 SDK 等三大模块。接下来重点介绍七牛在推流端和播放端 SDK 方面的功能特性，以及它们在性能方面的表现。

SDK 功能特性

1）SDK 处理流程

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

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

1. 数据采集源的开放性。我们提供了一个开放式的采集接口来进行视频内容的采集，目前主要的采集源有手机屏幕采集和摄像头采集。

2. 可插拔的数据处理模块。对于视频内容的处理，目前我们提供了美颜、水印和基本的滤镜功能，但它其实也提供了一个开放式的处理接口。

除了开放性，七牛也支持了 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 库上的关注度就可以看出。