Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#540723: Subject: vlc: video brightness/contrast/gamma is really off

39 views
Skip to first unread message

Gary Dale

unread,
Aug 9, 2009, 5:30:14 PM8/9/09
to
Package: vlc
Version: 0.9.9a-3
Severity: important

I was just fiddling around with the video drivers on my computer after
switching to a new mainboard - still with onboard ATI video (now
HD3300). I tried to move to the open source drivers without any luck so
eventually re-installed the closed fglrx driver from Debian/Squeeze.
When I did that, I ran into a few problems with my various video players
so I revisited the vlc player to see how it was working.

My desktop looks great and performs well after the fglrx reinstall.

Kaffeine had the same problem I am describing here, but I traced that to
a really bad contrast control setting. Resetting it to the default fixed
it. Kaffeine works great.

mPlayer was having problems with extreme flickering, but good colours,
with the (preferences | video) GL video I had been using. Switching to
xv gave me the same extreme contrast issue I had with kaffeine. x11
however works perfectly.

Which brings me to vlc: Tools | preferences | video and selecting
Default output gives me the high-contrast overly bright picture I got
with Kaffeine and mPlayer before I adjusted them to better settings.
However, I can't find a way to make vlc work.

OpenGL video output gives me a flashing picture (though not as bad as
mPlayer) that is grey-scale, not colour and is horizontally compressed
nto the left quarter of the output window. THere is also some noise in
the rest of the video window and the window displays on all virtual
desktops.

xVideo extension video output gives the same output as "default".

x11 video output compresses the video into the left quarter of the
window but without the noise I got with OpenGL and without the flashing.
And it stays in its current virtual desktop. However, the picture is
grey-scale, not colour.

I've tried adjusting the colour using the Tools | Extended Settings |
video effects but without numeric settings, it's almost impossible to
use. The gamma control in particular only seems to be useful in a very
small part of the total allowed range, making setting it with a mouse
next to impossible. Moreover, the settings only affect the current video.

And I can't find any other controls to let me adjust vlc's video output.
So vlc only produces bad or useless video output.


