硬件解码后不恰当地使用OpenGL渲染会导致性能下降，甚至不如软解。本文来自PPTV移动端研发经理王斌在LiveVideoStackCon 2017大会上的分享，并由LiveVideoStack整理而成。分享中王斌详细解析了Windows、Linux、macOS、Android、iOS等多种平台下硬件解码的渲染方法及优化实践。

文 / 王斌

整理 / LiveVideoStack

大家好，我是来自PPTV的王斌。接下来我将围绕以下几个话题，为大家分享有关全平台硬件解码的渲染与优化的实践经验。

解码后的视频数据需经过纹理加载后才会进行下一步的OpenGL ES渲染操作，其关键在于如何将解码后的数据填充到纹理中。不同的平台对于此问题的解决方案也不尽相同，这也是我们今天讨论的重点。

1、常规方法渲染硬解数据

1.1 常规的OpenGL渲染

1）软解OpenGL渲染流程

常规的软解OpenGL渲染流程主要分为两部分：一是在渲染纹理前进行的准备纹理，二是渲染前更新纹理。准备纹理具体是指在第一次渲染第一帧前先创建一个设置好相应参数的纹理，而后再使用Texlmage2D将GPU上一定大小的显存空间分配给此纹理；进行渲染前首先需绑定此纹理，并借助TexSublmage2D技术将解码数据填充进之前分配好的纹理存储空间中，也就是所谓的“纹理上传”。

2）软解数据流

软解OpenGL渲染的数据流为：首先，通过调用TexSublmage将解码后放在主存上的数据拷贝到显存上用于更新纹理，随后的渲染过程也是基于显存上的数据进行。

1.2 硬解OpenGL渲染

硬解OpenGL渲染的数据流原理与软解略有不同，解码过程中的数据存储在显存上。这里需要强调的是，即使对基于统一内存模型的移动平台而言不一定存在物理显存，但移动平台会通过将内存映射给GPU与CPU来构建逻辑显存。解码后的拷贝、更新纹理、渲染与软解类似，数据流会分别经过主存、显存、显存。这里的解码在显存上的数据其实是硬解提供的相应解码输出而非各个平面的数据指针，因此系统需要将硬解出的数据拷贝至内存上并借助TexImage2D技术上传纹理。经过实践我们发现此方法的效率并不高，例如在实测中我们借助软解流程可实现1080P全高清视频的流畅播放，而若借助DXVA硬解流程处理同一个全高清视频文件则会变得非常卡顿，那么如何来优化硬解流程呢？思路一是对显存与内存间的拷贝过程进行优化，例如在Windows上较为出名的LAV Filters滤镜就使用了如SSEV4.1加速、多线程拷贝等，提升显著。但如果面对同时播放多个视频等较为复杂的应用场景，内存之间的拷贝仍会影响整个处理流程的稳定运行。

上图表示GPU（CPU）内存与显存间数据的交换速度，其中虚线表示数据由显存拷贝到内存的速度，实线表示数据由内存拷贝到显存的速度。从中我们可以看到，数据由显存拷贝到内存的速度大约是内存拷贝到显存的1/5，这也是为什么使用DXVA硬解时会出现不如软解流畅的原因。

我们期待将这个问题简化，也就是实现从解码开始到渲染结束视频数据一直在显存上进行处理。我猜想，是否存在一种数据共享方式也就是API间的数据共享从而避免数据在内存与显存之间不必要的来回拷贝？例如使用D3D则会生成D3D的Texture，如果D3D与OpenGL间存在允许数据共享的接口，那么就可以保证无论数据如何被传输都保留在显存上或不需要传输就可直接进行下一流程的处理；如果上述猜想不成立，由于内存与GPU间的数据传输速度和内存与CPU间相比快很多，能否通过与GPU间的数据拷贝显著提升性能？当然我们也可以针对GPU提供的接口，转换GPU中的数据，例如将OpenGL的纹理从原来的YUV转换成RGB以获得理想的硬解数据流，上述都是我们在考虑硬解优化时想到的解决方案。

