GNOME Bugzilla – Bug 357741
[xvimagesink] Inverted Color Channels with ATI
Last modified: 2007-08-01 07:35:02 UTC
Distribution: Ubuntu 6.06 (Dapper Drake) Color Channels in totem-gstreamer (1.4.3-0ubuntu1 version) seem to be inverted, everything else works normal (even hue controls). Totem-xine works fine. Hardware related: ATi X1800XL and X1800 Mobility One user with nVidia card has the same problem, and gxine does the same if he uninstalls totem-gstreamer
I agree. I have an Nvidia 5600 and using either the 'nv' or 'nvidia' driver, using Totem with totem-gstreamer or Gxine with xine-gstreamer, the colors are off. Only until I remove Totem-gstreamer and reboot, will Gxine colors be correct. I've narrowed it right down to Totem-gstreamer. Colors are corrupt :(
I apologize about 'xine-gstreamer'. I meant Gxine with what ever backend it uses doesn't work until I remove 'totem-gstreamer'. The colors are off and I've narrowed it down to 'totem-gstreamer' as being the problem. In the end, I know the problem is with 'totem-gstreamer' and when I remove it and do a reboot, Gxine colors are perfect. Sorry for the mistake.
What do you mean by 'inverted'? Can you fix it by adjusting the hue etc. in the preferences dialog? If you reboot and then do this from a command line after logging into X/Gnome/your desktop: $ gst-launch-0.10 videotestsrc ! xvimagesink videotestsrc ! ximagesink do both look the same? The colours in the top row should be (from left to right): white, yellow, turquois/cyan, green, magenta, red, blue. Is this the same as bug #306621?
If I take a screenshot, the screenshot comes out in the right color but the actual video color is far different. I tried to take a system screenshot but the video display area of Totem doesn't show, otherwise you would be able to see a huge difference in color. I ran the following $ gst-launch-0.10 videotestsrc ! xvimagesink videotestsrc ! ximagesink and had two small color test boxes come up. One comes up in what seems to be the right colors *but* the colors in the second box are far off. From left to right and top to bottom, this is how I can best describe them. 1st row: white, light blue, pink, lavendar, green, dark green, black. 2nd row: black (hint of red), black, green, black, pink, black, white 3rd row: black (hint of red), white, black, black, black, snow box I tried to take a screenshot of the two boxes *but* the box with the colors off don't show up in the screenshot at all. I thought I would paste the colors and show them off *but* the second box just doesn't show up in the screenshot :( if you would like any more information, just tell me what and how to get it and I'll paste it back for you. Thank you!
Sorry, I just checked out the bug you linked too http://bugzilla.gnome.org/show_bug.cgi?id=306621 I don't think the problem is the same *but* the idea of lowering the hue slider to 0 makes all the colors in Totem look fine. I hope this helps!
@Tim: It's not moved hue, more like blue+red inversion. Where red should be displayed there is blue and vice-versa, you can move hue to match the skin color to a normal one, but this will move other colors so it's not a solution. i'll try your suggestion though.
Ximagesink displays regularly (as you said it would) Xvimage sink however: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 141 (XVideo) Minor opcode of failed request: 19 () Value in failed request: 0x3a00003 Serial number of failed request: 56 Current serial number in output stream: 57
Another update ... the guy that had this problem with the nVidia driver was more related to the bug posted here by tim. This is more ATi specific and the "Hue fix" doesn't work (if you have an nVidia card, try to move the hue to zero) and this bug doesn't happen with ubuntu's iregular ati driver (it happens with fglrx) and it works when you're on an XGL session. it might be something around the combination of fglrx->totem-gstreamer.
Created attachment 73463 [details] windows
Created attachment 73464 [details] ubuntu
hi I want to confirm the bug. Well the hole thing was disgussed [url=http://www.ubuntuforums.org/showthread.php?t=254264]here[/utl] before the reporter of the bug reported it here. I ran the two commands mentioned above and everything worked fine for both. I am the owner of the X1800XL mentioned above and I am using Ubuntu 6.06 and Ati's drivers 8.29.6 and totem-gstreamer 1.4.3(gstreamer0.10.6). The hue thing doesn't work. I also provide you with two screenshots that show the problem the first is under Windows and the second one is under Ubuntu. But something interesting happens. When I tried taking the screenshot under Ubuntu and using in totem the command "Edit->Take Screenshot..." the preview of the screenshot was showing the image with the right colors while the player with the wrong ones(shown on pic2-ubuntu.jpg). I had to use the "print screen" in order to take the screenshot with the wrong colors.
Oh man everything is mess up. The two preceding screenshots are the ones mentioned on the above reply.
Some more update. I think the problem is actually located in Gstreamer and not Totem. That's because when I run gstramer from command-line using this "gst-launch playbin uri=file:///home/joe/my-random-media-file.mpeg" the same problem occurs.
I can confirm two things in which Hammered mentioned. 1. The attached screenshots is exactly what happens. I see the correct colors in Gxine *but* the busted colors in Totem. 2. Although Totems colors are distored, the actual screenshot of the image from Totem itself looks fine. I have an Nvidia card so sliding the HUE slider all the way to the left (0?) corrects the colors although on the forum in which Hammered posted, this fix does not work on an ATI card. Hope to see this fixed soon. Any information needed, just ask for it and possibly how to get it if it is real technical :) Thank you :)
I can corroborate the screenshot fact. On nvidia: Have you tried checking the original colors against the "Hue 0" colors in totem-gstreamer? maybe some colors match but not all of them, it would be nice to see. Question, should we close this bug and send it to Gstreamer only? not just totem-gstreamer?
> Question, should we close this bug and send it to Gstreamer only? not just > totem-gstreamer? Let's re-assign it to GStreamer. So, just to summarise so far and since I'm a bit confused now: - the issue with the nVidia card is covered by bug #306621, right? (since you can fix the colours by fiddling with the sliders, right?) If yes, then let's keep this bug focused on the issue with the ATI card/drivers. Also, has anyone tested this with edgy or GStreamer CVS?
I own the Nvidia card and after comparing my issue to bug #306621, I can probably say my problem is 99% relevant to it as it can easily be fixed by sliding the hue slider to 0. Sorry for duping it here and I still hope the problem here gets fixed. Thanks fellas and good luck!
I haven't tested it with edgy or a cvs build of gstreamer.
This is likely an X bug. The drivers appear to be confusing the U and V channels.
*** Bug 361587 has been marked as a duplicate of this bug. ***
more info from bug #361587 : I have the same problem with an ATI X1600 it seems to be because the driver exposes to video/x-raw-yuv fourcc in its caps (I420 and YV12), but doesn't handle properly I420. as a workaround, I added near xvimagesink.c:1306 case XvYUV: if (formats[i].id == GST_MAKE_FOURCC ('I','4','2','0')) break; which removes I420 from the caps list. then the format is removed from the list, "YV12" is chosen instead, and everything works as expected.
forgot to mention, though I had the problem in Dapper right out of the box, the problem seems to have gone away for me in Edgy. I am the user with the Nvidia card. Thanks!
*** Bug 364737 has been marked as a duplicate of this bug. ***
problem persists with Edgy (Ubuntu 6.10) and ATI drivers v8.30.3
I have the same problem: totem (and mythtv) shows shifted colors and xine shows the colors normally. I have a Fedora Core 6 system, ati fglrx 8.31.5 on a sapphire 1950xt I noticed the problems first in mythtv where live tv showed shifted colors while the mpgs recorded by mythtv (through the wintv 500 card) play normally in xine. changing hue or color or gamma does not help. I have spent a day searching and trying different solutions but nothing seems to work, seems like a real bug :-) really hope this gets solved soon :-)
by the way the color are displayed it might be as simple as an endianness problem. red and blue seem to be switched while green seems to be ok.
edgy and 8.31.5 = same problem. Also I sent feedback to ATI pointing back to this thread. I hope they can help.
Fedora Core 6 with 8.33.6 = same problem
Ubuntu 6.10 + 8.33.6 = same problem (I am glad to see this isn't ubuntu-specific bug)
I can confirm this bug also, using an ATI X1300 mobility on ubuntu 6.10 and 8.33.6 driver. Also, some more to add: Normally, using mplayer with xv video output is fine, as is the $gst-launch-0.10 videotestsrc ! xvimagesink videotestsrc ! ximagesink pipeline (with a small exception of one of the bottom colours being slightly more purple on the xvimagesink than on the ximagesink). If, however, I run totem, then until a reboot mplayer shows the funny colours. Using gl2 output solves the problem from a user perspective. This also causes the pipeline above to produce funny colours. I have been doing some hacking on pipelines with an xvimagesink, and I can say that the following pipeline seems to give the same problem (from cold - ie before totem has caused the problem): $gst-launch-0.10 -v filesrc location=photo.jpg ! jpegdec ! freeze ! ffmpegcolorspace ! xvimagesink I will confirm this behaviour when I have a moment, and whether it results in the same system wide changes. So, in conclusion, xv seems to be fine on the system until gstreamer triggers something, when all programs that use xv start exhibiting the bug.
Henry: I think what you're seeing is a different issue, which I think might have been fixed (maybe it was #354773, but there was also another bug I can't find right now). The main issue in this report seems to be a driver bug, ie. not swapping chroma planes for YV12 vs. I420 format. mplayer usually uses YV12, we usually use I420, that's why mplayer "gets it right" (=luck).
So has ATi been informed of the bug in their drivers? Ubuntu Feisty testing + 8.32.5 = Same problem
After reading the comments about YV12 vs. I420 colour formats, and playing about with gstreamer-properties, I found a workaround (for those who don't like watching blue videos!): * open up gstreamer-properties * change the video output plugin to custom * change the video output pipeline to: ffmpegcolorspace ! video/x-raw-yuv,format=(fourcc)YV12 ! xvimagesink Then open up Totem, and play a video full screen. It hopefully shouldn't flicker (which it probably would do if you were using ximagesink); and the video should have the correct colours.
I was thinking something similar to that but I am no expert and I didn't know where to start. Thank you for your simple workaround. Unfortunately, I don't have my PC(with the Ati card) because it is for repair. When, I get it back I will inform you if this works.
I got back my PC(with the Ati card) and your workaround works just fine. I also replaced "YV12" with the "I420" and I got back the "funny colors".
(In reply to comment #33) > After reading the comments about YV12 vs. I420 colour formats, and playing > about with gstreamer-properties, I found a workaround (for those who don't like > watching blue videos!): > > * open up gstreamer-properties > * change the video output plugin to custom > * change the video output pipeline to: > ffmpegcolorspace ! video/x-raw-yuv,format=(fourcc)YV12 ! xvimagesink > > Then open up Totem, and play a video full screen. It hopefully shouldn't > flicker (which it probably would do if you were using ximagesink); and the > video should have the correct colours. > I tried this (FC6, 8.33.6) and it work with totem, but not with MythTV
I confirm the same problem Feisty Fawn Beta Totem 2.18.0 GStreamer 0.10.12 ATI fglrx drivers
I'm not sure why this bug is still open, since it's not a GStreamer bug. I've written a little test script that can be used on a system with a suspicious X driver to determine if the driver is buggy. http://www.schleef.org/~ds/xvideo_test In particular, it is known that some versions of the fglrx drivers are buggy. I'd appreciate it if someone could install the latest version and indicate whether they're still buggy (using the script, please), including the version number.
David, well that's natural since people complain about things they know and this artifact appears only with GStreamer (no VLC for example). Thank god I didn't file a bug for Totem ;) This happens with the latest ATI drivers. From ATI support: ATI Driver Installer 47.4MB 8.34.8 Feb. 21, 2007 Automated installer and Display Drivers for XFree86 4.3 and X.Org 6.7, 6.8, 6.9, 7.0, 7.1 moo@hacker:~$ fglrxinfo display: :0.0 screen: 0 OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: ATI Mobility Radeon X1600 OpenGL version string: 2.0.6334 (8.34.8) I'll bug ATI about the issue.
Thanks for the info, Mikko. Closing this bug, since it's not a GStreamer issue, and there's a workaround in comment #33.
and it is fixed (at last!) in ati driver 8.39.4 OpenGL version string: 2.0.6650 (8.39.4)