-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages vlc depends on:
ii libaa1 1.4p5-38 ascii art library
ii libc6 2.9-12 GNU C Library: Shared libraries
ii libdbus-1-3 1.2.16-2 simple interprocess
messaging syst
ii libfreetype6 2.3.9-4.1 FreeType 2 font engine,
shared lib
ii libfribidi0 0.10.9-1 Free Implementation of the
Unicode
ii libgcc1 1:4.4.0-5 GCC support library
ii libgl1-mesa-glx [libgl 7.0.3-7 A free implementation of
the OpenG
ii libglib2.0-0 2.20.1-2 The GLib library of C routines
ii libglu1-mesa [libglu1] 7.0.3-7 The OpenGL utility library
(GLU)
ii libgtk2.0-0 2.16.1-2 The GTK+ graphical user
interface
ii libnotify1 [libnotify1 0.4.5-1 sends desktop notifications
to a n
ii libqtcore4 4:4.5.2-1 Qt 4 core module
ii libqtgui4 4:4.5.2-1 Qt 4 GUI module
ii libsdl-image1.2 1.2.7-1 image loading library for
Simple D
ii libsdl1.2debian 1.2.13-4+b1 Simple DirectMedia Layer
ii libstdc++6 4.4.0-5 The GNU Standard C++ Library v3
ii libtar 1.2.11-6 C library for manipulating
tar arc
ii libvlccore0 0.9.9a-3 base library for VLC and
its modul
ii libx11-6 2:1.2.2-1 X11 client-side library
ii libxext6 2:1.0.4-1 X11 miscellaneous extension
librar
ii libxinerama1 2:1.0.3-2 X11 Xinerama extension library
ii libxv1 2:1.0.4-1 X11 Video extension library
ii libxxf86vm1 1:1.0.2-1 X11 XFree86 video mode
extension l
ii ttf-dejavu-core 2.29-3 Vera font family derivate
with add
ii vlc-nox 0.9.9a-3 multimedia player and
streamer (wi
ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime

vlc recommends no packages.

Versions of packages vlc-nox depends on:
ii liba52-0.7.4 0.7.4-11 library for decoding ATSC
A/52 str
ii libasound2 1.0.20-2 shared library for ALSA
applicatio
ii libass3 0.9.6-1 library for SSA/ASS
subtitles rend
ii libavahi-cli 0.6.25-1 Avahi client library
ii libavahi-com 0.6.25-1 Avahi common library
ii libavcodec52 5:0.5+svn20090720-0.0 library to encode decode
multimedi
ii libavformat5 5:0.5+svn20090720-0.0 ffmpeg file format library
ii libavutil49 4:0.5+svn20090609-1 ffmpeg utility library
ii libc6 2.9-12 GNU C Library: Shared libraries
ii libcaca0 0.99.beta16-2 colour ASCII art library
ii libcdio7 0.78.2+dfsg1-3 library to read and control
CD-ROM
ii libdbus-1-3 1.2.16-2 simple interprocess
messaging syst
ii libdca0 0.0.5-3 decoding library for DTS
Coherent
ii libdvbpsi4 0.1.5-3.1 library for MPEG TS and DVB
PSI ta
ii libdvdnav4 4.1.3-3 DVD navigation library
ii libdvdread4 4.1.3-5 library for reading DVDs
ii libebml0 0.7.7-3.1 access library for the EBML
format
ii libfaad0 2.6.1-3.1 freeware Advanced Audio
Decoder -
ii libflac8 1.2.1-1.2 Free Lossless Audio Codec -
runtim
ii libfontconfi 2.6.0-4 generic font configuration
library
ii libfreetype6 2.3.9-4.1 FreeType 2 font engine,
shared lib
ii libfribidi0 0.10.9-1 Free Implementation of the
Unicode
ii libgcc1 1:4.4.0-5 GCC support library
ii libgcrypt11 1.4.4-3 LGPL Crypto library -
runtime libr
ii libgnutls26 2.6.6-1 the GNU TLS library -
runtime libr
ii libhal1 0.5.12~git20090406.46dc48-2 Hardware Abstraction Layer
- share
ii libid3tag0 0.15.1b-10 ID3 tag reading library
from the M
ii liblircclien 0.8.3-3 infra-red remote control
support -
ii liblua5.1-0 5.1.4-3 Simple, extensible,
embeddable pro
ii libmad0 0.15.1b-4 MPEG audio decoder library
ii libmatroska0 0.8.1-1.1 extensible open standard
audio/vid
ii libmodplug0c 1:0.8.7-1 shared libraries for mod
music bas
ii libmpcdec3 1:1.2.2-2.1 Musepack (MPC) format library
ii libmpeg2-4 0.4.1-3 MPEG1 and MPEG2 video
decoder libr
ii libncursesw5 5.7+20090523-1 shared libraries for
terminal hand
ii libogg0 1.1.3-5 Ogg Bitstream Library
ii libpng12-0 1.2.38-1 PNG library - runtime
ii libpostproc5 5:0.5+svn20090720-0.0 postproc shared libraries
ii libschroedin 1.0.7-1 library for
encoding/decoding of D
ii libshout3 2.2.2-5+b1 MP3/Ogg Vorbis broadcast
streaming
ii libsmbclient 2:3.3.4-1 shared library for
communication w
ii libspeex1 1.2~rc1-1 The Speex codec runtime library
ii libstdc++6 4.4.0-5 The GNU Standard C++ Library v3
ii libswscale0 5:0.5+svn20090720-0.0 ffmpeg video scaling library
ii libsysfs2 2.1.0-5 interface library to sysfs
ii libtag1c2a 1.5-7 TagLib Audio Meta-Data Library
ii libtheora0 1.0-2+b1 The Theora Video
Compression Codec
ii libtwolame0 0.3.12-1 MPEG Audio Layer 2 encoding
librar
ii libv4l-0 0.6.0-1 Collection of video4linux
support
ii libvcdinfo0 0.7.23-4 library to extract
information fro
ii libvlc2 0.9.9a-3 multimedia player and
streamer lib
ii libvlccore0 0.9.9a-3 base library for VLC and
its modul
ii libvorbis0a 1.2.0.dfsg-5+b1 The Vorbis General Audio
Compressi
ii libvorbisenc 1.2.0.dfsg-5+b1 The Vorbis General Audio
Compressi
ii libxml2 2.7.3.dfsg-2+b1 GNOME XML library
ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime

Versions of packages libvlc2 depends on:
ii libc6 2.9-12 GNU C Library: Shared libraries
ii libvlccore0 0.9.9a-3 base library for VLC and
its modul

Versions of packages libvlccore0 depends on:
ii libc6 2.9-12 GNU C Library: Shared libraries
ii libdbus-1-3 1.2.16-2 simple interprocess
messaging syst
ii libhal1 0.5.12~git20090406.46dc48-2 Hardware Abstraction Layer
- share
ii vlc-data 0.9.9a-3 Common data for VLC

-- debconf-show failed

--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

Reinhard Tartler

unread,
Aug 10, 2009, 3:00:19 AM8/10/09
to
reassign vlc,fglrx-source
severity wishlist
retitle 540723 fglrx: video brightness/contrast/gamma is really off
stop

Gary Dale <gary...@rogers.com> writes:

> I tried to move to the open source drivers without any luck so
> eventually re-installed the closed fglrx driver from Debian/Squeeze.
> When I did that, I ran into a few problems with my various video players
> so I revisited the vlc player to see how it was working.

This really sounds like video driver issues here. I'm reassigning this
bug to both packages for now. However, since fglrx is developed by
AMD/ATI, I persume they would be in the best position to actually do
something about that.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

Gary Dale

unread,
Aug 10, 2009, 11:50:10 AM8/10/09
to
Reinhard Tartler wrote:
> reassign vlc,fglrx-source
> severity wishlist
> retitle 540723 fglrx: video brightness/contrast/gamma is really off
> stop
>
> Gary Dale <gary...@rogers.com> writes:
>
>
>> I tried to move to the open source drivers without any luck so
>> eventually re-installed the closed fglrx driver from Debian/Squeeze.
>> When I did that, I ran into a few problems with my various video players
>> so I revisited the vlc player to see how it was working.
>>
>
> This really sounds like video driver issues here. I'm reassigning this
> bug to both packages for now. However, since fglrx is developed by
> AMD/ATI, I persume they would be in the best position to actually do
> something about that.
>
>
I might agree except that:

1) my desktop display is fine. I didn't have to do anything with gimp,
gwenview or any of my other desktop applications. It was just the video
applications that were messed up.

2) the Kafeine fix was a simple setting that was off while mPlayer
needed a different output to be selected. It appears that the fglrx GL
implementation is faulty, since I can't get good output from it. However
both Kaffeine and mPlayer have no problem with normal x11 video.
Kaffeine picks x11 automatically while mPlayer needed to be told to use it.

Unfortunately vlc's x11 video output, which works fine for the other two
players, produces bad output. And there doesn't appear to be a way to
reduce the extreme contrast like there was in Kaffeine.

Reinhard Tartler

unread,
Aug 10, 2009, 12:30:28 PM8/10/09
to
Gary Dale <gary...@rogers.com> writes:

> Reinhard Tartler wrote:
>> This really sounds like video driver issues here. I'm reassigning this
>> bug to both packages for now. However, since fglrx is developed by
>> AMD/ATI, I persume they would be in the best position to actually do
>> something about that.
>>
>>
> I might agree except that:
>
> 1) my desktop display is fine. I didn't have to do anything with gimp,
> gwenview or any of my other desktop applications. It was just the video
> applications that were messed up.

