View source for Video capture comparison V4L2 versus omx camera

<seo title="Video Capture Comparison V4L2 Versus OMX Camera" titlemode="replace" keywords="GStreamer, Linux SDK, Linux BSP,  Embedded Linux, Device Drivers, Nvidia, Xilinx, TI, NXP, Freescale, Embedded Linux driver development, Linux Software development, Embedded Linux SDK, Embedded Linux Application development, GStreamer Multimedia Framework."  description="When you are creating a video capture product, you can use either V4L2 or OMX camera to get the video frames. Learn which choice is better for your situation today."></seo>

<table>
<tr>
<td><div class="clear; float:right">__TOC__</div></td>
<td valign=top>
{{GStreamer debug}}
</td>
</table>

You are creating a video capture product and you can use either V4L2 or OMX camera to get the video frames.  Which is the best choice?

== V4L2  ==

[https://en.wikipedia.org/wiki/Video4Linux Video4Linux2] or V4L2 is the second version the the Linux kernel video capture and output device API and driver framework.  The most important attribute is V4L2 is not a standard.  The Linux kernel follows the POSIX standard to a very large degree, but POSIX never defined a video API.

== OpenMax OMX camera ==

[https://en.wikipedia.org/wiki/OpenMAX OpenMAX] (Open Media Acceleration) camera, often shortened as "OMX camera", is a non-proprietary and royalty-free cross-platform set of C-language programming interfaces for video capture.

== Video capture on DM81xx ==

The DM81xx architecture includes an array of coprocessors collectively called the [http://omappedia.org/wiki/Ducati_For_Dummies Ducati subsystem].  The coprocessors include two M3s called media controllers which basically performs the capture, resizing and encoding tasks, so those processes are not being handled by the ARM itself.  Instead the ARM sends commands to the media controllers to do different tasks.

The subsystem inside of Ducati that does the capture, resize, color space tasks is called [http://processors.wiki.ti.com/index.php/DM816X_AM389X_VPSS_Video_Driver_User_Guide High Definition Video Processing Subsystem] (HDVPSS).  Depending on the SoC, HDVPSS can capture two video streams at 1080p@60fps. Also it can handle 3 video pipelines simultaneously and 3 graphics pipelines (framebuffer) at the same time.

Like most SoCs with dedicated video acceleration hardware, accessing the hardware is though a proprietary API provide by the SoC vendor.  For TI DM81xx SoCs, this API is Ducati.

When the system boots firmware (provided by TI as pre-compiled binary images) are loaded into the media controllers, so we can take advantage of the Ducati subsytem, i.e, we load one firmware into the the VPSS, one firmware into the media controller of the HDVICP2 (encoders/decoders) and one firmware for the DSP. This loading process takes like one second for all the firmware images. Depending on the video processing functions required, the M3 code may need to be modified.  RidgeRun has the M3 source code and can make enhancements as needed.

All the functions present in the coprocessors are exposed to the ARM through an openMax/syslink shim layer that sits on top of the Ducati API.  This means OMX camera can be used to access the control for the capture, encoding, etc. GStreamer uses that layer in order to take advantage of all the capabilities of the GStreamer framework. The plugin that makes use of the openMax API to capture frames is called omx_camera. There are other GStreamer elements that expose the encoding/decoding functionality, you can run:

 gst-inspect | grep omx

to see a list of them.

TI added another option to access the capture/display functions implemented in the VPSS, this option is through the Linux kernel V4L2 API, which can capture/display frames sending functions through syslink to something called a server proxy that is always running on the M3 side.

For the DM816x, RidgeRun has enabled the dual capture through V4L2 since it is the most common way in Linux to handle capture devices.  TI provided the V4L2 capture driver, but it lacked dual capture support.  RidgeRun has enhanced the offering to include support for dual capture.

The good thing about V4L2 is that it gives you the option to configure your video decoders (ADV7611, TVP5150, etc).  The V4L2 subsystem will call the driver's probe function each time a user space applications opens a video device (/dev/video0 or /dev/video5).  This give the driver ported to your specific hardware the opportunity to configure and initialize your video decoders.

The other option to capture is through openMax, however in this case you would need to initialize your video decoders in some other way (i2c tools maybe) since openMax just tries to get data from the VPSS inputs without initializing any external chip.  Setting hardware registers from a Linux application using direct access to the I2C bus violates the Linux convention that kernel level drivers are used to configure the low level hardware chips.

The latest M3 Ducati firmware provided by TI for V4L2 firmware also supports the OMX capture.

Currently RidgeRun offers software for the Z3 board that has a dual capture patch to enable both video inputs.  This patch removes all the calls to the subdevices so the initialization of the video decoders is done through the script called ./init_7611_edid.sh.  The script programs the ADV7611 and that is why you can capture from HDMI. The [http://developer.ridgerun.com/wiki/index.php?title=SDK_Irazu_for_DM8168_Z3_Board#Add-on_support RidgeRun SDK offers add-ons] to support the ADV7611 and the TVP5150 video capture chips.

[[Category:DM8168]][[Category:DM8148]]