xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 9 years ago

Closed 2 years ago

Last modified 17 months ago

#451 closed enhancement (fixed)

libva accelerated encoding

Reported by: Antoine Martin Owned by: Antoine Martin
Priority: major Milestone: 4.1
Component: encodings Version:
Keywords: Cc: rektide@…


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.

Attachments (1)

libva-stub.patch (23.5 KB) - added by Antoine Martin 6 years ago.
stub implementation

Download all attachments as: .zip

Change History (13)

comment:1 Changed 7 years ago by rektide

Cc: rektide@… added

comment:2 Changed 7 years ago by Antoine Martin

Milestone: future0.17
Priority: minormajor
Status: newassigned

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

Changed 6 years ago by Antoine Martin

Attachment: libva-stub.patch added

stub implementation

comment:4 Changed 6 years ago by Antoine Martin

Component: serverencodings

comment:7 Changed 6 years ago by Antoine Martin

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

comment:10 Changed 4 years ago by Antoine Martin

Milestone: 0.173.0

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.

Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:12 Changed 3 years ago by Antoine Martin

Milestone: 3.04.0

Milestone renamed

comment:14 Changed 2 years ago by 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:

  • r26720 (+r26723 + r26730 fixups) libyuv support for NV12, since we need this pixel format to feed vaapi
  • r26721 use vaapi for the codecs that are available
  • r26722 enable vaapi in ffmpeg rpm

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

Still TODO:

  • add NV12 support to csc_swscale so Debian users aren't left behind (why don't they just package libyuv??)
  • fix bugs (ie: color problems, client decoding errors, etc)
  • test on AMD
  • test more codecs, adapt encoder scoring
  • assuming this works well enough, backport to v3.1
Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:15 Changed 2 years ago by Antoine Martin


  • r26725: NV12 support for swscale - also needed for when we want to downscale video before compressing since libyuv can't do that yet

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?

Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:16 Changed 2 years ago by 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)

Last edited 2 years ago by Antoine Martin (previous) (diff)

comment:17 Changed 2 years ago by Antoine Martin

Resolution: fixed
Status: assignedclosed


  • r26749 hide warnings and messages during initialization / probing
  • r26751 vaapi is Linux-only
  • r26750 + r26752 fast path logging callback, XPRA_LIBAV_TRACE=1 env var to enable full trace logging
  • r26753 simplify win32 sanity checks
  • r26754 type safe access to encoding options
  • r26755 set more codec specific options
  • r26756 set profile correctly (support html5 client - which needs baseline)
  • r26757 score h264 and hevc higher than mpeg2 by default

Notes about this updated enc_ffmpeg codec:

  • we use a fixed quality which is set when the encoder is initialized
  • could also be used for encoding h264, but somehow the html5 client then fails to decode the stream (problem with nals? or different settings from enc_x264?)
  • vp9 and hevc cause the process to exit! (ouch! so they're not enabled..)
  • pyav is neat - could this replace the cython glue? (and keep the zerocopy?)

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

comment:18 Changed 17 months ago by migration script

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

Note: See TracTickets for help on using tickets.