[FFmpeg-trac] #10236(avcodec:new): av_hwframe_transfer_data fails from QSV decoded frame on Intel 4th gen hardware

FFmpeg trac at avcodec.org
Wed Mar 8 17:38:23 EET 2023

#10236: av_hwframe_transfer_data fails from QSV decoded frame on Intel 4th gen
             Reporter:  Steve Browne  |                     Type:  defect
               Status:  new           |                 Priority:  normal
            Component:  avcodec       |                  Version:  5.1.2
             Keywords:                |               Blocked By:
             Blocking:                |  Reproduced by developer:  0
Analyzed by developer:  0             |
 Summary of the bug:
 On Intel 4th gen (probably older as well) hardware decode with an h264_qsv
 decoder then try to transfer the frame to system memory with

 For reference the hwdevice_ctx was created as follows:
 av_dict_set(&dict, "child_device_type", "d3d11va", 0);
 av_hwdevice_ctx_create(&ctx, AV_HWDEVICE_TYPE_QSV, "auto", dict, 0);

 Then try to copy the frame back to system memory:
 av_hwframe_transfer_data(dstFrame, frame,

 This will fail with:
 Error synchronizing the operation: -17

 Error -17 corresponds to MFX_ERR_DEVICE_FAILED. I assume the problem is
 simply that MFXVideoVPP_RunFrameVPPAsync doesn't support copying to system
 memory on the older hardware. I updated to the latest Intel drivers etc
 and it still didn't work. On newer Intel hardware this works just fine.

 Luckily this was a result of a recent ffmpeg upgrade of our code where I
 was trying to ditch our existing code that worked with qsv/mfx directly so
 using our existing code I could see that we were creating a staging
 texture and mapping/unmapping that. So the workaround is to avoid
 av_hwframe_transfer_data and instead use av_hwframe_map to map to an
 AV_PIX_FMT_D3D11 frame. Then create the D3D11 staging texture using the
 device I get from the ID3D11Texture2D from the mapped frame, lock the
 staging texture, put those buffers on an intermediate frame then
 av_frame_copy that to the final output frame.

 I've timed the code using av_hwframe_transfer_data vs the workaround on
 newer Intel hardware and there's not much of a performance difference. If
 anything the workaround is ~0.1ms faster on average.
Ticket URL: <https://trac.ffmpeg.org/ticket/10236>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list