After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 545108 - PATCH: use libv4l in v4l2 plugin, adding support for many cam specific formats
PATCH: use libv4l in v4l2 plugin, adding support for many cam specific formats
Status: RESOLVED FIXED
Product: ekiga
Classification: Applications
Component: PTLIB
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Ekiga maintainers
Ekiga maintainers
Depends on:
Blocks:
 
 
Reported: 2008-07-28 09:14 UTC by Hans de Goede
Modified: 2008-10-26 20:02 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
PATCH: use libv4l in v4l2 plugin (13.71 KB, patch)
2008-07-28 09:23 UTC, Hans de Goede
none Details | Review

Description Hans de Goede 2008-07-28 09:14:29 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).
Comment 1 Hans de Goede 2008-07-28 09:23:55 UTC
Created attachment 115415 [details] [review]
PATCH: use libv4l in v4l2 plugin
Comment 2 Matthias Schneider 2008-07-29 17:19:32 UTC
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
Comment 3 Hans de Goede 2008-07-29 17:30:37 UTC
> 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.
Comment 4 Damien Sandras 2008-07-29 17:38:42 UTC
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.
Comment 5 Matthias Schneider 2008-07-29 18:06:11 UTC
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?
Comment 6 Hans de Goede 2008-07-29 18:08:16 UTC
(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.
Comment 7 Damien Sandras 2008-07-29 18:32:37 UTC
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.
Comment 8 Damien Sandras 2008-07-29 18:34:48 UTC
Patch committed.

Thanks a lot!!

It will be available in 3.00.
Comment 9 Matthias Schneider 2008-07-29 18:43:47 UTC
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).