Dropped Frames on Decklink Quad 2 using SDK

Hi,

we are using a Decklink Quad 2 to capture and encode 8 video feeds (1080p59.94). The PC is an HP-Workstation Z840 with 2 Xeon-CPU E5-2640 v4 hyperthreaded to 40 virtual cores running a win10.

At approx. 60% CPU-Utilization (even on all cores) the Decklink starts to drop frames (missmatch in successive timestamps from IDeckLinkVideoInputFrame::GetStreamTime).
But the strange thing is, that this effect does not always appear. Sometimes the CPU-Utilization can be up to 90% and no frame is dropped.

To test this behaviour i created a simple application that only captures the frames to check stream times while some threads in the backgrond simulate CPU-Utilization.

DecklinkTest Application.zip

source code test application VS2015

(56.31 KiB) Downloaded 91 times

Is there a possibility to get more information from the devices why frames are dropped?
Can the capture-performance be improved by assigning fixed cpu usage?
What else might have a effect on dropping the frames?

[Cameron Nichols]

Hi Steffen,

Thanks for providing your sample application - what version of Desktop Video are you running? Is the dropped frame always on a specific input channel or is it unpredictable?

I have run the project - I am working with 8 channels on DeckLink Quad 2 card, 1080p59.94. I have added approx 90 threads with 90% CPU load, but yet to see frame drop message.

There are a few things I picked up in the design:
1) It is possible (although uncommon) for VideoInputFrameArrived callback to occur with IDeckLinkVideoInputFrame* object equal NULL, even with active input capture. This could occur if there was delay for hardware access on video frame, however there are sufficient samples in audio buffer.

The issue with this is that the first call to AddRef() will create a valid COM object, and will call GetStreamTime() with unpredictable output.

2) There are calls to WaitForSingleObject(HANDLE) within the callback. Although use of mutexes are key to reliable multi-threaded applications, you need to ensure that the Callbacks are processed in reasonable timeframe so as not to block driver. It would be better to use non-blocking PostMessage and construct m_lErrors outside callback.

I hope this helps.

Kind Regards
Cameron Nichols

Hi Cameron,

currently we are using Version 10.9.3. As video source i use a Terranex-Converter and a SDI Crossbar/Router to multiply the video feeds, all synced by the Terranex Ref-Out.

The dropped frames do not occur on a specific channel and in no regular manner.
Using the test application, when you go slowly up with the CPU utilization. At a certain point the devices start to drop, and when CPU utilization is decreasing the devices seem to recover.

Our "real" application is by far more complex than this sample but as long as the dropped frames occur in this simple application its hard to make progress.

Concerning your advices:

(1) I just forgot to check the pointer in the sample...

(2) That was my first thought too, but i check the time spend in IDeckLinkVideoInputFrame::VideoInputFrameArrived and it was always far below 1ms.
I even provoked a delay of 10ms... no frame was dropped.

Regards
Steffen