A New Release Of The AMD XvBA Back-End To VA-API

[gbeauche]

vlc git shows green.

I sent a patch to VLC devs. This may also fix a problem on Ironlake.

[Cory]

Arch Linux packages are generally current. Use either upstream 0.31.0 (so called "1.0.1") without any patches or libva-sds 0.31.1-1+sds3. I just saw some packages built this morning. This might work now.

Packages in Arch Linux repos are updated now

[DivineGrace]

Well, what about earlier ATI GPUs, like the HD2000 series? Is it possible to get any kind of decode acceleration with XvBA now?

Yes. My notebook has a mobile HD2600, and XvBA works quite well with L4.1 material. Occasionally, playback stutters with mplayer-vaapi, but it works well for the most part. Granted, XvBA just is not as good as VDPAU, but for notebook users such as myself, it is a viable solution. Although mplayer-mt also works quite well, I prefer mplayer-vaapi simply because the XvBA implementation allows lower CPU frequencies, which translates to cooler and quieter CPU operations.

[DanL]

How do you use it? What kind of video file? What version of gstreamer? Just saying "doesn't work" doesn't help much. If your videos are embedded in a .ts container, then there indeed could be decoding -- well, parsing -- problems.

I am using the following versions:
Catalyst 10-6
gstreamer from this PPA: https://launchpad.net/~gstreamer-dev...s_filter=lucid
gstreamer-ffmpeg 10.10.5
ffmpeg and x264 built from svn/git yesterday
libva 0.31.1-sds3
xvba 0.7.1
gstreamer-vaapi 0.2.5

Do I need to build gstreamer myself?

I was trying several different video formats (avi, flv, mp4, mpeg) using gst-launch. I'm not on that partition at the moment, but I can get you more detailed output if you think it will be helpful. Thanks for your efforts/time/attention.

[brent]

However, when it works, everything is offloaded to the GPU unlike NVIDIA for VC-1 and earlier GPUs.

Well, what about earlier ATI GPUs, like the HD2000 series? Is it possible to get any kind of decode acceleration with XvBA now?

[Kano]

It was a very short test with xbmc I found already 2 other bugs in xmbc while testing it. One crash with fglrx (not nvidia) even with software decoding. vaapi is choppy in xbmc with nvidia, intel and ati. Some xbmc dev should fix it...

[gbeauche]

However, when it works, everything is offloaded to the GPU unlike NVIDIA for VC-1 and earlier GPUs.

[gbeauche]

Why?

While the solution may be not so good I actually can watch hd videos with < 10% CPU load extremely smooth...
What can nvidia users with vdpau do that I can't?

Memory leaks and corruption in the long run, thus leading to system crashes. Much less features exposed in XvBA/GL than in another XvBA backend. Suboptimal use of GPU memory resources because of driver bugs or things not fully implemented. i.e. another indirection to accomplish the expected task, thus requiring more memory (and work). Some sync problems in the pipeline, depending on the driver (regression). etc.

[ChrisXY]

don't expect to experience wonderful ATI video playback on Linux that's elegantly offloaded to the GPU in the manner that NVIDIA customers can with VDPAU and GeForce hardware.

Why?

While the solution may be not so good I actually can watch hd videos with < 10% CPU load extremely smooth...
What can nvidia users with vdpau do that I can't?

[gbeauche]

By the time there are usable radeon Gallium drivers, VA-API will be completely obsolete, since there is a WIP VDPAU state stracker.

Ah, because you believe there is a WIP VDPAU state tracker implies that (i) the actual decoders are available, (ii) they are efficient and effective, (iii) magically support all other HW like ATI, Intel G45 and GMA500? The answer to all of those is "no". I don't see how the API can be obsolete when it has implementations for every single combined GPU+HW accelerator in Linux.