CasparCG -> SMPTE ST-2110

Hi everyone,

I am increasingly getting enquiries from new and existing clients about moving from a traditional HD-SDI key and fill setup to an IP based solution, specifically ST-2110. Personally I think it is a bit too early for these clients to be doing that already, but at the end of the day it is their call not mine!
My job is to try and fit within their ecosystem.

I know CasparCG can already output NDI, but has anyone looked into this possibility yet, or has an idea of what kind of effort would be required to add being able to output to ST-2110 into the server code?


I think it needs someone to either do the work to implement it or be willing to fund development.

Probably best to start with an off the shelf 2110 card made by an sdi card manufacturer for simplicity and reliability

As far as I know only Matrox SMPTE ST 2110 Network Interface Controller (NIC) Cards can support the IP broadcasting such as X.mio5 Q25 card. But obviously I don’t think CasparCG is ready to support the Matrox SDK.

I think that Deltracast also has such cards. I probably will talk to them at IBC about that.

@carmacoma: Would you be able and willing to sponsor the development of a consumer for Matrox or Deltacast cards? And also: Would you be able to help on the development, by offering a test facility? Because I don’t think, that any of our developers has a monitor, that supports ST-2110. So one would probably use an SDI card, that is compatible to the chosen SDK. But to make sure, that it works, somebody would then need to test it in a ST-2110 environment.

Deltacast has at least one output card DELTA-ip-ST2110 01 - Deltacast and an input version DELTA-ip-ST2110 10 - Deltacast. SuperFly owns a pair of these, which are currently in my possession. But Im not sure if I have the time to commit to anything right now.

Bluefish looks to have some new cards under ‘coming soon’ that support ST-2110 also. It will probably require some changes in casparcg to support, but will probably be easier than a new manufacturer once the cards are available.

One big hurdle to supporting new cards is that the licensing of the SDK is often incompatible with CasparCG. As in, the source code of the SDK cannot be shared publicly, and so any builds containing the SDK will not be publicly sharable without violating the GPL license of CasparCG.
I dont think this should block this from being prototyped at least, as I think there will be ways we can work around this limitation

@didikunz If AJA would release a ST-2110 card that would be ideal. They recently open sourced their SDK, and so is an easy candidate for supporting. This is on my list of things to play around with if I can find time


AJA have that already - sort of. There is the Avid Artist DNxIP, which is based on AJAs Io 4K-Hardware. It does ST 2110 but seems to be quite hard to get these days.
Perhaps @didikunz can ask AJA as well, if you’re already on it :wink:
There also seem to be efforts to get ffmpeg to support it (see: - Support of SMPTE 2110 in FFmpeg - OSS Project detail) but that might also take some time

That is right, I did not think about that.

If everything works out as expected and I really make it to IBC this year :slight_smile: I can go around these manufactures and ask them abut their plans concerning ST-2110. As I currently do not have a use for ST-2110 (as most of us, I guess), we should make sure, that there is a demand for that in the community, before we start to invest time and money into such a solution.

@carmacoma: Can you tell us, how much you see a need for that? Do we need that fast, or is it ok to wait until a wider adoption of this standard.

Here in Switzerland only the national TV (SRF) is using IP workflows, with various success (compatibility issues and the like), as I heard, everybody else is still using SDI.

Some manufacturers use Mellanox ConnectX®-5
which is “off the shelf ethernet card” (more or less)
but the price is lower than a specialized card.

Kona IP from AJA seems to be no longer available.

Take into account about the need for PTP time source when transitioning to ST2110
also switch capable to handle those high bitrates.

One of the major broadcasters here in Australia who I work with is full steam ahead on ST2110 implementation. Too early in my opinion, but what can we do? :slight_smile:

They too have suggested trying to use the Matrox X.mio5 card. I am happy to pass on any cost to the broadcaster to fund development. Also, I can offer development resources (I have two high quality C devs on staff, although they have no experience with the CasparCG codebase). I can also use the broadcaster facility for any alpha and beta testing.

How much development could be recycled if this process begins now, before various manufacturers release 2110 hardware? Could there be a reasonable amount of code re-use for a future Blackmagic or AJA board for example, if dev work was done on the Matrox board?

What are any other hurdles you can see other than time, money and testing resources?


1 Like

Not really, the code that needs to be written will be using the matrox sdk to interface with their cards, so is very specific to them.
I haven’t look at the aja sdk yet, but from experience I expect that if blackmagic release any 2110 decklinks then they will work with minimal to no code changes needed. Other new decklink models worked without changes, other than adding new formats to a list.

