关于音视频:音视频终端引擎优化实践

本文由百度智能云 - 视频云终端技术架构师 ——李明路，在百度开发者沙龙线上分享的演讲内容整顿而成。内容从音视频终端引擎的概念登程，梳理了音视频终端引擎的倒退和技术演进，重点介绍了音视频终端引擎的关键技术组件，分享了开发过程中的教训与实际。

文 / 李明路

整顿 / 百度开发者核心

视频回放：https://developer.baidu.com/l…

本次分享的主题是：音视频终端引擎优化实际。内容次要分为以下五个局部介绍：

1. 音视频终端引擎介绍
2. 视频云音视频终端引擎倒退
3. 视频云音视频终端引擎面向企业级架构思考
4. 视频云音视频终端引擎关键技术组件
5. 视频云音视频终端引擎面向开发者提供服务

01 音视频终端引擎

什么是音视频终端引擎

定义：音视频终端引擎，是一款集成在挪动或嵌入式设施中，应用软件定义的办法，扩大终端原有音视频解决能力，以高效地形式解决异构音视频场景下的归一化、抽象化、层次化的客户端问题。

正文：

1. 归一化：指提炼不同音视频场景背地的主线逻辑。
2. 抽象化：采纳虚构映射的形式，定义不同音视频实体与组件内部分割。
3. 层次化：通过顶层架构的设计，实现不同音视频业务与接口内生关系。

音视频引擎终端引擎根本架构

首先看图片的顶端，这一条链路很好的解释了在上一章提到的归一化：音视频终端是从业务中迭代进去的，通过一些方法论，还要可能回归到业务当中。

在这条链路上，列举了几个常见的业务场景：点播、直播、短视频、实时音视频等。随着这些音视频场景的不断丰富，业务也会越来越简单，可能提炼不同音视频场景背地的主线逻辑就显得非常重要。

接下来，咱们重点剖析音视频终端引擎架构。

音视频框架首先要立足挪动端提供的零碎能力，包含零碎框架和硬件能力。
如图，零碎框架层有 iOS/Android 的一些多媒体框架、硬件的编解码、硬件的解决能力如 CPU、GPU、NPU 的解决模块，以及一些开源图像库。

零碎框架层之上是第三方框架，如 FFmpeg、OpenSSL（加解密）；在点播场景用的比拟多的 Ijkplayer/Exoplayer；用于底层通信的技术：双向、低延时的 WebRTC 技术，用于单向点播的 RTMP，目前比拟火的 SRT 低延时计划；除此之外，还会有一些图像处理方面的框架如 GPUImage 等。

在此之上，就是一些跟场景相结合比拟多的模块，这里大抵列出了局部外围模块。

数据从多媒体采集模块进去，会通过一路或多路的混音混流（与理论场景相结合），而后过渡到多媒体编辑模块：当下短视频的一些能力（比方：转场、字幕成果增加等）都是通过多媒体编辑这个处理单元实现，再到前面的多媒体后处理模块：例如 AR 特效，以及一些比拟好玩的互动能力等；内容生产实现后，咱们会依据点播、直播或者短视频等场景的不同，采纳不同协定进行散发。

再上面就是生产侧，这里能够间接读取数据，也能够间接读取数据作为缓存放慢二次读取数据的载入。获取数据后会依据不同的封装格局，如 FLV、TS 或者是 MP4 等对数据进行解封装，再进行解码和渲染操作。

相比于其它挪动端框架，音视频框架最特地的中央就是管线局部，因为音视频 SDK 的产品与其它产品不太一样，首先须要的是实时处理，数据流是一直在各个模块之间穿梭的，如何保障各个模块间的高效传输，这里提出了一个管线的概念。

那么，是不是有这样的根本架构后，就能解决当初音视频场景的能力呢？答案当然是否定的。事实上，这套架构中，在软件层面、硬件层面都或多或少面临着挑战。具体来说，大抵能够分为以下几种：

1. 平台能力不对齐

尽管当初很多的平台都提供了大量的音视频解决能力，然而这些平台的能力并不对齐。上面以苹果 iOS 零碎的多媒体框架和 Android 多媒体框架解决 1080p 的高清视频举例说明。

• iOS 零碎多媒体框架：
  领有 AVAsset, AVCapture 接口，通过这些接口可能很疾速获取到高分辨率视频的裸数据。
• Android 零碎多媒体架构：
  不足像苹果这样的简略高效接口。通常须要两步解码，并且针对高分辨率的视频可能会解码失败。

2. 编解码芯片适配难

