Bad Video colours with 180.22

[magicmyth]

Now for my second bug

With the latest 180.22 drivers, whenever I play a video with any of the major linux media backends (xine, gstreamer, mplayer) the colours are completely of. Pinks are turquoise etc.

Thanks to another posters suggestion I've found a work around by adjusting the hue sliders in the media players but this re-sets every time they are restarted. It seems at some point the drivers are setting the hue slider all the way to the left. Since this is occurring with different media backends and various players with separate config files (smplayer, kaffiene) I doubt it is bug or setting with the media players.

A pic and the bug report:

Nvidia Bug Report log

[kernelOfTruth]

this is NOT BUG this most likely is a FEATURE

I got the same behavior on a 8400M GS

a lot of players where affected for me with this "FEATURE", try out as much players as you can and you'll most probaby find one that doesn't have this problem

afaik this was related to some xorg.conf and this appeared after I had re-emerged / updated smplayer, and some other players

[gbil]

This is probably an old bug with gstreamer.

when you hit this issue run

> xvattr -a XV_HUE

and see the output. If it is anything else than 0, run

> xvattr -a XV_HUE -v 0

and see what happens

[Chauncellor]

I'm not sure what I hate more -- GStreamer or the nVidia drivers

[AaronP]

Yes, this is a problem caused by the video player deciding that it needs to set the XV_HUE attribute to the middle of its range (i.e. a 180 degree color adjustment) even though the default (and current) setting is 0 degrees. Since it looks like there's little traction getting the video players fixed, we're going to work around it in a future driver release by changing the XV_HUE attribute range so that 0 is in the middle. If you have a video player that relies on the 0-360 range, I'm sorry.

[Vorgus]

Originally Posted by AaronP

Yes, this is a problem caused by the video player deciding that it needs to set the XV_HUE attribute to the middle of its range (i.e. a 180 degree color adjustment) even though the default (and current) setting is 0 degrees. Since it looks like there's little traction getting the video players fixed, we're going to work around it in a future driver release by changing the XV_HUE attribute range so that 0 is in the middle. If you have a video player that relies on the 0-360 range, I'm sorry.

Why not just make it a user switch so they can match it to which ever player they use. That way they are not stuck if they use a player that follows some standards

[magicmyth]

Originally Posted by kernelOfTruth

this is NOT BUG this most likely is a FEATURE

I thought so too. Qui-Gon looks more funky this way

Originally Posted by gbil

This is probably an old bug with gstreamer.

when you hit this issue run

> xvattr -a XV_HUE

and see the output. If it is anything else than 0, run

This reported: XV_HUE = 180

Originally Posted by gbil

> xvattr -a XV_HUE -v 0

and see what happens

Awesome mate that did the trick. Thanks.

Originally Posted by AaronP

Yes, this is a problem caused by the video player deciding that it needs to set the XV_HUE attribute to the middle of its range (i.e. a 180 degree color adjustment) even though the default (and current) setting is 0 degrees. Since it looks like there's little traction getting the video players fixed, we're going to work around it in a future driver release by changing the XV_HUE attribute range so that 0 is in the middle. If you have a video player that relies on the 0-360 range, I'm sorry.

As I mentioned I tried all the media player backends (mplayer, gstreamer, xine, vlc) with various players. A couple of interesting things I discovered was that in VLC if I used the Adjustment and Effects dialogue, hue was set to 0 (far left) but when I moved it to the middle the colour was correct. In Smplayer's filter dialogue the hue was in the middle to begin with but as soon as I touch the slider (note slider not moved) the colour became correct, and if I moved it to the far left it changed to the altered tones as expected.

I find it odd that all the media players exhibited this same issue. Why would they all mess with the hue range as AaronP stated if it was not consider correct? Still as long as they all do it the wrong way the same way then you nv guys working around it seems the best route.

What I find the most strange is why my xv_hue range seemed to become set wrong as soon as the Nvidia drivers were installed. But at least the answer to resolve it is here, Thanks again gbil.

As a note to other opensuse users with the same issue. I found xvattr was not installed by default so do a quick search in yast to install it. I'm sure other distros have in their repositories too.

[pacho2]

Any news on this? Thanks for the info

[Stephen Warren]

The fix for this should be in the 185.xx drivers.

[pacho2]

Thanks a lot!

[micronux]

Originally Posted by gbil

This is probably an old bug with gstreamer.

when you hit this issue run

