[nvidia] Blue hue in all videos

Reported by Ignacio Martin Rodriguez on 2008-01-19
This bug report is a duplicate of:  Bug #395476: nvidia sets HUE to -1000. Edit Remove
90
This bug affects 10 people
Affects Status Importance Assigned to Milestone
Totem
Fix Released
Unknown
linux-restricted-modules-2.6.24 (Debian)
Invalid
Undecided
Unassigned
linux-restricted-modules-2.6.24 (Ubuntu)
Low
Unassigned
Nominated for Hardy by Kẏra
Nominated for Intrepid by Kẏra
Nominated for Jaunty by Kẏra
totem (Ubuntu)
Low
Unassigned
Nominated for Hardy by Kẏra
Nominated for Intrepid by Kẏra
Nominated for Jaunty by Kẏra

Bug Description

Binary package hint: totem

Since I've upgraded to Hardy, all the videos are bluish when they're played with totem.

This behavior occurs always with totem (totem-gstreamer) but only from time to time with VLC (specially after having played it with totem). This makes me wonder if the bug really concerns totem only.

I'm using totem 2.21.5, nvidia driver 169.07, and xorg 7.3

Pedro Villavicencio (pedro) wrote :

Thanks for your report, that's more like a driver issue rather than a totem one, re assigning, thanks.

Oli (oli) wrote :

I had this when first moving to Hardy. I had to set the hue to 0 (instead of the default middle value) for normal playback.

But that was last week. Things *seem* to be working as expected now. Is that true for you too?

no luck yet.

Window shadows in compiz are also behaving weird, with pink color instead of black.

Linard Verstraete (linardv) wrote :

I can confirm that on Xubuntu Hardy 8.04 Alpha 4 people look blue when playing videos

Changed in linux-restricted-modules-2.6.24:
status: New → Confirmed
taojones (adamjuda) wrote :

Movies within Totem were blueish (polarized) for me. Changing Totem's hue setting accomplished nothing. The picture always looked blue. I set the HUE to zero (as suggested above).

I then uninstalled totem-xine and installed totem-gstreamer. At this point everything looked normal as long as HUE was kept set to zero.

My system is Ubuntu Hardy (NVidia) and was updated within the last hour.

Timo Aaltonen (tjaalton) wrote :

Ignacio: are you using totem-xine or the default totem-gstreamer? Is it the same with other video players (vlc, mplayer..)?

Changed in linux-restricted-modules-2.6.24:
importance: Undecided → Low
status: Confirmed → Incomplete
Philipp Lehmann (philipp2k7) wrote :

i have the same problem with totem and my integrated webcam (iam using cheese to watch it)

when clicking the "reset hardware defaults" button in the nvidia-settings control panel, the bluish hue temporarily disappears, but when opening a new video, its there again.

thanks

Philipp Lehmann (philipp2k7) wrote :

iam using ubuntu 7.10 32bit and i mean the button on the page "xserver xvideo settings"

BadServo (badservo) wrote :

I can also confirm this bug. All videos in all media players (mplayer, totem+gstreamer, vlc, xine) appear bluish in hue regardless of individual player color settings.

Using Hardy Nightly Build 2-20-08 fully updated.

Linard Verstraete (linardv) wrote :

For me the issue is resolved in Hardy Alpha 6. Feel free to reopen the bug.

Changed in linux-restricted-modules-2.6.24:
status: Incomplete → Fix Released

Hi,
this bug is present for me with Hardy and today updates.
In mplayer selecting "gl2" as video output solve the problem.

mgreen (mattias-green-gmail) wrote :

Confirmed on fully updated Hardy AMD64 with proprietary nv driver.

The problem seems to be related to 'xv' (hardware video scaling). Temporary fix is to use sofware/OpenGL video scaling.
For gstreamer applications (Totem etc):
1) 'gstreamer-properties'
2) Under Video tab, choose Plugin: 'X Window System (No Xv)'

