Jeket is a software-defined dynamic media facility. Media functions run on MXL, not on hardware, so the same platform that takes SRT off your laptop today runs ST 2110 across a multi-node cluster when you need it. Built on the principles the largest broadcasters already use. You never re-platform.
The whole point
Most platforms make you choose a tier and then re-platform when you outgrow it. Jeket has one architecture: IP at the edge, MXL at the core. Everything below is a hardware decision you make when the work demands it, not a product decision you make on day one.
| Stage | Ingest | Core | Network | Clock |
|---|---|---|---|---|
| Day oneOne box | SRT, RTMP, RTSP | MXL shared memory | Any managed switch | Not required |
| Scale upBroadcast signal | + ST 2110, via IP gateways or native cameras | unchanged | + 2110-capable switching | + PTP grandmaster |
| Scale outMore capacity | unchanged | MXL Fabrics over RDMA | + RoCEv2 | unchanged |
| ArrivedFull facility | Full ST 2110 plant | MXL across the cluster | Facility IP fabric | Facility PTP |
There is no column for the software, because the software never changes.
Same code, same graph, same media functions, from the first box to the last rack.
Two independent axes
Signal quality and capacity are separate decisions. Nothing forces you to take them together, and nothing about taking one later costs you anything now.
Not ready for 2110? Use SRT, RTMP or RTSP. It is the same pipeline, the same processing and the same output. Nothing is crippled and nothing is a trial.
When you do want uncompressed broadcast video, with raw camera capture, real ancillary data and proper timing, ST 2110 is already built in. Put IP gateways at the edge, or buy cameras that speak it natively.
You add: a PTP grandmaster and 2110-capable switching. That is the whole upgrade.One box is a complete facility. Functions exchange media through shared memory, so a single node needs no fabric, no RDMA and no special network at all.
Need more than one box can carry? MXL Fabrics moves the same media between nodes over RDMA. The graph does not change, the functions do not change, and you do not re-architect anything.
You add: switching that supports RoCEv2. The software already knows how.Live at NAB 2026 with Cloudflare.
Browser webcam ingest, composited against an ST 2110 program feed, delivered end-to-end in sub-second glass-to-glass.
What it does
Six operator functions, running continuously on every source in the chain, with nobody at a panel.
Station bugs, lower thirds, tickers, full-frame graphics. Keyed onto the live program by a downstream keyer that runs as software, not as a box in the rack.
SCTE-driven break insertion and return, frame-accurate. Ad markers carried through the chain so downstream delivery knows where the opportunities are.
Every source watched continuously: what is in frame, what changed, and whether the picture is still there. Faults surface as events, not as a phone call from a viewer.
Loudness measured against target, silence and over-level detected, speakers identified. The checks a good audio operator makes constantly, made constantly.
Live captions with word-level timing, carried as timed text through the pipeline and out to every egress that can take them.
Sub-second live over Media over QUIC, with parallel CMAF egress on HLS and DASH for every device that does not speak MoQ yet. One pipeline, every viewer.
One graph
Every signal chain is a Kubernetes Custom Resource. Design it in the editor, deploy it with kubectl, watch it run. The same graph describes development, staging and air.
Design, deploy, monitor. The whole broadcast signal chain, in one declarative graph.
The architecture
This is why the ladder works. A keyer is not a box, a mixer is not a card, and an encoder is not an appliance. They are functions on a shared data plane. Adding one costs compute. Moving one costs nothing. Outgrowing one is not a thing that happens.
Built on the Linux Foundation dmf-mxl SDK. Functions on a host exchange media through shared memory: zero-copy, zero-serialisation, sub-frame latency inside the pipeline.
The same exchange over RDMA once a chain spans boxes. No network video protocol in the middle of your own pipeline.
ST 2110 for uncompressed video, audio and ancillary data. SRT, RTMP and RTSP when you would rather not. Both, when that is what the room looks like.
IS-04 discovery, IS-05 connection management, IS-12 device control. The sources panel populates itself.
Media over QUIC for sub-second live, CMAF over HLS and DASH in parallel for everything else.
Zero-touch Kubernetes on bare metal on-prem, hybrid with cloud-extended distribution, or fully cloud-native. Same platform, same APIs.
Partners
Software does not remove the network. Moving up the ladder means switching that handles ST 2110 and RoCEv2, and a grandmaster once you want proper timing. NETGEAR is a partner for exactly that part of the climb. So when you are ready for the next rung, the hardware answer already exists and somebody supports it.
Who it's for
The same software, running on however much hardware the work happens to need.
A rig that fits in a case, sets itself up from a file, and does the work of a crew you cannot yet afford. SRT or RTMP in, and 2110 waiting for the day you want it.
Multi-camera, multi-campus production that keeps working when the volunteer who knew the switcher moves away. One campus or twelve, same configuration.
Broadcast output from an AV budget and an AV team, on the network the building already runs. Add real timing later if the studio grows into it.
Athletics, esports and the broadcast programme on one platform, run by students. The venue that needs 2110 gets 2110; the one that does not, does not.
Full ST 2110 plant, MXL across the cluster, and a new channel that costs compute rather than capex. The top of the ladder, on the same software as the bottom.
One software line item you can quote alongside the switch, the gateways and the cameras, plus a platform that grows inside the account instead of being ripped out.