XV extension produce strange colors: hue missed up whith 169.09 drivers

[mastro]

I play video and i get all the hue wrong! I would say the colors are missed-up..
images talk best then words in this case...
if i use gl extension or x11 extension the colors are right..
i think this is a bug...

to let you see what i'm talking about watch this video:
http://video.google.com/videoplay?do...59908534146317
or just see this screenshot taken by me with gl extension:


then watch this screenshot taken by me with xv extension: (click on it to see the full image):


do you have any idea? should i file a bug?
this doesn't happen with drivers i had before: 100.14.23

the 100.14.23 and the 169.09 drivers are the only one i tried here

/var/log/Xorg.0.log seems to not saying anything strange...
http://pastebin.ca/875938

and that's my xorg.conf
http://pastebin.ca/875941

i've done some testing... it has exactly a Hue bias of +180 or -180
if you open the second image with GIMP and do: Colors-> Hue and saturation.. drag the Hue to 180 or -180 and you'll see the photo is back to his original colors...

and if i use vlc i can change the hue on the fly .. changing it to more or less half of the slide do the trick... do you think i should file a bug to nvidia?

(or with mplayer using 5/6 key to change the hue)

sorry if the log-report is missing... i can't reboot for now...
if you think you need it i'll add it when i can reboot

anyway: here another example...
how should be... (video watched with gl extension: mplayer -vo gl)


how it is.... (with xv extension: mplayer -vo xv)

[AaronP]

Please try restarting X, then running "xvinfo | grep -A2 XV_HUE". It should print something like this:

      "XV_HUE" (range 0 to 360)
              client settable attribute
              client gettable attribute (current value is 0)

Then, play your video and see if the value changes.

[mastro]

ok i've tried it...
when i start X that command give:

$ xvinfo | grep -A2 XV_HUE
      "XV_HUE" (range 0 to 360)
              client settable attribute
              client gettable attribute (current value is 0)

and if i use GMplayer it stay "0" and i see video in the right way..
if i use any other player (totem, vlc, mplayer [not gmplayer], etc...) the video has strange color and that value change to 179:

$ xvinfo | grep -A2 XV_HUE
      "XV_HUE" (range 0 to 360)
              client settable attribute
              client gettable attribute (current value is 179)

as you can see.. is this a bug with totem/vlc/etc... or with drivers? and if it's a bug with software until they fix it how can i solve this?

thanks

