VA-API Gets Extended With Flexible Encoding Infrastructure

[phoronix]

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?page=news_item&px=VA-API-FEI

[Adarion]

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.

[starshipeleven]

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)

[Adarion]

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.

[mlau]

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, ...)