GNOME Bugzilla – Bug 306621
Doesn't reset hue correctly when setting to default (0)
Last modified: 2009-05-07 10:59:35 UTC
Please describe the problem: When the "Reset to Default" button is pressed in the Display section of the preferences, the hue is set to a 180 degree rotation, rather than 0. Steps to reproduce: 1. Go to the display tab of the preferences 2. Click on "Reset to Default" 3. Watch anything - the colours will be inverted Actual results: The hue rotation is set to 0 degrees Expected results: The hue rotation is set to 180 degrees Does this happen every time? Yes Other information:
Created attachment 47334 [details] screenshot Also, when you set the hue to maximum, you can see that after you close and open totem again, the scrollbar isn't at maximum anymore.
James, which backend do you use? Could you take a screenshot of a video showing the problem and one not showing it (using Edit/Take Screenshot)?
It happens with gstreamer, taking a screenshot always gives a image with the correct hue... It's the image in totem that changes.
I'm using 1.1.2 with the gstreamer backend. I has a quick look at the code and in on_tpw_color_reset_clicked() [totem-preferences.c] it sets all four sliders to the centre, which for hue is a 180 degree colour rotation (at least for me, using the gstreamer backend). Editing the code to set the hue to 0 on reset seems to fix it for me. I'm not sure if it is different when using the xine backend.
What's the output of xvinfo before and after launching totem? (Best would be to restart the X server to be sure the default values are reset)
Created attachment 48277 [details] diff of xvinfo, before and after running totem This is the diff of the outputs of xvinfo, before and after totem is run (with the display options set to what "reset to defaults" sets them to).
Should be out of NEEDINFO.
This bug is not tied to backend. Totem's reset to default button sets the colorbalance channels to the middle value (65535/2), that's fine for most graphic cards but a lot of cards have their default not being in the middle of the range. There's no way to know the correct default from the XV API. When totem starts up it get's the value from the card. You could assume they are default and store them in gconf but that's a hack. Bastien ??
That means that the driver for this card should be fixed, IMO. There were some similar problems in the xine-lib backend with NVidia cards[1]. James, is that what you're using? [1]: http://cvs.sourceforge.net/viewcvs.py/xine/xine-lib/src/video_out/video_out_xv.c?r1=1.191&r2=1.192
Yep, I'm using a NVidia card (with the non-free drivers). I guess complaining to nvidia is about all we can do?
That, and the GStreamer X sink not setting the Hue for NVidia cards.
I m sorry but this has nothing to do with GStreamer. If in a range from -1000 to 1000 the correct default setting is -500 and you can't know that, there's not much you can do. x[v]imagesink provide an api to gather colorbalance settings as they are without touching them, it's application's job to store defaults correctly.
This has to do with GStreamer, it should work around (or not, it's up to you) bugs lower down the stack, in this case, in the NVidia drivers. While it's the application's job to "store defaults", there's no such thing as defaults for the XV properties, you can only gather the range of setting (which we scale to a value between 0 and 65535 afterwards) and the current value. There's no defaults.
Doesn't Xv have the 'XV_SET_DEFAULTS' attribute for exactly this purpose? i.e, you set XV_SET_DEFAULTS and read the values - and then thems yer defaults?
From xvinfo: "XV_SET_DEFAULTS" (range 0 to 1) client settable attribute Do you know how to use it? Set "XV_SET_DEFAULTS" to 1, read the values, set it back to 0, then modify the properties with the saved values, right?
Something like that, yep. I don't think you need to set it back to 0 either - it's not a XvGettable value, only XvSettable so when you set it to 1, you trigger resetting the values to defaults.
*** Bug 351799 has been marked as a duplicate of this bug. ***
*** Bug 343378 has been marked as a duplicate of this bug. ***
*** Bug 513542 has been marked as a duplicate of this bug. ***
Agh, just got bitten by this again after updating to FC9. Even managed to file a nvidia report about it: http://nvnews.net/vbulletin/showthread.php?t=114369 Only to get told this was a well known Totem issue.
Aaron from Nvidia just posted this to the bug on nvnews: It's not, though. The behavior of the hue attribute is the same as it was when NV17 was brand-new, and I'm not about to change it now. All of the drivers I looked at use 0 as the default hue value, and in addition to that, there's a XV_SET_DEFAULTS attribute they can use to reset the defaults.
Just tried a couple of custom GStreamer playback pipelines to see if I could fix this, after it recently affecting a bunch of HP notebooks I have. With Totem's (2.22.1 GStreamer 0.10.18) sliders at the defaults, using the following pipeline seems to make the first video play normally, but others (either in a playlist or via a fresh startup) play blue. ffmpegcolorspace ! video/x-raw-yuv,format=(fourcc)YV12 ! videobalance contrast=1 brightness=0 hue=-1 saturation=1 ! autovideosink If I pull the hue bar to the far left, the opposite is true -- the first video is blue, but any other video plays back normally. The odd thing (to me) is that taking a screenshot of a blue-tinged movie from within Totem, displays normally.
*** Bug 550194 has been marked as a duplicate of this bug. ***
Although this bug is has low priority, it is affecting quite a number of people, and let's note that neither mplayer, nor xine, nor vlc have the same problem, so it's likely some things can be done to improve the experience with totem-gstreamer. In particular, I think it should be possible to add code in totem to use the "xv_set_default" command if the driver supports it in order to get reset the values. If the attribute is not available (such as with my intel driver, the current code should be used as fallback). Also, I wonder if it's a good idea to store _and force_ the values of the videobalance independently from the current values of the screen. Instead of setting the balance to the saved values (which default to 50% the first time totem is used), totem should just read the current attribute values of the screen and use them. That's probably the reason it's not happening with other players.
As far as I can remember, I always had this bug. VLC and Miro TV do not have this problem, why would it be a driver problem in this case? (and subscribe :)
There is a good summary there: https://qa.mandriva.com/show_bug.cgi?id=45118#c1 Looking at the current code of totem, it seems to be doing the right thing: it reads the current hue value and uses it. (But I cannot test myself as the driver on my computer does not export any hue value.) Some people have reported that it also happens is the gstreamer preference dialog, so this could be a bug in gstreamer more than totem. Nevertheless, in totem it would be good that the "Reset to default" button resets to correct values, using XV_SET_DEFAULTS attribute when available.
Created attachment 125043 [details] [review] allow setting color balance to min/max value (stops totem from messing up hue on start) (In reply to comment #26) > Looking at the current code of totem, it seems to be doing the right thing: it > reads the current hue value and uses it. (But I cannot test myself as the > driver on my computer does not export any hue value.) It doesn't work properly, because bacon_video_widget_set_video_property() doesn't allow setting the property value to the min (0) or max (65535): if ( !(value < 65535 && value > 0) ) return; Changing it to if ( !(value <= 65535 && value >= 0) ) return; fixes it. Now totem correctly doesn't mess up hue when no hue is set in gconf. Of course this still leaves 2 problems: (1) "Reset to defaults" resets hue to a wrong value (2) Initial hue configuration is saved, even though user did not touch them. This is because totem_setup_preferences() detects current hue values and then calls gtk_range_set_value() with them, which causes hue_changed() to be called, which calls bacon_video_widget_set_video_property() which in turn saves the value into gconf.
(In reply to comment #27) Isn't this actually two bugs? 1) Totem resets to incorrect values. (This bug report.) 2) Totem does not accept minimum value of 0 and thus resets hue to whatever value it has stored. (What your patch fixes.) I would submit another bug report, but you, Anssi, seem to know far more about it than I do, so perhaps you should.
Oh, I see you already have, :) <http://bugzilla.gnome.org/show_bug.cgi?id=567279>
Yes, that has been now fixed. To fix the "Reset to defaults" button, I guess we'd have to add a "reset to defaults" API to both GST and Xinelib, that would then use XV_SET_DEFAULTS.
xvimagesink says the default value for the hue is 0. It should either rejigger the values expected by the backend taking into account the default hue, or it should change the default value exported.
Just as a data point. It seems that the nvidia driver's developers are going to change things on their end: http://www.nvnews.net/vbulletin/showthread.php?p=1913036#post1913036
Is there still anything to be done for this bug? The attached patch is committed to totem already, the NVidia people are changing their driver to fix this bug, anything on the GStreamer side that needs to be done? :)
No, with the NVidia fix I think we can consider this bug fixed.