在当前直播和短视频领域，各家公司为了吸引用户和提升用户体验都在创新各种视频玩法，例如美颜、美妆、虚拟形象等。这些酷炫的效果背后其实是强大的渲染技术。我们亟需一个底层渲染框架来高效地支撑我们的业务迭代。
引擎设计
1. 引擎特点
前面说了我们的目标是开发一个跨平台、可扩展、高性能的渲染引擎。怎么理解？下面详细阐述一下：
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双端。并且稳定迭代了若干个版本，在多个业务场景中使用，例如秀场直播、电台直播、录屏直播等。
来源：oschina
链接：https://my.oschina.net/u/4203900/blog/4304874