gimp and other 'normal' applications do not require hardware assistance
in the same way as a media player needs it. Xv is useful to lower CPU
consumption in media players. X11 backends makes media players to behave
like other 'normal' applications, at the expense of wasting CPU time.

> 2) the Kafeine fix was a simple setting that was off while mPlayer
> needed a different output to be selected. It appears that the fglrx GL
> implementation is faulty, since I can't get good output from
> it. However both Kaffeine and mPlayer have no problem with normal x11
> video. Kaffeine picks x11 automatically while mPlayer needed to be
> told to use it.

Video drivers sometimes offer only limited xv ports, which limits the
number of applications that can simultaneously use the xv extension.

> Unfortunately vlc's x11 video output, which works fine for the other two
> players, produces bad output. And there doesn't appear to be a way to
> reduce the extreme contrast like there was in Kaffeine.

The application could indeed influence this. However, I see little point
in working around bugs in proprietary display drivers like this in open
source applications.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

--

Gary Dale

unread,
Aug 10, 2009, 4:30:13 PM8/10/09
to
Reinhard Tartler wrote:
> Gary Dale <gary...@rogers.com> writes:
>
>
>> Reinhard Tartler wrote:
>>
>>> This really sounds like video driver issues here. I'm reassigning this
>>> bug to both packages for now. However, since fglrx is developed by
>>> AMD/ATI, I persume they would be in the best position to actually do
>>> something about that.
>>>
>>>
>>>
>> I might agree except that:
>>
>> 1) my desktop display is fine. I didn't have to do anything with gimp,
>> gwenview or any of my other desktop applications. It was just the video
>> applications that were messed up.
>>
>
> gimp and other 'normal' applications do not require hardware assistance
> in the same way as a media player needs it. Xv is useful to lower CPU
> consumption in media players. X11 backends makes media players to behave
> like other 'normal' applications, at the expense of wasting CPU time.
>
Reasonable enough explanation for what is going on, except that x11
doesn't work with vlc while xv does (just not very well). Using x11 with
vlc, the video is squashed into the left quarter of the window and it
appears to be greyscale. I've just switched Kaffeine to xv from auto
and it works. mPlayer also gave the high-contrast output when using xv
until I found the video control under "equalizer" to set the contrast to
a sane value (the same problem I was having with Kaffeine - the contrast
control was set to its maximum).

