AMD's UVD2-based XvBA Finally Does Something On Linux

[gbeauche]

xvba-video 0.7.3

A new version of xvba-video, the XvBA backend to VA-API, is now available at:

http://www.splitted-desktop.com/~gbeauchesne/xvba-video/

Version 0.7.3 - 05.Aug.2010
* Add compatibility glue with original VA-API 0.31.1
* Fix vaCopySurfaceGLX() to a GLX texture of different size

For casual uses, there is no real changes from xvba-video 0.7.2. The first change makes it possible to use xvba-video with any upstream libva. Tested with 1.0.1, 1.0.3 and 1.0.4. i.e. no need for the -sds variant since there were no API difference for a while now. Note that VA-API 0.31.1 is available as libva 1.0.3 and 1.0.4.

The second change fixes a bug whereby vaCopySurfaceGLX() was not correctly rendering to a GLX texture of size different than that of the source surface. Note, there is still a bug in the Catalyst driver, so this fix is suboptimal in memory as a temporary FBO+texture of full surface size is needed...

Deinterlacing regression you may have noticed might be fixed in a future future Catalyst release.

[gbeauche]

Correct me if I'm wrong, but I thought XvBA did not function at all with the Evergreen series of GPUs. That reason is probably the source of your mplayer errors.

Yes, it's useless to report bugs on Evergreen. We all know this is broken for a while and will remain so for a while. There is nothing that can be done in xvba-video.

[DivineGrace]

Yes, it's useless to report bugs on Evergreen. We all know this is broken for a while and will remain so for a while. There is nothing that can be done in xvba-video.

Gbeauche, will you be releasing a new version of mplayer-vaapi soon?

[SP8472]

Version 0.7.3 - 05.Aug.2010
* Add compatibility glue with original VA-API 0.31.1

Tested with 1.0.1, 1.0.3 and 1.0.4. i.e. no need for the -sds variant since there were no API difference for a while now.

This glue doesn't seem to be working on Debian (though the issue may be on my system only, I can't be sure).

I have xvba-video 0.7.3 for amd64.

With libva1, libva-x11-1 and vainfo from Debian, vainfo shows

libva: va_getDriverName() returns -1

With libva1 (and included vainfo) from you, vainfo works fine, but Debian's vlc shows the message as above. I suspect an interaction with libva1-x11-1 from Debian. I'm not sure what that is, your packages don't mention a libva-x11.

[SP8472]

Fixed it by manually redirecting libva-x11 to your packages. It works, I can play HDTV in vlc without stuttering now.
The Debian packages are libva 1.0.1, by the way, so I guess the compatibility glue isn't even supposed to work. The maintainer has committed 1.0.3 to git in June, but not actually uploaded new packages yet.

[Ck-NoSFeRaTU]

With vaapi/xvba-video on start up of couple h264 mkv files I'm experiencing 100% full system lockup and green artifacts in video player or rarely black screen (monitor says no signal) and 100% video card fan.

gentoo 2.6.34/radeon 4870/xvba-video 0.7.3/libva 0.31.1-1+sds4/catalist 10.7/MPlayer SVN-r31722-4.4.4

Test file.



Driver bug?

[gbeauche]

With vaapi/xvba-video on start up of couple h264 mkv files I'm experiencing 100% full system lockup and green artifacts in video player or rarely black screen (monitor says no signal) and 100% video card fan.

gentoo 2.6.34/radeon 4870/xvba-video 0.7.3/libva 0.31.1-1+sds4/catalist 10.7/MPlayer SVN-r31722-4.4.4

Driver bug?

Yes, driver bug in the OpenGL component, even with the new Catalyst 10.8. The bug can be reproduced with plain -vo gl, I don't know why. The video can play fine with PCOM or Xv.

[gbeauche]

Gbeauche, will you be releasing a new version of mplayer-vaapi soon?

Probably next week, if I have the time. Otherwise, I will be on vacation so probably in late September, or October. I generally update mplayer-vaapi if I actually have changes to make to the VA-API output or want to test new features. e.g. Intel is working on high-quality scaling (NLA), so expect new flags to appear. ;-)

[gbeauche]

This glue doesn't seem to be working on Debian (though the issue may be on my system only, I can't be sure).

I have xvba-video 0.7.3 for amd64.

With libva1, libva-x11-1 and vainfo from Debian, vainfo shows

libva: va_getDriverName() returns -1

With libva1 (and included vainfo) from you, vainfo works fine, but Debian's vlc shows the message as above. I suspect an interaction with libva1-x11-1 from Debian. I'm not sure what that is, your packages don't mention a libva-x11.

The ATI detection code fix was committed only for 1.0.4. Actually, it's a workaround since AMD is no longer using a standard DRM. You will have to name the driver explicitly with earlier upstream versions. e.g. LIBVA_DRIVER_NAME=fglrx. Besides, you will also have to move the fglrx_drv_video.so file to the VA drivers path used on your system, instead of /usr/lib/va/drivers/.

The current xvba-video 0.7.3 works for any of the upstream libva 1.0.x series + the latest libva -sds variants.

[Ck-NoSFeRaTU]

Yes, driver bug in the OpenGL component, even with the new Catalyst 10.8. The bug can be reproduced with plain -vo gl, I don't know why. The video can play fine with PCOM or Xv.

Strange... I have problems only with -vo vaapi and -vo vaapi:gl. With plain -vo gl,gl_nosw,x11,fbdev,caca and so on I have no problems. I'm currently using catalist 10.8 too.