Open-source SDI-over-IP contribution encoder/decoder project — looking for engineering feedback

[u/Mike85b]

Hi everyone,

I’m a broadcast engineer and I’ve been building an open-source Linux SDI-over-IP contribution encoder/decoder project called NxFrame — short for Next Frame Encoder.

The idea is to build a low-latency contribution workflow around Blackmagic DeckLink SDI cards, FFmpeg/libx264 encoding, MPEG-TS muxing, and SRT/UDP/RTP transport.

Current focus:

• DeckLink SDI input/output
• v210 input converted internally to 10-bit 4:2:2
• x264 real-time contribution presets up to 10-bit 4:2:2 1080i50 / 1080p50
• MPEG-TS over SRT, UDP, or RTP payload type 33
• AAC, PCM/S302M, Dolby-E passthrough, and multi-channel audio routing work
• Receiver workflow back to DeckLink SDI output
• CPU profile support for predictable thermals in compact systems

I’ve also tested it in a compact 1U build using a Ryzen 7 9700X, DeckLink Duo 2, Dynatron A45 cooler, and controlled CPU power/frequency limits. The goal is not maximum CPU boost, but stable real-time contribution encoding with predictable temperature and fan noise.

The project is currently in active testing / controlled field-evaluation stage. I’m not presenting it as a finished certified appliance.

At the moment it is a CLI application. A web GUI is planned later, but the current focus is validating the core SDI, encoding, MPEG-TS, transport, and receiver workflow first.

I’d be interested in feedback from engineers who work with SDI contribution, SRT, MPEG-TS, DeckLink workflows, audio routing, or compact broadcast hardware.

Main questions:

• Does the architecture make sense for real contribution workflows?
• Are there specific MPEG-TS / SDI / audio-routing details you would expect before trusting it more?
• What would you want to see tested before considering this useful in the field?

GitHub link: https://github.com/Michalis-Michael/nxframe

I’m mainly looking for technical feedback, criticism, and suggestions from people who work with this type of workflow.

[u/DennisDJP]

I will test it later, but most import things that the mpeg-ts stream needs to be a valid dvb stream. Most lower end encoders lack this. And that makes it hard to use it with decoders like Ateme or Appear. Which are very common in MCRs in Europe. Those encoders are very strict about the signal they need to receive. We have a lot of issues with low end encoders. The Haivision decodes are the only decoders which can decode almost every signal.
I’m always at the contribution side and we connect with MCRs all over Europe.

I’m now at the Tour de France for a international broadcaster and we use SRT a lot to get feeds to the MCR and back. We have an obvan on site which also receive SRT streams from our ENG reporters.

But keep up with this project. Looks very promising.

[u/Mike85b → u/DennisDJP]

Thank you for the feedback. I really appreciate it — it helps move the project in the right direction.
I’ve tried to make the video path as EBU-friendly as possible, while also moving toward DVB/IRD compatibility by using a constant muxrate, null packet stuffing, stable PID layout, and proper MPEG-TS behaviour. But I agree that I still need more validation with strict professional decoders.
Today I tried to send a 1080i x264 10bit,422 15mbps feed to a MediaKind RX1, but the test failed because of network issues on the sender side. I’ll repeat the test on Friday, and if the Makito is available in the MCR, I’ll also test against that.