短视频 SDK 架构设计实践

作者简介

孔维乐，七牛云客户端团队 Android 平台高级开发工程师，专注音视频，图形图像领域。OpenGL 专家，先后参与直播推流及连麦 SDK 的开发，主导短视频 SDK 的架构设计与实现， 对客户端架构设计及性能优化有丰富经验。

短视频发展史

image

图 1

图 1 所示是短视频及直播的发展史，众所周知，2016 年是直播元年，在这期间诞生了很多直播平台，比如熊猫、映客、斗鱼等；而在 2017 年，短视频的火爆程度并不亚于直播，可能大家都以为短视频是从 2017 年开始火爆起来的，但其实早在 2015 年就已经诞生出快手、秒拍、美拍等短视频 App。当时我正好在 YY 从事短视频 App 相关的工作，来到七牛后，在客户端团队先后参与直播、连麦 SDK 的开发，后面开始主研短视频 SDK，致力做最优秀最好用的短视频 SDK。

image

图 2

2016 年中国移动短视频用户数为 1.5 亿，今年预计会达到 2.4 亿，增长率高达 58.2%，可见短视频的热度在一直提升；近几年，短视频的生产模式在不断演进，从 UGC 到 PGC，再到最新的 MCN（Multi-Channel Network），内容的产能和质量均得到了巨大提升。

图 2 所示是短视频在各个行业的综合应用。

研发短视频 App 的难点

前面介绍完有关短视频的历史以及发展趋势，下面着重介绍一下关于短视频开发需要的预备知识及难点：

1、音视频领域固有门槛
深刻理解音视频编码格式 H.264 和 AAC 的编码细节；混音时如何将两个音频调整到一致的参数，使用什么样的算法去混合等等。

2、图形图像、OpenGL 处理
摄像头预览数据，图像处理，音视频编解码都需要了解 RGB 和 YUV 色彩空间的数据格式，以及它们之间转换的方式等等；其中部分操作可以利用更高效的 OpenGL 去完成，如美颜滤镜，图层混合，放大/缩小，旋转，还有图像裁剪等等。

3、平台相关
要对相应平台的摄像头、麦克风、编解码、多媒体处理等 API 十分熟悉，否则它们的一些坑会耗费你大量时间。

4、高级功能
视频编辑少不了特色和高级的功能，例如美颜，滤镜，MV 特效，倍数拍摄，文字特效等，每一个高级功能都对各方面技术提出很高的要求。

5、系统版本，机型等兼容性问题
这算是一个老生常谈的问题，无论 iOS 还是 Android，机型和系统版本都越来越多了，必然会带来兼容性问题。比如会有小部分 Android 机型编码的视频在 iOS 端播放不了的情况，类似这种兼容性问题都是需要进行解决的。

6、性能以及资源占用的优化
移动应用的计算资源受到相应系统的严格制约，在进行音视频采集，渲染，编码等复杂计算的同时，还要确保应用有足够的资源流畅运行，这要求开发人员有丰富的调优能力。

解决以上的难点是首要的事情，但开发时间也是研发人员必须考虑的问题，开发一款优秀的短视频 App，从熟悉音视频领域开始，到解决系统兼容性问题，紧接着去编写复杂业务逻辑，还有相应的UI界面这些工作需要耗费3-6个月的时间，是非常耗费时间和精力的。最开始我们团队进行短视频 SDK 开发时也踩过很多坑，用了将近一个月的时间才真正稳定下来，经过沉淀，现在我们针对一款 App 进行短视频 SDK 的对接，基本一周时间就可以完全搞定。

短视频 SDK 架构设计

接下来介绍一下我们团队在进行短视频 SDK 实践中主要做的一些事情，这其中最重要的就是短视频 SDK 的架构设计，包括架构设计理念、架构图、整体数据流程、模块架构设计等。

1、SDK 架构设计理念

image

图 3

说到 SDK 的设计理念必定要提到命名规范，就跟七牛的企业理念「简单.可信赖」一样，我们的命名规范是统一、简单并且精炼的，比如我们将对外的核心类统一以 PLShortVideo 为前缀，如图 3 所示分别是录制、编辑以及剪辑等模块的命名；参数配置类则均以 PLxxxSetting 为标准进行命名（图 4）；接口回调类则均以 PLxxxListener 为标准命名。

image

图 4

第二点我们遵循的是高模块化、模块可插拔的一个理念；高模块化必须要保证每个类每个方法都「名副其实」并「各司其职」，这样才能编写更清晰的逻辑；高模块化同时可以促进高复用，减少重复代码；图 5 所示是 SDK 内的转码核心类，因为编辑、剪辑在最后保存的时候都需要一个解码并重新编码的过程，在这里，转码核心类可以达到一个高复用。

image

图 5

image

图 6

图 6 所示为短视频 SDK 的包体划分，从表中我们可以清晰地看到每个包体的功能划分，不同的功能放在了不同的包体当中。我们并没有使用 ffmpeg 的软解软编，而是尽量使用 Android 和 iOS 的系统 API 进行硬编硬解，这样不仅减少了包体大小，而且速度要快很多，尽管在技术层面上会增加很多难度，会踩很多坑，但我们还是坚持选用这个方案。在引入第三方库时，我们也都是会经过充分配置和裁剪去严格控制包体的大小，这样一来，所有包体总和才能有现在「小而精」（1.5M）的成果。表中最后的内置滤镜模块，其中的滤镜资源可以选择性拷贝，SDK 内部会自动判断。这是关于模块设计方面的一些理念。

image

图 7

