直播美颜技术大揭秘！

作者 | 阿里文娱无线开发专家风吟

责编 | 胡巍巍

出品 | CSDN（ID：CSDNnews）

背景

在当前直播和短视频领域，各家公司为了吸引用户和提升用户体验都在创新各种视频玩法，例如美颜、美妆、虚拟形象等。这些酷炫的效果背后其实是强大的渲染技术。优酷和来疯也在布局这一领域，我们亟需一个底层渲染框架来高效地支撑我们的业务迭代。于是，自主开发一个跨平台、可扩展、高性能的渲染引擎就被提上了日程。

引擎设计

1. 引擎特点

扫描二维码关注公众号，回复： 9690593 查看本文章

前面说了我们的目标是开发一个跨平台、可扩展、高性能的渲染引擎。怎么理解？下面详细阐述一下：

1）跨平台。我们的业务场景涵盖了移动端和PC端。为了提高开发效率，我们要把平台无关的逻辑抽象成公共组件，例如渲染管线、后处理算法等，实现一份代码，多端共用。

2）可扩展。跨平台解决了横向的平台差异问题，而可扩展就是解决业务迭代的纵向问题。我们将渲染逻辑分解成一个一个的小“零件”，业务方可以像搭积木一样自由组合这些“零件”，而算法同学也可以很容易的造“零件”。这样业务迭代就简化成了简单的加减法，效率大大提升。

3）高性能。音视频渲染，尤其是视频渲染，是很耗费计算资源的。在端侧有限的计算资源前提下，还要能实现快速、高质量的渲染效果，就需要我们厘清渲染链路中的每个环节，剔除冗余逻辑，实现高效渲染。

2. 引擎架构

在以上思想的指导下，我将渲染引擎分成了两层：引擎层（Engine）和业务封装层（MediaSDK）。

1）引擎层是平台无关的，使用C++开发，渲染后端使用了各平台都支持的OpenGL框架。核心思想是把渲染链路抽象成有向无环图（DAG），最基础的组件抽象成插件（Plugin），所有的数据源（Source）、算法（Filter）、输出终端（End）都是插件，再定义好插件的输入/输出协议，只要上下游插件的数据交互满足协议就可以自由组合。引擎层的架构图如下：

2）业务封装层封装了引擎层的调用逻辑，在Android、iOS和Windows平台上对业务方提供统一调用接口，方便业务同学使用，并提供日志、监控和资源管理等能力。业务封装层的架构图如下：

实践

1. 技术挑战

实现过程有两个挑战，一个是跨平台，一个是高性能。

1）跨平台

a) 引擎层虽然使用了OpenGL作为渲染后端，但Android和iOS系统提供的是OpenGL ES，Windows提供的是OpenGL，这两个版本在shader语法上是有差别的，这就需要引擎和算法去做适配。其次，要使用OpenGL需要在每个平台上都实现一个上下文环境，iOS是EAGL，Android是EGL，Windows是WGL。各平台虽然都有封装好的GL组件，但是都不太好用（有Bug）,最好的办法还是自己调用底层API，这就需要对OpenGL有一定的了解。

b) 业务封装层封装了引擎层的底层接口，对外提供统一业务接口。而业务开发是平台相关的，语言也不尽相同，Android是Java，iOS是OC，Windows是C++。并且像相机、编/解码器、View这些系统组件各平台实现并不统一。因此开发业务封装层需要对各语言和系统特性都有较深入的理解，才能实现易用性和性能的统一。

2. 高性能

a) 一个思路是尽可能的使用GPU，解放CPU，因为GPU在视频处理方面有天然优势，引擎里的计算基本上都放在了GPU侧，包括图像色彩空间转换、后处理等。而且在某些场景下还会对图像做下采样，进一步降低GPU使用率。

b) 即使算法都使用GPU实现，但是还要面对显存-内存数据互传的问题，从内存上载数据到显存和从显存下载数据到内存都会阻塞CPU，导致CPU占用率高。解决方法一是引擎内部数据都使用纹理传递，尽可能减少显存-内存数据互传。二是使用双PBO，异步传输数据，但这个方案需要注意数据同步的问题。

3. 引擎落地

1）算法接入

由于引擎的算法实现都抽象成了插件，而且将渲染的公共逻辑都提取到基类，算法同学接入算法时只需要关注shader本身就可以了，接入是很方便的。理论上只要符合插件规范，任何算法甚至二方或者三方SDK都是可以做成插件接入进来的。目前引擎接入的算法能力有：人脸检测、美颜、滤镜、2D贴纸，未来还将接入美妆、美体、3D贴纸、Avatar等。

2）业务接入

渲染引擎提供了多种输入，如相机采集、帧序列等；多种输出，如UI、编码、帧序列等，结合前面提到的算法能力，业务方只需要调用简单的几个接口就可以定制自己的渲染管线，从而实现自己的业务需求。目前渲染引擎接入了来疯iOS和Android双端，来疯PC浏览器插件，优来播iOS和Android双端。并且稳定迭代了若干个版本，在多个业务场景中使用，例如秀场直播、电台直播、录屏直播等。

总结与展望

1. 沉淀

回顾整个渲染引擎的开发过程，其实是踩了很多坑，也是对渲染技术的一次深入挖掘。整个架构的设计经受住了业务的考验，也为今后类似SDK的开发提供了宝贵的经验。

2. 引擎存在的不足

虽然渲染引擎在目前的应用场景中运行良好，但还是存在一些不足，主要有两点，一个是OpenGL天生的缺陷，即OpenGL上下文和线程是强相关的，导致渲染引擎设计上虽然是一个DAG，但实际上管线的所有绘制操作都是串行的，不能充分发挥GPU性能；二是引擎内部数据传输只支持push的方式，即只能上游推动下游消费数据，而不能下游主动从上游拉取数据消费，这就制约了引擎的使用方式。

3. 引擎2.0

前面提到渲染引擎在低端机上性能不佳，主要原因是OpenGL渲染耗时。其实谷歌和苹果都已经在最新的代码中将OpenGL标记为deprecated，分别在推广新一代渲染框架，即Vulkan和Metal，而微软也有自家的渲染框架，即DirectX：

这些新框架思路大同小异，相比OpenGL的优点有：支持预编译shader、支持多CPU线程、支持直接访问GPU CommandBuffer等，对开发者更友好，运行效率更高，甚至能达到成倍性能提升。所以，未来渲染引擎的2.0版本将会支持多backends，包括Vulkan、Metal和DirectX，以实现更好的性能。

【End】

《原力计划【第二季】- 学习力挑战》正式开始！
即日起至 3月21日，千万流量支持原创作者，更有专属【勋章】等你来挑战