编解码芯片简单且多变，很多厂商会依据本人的平台 / 产品进行二次定制，导致音视频编解码芯片的规范是对齐的。这对于开发者和云厂商来说，适配的技术老本十分高。

3.CPU 到 GPU 性能开销解决难

尽管说当初很多的高端手机都能提供十分多的协处理器，能力也十分强。然而针对音视频场景，性能开销的解决却有肯定挑战。比方视频的采集，通常是在 CPU 解决，然而若想做一些减速解决，须要在 GPU 进行。从 CPU 到 GPU 这种数据的转化协同，如果解决的计划不是特地好，会导致性能的开销十分大。

4. OpenGL 图像处理框架挑战频频

OpenGL 是比拟老旧图像零碎框架，目前遇到了十分大的挑战。苹果在 ARM11 处理器上已提出自研的 Metal 解决框架，并把 OpenGL 图像处理框架标记为将来可废除。若 OpenGL 在将来废除，势必会影响目前大多数主流产品的稳定性。

音视频终端引擎新挑战

简略介绍了音视频 SDK 的框架，接下来介绍目前框架遇到一些问题和挑战。

1. 更高的音画规范
   
   目前很多业务场景，其实都在谋求更多的新玩法。会谋求更大的分辨率，还有一些更高的刷新率，甚至是更极致的体验。比方：有些场景像点播或短视频，720p 的分辨率曾经不能满足场景的应用，甚至在一些静止场景，30fps 的刷新率也曾经没方法满足场景的开发。

但音视频 SDK 很大水平上会受制于平台的能力，因为平台具备很多差异性，以及相干硬件没有齐全遍及，所以导致音视频 SDK 在倒退过程当中，其遇到很多的问题。

另外多模块间的数据交互到模块间的数据交互也是一个微小挑战，如何保证数据无损解决和高效传递？

2. 跨屏的音画场景
   
   除了方才说音视频本身的高清技术标准的降级外，音视频终端也在缓缓的摸索一些沉迷式场景体验，这也催生了一些新的平台和新的交互方式。

比如说一些带屏幕的智能音箱，用户能够在这种类型的设施上就会有一些新的需要：更好的场景渲染、更好的通话质量、更低的播放时延。
还有目前比拟风行的数字人：如何在户外大屏幕，甚至在一些专有设施上以更高精度的形式出现进去？

这些音视频终端数据跨屏，迫使音视频终端引擎反对更多的硬件平台、更多的个性适配、更好的人机交互。但受限于设施兼容性，如何保证数据的高效计算和稳固传输？这些都是音视频终端引擎须要面对的问题。

02 视频云音视频终端引擎倒退

通过上一章的介绍，置信大家对音视频终端引擎有肯定的理解。在本章将梳理百度视频云做音视频引擎的倒退过程，并筛选几个重要节点介绍具体的利用计划。

视频云音视频终端引擎倒退路线图

百度智能云在较早的时候就提出过音视频解决方案，下图形容了次要的倒退历程。

阶段 1：OneSDK 音视频解决方案
提供推拉流能力，在千播大战和直播答题等场景有宽泛的利用。

阶段 2：一站式解决方案
随着当初短视频、互动直播、以及其余实时音视频场景的一直的丰盛。百度提供了更全面的一站式的解决方案，其中包含了特效、编辑和连麦的能力。

阶段 3：Pipeline 设计
随着开发者对音视频场景的一直理解和深刻，也提出了一些更高的要求规范。如：低时延、高清化。百度视频云通过重构的 Pipeline 计划，将底层能力通过管线进一步凋谢进去。

阶段 4：研发范 式
如何让开发者更高效的利用这些管线？百度视频云也提供了一些研发范式。通过研发范式，使得管线可编程。除此之外，也提供一些简略利用的组件，可能让开发者更疾速、更高效的将凋谢能力与业务相结合。

阶段 5：SDKEngine
目前，SDKEngine 也还在继续技术演进，次要是钻研通用引擎技术的落地，以更好满足跨平台、跨终端的音视频需要。

一站式解决方案介绍

一站式的解决方案，是以本身业务倒退为出发点，将业务依照肯定模块进行划分，并以模块化形式进行对外输入。

从上图能够看到，在最早的一站式解决方案中，会提供十分多的组件与模块。比方：录制模块、直播模块、互动模块、特效模块等，并且这些模块之间存在肯定的依赖关系。
这种计划对于想疾速接入音视频场景的开发者来说是非常的高效，可能帮忙开发者从 0 到 1 疾速建设音视频场景，并提供轻量级、一站式的接口解决方案。

