Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libva accelerated encoding #451

Closed
totaam opened this issue Nov 5, 2013 · 10 comments
Closed

libva accelerated encoding #451

totaam opened this issue Nov 5, 2013 · 10 comments

Comments

@totaam
Copy link
Collaborator

totaam commented Nov 5, 2013

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.

@totaam
Copy link
Collaborator Author

totaam commented Sep 4, 2015

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

@totaam
Copy link
Collaborator Author

totaam commented Jan 11, 2016

2016-01-11 05:05:00: antoine uploaded file libva-stub.patch (23.5 KiB)

stub implementation

@totaam
Copy link
Collaborator Author

totaam commented May 12, 2016

@totaam
Copy link
Collaborator Author

totaam commented Sep 16, 2016

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

@totaam
Copy link
Collaborator Author

totaam commented Mar 12, 2018

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.

@totaam
Copy link
Collaborator Author

totaam commented Sep 21, 2019

@totaam
Copy link
Collaborator Author

totaam commented Jun 14, 2020

Contrary to what I said in #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

@totaam
Copy link
Collaborator Author

totaam commented Jun 15, 2020

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?

@totaam
Copy link
Collaborator Author

totaam commented Jun 16, 2020

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)

@totaam
Copy link
Collaborator Author

totaam commented Jun 17, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant