返回 登录
0

短视频 SDK 架构设计实践

作者简介

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

短视频发展史


图 1

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

图 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 架构设计理念


图 3

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


图 4

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


图 5

图 6

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

图 7

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

PLShortVideoRecorder:prepare(GLSurfaceView preview, …)

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

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

2、短视频SDK架构


图 8

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


图 9

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


图 10

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


图 11

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


图 12

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

图 13

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



## 踩过的坑

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

部分视频剪辑出现花屏


图 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-

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

评论