How different is SDK 12 from current build?

Long time reader, first time poster.

I, and the company I work for (Nexstar Media Group), am a heavy OBS (Open Broadcaster Software) user. We've been having various issues with our OBS output via DeckLink (we primarily use the Duo 2). While trying to troubleshoot, I discovered the OBS coding is still using SDK 12.0. Could that be the problem? I am not a coder myself so I'm a bit in the dark on how impactful that coding could be on DeckLink operation, or not.

OBS GitHub and DeckLink folder for quick reference https://github.com/obsproject/obs-studi ... s/decklink

Thanks all!

-Chip

Two weeks, more than 250 views, no replies. Woof. Are there not Blackmagic official peeps on this forum? Would really love an answer I can pass along to the OBS team if there is indeed a major difference (or hopefully someone from BM would do just that).

Hi Chip,

The most significant changes were implemented in version 14.3 of the DeckLink SDK. For detailed information, I recommend checking the Desktop Video 14.3 SDK Migration Guide.

It seems your version of OBS was likely compiled with SDK 12.0, so for better compatibility, I’d recommend using drivers from before Desktop Video SDK 14.3, such as 12.0, 12.8.1, 12.9 or 14.2.1.

Summary of changes:

1 The IDeckLinkMemoryAllocator interface has been replaced
with the IDeckLinkVideoBufferAllocatorProvider and
IDeckLinkVideoBufferAllocator interfaces.
2 Removed the IDeckLinkInput::SetVideoInputFrameMemoryAllocator
method, the memory allocators are provided with the new method
IDeckLinkInput::EnableVideoInputWithAllocatorProvider.
3 Removed the IDeckLinkOutput::SetVideoOutputFrameMemoryAllocator
method, custom memory allocation should be implemented external
to the DeckLinkSDK and generated buffers provided via the
IDeckLinkOutput::CreateVideoFrameWithBuffer method.
4 Removed the IDeckLinkEncoderInput::SetMemoryAllocator method, only the
default allocator can be used with IDeckLinkEncoderInput capture.
5 Added the new interface IDeckLinkVideoBuffer that provides access to the underlying
video frame buffer.
6 Added the new interface IDeckLinkMacVideoBuffer, a specialized video buffer that
provides access to the underlying Mac IOSurface via CVPixelBuffer.
7 The IDeckLinkVideoFrame::GetBytes method has been removed.
Frame buffer access is now provided via the IDeckLinkVideoBuffer or
IDeckLinkMacVideoBuffer interfaces.
3Desktop Video 14.3 SDK Migration Guide
8 Added a new interface IDeckLinkMacOutput that extends IDeckLinkOutput with
a method to create an IDeckLinkMutableVideoFrame interface pointer that wraps a
CVPixelBufferRef object.
9 Added the new helper method
IDeckLinkMutableVideoFrame::SetInterfaceProvider to simplify the
implementation of custom interfaces associated with an IDeckLinkVideoFrame.
10 Added the new helper method IDeckLinkOutput::RowBytesForPixelFormat to
calculate row bytes for pixel format.
11 Added the new conversion method IDeckLinkVideoConversion::ConvertNewFrame
that creates and converts into the destination IDeckLinkVideoFrame, with an optional
IDeckLinkVideoBuffer buffer.

Hope this helps with your troubleshooting!

Regards

Thanks for trying? I guess? I'm already aware significant changes were made which is why I'm here looking for insight about those changes.

I have seen the "migration guide" but it doesn't answer my question. Does OBS running on SDK 12 cause issues with using drivers from 14.3 or more current? An OBS programmer told me "I would not expect much change, since the SDK provides mostly just entry points to the runtime". I do not have the backend experience to understand the changes made so I don't have a good response for him.

I'm looking for something official from Blackmagic or a Blackmagic SDK guru to tell me "oh man, yes! x and y and z are all negatively impacted if you don't update the coding language to at least 14.3" so I can pass that on to the OBS folks. Or maybe it's a "naw, no need to update. everything will work just fine".

The generic tips of your response don't quite get me where I'm looking to be.

As a maintainer of some other opensource software using the decklink sdk, our latest release is using sdk 11.0, and development is using 12.3. Other than the issue introduced in 14.3 (which requires a trivial code change to handle, and doesnt require updating the sdk), there has been no reason to update the sdk. The only times we update the sdk are when we want to use some newer functionality that require newer sdk.

Blackmagic are generally good about maintaining backwards compatibility in the sdk. They do occasionally introduce bugs in the drivers though, so our users are often hesistant to update those in case of new issues which is partly what drives our slow sdk update.
I am typically running near latest drivers on my dev and production machines, and havent encountered any issues even with these ancient sdk versions