Bug 42727 - Blinking bottom line with mplayer's XV backend[SNA]
Summary: Blinking bottom line with mplayer's XV backend[SNA]
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Chris Wilson
QA Contact: Intel GFX Bugs mailing list
Depends on:
Reported: 2011-11-08 16:30 UTC by Clemens Eisserer
Modified: 2019-11-27 13:28 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

screenshot, pixel-line marked with red arrows (10.73 KB, image/png)
2011-11-08 16:30 UTC, Clemens Eisserer
no flags Details
screenshot of image scaled up, green line spans multiple pixels now (212.00 KB, image/png)
2012-10-08 08:47 UTC, Clemens Eisserer
no flags Details
stale video data at left corner (123.66 KB, image/png)
2013-01-29 10:26 UTC, Clemens Eisserer
no flags Details

Description Clemens Eisserer 2011-11-08 16:30:07 UTC
Created attachment 53308 [details]
screenshot, pixel-line marked with red arrows

When playing video using mplayer's XV backend, at certain video zoom levels there are a few pixels at the bottom blinking.

I suspect this is somehow related to bug 42412.
Comment 1 Clemens Eisserer 2011-11-08 16:30:30 UTC
sorry, forgot to mention:

intel i945GM
xorg 1.11.1
Comment 2 Chris Wilson 2011-11-09 01:27:10 UTC
Sounds like I've miscomputed the number of lines to copy. Do you have a specific command that reproduces the issue?
Comment 3 Clemens Eisserer 2011-11-09 01:33:45 UTC
The following steps worked for me:
1. mplayer -vo xv videofile.avi
2. press "f" to switch to fullscreen
3. change zoom mode with ctrl+w/e a few times until the line is shown

Works for me, however it seems to not happen with every video file.
Comment 4 Chris Wilson 2011-11-09 01:51:32 UTC
Ah, if I fullscreen after pressing ^E, then I get unredrawn borders upon pressing ^W (using awesome as the WM). Not sure if that is expected or not, the actual video content still looks correct.
Comment 5 Chris Wilson 2011-11-09 01:56:59 UTC
That seems to be an artifact of awesome more than anything else.
Comment 6 Clemens Eisserer 2011-11-09 01:59:38 UTC
The bottom line I see changes as the video plays, so I don't think its just not drawn.
Comment 7 Clemens Eisserer 2011-11-09 02:06:13 UTC
I am barely able to see it on my small and dark laptop screen, however on my 1920x1200 26' screen its quite irritating in dark scenes:

Comment 8 Chris Wilson 2011-11-09 02:46:21 UTC
Oh, that line! ;-)

Comment 9 Chris Wilson 2011-11-09 02:54:34 UTC
I've seen that before, just can't find a reproducing video right now.
Comment 10 Clemens Eisserer 2011-11-11 04:46:20 UTC
Any idea how I can send you a 350mb video file? maybe via scp or ftp to some non important intel owned machine?
Comment 11 Clemens Eisserer 2012-03-28 02:42:16 UTC
Watching a different video, I get that line on the right side.
Comment 12 Chris Wilson 2012-10-02 15:13:17 UTC
Still no closer to fix, my inclination is that the rounding for sending complete chroma samples is incorrect, though it like it does take all the alignment into account. I did find a few other potential sources of error, so Clemens could I ask you to verify whether this bug still exists?
Comment 13 Clemens Eisserer 2012-10-03 19:00:07 UTC
Unfourtunatly I can still reproduce this issue with gmplayer+intel-master.
The only difference was, the colored bar this time was on the right side.
Comment 14 Clemens Eisserer 2012-10-08 08:46:23 UTC
It seems when scaling the video, the misrendered area also grows as can be seen on the new screenshot.
Comment 15 Clemens Eisserer 2012-10-08 08:47:05 UTC
Created attachment 68247 [details]
screenshot of image scaled up, green line spans multiple pixels now
Comment 16 Chris Wilson 2012-10-08 08:56:20 UTC
Yes, that is consistent with me not feed the right number of pixels to create the textures (so it is reading and interpolating the border values, which is zero / green).
Comment 17 Chris Wilson 2012-10-08 13:37:01 UTC
Repeating with that example, can you please try:

diff --git a/src/sna/sna_video.c b/src/sna/sna_video.c
index 7bf20e9..22cde95 100644
--- a/src/sna/sna_video.c
+++ b/src/sna/sna_video.c
@@ -169,7 +169,7 @@ sna_video_clip_helper(ScrnInfoPtr scrn,
        frame->top = y1 >> 16;
        frame->left = (x1 >> 16) & ~1;
        frame->npixels = ALIGN(((x2 + 0xffff) >> 16), 2) - frame->left;
-       if (is_planar_fourcc(frame->id)) {
+       if (1||is_planar_fourcc(frame->id)) {
                frame->top &= ~1;
                frame->nlines = ALIGN(((y2 + 0xffff) >> 16), 2) - frame->top;
        } else

as a complete guess.
Comment 18 Clemens Eisserer 2012-10-08 13:47:24 UTC
Doesn't help unfourtunatly :/
Comment 19 Chris Wilson 2012-10-08 13:52:45 UTC
Whilst you are there, you might as well try aligning to blocks of 4 pixels (i.e. &~3 and ALIGN(, 4)).
Comment 20 Chris Wilson 2012-12-12 12:08:36 UTC
Do you know whether mplayer is padding it's source material? I just caught gstreamer1.0 doing that... Zero padding will cause a green bleed.
Comment 21 Clemens Eisserer 2013-01-29 09:59:11 UTC
With the latest round of changes, this got actually worse - I often get a stripe as large as ~50px. Probably mplayer is doing something stupid here...
Comment 22 Chris Wilson 2013-01-29 10:23:00 UTC
I can quite honestly say that's unexpected as I haven't touched the video paths in the last couple of months. :|
Comment 23 Clemens Eisserer 2013-01-29 10:26:43 UTC
Created attachment 73818 [details]
stale video data at left corner
Comment 24 Clemens Eisserer 2013-01-29 10:27:37 UTC
the left/top corner now often contains stale data which is only updated once at the time mplayer is switching to fullscreen.
Comment 25 Clemens Eisserer 2013-10-15 20:28:42 UTC
unfourtunately still alive :/
Comment 26 Martin Peres 2019-11-27 13:28:43 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/10.

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.