Hi Mitar, On Sunday 24 October 2010 17:46:28 Mitar wrote: > Hi! > > I can also confirm that Logitech HD Pro Webcam C910 works on Linux. > But I have few (small) issues/quirks. > > The first one is that it seems with HD (1920x1080) field of view is > much much smaller then normally. Probably so that it is possible to > pan/tilt it around for face following on Windows. Maybe this is not > configurable, but maybe this is just default and could be turned-off > somehow? > > Device supports zoom (at least this is what it tells uvc driver) in > range 1-5, but selecting anything except default (1) makes it simply > hangs when you want to do anything with it. Is this a driver issue? > But device still works and you can select back zoom level 1 and it > works normally then.
I'm waiting for an answer from Logitech on those two questions. > The third issue is the most interesting for me. Device supports > 2592x1944 (this seems to be native resolution and 1920x1080 is > achieved by using just a part of that and allowing panning and tilling > with moving the area around). In YUYV format it declares itself to > have 2 FPS, but in practice it is only 1 FPS. I have used example > capture program from V4L documentation to experiment with that. I have > compared time when timestamp is put on the buffer in kernel and when > this buffer arrives into my program. Normally this time is around time > length of one frame (1 / FPS). But in the case of 2592x1944 (and not > for lower resolutions) this time is around second. So 500 ms more than > it is normal with other resolutions and cameras is spend somewhere in > the kernel. As I have been just queuing and dequeuing buffers without > doing any processing on them it seems this is really something > internal. As on this resolution FPS is already very low with YUYV > format it would be really great to get that one frame more in. I don't think that's caused by CPU time being spent in the kernel. The driver timestamps the buffer when the first packet is received. Your application will get the buffer when the last packet is received. If the delay is around 1s, that probably means that the camera only sends one frame per second. One possible reason for that would be auto-exposure. Have you tried disabling auto-exposure and setting the exposure time manually to a low value ? > I use 2.6.36-rc6-amd64 and Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz. > > Otherwise things work as expected. The only thing I noticed is that > with such high resolution and MJPEG encoding decoding time of frames > is quite visible if you want to decode MJPEG on the fly in real-time. > For example, with libv4l decoding of one pixel of MJPEG to BGR24 takes > around 0.025 microseconds on my machine. This is nothing important > with for example 640x480 resolution, it takes around 7680 > microseconds, that is 8 milliseconds. But with 2592x1944 this becomes > around 125 milliseconds. So it is impossible to decode stream n the > fly in real-time with 10 FPS which device supports for this resolution > and MJPEG. > > Has anybody tried to improve MJPEG support in libv4l? For example by > using ffmpeg MJPEG decoder? They argue it has better performance: > > https://roundup.ffmpeg.org/issue1816 You will have to ask that on the linux-media mailing list. I know there was a mail thread about the same topic recently. -- Regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
