[FFmpeg-devel] [PATCH v5 1/2] avfilter: add scale_d3d11 filter

[Dash Santosh Sathyanarayanan]

On 20-07-2025 15:22, Hendrik Leppkes wrote:
> On Sun, Jul 20, 2025 at 11:15 AM Dash Santosh Sathyanarayanan
> <dash.sathyanarayanan at multicorewareinc.com> wrote:
>>
>> Regarding the while loop in hwcontext_d3d11va get_buffer, I understand
>> the concern about introducing an unbounded wait. However, there have been
>> a couple of issues reported in the past that highlight this problem:
>>
>> - https://lists.ffmpeg.org/pipermail/libav-user/2024-March/013469.html
>> - https://lists.ffmpeg.org/pipermail/ffmpeg-trac/2023-October/067420.html
>>
>> In both the cases, the error reported was: "static surface pool size exceeded".
>> The suggested workaround was to increase extra_hw_frames, but in practice,
>> this isn't always feasible. But in practice, for decoder-bound D3D11 resources,
>> the driver restricts ArraySize to 64, which caps the total surface pool size -
>> so increasing extra_hw_frames isn’t always viable.
>>
>> In such scenarios, a short retry loop becomes necessary to maintain pipeline
>> flow and avoid premature allocation failures. I instrumented the retry logic
>> in one of my test cases - 4K to 1080p AVC transcode using D3D11VA decode
>> and Media Foundation encode - and observed the following behavior:
>>
>> - Most frames succeed with 1-2 retries
>> - Roughly 1 in 100 frames may require up to 10 retries
>>
>> Based on this, I’ve bounded the retry count to 50. This allows enough headroom
>> without risking an infinite loop. Please let me know if this works.
>>
>
> You are just piling hacks ontop of hacks. As I have said before, this
> is the wrong layer to solve your specific problem. It will not be
> accepted as part of the hwcontext.
> Move it to a user-layer.
>
> - Hendrik

Just to clarify - the error is being triggered from within avcodec_send_packet, due to
get_buffer returning ENOMEM when all surfaces are busy. In that case, do you still think
it should be handled entirely from the user layer?

Would appreciate your guidance on how best to manage this scenario without
disrupting the decode pipeline.

- Dash