中期检查报告

适用于ChromeOS/Android的硬件加速视频编解码中期检查报告 

    从得知有幸参加夏令营到现在差不多有一个月了。在这一个月内，经过不断的阅读文献以及和导师的交流，对整个项目有了一个比较清晰的认识，下面谈谈个人对项目的一些认识以及总结这一个月所做的工作。

    首先介绍一下硬件加速。视频的播放过程中离不开解码， 视频解码是非常消耗CPU的一个任务，尤其是1080P这种高分辨率的高清节目。解码方式可以分为硬解和软解，可以简单得理解为用CPU进行解码就是软解，而是用GPU进行解码就是硬解。GPU视频解码的诞生就是为了解决因为高清视频运算量大，中低端CPU根本跑不动的问题，而且显卡的价格相对于CPU来说也更加便宜，用户投资更小。项目所提到的硬件加速视频编解码顾名思义是指利用GPU进行视频解码，从而降低CPU的占用率。

   为了对硬件解码加速有一个更加直观的了解，在windows系统中利用完美解码的硬件解码功能进行体验。分别对1920*1080和1024*576两种规格的视频在软件解码和硬件解码下查看CPU占用率，测试结果如下：

               

                      

                                                                                                                            图1   CPU软件解码（1024*576）

       

                                                                   

                                                                                                                         图2   GPU硬件解码（1024*576）

                      

                                                      

                                                                                                                        图3  CPU软件解码 （1920*1080）

                     

                                                                                                                       图4  GPU硬件解码 （1920*1080）

         从图2和图4中输出后面的dxva（后面会提到）可以确定开启了GPU硬件加速功能。并且可以看到CPU到的占用率分别从19%和52%降低到4%和8%。可以看出硬件加速确实很好地降低了CPU的占用率，并且高清视频的效果更加明显。

        有了上面的认识之后，接下来简要介绍一下该项目中涉及到的一些知识。

         首先，什么是Gstreamer？Gstreamer是GNOME桌面环境下用来构建流媒体应用的开源多媒体框架（framework），其目标是简化音视频应用程序的开发。GStreamer框架是基于插件的，有些插件中提供了各种各样的多媒体数字信号编解码器，也有些提供了其他的功能。GStreamer核心库函数是一个处理插件、数据流和媒体操作的框架。

        现在显卡制造商分为三大家：intel，ati和nvidia。想要进行硬解就得确保自己的显卡支持视频硬解。首先，必不可少需要利用显卡驱动来调用电脑的显卡，但是光有显卡驱动是不行的，显卡驱动本身不提供硬解所用的编程接口，你还需要驱动和播放器中间的api接口，从windows上这个叫dxva（如图2或图 4所示），是自带的，由微软定义。linux上由于没有了厂家，所以只能由显卡制造商来定义，n卡的名为vdpau，a卡和intel的名为vaapi，是由intel开发的。通常这些API提供了一系列的功能，比如：视频解码，后处理，解码帧的描述，或者把帧下载到系统内存等等。相应的，不同的功能插件一般是给不同的element使用的，这样pipeline可以适应任何需求。

         VAAPI(Video Acceleration API)：2007年Intel设计的，目的是在Unix操作系统的XWindow系统下运行，现在开源了。现在不仅仅局限于Intel的GPU了，其他制造商也可以使用了。GStreamer通过gstreamer-vaapi和fluvadec这个插件来使用。

         VDPAU(Video Decode and Presentation API for Unix)：2008年NVidia设计的，最早也是运行在Unix的XWindow系统下，现在同样开源了。虽然同样已经是开源库了，但除了NVidia自己外还没有其他制造商使用。GStreamer通过vdpau和fluvadec这个插件来使用。

         DXVA(DirectX Video Acceleration):微软为了Windows系统和XBox360定制的。GStreamer通过fluvadec这个插件来使用。

         XVBA(X-Video Bitstream Acceleration)：AMD设计，在linux操作系统的XWindow系统下下X Video的扩展。目前在AMD的ATI显卡中有支持。GStreamer通过fluvadec这个插件来使用。

         VDA(Video Decode Acceleration)：应用于Mac OSX10.6.3之后，仅仅加速H.264的解码，GStreamer通过fluvadec这个插件来使用。

         OpenMAX(Open Media Acceleration)：由非盈利性联合Khronos Group设计的，是一组跨平台的C语言编程接口。GStreamer通过gstreamer-omx这个插件来使用。

         OVD(Open Video Decode)：AMD的又一个API，GStreamer目前不能使用这个接口。

         DCE(Distributed Codec Engine)：一个开源的软件库(libdce)和TI定制的API，提供给linux系统和ARM平台的。GStreamer通过gstreamer-ducati插件可以使用。

         以上介绍了很多的API，我们要用的是OpenMAX。

        多媒体应用程序广泛应用于各种电子产品领域。然而由于各种设备硬件平台的差异和操作系统的不同，多媒体应用程序必须针对平台和系统定制开发，OpenMAX IL致力于解决在众多不同的媒体系统间的移植性问题。

        而我们项目中提到的libyami ,它是视频编解码的核心库，基于开源视频驱动vaapi ,提供帧层级的应用接口，可以被包装成OpenOMX-IL的组件，从而使用在ChromeOS或者Andriod平台上。可以这么说，Libyami相当于gstreamer-vaapi中gst-libs的子目录，进一步剔除了gst/glib之间的依赖关系后用openmax进行封装，从而能够很好地移植到不同的平台之上。

        在ubuntu中利用gst-omx进行测试时整理出各个部分之间的关系简图如下：

                             

         如果在Andriod中则无需使用gst-omx该插件，其整体框图如下：

          到此，对于硬件加速在linux系统中的实现有了很好的认识，下面在ubuntu中搭建起测试环境。如上所述，在搭建环境的过程中主要用到 intel-driver, libva ,libyami ,omxil-core ,omxil-components ,gst-omx这六个源码包，对其进行正确编译之后，在ubuntu中的测试环境算是基本建立起来了。下面就可以在ubuntu中测试硬件解码能否起作用。本次测试用了三个不同规格的视频，分别为1920*818，1280*544，1920*1080,，视频编码器采用H.264，容器采用Matroska。测试结果如下：

 

