Announcement

Collapse
No announcement yet.

AMD Opens Up XvBA! Their Catalyst Linux Video API

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

  • #11
    actually , come to think about it, now they released this info does this mean AMD now have no valid reason not to also compile and release the missing openCL Linux decode lib to go with the already released header ASAP !

    Comment


    • #12
      3 years late, but now i want to see if it works better without gl. Also i want debian packages for xvba, gb could you do that? Would be great for my script(s)...

      Comment


      • #13
        OK, so I'm a bit lost here.

        They opened up the interface but not UVD itself. My question is why can't the radeon driver link to the xvba library and use it? Well, that would ruin the completely open source experience on my machine but this might still be better than nothing.

        Comment


        • #14
          Originally posted by HokTar View Post
          OK, so I'm a bit lost here.

          They opened up the interface but not UVD itself. My question is why can't the radeon driver link to the xvba library and use it? Well, that would ruin the completely open source experience on my machine but this might still be better than nothing.
          The lib is interface to fglrx, and not software part of UVD. You cannot have 2 distinct drivers driving one single device at one time.

          Comment


          • #15
            Originally posted by Drago View Post
            The lib is interface to fglrx, and not software part of UVD. You cannot have 2 distinct drivers driving one single device at one time.
            Fair enough. My understanding was that they created a stand-alone library for xvba. It's a pity, btw.

            Thanks for the heads-up!

            Comment


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

                      Working...
                      X