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.
Raising, Intel's Valley Vista makes this much more interesting. Awaiting hardware to take this on.
stub implementation
Spotted: Add Low power, High performance h264 encoder support.
Could be used for 10-bit colour too, see #909.
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.
Milestone renamed
See also #1666
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:
libyuv
support for NV12
, since we need this pixel format to feed vaapi
With the default quality setting, the performance is quite good.
Still TODO:
NV12
support to csc_swscale
so Debian users aren't left behind (why don't they just package libyuv
??)
Updates:
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
?
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)
Updates:
vaapi
is Linux-only
XPRA_LIBAV_TRACE=1
env var to enable full trace logging
baseline
)
Notes about this updated enc_ffmpeg
codec:
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..)
This will do for now. More testing needed, especially with an AMD card.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/451