Re: [FFmpeg-devel] [PATCH] Playout to DeckLink will wait for all buffered frames before stopping.

[Marvin Scholz <epirat07-at-gmail.com@ffmpeg.org>]

On 8 Jul 2025, at 18:22, Devin Heitmueller wrote:

> Hi Marvin,
>
> On Tue, Jul 8, 2025 at 11:19 AM Marvin Scholz
> <epirat07-at-gmail.com@ffmpeg.org> wrote:
>> I think even if a frame is schedule "far" in the future, if I want them
>> all played out then it should probably still wait, no? As what is considered
>> "far" is a matter of interpretation…
>
> That probably depends.  If the clock gets screwed up and a frame is
> submitted with a PTS five hours into the future you don't want it to
> stall for five hours.  The driver lets you control the number of
> buffers available (and has limits on such), but IIRC not explicitly on
> the timestamps submitted (which dictates when the frame gets played
> out).
>
> But yeah, "far" is a matter of interpretation.  In practice you
> generally won't see frames queued more than a second in advance. I
> think we can agree on a reasonable threshold that prevents it getting
> stuck in a loop for potentially hours if the clocks were bad but
> doesn't cause issues in practice (e.g. 2 seconds?).
>
>> Also there should likely be an option to opt in to this new behavior?
>
> Agreed, this behavior should probably be configurable.  I would argue
> though that the behavior provided by this patch should be the default.
> AFAIK, it wasn't an intentional decision to terminate before all
> buffers were output, and flushing pending data on close is the
> standard behavior for other muxers.
>
> On a personal note, I work with realtime decoding and thus the
> existing behavior is my preference (since I want it to terminate
> immediately).  But I think my use case is far less common than people
> who simply want to play out their file based content to the Blackmagic
> device.

What about a drain_timeout option? This could then solve all the
mentioned cases. We could have it default to something like 1000ms,
and for your use-case you could set it to 0, to not drain at all?

>
> Devin
>
> -- 
> Devin Heitmueller, Senior Software Engineer
> LTN Global Communications
> o: +1 (301) 363-1001
> w: https://ltnglobal.com  e: devin.heitmueller@ltnglobal.com
> _______________________________________________
> 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".
_______________________________________________
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".