Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: VA-API Support For Google Android Platform

  1. #1
    Join Date
    Jan 2007
    Posts
    14,630

    Default 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...

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

  2. #2
    Join Date
    Nov 2010
    Posts
    1

    Default

    Quote 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?

  3. #3
    Join Date
    Jan 2007
    Posts
    459

    Default

    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
    ...."

  4. #4
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,067

    Default

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

  5. #5
    Join Date
    Sep 2008
    Posts
    989

    Default

    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.

  6. #6
    Join Date
    Jan 2007
    Location
    Germany
    Posts
    2,124

    Default

    Flash sucks and it will continue to suck in 2011.

  7. #7
    Join Date
    May 2007
    Location
    Third Rock from the Sun
    Posts
    6,583

    Default

    Quote Originally Posted by d2kx View Post
    Flash sucks and it will continue to suck in 2011.
    Steve Jobs is that you?

  8. #8
    Join Date
    Oct 2009
    Posts
    2,086

    Default

    Quote 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.

  9. #9
    Join Date
    May 2009
    Posts
    80

    Default 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

  10. #10
    Join Date
    Oct 2009
    Posts
    2,086

    Default

    ... the underlying hardware has to support it.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •