BlackMatrix

An ATEM doesn't have one thing you could call a router, so this treats every bus that takes one source at a time as a destination: the aux outputs, program and preview on each ME, upstream and downstream keyer fill and key, every SuperSource box plus the art fill and key, and every multiviewer window. On a Mini Extreme ISO that's 29 sources by 39 destinations, across as many switchers as you point it at.

Which sources are allowed on which destination comes off the switcher itself, not from a per-model table. Every input reports an availability mask, and the app draws the illegal cells hatched and refuses them on the server. That's what stops an aux output being routed back onto an aux bus, or ME 1's own output onto ME 1, without anybody having to maintain a compatibility chart.

The second half is protocol emulation. Each switcher also gets a Videohub Ethernet Protocol v2.3 server, so a hardware router panel, Companion's Videohub surface or Blackmagic's own software can drive the crosspoints without ever finding out there's an ATEM on the other end.

An ATEM already serves that protocol itself on TCP 9990. Read back to back, the two agree on every destination they share. Blackmagic's own server offers five outputs: Output 1, Output 2, Webcam Out, Program and Preview. This offers the other thirty-four. If five is all you need, use the switcher's own.

Between the switchers and the router there are cables, and nothing on the network knows which. Wiring is where you write them down (router outputs into switcher inputs, switcher auxes back into the router), and once it knows, a cabled input says what it's actually carrying, however many boxes upstream the picture starts. Route through then routes end to end: a router input straight onto a switcher bus, or a switcher output through the router to a screen. It plans the crosspoints, tells you everything else they'd change, and sends them upstream first, stopping at the first refusal, so a switcher never gets cut to a cable that didn't get the picture.

The third half is redundancy. A failover watch polls a machine (a TCP port, a URL, or a heartbeat it has to be sent) and fires an ordinary salvo when it stops answering. That's the whole safety argument: the failover is the same button an operator can press by hand, so you can rehearse it before the show instead of discovering it during one. It won't fire until it's seen the machine working at least once, it starts disarmed, and it won't switch back unless you tell it what back means. For rigs where the media server drives the router itself (disguise's understudy sends matrix routing on failover, PIXERA fires a control action at a matrix switcher), the Videohub emulation is the target, and there's a plain-text line protocol on TCP and UDP for anything that can send a string but can't speak Videohub.

There's a browser simulator with a device library, a mock fleet of three switchers that are different on purpose for development, desktop builds that bring their own Node runtime, a container, and native iOS and Android shells that find the server for you, though neither of those has run on a physical device yet. A real Blackmagic Videohub can join the fleet as a device, not just as a client, so one grid covers both.