Announcement

Collapse
No announcement yet.

AMD Opens Up XvBA! Their Catalyst Linux Video API

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

  • #21
    Originally posted by aussiebear View Post
    This feels more like a move from AMD to address a key deficiency on Linux for their Fusion lines...Both the E-/C-series (Zacate/Ontario) and the upcoming A-series (Llano) are pretty much ideal for their respective markets; given their reasonably capable GPU-based IGP.

    If they can get their A-series working with accelerated video playback on Linux; I'm pretty much sold for the K10.5-based "Llano" (2011) and Bulldozer-based "Trinity" (2012).

    ...I'm not all that enthusiastic about buying a discrete video card when I don't have to. I've seen leaked slides that indicate that the A-series (Llano) IGP performs like a Radeon HD 5550 GPU. (It meets my computing needs.)
    Yeah. I was looking to upgrade my HTPC recently, and was very excited about Sandy Bridge as an all-in-one solution, but I ended up being extremely disappointed with the product delivery (must have K series to get best graphics core, must use H series M/B to use best graphics core, must use P series for K series processor to make any sense--duh, way to go Intel). I ended up going with an nvidia 9300 chipset and a core2. The 9300 wasn't quiiiite fast enough for what I needed so I also used a discrete gf240.

    I'm very pleased with the results, however sometime this summer or fall I'll probably be looking at building two mythfrontend-only machines, and this development means I'll be looking very seriously at Llano as a solution. Bravo AMD.

    Comment


    • #22
      It's late to say the least, but awesome as well.
      Good job, ATI! Next up: proper and not so buggy OpenGL support?

      i have high hopes

      Comment


      • #23
        popper: tnhanks!

        DanL: that's what I was referring to, also found the original article at phoronix. The corresponding thread ends in november 2010 - guess I'll go asking there

        Comment


        • #24
          Originally posted by edgar_wibeau View Post
          popper: tnhanks!

          DanL: that's what I was referring to, also found the original article at phoronix. The corresponding thread ends in november 2010 - guess I'll go asking there
          Seriously edgar_wibeau, you need to stop following me. They cannot help with our little X120e issue

          Comment


          • #25
            Originally posted by d2kx View Post
            Seriously edgar_wibeau, you need to stop following me. They cannot help with our little X120e issue
            Well, who's more fool after all

            Comment


            • #26
              Originally posted by gbeauche View Post
              There are some things that are still secret. I am not sure I would release xvba-video sources soon as this would make me maintain two different branches, which would be time consuming. No time yet to spend on that. Sorry.



              I already have FFmpeg support but since the API was not fixed... In particular, having to link libavcodec against X11 & GL for XvBA support is a no go.
              ooh you mean the libavcodec API ? , i didnt see you mention that problem over there yet,ping it if you did, so it shows up again and gets someone's attention there.

              perhaps a libavcodec API patch can be made before they do the major revision bump if so given the new faster structure (x264 style) , #ffmpeg-devel IRC realtime develop, and review, then post the finished patch to the mailing list for nitpick, ok, push...

              or did you mean the catalyst driver API bug's ,no go there then.....

              Comment


              • #27
                I still doubt "shader-based video acceleration" is worth the effort. It requires a fair bit of shader horsepower, only partial acceleration is possible and it's still very complicated to implement.

                Comment


                • #28
                  Originally posted by Kano View Post
                  3 years late, but now i want to see if it works better without gl.
                  You can't see that because what was released was XvBA with the OpenGL backend. Xv in the name has nothing to do with Xv...

                  Also i want debian packages for xvba, gb could you do that? Would be great for my script(s)...
                  I have no intention to package XvBA Tools. XvBA SDK should appear in Catalyst. This shouldn't be hard since this is only a symlink and file copy.

                  Comment


                  • #29
                    Originally posted by popper View Post
                    or did you mean the catalyst driver API bug's ,no go there then.....
                    XvBA depends on X11 & OpenGL. It's not split into two parts, unlike VA-API or VDPAU, which can perfectly link without X11 dependency. lavc should have as little dependency as possible. Having a resulting libavcodec library linked against XvBA and then X11 and OpenGL is not what I'd call a sane thing for this decoder library. You can try to argue if you want, or move as many things as possible out of the core libavcodec library. But this would be a total non sense since users of the library would have to duplicate much code in their player then.

                    Comment


                    • #30
                      Originally posted by gbeauche View Post
                      XvBA depends on X11 & OpenGL. It's not split into two parts, unlike VA-API or VDPAU, which can perfectly link without X11 dependency. lavc should have as little dependency as possible. Having a resulting libavcodec library linked against XvBA and then X11 and OpenGL is not what I'd call a sane thing for this decoder library. You can try to argue if you want, or move as many things as possible out of the core libavcodec library. But this would be a total non sense since users of the library would have to duplicate much code in their player then.
                      ooh WOW, that's insane today , totally agree , and we dont need any more drama on the ffmpeg mailing list

                      scratches head trying to think of a way to solve or at least get around it.....

                      nope nothing coming to mind here , i guess we have to give XvBA yet another strike for fail, so back to VA-API and the OpenCL decode as the only option If They Ever get around to making it available to Linux OC

                      Comment

                      Working...
                      X