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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