但事实上，客户侧的需要也在一直地发生变化。如：业务须要做推流或者一些更底层地调试以及取得底层能力的凋谢服务，这须要客户通过提工单的形式告知解决方案厂商，而厂商又须要评估、迭代，将这些能力逐渐的凋谢，这对开发者的体验并不是很敌对。因而，接口与业务解耦是引擎的下一步倒退方向。

Pipeline 设计方案介绍

Pipeline 设计，站在交融的视角，以流水线的形式交融异构业务架构，整合音视频底层能力，复用音视频模块，以实时音视频引擎为基座，插件化对外输入。

从上图能够看到，Pipeline 设计将之前比拟高级的业务接口剔除，并凋谢更底层的接口。以录制模块为例：将录制模块中，与业务相干的逻辑进行抽离，而提供像 Capture 这样的采集组件。通过 Pipeline 的设计，逐渐的把底层能力逐步凋谢进去。

然而在凋谢过程当中，如能可能让开发者更好的应用底层技术？以及如何在 Pipeline 上做一些更加灵便的定制？这催生了咱们新的终端引擎。

研发范式计划介绍

针对开发者在 Pipeline 设计方案上的一些应用问题, 咱们期待终端引擎具备可编程、可自制的能力。
所以，百度视频云以企业级架构为出发点，联合平台中间件和业务低代码为设计思维，对外输入能力。

在之前的设计中，终端引擎都是对接 APP，而研发范式计划里，对接的是开发者。这其实是一个设计理念的降级：将 SDKEngine 泛化为研发范式，开发者能够依据本身状况，按需应用或进行二次开发。

在利用层面，将常见的组件进行封装，如：相机组件、连麦组件、推流组件等，开发者可能疾速、插拔式地应用这些组件。
在平台两头层面，实现了架构层面的治理。针对不同的音视频场景，能够通过构建计划、灵便自动化地打包相应的产品能力。

与此同时，底层的引擎能力也在逐步地凋谢进去，如：针对弱网的优化、传输能力等。

03 视频云音视频终端引擎面向企业级架构思考

在上一章介绍了视频云音视频终端引擎的倒退历程，在整个过程中也得出了一些教训。以下是针对实际得出的一些教训：

去中心化的设计理念

背景：音视频场景越来越简单，业余水平也越来越高，随着音视频开发者逐步倒退，以业务为驱动的传统设计理念无奈满足发者对新场景的一些场景的定义。

去中心化的含意：

以业务为核心转变为以服务为前提
这就意味着，云厂商要站在开发者的角度，去扫视终端引擎的倒退。该如何提供哪些能力？每个能力又该如何进行自我演进？这是一个特地好的反馈机制。

关闭架构设计转变为协同共赢
如后面章节提到的研发范式这种解决方案，它实际上是将更多的接口与底层能力凋谢给开发者。这也是心愿可能和开发者们更好的协同，并更好的服务一些新的场景。

去中心化的设计理念：

1. 繁多责任法令：将业务场景模块化。
2. 开闭法令：即高度自治，不影响其余模块。

模块品质通过厂商严格的内部测试，解决开发者的后顾之忧，并且每个模块是可插拔的，一旦呈现问题，能够疾速剔除。

3. 接口可替换：接口设计兼容并蓄。

目前音视频辨认场景的复杂程度远超云厂商的设想，开发者对模块或者说接口的需要是个性化的。这就须要音视频终端引擎的模块、接口是能够独立输入的，并且设计兼容并蓄，以缩小开发者在应用过程中的一些累赘。

4. 接口隔离：接口易于了解。
5. 依赖反转：面向接口编程，易用。即：要求接口是好上手，可能疾速应用的，甚至在二次开发和进一步封装的时候都是没有任何累赘的。

被集成到可编程

历经音视频终端引擎的倒退，咱们认为，SDK 可集成是根本能力，具备可编程的能力才可能更好服务于开发者。这样可能将客户侧业务与终端引擎解耦，提供规范组件，反对可编程的范式开发。

如上图示例：原有的直播 Demo，在设计层面会提供很多简单的 UI 与业务逻辑，而在代码层面，会蕴含很多业务的 SDK，这种设计接入简略，然而能力有余，无奈拆分细化场景，影响开发者对 SDK 产品的辨识度。

通过 B 端设计与业务重构，将原有的直播 Demo 拆分为几个业务场景：规范直播场景、互动直播场景、低延时直播场景等，通过研发范式，将终端引擎能力释放出来。并且每个模块之间的内聚性强，节俭开发者的应用老本。

03 关键技术组件介绍

数据管线组件介绍

数据传递由数据管线负责，它可能让各个组件之间的数据传递实现高齐全解耦。以上图的直播推流场景为例，介绍数据管线是如何实现数据传递的高齐全解耦。

