Frame tearing on decklink 8k pro

Hiya

I'm having some trouble with tearing on my decklink 8k pro.

It will be a case of it showing a bit of frame A and frame B but on top of each other - almost like an interpolation of the two. Interestingly its sometimes as if it will show frame A for say 20 lines, B for 20 lines then back to A for the rest of the frame.

I am using scheduleVideoFrame after realising that displayVideoFrameSync was not performant enough in terms of it was taking >20ms to display a frame and I need the whole business of frame creation to frame display to take less than this time.

Now that I'm using scheduleVideoFrame, according to my debug tools, it's taking sub 1.2ms to populate a frame with the new frame data and to then schedule it. This seems totally acceptable but then why is tearing occurring?

For more info about my project, it consists of a D3D program that runs on its own thread. It then adds its frame data to a thread safe queue every 50ms. The ScheduledFrameCompleted callback then looks to see if there is anything in the queue and if so, populates the completedFrame from the callback with the D3D frame data. It then schedules the frame.

I can make this problem worse (and I mean much worse) by pausing execution of my D3D program and resuming it again. At which point there is a crazy amount of tearing.

I've looked to the examples but feel like I can't gain much more information about how I would render in what is effectively one program and schedule frames from the Black Magic thread.

I really appreciate any advice that can be given.

Extra information, current target format is bmdModeHD1080p50 with bmdFormat8BitBGRA. The problem occurs at 720p50 also. I preroll 3 frames.

[Cameron Nichols]

Hi Benjamin,

It is important that you don't modify the frame data between the call to IDeckLinkOutput::ScheduledVideoFrame and IDeckLinkVideoOutputCallback::ScheduledFrameCompleted callback for that frame, this is the likely reason for frame tearing. It may be that part of the video frame has been transferred via PCIe and then another part of the application is overwriting the frame before the next PCIe transaction.

Further, I recommend implementing the IDeckLinkScreenPreviewCallback for implementing the D3D rendering task. You can then register the implemented screen preview callback by calling IDeckLinkOutput::SetScreenPreviewCallback. You can find example of this in the FilePlayback sample in the Desktop Video SDK package.

The reason for using the IDeckLinkScreenPreviewCallback::DrawFrame callback for your rendering, rather than IDeckLinkVideoOutputCallback::ScheduledFrameCompleted, is that DrawFrame will not queue frames if the render task is longer than a frame period, it will simply drop. The ScheduledFrameCompleted callback can queue waiting for return from previous callbacks, so that the completion is delivered for every frame.

Regards
Cameron