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 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 "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
--
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
