[Hardy] xine/mplayer/vlc/gstreamer output video in wrong colourspace

Bug #218736 reported by Dirk
14
Affects Status Importance Assigned to Milestone
mplayer (Ubuntu)
Invalid
Undecided
Unassigned
Nominated for Intrepid by Ansus
Nominated for Jaunty by Ansus
nvidia-graphics-drivers-180 (Ubuntu)
Invalid
Undecided
Unassigned
Nominated for Intrepid by Ansus
Nominated for Jaunty by Ansus
vlc (Ubuntu)
Invalid
Undecided
Unassigned
Nominated for Intrepid by Ansus
Nominated for Jaunty by Ansus
xine-ui (Ubuntu)
Invalid
Undecided
Unassigned
Nominated for Intrepid by Ansus
Nominated for Jaunty by Ansus
xorg (Ubuntu)
Invalid
Undecided
Unassigned
Nominated for Intrepid by Ansus
Nominated for Jaunty by Ansus

Bug Description

This is related to #59539 #199975 #79559 and http://ubuntuforums.org/showthread.php?t=231521

But I don't think it has anything specific to do with any of the programs themselves. As far as I can tell this is a change that has happened (for me) either with the latest compiz or xorg in Hardy in the last couple of days (<17Apr08). I have not seen the problem before and the only thing that has changed is rebooting the machine. Looking at the test bars in VLC, I would guess that video is using complementary colours (ie CMYK, rather than RGB). On programs that have it (eg gxine->video->controls), moving the 'saturation' slider to either end (from the middle) will bring video back to normal. Fiddling with output drivers sometimes cures it, but it seems to come back. The act of changing the output driver may be enough in itself (uninitialised variable somewhere?) .

Also changing from 'auto' ->opengl in xine (settings in 'master of the universe mode) cures the colour problem, but then kaffeine complains that opengl does not exist and reverts to auto (but usually works in correct colourspace and no extra cpu). Setting it to xshm also works but at the expense of more cpu and a very jaggy (not horizontally anti-aliased) output (at least from a DVB TV card). Gxine cannot be set to anything other than its default video driver (don't know why) and is always in the wrong colourspace for any video.

There a colourspace problem in *all* video playing programs that I have tried. It was not there in Gutsy, it wasn't there in previous versions of xorg in Hardy. Nothing else has changed. The default settings of all the video players no longer work correctly, whether playing DVDs/WMV files or from DVB tv cards.

Doing a test from setup will give you: http://launchpadlibrarian.net/5771282/Screenshot1-bad.png, if it is wrong.

The hardware is Intel E8400, Intel Chipset, Nvidia 8600GT, Nvidia driver. I am up to date in Hardy as of posting.

Revision history for this message
Travis Watkins (amaranth) wrote :

Do you see this when running metacity too?

Revision history for this message
Dirk (ubuntu-tobit) wrote : Re: [Bug 218736] Re: [Hardy] xine/mplayer/vlc/gstreamer output video in wrong colourspace

Travis Watkins wrote:
> Do you see this when running metacity too?
>

No. In metacity it works fine.

The most reliable way of demonstrating this is to use gxine.

I set the video driver to 'auto' (in master of the universe mode) in gxine.

With compiz (as in compiz --replace), I get CMYK rendering, with
metacity (as in metacity --replace), I get normal RGB.

So is compiz spreading misinformation?

Setting the video driver in gxine to 'opengl' allows gxine/xine to work
with compiz in RGB.

Kaffeine, on the other hand says that 'opengl' isn't valid (for some
obscure reason), even though it seems to work in the correct colourspace
and 'opengl' is offered as a valid driver in xine parameters.

But try this!

* run compiz
* set gxine and kaffeine's video drivers to auto.
* start gxine on some movie/vmw - it comes up in CMYK
* now start kaffeine and look at some DVB program (or another wmv).
* kaffeine comes up in RGB *and* resets the still playing gxine to RGB!.
* do it the opposite way round and kaffeine starts in RGB, but ends up
changing to CMYK when gxine starts.

Dirk

Revision history for this message
gkvas (gernot-kvas-at) wrote :

I'm running Hardy on an Lenovo X61 and the same happens in xine. Desktop effects are set to "None". Chipset is Intel 965GM. Setting xine from "auto" to opengl fixes the problem as far as xine is concerned.

Gernot

Revision history for this message
Chocwise (chocwise) wrote :

I confirm this Bug.
I use Compiz Fusion on my Hardy. I wasn't able to see if special Video's changed the colors. It seems to happen at random to me, when I start a video.
Changing from auto to opengl in gxine works for me as well.
My System: Intel Core 2 Duo 2x 2,2 GHz, Nvidia GeForce 8600 GT with the Nvidia-Drivers from the restricted Repository.

Thanks to Dirk for the Workaround with the gxine-Settings. Without that I'd have to restart X to get back the normal colors. :)

Revision history for this message
Bryce Harrington (bryce) wrote :

This is sort of sounding like a graphics library issue, not necessarily an xorg bug so closing this component.
If it turns out that this can be demonstrated to be an Xorg issue please feel free to reopen this component.

Changed in xorg:
status: New → Invalid
Revision history for this message
Ajo Paul (ajopaul01) wrote :

I can confirm this on Hardy upgrade nvidia 8400M GS and compiz running. The only workaround I have right now is by using nvidia-settings -> Xserver-color-correction and selecting Reset Hardware Defaults. Post which I get normal color during video playback in vlc/mplayer/xine/totem

