第二周工作报告

第二周工作报告

本周是项目进行的第二周,本周工作包括以下几个部分:

1、之前在家对项目只是做了一个较为简单的了解，本周回到学校后下了一些相关的论文整理了一下思路，并跟导师进行沟通，理清了各个部分之间的关系。

和导师沟通的过程：

我：赵老师，这两天回学校下了点论文看看，整理了一下思路。大致了解到openmax的作用是能够更加方便地适应各种平台。在网上搜到libva是vaapi在linux中的一种实现，我想问一下libva和libyami的区别。

导师：Libva是driver的API，（虽然video driver是在userspace来实现的）。Libyami是middleware的API和实现：libyami使用codecparser分析码流的基本信息（SPS/PPS等等），然后组装成driver（libva）所需要的数据结构；并管理其他编解码逻辑，如参考帧的管理，一些上下文的context。

我:赵老师，您好，又要来打扰您了。上次问了下VAAPI和libyami的区别，感谢老师的回答。今天看到gstreamer-vaapi is a collection of GStreamer plugins and helper libraries that allow hardware accelerated video decoding, encoding and processing through VA-API. 这么一句话。我的理解是gstreamer-vaapi是基于VAAPI的一系列的组件，就是说gstreamer-vaapi可以实现硬件解码的功能。那么为什么不直接将gstreamer用openmax包装起来实现到andriod等平台的移植，而是重新建立libyami的库再用openmax封装？

导师：Gst-omx可以将omx的plugin包装成gstreamer的plugin；从上面这个事实，我们可以知道，从软件stack角度来看，gstreamer是在openmax上面的。Gstreamer的plugin包含了很多omx不需要的东西。如果你看gstreamer-vaapi的code，libyami相当于是他的gst-libs的子目录。进一步剔除了gst/glib的依赖，并使用C++进行了代码优化。

从以上跟导师的交流以及阅读相关的资料后，大致整理项目中涉及到的各个部分之间的关系。

 对于gstreamer多媒体框架在硬件平台上面的适配，目前有两种方法，一种是直接将硬件平台的编解码能力直接编写为gstreamer插件，这也是前期选择的方法;另一种是使用gst-openmax抽象层，使得实现了Openmax-IL接口的硬件平台可以直接使用gstreamer框架（因为众多的android设备都实现了openmax-IL接口，所以gst-openmax可以使得支持了android设备的硬件平台方便地支持gstreamer框架）；

本项目主要研究的是第二种方法，因此设计的libyami可以通过噢penmax进行封装从而适应于不同的平台。其主要的框架图如下(以gstreammer框架为例)：

 

2、由于本项目使用的是linux平台，因此本周回学校后安装了双系统，在windows7的基础上安装ubuntu 14.04。具体细节不再描述。

 

 

3、本项目是针对于硬件加速来说的，因此为了对硬件加速有一个更加直观的了解，本周进行了硬件加速方面的相关测试。采用的vlc播放器，对1080P的视频在软解和硬解下的CPU占用率进行了比较，电脑是双核四线程，所以显示4个CPU。可以明显看到硬解和软解得差别。

 软解：

 

 

 

 硬解：

 

本周主要完成以上一些工作，下周准备对现有代码进行理解加深对项目的看法，并纠正一些可能存在的错误观点。