For mplayer:
1) Pick a video out format that is not 'xv'; preferably 'x11', 'gl' or 'gl2' using 'mplayer -vo <format> somemovie.avi'.

Jon Leighton (jonleighton) wrote :

I can confirm this also, and that mgreen's workaround works.

Jon Leighton (jonleighton) wrote :

I also experience the pink window shadow reported by Ignacio Martin Rodriguez.

Linard Verstraete (linardv) wrote :

Can anyone reproduce their symptoms in VLC like "Ignacio" says in his opening post? Because for me this bug is still fixed...

If you can't reproduce this bug in VLC, then there is a fix for the bug reported by "Ignacio" and we have 2 different bugs with similar symptoms... If that's the case, I would suggest that you fill in a new bug report.

Jon Leighton (jonleighton) wrote :

I can reproduce this bug in VLC.

Linard Verstraete (linardv) wrote :

Since all symptoms of the bug reporter are back, the status is back to confirmed...

Changed in linux-restricted-modules-2.6.24:
status: Fix Released → Confirmed
mgreen (mattias-green-gmail) wrote :

Confirmed in VLC aswell. Same 'xv' problem.

Workaround for VLC junkies:
1) Settings/Preferences
2) Toggle "Advanced options" on, if you haven't already. (Checkbox in lower right corner.)
3) Click Video/Output Modules in the tree view to the left.
4) Choose X11 (for example) as 'Video output module'.
5) Click Save

You may have to restart VLC for Video output module changes to take effect.

Same problem here. Using nvidia proprietary driver 169.12. Videos are blue in totem, but setting hue to 0 solves the problem.

mgreen (mattias-green-gmail) wrote :

Verified Moritz Kammerer's resolution. This is a better temporary fix, since videos are still hardware scaled with 'xv'.

The odd thing, however, is that mplayer (with default 'xv' vide out) now works fine too. It seems as if the totem setting somehow changes system-wide state.

Can more people confirm that after changing setting in Totem (or, potentially, some other tool), that VLC and mplayer also are affected? This could perhaps indicate that some intermediate (or current) version of Totem or gstreamer had a bug in the default hue calibration, which set the wrong system-wide state.

So far only speculation, so we need more input from other users and perhaps someone with more intimate knowledge of the "video stack".

mgreen (mattias-green-gmail) wrote :

I fiddled around some more with this when I got home. Try this out:

1) Open Totem
2) Open some video for reference
3) Pause video with some reference colors visible
4) Open a terminal and play the same reference video with mplayer
5) Now, when tweaking hue values in Totem preferences, it updates live in the playing mplayer window

The question now is if this is an NVIDIA driver issue or an issue with Totem default preferences.

Stefan Rehm (stefan-rehm) wrote :

It seems to be a issue with the nvidia-glx-new package in the ubuntu repository. Installing the NVIDIA driver with the installer from NVIDIAs website fixed this problem for me. So this is maybe related to bug #186382.

Stefan Rehm (stefan-rehm) wrote :

While doing some more research regarding bug #186382, I found it (suddenly) also works using the Ubuntu package. The reason for this is, that the Hue slider in the preferences dialog dropped to zero as taojones mentioned above, which is strange, because I never touched that slider :).

Avi Schwartz (le-avion) wrote :

I am seeing the same blue hue problem with linux-restricted-modules-2.6.24-16-generic. The driver is the Nvidia restricted driver and the video card is the nVidia Corporation GeForce 8400M GS (rev a1) in a Dell XPS M1330.

weirdbro (wierdbro) wrote :

I have had this problem in totem and vlc, with vlc only having trouble after it happened in totem. I'm running an nvidia 8800 gts, with linux-restricted-modules-2.6.24-16-generic. I fixed it by changing the video output mode in gstreamer-properties to X Window System (No Xv), but since VLC doesn't use gstreamer, I'd agree with the assessment that this is a driver bug.

mgreen (mattias-green-gmail) wrote :

This update from 'weirdbro', "I have had this problem in totem and vlc, with vlc only having trouble after it happened in totem.", seems to further indicate what i suggested above.

https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/184440/comments/20

'weirdbro', a better temporary fix than setting x11 output is to set hue value to zero in Totem, since it still uses hardware scaling.

https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/184440/comments/20

whitepixel (whitepixel) wrote :

I can confirm this on my Lenovo T61 running nvidia 169.12, ubuntu 64 bit. The problem also exists with my webcam though cheese, camorama, and skype.

Michael Wilson (wilsoniya) wrote :

Confirmed in Hardy x86_64 running on an 8800GT using the restricted driver installed using the driver manager. Blue/green skin hues in VLC, mplayer, and Totem. Everything worked fine in 7.10, so I removed the driver and installed the 169.12 x86_64 driver from nVidia's site and now things are back to normal. Problem w/ the driver in the repo?

Timo Aaltonen (tjaalton) wrote :

Try the kernel&driver from hardy-proposed, which might fix this.

Javier Sixto (javyyer) wrote :

I have the latest kernel&driver from hardy-proposed, and there is no change :
"I have had this problem in totem and vlc, with vlc only having trouble after it happened in totem."
It seems to me that Totem/GStreamer change something on the xv settings, and not other players.
My card is an Nvidia 8600GT on hardy 32bits with restricted driver.

David (davidshen84) wrote :

I am using Ubuntu 8.04 LTS, on Thinkpad T61, with Nvidia NVS 140M. I can confirm this too. I was using RealPlayer 11.

sc00ter (gosdenj) wrote :

Yep, I can confirm the same behaviour. Using NVidia drivers via EnvyNG 169.12 and Ubuntu 8.04LTS. (+Compiz)

Only happens AFTER I've opened a video in Totem, then all video playback regardless of the player (VLC/TotemMPlayer) has a blue/green hue. I normally end up re-booting to get the normal color tones back.

Basically my work-around is to avoid using Totem for video playback and use only VLC.

Any lead-time on a fix?

Linard Verstraete (linardv) wrote :

I have read a report today, that if you uninstall totem/GStreamer, and install totem/Xine, it should prevent from "blueing" your video. Maybe the people here can give it a shot?

mgreen (mattias-green-gmail) wrote :

This seems to be in line with my original assumption:

"This could perhaps indicate that some intermediate (or current) version of Totem or gstreamer had a bug in the default hue calibration, which set the wrong system-wide state."

The temporary fix, which should somehow be BOLDFACED in an updated bug description, is, again, setting the hue value in Totem to zero.

Can anyone clue us in on if this is a GStreamer or Totem bug? If this is a combo-issue that is hard to fix, we should at least have a wiki post or update the bug description with the easy fix.

mgreen

Ramaddan (ramaddan) wrote :

Just to confirm

Same problem here, and I don't think it's just related to Totem

I am playing realmedia files with RealPlayer 11 for Linux, and it has the same bluish hue problem.

However, there is no option to change hue in RealPlayer, so I cannot do a temp fix for it.

I'm using the latest updates for Ubuntu Hardy (without hardy-proposed) on a laptop that uses nVidia GeForce 8 series with the propriety drivers.

Tom Haddon (mthaddon) wrote :

I just started to experience this problem. I'd applied some updates (including updates to linux-restricted-modules) and rebooted. I then tried gxine for the first time and all the colors where bluish. I uninstalled, but discovered that it was affecting all media players. I was able to play a video without problems in xine before running it in gxine (which now has affected all players despite a reboot), but now I'm unable to revert the behaviour. I've tried setting the hue to 0 in totem, but it doesn't seem to persist...

whitepixel (whitepixel) wrote :

I'm not experiencing this issue anymore. I don't know how I got this to be fixed, but try this out:

$ sudo apt-get install xvattr
$ xvattr -a XV_HUE
Found Xv 2.2
XV_HUE = 0

