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 635938 - gst-camera video too dark at 320x240, OK at 640x480
gst-camera video too dark at 320x240, OK at 640x480
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: dont know
0.10.29
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-11-27 19:05 UTC by Victor Bandur
Modified: 2010-12-03 14:25 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Victor Bandur 2010-11-27 19:05:43 UTC
The video stream shown by gst-camera is very dark in normal light conditions when a resolution of 320x240 is selected.  When 640x480 the brightness is OK.

Steps to Reproduce:
------------------
Run gst-camera and observe video feed for the various resolution settings.

Actual Results:
--------------
Video feed is too dark, unless pointed directly at a source of light at 320x240 resolution, whereas it is fine at 640x480.

Expected Results:
----------------
Brightness should be independent of the capture resolution.

Build Date and Platform:
-----------------------
Version 0.10.29, Gentoo Linux for PPC, Kernel version 2.6.34.

Additional Information:
----------------------
Using camera Logitech QuickCam for Notebooks with kernel driver
``gspca_zc3xx''.  As an example, brightness is fine when recording using ffmmpeg, whereas Ekiga shows the same brightness anomaly as described above.
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2010-11-29 12:38:28 UTC
This imho would be a bug in the driver or the camera. Gstreamer is not affecting the image brightness depending on the resolution.
Comment 2 Stefan Sauer (gstreamer, gtkdoc dev) 2010-12-03 13:24:12 UTC
can you try something like

mplayer -tv driver=v4l2:width=640:height=480:device=/dev/video0 tv://

and

mplayer -tv driver=v4l2:width=320:height=240:device=/dev/video0 tv://

does it show the same problem?
Comment 3 Victor Bandur 2010-12-03 13:52:52 UTC
Hi Stefan,

It does not show the same problem.  It also no longer shows this problem in any of the other applications (cheese, ekiga, Jean-Francois Moine's svv utility).  Does running mplayer like suggested make any permanenet changes?
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2010-12-03 13:56:15 UTC
Hmm, not sure about that. There is also an app called v4l2ucp to see what kind of change apps make to v4l2 settings (and to change settings in addition). Have you seen the problem in ekiga before as well? This would indicate that it is not a gstreamer problem (ekiga uses v4l2 directly).

Please close the ticket as obsolete, if there problem is not visible in cheese anymore even after a reboot.
Comment 5 Victor Bandur 2010-12-03 14:17:31 UTC
Not sure if this is significant, but the version of Ekiga I'm using is 2.0.12, since Gentoo PPC lags a bit.

Even after reboot the problem no longer shows up.  I should mention, though, that when I was seeing these problems I did not have MPlayer installed.  I installed it, coicidentally, last night.  Could this have been the solution?  If so, what was it in MPlayer that solved it?
Comment 6 Stefan Sauer (gstreamer, gtkdoc dev) 2010-12-03 14:25:07 UTC
Victor, the installation of mplayer could not fix it. I just gave mplayer a an example to try one application that for sure not uses GStreamer to see if the problem is in the driver or gstreamer.

I am closing the ticket now. Feel free to reopen, if you have news or the problem reappears.