summaryrefslogtreecommitdiffstats
path: root/win/images
diff options
context:
space:
mode:
authorSven Gothel <[email protected]>2018-01-12 02:40:17 +0100
committerSven Gothel <[email protected]>2018-01-12 03:08:47 +0100
commit08aa5c376a5d80743ac79bb5d560ed145a75de59 (patch)
treed76fcbccb3839d05bc2860b857e01d0f198d69cd /win/images
parenta01d0cf9b9a7367b4bd5d094470cd50e68ebec45 (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