if that returns anything other than 0, try doing the following command and it should set it to zero:

$ xvattr -a XV_HUE -v 0
Found Xv 2.2
XV_HUE set to 0

Tom Haddon (mthaddon) wrote :

Turns out my problem was indeed caused by gxine.

I ran xvattr and saw it was set to 180. Set it to 0. Ran gxine, and got the same color distortion. Ran xvattr again and saw it had been reset to 180. Set it back to 0 and reran xine instead of gxine. Colors all good. Now I have my colors working, but I have a different issue with no sound on startup with xine. Still, that's a separate issue - thx so much for the tip.

Gary (garycai997) wrote :

I have a T61p with 256 Nvidia Quatro 570M graphics card with Ubuntu 8.04 Hardy Heron 64bit.

I too experience this problem, but only after seeing a Realplayer format video through the official realplayer application. These are files ending with .rm and .rmvb

With any other file type, it's fine. But after watching .rm or .rmvb (or even watching for the first time) the videos will have a bluish hue affecting ALL videos of any type in my system. Logging out/in again doesn't solve it. Only a restart will. But only for the next session. It doesn't happen all the time, but the percentage probability is very, very high.

d4v1dv00 (davidvoo) wrote :

Same issue here, here are my findings:

- Real player : turn off Xvid settings restart real player then its gone

- Totem movie player : slide hue to 0 then then its gone.

so what seems to be the problem here?

Regardless of whether there are fixes, its a bug, and shouldn't be
happening in the first place.

On Sat, Jun 28, 2008 at 10:21 AM, d4v1dv00 <email address hidden> wrote:
> Same issue here, here are my findings:
>
> - Real player : turn off Xvid settings restart real player then its gone
>
> - Totem movie player : slide hue to 0 then then its gone.
>
> so what seems to be the problem here?
>
> --
> [nvidia] Blue hue in all videos
> https://bugs.launchpad.net/bugs/184440
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Giovanni Figliozzi (giomini) wrote :

this problem is not a driver problem! It's a Totem preferences problem!
I copy/paste a reply of mine
"I had the same problem, and i found a solution. The problem (in my case) was this: if you restore the default settings about colours in totem preferences it will set the hue bar in the middle, like contrast, colour etc. Instead of this the hue bar should stay at the beginning (0) value, so the videos will play in the correct way. this bug influences also other programs, like vlc and xine (if I remember).
You can also set the hue with xvattr, but at the next opening of totem it will reset to the incorrect value."

weirdbro (wierdbro) wrote :

If it were just a Totem problem, it would not be able to affect
programs such as VLC which share no backend with Totem. This is a bug
related to an interaction between Totem and Nvidia drivers, which,
while able to be fixed by changing totem settings, is more complicated
than that.

On Mon, Jun 30, 2008 at 3:23 PM, Giovanni Figliozzi <email address hidden> wrote:
> this problem is not a driver problem! It's a Totem preferences problem!
> I copy/paste a reply of mine
> "I had the same problem, and i found a solution. The problem (in my case) was this: if you restore the default settings about colours in totem preferences it will set the hue bar in the middle, like contrast, colour etc. Instead of this the hue bar should stay at the beginning (0) value, so the videos will play in the correct way. this bug influences also other programs, like vlc and xine (if I remember).
> You can also set the hue with xvattr, but at the next opening of totem it will reset to the incorrect value."
>
> --
> [nvidia] Blue hue in all videos
> https://bugs.launchpad.net/bugs/184440
> You received this bug notification because you are a direct subscriber
> of the bug.
>

David (davidshen84) wrote :

Yep, xvattr works for me.

On Tue, Jul 1, 2008 at 5:50 AM, weirdbro <email address hidden> wrote:

