sorry, forgot to mention:

intel i945GM
libdrm-2.4.27
pixman-0.23.8
linux-3.1.0
xorg 1.11.1

Sounds like I've miscomputed the number of lines to copy. Do you have a specific command that reproduces the issue?

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.

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.

That seems to be an artifact of awesome more than anything else.

The bottom line I see changes as the video plays, so I don't think its just not drawn.

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

Oh, that line! ;-)

gotcha.

I've seen that before, just can't find a reproducing video right now.

Any idea how I can send you a 350mb video file? maybe via scp or ftp to some non important intel owned machine?

Watching a different video, I get that line on the right side.

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?

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.

It seems when scaling the video, the misrendered area also grows as can be seen on the new screenshot.

Created attachment 68247 [details]
screenshot of image scaled up, green line spans multiple pixels now

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).

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.

Doesn't help unfourtunatly :/

Whilst you are there, you might as well try aligning to blocks of 4 pixels (i.e. &~3 and ALIGN(, 4)).

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.

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...

I can quite honestly say that's unexpected as I haven't touched the video paths in the last couple of months. :|

Created attachment 73818 [details]
stale video data at left corner

the left/top corner now often contains stale data which is only updated once at the time mplayer is switching to fullscreen.

unfourtunately still alive :/

-- 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.