直播推流场景依照较粗的分类维度，可大抵分为以下几类：相机类、美颜类、推流类。
相机类会应用到一些底层组件，比方：采集组件（开启摄像头、麦克风等），采集组件会将数据通过接口回调的模式传送给相机类，那么相机类的数据又如何传输给美颜类或者其余类呢？

首先是制订数据协定，次要解决的是最根本的模块间数据的高效、稳固的传递。咱们提供了 AVOutput 模块和 AVInput 的数据传输接管的协定，单纯的去记录和治理这条链条上的各个的组件，咱们称之为 target。

而后通过 Dispatcher 的机制，散发从生产端上报的视频帧，通过视频帧一直的传递到各个链路的 target 当中，而每个 target 实现 AVInput 其中的协定办法。例如 frame 跟 type 两个函数，frame 就是从 raiseFrame Output 传递下来的数据；type 次要是做一些音视频的音频跟视频的辨别。

除此之外咱们还反对一些二进制场景的散发，次要是为了配合像直播这种对数据有散发要求的场景做了一些协定的降级。在链条的最末端，能够看到咱们也实现 AVControl，跟之前不太一样是咱们制订了一个控制协议，这个控制协议次要是为了控制数据的流入和流出。

为什么要做这个事件呢？咱们晓得音视频 SDK 最外围的就是数据在一直的传递，如果说某个模块出现异常，数据没有一种机制能爱护它，可能会导致整个 SDK 的运行呈现不稳固的状况。比方在直播场景散发的时候，咱们发现网络有抖动，此时咱们能够调整发送的速率、速度等。

这里简略的画了一下咱们的数据流向。

一个是推的形式，就是间接从相机这种模块采集数据，间接着向前面的某个模块去传递。
一个是拉的形式，次要是指读取本地文件或者说是间接的获取数据，比方从网络读取数据首先须要将数据读下来，而后再传递到各个模块。

这里其实绝对于之前说了 GPU 在异步线程的一些解决，咱们也做了一些兼容和爱护，就是避免异步解决时对象被开释的状况产生。所以说咱们基本上也是沿用了 GPUImage 协定简略的这种思维，而后在此基础上又减少了一些像控制协议的实现机制，让整个链路变得可控。

在这一步中，控制协议的退出是十分必要的。咱们晓得，终端音视频的场景，大多时候都是实时处理的，而预处理的功能模块一直叠加，给终端性能带来了很大的挑战，退出控制协议，能够将这些管制交给开发者治理，通过及时调整参数，保证数据的高效传输。

特效组件介绍

特效组件会有提供很多接口，特效模块通常是典型的 PaaS 构造，它下面存在多种模型，而且模型之间是能够进行插拔；它还有另外一个特点就是耗资源。那么如何在音视频 SDK 中将这个模块更好的使用起来，去对外提供能力呢？

咱们这里以人脸特效的高级美颜接口为例，高级美颜中波及到的特色点十分多，像大眼、瘦脸、下巴等，而且这些特色点并不是通过一次迭代或是一个模型就能解决的，它可能会波及到屡次的迭代和多种模型的组合叠加。这样就会带来一个问题，在集成特效模块的时候，如果这些能力都是一直变动的，对于模块的应用来说，就存在一个不平安不稳固的因素。那么咱们该如何把这个问题解决，或者说屏蔽掉呢？

这里提供了一个概念：代理层。
首先在调用能力的时候，不间接去调用，而是把这些能力做进行形象、封装，而后这些封装的模型，用来关联前面的一些不同的算法。因为开发者在应用 SDK 的时候，不肯定依照厂商提供的所有货色来集成，可能只应用其中局部能力，这样就有可能会导致一些特效的 SDK 存在版本不统一。

如果没有这个代理层，当呈现版本不统一的状况，对于下层来说可能就会呈现大量接口的调整和批改，会比拟耗时耗力。不过咱们做代理的话，可能就给屏蔽下层接口的稳定性，而后通过咱们的模型跟一些形象对象，能够去驱动不同的 AR 模块的版本。

通过上图，咱们能够更加直观的理解：
相机模块和特效模块之间的数据通过数据管线的形式进行连贯，当数据进入特效模块后，依据开发者传入的不同参数，组件会通过该特色去关联相干的人像算法，以可能更快和更有保障的隔离一些问题的产生。

同时这些数据还会传输给端侧进行端侧推理，目前百度视频云音视频终端引擎是利用百度的 Paddle lite 进行的端侧推理。通过外围性能和指标的检测，实现图的优化，最终通过渲染、数据转换，造成最终的特效成果。

