DisplayVideoFrameSync vs ScheduleVideoFrame

What is the difference between these two methods? I would like to write frames to the video output at the frame rate of the card. Which method should I use?

[Waqqas Sharif]

Hello Jonas,

IDeckLinkOutput::DisplayVideoFrameSync and IDeckLinkOutput::ScheduleVideoFrame will both cause video frames to be output at the next clock interval for the specified video mode.

The primary difference is that DisplayVideoFrameSync will write/overwrite the next frame for video output, while scheduled playback (ScheduleVideoFrame / IDeckLinkVideoOutputCallback::ScheduledFrameCompleted) will push the next video frame onto a queue to be output (making it possible to insulate the video output from application latency by increasing the preroll).

If the application were using scheduled playback, the frame result in ScheduledFrameCompleted provides a means to identify if a frame was displayed late or dropped, and to correct for this situation.

If it fits the structure of your application, scheduled playback is the preferred playback mechanism, if not, it is perfectly reasonable to use DisplayVideoFrameSync.

Importantly, the minimum latency with both methods is 1 frame.

Hope this helps.

Regards
Waqqas

Hi, I also use DisplayVideoFrameSync and WriteAudioSamplesSync methods.

I'm using an internal timer for frame duration implemented as absolute clock with

Code: Select all

clock_nanosleep

My question is: is there a way to application to wait for next clock interval for the specified video mode and immediately return, as in BlueFish SDK's

Code: Select all

wait_output_video_synch(.., ..);

method.
Which causes the application wait next frame interval (I believe this is implemented as in h/w that generates interrupt when vertical retrace happens).

And also: is my method optimal (clock_nanosleep to wait for 1 frame_duration) ?

My system is Ubuntu Linux Server and I don't use Scheduled output for various reasons.

Thanks.

[Cameron Nichols]

Hi Sayit,

The DeckLinkAPI has been developed with non-blocking function calls. As such, there are no wait functions in the DeckLinkAPI.

I suggest instead of calling DisplayVideoFrameSync/WriteAudioSamplesSync, use the ScheduleVideoFrame/ScheduleAudioSamples [1][2]. With scheduled video/audio, you can then implement ScheduledFrameCompleted callback [3] and provide a blocking thread in your application.

Regards
Cameron

Refs (DeckLink SDK manual)
[1] 2.5.3.11 IDeckLinkOutput::ScheduleVideoFrame method
[2] 2.5.3.19 IDeckLinkOutput::ScheduleAudioSamples method
[3] 2.5.6.1 IDeckLinkVideoOutputCallback:: ScheduledFrameCompleted method

Hi, thanks for your reply.

As I mentioned there is some reasons that I abandoned scheduled playback methods. My earlier version of playback app was based on this. The thing is we develop professional encoder and decoder devices, mostly using blackmagic cards.

The problem is, the end user side (mostly a TV channel) many things go wrong, for example: signal cable occasionally unplugged and re-plugged (this can be as short as <1 secs or as long as several hours), source stream maybe corrupted partially or completely lost for some time, etc.. Our customers expects the device (actually playback app for this example) will continue to work no matter what, in case of no signal it should output as configured (black frame, colorbar, lastframe or custom picture, etc..) when signal and stream returns to normal, picture and sound must be perfect in sync etc.

To me especially keeping the A/V sync in scheduled mode in case of aforementioned problems happens is not easy to maintain. So I recently revised the whole algorithm and it is best to me to use sync methods instead of Scheduled ones. Perhaps you should implement blocking version of video frame sync function on next SDK update. And with it also double or triple buffering would be nice. While current frame displayed I would dma next frame to the card (again as in Bluefish444 SDK's).

Anyway I'll stick witch sync methods for now. It works much much better with my revised algorithm.
Thanks again.