Hi Franck, > Strange thing I have noted with Livecam only is about the raw buffer. > If the size is not exactly 640*480, livecam cannot use mmap(). > I don't undertstand why because mapping is not done with raw > but with the 'bufmem' buffer...
Livecam is able to cope with other resolutions provided that they're managed correctly by the V4L2 api in the driver. > And the image is far from fluid. I get 19 FPS for my Genius Slim 231C (m5603c+mt9v011 based). After tweaking the exposure and some other parameters, I get upto 25 FPS. Just keep in mind that there is an extra copy of the buffer provided by the driver. This is can't be avoided in case of color conversion. There is a method in V4L2 (V4L2_MEMORY_USERPTR mode) that allows the driver to use userspace provided buffers to put the data in. This mode allows for a zero-copy capture (that's if we can avoid the color conversion step) and it's by far the most efficient way to deal w/ the cam. > Does Livecam works for you ??? Oh yeah! > With xawtv it is ok after resizing the screen. This one too, but it suffers a severe bug in the shutdown of the capture. > > Something I don't understand is why there is a distingo > for .PIXEL_FORMAT = V4L2_PIX_FMT_SBGGR8 This is the only way (and flag) I found available to export the raw bayer stream to the userland. > What is the correct place for decoding from one format > to another? Inside the driver!? So why this distinguo? Definitely in userspace. It's not recommended to do it in kernel space since it's not recommended to mess with the floating point registers of a given CPU (linux is supposed to be multi-platform). Color conversion can be (ex, for high resolutions, high capture FPS) a computing intensive process and by do it in the kernel, you risk to delay/disrupt the execution of some other higher priority tasks. Think about interrupts management, kernel threads, DMA, I/O, userspace applications constraints, etc. The driver has just to export the stream as provided by the native capabilities of the cam (if it supports native bayer to RGB color conversion, like the ov sensors, then we're good) and is supposed to be as fast as possible. At some point, I read that the V4L2 project is going to provide a library for decompression and color format conversion, but nothing so far. > Just a tweak for testing in livecam the 'pitch'? The pitch tweak is for the m5602. I couldn't figure out how to read the raw pitch for the m5602 bridge. I don't have the hardware. Now to get back to V4L2, I really don't understand why they did it in the kernel. I dream of a standardized userspace, X11 like, server for video capture, since applications can use libusb to deal w/ USB devices in userland (the same for firewire, for PCI stuff we still have to go through the kernel). I hope the KDE folks will do it since KDE 4 is shaping up to be a killer desktop environment. BR, Ilyes Gouta. > Franck > > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ M560x-driver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/m560x-driver-devel
