Open-source SDI-over-IP contribution encoder/decoder project — looking for engineering feedback
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.