第三点是要和 UI 解耦，如图 7 所示，是从不同 App 中截图得到的画面，可以看出每一个App 都有各自的设计，作为一款短视频 SDK，是绝对不可以在 UI 方面限制客户发挥的。市面上有些短视频 SDK 将 UI 写死并作为 SDK 的一部分，这样对于客户在设计 UI 界面上来说，是非常不友好的；我们采用的是另一种方法，SDK 与 UI 进行解耦，客户的 UI 是可自定义的，整个 SDK 中接受 view 的地方只有一处：

PLShortVideoRecorder:prepare(GLSurfaceView preview, …)

接着是扩展性这一块，我们遵循高扩展，开放性的理念。在录制以及编辑过程中，都会有数据的回调并支持第三方库进行美颜，滤镜，贴纸，特效等功能。

最后是关于可配置参数方面的设计，除了常规参数，比如摄像头分辨率和帧率、麦克风采样率等可以进行配置之外，包括美颜等参数也都是可以进行配置的。

2、短视频SDK架构

image

图 8

图 8 所示为 Android 短视频 SDK 的架构图，可以划分为四层。第一层为应用层（基于 SDK 开发的应用）；第二层为 SDK 对外的接口层（均以 PLShortVideo 为前缀）；第三层为核心层，主要是内部的一些模块（其中分 Java 和 Native 两块）；第四层主要是 Android 系统层。

image

图 9

图 9 所示是整体数据流程图；输入模块支持通过两种方式采集数据，一种是通过摄像头和麦克风采集数据，采集到的数据可以进行数据处理（美颜、人脸识别等），另一种则是通过文件导入并进行解码处理；编辑模块有着十分丰富的功能比如添加字幕、MV 特效、添加背景音乐等等；编码模块主要支持 H.264 软编/硬编以及 ACC 软编/硬编；编码之后的数据会进行 MP4 封包，此后进入输出模块，可以存储到本地也可以使用 HTTP 进行上传。下面将着重就几个模块进行介绍。

image

图 10

图 10 为录制模块的示意图。录制模块的重点在于帧数据获取，除了可以通过摄像头获取视频帧，还可以通过屏幕录制获取视频帧，而音频帧数据主要还是通过麦克风进行获取；虚线部分的 Filter 模块主要实现了内置美颜/滤镜功能，另外因为有纹理和 YUV 数据的 CallBack 回调机制，所以也支持第三方库的美颜、滤镜、特效等功能；处理后的数据会经过 OpenGL 进行裁剪，缩放，旋转等操作，这些工作虽然可以由 CPU 来进行，但是会比较耗时，利用 GPU 是更明智的选择；最后得到纹理后，会被分成两路，一路渲染显示，另一路进行编码封装，这两个线程共享同一个纹理，这样的处理大大减少了资源的占用，提高了 SDK 的工作效率。

image

图 11

图 11 所示为编辑模块的示意图。首先需要导入一个视频文件（使用短视频 SDK 拍摄或者从外部导入的视频文件），解包之后会得到相应的帧数据，接着分别通过音视频解码器得到 PCM 和纹理，然后把它们送进编辑引擎，在这里面可以进行各种各样的处理（水印、文字特效、背景音乐、多音频混音等）数据经过编辑之后，与录制相同会分两路，其中一路进行播放渲染，另一路会进行转码保存。

image

图 12

图 12 所示是 MV 特效的实现思路。通过摄像头采集的数据无需解码，而 MV 视频文件的帧数据则需要解码后才可以进行处理。SurfaceTexture 的主要作用是将解码后的数据帧进行回调通知你可以在 OpenGL 线程中更新纹理了，这个通知可以是多线程同时进行的操作，所以在帧回调时一定要对其进行上锁，防止出现 MV 画面之间不同步的问题。更新之后得到相应的纹理，将其进行混合就能得出最后的 MV 特效图。

image

图 13

图 13 为日志系统的模块图。日志系统主要是为了方便排障，快速定位问题以及调试问题，我们会将 SDK 版本、设备机型、系统版本，关键配置等一一进行输出，以方便用户根据这些信息进行排障。

踩过的坑

当然，研发过程不可能一帆风顺，总要踩过一些坑才能使整个 SDK 更加完善。下面就列举一些我们踩过的坑以及排查的过程。

部分视频剪辑出现花屏

image

图 14

我们通过对客户提供的一些样本视频进行分析后，发现出问题的都是带有双向引用 B 帧的 High profile 视频，如图 14 所示，B 帧（3）位于中间，其引用左右两边的 P 帧（2、4）在显示时是这样的顺序，但是在进行帧存储以及视频解码时，B 帧（3）是在这 2 个 P 帧其后的。

在使用 MediaMuxer 封包时有要求下一帧的 PTS 必须大于等于上一帧的 PTS, 也就是：

i +1 帧 PTS >= i 帧 PTS

而 MediaExtractor 读出视频帧是按照 DTS 顺序的，也就是 PTS 是会有回退的，所以问题就出在这里了，按照 DTS 的顺序去重新封包，必然会导致后方的 B 帧被丢掉，这样就导致了花屏的问题。目前 MediaMuxer 在 Android 7.0+ 才支持对 B 帧封包，因此除非你的 APP 最低兼容到 7.0，否则建议选择使用 FFMpeg 进行封包。

最后给大家分享一句话，也算是对自己的一个鼓励，就是「Fake it until you make it」。对于我们客户端团队，要将 SDK 打磨到最完美的状态我们进行了很多尝试，也历经了很多血泪，最后才有今天的成果，我们需要努力的地方也还有很多，也会再接再厉，谢谢大家！

-END-

点击立即体验［七牛云短视频解决方案］