Announcement

Collapse
No announcement yet.

XvBA / VA API

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

  • #31
    Is there any news on XvBA?

    (Just to remind AMD that we sitll want accelerated decoding :-)

    Comment


    • #32
      Originally posted by mibo View Post
      Is there any news on XvBA?

      (Just to remind AMD that we sitll want accelerated decoding :-)
      mmmm... my view here is that isnt going to happen any time soon, expecially since stream techonology is missing from fglrx as far as i know and opencl is very further away in the future too.

      beside fglrx code seems to be a trully mess and is very far away from windows equivalent + unstable as hell(at least in rv7xx chips). so adding this new stuff could break it even more(not being ironic it can be even worse than now even if is hard to imagine).

      if your budget allow it do like me buy an nvidia gts250 that will fit fine for modest game and clear h264 play with vdpau until OSS drivers get full mesa support and gallium/openCL become usable cuz in fglrx is not going to happen and even if someday in fglrx 20.20 happens i really doubt would be any usable until fglrx 32.14 in 2034. but by then prolly my 128 cores 40 ghz cpu can handle BD just fine lol.

      beside the homourus comment up, the truth here seems to be than first AMD dont care too much about fglrx cuz market issues and the code they got from ATI was a trully hellish completly undebugged code, plus AMD is producing new technologies like crazy in the gPU side (most productive part of AMD now) so it will take a long time to get a stable functional code because they seems to be forced to add code on the fly to support at least basically these tech beside the driver is stable or not. so more chaos to a chaotic code lol. so those of us that say ohh i love that 4800 card and commit the sin of use linux, our only hope is the OSS driver (which is going nice btw) cuz devs seems to put more thinking and optimization in the code, i guess is cuz of the lack of pressure of crazy enterprise politics and more access to OS info from already +AAAAA drivers like OSS intel.

      so wait for OSS driver/gallium/opencl and later wait for xine/ffmpeg/VA-API opencl video accelaration infrastucture (maybe this come faster cuz nvidia have already a very nice openCL capable driver, so we dont have to wait for gallium or AMd at the very begining)

      Comment


      • #33
        Originally posted by jrch2k8 View Post
        mmmm... my view here is that isnt going to happen any time soon, expecially since stream techonology is missing from fglrx as far as i know and opencl is very further away in the future too.

        beside fglrx code seems to be a trully mess and is very far away from windows equivalent + unstable as hell(at least in rv7xx chips). so adding this new stuff could break it even more(not being ironic it can be even worse than now even if is hard to imagine).
        The stuff is already there, all AMD has to do is open up their API.

        Comment


        • #34
          Originally posted by monraaf View Post
          The stuff is already there, all AMD has to do is open up their API.
          No, God, no! No more video API's. What they need to do is write a library that allows you to use their XvBA as a VA-API backend.

          Comment


          • #35
            Originally posted by monraaf View Post
            The stuff is already there, all AMD has to do is open up their API.
            well you think the code is already there cuz you see a library there, but there is a reason cuz is not operational dont you think? as far as im concerned that could be a loot of porn images in base64 put in a so file just to show something.

            Comment


            • #36
              Did anybody really test vaapi? It is possible to test with GMA 500, G45/Q45 (there only Mpeg2) and via vdpau-video wrapper with vdpau capable cards. If you use debian or ubuntu just run this script:



              this is a variant of



              which updates the mplayer to current svn, that works without problems currently. For the gl output vsync should be enabled for opengl. The script compiles the 965 driver which i tested worked for karmic at least. To test with nvidia all distros should work. I think testing vaapi is a good idea to know what is different to vdpau implementations (mplayer can do both with nvidia then).

              Comment


              • #37
                Originally posted by Max Spain View Post
                Boo @ TPM
                tpm in itself is not bad. It all depends on how it is used.

                Comment


                • #38
                  gnash with VA API

                  Hi all,

                  did some one already tested GNASH with VAAPI (cf http://www.splitted-desktop.com/~gbe...e/gnash-vaapi/) ?
                  it is supposed to work on radeon with xvba-video driver.

                  Comment


                  • #39
                    Originally posted by jery View Post
                    Hi all,

                    did some one already tested GNASH with VAAPI (cf http://www.splitted-desktop.com/~gbe...e/gnash-vaapi/) ?
                    it is supposed to work on radeon with xvba-video driver.
                    I would love to test it but unfortunately I don't have access to the xvba-video driver, if you have send it to me and I'll test it for you

                    Comment


                    • #40
                      Originally posted by monraaf View Post
                      I would love to test it but unfortunately I don't have access to the xvba-video driver, if you have send it to me and I'll test it for you
                      I guess this part of libamdxvba1 package description is the problem you're talking about:

                      Unfortunately, this package requires an unsupported library,
                      so it is not installed by default.

                      Comment

                      Working...
                      X