Bug 87455

Created attachment 111005 [details]
another screenshot of 3 mplayer windows.

This is from xv/vdpau/x11 playback of an BBC iplayer video; the positioning of the 3 are different from the last, but the one with corruption of the right side is the xv- one, the one with the fullest width is the x11- unaccelerated one.

Comment on attachment 111005 [details]
another screenshot of 3 mplayer windows.

wrong mime type...

Created attachment 111006 [details]
tgz's of *info output

7 files from the various *info commands output. I was just doing most of the /usr/*bin/*info's that looks relevant. xwininfo is against one of the mplayer windows, but the rest are for the whole graphic system, I hope.

$ tar -czpvf /tmp/infos.tgz *-out
glxinfo-out
vdpauinfo-out
visualinfo-out
xdpyinfo-out
xdriinfo-out
xvinfo-out
xwininfo-out

I just realised that the corruptedness might be a generic problem with accelerated playback. While xv is obviously very bad, it appeared that the extra right margin in vdpau video playback is also filled with gabbage at launch, but mplayer somehow clears it as playback starts. It is merely not cleared in the xv  case.

Created attachment 115028 [details]
1MB webm test video file from youtube

first 1MB of the video of the screen shots shown in:

https://bugs.freedesktop.org/attachment.cgi?id=111004

ffplay, mplayer, cvlc all will play just the 1st 1MB of the file, so this works as a smaller test file than the original

(13968782 bytes downloaded from https://www.youtube.com/watch?v=GT_s-1A5kBE with youtube-dl).

Created attachment 115029 [details]
screeshot of that video played with vlc using x-video as output device

here vlc with x-video is corrupted in the same way as mplayer -vo xv and -vo sdl.

I am showing it here as vlc with sdl is different from mplayer with -vo sdl, and vlc with xv.

Created attachment 115030 [details]
screeshot of that video played with vlc using sdl

interestingly enough, vlc with sdl is almost correct (unlike vlc xv, mplayer xv, and mplayer sdl), except with a green band bottom and right border.

I have worked out that the problem with the youtube video is two issues - the skewed corruptedness (or green bottom and right border for vlc + sdl) is a separate issue from the black left-right border on mplayer.

The black left-right border on mplayer seems to be mplayer-specific with the x.
if I comment out the PAspect line near line 1000 of libvo/x11_common.c for XSetWMNormalHints():

//vo_hint.flags |= PAspect;
...
XSetWMNormalHints(mDisplay, vo_window, &vo_hint);

The left-right black border for mplayer would go away. Somehow gnome-shell seems to take PAspect the wrong way, I think, though XSetWMNormalHints() belongs to libX11?

(In reply to Hin-Tak Leung from comment #5)
> Created attachment 115028 [details]
> 1MB webm test video file from youtube

can somebody have a go playing this video with mplayer or vlc with xv and see if they see a skewed video?

Here are two more videos which are interesting and different from the previous, in that mplayer + xv plays corrupt, but vlc + xv simply refuses to play. (but mplayer + x11 and vlc + sdl are happy playing them).

Created attachment 115031 [details]
another video, mp4, plays b/w with color shifted elsewhere.

The video should show a red boot towards the end. mplayer + xv shows largely b/w but seemingly okay video with the red color shifted elsewhere; vlc + xv refuses to play.

mplayer + x11 or vlc + sdl are okay with it.

Created attachment 115032 [details]
3rd video, mp4 showing skewed playback

mplayer + xv playback skewed, while vlc + xv refused to play. player + x11 and vlc + sdl are okay.

Comment on attachment 115031 [details]
another video, mp4, plays b/w with color shifted elsewhere.

correcting mine-type.

Fixed in xserver 1.17:

commit 70a6f65f9e2b26ef7539dcacfcfea927bc1f13fd
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Thu Dec 25 11:42:03 2014 +0900

    glamor: Make sure Xvideo source image data is properly aligned
    
    _glamor_upload_bits_to_pixmap_texture currently ignores the stride
    parameter, but __glamor_upload_pixmap_to_texture uses 4-byte alignment
    via glPixelStorei(GL_UNPACK_ALIGNMENT, 4).
    
    Also fix up the stride argument passed in though, in case it starts
    being used properly in the future.

Created attachment 115169 [details] [review]
back-ported patch to xserver 1.16.3

back-ported the relevant comment to 1.16.3 and rebuilt the fedora rpm (I reckoned it is easier to patch the X server than to upgrade it plus hunting down
all the other bits that needs upgrading from 1.16 -> 1.17). And indeed, now video playback is correct except for the border issue I wrote about in comment 8.

For the border issue I tried switching to a different window manager - both gnome-shell/clutter and mutter are broken, but it works correctly under fvwm, so that appears to be a cluter/mutter-specific issue. I shall file that with fedora and how that they move it upstream etc.

Thanks a lot for the fix - I realized it was fixed a week after I filed - would have been nice to make a note here then :-).

(In reply to Hin-Tak Leung from comment #15)
...
> For the border issue I tried switching to a different window manager - both
> gnome-shell/clutter and mutter are broken, but it works correctly under
> fvwm, so that appears to be a cluter/mutter-specific issue. I shall file
> that with fedora and how that they move it upstream etc.
...

That issue was filed as
https://bugzilla.redhat.com/show_bug.cgi?id=1213021
and fixed in gnome 3.16
https://git.gnome.org/browse/mutter/commit?id=cb66ab5a87251b21

I applied the fix to 3.14.4 and it works correctly now.