Bug 78827 - [uxa hsw] xv video corrupted
Summary: [uxa hsw] xv video corrupted
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
Depends on:
Reported: 2014-05-17 12:58 UTC by Tom Horsley
Modified: 2019-11-27 13:33 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

photo of corrupted mplayer window (437.23 KB, image/jpeg)
2014-05-17 17:15 UTC, Tom Horsley
no flags Details
Xorg.0.log (36.74 KB, text/plain)
2014-05-17 17:17 UTC, Tom Horsley
no flags Details
Xorg.0.log with SNA enabled (22.88 KB, text/plain)
2014-05-17 22:35 UTC, Tom Horsley
no flags Details

Description Tom Horsley 2014-05-17 12:58:08 UTC
I see several bugs against various linux distros about the video corruption problem that appeared on intel graphics when the 3.14 kernel arrived, but I don't see an upstream bug here, so I'm making this one. Details of the problem can be found in various other bug reports:




Only seems to affect "xv" video, gl rendering is OK (and a good work around), but xv seems to be the default for most players, so it gets noticed.
Comment 1 Chris Wilson 2014-05-17 16:09:31 UTC
Please attach your Xorg.0.log.
Comment 2 Chris Wilson 2014-05-17 16:09:46 UTC
And a screenshot or photograph.
Comment 3 Tom Horsley 2014-05-17 17:15:35 UTC
Created attachment 99223 [details]
photo of corrupted mplayer window

If I take a screenshot, the image provided in the screenshot is not corrupt (which probably says something about where the problem is). This is a photo I took of the screen while playing the video for the Doctor Who episode "Blink" with mplayer using the -vo xv option.

Horizontal bands seem to be leftover from old frames trying to catch up. In fact, if I pause the video, in a few seconds they will manage to catch up and everything will look normal till I start playing again.
Comment 4 Tom Horsley 2014-05-17 17:17:14 UTC
Created attachment 99224 [details]

There are other copies of the log and dmesg and wot-not in the bugzillas pointed at. Perhaps they have something in common.
Comment 5 Chris Wilson 2014-05-17 19:39:03 UTC
You are all using hsw + uxa. UXA Xv uses textured video, which should mean that there is no discrepancy between the GetImage screenshot and the image.

Are you using any form of compositing?

Have you tried a more recent driver with the switch to SNA? (That at least would provide us with more diagnostics.)
Comment 6 Tom Horsley 2014-05-17 22:20:46 UTC
I don't know what the ksnapshot tool uses to take a screenshot, but it definitely shows an image without the banding (using gimp for screenshot has the same results - no banding).

I'm running a plain fvwm session with no compositing or any kind of fancy eye candy.

I see the debian bug says that adding an xorg.conf.d file to force SNA did fix the problem. I haven't tried that yet.
Comment 7 Tom Horsley 2014-05-17 22:35:47 UTC
Created attachment 99253 [details]
Xorg.0.log with SNA enabled

OK I created the file /etc/X11/xorg.conf.d/intel.conf with this content:

Section "Device"
   Identifier  "Intel Graphics"
   Driver      "intel"
   Option "AccelMethod" "sna"

Then I rebooted and I can indeed play video now with mplayer -vo xv without the banding effect. Attached is the new Xorg.0.log file from booting with intel.conf.
Comment 8 Martin Peres 2019-11-27 13:33:35 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-intel/issues/29.

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.