Tried to test vdpau using
but it failed with:
AMD E-350 Processor
VDPAU API version : 1
VDPAU implementation : G3DVL VDPAU Driver Shared Library version 1.0
FATAL: get_bits failed : No backend implementation could be loaded.!!
and very bad framerate (MPEG DECODING (1920x1080): 53 frames/s)
"No backend implementation could be loaded" happened with shaders decoding and also with UVD decoding (while mplayer -vo vdpau worked fine on both cases)
"No backend implementation could be loaded" is mesa VDP_STATUS_NO_IMPLEMENTATION
- kernel from drm-fixes + radeon UVD patches (http://lists.freedesktop.org/archives/dri-devel/2013-April/036766.html + http://paste.debian.net/247063/)
- mesa 9.2 from master as of 302df7cc85b0e2ce47c40048f30bd116b0d692fc + patches http://comments.gmane.org/gmane.comp.video.mesa3d.devel/55622 and http://lists.freedesktop.org/archives/mesa-dev/2013-April/037089.html
- E350 AMD APU with [AMD] nee ATI Wrestler [Radeon HD 6310] GPU
- vdpauinfo with shaders: http://pastebin.com/UV2CAX9F
- vdpauinfo with UVD working: http://pastebin.com/FjpLyMqr
I have same platform as Arkadiusz [E-350] and I can confirm his results of 53 frames/s.
Kernel 3.9-rc6 + drm uvd patches
libdrm Git 08.04.2013
Mesa Git 08.04.2013 + uvd patch
On the other hand mplayer -vo vdpau was not enough to get smooth playback of H264 content. I had to specify "mplayer -vo vdpau -vc ffh264vdpau" with perfect results. Using standard combination of "mplayer -vo vdpau -vc ffmpeg12vdpau,ffvc1vdpau,ffh264vdpau,ffodivxvdpau" on the H264 content made mplayer use ffmpeg12vdpau which resulted in jerky playback.
Using XBMC from FernetMenta tree https://github.com/FernetMenta/xbmc which has number of vdpau playback fixes resulted in jerky playback for high bitrate content at 1920@1080.
As of VC1 content any player I used created either dark screen with green artifacts at playback
Please let me know if You need any logs (dmesg/Xorg/lspci) or configs (kernel/Xorg) or any other for that matter
That's a bug in qvdpautest. It tries to get the surface data in YUYV format, which is simply not supported by the hardware.
We could implement a software fallback, but mesuring that would be pretty much nonsense.