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 <bjorn.lie@gmail.com> 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.