Re: Switching input during capture
Hi all,
On Tue, Nov 8, 2011 at 1:50 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 29-10-2011 05:52, Laurent Pinchart escreveu:
Hi Mauro,
On Saturday 29 October 2011 00:30:12 Mauro Carvalho Chehab wrote:
Em 28-10-2011 14:42, Laurent Pinchart escreveu:
On Friday 28 October 2011 03:31:53 Gilles Gigan wrote:
Hi,
I would like to know what is the correct way to switch the current
video input during capture on a card with a single BT878 chip and 4
inputs
(http://store.bluecherry.net/products/PV%252d143-%252d-4-port-video-capt
ur e-card-%2830FPS%29-%252d-OEM.html). I tried doing it in two ways: -
using VIDIOC_S_INPUT to change the current input. While this works, the
next captured frame shows video from the old input in its top half and
video from the new input in the bottom half.
This is is likely easy to fix. The driver has already a logic to prevent
changing the buffer while in the middle of a buffer filling. I suspect
that the BKL removal patches might have broken it somewhat, allowing
things like that. basically, it should be as simple as not allowing
changing the input at the top half.
This will work optimally only if the input analog signals are synchronized,
right ? If we switch to a new input right when the frame start, can the first
frame captured on the new input be corrupted ?
That's a good question. I'm not sure how those bttv cards solve it, but as
they're widely used on such configurations, I suspect that the hardware used
on those CCTV boards have some logic to keep them in sync.
Please try the enclosed patch.
Regards,
Mauro
-
bttv: Avoid switching the video input at the top half.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/video/bt8xx/bttv-driver.c
b/drivers/media/video/bt8xx/bttv-driver.c index 3dd0660..6a3be6f 100644
--- a/drivers/media/video/bt8xx/bttv-driver.c
+++ b/drivers/media/video/bt8xx/bttv-driver.c
@@ -3978,7 +3978,7 @@ bttv_irq_switch_video(struct bttv *btv)
bttv_set_dma(btv, 0);
/* switch input */
- if (UNSET != btv-new_input) {
+ if (! btv-curr.top UNSET != btv-new_input) {
video_mux(btv,btv-new_input);
btv-new_input = UNSET;
}
I am yet to try the above patch myself, but I have received feedback
from another user and it seems it does not solve the issue.
Will keep you posted as soon as I got around to testing it.
Thanks
Gilles
--
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
Switching input during capture
Hi, I would like to know what is the correct way to switch the current video input during capture on a card with a single BT878 chip and 4 inputs (http://store.bluecherry.net/products/PV%252d143-%252d-4-port-video-capture-card-%2830FPS%29-%252d-OEM.html). I tried doing it in two ways: - using VIDIOC_S_INPUT to change the current input. While this works, the next captured frame shows video from the old input in its top half and video from the new input in the bottom half. - I tried setting the input field to the new input and flags to V4L2_BUF_FLAG_INPUT in the struct v4l2_buffer passed to VIDIOC_QBUF when enqueuing buffers. However, when doing so, the ioctl fails altogether, and I cannot enqueue any buffers with the V4L2_BUF_FLAG_INPUT flag set. Is there another way of doing it ? or is there a way to synchronise the input change (when using VIDIOC_S_INPUT) so it happens in between 2 frames and produces a clean switch ? Thanks Gilles -- 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, 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
