Re: libv4l release: 0.5.97: the whitebalance release!
On 04/20/2009 06:43 AM, Erik Andrén wrote: Hans de Goede wrote: On 04/19/2009 09:20 PM, Erik Andrén wrote: 2009/4/19 Hans de Goedehdego...@redhat.com: On 04/18/2009 04:40 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/17/2009 09:27 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/16/2009 10:46 PM, Adam Baker wrote: On Thursday 16 Apr 2009, Hans de Goede wrote: On 04/16/2009 12:26 AM, Adam Baker wrote: On Wednesday 15 Apr 2009, Hans de Goede wrote: Currently only whitebalancing is enabled and only on Pixarts (pac) webcams (which benefit tremendously from this). To test this with other webcams (after instaling this release) do: export LIBV4LCONTROL_CONTROLS=15 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp Strangely while those instructions give me a whitebalance control for the sq905 based camera I can't get it to appear for a pac207 based camera regardless of whether LIBV4LCONTROL_CONTROLS is set. Thats weird, there is a small bug in the handling of pac207 cams with usb id 093a:2476 causing libv4l to not automatically enable whitebalancing (and the control) for cams with that id, but if you have LIBV4LCONTROL_CONTROLS set (exported!) both when loading v4l2ucp (you must preload v4l2convert.so!) and when loading your viewer, then it should work. I've tested it by plugging in the sq905 camera, verifying the whitebablance control is present and working, unplugging the sq905 and plugging in the pac207 and using up arrow to restart v4l2ucp and svv so I think I've eliminated most finger trouble possibilities. The pac207 is id 093a:2460 so not the problem id. I'll have to investigate more thoroughly later. Does the pac207 perhaps have a / in its card string (see v4l-info output) ? if so try out this patch: http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a I have the same issue as Adam when trying to test this with my gspca_stv06xx based Quickcam Web camera i. e no whitebalancing controls show up. I'm attaching a dump which logs all available pixformats and v4l2ctrls showing that libv4l is properly loaded. (And yes, LIBV4LCONTROL_CONTROLS is exported and set to 15). Best regards, Erik Ah, you are using v4l2-ctl, not v4l2ucp, and that uses V4L2_CTRL_FLAG_NEXT_CTRL control enumeration. My code doesn't handle V4L2_CTRL_FLAG_NEXT_CTRL (which is a bug). I'm not sure when I'll have time to fix this. Patches welcome, or in the mean time use v4l2ucp to play with the controls. Actually, I've tried to use both without finding the controls. I've only tried with v4l2ucp v. 1.2. Is 1.3 necessary? Apparently there are different versions of v4l2ucp in different distro's and some do use the V4L2_CTRL_FLAG_NEXT_CTRL, just like v4l2-ctl. See Adam Baker's patch later in this thread. Which I will apply to my tree after I've reviewed it (when I find some time currently I've a lot of $work$ ) Applying Adam Bakers patch makes the control appear _but_ I can't seem to make out any difference when any of the whitebalancing and normalize options, regardless of how i tweak the max / min values. Did you also do the export LIBV4LCONTROL_CONTROLS=15 In the terminal from where you are starting the viewing application ? Yes. Hmm, Then the camera you are using probably already has some whitebalancing itself using the same algorithm. What happens if you enable normalize and then lower the high bound significantly? If that doesn't do anything either then somehow things are not working. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libv4l release: 0.5.97: the whitebalance release!
2009/4/20 Hans de Goede hdego...@redhat.com: On 04/20/2009 06:43 AM, Erik Andrén wrote: Hans de Goede wrote: On 04/19/2009 09:20 PM, Erik Andrén wrote: 2009/4/19 Hans de Goedehdego...@redhat.com: On 04/18/2009 04:40 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/17/2009 09:27 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/16/2009 10:46 PM, Adam Baker wrote: On Thursday 16 Apr 2009, Hans de Goede wrote: On 04/16/2009 12:26 AM, Adam Baker wrote: On Wednesday 15 Apr 2009, Hans de Goede wrote: Currently only whitebalancing is enabled and only on Pixarts (pac) webcams (which benefit tremendously from this). To test this with other webcams (after instaling this release) do: export LIBV4LCONTROL_CONTROLS=15 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp Strangely while those instructions give me a whitebalance control for the sq905 based camera I can't get it to appear for a pac207 based camera regardless of whether LIBV4LCONTROL_CONTROLS is set. Thats weird, there is a small bug in the handling of pac207 cams with usb id 093a:2476 causing libv4l to not automatically enable whitebalancing (and the control) for cams with that id, but if you have LIBV4LCONTROL_CONTROLS set (exported!) both when loading v4l2ucp (you must preload v4l2convert.so!) and when loading your viewer, then it should work. I've tested it by plugging in the sq905 camera, verifying the whitebablance control is present and working, unplugging the sq905 and plugging in the pac207 and using up arrow to restart v4l2ucp and svv so I think I've eliminated most finger trouble possibilities. The pac207 is id 093a:2460 so not the problem id. I'll have to investigate more thoroughly later. Does the pac207 perhaps have a / in its card string (see v4l-info output) ? if so try out this patch: http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a I have the same issue as Adam when trying to test this with my gspca_stv06xx based Quickcam Web camera i. e no whitebalancing controls show up. I'm attaching a dump which logs all available pixformats and v4l2ctrls showing that libv4l is properly loaded. (And yes, LIBV4LCONTROL_CONTROLS is exported and set to 15). Best regards, Erik Ah, you are using v4l2-ctl, not v4l2ucp, and that uses V4L2_CTRL_FLAG_NEXT_CTRL control enumeration. My code doesn't handle V4L2_CTRL_FLAG_NEXT_CTRL (which is a bug). I'm not sure when I'll have time to fix this. Patches welcome, or in the mean time use v4l2ucp to play with the controls. Actually, I've tried to use both without finding the controls. I've only tried with v4l2ucp v. 1.2. Is 1.3 necessary? Apparently there are different versions of v4l2ucp in different distro's and some do use the V4L2_CTRL_FLAG_NEXT_CTRL, just like v4l2-ctl. See Adam Baker's patch later in this thread. Which I will apply to my tree after I've reviewed it (when I find some time currently I've a lot of $work$ ) Applying Adam Bakers patch makes the control appear _but_ I can't seem to make out any difference when any of the whitebalancing and normalize options, regardless of how i tweak the max / min values. Did you also do the export LIBV4LCONTROL_CONTROLS=15 In the terminal from where you are starting the viewing application ? Yes. Hmm, Then the camera you are using probably already has some whitebalancing itself using the same algorithm. What happens if you enable normalize and then lower the high bound significantly? If that doesn't do anything either then somehow things are not working. I don't think this sensor/camera has any whitebalancing as the image quality is fine in normal daylight but gets yellowtones when using lightbulbs. I'll add some printks to libv4l to verify that the whitebalance processing routines are actually called and get back to you with the results. Best regards, Erik Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libv4l release: 0.5.97: the whitebalance release!
On 04/18/2009 04:40 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/17/2009 09:27 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/16/2009 10:46 PM, Adam Baker wrote: On Thursday 16 Apr 2009, Hans de Goede wrote: On 04/16/2009 12:26 AM, Adam Baker wrote: On Wednesday 15 Apr 2009, Hans de Goede wrote: Currently only whitebalancing is enabled and only on Pixarts (pac) webcams (which benefit tremendously from this). To test this with other webcams (after instaling this release) do: export LIBV4LCONTROL_CONTROLS=15 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp Strangely while those instructions give me a whitebalance control for the sq905 based camera I can't get it to appear for a pac207 based camera regardless of whether LIBV4LCONTROL_CONTROLS is set. Thats weird, there is a small bug in the handling of pac207 cams with usb id 093a:2476 causing libv4l to not automatically enable whitebalancing (and the control) for cams with that id, but if you have LIBV4LCONTROL_CONTROLS set (exported!) both when loading v4l2ucp (you must preload v4l2convert.so!) and when loading your viewer, then it should work. I've tested it by plugging in the sq905 camera, verifying the whitebablance control is present and working, unplugging the sq905 and plugging in the pac207 and using up arrow to restart v4l2ucp and svv so I think I've eliminated most finger trouble possibilities. The pac207 is id 093a:2460 so not the problem id. I'll have to investigate more thoroughly later. Does the pac207 perhaps have a / in its card string (see v4l-info output) ? if so try out this patch: http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a I have the same issue as Adam when trying to test this with my gspca_stv06xx based Quickcam Web camera i. e no whitebalancing controls show up. I'm attaching a dump which logs all available pixformats and v4l2ctrls showing that libv4l is properly loaded. (And yes, LIBV4LCONTROL_CONTROLS is exported and set to 15). Best regards, Erik Ah, you are using v4l2-ctl, not v4l2ucp, and that uses V4L2_CTRL_FLAG_NEXT_CTRL control enumeration. My code doesn't handle V4L2_CTRL_FLAG_NEXT_CTRL (which is a bug). I'm not sure when I'll have time to fix this. Patches welcome, or in the mean time use v4l2ucp to play with the controls. Actually, I've tried to use both without finding the controls. I've only tried with v4l2ucp v. 1.2. Is 1.3 necessary? Apparently there are different versions of v4l2ucp in different distro's and some do use the V4L2_CTRL_FLAG_NEXT_CTRL, just like v4l2-ctl. See Adam Baker's patch later in this thread. Which I will apply to my tree after I've reviewed it (when I find some time currently I've a lot of $work$ ) Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libv4l release: 0.5.97: the whitebalance release!
2009/4/19 Hans de Goede hdego...@redhat.com: On 04/18/2009 04:40 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/17/2009 09:27 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/16/2009 10:46 PM, Adam Baker wrote: On Thursday 16 Apr 2009, Hans de Goede wrote: On 04/16/2009 12:26 AM, Adam Baker wrote: On Wednesday 15 Apr 2009, Hans de Goede wrote: Currently only whitebalancing is enabled and only on Pixarts (pac) webcams (which benefit tremendously from this). To test this with other webcams (after instaling this release) do: export LIBV4LCONTROL_CONTROLS=15 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp Strangely while those instructions give me a whitebalance control for the sq905 based camera I can't get it to appear for a pac207 based camera regardless of whether LIBV4LCONTROL_CONTROLS is set. Thats weird, there is a small bug in the handling of pac207 cams with usb id 093a:2476 causing libv4l to not automatically enable whitebalancing (and the control) for cams with that id, but if you have LIBV4LCONTROL_CONTROLS set (exported!) both when loading v4l2ucp (you must preload v4l2convert.so!) and when loading your viewer, then it should work. I've tested it by plugging in the sq905 camera, verifying the whitebablance control is present and working, unplugging the sq905 and plugging in the pac207 and using up arrow to restart v4l2ucp and svv so I think I've eliminated most finger trouble possibilities. The pac207 is id 093a:2460 so not the problem id. I'll have to investigate more thoroughly later. Does the pac207 perhaps have a / in its card string (see v4l-info output) ? if so try out this patch: http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a I have the same issue as Adam when trying to test this with my gspca_stv06xx based Quickcam Web camera i. e no whitebalancing controls show up. I'm attaching a dump which logs all available pixformats and v4l2ctrls showing that libv4l is properly loaded. (And yes, LIBV4LCONTROL_CONTROLS is exported and set to 15). Best regards, Erik Ah, you are using v4l2-ctl, not v4l2ucp, and that uses V4L2_CTRL_FLAG_NEXT_CTRL control enumeration. My code doesn't handle V4L2_CTRL_FLAG_NEXT_CTRL (which is a bug). I'm not sure when I'll have time to fix this. Patches welcome, or in the mean time use v4l2ucp to play with the controls. Actually, I've tried to use both without finding the controls. I've only tried with v4l2ucp v. 1.2. Is 1.3 necessary? Apparently there are different versions of v4l2ucp in different distro's and some do use the V4L2_CTRL_FLAG_NEXT_CTRL, just like v4l2-ctl. See Adam Baker's patch later in this thread. Which I will apply to my tree after I've reviewed it (when I find some time currently I've a lot of $work$ ) Applying Adam Bakers patch makes the control appear _but_ I can't seem to make out any difference when any of the whitebalancing and normalize options, regardless of how i tweak the max / min values. Best regards, Erik Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libv4l release: 0.5.97: the whitebalance release!
On 04/19/2009 09:20 PM, Erik Andrén wrote: 2009/4/19 Hans de Goedehdego...@redhat.com: On 04/18/2009 04:40 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/17/2009 09:27 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/16/2009 10:46 PM, Adam Baker wrote: On Thursday 16 Apr 2009, Hans de Goede wrote: On 04/16/2009 12:26 AM, Adam Baker wrote: On Wednesday 15 Apr 2009, Hans de Goede wrote: Currently only whitebalancing is enabled and only on Pixarts (pac) webcams (which benefit tremendously from this). To test this with other webcams (after instaling this release) do: export LIBV4LCONTROL_CONTROLS=15 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp Strangely while those instructions give me a whitebalance control for the sq905 based camera I can't get it to appear for a pac207 based camera regardless of whether LIBV4LCONTROL_CONTROLS is set. Thats weird, there is a small bug in the handling of pac207 cams with usb id 093a:2476 causing libv4l to not automatically enable whitebalancing (and the control) for cams with that id, but if you have LIBV4LCONTROL_CONTROLS set (exported!) both when loading v4l2ucp (you must preload v4l2convert.so!) and when loading your viewer, then it should work. I've tested it by plugging in the sq905 camera, verifying the whitebablance control is present and working, unplugging the sq905 and plugging in the pac207 and using up arrow to restart v4l2ucp and svv so I think I've eliminated most finger trouble possibilities. The pac207 is id 093a:2460 so not the problem id. I'll have to investigate more thoroughly later. Does the pac207 perhaps have a / in its card string (see v4l-info output) ? if so try out this patch: http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a I have the same issue as Adam when trying to test this with my gspca_stv06xx based Quickcam Web camera i. e no whitebalancing controls show up. I'm attaching a dump which logs all available pixformats and v4l2ctrls showing that libv4l is properly loaded. (And yes, LIBV4LCONTROL_CONTROLS is exported and set to 15). Best regards, Erik Ah, you are using v4l2-ctl, not v4l2ucp, and that uses V4L2_CTRL_FLAG_NEXT_CTRL control enumeration. My code doesn't handle V4L2_CTRL_FLAG_NEXT_CTRL (which is a bug). I'm not sure when I'll have time to fix this. Patches welcome, or in the mean time use v4l2ucp to play with the controls. Actually, I've tried to use both without finding the controls. I've only tried with v4l2ucp v. 1.2. Is 1.3 necessary? Apparently there are different versions of v4l2ucp in different distro's and some do use the V4L2_CTRL_FLAG_NEXT_CTRL, just like v4l2-ctl. See Adam Baker's patch later in this thread. Which I will apply to my tree after I've reviewed it (when I find some time currently I've a lot of $work$ ) Applying Adam Bakers patch makes the control appear _but_ I can't seem to make out any difference when any of the whitebalancing and normalize options, regardless of how i tweak the max / min values. Did you also do the export LIBV4LCONTROL_CONTROLS=15 In the terminal from where you are starting the viewing application ? Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libv4l release: 0.5.97: the whitebalance release!
Hans de Goede wrote: On 04/19/2009 09:20 PM, Erik Andrén wrote: 2009/4/19 Hans de Goedehdego...@redhat.com: On 04/18/2009 04:40 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/17/2009 09:27 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/16/2009 10:46 PM, Adam Baker wrote: On Thursday 16 Apr 2009, Hans de Goede wrote: On 04/16/2009 12:26 AM, Adam Baker wrote: On Wednesday 15 Apr 2009, Hans de Goede wrote: Currently only whitebalancing is enabled and only on Pixarts (pac) webcams (which benefit tremendously from this). To test this with other webcams (after instaling this release) do: export LIBV4LCONTROL_CONTROLS=15 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp Strangely while those instructions give me a whitebalance control for the sq905 based camera I can't get it to appear for a pac207 based camera regardless of whether LIBV4LCONTROL_CONTROLS is set. Thats weird, there is a small bug in the handling of pac207 cams with usb id 093a:2476 causing libv4l to not automatically enable whitebalancing (and the control) for cams with that id, but if you have LIBV4LCONTROL_CONTROLS set (exported!) both when loading v4l2ucp (you must preload v4l2convert.so!) and when loading your viewer, then it should work. I've tested it by plugging in the sq905 camera, verifying the whitebablance control is present and working, unplugging the sq905 and plugging in the pac207 and using up arrow to restart v4l2ucp and svv so I think I've eliminated most finger trouble possibilities. The pac207 is id 093a:2460 so not the problem id. I'll have to investigate more thoroughly later. Does the pac207 perhaps have a / in its card string (see v4l-info output) ? if so try out this patch: http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a I have the same issue as Adam when trying to test this with my gspca_stv06xx based Quickcam Web camera i. e no whitebalancing controls show up. I'm attaching a dump which logs all available pixformats and v4l2ctrls showing that libv4l is properly loaded. (And yes, LIBV4LCONTROL_CONTROLS is exported and set to 15). Best regards, Erik Ah, you are using v4l2-ctl, not v4l2ucp, and that uses V4L2_CTRL_FLAG_NEXT_CTRL control enumeration. My code doesn't handle V4L2_CTRL_FLAG_NEXT_CTRL (which is a bug). I'm not sure when I'll have time to fix this. Patches welcome, or in the mean time use v4l2ucp to play with the controls. Actually, I've tried to use both without finding the controls. I've only tried with v4l2ucp v. 1.2. Is 1.3 necessary? Apparently there are different versions of v4l2ucp in different distro's and some do use the V4L2_CTRL_FLAG_NEXT_CTRL, just like v4l2-ctl. See Adam Baker's patch later in this thread. Which I will apply to my tree after I've reviewed it (when I find some time currently I've a lot of $work$ ) Applying Adam Bakers patch makes the control appear _but_ I can't seem to make out any difference when any of the whitebalancing and normalize options, regardless of how i tweak the max / min values. Did you also do the export LIBV4LCONTROL_CONTROLS=15 In the terminal from where you are starting the viewing application ? Yes. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libv4l release: 0.5.97: the whitebalance release!
On 04/17/2009 09:27 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/16/2009 10:46 PM, Adam Baker wrote: On Thursday 16 Apr 2009, Hans de Goede wrote: On 04/16/2009 12:26 AM, Adam Baker wrote: On Wednesday 15 Apr 2009, Hans de Goede wrote: Currently only whitebalancing is enabled and only on Pixarts (pac) webcams (which benefit tremendously from this). To test this with other webcams (after instaling this release) do: export LIBV4LCONTROL_CONTROLS=15 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp Strangely while those instructions give me a whitebalance control for the sq905 based camera I can't get it to appear for a pac207 based camera regardless of whether LIBV4LCONTROL_CONTROLS is set. Thats weird, there is a small bug in the handling of pac207 cams with usb id 093a:2476 causing libv4l to not automatically enable whitebalancing (and the control) for cams with that id, but if you have LIBV4LCONTROL_CONTROLS set (exported!) both when loading v4l2ucp (you must preload v4l2convert.so!) and when loading your viewer, then it should work. I've tested it by plugging in the sq905 camera, verifying the whitebablance control is present and working, unplugging the sq905 and plugging in the pac207 and using up arrow to restart v4l2ucp and svv so I think I've eliminated most finger trouble possibilities. The pac207 is id 093a:2460 so not the problem id. I'll have to investigate more thoroughly later. Does the pac207 perhaps have a / in its card string (see v4l-info output) ? if so try out this patch: http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a I have the same issue as Adam when trying to test this with my gspca_stv06xx based Quickcam Web camera i. e no whitebalancing controls show up. I'm attaching a dump which logs all available pixformats and v4l2ctrls showing that libv4l is properly loaded. (And yes, LIBV4LCONTROL_CONTROLS is exported and set to 15). Best regards, Erik Ah, you are using v4l2-ctl, not v4l2ucp, and that uses V4L2_CTRL_FLAG_NEXT_CTRL control enumeration. My code doesn't handle V4L2_CTRL_FLAG_NEXT_CTRL (which is a bug). I'm not sure when I'll have time to fix this. Patches welcome, or in the mean time use v4l2ucp to play with the controls. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libv4l release: 0.5.97: the whitebalance release!
Hans de Goede wrote: On 04/17/2009 09:27 PM, Erik Andrén wrote: Hans de Goede wrote: On 04/16/2009 10:46 PM, Adam Baker wrote: On Thursday 16 Apr 2009, Hans de Goede wrote: On 04/16/2009 12:26 AM, Adam Baker wrote: On Wednesday 15 Apr 2009, Hans de Goede wrote: Currently only whitebalancing is enabled and only on Pixarts (pac) webcams (which benefit tremendously from this). To test this with other webcams (after instaling this release) do: export LIBV4LCONTROL_CONTROLS=15 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp Strangely while those instructions give me a whitebalance control for the sq905 based camera I can't get it to appear for a pac207 based camera regardless of whether LIBV4LCONTROL_CONTROLS is set. Thats weird, there is a small bug in the handling of pac207 cams with usb id 093a:2476 causing libv4l to not automatically enable whitebalancing (and the control) for cams with that id, but if you have LIBV4LCONTROL_CONTROLS set (exported!) both when loading v4l2ucp (you must preload v4l2convert.so!) and when loading your viewer, then it should work. I've tested it by plugging in the sq905 camera, verifying the whitebablance control is present and working, unplugging the sq905 and plugging in the pac207 and using up arrow to restart v4l2ucp and svv so I think I've eliminated most finger trouble possibilities. The pac207 is id 093a:2460 so not the problem id. I'll have to investigate more thoroughly later. Does the pac207 perhaps have a / in its card string (see v4l-info output) ? if so try out this patch: http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a I have the same issue as Adam when trying to test this with my gspca_stv06xx based Quickcam Web camera i. e no whitebalancing controls show up. I'm attaching a dump which logs all available pixformats and v4l2ctrls showing that libv4l is properly loaded. (And yes, LIBV4LCONTROL_CONTROLS is exported and set to 15). Best regards, Erik Ah, you are using v4l2-ctl, not v4l2ucp, and that uses V4L2_CTRL_FLAG_NEXT_CTRL control enumeration. My code doesn't handle V4L2_CTRL_FLAG_NEXT_CTRL (which is a bug). I'm not sure when I'll have time to fix this. Patches welcome, or in the mean time use v4l2ucp to play with the controls. Actually, I've tried to use both without finding the controls. I've only tried with v4l2ucp v. 1.2. Is 1.3 necessary? Best regards, Erik Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libv4l release: 0.5.97: the whitebalance release!
On Saturday 18 Apr 2009, Hans de Goede wrote: Ah, you are using v4l2-ctl, not v4l2ucp, and that uses V4L2_CTRL_FLAG_NEXT_CTRL control enumeration. My code doesn't handle V4L2_CTRL_FLAG_NEXT_CTRL (which is a bug). I'm not sure when I'll have time to fix this. Patches welcome, or in the mean time use v4l2ucp to play with the controls. I tried v4l2ucp first (I rebuilt the Debian package of 1.3 for Ubuntu) and only switched to v4l2-ctl when I wanted something command line oriented to debug with. Not sure when I'd get time to look at V4L2_CTRL_FLAG_NEXT_CTRL support either but if I find time before you post an update then I think I know how to fix it. Adam -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libv4l release: 0.5.97: the whitebalance release!
On 04/16/2009 10:46 PM, Adam Baker wrote: On Thursday 16 Apr 2009, Hans de Goede wrote: On 04/16/2009 12:26 AM, Adam Baker wrote: On Wednesday 15 Apr 2009, Hans de Goede wrote: Currently only whitebalancing is enabled and only on Pixarts (pac) webcams (which benefit tremendously from this). To test this with other webcams (after instaling this release) do: export LIBV4LCONTROL_CONTROLS=15 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp Strangely while those instructions give me a whitebalance control for the sq905 based camera I can't get it to appear for a pac207 based camera regardless of whether LIBV4LCONTROL_CONTROLS is set. Thats weird, there is a small bug in the handling of pac207 cams with usb id 093a:2476 causing libv4l to not automatically enable whitebalancing (and the control) for cams with that id, but if you have LIBV4LCONTROL_CONTROLS set (exported!) both when loading v4l2ucp (you must preload v4l2convert.so!) and when loading your viewer, then it should work. I've tested it by plugging in the sq905 camera, verifying the whitebablance control is present and working, unplugging the sq905 and plugging in the pac207 and using up arrow to restart v4l2ucp and svv so I think I've eliminated most finger trouble possibilities. The pac207 is id 093a:2460 so not the problem id. I'll have to investigate more thoroughly later. Does the pac207 perhaps have a / in its card string (see v4l-info output) ? if so try out this patch: http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a Thanks Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libv4l release: 0.5.97: the whitebalance release!
Hans de Goede wrote: On 04/16/2009 10:46 PM, Adam Baker wrote: On Thursday 16 Apr 2009, Hans de Goede wrote: On 04/16/2009 12:26 AM, Adam Baker wrote: On Wednesday 15 Apr 2009, Hans de Goede wrote: Currently only whitebalancing is enabled and only on Pixarts (pac) webcams (which benefit tremendously from this). To test this with other webcams (after instaling this release) do: export LIBV4LCONTROL_CONTROLS=15 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp Strangely while those instructions give me a whitebalance control for the sq905 based camera I can't get it to appear for a pac207 based camera regardless of whether LIBV4LCONTROL_CONTROLS is set. Thats weird, there is a small bug in the handling of pac207 cams with usb id 093a:2476 causing libv4l to not automatically enable whitebalancing (and the control) for cams with that id, but if you have LIBV4LCONTROL_CONTROLS set (exported!) both when loading v4l2ucp (you must preload v4l2convert.so!) and when loading your viewer, then it should work. I've tested it by plugging in the sq905 camera, verifying the whitebablance control is present and working, unplugging the sq905 and plugging in the pac207 and using up arrow to restart v4l2ucp and svv so I think I've eliminated most finger trouble possibilities. The pac207 is id 093a:2460 so not the problem id. I'll have to investigate more thoroughly later. Does the pac207 perhaps have a / in its card string (see v4l-info output) ? if so try out this patch: http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a I have the same issue as Adam when trying to test this with my gspca_stv06xx based Quickcam Web camera i. e no whitebalancing controls show up. I'm attaching a dump which logs all available pixformats and v4l2ctrls showing that libv4l is properly loaded. (And yes, LIBV4LCONTROL_CONTROLS is exported and set to 15). Best regards, Erik Thanks Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ioctl VIDIOCGTUNER: Invalid argument ioctl VIDIOCGFBUF: Invalid argument try direct access to /dev/video0 device /dev/video0 open for read ### video4linux device info [/dev/video0] ### general info VIDIOCGCAP name: Camera type: 0x1 [CAPTURE] channels: 1 audios : 0 maxwidth: 356 maxheight : 292 minwidth: 48 minheight : 32 channels VIDIOCGCHAN(0) channel : 0 name: STV06xx tuners : 0 flags : 0x0 [] type: CAMERA norm: 0 tuner audio VIDIOCGAUDIO audio : 0 volume : 0 bass: 0 treble : 0 picture VIDIOCGPICT brightness : 0 hue : 0 colour : 0 contrast: 0 whiteness : 0 depth : 8 palette : unknown buffer window VIDIOCGWIN x : 0 y : 0 width : 356 height : 292 chromakey : 0 flags : 0 ### v4l2 device info [/dev/video0] ### general info VIDIOC_QUERYCAP driver : STV06xx card: Camera bus_info: usb-:00:1d.0-1 version : 2.5.0 capabilities: 0x501 [VIDEO_CAPTURE,READWRITE,STREAMING] standards inputs VIDIOC_ENUMINPUT(0) index : 0 name: STV06xx type: CAMERA audioset: 0 tuner : 0 std : 0x0 [] status : 0x0 [] video capture VIDIOC_ENUM_FMT(0,VIDEO_CAPTURE) index : 0 type: VIDEO_CAPTURE flags : 0 description : GRBG pixelformat : 0x47425247 [GRBG] VIDIOC_ENUM_FMT(1,VIDEO_CAPTURE) index : 1 type: VIDEO_CAPTURE flags : 0 description : RGB3 pixelformat : 0x33424752 [RGB3] VIDIOC_ENUM_FMT(2,VIDEO_CAPTURE) index : 2 type: VIDEO_CAPTURE flags : 0 description : BGR3
Re: libv4l release: 0.5.97: the whitebalance release!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans de Goede wrote: [snip] libv4l-0.5.97 - * Some applications / libs (*cough* gstreamer *cough*) will not work correctly with planar YUV formats when the width is not a multiple of 8, so crop widths which are not a multiple of 8 to the nearest multiple of 8 when converting to planar YUV Could you please elaborate how this is supposed to work, because it doesn't with the gspca_stv06xx driver and a sensor supporting raw bayer and 356x292. Best regards, Erik Get it here: http://people.atrpms.net/~hdegoede/libv4l-0.5.97.tar.gz Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkno2PsACgkQN7qBt+4UG0GdWQCgiHC3jAVJk8znEgAk0cgrt4Cp Tg0AmQEk4TMJG2l3It7vCa9NKHiZg9eM =NEdy -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libv4l release: 0.5.97: the whitebalance release!
On Friday 17 Apr 2009, Hans de Goede wrote: I've tested it by plugging in the sq905 camera, verifying the whitebablance control is present and working, unplugging the sq905 and plugging in the pac207 and using up arrow to restart v4l2ucp and svv so I think I've eliminated most finger trouble possibilities. The pac207 is id 093a:2460 so not the problem id. I'll have to investigate more thoroughly later. Does the pac207 perhaps have a / in its card string (see v4l-info output) ? if so try out this patch: http://linuxtv.org/hg/~hgoede/libv4l/rev/1e08d865690a No, no / in the device name. I've tried enabling the logging option in libv4l while running v4l2-ctl -l to list the controls present on each camera but I can't see any significant looking differences in the log other than the the fact the sq905 seems to get many more unsuccessful VIDIOC_QUERYCTRL requests. Unless you have a better idea my next step would be to extend the logging to include the parameters on the VIDIOC_QUERYCTRL ioctls, however my gut feel is that it is related the camera having controls that have CIDs both lower and higher than the ones libv4l adds and libv4l doesn't do anything with the driver returned values if V4L2_CTRL_FLAG_NEXT_CTRL is set. Adam normalize_low_bound (int) : min=0 max=127 step=1 default=0 value=0 whitebalance (bool) : default=1 value=1 normalize (bool) : default=0 value=0 normalize_high_bound (int) : min=128 max=255 step=1 default=255 value=255 brightness (int) : min=0 max=255 step=1 default=4 value=4 exposure (int) : min=5 max=26 step=1 default=5 value=5 auto_gain (bool) : default=1 value=1 gain (int) : min=0 max=31 step=1 default=9 value=9 libv4l2: open: 3 libv4l2: open 3: setting pixelformat to RGB24 VIDIOC_S_FMT app requesting: RGB3 VIDIOC_S_FMT converting from: BA81 request == VIDIOC_S_FMT pixelformat: RGB3 320x240 field: 1 bytesperline: 960 imagesize230400 colorspace: 8, priv: 0 result == 0 libv4l2: open 3: done setting pixelformat request == VIDIOC_QUERYCAP result == 0 request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == 0 request == VIDIOC_QUERYCTRL result == 0 request == VIDIOC_QUERYCTRL result == 0 request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == 0 request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == -1 (Invalid argument) request == VIDIOC_QUERYCTRL result == 0 request == VIDIOC_G_CTRL result == 0 request == VIDIOC_QUERYCTRL result == 0
Re: libv4l release: 0.5.97: the whitebalance release!
Hans, I have tested libv4lconvert with a PCI hauppauge hvr1300 DVB-T and found that v4lconvert_create() returns NULL. The problem comes from the shm_open calls in v4lcontrol_create() in libv4lcontrol.c (lines 187 190). libv4lconvert constructs the shared memory name based on the video device's name. And in this case the video device's name (literally Hauppauge WinTV-HVR1300 DVB-T/H) contains a slash, which makes both calls to shm_open() fail. I can put together a quick patch to replace '/' with '-' or white spaces if you want. Gilles On Wed, Apr 15, 2009 at 10:36 PM, Hans de Goede j.w.r.dego...@hhs.nl wrote: Hi All, As the version number shows this is a beta release of the 0.6.x series, the big change here is the addition of video processing to libv4l currently this only does whitebalance and normalizing (which turns out to be useless for most cams) but the basic framework for doing video processing, and being able to control it through fake v4l2 controls using for example v4l2ucp is there. Currently only whitebalancing is enabled and only on Pixarts (pac) webcams (which benefit tremendously from this). To test this with other webcams (after instaling this release) do: export LIBV4LCONTROL_CONTROLS=15 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp Notice the whitebalance and normalize checkboxes in v4l2ucp, as well as low and high limits for normalize. Now start your favorite webcam viewing app and play around with the 2 checkboxes. Note normalize seems to be useless in most cases. If whitebalancing makes a *strongly noticable* difference for your webcam please mail me info about your cam (the usb id), then I can add it to the list of cams which will have the whitebalancing algorithm (and the v4l2 control to enable/disable it) enabled by default. Unfortunately doing videoprocessing can be quite expensive, as for example whitebalancing is quite hard todo in yuv space, so doing white balancing with the pac7302, with an apps which wants yuv changes the flow from pixart-jpeg - yuv420 - rotate90 to: pixart-jpeg - rgb24 - whitebalance - yuv420 - rotate90 This is not a problem for cams which deliver (compressed) raw bayer, as bayer is rgb too, so I've implemented a version of the whitebalancing algorithm which operates directly on bayer data, so for bayer cams (like the pac207) it goes from: bayer- yuv to: bayer - whitebalance - yuv For the near future I plan to change the code so that the analyse phase (which does not get done every frame) creates per component look up tables, this will make it easier to stack multiple effects in one pass without special casing it as the current special normalize+whitebalance in one pass code. Then we can add for example gamma correction with a negligible performance impact (when already doing white balancing that is). libv4l-0.5.97 - * As the version number shows this is a beta release of the 0.6.x series, the big change here is the addition of video processing to libv4l currently this only does whitebalance and normalizing (which turns out to be useless for most cams) but the basic framework for doing video processing, and being able to control it through fake v4l2 controls using for example v4l2ucp is there. The initial version of this code was written by 3 of my computer science students: Elmar Kleijn, Sjoerd Piepenbrink and Radjnies Bhansingh * Currently whitebalancing gets enabled based on USB-ID's and it only gets enabled for Pixart webcam's. You can force it being enabled with other webcams by setting the environment variable LIBV4LCONTROL_CONTROLS, this sets a bitmask enabling certain v4l2 controls which control the video processing set it to 15 to enable both whitebalancing and normalize. You can then change the settings using a v4l2 control panel like v4l2ucp * Only report / allow supported destination formats in enum_fmt / try_fmt / g_fmt / s_fmt when processing, rotating or flipping. * Some applications / libs (*cough* gstreamer *cough*) will not work correctly with planar YUV formats when the width is not a multiple of 8, so crop widths which are not a multiple of 8 to the nearest multiple of 8 when converting to planar YUV * Add dependency generation to libv4l by: Gilles Gigan gilles.gi...@gmail.com * Add support to use orientation from VIDIOC_ENUMINPUT by: Adam Baker li...@baker-net.org.uk * sn9c20x cams have occasional bad jpeg frames, drop these to avoid the flickering effect they cause, by: Brian Johnson brij...@gmail.com * adjust libv4l's upside down cam detection to also work with devices which have the usb interface as parent instead of the usb device * fix libv4l upside down detection for the new v4l minor numbering scheme * fix reading outside of the source memory when doing yuv420-rgb conversion Get it here: http://people.atrpms.net/~hdegoede/libv4l-0.5.97.tar.gz Regards, Hans -- To unsubscribe from this list: send the line
Re: libv4l release: 0.5.97: the whitebalance release!
Hans, The patch fixes the problem. Gilles On Thu, Apr 16, 2009 at 7:25 PM, Hans de Goede hdego...@redhat.com wrote: On 04/16/2009 08:16 AM, Gilles Gigan wrote: Hans, I have tested libv4lconvert with a PCI hauppauge hvr1300 DVB-T and found that v4lconvert_create() returns NULL. The problem comes from the shm_open calls in v4lcontrol_create() in libv4lcontrol.c (lines 187 190). libv4lconvert constructs the shared memory name based on the video device's name. And in this case the video device's name (literally Hauppauge WinTV-HVR1300 DVB-T/H) contains a slash, which makes both calls to shm_open() fail. I can put together a quick patch to replace '/' with '-' or white spaces if you want. Gilles Hi, Thanks for reporting this! Can you please test the attached patch to see if it fixes this? Thanks, Hans On Wed, Apr 15, 2009 at 10:36 PM, Hans de Goedej.w.r.dego...@hhs.nl wrote: Hi All, As the version number shows this is a beta release of the 0.6.x series, the big change here is the addition of video processing to libv4l currently this only does whitebalance and normalizing (which turns out to be useless for most cams) but the basic framework for doing video processing, and being able to control it through fake v4l2 controls using for example v4l2ucp is there. Currently only whitebalancing is enabled and only on Pixarts (pac) webcams (which benefit tremendously from this). To test this with other webcams (after instaling this release) do: export LIBV4LCONTROL_CONTROLS=15 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp Notice the whitebalance and normalize checkboxes in v4l2ucp, as well as low and high limits for normalize. Now start your favorite webcam viewing app and play around with the 2 checkboxes. Note normalize seems to be useless in most cases. If whitebalancing makes a *strongly noticable* difference for your webcam please mail me info about your cam (the usb id), then I can add it to the list of cams which will have the whitebalancing algorithm (and the v4l2 control to enable/disable it) enabled by default. Unfortunately doing videoprocessing can be quite expensive, as for example whitebalancing is quite hard todo in yuv space, so doing white balancing with the pac7302, with an apps which wants yuv changes the flow from pixart-jpeg - yuv420 - rotate90 to: pixart-jpeg - rgb24 - whitebalance - yuv420 - rotate90 This is not a problem for cams which deliver (compressed) raw bayer, as bayer is rgb too, so I've implemented a version of the whitebalancing algorithm which operates directly on bayer data, so for bayer cams (like the pac207) it goes from: bayer- yuv to: bayer - whitebalance - yuv For the near future I plan to change the code so that the analyse phase (which does not get done every frame) creates per component look up tables, this will make it easier to stack multiple effects in one pass without special casing it as the current special normalize+whitebalance in one pass code. Then we can add for example gamma correction with a negligible performance impact (when already doing white balancing that is). libv4l-0.5.97 - * As the version number shows this is a beta release of the 0.6.x series, the big change here is the addition of video processing to libv4l currently this only does whitebalance and normalizing (which turns out to be useless for most cams) but the basic framework for doing video processing, and being able to control it through fake v4l2 controls using for example v4l2ucp is there. The initial version of this code was written by 3 of my computer science students: Elmar Kleijn, Sjoerd Piepenbrink and Radjnies Bhansingh * Currently whitebalancing gets enabled based on USB-ID's and it only gets enabled for Pixart webcam's. You can force it being enabled with other webcams by setting the environment variable LIBV4LCONTROL_CONTROLS, this sets a bitmask enabling certain v4l2 controls which control the video processing set it to 15 to enable both whitebalancing and normalize. You can then change the settings using a v4l2 control panel like v4l2ucp * Only report / allow supported destination formats in enum_fmt / try_fmt / g_fmt / s_fmt when processing, rotating or flipping. * Some applications / libs (*cough* gstreamer *cough*) will not work correctly with planar YUV formats when the width is not a multiple of 8, so crop widths which are not a multiple of 8 to the nearest multiple of 8 when converting to planar YUV * Add dependency generation to libv4l by: Gilles Gigan gilles.gi...@gmail.com * Add support to use orientation from VIDIOC_ENUMINPUT by: Adam Bakerli...@baker-net.org.uk * sn9c20x cams have occasional bad jpeg frames, drop these to avoid the flickering effect they cause, by: Brian Johnsonbrij...@gmail.com * adjust libv4l's upside down cam detection to also work with devices which have the usb interface as parent instead
Re: libv4l release: 0.5.97: the whitebalance release!
On 04/16/2009 08:16 AM, Gilles Gigan wrote: Hans, I have tested libv4lconvert with a PCI hauppauge hvr1300 DVB-T and found that v4lconvert_create() returns NULL. The problem comes from the shm_open calls in v4lcontrol_create() in libv4lcontrol.c (lines 187 190). libv4lconvert constructs the shared memory name based on the video device's name. And in this case the video device's name (literally Hauppauge WinTV-HVR1300 DVB-T/H) contains a slash, which makes both calls to shm_open() fail. I can put together a quick patch to replace '/' with '-' or white spaces if you want. Gilles Hi, Thanks for reporting this! Can you please test the attached patch to see if it fixes this? Thanks, Hans On Wed, Apr 15, 2009 at 10:36 PM, Hans de Goedej.w.r.dego...@hhs.nl wrote: Hi All, As the version number shows this is a beta release of the 0.6.x series, the big change here is the addition of video processing to libv4l currently this only does whitebalance and normalizing (which turns out to be useless for most cams) but the basic framework for doing video processing, and being able to control it through fake v4l2 controls using for example v4l2ucp is there. Currently only whitebalancing is enabled and only on Pixarts (pac) webcams (which benefit tremendously from this). To test this with other webcams (after instaling this release) do: export LIBV4LCONTROL_CONTROLS=15 LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so v4l2ucp Notice the whitebalance and normalize checkboxes in v4l2ucp, as well as low and high limits for normalize. Now start your favorite webcam viewing app and play around with the 2 checkboxes. Note normalize seems to be useless in most cases. If whitebalancing makes a *strongly noticable* difference for your webcam please mail me info about your cam (the usb id), then I can add it to the list of cams which will have the whitebalancing algorithm (and the v4l2 control to enable/disable it) enabled by default. Unfortunately doing videoprocessing can be quite expensive, as for example whitebalancing is quite hard todo in yuv space, so doing white balancing with the pac7302, with an apps which wants yuv changes the flow from pixart-jpeg - yuv420 - rotate90 to: pixart-jpeg - rgb24 - whitebalance - yuv420 - rotate90 This is not a problem for cams which deliver (compressed) raw bayer, as bayer is rgb too, so I've implemented a version of the whitebalancing algorithm which operates directly on bayer data, so for bayer cams (like the pac207) it goes from: bayer- yuv to: bayer - whitebalance - yuv For the near future I plan to change the code so that the analyse phase (which does not get done every frame) creates per component look up tables, this will make it easier to stack multiple effects in one pass without special casing it as the current special normalize+whitebalance in one pass code. Then we can add for example gamma correction with a negligible performance impact (when already doing white balancing that is). libv4l-0.5.97 - * As the version number shows this is a beta release of the 0.6.x series, the big change here is the addition of video processing to libv4l currently this only does whitebalance and normalizing (which turns out to be useless for most cams) but the basic framework for doing video processing, and being able to control it through fake v4l2 controls using for example v4l2ucp is there. The initial version of this code was written by 3 of my computer science students: Elmar Kleijn, Sjoerd Piepenbrink and Radjnies Bhansingh * Currently whitebalancing gets enabled based on USB-ID's and it only gets enabled for Pixart webcam's. You can force it being enabled with other webcams by setting the environment variable LIBV4LCONTROL_CONTROLS, this sets a bitmask enabling certain v4l2 controls which control the video processing set it to 15 to enable both whitebalancing and normalize. You can then change the settings using a v4l2 control panel like v4l2ucp * Only report / allow supported destination formats in enum_fmt / try_fmt / g_fmt / s_fmt when processing, rotating or flipping. * Some applications / libs (*cough* gstreamer *cough*) will not work correctly with planar YUV formats when the width is not a multiple of 8, so crop widths which are not a multiple of 8 to the nearest multiple of 8 when converting to planar YUV * Add dependency generation to libv4l by: Gilles Gigan gilles.gi...@gmail.com * Add support to use orientation from VIDIOC_ENUMINPUT by: Adam Bakerli...@baker-net.org.uk * sn9c20x cams have occasional bad jpeg frames, drop these to avoid the flickering effect they cause, by: Brian Johnsonbrij...@gmail.com * adjust libv4l's upside down cam detection to also work with devices which have the usb interface as parent instead of the usb device * fix libv4l upside down detection for the new v4l minor numbering scheme * fix reading outside of the source memory when doing yuv420-rgb conversion Get it here:
