Should frame retrieval block at the framerate?

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

kwiley

  • Posts: 7
  • Joined: Mon Jan 25, 2021 7:25 am
  • Real Name: Keith Wiley

Should frame retrieval block at the framerate?

PostWed Feb 10, 2021 9:43 pm

If I query for frames faster than the incoming video frame rate, I don't experience a block. My main loop can "spin" faster than the framerate, receiving duplicate frames until a new frame is available. I did this by altering the CaptureStills sample to loop faster, simply by discarding the RGB conversion and write-to-disk steps. DeckLinkInputDevice::WaitForVideoFrameArrived() is not blocking, returning false, or doing anything else that would indicate any awareness of the situation. I also put a comment inside DeckLinkInputDevice::WaitForVideoFrameArrived() above the line that actually populates the frame from the front of the queue and that line is definitely being called. The queue has a new frame available, a duplicate until the frame eventually updates.

Is this the expected behavior?
Offline

Cameron Nichols

Blackmagic Design

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

Re: Should frame retrieval block at the framerate?

PostFri Mar 05, 2021 3:50 am

Hi Keith,

By design of the CaptureStills SDK sample, the call to DeckLinkInputDevice::WaitForVideoFrameArrived should block until a new frame has been received and added to the queue. You should not get duplicate frames when the queue is empty as IDeckLinkVideoFrame* receivedVideoFrame should be null on entry to function.

You may want to look at the queuing system in sample InputLoopThrough. It implements its own queue in SampleQueue.h, but has blocking and non-blocking methods for receiving new frames, waitForSample() and popSample() respectively.

Regards
Cameron

Return to Software Developers

Who is online

Users browsing this forum: No registered users and 4 guests