Announcement

Collapse
No announcement yet.

Adobe's Flash Video Acceleration On Linux Uses VDPAU

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

  • Adobe's Flash Video Acceleration On Linux Uses VDPAU

    Phoronix: Adobe's Flash Video Acceleration On Linux Uses VDPAU

    This morning there was the report on the release of Adobe Flash Player 10.2 Beta 1, which finally brought GPU-based Flash video acceleration to Linux. H.264 video acceleration has already been available on Windows and Mac OS X operating systems, but this is the first time that Adobe is bringing this support to the official Linux Flash player. With the 10.2 release to all operating systems they are providing this support via an API they call "Stage Video" for the complete acceleration of the entire playback process...

    http://www.phoronix.com/vr.php?view=ODg1NQ

  • #2
    Maybe this will be finally the push that gets vdpau adopted in other drivers.

    Comment


    • #3
      Can someone explain the "next-to-broken state thanks to bugs in the X-Video Bitstream Acceleration driver" to me?

      I have used catalyst for some time with my HD 4670. It worked very good for most videos. There were some (x264 encoded, level 5 @ high I think) that had huge block artifacts but the vast majority of the videos just played flawless.

      Comment


      • #4
        Originally posted by ChrisXY View Post
        Can someone explain the "next-to-broken state thanks to bugs in the X-Video Bitstream Acceleration driver" to me?

        I have used catalyst for some time with my HD 4670. It worked very good for most videos. There were some (x264 encoded, level 5 @ high I think) that had huge block artifacts but the vast majority of the videos just played flawless.
        Here is a nice 105 page write up on the various issues.

        http://www.phoronix.com/forums/showt...ewpost&t=19983

        Comment


        • #5
          I have read like 70 posts and there were only people complaining that their older cards are not supported or discussing when video acceleration will come to the open source driver. One person had a problem that was solved quickly. Post 60 finally named some issues.
          I'm not currently running catalyst but I think deinterlacing worked...
          h264 l5.1 doesn't play. I said that, but few, very few videos I have encountered use it (actually 2).
          I have only managed to crash X with a broken video once in a long time... Certainly this is not the reason for saying it is "half broken".
          I have never encountered wrong colors on h264, only said problems with above videos. Does someone have a screenshot or something?

          Is there more to come? Do I have to read all posts of which only a a small minority is about the problems?

          I also don't understand why people like to have to have so many pages all the time. With my forum settings it are only 12 pages.

          Comment


          • #6
            Originally posted by ChrisXY View Post
            I also don't understand why people like to have to have so many pages all the time. With my forum settings it are only 12 pages.
            Ever try to load a page with 100 posts on one page on a cell phone?

            Comment


            • #7
              xvba is crap, just like all other AMD proprietary stuff. get over it.

              Comment


              • #8
                I wonder when does Flash get support for webm, I thought they'd do that asap.
                And yes, I also hope that now AMD driver devs might consider supporting vdpau.

                Comment


                • #9
                  Originally posted by ChrisXY View Post
                  I have read like 70 posts and there were only people complaining that their older cards are not supported or discussing when video acceleration will come to the open source driver. One person had a problem that was solved quickly.
                  I am sorry but I have never seen any XvBA bug fixed quickly. I remind there was a stupid and crashing bug that prevented *any* XvBA based application (or library) to function properly without appropriate workaround. The fix was as trivial as a 10 characters (yes, ten!) change in the Makefile or whatever is used in the build system. However, this was only done 8 months later, yes, months...

                  Comment


                  • #10
                    Originally posted by deanjo View Post
                    Maybe this will be finally the push that gets vdpau adopted in other drivers.
                    Or other vendors getting their stuff together. I'd much rather the latter actually. Not too keen on the one-size-fits-all approach.

                    Comment


                    • #11
                      Originally posted by PsynoKhi0 View Post
                      Or other vendors getting their stuff together. I'd much rather the latter actually. Not too keen on the one-size-fits-all approach.
                      The last thing needed is a different API for every vender. It serves no purpose.

                      Comment


                      • #12
                        Well i see no huge problem to use nvidia accelleration via vdpau-video wrapper - just the apps need to be fine tuned ab bit like xbmc. vlc has got only problems with vc1 and ion - but there even on win...

                        Comment


                        • #13
                          Originally posted by PsynoKhi0 View Post
                          Or other vendors getting their stuff together. I'd much rather the latter actually. Not too keen on the one-size-fits-all approach.
                          This is why Windows is so much better: Microsoft provides ONE interface spec (DxVA) and driver and player software writers only have to worry about ONE interface (nevermind that DxVA isn't the perfect system).

                          The current VDPAU/VAAPI/XvBA situation in the linux world is ridiculous: Just pick one and fix it up so that all parties are satisfied instead of having every vendor invent their own.

                          Personally, I favor VDPAU: a lot of thought has been put into the overall
                          design, and the developers are responsive to inquiries and suggestions.

                          Comment


                          • #14
                            Agree and disagree...

                            Originally posted by mlau View Post
                            This is why Windows is so much better: Microsoft provides ONE interface spec (DxVA) and driver and player software writers only have to worry about ONE interface (nevermind that DxVA isn't the perfect system).

                            The current VDPAU/VAAPI/XvBA situation in the linux world is ridiculous: Just pick one and fix it up so that all parties are satisfied instead of having every vendor invent their own.

                            Personally, I favor VDPAU: a lot of thought has been put into the overall
                            design, and the developers are responsive to inquiries and suggestions.
                            Yes, I also think the way MS handles driver's APIs is much better.
                            You just have a single API (DirectX), and if your drivers need to work with Windows, you just need to be complaint with MS API(s) (DirectDraw, Direct3D, DxVA, for instance). In another words, you don't need to create your own APIs, like it happens a lot on Linux (unfortunately).

                            Personally, I'd prefer an OpenGL-based shader solution to decode videos in HW. OpenGL is a proven technology, and is supported by almost all modern linux drivers. By another side, rival nVidia companies might not like to use rival technologies (VDPAU), so, here I disagree with your PoV. Futhermore, there are also some video decoding features in VDPAU that need PureVideo, and to make VDPAU work in another drivers, it might be needed to reverse-engineer some PureVideo features... (which could lead (although improbable) to lawsuits).

                            My 2c, cheers!

                            Comment


                            • #15
                              Originally posted by evolution View Post
                              Personally, I'd prefer an OpenGL-based shader solution to decode videos in HW. OpenGL is a proven technology, and is supported by almost all modern linux drivers.
                              Nothing prevents utilizing libvdpau on shader based decoding. There is however potential legal issues by using open shader base decoding for patent laden codecs like h264. A dedicated hardware decoder is licensed with the MPEG-LA , an open software based solution would almost certainly not be licensed. This is why distros can include vdpau decoding but not any open software based h264 decoding libraries.

                              . Futhermore, there are also some video decoding features in VDPAU that need PureVideo, and to make VDPAU work in another drivers, it might be needed to reverse-engineer some PureVideo features... (which could lead (although improbable) to lawsuits).
                              Not true. libvdpau is vendor agnostic. What libvdpau, the API is extremely open as to what functions it calls for. It would be on the driver end that one would have to determine how to handle it on their hardware. If they have a hardware solution for that function then they can utilize that otherwise they can use a software solution for it. S3's implementation of vdpau shows this. It doesn not have the same hardware decoding engine as nvidia but it can still use vdpau.

                              Comment

                              Working...
                              X