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

[Kano]

Missed a t in the link due to edittime limit. Very stupid that you can not even delete it completely later. The correct link:

http://kanotix.com/files/fix/vlc-vaapi-local.txt

[Armin]

Hi,
I was curious if this XvBA thing also works on my "ATI Mobility Radeon HD 3650" (Thinkpad T500). So I did some testing, but unfortunately it always led to a full system crash. However I was still able to access the machine with ssh and I saved at least some log files. I can reproduce the crash for example with all H.264 video-files I came across.

Here are some infos about my system:

Distribution: Archlinux x86_64
Graphics card: ATI Mobility Radeon HD 3650
Kernel: 2.6.35-ARCH (stock Arch kernel)
X.org driver: Catalyst 10.9 (fglrx module version = 8.77.5)
Some software versions:
xvba-video 0.7.4
libva 1.0.4
mplayer-vaapi 32227

I put the log files to pastebin:
kernel: http://pastebin.com/0Hbbp8Wr
X.org log: http://pastebin.com/viWbDd5X

Maybe it helps to fix the problem someday and makes UVD unit work on my system ... hopefully. Of course there is also the possibility that I do something fundamental wrong, in this case I would be happy for some hints. :-)
Btw, the driver reports (according to X.org.log):
(==) fglrx(0): ATI 2D Acceleration Architecture enabled
(II) fglrx(0): UVD2 feature is available

-Armin

[Armin]

here is additionally the output of mplayer, which might also help to narrow down the problem:

http://pastebin.com/2kwemcgp

I started mplayer from a shell (within X11/ KDE) with the following command:
mplayer -v -vo vaapi:gl -va vaapi 3DMark2000.mkv > mplayer.log

kwin desktop effects are always switched off and vsync is always on (in amdcccle)

-Armin

[Kano]

@Armin

I had no success with h264 and a 3450, but interestingly vc1 worked.

[Armin]

@Kano
Jepp, I tested a VC-1 file and that works perfectly here too. I tested gl output and xv (I assume it is xv if I don't define it explicitly!?).
here are the two log file for the vc-1 video, just in case it would help to hunt down the issue with the h264 videos:
mplayer -vo vaapi -va vaapi 00501.m2ts

http://pastebin.com/gx1UEdRm

mplayer -vo vaapi:gl -va vaapi 00501.m2ts

http://pastebin.com/GQyQBprQ

again all test were done on my Thinkpad T500 with a ATI Mobility Radeon HD 3650 (RV635)

@gbeauche
if you are willing to fix the problem with the h264 decoding, I would volunteer as beta-tester and provide you with the needed information (log files, etc.). Of course, this implies that the problem lies in the xvba-video implementation. I don't want to claim that, but you are the only one who can answer that. :-)

[monraaf]

@monraaf

Time has come already it seems It's in the U repository now the xserver 1.9 part (i would prefer a dl link for the full installer however for my script). Can be patched like 10-9 for newer kernels.

http://archive.ubuntu.com/ubuntu/poo...80.orig.tar.gz

Thanks for the pointer. I gave it a try. XvBA does indeed work now with Evergreen and vlc, but CPU usage it too high especially with GL output. It's okaish with Xv output, but contrary to some recent claims I have read here Xv still tears, so that's not an option. I guess vlc is doing something different and terribly inefficient and that's why it works with vlc but not with mplayer.

[Kano]

vlc needs more cpu power, but basically it is low enough, with high bitrate content it is very low compared to cpu.

[smitty3268]

VLC copies the decoded video back to the CPU before displaying it, while other programs just pipe the output straight to the monitor.

This was done intentionally, so that they can send the decoded video through their whole existing pipeline of filters, etc., and doesn't just do a dumb display to the screen.

For most people that's not very important, but it is nice for some.

[tbshl-vdr]

Hello,

(i'm german, hopefully my english is understandable...)

Maybe there is a bug in xvba while destroying surfaces.
You can reproduce it with mplayer-vaapi. Create a playlist with some entrys and play it. Look at memory-usage, everytime a new file will be played (skip in playlist), the memory-usage is increased.

I wrote a test-app, where, while playing a file, every x frames i destroy surface(s) and create new with same effect as above.
It seems, as vaDestroySurface does not really freeing resources.

Thanks for reading,
Thomas

[DivineGrace]

Hello,

(i'm german, hopefully my english is understandable...)

Maybe there is a bug in xvba while destroying surfaces.
You can reproduce it with mplayer-vaapi. Create a playlist with some entrys and play it. Look at memory-usage, everytime a new file will be played (skip in playlist), the memory-usage is increased.

I wrote a test-app, where, while playing a file, every x frames i destroy surface(s) and create new with same effect as above.
It seems, as vaDestroySurface does not really freeing resources.

Thanks for reading,
Thomas

Thomas, you are correct. I have noticed this from running mplayer-vaapi through gnome-terminal, and opening consecutive files. Perhaps there is a memory leak?