If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Announcement
Collapse
No announcement yet.
AMD's UVD2-based XvBA Finally Does Something On Linux
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
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
@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
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. :-)
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.
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.
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.
(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.
(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?
Comment