you are correct that omx and v4l2 sit at different levels one being userside API and other being kernel API.But from the point of view of integrating these API's in OS frameworks like gstreamer,Android camera service they are at the same level.I mean one will have to implement gstreamer source plugin based on either v4l2 or Omx.Also the way vendors(STE and TI) have gone about implementing OMX, they completely bypass v4l2 .The major reason being code sharing among different OS environments.The kernel side for OMX implementation just facilitates RPC between imaging coprocessor and ARM side..

On Tue, Feb 8, 2011 at 2:00 PM, Lee Jones <> wrote:
Bringing in my boys.

Robert, Linus, what say you?

On 07/02/11 12:33, Arnd Bergmann wrote:
> On Monday 07 February 2011, Sachin Gupta wrote:
>>     In Multimedia WG we have been posed with a question regarding best way
>> to expose low level API for this a questions mainly about pros and
>> cons of v4l2 and omx over each other.So to involve a wider community to
>> discuss this topic I am floating this mail on linaro-dev.Please share your
>> view/experiences.Also please involve any body else in this mail who can
>> provide valuable inputs on this.
> I've had to look up with "omx" actually stands for [1][2], but from
> an outsider view, they don't seem to be mutually exclusive or even
> competing interfaces. v4l2 is the interface you use to get at camera
> data, in whatever format the camera gives you. There are no alternatives
> to that. OpenMax gives you a way to accelerate video codecs, which
> is good, but this sits a layer higher up in the stack. Supporting omx
> is probably a good idea, but would be totally optional.
>       Arnd
> [1]
> [2]
> _______________________________________________
> linaro-dev mailing list

linaro-dev mailing list