Xpra: Ticket #451: libva accelerated encoding

Split from #370, see also #202 for the decoding side.

The only hardware supported by libva for accelerated encoding are some Intel chips.


Note: libva can encode to other formats (avc, mpeg2, ..) and maybe this can be useful in the future.

Mon, 13 Jul 2015 05:28:41 GMT - rektide: cc set

Fri, 04 Sep 2015 07:55:55 GMT - Antoine Martin: priority, status, milestone changed

Raising, Intel's Valley Vista makes this much more interesting. Awaiting hardware to take this on.

Mon, 11 Jan 2016 05:05:00 GMT - Antoine Martin: attachment set

stub implementation

Thu, 12 May 2016 09:43:45 GMT - Antoine Martin: component changed

Spotted: Add Low power, High performance h264 encoder support.

Fri, 16 Sep 2016 07:35:51 GMT - Antoine Martin:

Could be used for 10-bit colour too, see #909.

Mon, 12 Mar 2018 14:57:33 GMT - Antoine Martin: milestone changed

As per Fedora 28 Planning For VA-API 1.0 Support, Libva 2.0 was released last October with H.264 FEI support in its API, deprecating older parts of the API, fixing a race condition with the Wayland support, renaming some parts of the API, improving the logging capabilities, and various other changes. Libva 2.0 broke API/ABI compatibility with older versions of this Intel-developed Video Acceleration API.

We want to target libva 2.0, so let's wait for Fedora 28 beta.

OBS does it through ffmpeg: Add linux VAAPI h.264 encoding support - I'm not sure we should do the same: ideally we can reduce the dependency on ffmpeg, not increase it.

Wed, 20 Mar 2019 05:06:15 GMT - Antoine Martin: milestone changed

Milestone renamed

Sat, 21 Sep 2019 12:05:06 GMT - Antoine Martin: milestone changed

See also #1666

Sun, 14 Jun 2020 15:28:42 GMT - Antoine Martin:

Contrary to what I said in ticket:1666#comment:6, I can't get vaapi to encode anything with my nvidia card, but it does work well with the Intel iGPU.

Mostly working as of:

With the default quality setting, the performance is quite good.

Still TODO:

Mon, 15 Jun 2020 17:19:18 GMT - Antoine Martin:


New bug when testing with glxgears: do_check_pipeline: csc swscale(BGRX 300x300 - NV12 300x300) is closed - why is it closing?

New TODO: do scaling with libyuv before converting to NV12?

Tue, 16 Jun 2020 15:25:32 GMT - Antoine Martin:

New bug when testing with glxgears...

This bug affected csc_swscale, which is used by the distros that don't have csc_libyuv (ie: Debian and Ubuntu for sure, maybe others), it was introduced in r8125 (v0.15.x in 2014!), just fixed now in r26734. This caused video pipelines with csc_swscale to constantly recycle. Amazing that this was not spotted earlier. (I do have libyuv installed almost everywhere, so there is that)

Wed, 17 Jun 2020 16:05:53 GMT - Antoine Martin: status changed; resolution set


Notes about this updated enc_ffmpeg codec:

This will do for now. More testing needed, especially with an AMD card.

Sat, 23 Jan 2021 04:55:54 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/451