Comment # 10
on bug 71812
from Fabrice Bellet
Hi! I also see the same behaviour. I tested it with mplayer -vo vdpau -vc ffodivxvdpau, using both vdpau decoder render and vdpau presentation functions. I tested it with vlc --avcodec-hw=vdpau, using decoder render and video surface get bits functions, and finally with gstreamer vaapidecode and vaapisink/ximagesink. (using radeonsi/uvd). All these cases have in common the use of the vdpau decoder render functions. Tested with upstream mesa/xorg, in a fedora 20 x86_64, [AMD/ATI] Cape Verde PRO [Radeon HD 7750 / R7 250E]. I made some traces at the libvdpau level (VDPAU_TRACE env vars), that I can provide if needed. They don't seem to present major differences between situations with and without corruption. I tried to serialize the vdpau calls with a mutex without more success, I played with the number of surfaces too, no difference. libefence didn't help. I have the feeling that some uninitialized stuff is passed to the hardware decoder, because I would say the problem probalistically happens more frequently after a fresh boot. The initial frame is _sometimes_ garbled with some bad colors (chroma planes ?), and this corruption progates to consecutive frames, due to the way mpeg compression works. I also have the feeling that this bug occurs more frequently with gstreamer-vaapi/vdpau-driver than vlc and mplayer, because of the multithreaded nature of gst, where decoding operation and rendering operations are less regularily scheduled : in gst, a burst of 4 or 5 vdpau decode render operations can happen on different surfaces, before the generated data is consumed by the vdpau presentation mode. Another way this problem occurs is by corrupting other parts of the display, not limited to the X11 window area where the rendering should happen, like small black rectangles appearing randomly on the screen. In another case, I noticed that part of my gnome-terminal transparent background looses some small rectangular areas that become "more" transparent than they should be.
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
