GNOME Bugzilla – Bug 545108
PATCH: use libv4l in v4l2 plugin, adding support for many cam specific formats
Last modified: 2008-10-26 20:02:18 UTC
Short intro: I'm a long time Linux developer currently working on improving webcam support in Linux, see: http://fedoraproject.org/wiki/Features/BetterWebcamSupport 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 kernel space. As a result of this the gspca subdrivers can generate raw video frames in the following formats: #define V4L2_PIX_FMT_SN9C10X v4l2_fourcc('S', '9', '1', '0') /* SN9C10x compressed bayer #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 bayer #define V4L2_PIX_FMT_PAC207 v4l2_fourcc('P', '2', '0', '7') /* compressed BGGR bayer 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 library see: http://hansdegoede.livejournal.com/3636.html The attached patch adds support to the pwlib v4l2 plugin to use this library if available on the system. Note that currently there is an ifdef to handle compilation with/without the library but this is hard defined in the cxx file. I've done it this way as my autoconf skills are almost non existent so I thought it would be good to let someone else write the autoconf detection of libv4l. You can get the latest version of libv4l here: http://people.atrpms.net/~hdegoede/libv4l-0.3.7.tar.gz Note that this library is an official part of the v4l-dvb project, we just haven't gotten around yet to making a homepage for it at linuxtv.org, but if you look for example at the official v4l-dvb mercurial tree: http://linuxtv.org/hg/v4l-dvb Under v4l2-apps/lib/libv4l you will find libv4l there, a proper homepage is on my todo. 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. I've successfully tested this patch with ekiga 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 (unless using gspca version 1) without this patch, as pwlib does not support their proprietary video formats (and rightfully so).
Created attachment 115415 [details] [review] PATCH: use libv4l in v4l2 plugin
Hello Hans, first of all congratulations on your library, I think this is a good way forward to all this driver hassle. However I have two comments: a) Your lib is LGPL while the v4l2 plugin for ptlib is MPL. As far as i know these licences are partly incompatible (see http://www.voxgratia.org/docs/h263_codec.html) Thus for an MPL app it is only possible to load a LGPL lib at runtime, i.e. it cannot be statically nor dynamically linked against the lib. b) How should it work when distributing (apart from the licence story?) In case we do not link statically, we need to depend on another package with your lib. However I have not yet seen such a package yet (only looked up debian though). Matthias
> first of all congratulations on your library, I think this is a good way > forward to all this driver hassle. However I have two comments: > a) Your lib is LGPL while the v4l2 plugin for ptlib is MPL. As far as i know > these licences are partly incompatible (see > http://www.voxgratia.org/docs/h263_codec.html) > Thus for an MPL app it is only possible to load a LGPL lib at runtime, i.e. it > cannot be statically nor dynamically linked against the lib. The link you gives refers to the text of the LGPL as rationale for this, this is a misinterpretation of the LGPL dynamic linking LGPL code is fine. If it were not then any MPL software using glibc (_the_ C libary on Linux) would be in a violation of the license as glibc is LGPL licensed. > b) How should it work when distributing (apart from the licence story?) In case > we do not link statically, we need to depend on another package with your lib. > However I have not yet seen such a package yet (only looked up debian though). The intend is for the library to get packaged by the various distro's I myself have packaged it for Fedora and it is in Fedora's development branch now. AFAIK there are also some people working on a Debian package.
Yes, the problem would be with GPL. The LGPL is not a problem, Ekiga links with GTK+, which is LGPL without the need for an exception. I have written the autoconf code, and will commit it soon.
Thats great... So we will dynamically link to this lib? And make the v4l2 plugin package depend on it if it exists on the respective distro? And so all the hassle with dynamically loading ffmpeg (LGPL) was not really necessary?
(In reply to comment #5) > And so all the hassle with dynamically loading ffmpeg (LGPL) was not really > necessary? > Oh it is, but that would be because ffmpeg was (and is) GPL not LGPL last time I checked.
FFmpeg is licensed under the GNU Lesser General Public License (LGPL). However, FFmpeg incorporates several optional modules that are covered by the GNU General Public License (GPL), notably libpostproc and libswscale. See : http://ffmpeg.mplayerhq.hu/legal.html Perhaps it contains some GPL code by default in libavcodec against which we link.
Patch committed. Thanks a lot!! It will be available in 3.00.
As far as I know FFMPEG's libpostproc and libswscale are under GP (which we dont use). So its LGPL for ffmpeg. As far as I know even dynamically loading a GPL lib into MPL is not legal (for x264 which is GPL we had to undergo even more hassles by putting it into an independent process under the GPL).