常见的几种多媒体设计框架

1.基于FFMPEG的多媒体框架

场景1，基于FFMPEG Hardware Codec的多媒体Playback框架。

这种框架的好处以及需要做的工作:

1.可以有效利用硬件加速单元进行解码加速。

2.默认的FFMPEG使用软件解码器，这种方式需要将硬件解码器集成到FFMPEG Framework中，以便在利用FFMPEG友好生态的同时，又能充分利用硬件资源提供的加速性能.

3.HW Codecs使用可以有效降低CPU负荷，同时，可以有效复用基于FFMPEG框架的原有应用。

场景2：

使用VAAPI加速可以有效利用GPU加速，有现成的libVA开源代码可以使用，FFMPG可以使用VAAPI与硬件进行交互.

场景3:FFMPEG作为Gstreamer的一个插件运行。

需要将FFMPG封装为 Gstreamer Plugin的形式，集成到Gstreamer 框架中，基于gst开发的多媒体播放器可以有效利用FFMPEG的解码资源进行解码.

3.综合以上场景，典型的同编同解场景的框架如下：

将OMX嫁接到gstreamer上是什么样的效果?

内核态demuxer和muxer弃之不用。

计算多媒体

VAAPI callstack

SUPA BEBR框架

GPU上百路视频的并行解码

8路一个QUEUE，对应一个硬件HCQD，32 个QUEUE理论并行解码数量为256路。

1.每个cluster 1个event id.

2.16个codec，每个codec job done之后都会触发中断，但是只有属于同一个cluster 的所有codec都完成后才会发送MSI事件。

3.每个codec的中断状态都会被立刻清除，不会对发生中断的具体codec中断的原因寄存器status做任何解释，而是将其返回给IB BUFFER 由应用做解释。

4.VE有强制返回寄存器状态的需求，因为应用层驱动需要这些寄存器信息进行码率控制。但是VD不需要，根据debug条件打开。

5.每8路用一个HCQD，32个HCQD可同时解码256路。

6.同一时刻必然活跃着1个在奇PIPE上工作的HCQD和一个在偶PIPE上工作的HCQD，各有两个PACKET在执行（不算DUMMY），16个decoder满载。

7.每个querytask &disptach task对占用一个HCQD，负责对8路进行解码，同一个PIPE上不同的QUEUE（HCQD）按顺序执行。

8.每个PIPE上使用的CODEC应该是事先分好的，奇偶PIPE互补，平分16个codec，但是在每个PIPE上的HCQD是共同用一组deocder,需要按顺序提交执行。

Video Command Queue原理

可以单进程分配也可以多进程，无论那种情况下，KMD都是按照PIPE先分，分完一个PIPE上的再分下一个的。

云计算转码中的应用

在XINLINX官网(已被AMD收购），介绍了使用FFMPEG和GST框架进行实时转码的应用案例

视频和图像

Melis3.0 CedarX

结束！