>
>> 2) the Kafeine fix was a simple setting that was off while mPlayer
>> needed a different output to be selected. It appears that the fglrx GL
>> implementation is faulty, since I can't get good output from
>> it. However both Kaffeine and mPlayer have no problem with normal x11
>> video. Kaffeine picks x11 automatically while mPlayer needed to be
>> told to use it.
>>
>
> Video drivers sometimes offer only limited xv ports, which limits the
> number of applications that can simultaneously use the xv extension.
>

See my previous reply. The problem seems to be that the contrast on xv
is way too high.

>
>> Unfortunately vlc's x11 video output, which works fine for the other two
>> players, produces bad output. And there doesn't appear to be a way to
>> reduce the extreme contrast like there was in Kaffeine.
>>
>
> The application could indeed influence this. However, I see little point
> in working around bugs in proprietary display drivers like this in open
> source applications.
>

OK, but the fix turned out to just be finding out where in the program
to tone down the contrast - to its default value (i.e. hitting the reset
t default values button) in Kaffeine and to its centre value (0) in
mPlayer. The apparent lack of brightness and contrast controls in vlc is
strange. Interestingly, once I located and adjusted the contrast in
mPlayer using xv, vlc's contrast seemed to be fixed as well.

I'm guessing that they're both using the same back-end and that
mPlayer's controls adjust the contrast. Kaffeine must be using something
else.

Mark this one closed. Thanks!

Gary Dale

unread,
Aug 10, 2009, 5:30:10 PM8/10/09
to
BTW: as I mentioned in the beginning, I tried to use the open source
drivers but the ati, radeon and radeonhd drivers don't work with this
chipset and the vesa driver is really only good for debugging.
Unfortunately, right now there is no working open source driver for the
Radeon HD3300 (at least not in Debian). Hopefully AMD's efforts to open
up its hardware will change this.
0 new messages