> xvattr -a XV_HUE

and see the output. If it is anything else than 0, run

> xvattr -a XV_HUE -v 0

and see what happens

Hi guys, I come back on this thread to tell you that this do the the trick for me as well but its not permanent. I have to do it again and again each time i start a video, whatever the media player is.

Another inetresting fact is when i open the "NVIDIA X Server Setting" via "System=>Administration" (Yes i'm using Ubuntu 10.04 LTS with Gnome) in the section "X Server XVideo Settings", the Hue is set to 0 but when i launch the command :

$ xvattr -a XV_HUE

The result is :
Found Xv 2.2
XV_HUE = -1000

Either i click the "Reset Hardware Defaults" button or i launch
$ xvattr -a XV_HUE -v 0
it resolve the problem but just for the video i just start.

If i close the video player and start the video again, the HUE setting come back to -1000 and the NVIDIA HUE setting still show me 0.

I know how to workaround the problem, but how to make it permanent ??

Thanks a lot for helping me guys.

PS : i'm using the NVIDIA GeForce 9500 GT with 2 screens (it works great actually) and NVIDIA Driver Version : 195.36.24

Here is my /etc/X11/xorg.conf

# nvidia-settings: X configuration file generated by nvidia-settings
# nvidia-settings: version 1.0 (buildd@palmer) Fri Apr 9 10:35:18 UTC 2010

# nvidia-xconfig: X configuration file generated by nvidia-xconfig
# nvidia-xconfig: version 1.0 (buildmeister@builder75) Thu Apr 22 11:44:23 PDT 2010

Section "ServerLayout"
Identifier "Layout0"
Screen 0 "Screen0" 0 0
InputDevice "Keyboard0" "CoreKeyboard"
InputDevice "Mouse0" "CorePointer"
Option "Xinerama" "0"
EndSection

Section "Files"
EndSection

Section "InputDevice"

# generated from default
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/psaux"
Option "Emulate3Buttons" "no"
Option "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"

# generated from default
Identifier "Keyboard0"
Driver "kbd"
EndSection

Section "Monitor"
Identifier "Monitor0"
VendorName "Unknown"
ModelName "Samsung SyncMaster"
HorizSync 30.0 - 81.0
VertRefresh 56.0 - 75.0
Option "DPMS"
EndSection

Section "Monitor"
Identifier "Monitor1"
VendorName "Unknown"
ModelName "Samsung SyncMaster"
HorizSync 30.0 - 81.0
VertRefresh 56.0 - 75.0
EndSection

Section "Device"
Identifier "Device0"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName "GeForce 9500 GT"
EndSection

Section "Device"
Identifier "Device1"
Driver "nvidia"
VendorName "NVIDIA Corporation"
BoardName "GeForce 9500 GT"
BusID "PCI:1:0:0"
Screen 1
EndSection

Section "Screen"

# Removed Option "TwinView" "0"
# Removed Option "metamodes" "DFP: nvidia-auto-select +0+0"
# Removed Option "metamodes" "CRT: nvidia-auto-select +0+0, DFP: nvidia-auto-select +1440+0"
# Removed Option "metamodes" "CRT: nvidia-auto-select +1440+0, DFP: nvidia-auto-select +0+0"
# Removed Option "TwinViewXineramaInfoOrder" "DFP-0"
# Removed Option "metamodes" "CRT: nvidia-auto-select +0+0, DFP: nvidia-auto-select +0+0"
Identifier "Screen0"
Device "Device0"
Monitor "Monitor0"
DefaultDepth 24
Option "TwinView" "1"
Option "TwinViewXineramaInfoOrder" "CRT-1"
Option "metamodes" "CRT: nvidia-auto-select +0+0, DFP: nvidia-auto-select +1440+0"
SubSection "Display"
Depth 24
EndSubSection
EndSection

Section "Screen"
Identifier "Screen1"
Device "Device1"
Monitor "Monitor1"
DefaultDepth 24
Option "TwinView" "0"
Option "metamodes" "CRT: nvidia-auto-select +0+0"
SubSection "Display"
Depth 24
EndSubSection
EndSection

If its just a matter of a little option in the Xorg, Which one is it ??

Thanks again !

[Stephen Warren]

This is probably caused by the application you're using to play back video adjusting the hue value at startup to some incorrect value. Perhaps the value is stored in a configuration file you can simply edit or delete. Or, perhaps the player application has a configuration option that tells it not to adjust the hue.