[FFmpeg-devel] Decklink Output Problem

[Marton Balint]

On Tue, 29 Jan 2019, Deron wrote:

> Hello,
>
> A little history: Many years back I started using a modified version of 
> an unaccepted Decklink output patch, updated it to work for me, and 
> reposted a newer patch. Of course, the patch was not accepted for many 
> valid reasons like formatting and working only on Linux but it continued 
> to work well for me so I have stuck with it. Once an accepted Decklink 
> "encoder" was introduced, I gave it a try but could never get it to work 
> right under Ubuntu. Always crashed or did something crazy. I figured it 
> was me. Well, I've tried it out again and it work now for me. Almost. 
> This time, instead of just shrugging my shoulders I'm asking if maybe it 
> is not me since I can get it to work after a minor patch.
>
> The Problem: When I output any video, the last 60 frames are lost. 90% 
> of the time I would not even notice it, but the other 10% is another 
> story. No error is produced, and it is not file or command specific. 
> What appears to me to be happening is that the buffered frames are 
> tossed out at the end.
>
> The variable "frames_buffer_available_spots" is set to the array size 
> "frames_buffer" in the function "decklink_setup_video". Minimally, 
> "frames_buffer" is set to 60. Then the function 
> "decklink_write_video_packet" will wait if the number of available frame 
> buffers is zero. All fine and good until it gets to the closing function 
> "ff_decklink_write_trailer" where an abrupt call to the Decklink 
> function "StopScheduledPlayback" will do just that and toss out all 
> buffered frames. I have fixed this issue for me by including the 
> following ugly busy loop in "ff_decklink_write_trailer".
>
>         do {
> ctx->dlo->GetBufferedVideoFrameCount(&buffered);
>             av_log(avctx, AV_LOG_DEBUG, "ff_decklink_write_trailer 
> frames buffered: %d\n", buffered);
>         } while (buffered > 1);
>
> A conditional wait would obviously be the proper solution, but my point 
> was to test my observations.
>
> Another less serious problem I have observed is that if less than 60 
> frames are buffered to begin with, playback is not even begun. This 
> would require in the function "ff_decklink_write_trailer" that if 
> "playback_started" is not true, but frames are buffered, than playback 
> is started anyway.

Well, you can always use a shorter preroll interval, because buffered 
frames = 2 * preroll, but never more than 60. This way you can have a 
shorter supported minumum clip size and also less lost frames at the end.

Otherwise you are right, the code works as you described. Nobody cared so 
far, in fact, when "writing the trailer" it might be more desirable for 
the user to abort playback ASAP. It is rare that people play a single clip 
out with decklink, I am curious what is your use case.

Anyway, a patch can be made to fix the issues you reported, although I 
probably would insist on a user option to control write_trailer behaviour 
(quit immediately or wait for playout of buffered frames).

You probably have to factorize the code which starts the playback to a 
function and call that from write_trailer as well if needed. Since you 
know the frame rate it is enough to query buffered farmes once and sleep 
for (buffered + 1) * frame_time seconds before disabling the video/audio 
output.

Regards,
Marton