Should frame retrieval block at the framerate?

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?

[Cameron Nichols]

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