On 1/29/19 2:21 PM, Marton Balint wrote:
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
In my original development, I found that the Decklink device was very
picky about getting too few preroll frames. As recall, less than 30
would produce erratic behavior (dropped frames). Perhaps that has
changed in newer releases of the SDK.
Either way, why would the default behavior ever be to drop even a single
frame unless specifically aborted by the user? Seems sloppy, and when
half second fades at the end are dropped it makes the video ending
abrupt. The current driver would be useful only in a scenario where
ffmpeg was used to generate a final HD-SDI video stream. The tool is
much more capable than that.
Deron
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel