Gst-1.0 v4l2src in DM81xx

Introduction

RidgeRun has developed the necessary patches to use v4l2src with the gstreamer 1.6 version in the DM8148 and DM8168 platforms. This is important because allows to developers create useful applications which include video capture using a known framework as v4l2. The functionality of the plugin is close to OMX, because it has the function of provide the required contiguous memory to v4l2 in order to fill the buffers correctly with the frames captured. You could find the patches in the RidgeRun github repository https://github.com/RidgeRun/gst-omx/tree/ti-dm81xx and test it by your own.

The patches created are 3, and they have different functions:

   001-adding-userptr-memory-method : This patch create a method
      to use Userptr memory by using GstBuffers allocated by the
      omxbufferalloc. The buffers created by the omxbufferpool are
      filled by v4l2 and sent downstream.

With this first patch we create the UserPtr memory method to use by the v4l2src plugin, instead of use MMAP memory method, because this platforms don't have support for MMAP. This patch disable the allocator probe and the device polling, because they leave the device busy and we get an error. Also, since we use omxbufferalloc to allocate the used buffers, we have to configure the v4l2srcpool to use the pool and the buffers created by OMX.

   002-adding-stride-to-pixel-format : This patch avoid a Division
      by zero in kernel caused by the stride was not set in
      the pixel format of the frame.

Without this second patch we get a problem in the kernel due to the plugin doesn't set the stride or bytesperline of the pixel format which is passed to the driver.

   003-adding-queue-size-property-v4l2src : This patch enables
      control the size of the v4l2 queue to pass to the driver.

And the last patch create a property to control the size of the v4l2 queue in order to avoid the set of the minimum queue size of 2 buffers, which produce a low framerate.

With this 3 patches we are able to configure and use v4l2src in any application.

Testing v4l2src

The plugin has passed by several tests to make sure that it is working how it should. We provide to you some example pipelines to check its functionality.

Note 1: In all the tests you have to configure the caps with the resolution and framerate of your video source.

Note 2: Also you have to configure the video input in your board, /dev/video0 is set by default.

Note 3: Its important consider the memory management method supported is USERPTR and its represented by the number 3 in the io-mode property, so that this property has to be set always.

First a basic pipeline:

gst-launch-1.0 v4l2src io-mode=3 device=/dev/video0 ! 'video/x-raw,format=(string)NV12,width=1280,height=720,framerate=(fraction)60/1' ! perf print-arm-load=true ! omxbufferalloc num-buffers=12 \
! fakesink

We can record an mp4 file:

gst-launch-1.0 v4l2src io-mode=3 device=/dev/video0 num-buffers=1000 ! 'video/x-raw,format=(string)NV12,width=1280,height=720,framerate=(fraction)60/1' ! perf print-arm-load=true ! \
omxbufferalloc num-buffers=12 -v ! omxh264enc i-period=30 idr-period=30 ! queue ! rrh264parser single-nalu=true ! mp4mux dts-method=0 ! filesink location=test_v4l2src_1.0.mp4

And we could get a streaming in a host machine:

• Server: DM81xx

Set the variables HOST and PORT to your own, for example:

HOST=10.251.101.43
PORT=3001

And run the pipeline:

gst-launch-1.0 v4l2src io-mode=3 device=/dev/video0 ! 'video/x-raw,format =(string)NV12,width=1280,height=720,framerate=(fraction)60/1' ! perf print-arm-load=true ! omxbufferalloc num-buffers=12 ! \
omxh264enc i-period=30 idr-period=30 ! mpegtsmux ! udpsink host=$HOST port=$PORT sync=false async=false

• Client: Ubuntu PC

Set the same port configured in the server:

PORT=3001

And run the pipeline:

gst-launch-1.0 udpsrc port=$PORT ! tsdemux ! h264parse ! avdec_h264 ! xvimagesink sync=false async=false