视频1（1920*818）：

 

  CPU软件解码：

 GPU硬件解码：      

视频2（1280*544）：

 

CPU软件解码：

GPU硬件解码：

 

视频3（1920*1080）：

CPU软件解码：

GPU硬解解码： 

        前两个视频硬件解码的CPU占用率反而上升，只有最后一个视频的CPU占用率得到了比较明显的降低。询问导师之后明白CPU占用率上升是因为gst-omx的测试环境的问题。解码出来的结果在Video/Graphics memory，本来可以直接输出显示的；但是现在为了gst-omx的测试方便，把帧数据从Video/Graphics memory拷贝回CPU空间，然后显示的时候又拷贝回去；所以大大占用了CPU。至于CPU下降的情况个人认为该视频的分辨率较高因此硬件解码占据了绝对的优势，拷贝数据所使用的CPU就显得不那么明显了。在实际的Chromeos或者Android上，我们并没有使用gst-omx的，所以不存在这个问题。

    以上完成了在ubuntu中利用gst-omx进行视频的硬解播放。项目要求在libyami中加入对MPEG-2的支持。要完成此部分工作需要对视频的编码解码算法有一定的了解。因此，在阅读一些有关视频编码解码算法的文章后作出如下总结：

        以下三幅图分别是MPEG2，H.264以及VC1的解码流程图：

 

        可以看出视频解码过程中都会用到反量化，反变换运动补偿之类的模块，具体实现的方式可能各种视频之间有所差异，下面的表格给出了MPEG-2解码与H.264解码模块之间的对比。

        下图是MPEG-2硬件解码的一个模块。主要分为 8 个模块，读入模块（regdata）、parser 模块、功能控制模块、可变长解码、huffman 模块、反扫描反量化模块、IDCT 模块、运动补偿模块和后处理模块。在看之前的代码的时候看到parser,huffman等名词，应该会用到。

    以上是这个阶段以来完成的任务，下个阶段计划完成MPEG-2的添加，并在Andriod以及Chromeos上成功运行。