Bug 42727 - Blinking bottom line with mplayer's XV backend[SNA]
Summary: Blinking bottom line with mplayer's XV backend[SNA]
Status: NEW
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
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-08 16:30 UTC by Clemens Eisserer
Modified: 2013-10-15 20:28 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
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

Note You need to log in before you can comment on or make changes to this bug.
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
libdrm-2.4.27
pixman-0.23.8
linux-3.1.0
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:

http://youtu.be/KKsSxoogq4s
Comment 8 Chris Wilson 2011-11-09 02:46:21 UTC
Oh, that line! ;-)

gotcha.
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 :/


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.