【 声明:版权所有,欢迎转载,请勿用于商业用途。 联系信箱:feixiaoxing @163.com】
所谓的mpp开发,其实就是多媒体平台开发。一般来说,如果cpu性能足够强,其实要不要mpp,关系不大。只不过对于大部分嵌入式soc来说,cpu资源一般都不富裕,客户对soc的成本又比较在意,甚至内存都是sip内置的,这种情况能够做成硬件加速的部分,尽量用硬件完成。当然,mpp还是有它自己的一些特点的。
1、单独的内存管理
这里单独内存的意思,是说mpp的内存和linux kernel的内存一般是分开来的。假设物理ddr的大小是128MB,那么通常会按照2:1,或者是3:2的方式去安排mpp buf的大小。以2:1为例,有可能kernel是80M,mpp使用48M这样。这48M对于linux kernel来说,是完全不可见的。
2、模块bind和unbind
所谓的模块bind,就是说我们配置好模块之后,将他们bind的情况下,两者就可以直接进行数据交换了。比如说,vi-》vo,这就是camera in,yuv out;如果是mjpg解码,那就是vi-》vdec-》vo,中间多一个解码环节。
音频也是一样,比如ai-》aenc,这就是音频采样;反之,file-》demux-》adec-》ao,这就是mp3解码播放。一开始的时候,大家肯能不习惯bind和unbind,等到后期使用熟练之后,就会发现这个逻辑还是挺好用的。
3、mpp同时提供kernel驱动和user lib接口
所谓的kernel驱动,在linux上面表现为ko文件,这部分只有驱动,没有文档,也没有代码。而user lib,也就是如何使用这些驱动,有文档,有sample code,但是没有实现code,有头文件和动态库。这些就是mpp的全部。
4、mpp不一定全都是硬件加速
相比较mcu而言,soc更擅长处理音视频。这里面除了cpu更强一点之外,就是在于soc具有很好的硬件加速功能。所有的硬件加速里面,尤其是图像isp、视频编码、视频解码最为普遍。但是除此之外的其他api,并不一定全部都是硬件加速,虽然它们也有可能提供一些接口。比如说音频,音频的输入、输出、编码和解码。因为相比较视频而言,音频的数据量要少,编码解码的计算量和视频相比较,完全不在一个level。
以视频为例,哪怕是200w像素的1080p图像,1秒钟30个frame,那么1920*1080*3*30,这样下来等于说1秒差不多有180MB数据要处理,对cpu是不小的负担,这还不包括编解码的计算量。与此相比较,音频采样低很多,从降低成本角度来说,很多就变成了软件编解码,只是最终也集成在mpp里面。
5、被忽视的isp处理接口
isp非常重要,也就是原生的camera图像,对于后期的图像处理甚至起着关键性的作用。就个人实践而言,好的图像,其重要性要比好的算法更加重要,特别是自然环境下面。mpp里面,有的soc是带有isp处理模块的,有的则没有,我们学习的时候要提前判断和分辨一下。
当然,如果人不多的情况下,直接用usb camera也可以,只是如果有可能的话,还是要把soc的isp尽可能用起来。
6、视频分层输出
之前谈到的视频分层输出,也是mpp提倡的概念。一般输出会有两层,一层是ui层,专门处理qt、lvgl这些图形界面,用作交互使用,还有一层就是视频流层,这一层就是直接camera in,image out,不需要借助于qt、lvgl进行输出。相对而言,这样处理的效率高很多。
7、mpp和开源库要结合使用
mpp是soc特定的处理库,我们开发软件的时候一般还有自己习惯使用的多媒体处理库,这个时候就可以将mpp和开源库结合使用。比如说,大家都知道ffmpeg是音视频处理的基本库,但是怎么把ffmpeg和mpp加速结合起来,比如编解码,就要看各个方案商自己的能力水平了。
8、网络和ai
音视频的处理只是基础,未来的趋势是网络和ai。这里的网络不仅仅是rtsp、rtp,还有可能是其他协议。传统的rtsp,只是说把h264文件送出去。但是现在手机、汽车、安防、消费电子,除了要求画质质量、无线传输,还要求低延时,这也是我们需要努力的一个方向。对于视频流或者文件的demux处理,硬件加速或许会做一点,但是网络部分,一般还是纯软件完成的。
另外就是ai,这部分毋庸讳言,就是现在应用越来越广的领域,不管是手机、人脸、宠物、汽车、安防、医疗,每一个子领域都有很大的应用市场,大家一定要学会拓宽自己的眼界,不仅仅把眼光停留在mpp和安防这个上面。