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 306621 - Doesn't reset hue correctly when setting to default (0)
Doesn't reset hue correctly when setting to default (0)
Status: RESOLVED NOTGNOME
Product: GStreamer
Classification: Platform
Component: dont know
0.10.x
Other All
: Normal minor
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 343378 351799 513542 550194 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-06-06 07:13 UTC by James "Doc" Livingston
Modified: 2009-05-07 10:59 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
screenshot (29.04 KB, image/png)
2005-06-06 17:33 UTC, Michaël Arnauts
  Details
diff of xvinfo, before and after running totem (1.76 KB, text/plain)
2005-06-24 14:13 UTC, James "Doc" Livingston
  Details
allow setting color balance to min/max value (stops totem from messing up hue on start) (1.08 KB, patch)
2008-12-20 11:55 UTC, Anssi Hannula
rejected Details | Review

Description James "Doc" Livingston 2005-06-06 07:13:45 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:
Comment 1 Michaël Arnauts 2005-06-06 17:33:31 UTC
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.
Comment 2 Bastien Nocera 2005-06-24 13:06:34 UTC
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)?
Comment 3 Michaël Arnauts 2005-06-24 13:22:43 UTC
It happens with gstreamer, taking a screenshot always gives a image with the
correct hue... It's the image in totem that changes.
Comment 4 James "Doc" Livingston 2005-06-24 13:38:49 UTC
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.
Comment 5 Bastien Nocera 2005-06-24 13:53:39 UTC
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)
Comment 6 James "Doc" Livingston 2005-06-24 14:13:16 UTC
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).
Comment 7 Bastien Nocera 2005-10-25 22:54:21 UTC
Should be out of NEEDINFO.
Comment 8 Julien MOUTTE 2006-01-22 16:15:38 UTC
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 ??
Comment 9 Bastien Nocera 2006-01-22 23:41:07 UTC
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
Comment 10 James "Doc" Livingston 2006-01-23 05:15:33 UTC
Yep, I'm using a NVidia card (with the non-free drivers). I guess complaining to nvidia is about all we can do?
Comment 11 Bastien Nocera 2006-01-23 08:19:55 UTC
That, and the GStreamer X sink not setting the Hue for NVidia cards.
Comment 12 Julien MOUTTE 2006-01-23 10:10:06 UTC
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.
Comment 13 Bastien Nocera 2006-01-23 10:16:20 UTC
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.
Comment 14 Jan Schmidt 2006-02-02 14:43:00 UTC
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?
Comment 15 Bastien Nocera 2006-02-09 23:08:38 UTC
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?
Comment 16 Jan Schmidt 2006-02-10 09:18:21 UTC
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.
Comment 17 Tim-Philipp Müller 2006-09-04 09:34:02 UTC
*** Bug 351799 has been marked as a duplicate of this bug. ***
Comment 18 Philip Withnall 2007-04-03 14:37:04 UTC
*** Bug 343378 has been marked as a duplicate of this bug. ***
Comment 19 Tim-Philipp Müller 2008-01-31 22:27:44 UTC
*** Bug 513542 has been marked as a duplicate of this bug. ***
Comment 20 Christian Fredrik Kalager Schaller 2008-06-06 11:11:45 UTC
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.
Comment 21 Christian Fredrik Kalager Schaller 2008-06-06 16:47:47 UTC
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.
Comment 22 Paul Drain 2008-08-05 15:31:06 UTC
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.
Comment 23 Bastien Nocera 2008-09-02 09:38:14 UTC
*** Bug 550194 has been marked as a duplicate of this bug. ***
Comment 24 Eric Piel 2008-11-06 09:26:50 UTC
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. 
Comment 25 alexandreracine 2008-11-17 22:34:12 UTC
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 :)
Comment 26 Eric Piel 2008-11-18 09:03:10 UTC
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.
Comment 27 Anssi Hannula 2008-12-20 11:55:46 UTC
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.
Comment 28 David Tombs 2009-01-17 01:09:35 UTC
(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.
Comment 29 David Tombs 2009-01-17 01:20:09 UTC
Oh, I see you already have, :)

<http://bugzilla.gnome.org/show_bug.cgi?id=567279>
Comment 30 Anssi Hannula 2009-01-17 10:01:02 UTC
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.
Comment 31 Bastien Nocera 2009-01-21 14:16:29 UTC
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.
Comment 32 Rui Matos 2009-02-03 00:55:45 UTC
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
Comment 33 Sebastian Dröge (slomo) 2009-05-07 10:38:28 UTC
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? :)
Comment 34 Christian Fredrik Kalager Schaller 2009-05-07 10:59:35 UTC
No, with the NVidia fix I think we can consider this bug fixed.