Announcement

Collapse
No announcement yet.

VA-API Support For Google Android Platform

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

  • VA-API Support For Google Android Platform

    Phoronix: VA-API Support For Google Android Platform

    We have been tipped off that a few VA-API patches have hit the upstream libva tree for furthering along Google's Android support for this video acceleration API. VA-API is arguably the second best video playback acceleration API available to Linux users, after the NVIDIA-created VDPAU...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Originally posted by phoronix View Post
    Phoronix: VA-API Support For Google Android Platform

    We have been tipped off that a few VA-API patches have hit the upstream libva tree for furthering along Google's Android support for this video acceleration API. VA-API is arguably the second best video playback acceleration API available to Linux users, after the NVIDIA-created VDPAU...

    http://www.phoronix.com/vr.php?view=ODgzNg
    What's up with the humongous hex-blob in va_fool_264.h?

    Comment


    • #3
      while its true there's now an Android entry , it seem thats a side issue, and its Far More likely that these patches are setting the stage for the Sandy Bridge internal Encode/Decode video engine coming in January, hence the new
      4) Update VAAPI for dynamic bit rate control/AIR/maximum slice size ctrl
      5) Added VA_STATUS_ERROR_DECODING/ENCODING_ERROR to report decode/encode error
      etc.

      "kalas said:What's up with the humongous hex-blob in va_fool_264.h?"
      in effect its just a hard-coded 720P clip for the New Encoder tests their testing against.

      "+ * Do dummy decode/encode, ignore the input data
      + * In order to debug memory leak or low performance issues, we need to isolate driver problems
      + * We export env "VA_FOOL", with which, we can do fake decode/encode:
      + *
      + * LIBVA_FOOL_DECODE:
      + * . if set, decode does nothing, but fill in some YUV data
      + * LIBVA_FOOL_ENCODE:
      + * . if set, encode does nothing, but fill in a hard-coded 720P clip into coded buffer.

      + * . VA CONTEXT/CONFIG/SURFACE will call into drivers, but VA Buffer creation is done in here
      + * . Bypass all ~SvaBeginPic/vaRenderPic/vaEndPic~T
      + * LIBVA_FOOL_POSTP:
      + * . if set, do nothing for vaPutSurface
      ...."

      Comment


      • #4
        Heh, of all the companies google forces Adobe to accelerate flash :P

        Comment


        • #5
          Will this have any impact upon the performance of recent Android smartphones running the OMAP processor + SGX GPU combo? I have a Droid 2, and it's not rooted, because I don't need to root it so far... hopefully if this work can lead to performance improvements for video decode, then Google/Motorola/Verizon will work together to get this implemented throughout the stack, and push it out as an official software update.

          Unless they already use some proprietary APIs for GPU-based video decode, which would make VA-API just a redundant wrapper, I guess. But decoding on the SGX chip is preferable to decoding on the general-purpose CPU.

          Comment


          • #6
            Flash sucks and it will continue to suck in 2011.

            Comment


            • #7
              Originally posted by d2kx View Post
              Flash sucks and it will continue to suck in 2011.
              Steve Jobs is that you?

              Comment


              • #8
                Originally posted by allquixotic View Post
                Will this have any impact upon the performance of recent Android smartphones running the OMAP processor + SGX GPU combo? I have a Droid 2, and it's not rooted, because I don't need to root it so far... hopefully if this work can lead to performance improvements for video decode, then Google/Motorola/Verizon will work together to get this implemented throughout the stack, and push it out as an official software update.

                Unless they already use some proprietary APIs for GPU-based video decode, which would make VA-API just a redundant wrapper, I guess. But decoding on the SGX chip is preferable to decoding on the general-purpose CPU.
                Hate to break it to you, but yours, as well as everyone else's phones already have hardware accelerated video decode.

                There is nothing particularly special here. VAAPI isn't going to suddenly unleash magic video-decode superiority. It is just hopefully an eventual switch from proprietary video decode interfaces to VAAPI. Of course, it would depend on the particular hardware vendor to actually write a VAAPI driver for their hardware.... which in most cases, is unlikely.

                Comment


                • #9
                  What about support for free codecs?

                  I wonder why there isn't any activity to make VA-API support VP8 and maybe even Theora O_o

                  Comment


                  • #10
                    ... the underlying hardware has to support it.

                    Comment

                    Working...
                    X