Page 4 of 5 FirstFirst ... 2345 LastLast
Results 31 to 40 of 42

Thread: XvBA / VA API

  1. #31
    Join Date
    Sep 2007
    Location
    Germany
    Posts
    99

    Default

    Is there any news on XvBA?

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

  2. #32
    Join Date
    Jun 2009
    Posts
    1,118

    Default

    Quote 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)

  3. #33
    Join Date
    Dec 2008
    Posts
    985

    Default

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

  4. #34
    Join Date
    Aug 2008
    Location
    Finland
    Posts
    1,578

    Default

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

  5. #35
    Join Date
    Jun 2009
    Posts
    1,118

    Default

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

  6. #36
    Join Date
    Aug 2007
    Posts
    6,610

    Default

    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:

    http://kanotix.com/files/fix/mplayer-vaapi-latest-1.txt

    this is a variant of

    http://kanotix.com/files/fix/mplayer-vaapi-latest.txt

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

  7. #37
    Join Date
    Jul 2008
    Posts
    1,723

    Default

    Quote Originally Posted by Max Spain View Post
    Boo @ TPM
    tpm in itself is not bad. It all depends on how it is used.

  8. #38
    Join Date
    May 2009
    Location
    Toulouse (France)
    Posts
    40

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

  9. #39
    Join Date
    Dec 2008
    Posts
    985

    Default

    Quote 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

  10. #40
    Join Date
    May 2009
    Location
    Toulouse (France)
    Posts
    40

    Default

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •