I don't get removed from this list .... (web interface I tried many times but I keep receiving) Can someone remove me ?
Ilyes Gouta schreef: > 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 > > ------------------------------------------------------------------------- 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
