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

[Hendrik Leppkes <h.leppkes@gmail.com>]

On Sun, Jul 20, 2025 at 11:15 AM Dash Santosh Sathyanarayanan
<dash.sathyanarayanan@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".