[gm45] Xv video falls apart and flickers when obstructed by 2 windows

Can you please attach an Xorg.0.log so that I have details of your system?

Sure

started X11, played a video, obstructed it, closed X11

I've tried reproducing this on a few different machines without success. Are there any further steps required?

Ah.. It is actually dependent on the theme selected in fluxbox.

It happens only with themes that have round window corners (bora_*, zimek_*)

Did that help?

PS: pekwm's default theme also has round corners.

PS2: The video can be even in a paused state.
(in VLC that doesn't even stop the flickering, while in mplayer2 it does.
But the way how the frame is damaged changes with the position of the obstructing windows)

For very small dialogs of fluxbox's "fbrun" it doesn't seem to matter where are they positioned, as long as they are completely inside the Xv window and don't overlap each other.
This might be related to the fact that fluxbox automatically puts it in the topmost "above dock" layer.

xterm's windows seem to be a bit more picky

Thanks, with the shaped windows I can reproduce the corruption.

commit 3d7e16addb2fb5f35936aafe8e16685a91d30f59
Author: Chris Wilson <email address hidden>
Date: Tue Apr 2 10:58:52 2013 +0100

    sna/gen4: Break the Video rendering loop into 16 rectangle chunks

    If we feed more than 16 rectangles into the video rendering pipeline,
    the GPU goes crazy and starts emitting corruption. Lalalala.

    Bugzilla: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1162046
    Signed-off-by: Chris Wilson <email address hidden>

This bug was fixed in the package xserver-xorg-video-intel - 2:2.21.6-0ubuntu1

---------------
xserver-xorg-video-intel (2:2.21.6-0ubuntu1) raring; urgency=low

  * Merge from unreleased debian git
    - new upstream minor release (LP: #1162046)
 -- Timo Aaltonen <email address hidden> Tue, 09 Apr 2013 17:31:20 +0300

The fix arrived with the updates today.
Most of the corruption is gone. Almost all the frames now get though undamaged.
Thanks for the fix.

BUT

Some of the video frames still get damaged when drawn.
However, it does depend on the video content (and possibly on (absolute) window positions)

I attach a short captured dvb-t video to be played with mplayer2 using Xv output
and a picture with the example fbrun dialogue positions.

Steps:
Fluxbox with a round-cornered theme.
mplayer2 with the testcase.ts file, pause it as soon as it starts
fbrun #1, so it's bottom-left corner perfectly matches with the mplayer2's bottom-left corner
fbrun #2 somewhere in the video area, preferably far from the fbrun #1
unpause mplayer.

I observed damage between fbrun #2 and the right edge of the Xv video.

Notes:
fbrun's windows don't seem to be resizeable, mplayer opens a window 1:1 to the input (so, exactly defined again)

It seems to depend a bit on the position of the Xv window on the screen.
It does rarely work when the Xv is close to screen edges
 => preferably position the Xv window somewhat in the middle of the screen.

PS:
Alternatively you can start mplayer with "-fixed-vo -loop 0" as arguments for mplayer instead of pausing/unpausing
That will give you a continuous loop in the same Xv window.

The remaining corner case described in comment#10 is now filled as #1170117

The attachments related to that corner case were moved to that bug.