Bug 87455

Summary: corrupted xv video playback
Product: xorg Reporter: Hin-Tak Leung <htl10>
Component: Server/Acceleration/glamorAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
screen shot, of 3 mplayer window, bottom x11, top left vdpau, top right xv, all of the same video from youtube
none
another screenshot of 3 mplayer windows.
none
tgz's of *info output
none
1MB webm test video file from youtube
none
screeshot of that video played with vlc using x-video as output device
none
screeshot of that video played with vlc using sdl
none
another video, mp4, plays b/w with color shifted elsewhere.
none
3rd video, mp4 showing skewed playback
none
back-ported patch to xserver 1.16.3 none

Description Hin-Tak Leung 2014-12-18 19:12:15 UTC
Created attachment 111004 [details]
screen shot, of 3 mplayer window, bottom x11, top left vdpau, top right xv, all of the same video from youtube

It is better to explain with a screenshot. video playback via "mplayer -vo xv" is corrupted; -vo vdpau also seems be of a different size compared to x11.

Note the difference between the size of the image, as well as the presence of black border on either side of xv and vdpau playback. xv playback also has additional corruptedness on the right edge.

xorg-x11-server-Xorg-1.16.2.901-1.fc21.x86_64
mesa-libGL-10.2.9-2.20141104.fc21.x86_64
mplayer-1.1-31.20141020svn.fc21.x86_64
xorg-x11-drv-ati-7.5.0-1.fc21.x86_64

Note I am staying with mesa 10.2.9 as mesa 10.3.x/10.4.x seems to lock up the GPU often (https://bugzilla.kernel.org/show_bug.cgi?id=85421). The hardware is described there in.
Comment 1 Hin-Tak Leung 2014-12-18 19:16:54 UTC
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 2 Hin-Tak Leung 2014-12-18 19:18:09 UTC
Comment on attachment 111005 [details]
another screenshot of 3 mplayer windows.

wrong mime type...
Comment 3 Hin-Tak Leung 2014-12-18 19:23:03 UTC
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
Comment 4 Hin-Tak Leung 2014-12-19 16:56:31 UTC
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.
Comment 5 Hin-Tak Leung 2015-04-12 03:27:59 UTC
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).
Comment 6 Hin-Tak Leung 2015-04-12 03:31:58 UTC
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.
Comment 7 Hin-Tak Leung 2015-04-12 03:33:59 UTC
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.
Comment 8 Hin-Tak Leung 2015-04-12 03:43:36 UTC
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?
Comment 9 Hin-Tak Leung 2015-04-12 03:54:50 UTC
(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?
Comment 10 Hin-Tak Leung 2015-04-12 04:53:55 UTC
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).
Comment 11 Hin-Tak Leung 2015-04-12 04:57:06 UTC
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.
Comment 12 Hin-Tak Leung 2015-04-12 04:59:39 UTC
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 13 Hin-Tak Leung 2015-04-12 05:03:58 UTC
Comment on attachment 115031 [details]
another video, mp4, plays b/w with color shifted elsewhere.

correcting mine-type.
Comment 14 Michel Dänzer 2015-04-16 07:34:13 UTC
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.
Comment 15 Hin-Tak Leung 2015-04-17 22:51:31 UTC
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 :-).
Comment 16 Hin-Tak Leung 2015-04-23 16:55:51 UTC
(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.

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.