[FFmpeg-devel] Decklink Output Problem

[Deron]

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