UPDATE:
correction: the only player that cause me the problem is "totem".. VLC, mplayer, gmplayer works right (sorry i don't know why i was sure they had the same issue)

with suggestion on the private message here i tried to manually re-set it to "0" with:

xvattr -a XV_HUE -v 0

then it's back to 0 but when i use totem it go back to 179 and the colors got strange again

i think i can conclude this is a totem bug.. is this right? or it's an hardware specific + totem bug?

if it is i simply opened the "totem" preferences and onter "visualization" i dragged the "HUE" all left instead of the "almost center" default...

should i report a bug to totem developers?

[AaronP]

XV_HUE support was added for the 8-series GPUs in a relatively recent driver release, which is probably why you started seeing this problem recently. The range of 0 to 360 matches the way this attribute worked on the old NV17 Video Overlay adaptor, so the default of 0 should be pretty standard. This definitely sounds like a bug in Totem.

[mastro]

thanks.. i'm going to report the bug to the totem developers
i will link this post and will link the bug here when i create it

UPDATE:
i created the bug report: http://bugzilla.gnome.org/show_bug.cgi?id=513542

if you can read it and have any useful info you think i can gave to totem developer please tell me, thanks!

[theotheraether]

I thought I'd add a little to this, as I just recently started having this problem in a recent debian (sid) update, this morning actually. Posted the bug at:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472840

I can confirm though that it's not totem, or the fault of any other media player. If you take the hue slider bar all the way to the left in totem the problem goes away. The default setting in the middle sets it to 179/180 which should be the max. As you already stated, GIMP properly reports the hue (not using the overlay, of course) as -180/180. The 0-360 thing doesn't seem to work with XV at all, I'm still not sure if XV is improperly detecting the XV_HUE attribute, or if it is advertised incorrectly. Either way, it seems to me that XV is handling things improperly. If someone can correct me on this, please do.

Edit:

Well, everyone says it's not their fault, and there's obviously no standard regarding HUE, and if 50% should be default or if 0% should be default, I suppose we're at the mercy of the options panel in the various players in this case. It should be noteworthy, however, that the NVidia drivers seem to be doing something different from the norm here.

[AaronP]

theotheraether,
As I mentioned before, the code for the XV_HUE behavior is literally exactly the same as it was for the old Video Overlay, with 0 being the default and 1 through 360 being a hue angle offset from the default. This behavior predates both Totem and GStreamer.

[Scramblejams]

It's affecting me too, and having to run xvattr -a XV_HUE -v 0 as root every time I open a video is becoming a pain in the neck.

Aaron, you say it isn't Nvidia's fault, but Julien Cristau says it isn't libxv1's fault either (http://bugs.debian.org/cgi-bin/bugre...?bug=472840#30), so I have a suggestion: Please get in touch with Julien and work out what's wrong and the right way to get it fixed.

169.12 on an 8800GT 512, running Debian Sid.

Steve

[AaronP]

He's right, it's not libXv's fault, it's a bug in either Totem or GStreamer.

[weltall]

i did a little hack to overcome the problem but it's extremely hacky :P and borderline (minimum and maximum positions) values still get correct hue while they shouldn't, also going to the left or to the right is the same.... at least if you use the restore default function it doesn't mess the colours. i know i could have used abs but the header which contained it wasn't included and so i preffered to avoid a warning from the compiler or adding it :P

--- src/totem-preferences.c     2007-08-26 01:05:03.000000000 +0200
+++ ../../totem-2.20.0/src/totem-preferences.c  2008-04-07 13:36:45.000000000 +0200
@@ -353,6 +353,15 @@
        gdouble i;
 
        i = gtk_range_get_value (range);
+       if(i >= 32767)
+       {
+               i = i-32767;
+       }
+       else
+       {
+               i = 32767-i;
+       }
+       i = i*2; i++;
        bacon_video_widget_set_video_property (totem->bvw,
                        BVW_VIDEO_HUE, (int) i);
 }

[Alejandro Nova]

More info with Dragon Player (using Phonon GStreamer backend).

1. I opened a video. Hue was shifted, as I expected.
2. In Dragon Player, I selected "Settings | Video settings". You get 4 sliders, Brightness, Contrast, Hue and Saturation. I moved the Hue slider all the way to the left and I have correct colors.

So, this issue is about GStreamer. But it's a shame that you can't fix this with Totem. With Dragon Player's overlay controls (with Dragon Player relying on the same GStreamer that Totem uses), fixing this bug is a snap.

[Anssi]

You say that this is a bug in Totem/GStreamer, since no other players are affected. However, this is only because other players implement NVIDIA workarounds.

Mplayer:

               /* nvidia hue workaround */
                if (hue && port_min == 0 && port_max == 360)
                {
                    port_value =
                        (port_value >=
                         0) ? (port_value - 100) : (port_value + 100);
                }

Xine:

        if (!strncmp(adaptor_info[adaptor_num].name, "NV", 2)) {
            xprintf (this->xine, XINE_VERBOSITY_NONE, "video_out_xv: ignoring broken XV_HUE settings on NVidia cards");

VLC does not use port attributes at all.

Since it seems common to assume that the middle of the value range is the default (including the attributes of NVIDIA other than XV_HUE), I'd suggest to make XV_HUE a range (-180,180) keeping 0-180 as it is and moving 181-360 to -180-0.

For an analysis of XV_HUE handling of different players and backends, see my comment here:
https://qa.mandriva.com/show_bug.cgi?id=45118#c1