[FFmpeg-devel] [PATCH] lavc/amfenc: Retain a reference to D3D frames used as input during the encoding process
akravchenko188 at gmail.com
Thu Apr 5 22:10:26 EEST 2018
> This breaks the testcase described in
> https://trac.ffmpeg.org/ticket/6990 which is basically the same as the
> one you described in this patch.
> I get the following spammed repeatedly:
> [AVHWFramesContext @ 000000000502d340] Static surface pool size exceeded.
> [mpeg2video @ 0000000002f8d400] get_buffer() failed
> [mpeg2video @ 0000000002f8d400] thread_get_buffer() failed
> [mpeg2video @ 0000000002f8d400] get_buffer() failed (-12 0000000000000000)
> Error while decoding stream #0:1: Operation not permitted
I have checked the test, it causes such error because dxva decoder allocates small pool size for input of AV_CODEC_ID_MPEG2VIDEO
Option "-extra_hw_frames 16" solves this problem.
I have checked test using the following command line. Result video looks ok comparing to original video.
./ffmpeg -hwaccel d3d11va -hwaccel_output_format d3d11 -extra_hw_frames 12 -i matrixbench_mpeg2.mpg -an -c:v h264_amf out.mkv
I have found the logic in dxva.c which sets initial pool size
/* add surfaces based on number of possible refs */
if (avctx->codec_id == AV_CODEC_ID_H264 || avctx->codec_id == AV_CODEC_ID_HEVC)
num_surfaces += 16;
else if (avctx->codec_id == AV_CODEC_ID_VP9)
num_surfaces += 8;
num_surfaces += 2;
frames_ctx->initial_pool_size = num_surfaces;
There is alternative way to solve this problem, such as using copy surface before submitting to encoder, but this scenario will spend additional resources.
More information about the ffmpeg-devel