https://bugzilla.novell.com/show_bug.cgi?id=674287
https://bugzilla.novell.com/show_bug.cgi?id=674287#c22
--- Comment #22 from Bjørn Lie 2011-04-28 19:24:07 CEST ---
Yes you are right it's not crashing anymore - crashing was probably due to
xorg/kernel issues that have been sorted out in later versions - cheese just
happend to trigger it.
---
However - building gst-plug-good with v4l-dev dep mean that I don't get to use
cheese and other webcam apps without the stream going through a wrapperlayer -
nor do I get to use libv4l2 - this forces the camstream into beeing converted.
This is not what the devs of v4l intended - read the
/usr/share/doc/packages/libv4l/README
snip
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 libv4l2 wrapper which
adds support for various pixelformats to v4l2 applications is called
v4l2convert.so.
Example usage (after install in default location):
$ export LD_PRELOAD=/usr/local/lib/libv4l/v4l1compat.so
$ camorama
snip
libv42l is the way forward - what we are doing here is "prolonging2" libv4l
next excert
Q: Why should I use libv4l2 in my app instead of direct device access
combined with libv4lconvert?
A: 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.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.