Re: libv4l release: 0.5.97: the whitebalance release!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.degoede@xxxxxx> 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.gigan@xxxxxxxxx>
> * Add support to use orientation from VIDIOC_ENUMINPUT by:
>  Adam Baker <linux@xxxxxxxxxxxxxxxx>
> * sn9c20x cams have occasional bad jpeg frames, drop these to avoid the
>  flickering effect they cause, by: Brian Johnson <brijohn@xxxxxxxxx>
> * 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 "unsubscribe linux-media" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux