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 ... >> For higher pixels counts extra memcpy's >> are scary, especially if they are no visible. Sorry for the naive >> question, but what is libv4l role regarding buffer allocations? >> >> In ourcase we don't need any extra format conversion from libv4l. I am >> fine if it works without extra memcpy in that case and I understand that >> it would be tricky to support inplace formats conversions for some >> formats and extra memcpy for the rest. >>> I would be willing to take *clean, non invasive* patches to libv4l >>> to add >>> userptr support, but I'm not sure if this can be done in a clean way >>> (haven't >>> tried). >> Where are the libv4l sources hosted. I found your blog and the freshmeat >> page only so far. > > The sources are part of the v4l-dvb mercurial tree. But the latest > version is in my personal tree, please use that to base patches on: > http://linuxtv.org/hg/~hgoede/libv4l Don't count on it. I am quite busy in my current projects :/ Stefan
> > Regards, > > Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