> If it were just a Totem problem, it would not be able to affect
> programs such as VLC which share no backend with Totem. This is a bug
> related to an interaction between Totem and Nvidia drivers, which,
> while able to be fixed by changing totem settings, is more complicated
> than that.
>
> On Mon, Jun 30, 2008 at 3:23 PM, Giovanni Figliozzi <email address hidden>
> wrote:
> > this problem is not a driver problem! It's a Totem preferences problem!
> > I copy/paste a reply of mine
> > "I had the same problem, and i found a solution. The problem (in my case)
> was this: if you restore the default settings about colours in totem
> preferences it will set the hue bar in the middle, like contrast, colour
> etc. Instead of this the hue bar should stay at the beginning (0) value, so
> the videos will play in the correct way. this bug influences also other
> programs, like vlc and xine (if I remember).
> > You can also set the hue with xvattr, but at the next opening of totem it
> will reset to the incorrect value."
> >
> > --
> > [nvidia] Blue hue in all videos
> > https://bugs.launchpad.net/bugs/184440
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>
> --
> [nvidia] Blue hue in all videos
> https://bugs.launchpad.net/bugs/184440
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Source Package "linux-restricted-modules-2.6.24" in Ubuntu:
> Confirmed
>
> Bug description:
> Binary package hint: totem
>
> Since I've upgraded to Hardy, all the videos are bluish when they're played
> with totem.
>
> This behavior occurs always with totem (totem-gstreamer) but only from time
> to time with VLC (specially after having played it with totem). This makes
> me wonder if the bug really concerns totem only.
>
> I'm using totem 2.21.5, nvidia driver 169.07, and xorg 7.3
>

cbsim (cbsim) wrote :

I can confirm this too, as it occur whenever I use Totem and RealPlayer.

C. Mundi (cmundi) wrote :

Temporary workaround!

As other have said -- this appears to be an interaction problem after recent updates.

Anything XV_HUE set with xvattr is immediately reset by Totem.

But then I used gxvattr, and the settings *almost* stick. What I mean by this is that if I set the hue to 0, it comes back up to 4 or 7. That's still not right, but at least video looks normal to those of use who do not have CIELAB corrected vision!

Id2ndR (id2ndr) wrote :

My brother had this problem. It was fixed by removing .kde folder which contain the conf used by Kaffeine (where he had the trouble).

Safiyyah (safiyyah237) wrote :

I have this problem too. so far setting the hue to zero has worked

I'm getting this bug on Intrepid now.

The gstreamer-properties work around doesn't work, because I'm using Kubuntu, not Ubuntu. I need a solution for Kubuntu/Dragon player as well.

Alberto Milone (albertomilone) wrote :

Jeremy: Dragon player uses a xine backend. Open your ~/.xine/config and get to the following section:

# Videodriver to use (default: auto)
# { auto dxr3 aadxr3 xv XDirectFB DirectFB opengl SyncFB xshm caca aa none xxmc sdl fb xvmc }, default: 0
#video.driver:auto

and make it look like the following:

# Videodriver to use (default: auto)
# { auto dxr3 aadxr3 xv XDirectFB DirectFB opengl SyncFB xshm caca aa none xxmc sdl fb xvmc }, default: 0
video.driver:xshm

Save the file and launch Dragon player. It should work now.

Changing the plugin does work, however I was using the opengl plugin and
that was the one that was having a blue hue. Is that going to be fixed?
I have a decent video card so I would think I should be able to use
opengl. It's working fine for me now, my only concern is others that use
Intrepid out of the box when it's released, that may not be experienced
users.

Alberto Milone wrote:
> Jeremy: Dragon player uses a xine backend. Open your ~/.xine/config and
> get to the following section:
>
> # Videodriver to use (default: auto)
> # { auto dxr3 aadxr3 xv XDirectFB DirectFB opengl SyncFB xshm caca aa none xxmc sdl fb xvmc }, default: 0
> #video.driver:auto
>
> and make it look like the following:
>
> # Videodriver to use (default: auto)
> # { auto dxr3 aadxr3 xv XDirectFB DirectFB opengl SyncFB xshm caca aa none xxmc sdl fb xvmc }, default: 0
> video.driver:xshm
>
> Save the file and launch Dragon player. It should work now.
>
>

