V4L2-library

v4l2-library@linuxtv.org

81 discussions

Re: [V4l2-library] PATCH: v4l-dvb-do-not-strip-patch-files.patch
by Thierry Merle 03 Jul '08

03 Jul '08

Hi Hans, Hans de Goede a écrit : > Hi, > > While doing make commit of my latest patch I found out that > strip-whitespace also strips the application patches included in the > latest libv4l, which is bad, this patch fixes this. > > Regards, > > Hans > The libv4l directory contains some bugfix patches / port to libv4l patches > for various applications, strip-trailing-whitespaces.sh should not > touch these > this patch teaches strip-trailing-whitespaces.sh to not touch .patch > files. > > Signed-off-by: Hans de Goede <j.w.r.degoede(a)hhs.nl> > > diff -r 6169e79de2d2 v4l/scripts/strip-trailing-whitespaces.sh > --- a/v4l/scripts/strip-trailing-whitespaces.sh Tue Jul 01 21:18:23 > 2008 +0200 > +++ b/v4l/scripts/strip-trailing-whitespaces.sh Thu Jul 03 13:46:16 > 2008 +0200 > @@ -20,6 +20,12 @@ > fi > > for file in `eval $files`; do > + case "$file" in > + *.patch) > + continue > + ;; > + esac > + > perl -ne ' > s/[ \t]+$//; > s<^ {8}> <\t>; Applied thanks. Please post on the v4l2-library too since it targets the interested people about this v4l userspace library specifically. Cheers, Thierry

1 0

Re: [V4l2-library] [PATCH 4/4] libv4l global files
by Thierry Merle 01 Jul '08

01 Jul '08

Committed in http://linuxtv.org/hg/~tmerle/v4l2-library Thanks for the patches. So the library is put in v4l2-apps/lib/libv4l and has 3 sub-directories: -libv4lconvert containing all video frame decoding routines -libv4l2 containing 2 libs: - libv4l2 is a normal library with the decompressing algorithms, v4l2 API. It can be linked with v4l1 applications. - v4l2convert is the wrapper used like this: LD_PRELOAD=v4l2convert.so v4l2program -libv4l1 containing 2 libs: - libv4l1 is a normal library with the decompressing algorithms, v4l1 API. It can be linked with v4l2 applications. - v4l1compat is the wrapper used like this: LD_PRELOAD=v4l1compat.so v4l1program Please give us a feedback about these libraries, I will document a bit this solution on the wiki site. Regards, Thierry

1 1

[PATCH 4/4] libv4l global files
by Hans de Goede 30 Jun '08

30 Jun '08

Hi All, This is libv4l split into 4 patches for v4l-dvb tree inclusion, many thanks to Thierry Merle for preparing this patch series. Signed-off-by: Hans de Goede <j.w.r.degoede(a)hhs.nl> Regards, Hans

1 0

[PATCH 3/4] libv4l1
by Hans de Goede 30 Jun '08

30 Jun '08

1 0

[PATCH 2/4] libv4l2
by Hans de Goede 30 Jun '08

30 Jun '08

1 0

[PATCH 1/4] libv4lconvert
by Hans de Goede 30 Jun '08

30 Jun '08

1 0

Announcing libv4l 0.3 aka "the cheese release"
by Hans de Goede 29 Jun '08

29 Jun '08

Hi All, I'm happy to announce version 0.3 of libv4l: http://people.atrpms.net/~hdegoede/libv4l-0.3.tar.gz This release has the following changes (mostly bugfixes): libv4l-0.3 ---------- * add extern "C" magic to public header files for c++ usage (Gregor Jasny) * Make libv4l1 and libv4l2 multithread use safe, see README.multi-threading * Add v4lx_dup() calls (and intercept dup() from the wrappers) this fixes use with gstreamer's v4l2 plugin (tested with cheese) * Hopefully definitely fix compile errors on systems with a broken videodev2.h The big improvement here is that gstreamer using applications now work without any caveats. I also believe / hope that this release fixes the compile problems some people where having. Regards, Hans

2 2

Announcing libv4l 0.2
by Hans de Goede 28 Jun '08

28 Jun '08

