DisplayVideoFrameSync vs ScheduleVideoFrame

Ask software engineering and SDK questions for developers working on Mac OS X, Windows or Linux.
  • Author
  • Message
Offline

Jonas Geduldig

  • Posts: 34
  • Joined: Tue Jun 17, 2014 7:04 pm

DisplayVideoFrameSync vs ScheduleVideoFrame

PostWed May 03, 2017 3:30 pm

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?
Offline

Waqqas Sharif

Blackmagic Design

  • Posts: 21
  • Joined: Tue Oct 04, 2016 1:47 am

Re: DisplayVideoFrameSync vs ScheduleVideoFrame

PostThu May 04, 2017 1:19 am

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
Offline

Sayit Belet

  • Posts: 3
  • Joined: Thu Jan 11, 2018 9:23 am

Re: DisplayVideoFrameSync vs ScheduleVideoFrame

PostThu Jan 11, 2018 9:50 am

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.
Offline

Cameron Nichols

Blackmagic Design

  • Posts: 127
  • Joined: Mon Sep 04, 2017 4:05 am

Re: DisplayVideoFrameSync vs ScheduleVideoFrame

PostMon Jan 15, 2018 11:32 pm

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
Offline

Sayit Belet

  • Posts: 3
  • Joined: Thu Jan 11, 2018 9:23 am

Re: DisplayVideoFrameSync vs ScheduleVideoFrame

PostThu Jan 18, 2018 12:48 pm

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.

Return to Software Developers

Who is online

Users browsing this forum: No registered users and 1 guest