Testing IM Live Support

• mplayer: Works well, green color gamma.
• vlc: Works well, green color gamma.
• ekiga: Works well, green color gamma.

• mplayer: 15% CPU (AMD64 X2 5600+); visible latency; natural colors and good quality over all (with a bit of noise)
• vlc: 20% CPU; high latency; good colors but picture is grainy
• kdetv: 20%; not working (kdetv issue?): after fight with preferences of v4l plugin I get only strange stripes in parted picture
• skype: 8-11% CPU; low latency; good colors but even in small picture there is some noise; quality of picture during talk is far worser: details are strangely blurred (BTW, now I didn't even had to patch driver to have it working with skype)
• kopete: 6-10% CPU; low (but still visible) latency; good colors and quality

The picture may be a little bit blue and/or green. The automatic brightness adapter is very slow. Also the framerate and the picture quality is lower as with the Windows driver. But overall it is usable. Added also the skype workaround patch ([1]) and Skype works now with the cam.

Tested with 3.2GHz Intel P4 HT. Programs used: 1) vlc: 13% CPU 0.3 sec. latency; 2) camstream: 12% CPU NO latency.

The module is loaded without errors, but I can only see a totally blak screen or, forcing the palette to 13, a totally green screen from the webcam... tell me if there is something more I can do to give more feedback.

Good image quality, minimal lag, 20% CPU on a 3GHz pentium 4

Great image quality. This camera and the attached Windows USB captures attached are the originals used when Romain was getting this driver to work.

No extra parameters for module, AMD Athlon XP 2500+ (Barton)

• mplayer: CPU load: ~30%, noticeable latency, good colors, good quality but a bit noisy
• xawtv: 30 % CPU, no latency, good colors and quality but a bit noisy, can't resize (picture going black)
• kdetv: 30% CPU, no latency, good colors and quality, a bit noisy, can't resize (picture changes colors and deforms). I had to set brightness and so on to correct values. Quality is even better with post processing: no noise
• vlc: 20% CPU, high latency, good colors and quality but noisy, some problems with sound and recording (probably only vlc issues)
• ekiga 30% CPU, no latency, good quality

sometimes picture changes colors with every restart of one of them (not to green but colors are different)... keep that good work

Good quality image, seems as good as with Windows. I can also notice a small latency: 0,5 sec with VLC, 0,2 with Mplayer and almost nothing with aMSN. But there is also a very small latency with MSN and Windows so I guess there is not much to do about that. CPU Load (Core 2 Duo E6600): VLC: 20 %, Mplayer 15%, aMSN/Ekiga 10%

The load has dropped by almost one half from 50-60% to 30-40%! The rest seems to be the same.

Works under all of VLC, MPlayer and Ekiga. Relatively good image. Higher latency under VLC (around 1 second), less under MPlayer (around .5 second) and effectively no latency under Ekiga (which is the most important I would say). High load under all of these applications (around 50-60% of one CPU). If dumpjpeg=1 is used, load drops down to ~4% in these applications (of course they provide only green picture then, however getjpeg works fine). The mic seems to be working too although not very good quality (can be HW issue rather than SW issue though). All together - thank you for great work!!! EDIT: another small shortcoming: there is no special device created for mic (although seems to work with v4l driver) which makes it impossible to be used by voip programs such as Ekiga

No unknown issue so far..

• Vlc: good quality image (too much contrast though), heavy load (~50%), noticeable latency plus strong annoying wave noise coming from my audio device (probably unrelated to the driver).
• Mplayer: perfectly viewable image but strangely coloured, heavy load (~50% CPU), noticeable latency.
• Camorama: The image is B&W, horizontally replicated three times (strange), heavy load but surprisingly no latency.

Note: In all the three cases above I keep geting "Error decompressing frame" errors. See a sample driver-loading and video-playing-session log (debug=5) here

mplayer : 30% CPU. Image : good overal quality (not as good as on Windows => too much noise and constrast)

Mplayer: high quality image, but red and blue channels appear to be reversed - a bright red cushion appears blue, and the brown ubuntu background looks closer to light blue-green, slight lag (<<1s). 20% CPU (Celeron 2.6GHz) Kopete: green image (almost certainly due to kopete trying to force the display to 320x240).

Edited to add: changing the sensor_get_hue function to use OV7670_REG_RED instead of OV7670_REG_BLUE fixes the display issue in mplayer. With this change, Mplayer now has near perfect image quality.

Edited (2) to add: hardcoding the sensor to QVGA format output for kopete leads to the classic "green-luminance channel at top of image, green random noise below", which makes me think that kopete just doesn't understand the image format it's been sent. (The hardcoded image works perfectly at 320x240 in mplayer, with about 16% CPU)

Edited (3) to add: hardcoded QVGA kernel module works perfectly in aMSN, confirming that the issue is with kopete, not with the driver. It is possible that kopete requires v4l2 support in the driver, according to some sources, or that it tries to set non-standard resolutions.