Red Hat Bugzilla – Bug 456825
PATCH: use libv4l in v4l2 plugin, adding support for many cam specific formats
Last modified: 2008-08-10 23:32:50 EDT
As you probably know I'm one of the authors of the v4l2 rewrite of the gspca usb
webcam driver framework (which supports more then 100 different cams), this v4l2
rewrite has been merged into the 2.6.27 kernel and thus will become available in
the official Linux kernel soon.
One of the parts of the v4l2 rewrite has been removing conversion from various
manufacturer cam specific video formats to more normal videoformats from the
drivers, as this really does not belong in userspace.
As a result of this the gspca subdrivers can generate raw video frames in the
#define V4L2_PIX_FMT_SN9C10X v4l2_fourcc('S', '9', '1', '0') /* SN9C10x
#define V4L2_PIX_FMT_SPCA501 v4l2_fourcc('S', '5', '0', '1') /* YUYV per line
#define V4L2_PIX_FMT_SPCA505 v4l2_fourcc('S', '5', '0', '5') /* YYUV per line
#define V4L2_PIX_FMT_SPCA508 v4l2_fourcc('S', '5', '0', '8') /* YUVY per line
#define V4L2_PIX_FMT_SPCA561 v4l2_fourcc('S', '5', '6', '1') /* compressed GBRG
#define V4L2_PIX_FMT_PAC207 v4l2_fourcc('P', '2', '0', '7') /* compressed BGGR
As we do not want to see each application implement (nor having to implement)
support for these various formats, as we like to have one code base and only one
code base for these formats. A library has been written (with me as the main
author) to convert from these formats to BGR24 or YUV420. For more on this
The attached patch adds support to the gstreamer v4l2 plugin to use this library
if available on the system, it has also been submitted upstream:
libv4l will show up in rawhide as soon as a cvsadmin gets around to creating a
cvs module for it, see libv4l'2 review request: bug 456772
Getting this patch into Fedora is important for the F-10 better webcam support
A note about the patch, the patch is actually quite simple, as libv4l has been
designed for quick porting of existing apps to libv4l, for this reason libv4l
fully mimicks the raw /dev/video interface (and if no conversion is needed and
for non relevant calls like setting ctrl's, passes through all calls unmodified).
All that the patch does and all that needs to be changed to use libv4l is
replace the relevant xxx calls on /dev/video with v4l2_xxx calls.
The only special thing about the patch is that it passes the
V4L2_ENABLE_ENUM_FMT_EMULATION flag to libv4l2 on open, this patch tells libv4l2
to report the "emulated" formats in the ENUM_FMT ioctl results. Which libv4l2
does not do be default so that ENUM_FMT only reports the really supported
formats (a TRY_FMT with one of the 2 supported emulated formats can then be done
to see if conversion is supported for the specific device). Given the working of
the v4l2 plugin, enabling the ENUM_FMT emulation is needed.
I've successfully tested this patch with cheese and 2 spca561 cams (quite
popular IC, used by both logitech and creative), 2 pac207 cams (another quite
popular IC), 3 SN9C10X cams (also very popular) and 1 spca501 cam. All of which
do not work without this patch, as gstreamer does not support their proprietary
video formats (and rightfully so).
While doing a local rpm testbuild of gstreamer-plugins-good with this patch, it
failed because it build a couple of plugins not in the %files list due to me
having to much foo-devel packages installed, can you please add:
"--disable-esd --disable-libcaca --disable-aalib" to the %configure flags to fix
Created attachment 312745 [details]
PATCH adding support for using libv4l to the v4l2 plugin
libv4l has just been build for rawhide, and should show up in the next rawhide
push, in the mean time you can get it from koji:
Patch looks plausible, but I'm no expert. I'm curious to see how the upstream
(In reply to comment #3)
> Patch looks plausible, but I'm no expert. I'm curious to see how the upstream
> bug goes.
So am I :)
In the mean time can we have this patch go into rawhide please? We need to add
support to gstreamer's v4l2 plugin for the various cam specific formats oneway
or the other (I hope libv4l is the way), otherwise all the effort which has gone
into porting gspca to v4l2 and cleaning it up, which has lead to it being in the
mainline 2.6.27 kernel now, and thus in rawhide, is mostly in vain as people's
webcam's still won't work from an important group of applications.
I can co-maintain, or atleast request bugzilla watch rights for
gstreamer-plugins-good, if you want and then take care of any fallout this may
have. I already maintain gtsreamer-ffmpeg, gstreamer-plugins-ugly and
gstreamer-plugins-bad in that other repo.
If I become a co-maintainer I can also take care of adding the patch to CVS and
building it myself :)
There's still time before the beta. Please try to push the patch upstream first,
we'll see how this goes before adding it to rawhide.
I've submitted it upstream as noted in the original, but in my experience
upstream's response speed varies from fast to pretty slow. Also I would
preferably like to see this get some testing before the beta, the more testing
the better and remember release early release often :)
As I already was afraid little response from upstream sofar, could we please get this patch into rawhide so that it can get as much testing as possible. My offer to co-maintain still stands.
Feel free to commit and build using the latest patch I posted upstream on the bugzilla.
Built bastien's version of the patch in g-p-good 0.10.9-2.fc10.