0.媒体文件
１．退出机制
＇
2.OMX播放场景的一种组件连接方式：
3.Hisilicon MPP框架设计
4.OMX组件之间的调用关系
5.V4l2 Pipeline实现
同事画的更详细的一幅图：
VIPP四个节点，VINC四个节点，一共八个节点，他们其实可以不用在/dev/目录下创建对应的subdev节点的。分辨的原则是什么呢? 如果用户态需要用对应的节点去做控制或者其它任何事情，则必须暴露节点，如果用户态不需要做这些事情，那还要这些节点做什么呢？
比如，把VIPP和VINC的8个节点做掉，开机发现/dev目录下少了对应的/dev/subdevx。但是实际测试并不影响功能。
1.注册video节点是在vin_cap模块调用registered回调接口中进行。
2.vin_cap可以看成是video节点的内部反射？capture本身就是抓图的意思！
多个PIPE Line可以同时进行数据流动。
同编同解：同时编码，解码，就是VE分时复用或者，如果VPU更加强悍的话，支持硬件级并发，同时有解码和编码的场景应用，比如在播放视频（解码）的同时，后台在跑录制视频（编码）。
Gstreamer和FFMPEG是两款最受欢迎的开源多媒体框架，当然，如果DL,IL,AL都算上的话，OMX也算一个，不过OMX 侧重于硬解，偏向底层一些。
各类device的handler。
从数据结构的角度看Pipeline的连接图:
通过/dev/media0节点，可以获取到这个拓扑连接结构，本质上内核是调用以下几个接口实现的：
6.Gstreamer基本框架
7.FFMPEG多媒体框架
FFMPEG 流媒体Mpeg DASH Server框架设计
8.Gstreamer和OpenMax的相似度
9：一种基于VPU硬件加速的编码解码方案架构：
同编同解，多路编码，多路解码中的资源保护，每个API通过大锁的方式锁住VPU的资源。
10：一种多媒体解码播放器的实现框架：
11：某个用例的顺序图，
Bufferdone用在非Tunner模式给应用发送消息还帧？ XXXThisBuffer用在tunner模式还帧?这一点从callback的类型就可以看出来，EmptyBufferDone 所在的COMP_CALLBACKTYPE仅仅是一个类型，而FillThisBuffer则是一个OMX的一级API，COMP_FillThisBuffer.
12：关于mediacodec和mediaserver是安卓多媒体实现的两种框架，mediaplayer是一个server ,应用是通过binder请求多媒体服务的，这方面，mediacodec也一样，它也是server，应用也是通过binder请求media codec 服务的。mediacodec也有独立的进程，通过binder请求服务。
安卓系统默认的多媒体框架是nuplayer，它用的是软解，所以有研发能力的芯片原厂都会基于自己的VPU开发一套框架，来替换掉安卓原生的框架，对接安卓的播放器接口。
平板上用mediacodec比较多，手机上用mediaserver比较多。厂商也会给予开源框架比如FFMPEG，开发一套独立于上面两套框架的第三套框架，它的目的是为了和方案解耦，不依赖于原厂VPU的特性构建自己的播放器，这种对算力有要求，必须要用强一些的芯片，所以一般再手机上用的比较多，比如bilibili的手机播放器ijkPlayer，就是基于ffmpeg.参考链接：https://blog.csdn.net/xiaweilihai/article/details/107424291
Q1:bilibili有一个播放器叫做ijkplayer, 他是基于ffmpeg开发的，这种路线是否和mediaserver和mediacodec完全没有关系？ 属于独立的第三条技术路线？
{是的，这种就是属于app自己写了一套播放器的架构，跟Android的播放框架没有关联,这种实现都依赖于软解吧，毕竟没有和原厂勾搭，自己搞出来的。对，这种播放器的分辨率一般比较小，用软解的性能是足够的，而且，视频源的制作是网站自己制作，所以可以只实现h264/h265等几种解码器；怪不得,bilibili也做视频网站，自产自销，没啥兼容性问题}
Q2：我知道有一个播放器ijkplayer，是bilibili开发的手机播放器，它是完全基于ffmpeg开发的。是否走这条路子的实现和昨天讲的mediacodec和mediaserver是完全独立，没有关系的？属于第三条技术路线？
{ijkplayer应该也是调用的mediacodec解码吧，如果要使用硬解，目前android平台只有mediaplayer和mediacodec，ffmpeg应该可以通过openmax接口调用到硬解，ijkplayer 硬解是mediacodec}
Q3:ijkplayer有了解过么，它好像JNI之下完全调用FFMPEG的库,基于FFMPEG的话，软解，完全不依赖mediacodec和mediaserver行不通么，但这样是否也有好处，可以不依赖于原厂，各种兼容性问题都可以自己关起门来搞,前提是算力够
{MediaCodec只是干了解码的事情,完全基于FFMPEG性能很差,ffmpeg 在Android平台本来可以跑起来，只有3399这种性能怪兽，才会这么搞，3399或者一些手机厂，CPU比较牛逼的,确实很多都是用软解的,1080P，够了,只是发热比较愁,我们现在的框架都是用mediaserver，mediaplayer，通过ipc，现在都是hidl接口了,hidl是技术性的一个功能吧，本质还是靠binder. mediacodec 有一个独立的server,是的，本质上是binder）
13:多媒体框架的组成部分