2、硬解纹理转换一般思路

总结各个平台的情况不难发现，考虑硬解之前我们必须思考硬解的输出，由于硬解的输出不像软解的输出是一组到内存指向各平面的指针，我们需要获知硬解输出的对象与格式。现在很多硬解都是以YUV作为输出格式如NV12等，当然排除个别定制化产品通过参数配置调整输出格式为RGB的情况，根据经验硬解一般选用YUV作为输出格式。首先是因为RGB的输出实际上是在GPU内部进行的色彩空间转换，会对性能产生一定影响；其次我们也面临无法保证YUV转换成RGB的精确性，矩阵系数是定值则无法适应多样场景的问题。

如果采取数据共享，该怎样找到这些数据共享接口？首先我们应当从平台入手，了解像iOS、Android等不同平台提供了什么共享接口。如iOS与一些硬解库提供的数据拷贝接口，如英伟达的CUDA提供的转换接口等。Linux中也集成了被称为VA-API的硬解接口，针对GLX环境VA-API提供了一种可将硬解输出转换为RGB纹理的方法，开发者可直接调用此接口与其相应功能。

但用GLX的方法已经比较过时，而Linux平台上出现的一些新解决方案可带来明显的硬解性能提升。如现在比较流行的EGL，我们可将其理解为一个连接渲染接口与窗口系统之间的桥梁。EGL的大多数功能通过集成扩展实现，主要的共享方法为GELImage与GELStream。

被使用最多的EGLImage目前作为扩展形式存在，如OpenMarxAL等专门提供了一套可输出到EGLImage的接口，而树莓派的MMAL硬件解码则提供了一套由MMAL输出的Buffer转换为GELImage的方法。EGLImage可与窗口系统无关，同样也可用于没有窗口系统的服务器端。在实际应用中我们会优先考虑使用EGLImage，视频数据经过与EGLImage对应的OpenGL扩展输出为OpenGL纹理从而实现了接口之间的共享。而较新的EGLStream是英伟达一直推崇的方法，目前我所接触到的应用主要有两个：一个是OpenMarxAL接口，其可直接作为EGLStream的输入扩展并可输出OpenGL纹理，另一个则应用在D3D11的硬件解码上。如果大家使用EGLStream则需要重点核对两个扩展名：producer与consumer。producer是硬件解码输出的对象，consumer则是输出的OpenGL纹理。除了这些扩展，我们还可利用其他OpenGL扩展。对于Windows平台而言Windows使用DXVA与D3D11解码，输出结果为D3D纹理；在这里，英伟达提供了一个可将D3D资源直接转换为OpenGL纹理的接口，但此接口受到GPU驱动的限制，存在一定的使用环境限制；对于Linux平台而言如X11窗口系统，Linux提供了一个将X11的pixmap转换成GLX也就是OpenGL纹理的方法，此方法之前也用于VA-API现在已不被推荐使用。

3.、D3D11+EGLStream

接下来我将介绍D3D11硬解，D3D11硬解基于EGL提供的资源共享功能。而D3D可与OpenGL ES一直建立联系的原因是最早的Windows平台对OpenGL驱动的支持一直不佳，而火狐、Chromium等浏览器为了在各自环境下都能很好支持OpenGL，于是加入了一个由 Google发起的被称为ANGLE的开源项目。ANGLE是指用D3D9与D3D11的一些指令和（着色器）实现OpenGL ES与EGL所有接口类似的功能。除了使用ANGEL实现对OpenGL  ES的支持，这些厂商也通过ANGEL实现对WebGL的支持。除此之外，一些如QT还有微软推出的Windows Bridge for iOS等开源项目都是基于ANGEL Project，这些项目都是通过ANGEL Project实现OpenGL ES的调用。

