Hardware · Discipline
Video
Processing and decoding, on commodity silicon instead of a closed appliance.
Live video hardware is the most closed corner of the industry. A seamless switcher, a multi-layer processor and a network decoder are all, underneath, an FPGA or an SoC doing something well documented, and all three get sold as sealed boxes with a licence key and a support contract.
Both designs here make the same argument: the silicon is commodity, the standards are published, and the hard part is the pipeline rather than the box it comes in. One takes that as far as a modular processing mainframe. The other stops at a decoder that costs a fraction of the appliance it replaces and tells you its own IP address while it boots.
2 boards · none fabricated yet
Video · Modular AV processing mainframe
OpenAVSwitch
Phase 1 design · RTL in simulation
An open, modular AV processing mainframe: many simultaneous inputs, multi-layer real-time compositing and scaling, and seamless switching, built on commodity FPGA SoCs instead of closed, proprietary hardware.
- Phase 1 is small on purposeA 4-in / 1-out HDMI 4K seamless switcher. Prove the pipeline before scaling the frame.
- Compositing in fabricMulti-layer scaling and mixing on Zynq UltraScale+, not on a GPU that has to be scheduled.
- Seamless by constructionSwitching happens inside the video pipeline, so there's no black frame to hide.
- Modular frameInput, output and processing as separate cards, so the frame grows rather than being replaced.
Where it stands
Design and RTL only. None of it has been through professional design review or run on real hardware: it exists in simulation. Read the RTL with a sceptical eye before you rely on any of it.
- Platform
- Xilinx Zynq UltraScale+ SoC
- Phase 1
- 4-in / 1-out HDMI, 4K
- Class
- Large-format live video processor
- Language
- SystemVerilog
- Repo
- Private
Video · NDI and SRT decoder
PineMarten
SRT path built · NDI licensing unresolved
Open decoder firmware for a commodity single-board computer: a stream in over the network, a picture out of HDMI, for a fraction of what a closed appliance costs. Web UI, OSC and AES70 control, mDNS, and a boot splash that tells you the IP address of the box you're standing in front of.
- It tells you where it isFrom power-on it shows its own IP address, hostname, link speed and why it has no picture yet. A decoder that explains itself saves a walk to the truss.
- Switches without a black frameThe splash and the video live on separate hardware planes, so a stream arriving is a visibility change rather than a mode set with a blank screen in the middle of it.
- Fails over on picture, not handshakeA source is promoted when it delivers a frame, never when it merely connects. A connection carrying nothing is a failure that looks like a success.
- Hardware decode or a loud complaintSRT goes straight to the SoC's video unit. If the hardware decoder is ever missing, the firmware says so rather than quietly falling back to software and stuttering.
- One cablePower over Ethernet, or USB-C on a bench.
Where it stands
No board exists yet. The SRT receive and decode path is exercised end to end against a real stream, but in software on a development machine, and the display backend has never been run at all. Every performance figure is arithmetic from published specs, not a measurement, and the NDI decode budget in particular is an estimate with a wide error bar. Bigger than any of that: the free NDI SDK licence appears to exclude fixed-purpose Linux appliances, and that's what this is. So whether the NDI half can ship at all is an open question for the vendor, and no amount of code will settle it. SRT is unaffected.
- Platform
- Radxa ZERO 3E (Rockchip RK3566)
- Output
- 1x HDMI, 1080p60
- Transports
- SRT, NDI High Bandwidth, NDI|HX
- Control
- Web UI, OSC, AES70/OCA, mDNS
- Power
- PoE (802.3af) or USB-C
- Repo
- Private
Seamless has to be built in
Both boards turn down the same shortcut, which is to reconfigure an output and cover the gap. Switching inside the video pipeline means the change happens between frames, in fabric, with no mode set and so no black frame to hide. The decoder makes the same choice at the cheap end of the scale: its boot splash and its video live on separate hardware planes, so a stream arriving is a visibility change rather than a mode switch.
It's also why failover goes on picture rather than on handshake. A source gets promoted when it delivers a frame, never when it merely connects, because a connection carrying nothing is a failure that looks just like a success.
Where the open questions are
For the mainframe, everything. It exists as design and RTL in simulation, it has never been through professional design review, and no board has been made. For the decoder, the technical path is further along than the licensing one. The SRT receive and decode path is exercised end to end against a real stream, in software on a development machine, but the free NDI SDK licence appears to exclude fixed-purpose Linux appliances, and a fixed-purpose Linux appliance is what the product is.
No amount of code settles that one, so I've left it as a question for the vendor rather than dressing it up as a roadmap item. The SRT half is unaffected either way.
Related, elsewhere on the site
The whole bench
This is only one corner of it
The hardware index has every board on one page, and you can filter it by discipline: lighting nodes, audio boxes, video processing, the physical layer under all of it and the RF work on top.