Revision history for this message
Ajo Paul (ajopaul01) wrote :

my xorg.conf

Revision history for this message
David Nemeskey (nemeskeyd) wrote :

Is this still an issue for you? It had been for me until like a week ago. Then xv began working again. I don't know what happened, I kind of remember two changes that could possibly induce the change:
1. I think there was a kernel update recently
2. I installed realplayer from the web site. But this should not have any effect on the system libraries, should it?

Revision history for this message
Magnus S (magnuss) wrote :

Hi all, is this still a problem in Hardy(up-2-date) or Intrepid?

//magnus

Changed in vlc:
status: New → Incomplete
Daniel T Chen (crimsun)
Changed in compiz:
status: New → Incomplete
Changed in xine-ui:
status: New → Invalid
Changed in mplayer:
status: New → Invalid
Changed in vlc:
status: Incomplete → Invalid
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package nvidia-graphics-drivers-180 - 180.22-0ubuntu1

---------------
nvidia-graphics-drivers-180 (180.22-0ubuntu1) jaunty; urgency=low

  * New upstream version. First "stable" driver in 180 series. (LP: #315169)
    * Added support for the following GPUs:
          o Quadro FX 2700M
          o GeForce 9400M G
          o GeForce 9400M
          o GeForce 9800 GT
          o GeForce 8200M G
          o GeForce Go 7700
          o GeForce 9800M GTX
          o GeForce 9800M GT
          o GeForce 9800M GS
          o GeForce 9500 GT
          o GeForce 9700M GT
          o GeForce 9650M GT
          o GeForce 9500 GT
    * Added initial support for PureVideo-like features via the new VDPAU API (see the vdpau.h header file installed with the driver).
    * Added support for CUDA 2.1.
    * Added preliminary support for OpenGL 3.0.
    * Added new OpenGL workstation performance optimizations.
    * Enabled the glyph cache by default and extended its support to all supported GPUs.
    * Disabled shared memory X pixmaps by default; see the "AllowSHMPixmaps" option.
    * Improved X pixmap placement on GeForce 8 series and later GPUs.
    * Improved stability on some GeForce 8 series and newer GPUs.
    * Fixed a regression that could result in window decoration corruption when running Compiz using Geforce 6 and 7 series GPUs. (LP: #306605)
    * Fixed an nvidia-settings crash when xorg.conf contains Device and Screen sections but no ServerLayout section.
    * Fixed a problem parsing the monitor sync range X config file options.
    * Fixed a problem with the SDI sync skew controls in nvidia-settings.
    * Fixed a problem that caused some SDI applications to hang or crash.
    * Added support for SDI full-range color. (LP: #218736)
    * Improved compatibility with recent Linux kernels.
  * debian/rules:
    - Create patches directory in case it wasn't present in orig.tar.gz

 -- Mario Limonciello <email address hidden> Thu, 08 Jan 2009 14:26:09 -0600

Changed in nvidia-graphics-drivers-180:
status: Incomplete → Fix Released
Revision history for this message
Ansus (neptunia) wrote :

Confirming the same bug in nvidia-180.29

Revision history for this message
Ansus (neptunia) wrote :

Confirming the same bug in nvidia-180.29 and Intrepid. All colors in video playback programs are in inverse palette.

Changed in nvidia-graphics-drivers-180:
status: Fix Released → Confirmed
Revision history for this message
Bryce Harrington (bryce) wrote :

[This is an automated message]

In Jaunty (9.04), we have just updated to the latest
nvidia-graphics-drivers-180 package from nVidia, version 180.44.

This package provides fixes for a large number of bugs, and we need your
assistance in testing if it fixes the issue you reported.

To do this, please do the following:

 a. Update to the 180.44 version of -nvidia using your favorite update
     method

 b. Attempt to reproduce your bug

 c. If your bug still remains, please simply reply to this email
     indicating so.

 d. If your bug is now solved, you can help us by setting your bug
     report to Fix Released:
     * In launchpad, go to your bug report
     * Click on the downward pointing arrow under Status
     * Set the Status field to 'Fix Released'
     * Comment on the change, such as, 'Verified fixed in 180.44'
     * Click 'Save Changes'

 e. If the original problem is solved but there are now other problems,
     please close the original bug and open new ones for those issues.

Thank you!

For details on the changes in this version of -nvidia, please see:

   http://www.nvidia.com/object/linux_display_ia32_180.44.html

Revision history for this message
Bryce Harrington (bryce) wrote :

I've posted a new version of the -nvidia driver to our xorg-edgers PPA,
would you mind testing it either on Jaunty or Karmic and see if it
resolves this bug?

Get nvidia-graphics-drivers-180 - 185.18.14 here:

  https://edge.launchpad.net/~xorg-edgers/+archive/ppa

Changed in nvidia-graphics-drivers-180 (Ubuntu):
status: Confirmed → New
status: New → Incomplete
Revision history for this message
Bryce Harrington (bryce) wrote :

We're closing this bug since it is has been some time with no response from the original reporter. However, if the issue still exists please feel free to reopen with the requested information. Also, if you could, please test against the latest development version of Ubuntu, since this confirms the bug is one we may be able to pass upstream for help.

Changed in nvidia-graphics-drivers-180 (Ubuntu):
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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