Re: webcam drivers and V4L2_MEMORY_USERPTR support

[Hans de Goede <hdegoede@redhat.com>]

Hi all,

On 06/08/2009 10:58 AM, Stefan Kost wrote:
> Hans de Goede schrieb:
>>
>> On 06/05/2009 09:43 AM, Stefan Kost wrote:
>>> Hans de Goede schrieb:
>>>> On 06/01/2009 09:58 AM, Trent Piepho wrote:
>>>>> On Mon, 1 Jun 2009, Stefan Kost wrote:
>>>>>> I have implemented support for V4L2_MEMORY_USERPTR buffers in
>>>>>> gstreamers
>>>>>> v4l2src [1]. This allows to request shared memory buffers from
>>>>>> xvideo,
>>>>>> capture into those and therefore save a memcpy. This works great with
>>>>>> the v4l2 driver on our embedded device.
>>>>>>
>>>>>> When I was testing this on my desktop, I noticed that almost no
>>>>>> driver
>>>>>> seems to support it.
>>>>>> I tested zc0301 and uvcvideo, but also grepped the kernel driver
>>>>>> sources. It seems that gspca might support it, but I ave not
>>>>>> confirmed
>>>>>> it. Is there a technical reason for it, or is it simply not
>>>>>> implemented?
>>>>> userptr support is relatively new and so it has less support,
>>>>> especially
>>>>> with driver that pre-date it.  Maybe USB cams use a compressed format
>>>>> and
>>>>> so userptr with xvideo would not work anyway since xv won't support
>>>>> the
>>>>> camera's native format.  It certainly could be done for bt8xx, cx88,
>>>>> saa7134, etc.
>>>> Even in the webcam with custom compressed format case, userptr support
>>>> could
>>>> be useful to safe a memcpy, as libv4l currently fakes mmap buffers, so
>>>> what
>>>> happens  is:
>>>>
>>>> cam>direct transfer>   mmap buffer>libv4l format conversion>   fake mmap
>>>> buffer
>>>>> application-memcpy>   dest buffer
>>>> So if libv4l would support userptr's (which it currently does not
>>>> do) we
>>>> could still safe a memcpy here.
>>> Do you mean that if a driver supports userptr and one uses libv4l
>>> instead of the direct ioctl, there is a regression and the app iuppo
>>> getting told only mmap works?
>> Yes, this was done this way for simplicity's sake (libv4l2 is complex
>> enough at is). At the time this decision was made it was an easy one to
>> make as userptr support mostly was (and I believe still is) a paper
>> excercise. Iow no applications and almost no drivers support it. If
>> more applications start supporting it, support can and should be
>> added to libv4l2. But this will be tricky.
> E.g. omap2 v4l2 drivers (e.g. used in Nokia N800/N810) support it and
> the new drivers fro omap3 will do the same. I probably need to revert
> the libv4l usage in gstreamer than as we can have regressions in
> applications ...

Erm the current (0.10.15) gstreamer libv4l2 plugin does not even use
USERPTR support (which confirms my I didn't implement it because
nothing uses it reasoning), so there can be no regression.

Now not using libv4l will make gstreamer applications not work with
*hundreds* of different webcam models (and that is not an exageration),
see:
http://moinejf.free.fr/webcam.html

For an incomplete list, now some there may work without libv4l, but most
don't.

So given as a choice:
* not having a performance enhancement, which was never present before
   so no regression
* not working with *hundreds* of different webcam models

Which one are you going to choose ? I will most certainly know
where to redirect the bug reports.

Regards,

Hans