渲染组件介绍

渲染组件其实十分好了解：给定点线面信息及纹理信息，将这些信息生成一张或者多张位图的过程。它也是音视频终端引擎的关键技术之一，是用户感知的最初一公里，随着场景化丰盛，（比方：HDR 视频的合成与播放、VR 虚拟现实等）渲染模块成为数据交互和解决的汇聚点。

百度视频云目前次要还是应用 OpenGL 这个组件，也对这个组件做了一些优化与实际，通过这些优化以晋升渲染组件的跨平台易用性。

实际上，iOS 的离屏渲染和 Android 的离屏渲染在底层上有很大的差别，并且这些差别导致在封装和适配上有很多技术细节的不同。上面简略介绍一下这些技术细节实现的不同。

1. ES 3.0
   OpenGL 的 3.0 给开发者提供了很多的个性。如他新增了 VAO 的概念，而 VAO 在解决多 Buffer 的状况下，效率是更高的。
   而针对不反对 VAO 的平台，咱们也模仿了 VAO 的概念，这使得跨平台的渲染组件能够更加高效的反对在各个终端上。
2. 基于 OpenGL ES3.0 渲染组件部分框架：
   首先将传统 VBO 的概念通过 ES3.0 封装到 VAO 的数据格式里，接下来在 ES2.0 的根底上，通过模仿实现能力对齐。
   Shader 拆分：OpenGL 是可通过 Shader 语言编程的，所以将 Shader 进行拆分。如：将地位信息、顶点信息进一步拆分进去，并提供更简略、形象的接口，缩小大家的应用老本。在将来，也会逐渐开释 Shader 的一些底层开发方式，让开发者更好的适配一些高级办法。

基于此，根本可解决跨平台上对于渲染组件的一些根本诉求。

RTC 组件介绍

RTC，对于实时类的业务提出了更高的技术标准，更低的端到端时延以模仿更天然的交互。它的应用场景也非常广，比方：互动连麦、直播带货、超低延时播放等。

百度视频云团队目前是提供了两个 RTC 的组件能力。一个是连麦组件 RTCRoom, 另一个是针对超低时延场景的 RTCPlayer 播放器。并针对这两个组件，也做了技术的优化。

1. 传输品质的优化
   信令 Over UDP 更快的通道，时序解决。
   RTC 的信号传输是双向的，而传统的信令传输计划是基于 TCP 发展，为了达到更低时延的成果，采纳更快的通道：UDP。并且 UDP 在传输过程中是会呈现丢包的，并不是依照程序传输，所以还须要在时序上做一些解决和管制，防止出现不合预期的内容。
2. 传输链路剖析与优化
   传输链路调优，辨认不同网络下，上行拥塞控制策略。
   在用户应用 RCT 组件时，网络环境可能会实时变动，针对这种实时变动的场景，RTC 组件须要疾速辨认进去，并须要通过一些策略使得对上行接管侧的影响降到最低。具体流程可参照上图。

概括来说就包含：
基于发送侧拥塞管制，局部码率预估解决流程；上行分级传输，上行平滑渲染。

这其中，码率预估是整个 RTC 传输链路中的非常重要环节，如果上行传输品质无奈保障，上行的再多优化都是徒劳。
因而，在整个计划中，也会基于不同的场景，如：丢包场景，延时场景做出大量优化。
针对丢包场景，采纳不同分级策略。呈现常见的丢包状况（带宽无限度，只是丢包状况呈现），须要调整策略应用更高的码率去传输，并配合服务端的重传机制，让抖动的数据传输尽快恢复。
呈现高级丢包的状况（如：4G 切 3g, 进地铁等场景），是会呈现长时间的带宽延时，这个时候须要在在码率预估环节做出精准预估，不让它变动起伏显著，保障上行的传输。

上行平滑渲染也很要害。针对上行丢包的场景，如何在可能疾速渲染，使得延时变低？这须要制订一系列的传输质量标准，精简非必要的 RTC，以适应不同的网络。

05 视频云音视频终端引擎——面向开发者提供服务

• 面向行业用户
  目前百度视频云音视频终端引擎服务宽广行业用户。包含金融行业、教育行业、传媒行业等，针对不同场景，准入机制及要求都是不一样的。这也保障了不同的开发者在应用咱们产品中可能各取所需。
  
• 面向一般开发者
  https://cloud.baidu.com/doc/D…

一般开发者能够通过 SDK 核心理解视频云终端引擎的能力，也能够接入本人的产品中去体验。

以上是老师的全副分享内容。有疑难欢送在评论区提出。