Setting HUE to 0 (or 100, seems to be the same) and correcting a little bit with contrast and brightness in Totem Gstreamer worked for me, also for other players. Thanks.

Synthaxx (synthaxx) wrote :

Also ran into this today.
Standard Hardy install, installed the totem-xine package and the hue went to hell. (in VLC aswell)

Set them back to zero in both Totem and VLC, and it seems to help sofar. Still, needs looking into.

Markus Golser (golserma) wrote :
Changed in linux-restricted-modules-2.6.24:
status: Unknown → New
Ghosty (ghosty.be) wrote :

After figuring out some video did not play too well with standard totem-gstreamer, vlc nor gnome-mplayer i also installed totem-xine and gxine (video ran fine in totem-xine)
now i got the same issue in a new x86 ubuntu intrepid ibex.

As someone posted here setting hue values with xvattr is reset next time i start totem-gstreamer
only way to fix it is to set hue to 0 on totem itself

Did not have this bug before i install totem-xine and gxine

my graphics card is nvidia quadro fx570M running nvidia driver nvidia-glx-173 (package 173.14.12-1-0ubuntu4)

Erik (erik-lowney) wrote :

Is there a fix for this yet?

Maybe the fix is to uninstall gstreamer or gxine.

To sum up the problem:

NVidia thinks that hue values range between 0 and 360, with 0 being the default.

All other programs think that hue is a value between -180 and 180, again with 0 as the default.

Now, if hue is set to the center of a GUI slider bar (as mplayer shows), the center (or average) of [0 to 360] is 180. The center of [-180 to 180] is 0.

Seems like someone needs to standardize hue values and shift their range 180 degrees!

ba5e (willieham) wrote :

Hi After installing a new GTX 260 from an ATI card I now have
this issue too. I have carried out the video without xv output
workaround for the time being. What are the next steps to solve
this?

mikey (abc-mikey) wrote :

Seems to me to be a Xine / Gstreamer / NVidia problem. I was happily using Ubuntu 8.10 with my NVidia 8600GTS running the restricted drivers using mplayer, vlc and totem-gstreamer and I tried installing totem-xine which installed along side totem-gstreamer. After this my hue would often almost randomly change for all my video applications. I tried uninstalling totem-xine and reinstalling all the other totems. This didn't help till I removed the Xine libraries as well.

Seems to be back to normal now.

It's an nVidia problem. It only happens with the nVidia drivers.
It's something about the default value that nvidia X server settings assign to the hue. Changing the hue value in individual applications is in my opinion the wrong approach.
I think it's better to change the hue value in the nvidia panel or change the video complement in gstreamer-properties to something that doesn't use xv.

David Tombs (dgtombs) wrote :

Just because it only happens with nvidia drivers doesn't mean it's an nvidia problem. In fact, it's not an nvidia problem, it's more of a totem problem.

The problem is that the XV_HUE value has no prescribed default. Totem assumes that it is the middle value, along with Brightness, Contrast, and Saturation (which happen to be correct). In the case of nvidia drivers, this is incorrect for hue because the range is actually 0-360, with 0 being default[1]. The problem is confounded because totem doesn't like the minimum value of 0 for a hue, so it sets whatever default it has on startup[2].

So, there are actually two bugs in totem:
1) "Reset to defaults" makes up values that are usually correct but not always.
2) Totem, upon startup, does not accept the minimum value of 0 for hue and instead sets it to whatever value it has saved in gconf.

So, I'm going to file this against totem.

References:
[1]: <http://nvnews.net/vbulletin/showthread.php?t=107009#post1539184>
[2]: <http://bugzilla.gnome.org/show_bug.cgi?id=306621#c27> (includes patch to totem)

David Tombs (dgtombs) wrote :