D3D11的硬解输出结果为D3D11纹理，输出格式为NV12。后续在转换纹理时我们有两个思路：思路一较为常见，这里就不再赘述。思路二是借助EGLStream扩展，在创建一个共享的D3D11纹理后再从此纹理创建一个EGLSurface，此Surface可绑定至OpenGL纹理；我们需要做的是将解码出的纹理拷贝至共享的D3D11纹理上，拷贝方法是借助D3D11的Video Processor接口将YUV转换成RGB。尽管此方法效率较高，但有些Chrome开发者仍然觉得需要尽可能减小其带来的性能损失，也就是追求完全没有任何数据转换的最佳方案。因此在2016年时EGLStream扩展被推出，从而有效改善了性能损失带来的影响。

通过上图我们可以发现D3D11+EGLStream的软解流程与常规的OpenGL软解渲染流程有所不同，EGLStream首先需要创建EGLStream对象，而后再创建纹理对象；在纹理准备期间也需要利用此扩展并设置consumer的OpenGL ES纹理，更新、渲染纹理时EGLStream提供了PostD3D11的方法，此方法相当于直接将D3D纹理作为OpenGL ES纹理使用。在后期进行渲染时由于涉及到两个API——D3D11与OpenGL，调用API时不能同时访问二者，故需要进行Acquire过程用以锁定D3D11资源使得只有OpenGL可访问此资源。在此之后我们就可借助OpenGL渲染纹理，结束渲染后Release也就是解锁资源。

4、 iOS & macOS

而macOS与iOS也是借助之前提到的平台提供的纹理共享接口。

Apple的macOS使用VideoToolbox作为解码器且输出对象为CVPixelBufferRef也就是保存在内存或显存上的图像数据；VideoToolbox有多种输出格式，如YUV420P、NV12、RGB、UYVY422等。刚接触此平台时我注意到了其他平台没有的UYVY422格式，由于老版本系统不提供NV12接口，故UYVY442格式普遍用于老系统；而新系统上提供的NV12处理效率远高于UVYV442。当时我将此发现反馈给FFmpeg社区，随后社区在FFmpeg中添加了用以选择VideoToolbox输出结果的接口：如果是支持性能不佳的老系统则使用UYVY442格式，而新系统则使用NV12格式。macOS的纹理准备过程与传统软解相似，而纹理更新过程则略有不同，在其纹理更新中的PixelBuffer之后会输出并保存一个IOSurface，关于IOSurface的详细内容我会在后文提到。macOS通过OpenGL Framework中的一个CGL实现将IOSurface转换为纹理，而输出的结果较为独特，如输出的纹理并非2D类型而是一个矩形纹理。macOS也可通过TextureCache方法实现纹理转换并输出RGB型纹理，但性能较为低下，不在此赘述。

iOS仅提供TextureCache法，这意味着不需要生成纹理而仅需在准备纹理阶段创建TextureCache类即可并从Cache中直接获取纹理，此流程与绝大多数需要先生成一个纹理再进行转换等操作的传统硬解渲染方法有明显不同。

即使iOS与macOS可实现没有数据拷贝的纹理转换，但一个平台存在两套处理流程，这也会对开发者带来不便。而苹果公司随后公开的一个被称为IOSurface的新框架为接下来的探索提供了思路，其中包括了从PixelBuffer获取IOSurface的方法。IOSurface用以进程间进行GPU数据共享，硬件解码输出至GPU显存并通过IOSurface实现进程间的数据共享。VideoToolbox作为一个服务，只有在APP开始解码时才会启动解码进程。而Get IOSurface的方法在macOS上早已存在，但在iOS11的SDK中第一次出现。除了需要GetIOSurface，我们还需要转成纹理的函数，同样在macOS的OpenGL Framework中我们发现了TextureImageIOSurface。此函数的功能与macOS上的相似，这是不是意味着我们可以将iOS与macOS的处理流程进行整合？

事实证明这样是可行的，最终我们可统一整个苹果系统的解码渲染流程，除了OpenGL接口与OpenGL ES接口的差异之外，其它的流程完全相同。

