Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    Comment


    • 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

      Comment


      • here is additionally the output of mplayer, which might also help to narrow down the problem:
        Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.


        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

        Comment


        • @Armin

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

          Comment


          • @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
            Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.


            mplayer -vo vaapi:gl -va vaapi 00501.m2ts
            Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.


            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. :-)

            Comment


            • Originally posted by Kano View Post
              @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.

              Comment


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

                Comment


                • 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.

                  Comment


                  • 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

                    Comment


                    • Originally posted by tbshl-vdr View Post
                      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?

                      Comment

                      Working...
                      X