This is a bug in totem, not the nvidia binary. All related bugreports (gnome, debian, etc) reflect this.

Changed in linux-restricted-modules-2.6.24:
status: Confirmed → Invalid
Changed in totem:
status: Unknown → Confirmed
David Tombs (dgtombs) wrote :

Invalid for linux-restricted-modules-2.6.24. See previous comment.

For history's sake, the related Debian bugreport is here <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489487>.

Changed in linux-restricted-modules-2.6.24:
importance: Unknown → Undecided
David Tombs (dgtombs) wrote :

See previous comment.

Changed in linux-restricted-modules-2.6.24:
status: New → Invalid
David Tombs (dgtombs) wrote :

Changing the assigned-to bug from GNOME #306621 to GNOME #567279.

Although the 306621 is a problem and is still broken, 567279 will prevent totem from "proactively" taking any action and messing up a user's working hue value. So, as long as the user doesn't click "Reset to defaults" in totem, hue will be fine after patch in 567279. This is especially true since XV_HUE is set to the correct default value whenever X starts up.

Changed in totem:
status: Confirmed → Unknown
Changed in totem:
status: Unknown → Fix Released
David Tombs (dgtombs) wrote :

Added Ubuntu source package as a patch should probably be backported to intrepid/hardy.

Changed in totem:
status: New → Confirmed
hanz (hansvdvoort) wrote :

As all of you I'm seeing the complementatry color problem with totem, ubuntu 8.10, and an nVidia 8400gs.

But in addition to that, some wide aspect ratio movies show a thick green band and colored ghost images.
Running mplayer with -vo gl2 fixes all this. I experimented with different nvidia kernel modules (versions 177, 180) from the Ubuntu repository, no difference.

David Tombs (dgtombs) wrote :

@hanz: Yes, I have that issue as well. I don't think it's related to this one, though, as the issue still appears with this patch applied.

Feel free to submit a separate report about it, though, I've been meaning to.

Pedro Villavicencio (pedro) wrote :

this is fixed on jaunty now, thanks for reporting.

Changed in totem:
importance: Undecided → Low
status: Confirmed → Fix Released
Luca Aluffi (aluffilu) wrote :

Happened just today with:
Kernel 2.6.27-14
Nvidia 9800gtx+ and nvidia-glx-177 driver

Curious thing: it happens just in ubuntu-gdm-gnome partition but not it kubuntu-kdm-kde.

Gerrit Trawoger (gtrawoger) wrote :

I have seen this "blue bug" on Intel and ATi, and not only nvidia platforms.

Intel: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/160866
ATi: http://<email address hidden>/msg11162.html

Here is one solution that this website suggested: https://answers.launchpad.net/ubuntu/+source/totem/+question/7373
-------------------------------------------------
Put this in the terminal:
    "gstreamer-properties"

In the new window that pops up, change the video output plugin to "CUSTOM".

Change the video output pipeline to: ffmpegcolorspace ! video/x-raw-yuv,format=(fourcc)YV12 ! xvimagesink

The click test. See if it works.
-------------------------------------------------

This seemed to have changed things for me.

It looks like the bug exists in the initiation of Xv. I get the blue people in MythTv as well, but only until I get a video feed. I would usually get a hue value of -1000.

(Specs: nVidia 8600M GT, 185.13 driver, Jaunty 64-bit)

Gerrit Trawoger (gtrawoger) wrote :

QUICK NOTE: The video output pipeline entry was truncated to the next line. Here is the complete line:

ffmpegcolorspace ! video/x-raw-yuv,format=(fourcc)YV12 ! xvimagesink

eli bernstein (biggeman632) wrote :
Download full text (3.9 KiB)

i am having a similar problem as everyone else except the blue hue is on my back round and all videos like youtube and such.. her is a video overlay hope you can tell whats wrong by looking at it...im new to ubuntu so any instructions you give make sure they are detailed thannnkkksss...