<now with link to the new version included, sorry for the spam> Hi All, I'm happy to announce version 0.2 of libv4l: http://people.atrpms.net/~hdegoede/libv4l-0.2.tar.gz This release has the following changes (mostly bugfixes): libv4l-0.2 ---------- *** API change *** * Change v4lconvert api so that the v4lconvert struct always gets allocated by the library, this to make it opaque, so that we can avoid future API and ABI changes * Add support for yuv420 -> bgr24 conversion * When converting from v4l2 pixelformat to v4l12 palette return VIDEO_PALETTE_YUV420P instead of VIDEO_PALETTE_YUV420 for V4L2_PIX_FMT_YUV420 as that is what most apps seem to expect * override kernel v4l1 compat min / max size with our own more accurate values * fix v4l1 munmap bug where it didn't recognise the buffer being unmapped was our fake buffer (fixes gstreamer v4l1 support, checked with cheese) * add support for reporting the emulated pixelformats with ENUM_FMT, this defaults to off, and can be activated by passing a flag to enable it to v4l2_fd_open. This gets enabled by default the wrappers. * v4l2: mmap the real device buffers before doing conversion when DQBUF gets called before the application has called mmap (avoid crash). The big improvement here is that gstreamer using applications now work as long as they use v4l1, you can force this by [re]moving /usr/lib[64]/gstreamer-0.10/libgstvideo4linux2.so Getting gstreamer v4l2 working is planned for 0.3, this requires adding a v4l2_dup function (and catching dup() in the wrapper), and probably also making things threadsafe. Regards, Hans p.s. Thierry I know you're still working on getting 0.1 into the v4l-dvb no worries, I can split the work from 0.1 in a few seperate patches and submit those once 0.1 is in the v4l1-dvb tree.

3 4

Announcing libv4l 0.2
by Hans de Goede 28 Jun '08

28 Jun '08

Hi All, I'm happy to announce version 0.2 of libv4l, this release has the following changes (mostly bugfixes): libv4l-0.2 ---------- *** API change *** * Change v4lconvert api so that the v4lconvert struct always gets allocated by the library, this to make it opaque, so that we can avoid future API and ABI changes * Add support for yuv420 -> bgr24 conversion * When converting from v4l2 pixelformat to v4l12 palette return VIDEO_PALETTE_YUV420P instead of VIDEO_PALETTE_YUV420 for V4L2_PIX_FMT_YUV420 as that is what most apps seem to expect * override kernel v4l1 compat min / max size with our own more accurate values * fix v4l1 munmap bug where it didn't recognise the buffer being unmapped was our fake buffer (fixes gstreamer v4l1 support, checked with cheese) * add support for reporting the emulated pixelformats with ENUM_FMT, this defaults to off, and can be activated by passing a flag to enable it to v4l2_fd_open. This gets enabled by default the wrappers. * v4l2: mmap the real device buffers before doing conversion when DQBUF gets called before the application has called mmap (avoid crash). The big improvement here is that gstreamer using applications now work as long as they use v4l1, you can force this by [re]moving /usr/lib[64]/gstreamer-0.10/libgstvideo4linux2.so Getting gstreamer v4l2 working is planned for 0.3, this requires adding a v4l2_dup function (and catching dup() in the wrapper), and probably also making things threadsafe. Regards, Hans p.s. Thierry I know you're still working on getting 0.1 into the v4l-dvb no worries, I can split the work from 0.1 in a few seperate patches and submit those once 0.1 is in the v4l1-dvb tree.

1 0

Announcing libv4l 0.1
by Hans de Goede 26 Jun '08

26 Jun '08

