Lukáš Karas wrote:
Erm, I've successfully tested skype with the new gspca and libv4l with various webcams, that works fine without any if your hacks. Perhaps it would help if you would explain what you are seeing, what cam you are using and if you could attach a libv4l logfile of this.
To make a log file (with an unpatched libv4l please) do: LIBV4L2_LOG_FILENAME=/tmp/log skype
And then try to use the cam in skype, after exiting skype again attach /tmp/log.
Regards,
Hans
Ok, of course. I have kernel 2.6.27-rc8, architecture x86_64, newest gspca_m5602 driver, Skype version 2.0.0.27 and 2.0.0.72. My camera id is 0402:5602 (lsusb).
Own driver support only BA81 pixelformat with resolution 640x480.
Ah only a resolution of 640x480, yes that will make skype unhappy, I'm amazed it does work with your, return -EINVAL when we do not support the pixelformat, workaround.
Is skype showing the whole picture, or only the upper left corner of the picture with your workaround ?
Anyways attached is a patch which will work around this in a different (IMHO less ugly) way. It actually removes a number of lines of code.
Can you give this one a try please. Note with this patch skype will only show the middle 320x240 of the webcam picture.
This could be fixed by checking if dest_width < 2 * src_width in v4lconvert_crop() from libv4lconvert/crop.c
And if this is the case call special (to be written) versions of v4lconvert_crop_rgbbgr24() v4lconvert_crop_yuv420(). I would be very happy to take a patch doing this!
Regards,
Hans
p.s.
I'm really sorry I'm being a PITA with regards to taking patches, it is just that having a lib sitting between v4l-apps and devices open ups lots of posibilities and everyone seems to want to put everything including the kitchensync into libv4l. This was not how libv4l was envisioned at first, I'm fine with expanding what it does, but I want to be a bit careful as to not turn it into a big pile of spaghetti.
I'll make some time the next couple of days to take a look at your whitebalance patches and write a proposal for a kernel driver <-> userspace API for finding out if a cam needs software whitebalancing or not (I don't want to add it unconditionally to all v4l devices).
diff -r 7415d367a87a v4l2-apps/lib/libv4l/libv4lconvert/libv4lconvert.c --- a/v4l2-apps/lib/libv4l/libv4lconvert/libv4lconvert.c Tue Nov 04 10:33:55 2008 +0100 +++ b/v4l2-apps/lib/libv4l/libv4lconvert/libv4lconvert.c Wed Nov 12 09:59:01 2008 +0100 @@ -268,29 +268,26 @@ return result; }
- /* In case of a non exact resolution match, see if this is a resolution we - can support by cropping a slightly larger resolution to give the app - exactly what it asked for */ + /* In case of a non exact resolution match, see if this is a well known + resolution some apps are hardcoded too and try to give the app what it + asked for by cropping a larger resolution */ if (try_dest.fmt.pix.width != desired_width || try_dest.fmt.pix.height != desired_height) { for (i = 0; i < ARRAY_SIZE(v4lconvert_crop_res); i++) { if (v4lconvert_crop_res[i][0] == desired_width && v4lconvert_crop_res[i][1] == desired_height) { - struct v4l2_format try2_dest, try2_src; + struct v4l2_format try2_src, try2_dest = *dest_fmt; + /* Note these are chosen so that cropping to vga res just works for vv6410 sensor cams, which have 356x292 and 180x148 */ - unsigned int max_width = desired_width * 113 / 100; - unsigned int max_height = desired_height * 124 / 100; - - try2_dest = *dest_fmt; - try2_dest.fmt.pix.width = max_width; - try2_dest.fmt.pix.height = max_height; + try2_dest.fmt.pix.width = desired_width * 113 / 100; + try2_dest.fmt.pix.height = desired_height * 124 / 100; result = v4lconvert_do_try_format(data, &try2_dest, &try2_src); if (result == 0 && try2_dest.fmt.pix.width >= desired_width && - try2_dest.fmt.pix.width <= max_width && + try2_dest.fmt.pix.width <= 2 * desired_width && try2_dest.fmt.pix.height >= desired_height && - try2_dest.fmt.pix.height <= max_height) { + try2_dest.fmt.pix.height <= 2 * desired_height) { /* Success! */ try2_dest.fmt.pix.width = desired_width; try2_dest.fmt.pix.height = desired_height;
Dne Wednesday 12 of November 2008 10:52:35 jste napsal(a):
Lukáš Karas wrote:
Erm, I've successfully tested skype with the new gspca and libv4l with various webcams, that works fine without any if your hacks. Perhaps it would help if you would explain what you are seeing, what cam you are using and if you could attach a libv4l logfile of this.
To make a log file (with an unpatched libv4l please) do: LIBV4L2_LOG_FILENAME=/tmp/log skype
And then try to use the cam in skype, after exiting skype again attach /tmp/log.
Regards,
Hans
Ok, of course. I have kernel 2.6.27-rc8, architecture x86_64, newest gspca_m5602 driver, Skype version 2.0.0.27 and 2.0.0.72. My camera id is 0402:5602 (lsusb).
Own driver support only BA81 pixelformat with resolution 640x480.
Hi Hans Sorry for late answer.
Ah only a resolution of 640x480, yes that will make skype unhappy, I'm amazed it does work with your, return -EINVAL when we do not support the pixelformat, workaround.
Is skype showing the whole picture, or only the upper left corner of the picture with your workaround ?
Yes, Skype show whole image with my workaround. By the way, I tried which all formats request Skype, when result is always -1. Log from this test is attached.
Anyways attached is a patch which will work around this in a different (IMHO less ugly) way. It actually removes a number of lines of code.
Can you give this one a try please. Note with this patch skype will only show the middle 320x240 of the webcam picture.
Ok, this work fine! It dosn't solve Skype S_FMT bug, only add support for first requesting format... but yes, it is solution :)
This could be fixed by checking if dest_width < 2 * src_width in v4lconvert_crop() from libv4lconvert/crop.c
And if this is the case call special (to be written) versions of v4lconvert_crop_rgbbgr24() v4lconvert_crop_yuv420(). I would be very happy to take a patch doing this!
I will make all, what you want :)
See crop.patch ... Function v4lconvert_reduceandcrop_yuv420 work fine, v4lconvert_reduceandcrop_rgbbgr24 is untested!
Regards, Lukas
Lukáš Karas wrote:
Dne Wednesday 12 of November 2008 10:52:35 jste napsal(a):
And if this is the case call special (to be written) versions of v4lconvert_crop_rgbbgr24() v4lconvert_crop_yuv420(). I would be very happy to take a patch doing this!
I will make all, what you want :)
See crop.patch ... Function v4lconvert_reduceandcrop_yuv420 work fine, v4lconvert_reduceandcrop_rgbbgr24 is untested!
Thanks,
From the changelog for libv4l 0.5.4, which I will release soon: libv4l-0.5.4 ------------ * Don't report DQBUF errors when errno is EAGAIN, this fixes flooding the screen with errors when applications use non blocking mode * Add support for downscaling to make apps which want low resolutions (skype, spcaview) happy when used with cams which can only do high resolutions (by Lukáš Karas lukas.karas@centrum.cz).
Regards,
Hans
p.s.
There was a small bug in your patch you tested for src_width <= 2 * dest_width, but that should ofcourse be >= 2 * dest_width (and the same for height).
But review catched that, that is why review is good :)