[FFmpeg-devel] [PATCH] lavc/amfenc: Retain a reference to D3D frames used as input during the encoding process

Alexander Kravchenko 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 mailing list