On Sun, Jul 20, 2025 at 11:15 AM Dash Santosh Sathyanarayanan <dash.sathyanaraya...@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-requ...@ffmpeg.org with subject "unsubscribe".
