GNOME Bugzilla – Bug 669430
Building gstreamer-plugins-good with libv4l-devel gives bad video/pic quality
Last modified: 2013-08-24 17:44:56 UTC
Created attachment 206861 [details] Here gstreamer-plugins-good is built without libv4l-devel In openSUSE (and many/most other distros) gstreamer-plugins-good gets built with a buildrequires on libv4l-devel. This is a "good" thing for many webcam users as their cam would not work with cheese out of the box without it. However, in doing so we lower the over all quality for users that have cams that do not need this compatability layer. See the two attached images for a "visual" proof. See also downstream bug: https://bugzilla.novell.com/show_bug.cgi?id=731765
Created attachment 206862 [details] And here gst-plugins-good is built WITH libv4l-devel I have not moved the cam, or done anything to the config of cheese - but the quality is much much worse.
Do you have similar bad quality with other software using libv4l?
> This is a "good" thing for many webcam users as their cam would not work with > cheese out of the box without it. > > However, in doing so we lower the over all quality for users that have cams > that do not need this compatability layer. > > See the two attached images for a "visual" proof. This does not necessarily follow. There are a trizillion formats that libv4l handles, it might just be that there's a problem with one specific format, and that it works fine for most others. Do you have reports that indicate that there is a problem in general, with a wide range of cameras? As far as I know all major distros ship v4l2src linked against against libv4l, if there was a huge issue in general, I'm sure we'd have heard about that by now. Also, note that when v4l2src queries the formats, it should be able to tell which formats are 'native' and which are 'emulated' (conversion in libv4l), and it should prefer the native formats whenever possible.
RE comment 2: No Ekiga looks ok - granted I can't the the same high resolutions there. Re comment 3: No we do not have lots of bugs about this, but I bet most people don't even notice. Since one acutally has to rebuild gst-pl-good without the dep to see it. As to why the "magic" of emulated or not does not work I'm unsure.
Sorry, forgot to clear the needinfo flag.
(In reply to comment #4) > Re comment 3: > > No we do not have lots of bugs about this, but I bet most people don't even > notice. > Since one acutally has to rebuild gst-pl-good without the dep to see it. Most distributions build gst-plugins-good with libv4l nowdays, these include at least Debian, Ubuntu and Fedora.
I think Bjørn's point is that you need to test gst-plugins-good with and without libv4l to realize the issue. And since most people just use the distro version, they can't compare and therefore might not realize the issue.
(In reply to comment #7) > I think Bjørn's point is that you need to test gst-plugins-good with and > without libv4l to realize the issue. And since most people just use the distro > version, they can't compare and therefore might not realize the issue. Yes this is indeed the argument I'm trying to make.
Which libv4l version are you using here? Have you filed a bug against libv4l yet? Or do you think this is a GStreamer issue? If yes, why? Could you provide a log $ GST_DEBUG=*v4l*:5 gst-launch-0.10 v4l2src num-buffers=10 ! fakesink 2>dbg.log ?
Created attachment 207111 [details] log requested - Note this is with gstreamer built without libv4dev dep
(In reply to comment #9) > Which libv4l version are you using here? libv4l-0.8.5 > > Have you filed a bug against libv4l yet? Or do you think this is a GStreamer > issue? If yes, why? No I haven't. I started with gstreamer since this is where I can "mend" the issue at the current time. > > Could you provide a log > > $ GST_DEBUG=*v4l*:5 gst-launch-0.10 v4l2src num-buffers=10 ! fakesink > 2>dbg.log > Added
Created attachment 207112 [details] distropackages installed. ( with libv4l)
Is this still a problem with latest GStreamer (>= 1.0) and libv4l?
Actually no, gst-1.0 seems to be better in this regard.
Great, thanks for re-testing. Let's close this then.