Announcement

Collapse
No announcement yet.

Google's Linux Video Acceleration API: VAVDA

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

  • #16
    Originally posted by Gusar View Post
    9JI can respond in the same way: So what? VDPAU and vaapi are here and they work. It makes much more sense for Google to support one of these instead of something that's not used by any X driver. Standard or not.
    For Google this is true as VAVDA seems to be no new API.
    But for the AMD, NVIDIA and Intel it is not true. An system independent API like OpenMAX would allow to use the same code for various platforms. Media-Software programmers could find this a nice thing. Nowadays your have to use the DXVA-API for Windows and VA-API + VDPAU for Linux and i.e. OpenMAX for a Smartphone. A portable solution like OpenGL ES would be much better.

    Comment


    • #17
      anyone tried this? how can I be sure that I'm using vaapi after passing the --enable-vaapi flag to chromium?

      Comment


      • #18
        Originally posted by Gusar View Post
        9JI can respond in the same way: So what? VDPAU and vaapi are here and they work.
        VAAPI does not work on my NVidia system, just as VDPAU does not work on Intel systems. AMD's API works on neither of the first two, just as the first two do not work with AMD systems.
        I'm aware of wrapper libraries but those never worked for me. So no video acceleration with VLC (only supporting VAAPI) on my NVidia system.

        OpenMAX is far more widespread than any of those three proprietary APIs (I'm using the original meaning of “proprietary” here, not the FSF meaning of “proprietary” = “closed source”). Some Linux software (such as GStreamer) even support OpenMAX. The only major roadblock are the drivers because AMD, Intel, and NVidia all suffer from NIH syndrome in this case.

        Comment


        • #19
          Your example is wrong. the vdpau-video wrapper works with vlc (and with mplayer vaapi) but crashes with xbmc (but there you can use vdpau natively). It is easy to verify that vaapi is used, the output is similar to that what you get when you execute vainfo (only the debug lines).

          Comment


          • #20
            Additionally VA-API support is provided by Splitted Desktop's VA-API<-->XvBA wrapper library. But this solution doesn't always work flawlessly. And the native XvBA support came too late and has again its own API. But I agree that a common API (at least like DXVA under Windows) is required. Look at Adobe Flash - it does not support all APIs. And this applies to most other programs, too.

            Comment


            • #21
              Originally posted by ChrisXY View Post
              Video Acceleration API Video Decode Acceleration.
              You added in one too many "A"'s.

              Comment


              • #22
                OpenMAX is truly horrible and isn't really even 'one API'. Everyone implements similar but different things and you can't really use an OMX pipeline without having vendor-specific code. It's also a really terrible API and every implementation I've ever had to deal with has been shockingly buggy.

                Comment


                • #23
                  Ok then ignore OpenMAX but IHVs should start to invent a common solution. It is possible to provide a common API für different H/W (see DXVA) - should also be possible to invent a platform independent variant.

                  Comment


                  • #24
                    VAVDA is not yet supported on Pepper Flash for Linux

                    I spoke with Ami Fischman who is heading up the Google/Chromium team working on incorporating GPU accelerated video decoding into the Pepper Flash player for Chromeos. He confirmed that the vavda/vaapi accelerated decoding is not yet supported on Linux. He mentioned that because Chromeos is based on Linux, when they finish adding the feature for Chromeos they may take a stab at trying to get it working for Linux in general.

                    If this is a feature that you would like to see, please vote for it here: https://code.google.com/p/chromium/i...tail?id=137247

                    Josh

                    Comment


                    • #25
                      "The page you asked for does not exist."

                      Comment


                      • #26
                        Originally posted by elmariachi View Post
                        "The page you asked for does not exist."
                        that's because it has been shortened replace: s@i...tail@issues/detail@

                        Comment


                        • #27
                          Enable VAVDA on Linux feature request

                          Oops. Forgot to wrap the HTML.

                          Thanks for the heads up.

                          HTML Code:
                          https://code.google.com/p/chromium/issues/detail?id=137247

                          Comment


                          • #28
                            Originally posted by daniels View Post
                            OpenMAX is truly horrible and isn't really even 'one API'. Everyone implements similar but different things and you can't really use an OMX pipeline without having vendor-specific code. It's also a really terrible API and every implementation I've ever had to deal with has been shockingly buggy.
                            Same is often said about X11 and Xorg, yet you are listed as X.org Developer here.
                            You are advocating this: https://xkcd.com/927/

                            If OpenMAX has flaws, work on OpenMAX 2.0 with others from Khronos.

                            Comment

                            Working...
                            X