Hi All, As most of you know I've been working on a userspace library which can be used to (very) easily add support for all kind of pixelformats to v4l2 applications. Just replace open("dev/video0", ...) with v4l2_open("dev/video0", ...), ioctl with v4l2_ioctl, etc. libv4l2 will then do conversion of any known (webcam) pixelformats to bgr24 or yuv420. Also included is libv4l1, which offer v4l1_open, v4l1_ioctl, etc. which can be used to make v4l1 applications work with v4l2 devices, including the necessary format conversion. The functionality provided by libv4l1 for v4l1 apps and libv4l2 for v4l2 apps can also be used by existing apps without modifying them. For this purpose 2 wrapper libraries are provided which can be preloaded before starting the application using the LD_PRELOAD environment variable. For those interested you can get libv4l1 here: http://people.atrpms.net/~hdegoede/libv4l-0.1.tar.gz Below is the full README of libv4l-0.1 : Introduction ------------ libv4l is a collection of libraries which adds a thin abstraction layer on top of video4linux2 devices. The purpose of this (thin) layer is to make it easy for application writers to support a wide variety of devices without having to write seperate code for different devices in the same class. All libv4l components are licensed under the GNU Library General Publishing License version 2 or (at your option) any later version. libv4l consists of 3 different libraries: libv4lconvert ------------- libv4lconvert offers functions to convert from any (known) pixelformat to V4l2_PIX_FMT_BGR24 or V4l2_PIX_FMT_YUV420. Currently the following source formats are supported: jpeg, mjpeg, bayer (all 4 variants: bggr, rggb, gbrg, grbg), spca501 (chip specific yuv 420 with interlaced components), spca561 (chip specific compressed gbrg bayer) For more details on the v4lconvert_ functions see libv4lconvert.h . libv4l1 ------- This offers functions like v4l1_open, v4l1_ioctl, etc. which can by used to quickly make v4l1 applications work with v4l2 devices. These functions work exactly like the normal open/close/etc, except that libv4l1 does full emulation of the v4l1 api on top of v4l2 drivers, in case of v4l1 drivers it will just pass calls through. For more details on the v4l1_ functions see libv4l1.h . libv4l2 ------- This offers functions like v4l2_open, v4l2_ioctl, etc. which can by used to quickly make v4l2 applications work with v4l2 devices with weird formats. libv4l2 mostly passes calls directly through to the v4l2 driver. When the app does a TRY_FMT / S_FMT with a not supported format libv4l2 will get in the middle and emulate the format (if an app wants to know which formats the hardware can _really_ do it should use ENUM_FMT, not randomly try a bunch of S_FMT's). For more details on the v4l2_ functions see libv4l2.h . wrappers -------- The functionality provided by libv4l1 for v4l1 apps and libv4l2 for v4l2 apps can also be used by existing apps without modifying them. For this purpose 2 wrapper libraries are provided which can be preloaded before starting the application using the LD_PRELOAD environment variable. These wrappers will then intercept calls to open/close/ioctl/etc. and if these calls directed towards a video device the wrapper will redirect the call to the libv4lX counterparts. The preloadable libv4l1 wrapper which adds v4l2 device compatibility to v4l1 applications is called v4l1compat.so. The preloadable libv4l1 wrapper which adds v4l2 device compatibility to v4l1 applications is called v4l2convert.so Example usage: $ export LD_LIBRARY_PATH=`pwd`/lib $ export LD_PRELOAD=`pwd`/lib/v4l1compat.so $ camorama FAQ --- Q: Why libv4l, whats wrong with directly accessing v4l2 devices ? Q: Do we really need yet another library ? A: Current webcam using applications like ekiga contain code to handle many different specific pixelformats webcam's use, but that code only supports a small subset of all native webcam (compressed) pixelformats. Other current v4l2 applications do not support anything but rgb pixelformats (xawtv for example) and this will not work with most webcams at all. With gspca being ported to v4l2 and thus decoding to normal formats being removed from the device driver as this really belongs in userspace, ekiga would need to be extended with many more often chip dependent formats, like the bayer compression used by the spca561 and the (different) compression used by the pac207 and the (again different) compression used by the sn9c102. Adding support for all these formats should not be done at the application level, as then it needs to be written for each application seperately. Licensing issues with the decompressors will then also become a problem as just cut and pasting from one application to another is bound to hit license incompatibilities. So clearly this belongs in a library, and in a library with a license which allows this code to be used from as many different applications as possible. Hence libv4l was born. Q: Under which license may I use and distribute libv4l? A: All libv4l components are licensed under the GNU Library General Publishing License version 2 or (at your option) any later version. See the included COPYING.LIB file. Q: Okay so I get the use of having a libv4lconvert, but why libv4l1 ? A: Many v4l2 drivers do not offer full v4l1 compatibility. They often do not implemented the CGMBUF ioctl and v4l1 style mmap call. Adding support to all these drivers for this is a lot of work and more importantly unnecessary adds code to kernel space. Also even if the CGMBUF ioctl and v4l1 style mmap are supported, then most cams still deliver pixelformats which v4l1 applications do not understand. This libv4l1 was born as an easy way to get v4l1 applications to work with v4l2 devices without requiring full v4l1 emulation (including format conversion) in the kernel, and without requiring major changes to the applications. Q: Why should I use libv4l2 in my app instead of direct device access combined with libv4lconvert? libv4l2 is mainly meant for quickly and easily adding support for more pixelformats to existing v4l2 applications. So if you feel better directly accessing the device in combination with libv4lconvert thats fine too. Notice that libv4l2 also does emulation of the read() call on devices which do not support it in the driver. In the background this uses mmap buffers (even on devices which do support the read call). This mmap gives libv4lconvert zero-copy access to the captured frame, and then it can write the converted data directly to the buffer the application provided to v4l2_read(). Thus another reason to use liv4l2 is to get the no memcpy advantage of the mmap capture method combined with the simplicity of making a simple read() call. Regards, Hans

2 1

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

V4L2-library