SIS 300/315/330 series Video Overlay
 Port: 56
  Name: XV_COLORKEY
   Flags: XvGettable XvSettable
   Min value: 0
   Max value: 16777215
   Current value: 526352
  Name: XV_BRIGHTNESS
   Flags: XvGettable XvSettable
   Min value: -128
   Max value: 127
   Current value: 10
  Name: XV_CONTRAST
   Flags: XvGettable XvSettable
   Min value: 0
   Max value: 7
   Current value: 2
  Name: XV_SATURATION
   Flags: XvGettable XvSettable
   Min value: -7
   Max value: 7
   Current value: 0
  Name: XV_HUE
   Flags: XvGettable XvSettable
   Min value: -8
   Max value: 7
   Current value: 0
  Name: XV_AUTOPAINT_COLORKEY
   Flags: XvGettable XvSettable
   Min value: 0
   Max value: 1
   Current value: 1
  Name: XV_SET_DEFAULTS
   Flags: XvSettable
   Min value: 0
   Max value: 0
  Name: XV_TVXPOSITION
   Flags: XvGettable XvSettable
   Min value: -32
   Max value: 32
   Current value: 0
  Name: XV_TVYPOSITION
   Flags: XvGettable XvSettable
   Min value: -32
   Max value: 32
   Current value: 0
  Name: XV_GAMMA_RED
   Flags: XvGettable XvSettable
   Min value: 100
   Max value: 10000
   Current value: 1000
  Name: XV_GAMMA_GREEN
   Flags: XvGettable XvSettable
   Min value: 100
   Max value: 10000
   Current value: 1000
  Name: XV_GAMMA_BLUE
   Flags: XvGettable XvSettable
   Min value: 100
   Max value: 10000
   Current value: 1000
  Name: XV_DISABLE_GRAPHICS
   Flags: XvGettable XvSettable
   Min value: 0
   Max value: 1
   Current value: 0
  Name: XV_DISABLE_GRAPHICS_LR
   Flags: XvGettable XvSettable
   Min value: 0
   Max value: 1
   Current value: 0
  Name: XV_DISABLE_COLORKEY
   Flags: XvGettable XvSettable
   Min value: 0
   Max value: 1
   Current value: 0
  Name: XV_USE_CHROMAKEY
   Flags: XvGettable XvSettable
   Min value: 0
   Max value: 1
   Current value: 0
  Name: XV_INSIDE_CHROMAKEY
   Flags: XvGettable XvSettable
   Min value: 0
   Max value: 1
   Current value: 0
  Name: XV_CHROMAMIN
   Flags: XvGettable XvSettable
   Min value: 0
   Max value: 16777215
   Current value: 66046
  Name: XV_CHROMAMAX
   Flags: XvGettable XvSettable
   Min value: 0
   Max value: 16777215
   Current value: 66047
  Name: XV_SWITCHCRT
   Flags: XvGettable XvSettable
   Min value: 0
   Max value: 1
   Current value: 1
Adaptor: 1
Name: SIS 315/330 series Video Blitter
 Port: 57
  Name: XV_SET_DEFAULTS
   Flags: XvSettable
   Min value: 0
   Max value: 0
 Port: 58
  Name: XV_SET_DEFAULTS
   Flags: XvSettable
   Min value: 0
   Max value: 0
 Port: 59
  Name: XV_SET_DEFAULTS
   Flags: XvSettable
   Min value: 0
   Max value: 0
 Port: 60
  Name: XV_SET_DEFAULTS
   Flags: XvSettable
   Min value: 0
   Max value: 0
 Port: 61
  Name: XV_SET_DEFAULTS
   Flags: XvSettable
   Min value: 0
   Max value: 0
 Port: 62
  Name: XV_SET_DEFAULTS
   Flags: XvSettable
   Min value: 0
   Max value: 0
 Port: 63
  Name: XV_SET_DEFAULTS
   Flags: XvSettable
   Min value: 0...

Read more...

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.