Bug 72821 - xv playback on glamor shows wrong colors
Summary: xv playback on glamor shows wrong colors
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Acceleration/glamor (show other bugs)
Version: git
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Dave Airlie
QA Contact:
URL:
Whiteboard:
Keywords:
: 73765 74811 77079 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-12-18 05:41 UTC by Kertesz Laszlo
Modified: 2014-06-17 20:03 UTC (History)
7 users (show)

See Also:
i915 platform:
i915 features:


Attachments
vdpau playback showing the right colors (91.91 KB, image/jpeg)
2013-12-18 05:41 UTC, Kertesz Laszlo
no flags Details
xv playback showing the wrong colors (102.09 KB, image/jpeg)
2013-12-18 05:42 UTC, Kertesz Laszlo
no flags Details

Description Kertesz Laszlo 2013-12-18 05:41:32 UTC
Created attachment 90908 [details]
vdpau playback showing the right colors

Using the latest glamor git (build gfb4d046) xv playback shows wrong colors. This appeared after the latest batch of commits. 
I suspect this one (no time to bisect ATM):

75ea1b30117450ff1b2b34bc14acbcf4f466694d 
glamor: fix leak in xv code

Other playback methods, such as vdpau or opengl is fine.
This is a problem since certain applications use the xv overlay (such as Jitsi or gstreamer-based ones) with no option of changing it.

The hardware is A8-5500 / Radeon 7560D (uses the r600 driver), running 64 bit Debian Testing, kernel, mesa, drm, glamor, xf86-ati from git.
Comment 1 Kertesz Laszlo 2013-12-18 05:42:12 UTC
Created attachment 90909 [details]
xv playback showing the wrong colors
Comment 2 Kertesz Laszlo 2013-12-18 12:10:13 UTC
I reverted 75ea1b30117450ff1b2b34bc14acbcf4f466694d and xv playback is ok now.
Comment 3 Alex Deucher 2014-01-16 17:01:50 UTC
I can't seem to reproduce this.  Can you provide a problematic video?  Does updating your mesa stack help?
Comment 4 Kertesz Laszlo 2014-01-18 11:02:23 UTC
(In reply to comment #3)
> I can't seem to reproduce this.  Can you provide a problematic video?  Does
> updating your mesa stack help?

Well it isnt that simple it seems. The corruption isnt a fixed one, it appears in certain cases.
One is using Jitsi with video calls (Jitsi is a java-based app, but uses native libraries too - all video playback is xv on Linux). At first the colors are ok, but after a few video calls (or, it seems, just looking at the webcam's output) the colors start look like in those images i posted. 
So, if Jitsi starts to show wrong colors and it has an active video call or active overlay (such as looking at the webcam output), during that time other programs playing xv videos are fine. But after the Jitsi's playback is closed, all other players start to exhibit color issues.

Another thing i observed is that sometimes the colors are almost right on the actual video (this is afer i closed Jitsi), but there is a static overlayed image in the left corner (or all image if the previous video was bigger), composed of blue, yellow, red or green components, remained there from previous wrong-colored xv playbacks (presumably the last frame?). Other videos have only certain color overlays offset (black and white component is ok).

This issue wasnt present until i created this bug. I use today's git mesa, glamor, xf86-video-ati with 3.13.0-rc8-00057-g6b4f655 kernel from git and its the same as back then.
Comment 5 Kertesz Laszlo 2014-01-18 11:09:47 UTC
(In reply to comment #2)
> I reverted 75ea1b30117450ff1b2b34bc14acbcf4f466694d and xv playback is ok
> now.

I was wrong about this, see the above comment.
Comment 6 Alexander Tsoy 2014-01-18 14:48:14 UTC
I can confirm this bug. It's reproducible with certain videos.
Comment 7 Alexander Tsoy 2014-01-18 14:59:45 UTC
(In reply to comment #6)
> It's reproducible with certain videos.

Hmm.. All videos taken from Nikon D90 :) I'll upload samples.
Comment 8 Alex Deucher 2014-01-18 17:23:44 UTC
*** Bug 73765 has been marked as a duplicate of this bug. ***
Comment 9 Alexander Tsoy 2014-01-18 20:38:52 UTC
(In reply to comment #7)
> I'll upload samples.

As it turned out, it's actually not easy, because on many videos the problem is rarely reproducible. I have several videos where the problem is 100% reproducible, but I can't share them.
Comment 10 Alexander Tsoy 2014-01-18 21:52:34 UTC
How about this video (13 Mb)?
http://tsoy.me/pub/bug-72821.avi
Comment 11 Eugene 2014-01-18 22:51:49 UTC
(In reply to comment #10)
> How about this video (13 Mb)?
> http://tsoy.me/pub/bug-72821.avi

It's affected too. Do you need screenshots ?
Comment 12 Kertesz Laszlo 2014-01-19 07:28:00 UTC
(In reply to comment #10)
> How about this video (13 Mb)?
> http://tsoy.me/pub/bug-72821.avi

Yep, it looks bad, played with mpv -vo xv. Good with vdpau.
I noticed that the corruption that sometimes carries out to other videos (that otherwise are fine) clears up after some time.
Comment 13 Alex Deucher 2014-04-07 02:38:21 UTC
*** Bug 74811 has been marked as a duplicate of this bug. ***
Comment 14 Alex Deucher 2014-04-07 02:38:45 UTC
*** Bug 77079 has been marked as a duplicate of this bug. ***
Comment 15 Grigori Goronzy 2014-06-17 20:03:48 UTC
This should be fixed with commit 081a5370.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.