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 are sold as sealed boxes with a licence key and a support contract.
Both designs here are the same argument made twice: the silicon is commodity, the standards are published, and the part that is genuinely hard is the pipeline, not the packaging. 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 deliberately smallA 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 is no black frame to hide.
- Modular frameInput, output and processing as separate cards, so the frame grows rather than being replaced.
Honest status
Design and RTL only. Nothing here has been through professional design review or run on real hardware - it exists in simulation. Read the RTL critically before relying 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 are 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 - not 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.
Honest status
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 executed at all. Every performance figure is arithmetic from published specs, not a measurement. 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, which is exactly what this is - so whether the NDI half can ship at all is an open question for the vendor, not something the code can settle. 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 is an architecture, not a feature
Both boards refuse the same shortcut. Switching inside a video pipeline means the change happens between frames, in fabric, with no mode set and therefore no black frame to hide — as opposed to reconfiguring an output and covering the gap. The decoder makes the same choice at the other end of the cost 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.
That is also why failover is defined on picture rather than on handshake. A source is promoted when it delivers a frame, never when it merely connects, because a connection carrying nothing is a failure that looks exactly like a success.
Where the open questions are
For the mainframe, everything: it exists as design and RTL in simulation, 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, while the free NDI SDK licence appears to exclude fixed-purpose Linux appliances, which is precisely what the product is.
That second one is not a problem code can settle, so it is stated as a question for the vendor rather than dressed up as a roadmap item. The SRT half is unaffected either way.
Related, elsewhere on the site
The whole bench
This is one discipline of several
The hardware index carries every board at once, filterable by discipline — lighting nodes, audio boxes, video processing, the physical layer under all of it, and the RF work above it.