[FFmpeg-devel] Advice on patch: Decklink flushes most buffered frames at end of video instead of displaying them

[FFmpeg-devel] Advice on patch: Decklink flushes most buffered frames at end of video instead of displaying them

[Matthew Rademaker via ffmpeg-devel]

When playing out video to a Decklink SDI 4K card I've found that all/most
of the buffered frames get flushed instead of being displayed, essentially
shortening the video by the amount of pre-roll. I found a way to fix this
by adding a counter of outstanding frames, then delaying the call to
StopScheduledPlayback until all frames are returned.

I would submit this as a patch, but this is my first attempt at any ffmpeg
development so I wanted to see if this was the best way to fix this issue.
Are the outstanding frames already counted some other way? Is blocking via
sleep ideal? The StopScheduledPlayback has a pts parameter, which I assume
means that it should only stop playback at that time - should this not
prevent the issue I am seeing? Why would it flush the frames?

Again, I'm new to all this so more information would be great.
-- 
Matt
_______________________________________________
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".

Re: [FFmpeg-devel] Advice on patch: Decklink flushes most buffered frames at end of video instead of displaying them

[Devin Heitmueller]

On Tue, Mar 4, 2025 at 10:47 PM Matthew Rademaker via ffmpeg-devel
<ffmpeg-devel@ffmpeg.org> wrote:
>
> When playing out video to a Decklink SDI 4K card I've found that all/most
> of the buffered frames get flushed instead of being displayed, essentially
> shortening the video by the amount of pre-roll. I found a way to fix this
> by adding a counter of outstanding frames, then delaying the call to
> StopScheduledPlayback until all frames are returned.
>
> I would submit this as a patch, but this is my first attempt at any ffmpeg
> development so I wanted to see if this was the best way to fix this issue.
> Are the outstanding frames already counted some other way? Is blocking via
> sleep ideal? The StopScheduledPlayback has a pts parameter, which I assume
> means that it should only stop playback at that time - should this not
> prevent the issue I am seeing? Why would it flush the frames?

Thanks for reaching out.

This is a longstanding issue that has been reported before, and I just
never got around to submitting a fix for (since for my particular use
case, I actually want it to exit immediately, although I realize this
isn't the common use case).  The correct fix is simply to change the
StopScheduledPlayback to not exit immediately (for which there is a
specific argument, IIRC).  You shouldn't need to do any sort of
counters/timers to achieve the desired behavior.

If you still can't get it to work, let me know and I'll take a look
and submit the appropriate patch.

Regards,

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".