【 声明:版权所有,欢迎转载,请勿用于商业用途。 联系信箱:feixiaoxing @163.com】
对于芯片厂商来说,肯定希望客户的应用和自己的芯片绑定地越紧密越好。最好就是,他们自己成为客户的独家供应商。但是对于嵌入式开发的厂家来说,通常都会希望自己至少有两家以上的soc供应商可以选择,这样才不会被某一家捆绑住。毕竟,一旦自己的供应商是可以替换和选择的话,那么在后续的议价环节,会占据很大的优势。IPCam Soc竞争非常充分,非常适合用来做嵌入式产品。因此,那么从嵌入式Linux上位机开发的而角度来说,怎么做才能实现自由选择soc的目的呢?
1、提炼通用API接口
对于IPCam soc来说,一般都会提供MPP开发平台。对于那些不提供MPP平台的soc,也会提供类似的API给客户。所以,对于上层开发的同学来说,一定要构建一个抽象的通用API。比如说,common_vi,common_vo,common_isp,common_venc,common_vdec,common_ai,common_ao,common_aenc,common_adec,common_npu等等。在某一个结构里面,再去进行设计,比如common_vi,
typedef struct _Common_Vi
{
U8 devName[32];
U8 devId;
U8 devType[32];
U32 width;
U32 height;
U32 frameRate;
U32 dataType;
U32 isColor;
U8* pData;
U32 dataLength;
VOID* pVoid;
}Common_Vi;
这里的属性都比较好理解,从上到下依次是设备名称、设备编号、设备类型、宽度、高度、帧率、数据类型、是否为彩色、图像指针、数据长度。最后一个是pVoid,这个变量就比较有意思,它就是所有soc vi属性的基类。我们需要准备这样的一个基类,每个soc来实现基类的接口即可。这样就可以达到抽象接口的目的。通用api尽量是c语言,但是里面的VOID*可以是c++实现。
2、移植FFmpeg
soc里面的编解码,一般都是针对于h264、h265文件。这些文件又包含在mp4里面。因此,如果需要保存为mp4文件,或者从mp4文件提取h264文件,通常都要移植一下ffmpeg。虽然ffmpeg内部也有h264的编解码功能,但还是赶不上硬解码的性能,所以从实用的角度出发,一般都要替换成硬解码。嵌入式芯片的cpu和pc相比较,如果不替换成硬件加速模块,单靠cpu本身,效果一般都不好。
有了通用接口之后,ffmpeg做加速的时候,只需要调用通用接口即可。这样就可以实现ffmpeg和具体soc的解耦,后续即使替换了soc,也问题不大。
3、Qt & Boost
对于嵌入式Linux来说,用Qt做图形界面基本上是标配。不管是工业领域,还是医疗领域,用Qt做界面都很方便。本身Qt开发在windows上就非常方便,所以如果使用Qt+boost库进行功能开发,本身不需要做多大的修改,就可以port到嵌入式芯片上面。
4、使用OpenCV
在图像领域,OpenCV是标配,很多的算法,并不需要我们进行二次开发。所以,如果是用到一些简单的功能,直接移植OpenCV到嵌入式系统上即可。对于那些有性能要求的api,一般还是需要进行二次优化处理的,比如汇编加速,这样效果会好一点。
5、AI module
现在很多嵌入式soc都带有npu。如果我们不想依赖于任何一家的soc,那么就需要自己把module翻译成各个soc厂家可以识别的文件形式,再通过API把模型加载到npu上。常见的网络有Resnet、MobileNet、Yolo,它们都可以这么来处理。
6、RTSP等网络协议
网络协议这部分,都是软件来实现的,很少做成硬件加速。所以不管是哪一个soc,都需要自己移植开源代码来完成。比如利用live555实现rtsp协议等等。其他类似的协议还有RTP、RTMP、ONVIF等等。
7、业务代码
业务代码部分,就和具体的产品相关。这里面不光有硬件,还有软件。比如说使用到的按钮、对外接口、是否需要屏幕、u盘保存等等。软件部分的话,就涉及到产品所属行业、业务流程、操作人员的习惯、界面的布局、通讯协议等等。这方面不同的产品又不同的需求,具体情况具体分析即可。