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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
