Re: [M560x-driver-devel] about buffers

[Ilyes G. <ily...@gm...>]

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
> 
> 
>