Announcement

Collapse
No announcement yet.

AMD Opens Up XvBA! Their Catalyst Linux Video API

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

  • #16
    Originally posted by gbeauche View Post
    And I will let people try to write a player from scratch with only the header file and doc file, without cheating and looking at demo code and realize the particular things to adjust...
    I'll get right on that. Just let me finish my latest invention (I call it the "wheel").

    Comment


    • #17
      Originally posted by popper View Post
      does this mean that you are released from the NDA restrictions up to a point, and can now tell us were the bugs are in the catalyst driver and the header errors you mentioned that feels like a millennia ago ?
      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 noticed you posting on the ffmpeg mailing list BTW , perhaps you can send a post off there mention there that they have released this header and basic lib etc , perhaps someone there will slap something together using this info or even use it for the GSOC 2011 idea's and you can mentor them if that's allowed
      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.

      Comment


      • #18
        A little off the topic, but I heaven't heard about the (newer) ongoing efforts regarding Video en/decoding using the shaders. Does anyone know if this is still in development and how far it has evolved?

        The upsides about that effort not only are having no trouble with digital rights removal, but also the shaders can be used to ENcode stuff, plus (I guess) almost any codec can be addressed via the shaders while the fixed function units can only do what they were made for. What about WebM for example?

        Downsides: likely higher power draw, fights for the same ressources when video runs inside a 3D-environment.

        Comment


        • #19
          Originally posted by edgar_wibeau View Post
          A little off the topic, but I heaven't heard about the (newer) ongoing efforts regarding Video en/decoding using the shaders. Does anyone know if this is still in development and how far it has evolved?

          The upsides about that effort not only are having no trouble with digital rights removal, but also the shaders can be used to ENcode stuff, plus (I guess) almost any codec can be addressed via the shaders while the fixed function units can only do what they were made for. What about WebM for example?

          Downsides: likely higher power draw, fights for the same ressources when video runs inside a 3D-environment.
          you're not likely to either, that "Video en/decoding using the shaders" was basically put forward by the 'man with the plan' bridgman (Linux Project Management) something like 12 months ago or even longer now as the UVD Linux development became static and stagnant , there has been no actual code development on that ""Video en/decoding using the shaders" AFAIK or at least never mentioned anywhere here at phoronix in all that time!

          as for the "shaders can be used to ENcode stuff" part , LOL see my http://phoronix.com/forums/showthrea...543#post178543
          post for a reference to "< Dark_Shikari> because all people who try are eaten by the cuda monster"

          OC you could be the first to submit a working patch to x264, but do read the log as stated there...

          Comment


          • #20
            Regarding shader-based video accel, I thought C. Konig had started but found he did not have all the necessary building blocks. I'm not sure what the current status is.

            Comment


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