Announcement

Collapse
No announcement yet.

VA-API Gets Extended With Flexible Encoding Infrastructure

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

  • VA-API Gets Extended With Flexible Encoding Infrastructure

    Phoronix: VA-API Gets Extended With Flexible Encoding Infrastructure

    Intel added a new extension to the VA-API video acceleration API over the summer called the Flexible Encoding Infrastructure...

    http://www.phoronix.com/scan.php?pag...&px=VA-API-FEI

  • #2
    That sounds interesting. I hope it will be used by userspace programs as well as other GPU drivers. I imagine throwing my lots of (my own) BluRays that I ripped to watch them under Linux at some recent (yet to buy) AMD GPU (e.g. RX 560) that has x265 encoding (and decoding) capabilities and have a decent transcoding speed and enjoy the more moderate filesize afterwards.
    I think these encoders could also be very helpful during screen recording for e.g. tutorials if you currently block the CPU with something.
    Stop TCPA, stupid software patents and corrupt politicians!

    Comment


    • #3
      Originally posted by Adarion View Post
      That sounds interesting. I hope it will be used by userspace programs as well as other GPU drivers. I imagine throwing my lots of (my own) BluRays that I ripped to watch them under Linux at some recent (yet to buy) AMD GPU (e.g. RX 560) that has x265 encoding (and decoding) capabilities and have a decent transcoding speed and enjoy the more moderate filesize afterwards.
      I think these encoders could also be very helpful during screen recording for e.g. tutorials if you currently block the CPU with something.
      A word of caution: encoding hardware acceleration may very well have lower quality or less settings than encoding done on CPU. Intel's Quick Sync for example is like that.

      The main reason for encoding hardware acceleration is streaming, remote desktop or similar jobs where it MUST be done real-time and some quality loss is acceptable (or when the device's CPU is garbage like in embedded devices, but no sane person would try to transcode blurays on a smartphone)

      Comment


      • #4
        Originally posted by starshipeleven View Post
        A word of caution: encoding hardware acceleration may very well have lower quality or less settings than encoding done on CPU. Intel's Quick Sync for example is like that.

        The main reason for encoding hardware acceleration is streaming, remote desktop or similar jobs where it MUST be done real-time and some quality loss is acceptable (or when the device's CPU is garbage like in embedded devices, but no sane person would try to transcode blurays on a smartphone)
        Yes, I heard / read about that. But therefore a flexible approach sounds very interesting. Maybe one can experiment with the setting to reach a good compromise between encoding speed (offload) and quality.
        I tried x264 but with still good quality - but the saved bytes "gain" was rather moderate. I tried x265 and was surprised with the resulting filesize, surprisingly small, but still good quality (though still images would be blurry on scenes with movement, but this seems inherent to most efficient codecs). But the CPU (Athlon II x4 645, 4 x 3.1 GHz, slightly aged architecture but not actually slow) was on top load for a long time just to transcode my test trailer. This is why I hoped for some ASIC acceleration. I have a bit more than 2 TB to transcode, this would take probably a week of pure numbercrunching. And I lack money for a Threadripper currently.
        Stop TCPA, stupid software patents and corrupt politicians!

        Comment


        • #5
          Originally posted by Adarion View Post

          And I lack money for a Threadripper currently.
          Wait for Zen+ then. My hope is that it fixes a few of the performance bottlenecks you can see on the current generation (memory controller, inter-die communications, ...)

          Comment

          Working...
          X