Rockchip之linux+OpenCV和Gstreamer

Use OpenCV with Gstreamerdate_range 23/08/2017   visibility Hits: 319info最近在Rockchip Linux的平台尝试了一下OpenCV + Gstreamer的组合, 发现效果还蛮不错的.:)过程中有些心得, 在这里记录一下…. 我想这些也不只适用RockChip平台,因为涉及的都是标准的概念, 比如DMABUF, DRM,OpenCL,G2D…放到像Intel, Nvdia这些平台也是成立的.下面的内容会涉及一些Linux概念, 如果你不懂的话建议先查阅下相关文章, 当然最好是接触下对应的开发:DRMDMABufV4l2OpenCLCode一个简单的人脸识别应用:使用了2D加速, 视频硬解加速gstreamer-opencv

BackgroundGstreamer首先,要先讨论下为什么需要在OpenCV上用上Gstreamer. 比如我直接一个摄像头 v4l2 图像传给 OpenCV不行吗?Gstreamer是嵌入式平台处理Media的首选组件, 像Nvdia/TI/NXP/Rockchip平台,都是使用Gstreamer来整合Media应用. 在Rockchip平台上,我们已经有为Gstreamer开发了像Decode/Encode/ISP-Camera/2D加速器/DRM-Display-sink这些的Plugin.所以OpenCV如果链接上Gstreamer, 输入源就不仅仅是摄像头, 还可以是RTSP/本地视频;输出显示的代码可以不用写,让Gstreamer来显示; 转换格式让Gstreamer来转, 利用硬件加速; 处理的图像送回Gstreamer编码.ARM在ARM系统上做Media的开发, 有一个原则要很重要, 就是 : 避免拷贝.如果你手边正好有一块ARM板子和Linux PC, 可以尝试在上面跑一些memcpy的Test. 一般来说,测试的性能会相差5,6倍. 即时是DDR同频的两个系统, 性能也会差到3-4倍(不过也可能是DDR其他参数有影响?).内存操作速度的劣势是RISC天生的, ARM也不列外. (虽然也没有研究过对应微处理器结构,道听途说 :-P)还有一个更影响速度的就是, 这些Buffer一般都是uncached的DMA Buffer, 为了保证cpu和其他ip的内存一致性,所以CPU读写速度就更慢了..在开发OpenCV + Gstreamer的过程中, 一定要尽量避免拷贝的发生, 如果一定要有, 也不能是由CPU来做.(替代可以是2D加速器, GPU)(当然这里用2D加速拷出来后buffer,默认还是uncached的,还是不适合CPU直接在上面处理,就算改成cache的,cache刷新的时间也要10ms+。。不过如果你的算法需要CPU去实时处理每帧的话,我想一般的ARMCPU都做不到吧)OpenCV我之前只在X86上使用过OpenCV, 其实不太了解OpenCV在ARM Device需要怎么开发.(怀疑其他ARM平台上到底能不能用OpenCV, 因为像TI/NXP这种, CPU/GPU太弱, 估计只能内部的DSP跑算法;像全志, 基本没有Linux平台的组件支持; 唯一能搞的估计也就是Nvdia的terga了, cuda还是厉害. ;) )根据上面ARM的原则, 开发的时候要避免调用到OpenCv的cvtcolor和clone这些函数,因为每次拷贝都会消耗大量的CPU资源.OpenCV也支持OpenCL加速,当然..其实没什么卵用, 尤其你是在处理实时的图像的时候, 因为GPU处理数据的时候, 需要加载Texture到GPU内存上,放OpenCL上, 就是你要处理的帧, 全部要拷一份到新的内存地址上….虽然在嵌入式设备上, GPU并没有和CPU使用分离的内存,完全没必要这么做; 在图形应用的框架上, GPU处理dmabuf都是zero-copy的, 也就是要处理的帧, 只要让GPUMMAP一下就可以了, 而OpenCV, OpenCL,我是没找到方法…(所以GPU通用计算还是要靠Vulkan了..)当然在算法的处理耗时有好几秒的时候, 加载纹理消耗10毫秒也是可以忽视的 : 这种场合才建议使用OpenCL.才发现这个好像是ARM上特有的问题, opencv已经是用了CL_MEM_USE_HOST_PTR,理论上不应该有拷贝. 但是ARM上这个flag却会导致拷贝,ARM上需要使用特殊的api来做zero-copy.嗯…这样你得去修改OpenCV才能用起来…这几天尝试添加了一下异步处理, 这样来看拷贝的耗时反而不重要了, 比如一秒里可能就处理了2,3张图片,拷贝这一帧的30ms,opencl减少耗时500ms。而且拷贝后的buffer是cached的normal内存,cpu处理起来速度会更快. 所以拷贝是不是个问题, 得看相应的应用场景和算法需求.DesginPipelinePipeline Prototype 1:video/rtsp/camera -> decoder -> opencv这是我最先想到的, 通过gstreamer拿到decoder的buffer, 然后全部由opencv来处理. 但是前面说过,要避免拷贝, 而opencv的显示 imshow , 是存在大量拷贝的, 所以不能这么做.Pipeline Prototype 2:video/rtsp/camera -> decoder -> opencv -> display sink为了优化显示, 需要把buffer送回给gstreamer, 这样就得到了Prototype 2. 但是是要注意,OpenCV的默认格式是bgr的, 所有的画图函数都是基于bgr; CV的大部分算法都是都需要预处理成灰度图,而某些图像格式排列不适合转换灰度图.在Rockchip平台上Decoder出来的颜色格式是NV12的, 必须要想办法转换成BGR格式.所以decoder到opencv之间还需要有处理颜色格式的单元, 这个工作不可能由CPU来做, 一般可以使用专有硬件,如果相应的平台没有这样的硬件, 也可以使用GPU用特定的Shader来转(OpenGL的设计目的里, 加速2D就是很重要的一块,我们有时候看到QT/Wayland这些地方说使用到GPU加速, 就是用GPU做这样的事).Pipeline Prototype 3:video/rtsp/camera -> decoder -> 2d convert -> opencv -> display sinkImplement首先opencv在gstreamer是有plugin的, 但是从应用开发的角度, 这样不够flexible :plugin里的东西和外界是封闭的. 在实现上, 更建议使用Appsink和AppSrc, 这些模块, 在你的应用里,是以Thread的形式存在的, 开发起来要更方便.另外还有一点很重要, 就是什么gstreamer, gobject, 其实挺难用, 用C++会舒服很多。代码结构上很简单: Gstreamer AppSink不停的送Buffer, 应用MMap出来给OpenCV处理,完后AppSrc送会Gstreamer显示.Gstreamer Pipeline:video/rtsp/camera ! decoder ! v4l2videoconvert ! appsink appsrc ! displayRockchip Gstreamer Pipeline:"filesrc location=/usr/local/test.mp4 ! qtdemux ! h264parse ! mppvideodec ! v4l2video0convert output-io-mode=dmabuf capture-io-mode=dmabuf ! video/x-raw,format=BGR,width=(int)1920,height=(int)1080 ! appsink caps=video/x-raw,format=BGR name=sink" "appsrc caps=video/x-raw,format=(string)BGR,width=(int)1920,height=(int)1080,framerate=(fraction)30/1 block=true name=src ! rkximagesink sync=false";代码解释这段是核心的代码,是buffer处理过程,见其中的中文注释。void OpenCVStream::Process(){ GstSample* sample; GstMapInfo map; GstStructure* s; GstBuffer* buffer; GstCaps* caps; GstMemory* mem; int height, width, size; int fd; void* map_data; while (is_streaming__) { if (sink_pipeline__->GetIsNewFrameAvailable()) { sink_pipeline__->GetLatestSample(&sample); # 这里都是为了拿到buffer caps = gst_sample_get_caps(sample); buffer = gst_sample_get_buffer(sample); s = gst_caps_get_structure(caps, 0); gst_structure_get_int(s, "height", &height); gst_structure_get_int(s, "width", &width); size = gst_buffer_get_size(buffer); mem = gst_buffer_peek_memory(buffer, 0); # 注意这里拿到dmabuf的fd啦!!!!!很重要 fd = gst_dmabuf_memory_get_fd(mem); # 为什么不直接用gstreamer里已经mmap过的地址?因为gstreamer有权限问题,有可能mmap成只读的了 # 这里拿到buffer可读的地址了!!!!!!!fd就是这么转vaddr的 map_data = mmap64(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); std::list::iterator itor = effect_lists.begin(); while (itor != effect_lists.end()) { # 因为用了RGA,视频解码后的nv12已经变成rgb的了,你也可以不用rga,那opencv里就要当nv12处理 (*itor)->Process((void*)map_data, width, height); itor++; } munmap(map_data, size); # refcount加一,appsource pipeline的过程处理完了,他会减一 gst_buffer_ref(buffer); src_pipeline__->SendBUF(buffer); sink_pipeline__->ReleaseFrameBuffer(); } }}

(0)

相关推荐