xpra icon
Bug tracker and wiki

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


Opened 8 years ago

Closed 12 months ago

Last modified 5 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@…

Description

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

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

Pointers:

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 5 years ago.
stub implementation

Download all attachments as: .zip

Change History (13)

comment:1 Changed 6 years ago by rektide

Cc: rektide@… added

comment:2 Changed 6 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 5 years ago by Antoine Martin

Attachment: libva-stub.patch added

stub implementation

comment:4 Changed 5 years ago by Antoine Martin

Component: serverencodings

comment:7 Changed 5 years ago by Antoine Martin

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

comment:10 Changed 3 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 3 years ago by Antoine Martin (previous) (diff)

comment:12 Changed 2 years ago by Antoine Martin

Milestone: 3.04.0

Milestone renamed

comment:14 Changed 12 months 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 12 months ago by Antoine Martin (previous) (diff)

comment:15 Changed 12 months ago by Antoine Martin

Updates:

  • 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 12 months ago by Antoine Martin (previous) (diff)

comment:16 Changed 12 months 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 12 months ago by Antoine Martin (previous) (diff)

comment:17 Changed 12 months ago by Antoine Martin

Resolution: fixed
Status: assignedclosed

Updates:

  • 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 5 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.