这就引起了进一步思考：既然可以将二者进行统一，那么之前老平台上的Texturecache究竟起了什么作用？

上图展示的是Texturecache由TexToolbox buffer转到（Texture崩溃）的堆栈，仔细观察不难发现原先的Texturecache法其实也是调用TexImageIOSurface，为何老平台存在此接口却没有被启用？最终我在iOS5中发现了TextureImageIOSSurface的存在，而iOS11相对于iOS5仅仅是参数的添加与接口的微调，并且使用GPU分析工具检查后可发现IOS11与老版本系统的Texturecache方法类似，都是通过调用一个从老版本iOS上就存在至今的接口来实现相关功能。

最终我们成功统一了macOS与iOS两个平台的处理流程，在此之后如果开发者想调用官方提供的接口，首先需要判断iOS版本，如果是iOS11则使用新方法，老版本则需要使用添加参数的方法。 

5、Android硬解渲染及常见难题解决

Android平台中集成了Java、MediaCodec、OMX AL（应用层创建播放器）等可直接调用的接口。除此之外还有一种提供了如创建、解码器组件等诸多更底层功能的OMX IL接口，但如果将此接口与OpenGL结合，由于EGLImage所需的扩展是非公开的，并且OMX IL并非一个NDK系统库而Android7.0以后的版本不允许访问非NDK系统库，故而我们仅使用MediaCodec与OMX AL。

MediaCodec存在两种输出，其一是ByteBuffer也就是将结果输出到内存上，当然是不被我们采用的；其二是Surface也就是将结果输出到显存上，接下来我们需要讨论如何构造Surface。这里有两种方法构造Surface，方法一是由Surface View获取Surface并直接输出至View上，但这对我们而言意味着无法使用OpenGL，故排除。方法二是Surface Texture，在解码线程的开始需要配置MediaCodec输出，由纹理构建Surface Texture，而后Surface Texture借助UpdateTexImage法实现渲染线程更新纹理。这里需要明确的是Surface Texture纹理的对象是什么样的？由于Android没有相关文档，我们可假设此纹理是一个有效纹理，如何创建此纹理？

以XBMC为例，首先解码线程会给渲染线程以创建好纹理的信息同时渲染线程会反馈信息给解码线程。但由于此消息循环机制并未在所有APP上推行，这对设计适用所有APP框架下的播放器来说并不合理，针对此问题我们有两套解决方案：第一套方案是可以在解码线程创建共享上下文并在此上下文下创建一个可在渲染线程被访问的纹理。

但创建共享上下文的方法对一些安卓开发者而言门槛较高。第二套方案是在流程开始时创建一个无效的纹理，由于Surface Texture可把纹理附加至Surface Texture上，这样只需在第一次渲染时把这个在渲染线程创建的合适纹理附加上即可。

以上两种方法基本解决了一些相对重要的MediaCodec问题，除此之外我们也会面临APP后台切换至前台时UpdateTexImage（）错误的情况，如果是由于上下文不对一般可通过重新初始化解码器或使用TextureView等方法解决。但如果用户想借助SurfaceView解决此问题，也可通过共享上下文的方法，为SurfaceView提供一个上下文并在每次渲染前激活。但此方法具有仅适用于自己创建的上下文的局限性，如果上下文由外部提供，那么我们还可以通过attach方法。

attach方法大致流程如下：每次渲染时生成纹理并attach至上下文，调用更新纹理的方法使得数据保留在纹理上，最后将此纹理Detach。

最后想介绍些关于Open MAX AL的内容。Open MAX AL在安卓上并未提供EGLStream扩展，而创建OMXAL播放器时需要设置输出参数，对安卓而言输出Native Display对象也就是ANative Window，其由Surface获取并调用NDK接口，与OMX AL输出的Surface一致，所以之后的与Surface相关的流程和MediaCodec完全相同。