diff options
author | Sven Gothel <[email protected]> | 2018-01-12 02:40:17 +0100 |
---|---|---|
committer | Sven Gothel <[email protected]> | 2018-01-12 03:08:47 +0100 |
commit | 08aa5c376a5d80743ac79bb5d560ed145a75de59 (patch) | |
tree | d76fcbccb3839d05bc2860b857e01d0f198d69cd /win/images | |
parent | a01d0cf9b9a7367b4bd5d094470cd50e68ebec45 (diff) |
VAAPI: Initial Patch (WIP)vaapi-encoder
- Enabling VAAPI for GNU/Linux (SYS_LINUX) only, adding libraries 'X11 va-drm va-x11 va'
and USE_VAAPI define.
- hb.c:
- Adding global static 'vaapi_device_ctx0' default device
initialized via hb_avcodec_init() and released via hb_avcodec_free()
- hb_avcodec_vaapi_set_hwframe_ctx() attaches the new AVHWFramesContext
to the AVCodecContext
- hb_avcodec_test_encoder(..) adds VAAPI branch,
needs refinement
- encavcodec.c
- adding VAAPI branches, enabling available, needs refinement
Discussion:
First of all, only on Intel hardware I was able to produce a correct
encoded result. On AMD we seemingly have YUV420 / NV12 artifacts.
Therefor I need to learn more details on the pix_fmt handling
as described below.
While adding the VAAPI ffmpeg support the following might be an issue.
Usually HB seems to operate with AV_PIX_FMT_YUV420P in general
being set in the AVCodecContext's pix_fmt.
VAAPI performs as follows:
- It uses hardware frames on the target device, which are being transported
from the software device. Both format should be allowed to differ??
- AVCodecContext's pix_fmt uses AV_PIX_FMT_VAAPI
- AVHWFramesContext: format uses AV_PIX_FMT_VAAPI and sw_format AV_PIX_FMT_NV12,
the latter hinting on the actual hw-frame's target format.
- AV_PIX_FMT_NV12 uses interleaved UV data, where AV_PIX_FMT_YUV420P uses
seperated planes. Both use a separated Y plane upfront.
Therefor both formats are not picture compatible, memory requirements are same.
- Encode(..) hardcodes the source frame's to AV_PIX_FMT_YUV420P in VAAPI case,
usually the AVCodecContext's pix_fmt is being used.
I need to identify how HB uses AVCodecContext's pix_fmt, i.e. respects
the desired pix_fmt.
Then a hw_frame gets allocated and the source frame is being transported
to this target. Probably it happens here in VAAPI AMD case, that the YUV420
data is not being transformed to NV12.
Now the hw_frame is being sent 'avcodec_send_frame' and the code-path re-aligns
with non VAAPI.
Further fixes to do:
Naming of VAAPI's profile and level .. figuring out which settings are generally accepted.
Now the bf (b-frames) is set to zero, since it produces a failure otherwise.
The latter should only happen in certain profiles, but .. it does even in 100=high
Diffstat (limited to 'win/images')
0 files changed, 0 insertions, 0 deletions