As you have devs on staff, I would suggest they have a look at implementing something. I am happy to answer any questions they have on here, slack or email. The existing consumer implementations should be a reasonable reference on what needs to be done.

The big hurdle I expect will be as I mentioned before of SDK licensing. Deltacast require signing a NDA, which means supporting it without violating GPL will be tricky. I don’t know about Matrox, but I suspect they will be similar. Doesnt mean it isnt possible, but it does add complications

@Julusian Matrox isn’t an GA option, I think. They have SDK, of course. It’s paid, and one can buy a development card at discounted price. But no part of SDK, nor knowledge, can be incorporated in OSS program (NDA is mandatory). They sell their cards mostly in OEM model to big maket players like Ross or Viz and aren’t interested in open source market, because of risk of profit loss from them. However, it’s possible to buy some cards for internal project development, but it’s impossible to share just binaries without violating the NDA or GPL. The cards are not sold by resellers, only by OEMs and Matrox itself.

@carmacoma I think best idea is to add support ST2110 into FFmpeg, and then make it working in CasparCG. The work is started, FFmpeg reportedly can read ST2110 streams (i didn’t tested it by myself). Maybe your team can implement ST2110 producer based on it?

Matrox isn’t an GA option, I think. They have SDK, of course. It’s paid, and one can buy a development card at discounted price. But no part of SDK, nor knowledge, can be incorporated in OSS program (NDA is mandatory).

The same is true of the deltacast SDK, not sure about card availability.

However, it’s possible to buy some cards for internal project development, but it’s impossible to share just binaries without violating the NDA or GPL.

I need to check the NDA to see what the rules are around releasing software. But as it isn’t possible to include the SDK directly into CasparCG, perhaps this is a good time to get support for consumers as plugins. Or perhaps instead of a full plugin, the SDK could be wrapped in a simple dynamically linked C library exposing the minimum required functionality without revealing any sdk types.
From my understanding of GPL, that is perfectly fine as long as the user is the one to choose to use the non-compliant module and it is not distributed with the GPL binary. After all, this is how the decklink and ndi modules work. (the dynamially linked library being their SDKs)
But it depends on whether manufacturers will allow for a plugin like this to be distributed.

Even if this is not possible, then it should still be possible to use the cards, but as an in house ‘fork’ at the broadcaster. GPL allows for distributing within a company without also disclosing the code. Im not sure on where the NDA will stand on sharing that sourcecode with others who have also signed the NDA.
Not a general and opensource solution, but doable.

I think best idea is to add support ST2110 into FFmpeg

That is definitely a solution that is also welcome, it doesnt have to be one or the other.

Hi @Julusian @didikunz. Our customer is building new mobile units that will be put in play beginning in 2024 and these will be built for ST2110. Has there been any movement or development related to ST2110 since this thread was active in Nov 2021? Thanks.

I have been playing with doing 2110 with a SMPTE 2110 playout card - Deltacast recently. But the problem remains in that I can’t distribute any builds containing this or my full sourcecode because of the SDK being under an NDA, and so isnt GPL compatible.

I am considering trying GitHub - OpenVisualCloud/Media-Transport-Library: Real-time and low latency media transport(st2110) stack based on DPDK too, as that would be a pure software implementation, but I don’t know enough about it to say if it will be possible or reliable enough.

Maybe you could build a closed source implementation for @jpadj in the mean time? Later we could go with whatever you see fit.

Thanks for the feedback. That is helpful. I’ll pass this along to our lead developer on the project. We’ve been using CCG for seven years and hope to continue using it in the future.

We at SRG SSR are also going to test the SMPTE2110-way. But will be not before June this year, as we^re now also in the first preparations of elections this year, and so reconfiguring our wire-centers :slight_smile:
Will keep you updated.

Greetings from Bern

BMD announced 2110 cards today that should be plug’n’play.


They mention that they work the same way as previous decklinks so yes plug &play. Very cool!

I’m curious how f&k will work with these. Based on the converter box, it looks like they don’t support the optional embedded alpha channel, meaning it will need to be done over 2 streams.
Will the decklink accept the rgba buffers we provide today, or will it require being fed something yuv?
And if it is over 2 streams, the ‘key-device’ function we have today isn’t the most reliable, so should probably be reworked if it needs to be relied upon.

I will probably buy one of the cards when they are on sale, so should be able to do some tests

Privacy Policy   Terms of Service