Announcement

Collapse
No announcement yet.

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

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

  • 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/~gbe...ne/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.

    Comment


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

      Comment


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

        Comment


        • Originally posted by gbeauche View Post
          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
          Code:
          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.

          Comment


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

            Comment


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

              Comment


              • Originally posted by Ck-NoSFeRaTU View Post
                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.

                Comment


                • Originally posted by DivineGrace View Post
                  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. ;-)

                  Comment


                  • Originally posted by SP8472 View Post
                    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
                    Code:
                    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.

                    Comment


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

                      Comment

                      Working...
                      X