Architecture
A controller that decides, nodes that execute.
The controller carries no pictures. It holds the inventory, prepares the hosts, places the containers and watches. Real-time work lives on the nodes, as close to the network card as it can get.
Overview
Three network planes, one shared clock, one bus per node.
Controller
A central web application with no production container on board.
| Role | Control plane only: inventory, deployment, wiring, monitoring, broadcast protocols. |
|---|---|
| Stack | Python 3.13, Flask, SQLite, a fixed-period monitoring thread. |
| Interface | A single web application, translated into French and English and open to further languages, three themes, per-user permissions. |
| Extension | Container types and integrations are separate modules, versioned independently. |
| Security | No site-specific value in versioned code, a token per node, a token per container injected at start-up, an audit trail of actions. |
Nodes
Enrolled Debian servers, driven by their agent.
| Agent | A local HTTP service with its own token, responsible for the Docker lifecycle and host operations. |
|---|---|
| Preparation | Hugepages, network-card profile, queues, binding ports to the DPDK driver, core isolation: all of it is laid down by the controller. |
| Capabilities | A node declares what it can do: 2110 engine, compute, media, GPU. Placement takes that into account. |
| Autonomy | If the controller goes away, the agent watches over the deployed scripts and restarts them. |
| Installation | Dedicated installer, UEFI HTTP network boot or USB media, remote hands via the management controller. |
| Container network | A macvlan segment, one address per container, gateway derived from the node’s default route. |
Memory bus and replication
Inside a node, essences do not go back onto the network.
Video, audio and ancillary flows live in shared memory, in a domain common to every container on the node. A producer writes its grains; consumers read them with no network copy and no intermediate encode. A consumer that loses its producer reattaches on its own when the producer comes back.
| Origin | The bus is the Media eXchange Layer, the exchange layer called for by the EBU Dynamic Media Facility Reference Architecture. Bobi.Studio builds on its SDK, published under Apache 2.0, rather than inventing a proprietary transport. |
|---|---|
| Domain | Node-local shared memory, with grain indexing derived from time. |
| Essences | Planar video, multichannel audio, ancillary data. |
| Interoperability | The bus is an open format: other implementations read and write the same flows. |
| Inter-node | RDMA replication, multi-port distribution, link reconciliation. |
The three network planes
Separate because they share neither their constraints nor their failure modes.
| ST 2110 media | Dedicated card, kernel-bypass driver, multicast, PTP. No management traffic crosses it. |
|---|---|
| Containers | A macvlan segment, one address per container, reachable directly by the controller. |
| Control | The node’s fixed address, set at install time, carrying the agent and administration. |
Multicast is allocated centrally, one group per flow, with atomic reservation: a group belongs to a single flow, and IGMP membership is applied on the interface carrying it.
Only the media plane is specific to ST 2110. An installation that comes in and goes out over SRT or RTMP uses just the container segment and the control plane: no dedicated card, no PTP, no multicast.
Clock
Without a shared clock there is no chain, only flows.
Every node disciplines its clock to the site grandmaster over PTP. The controller samples the offset, keeps the history and alerts on a loss of lock. Session descriptions carry the clock reference of the chain.
| Protocol | IEEE 1588 with the SMPTE ST 2059 broadcast profile. |
|---|---|
| Per node | Synchronisation daemons driven by the controller, with state and offset reported continuously. |
| 2110 engine | On kernel-bypass nodes, the card’s clock is held by the engine itself. |
| Tracking | Offset history, lock-loss episodes, contextualised alerting. |
Resources
We measure. We do not guess.
Every container type carries a consumption profile, established under real production load. The allocator reserves cores inside the node’s isolated band with memory topology in mind, then a second mechanism checks the placement actually obtained: band respected, affinity applied, threads distributed. What the calculation predicts and what the machine does are two different things, and both are shown.
Node memory bandwidth is measured separately. On servers where it is the limiting factor, it explains ceilings that the core count alone cannot.
High availability
The standby says it is alone. It does not promote itself.
Two controllers can run as a pair, the active one replicating its state to the standby. The standby polls the active continuously; after a delay with no answer, an indicator visible on every page leads straight to promotion.
Handing over control stays a human act, deliberately: with no third witness, a controller cut off from the network cannot tell “the other one is dead” from “I am isolated”, and promoting itself in doubt would put two pilots on one production. The management address, on the other hand, moves on its own.
Hardware requirements
What to plan for before buying.
| Controller | A Debian 13 machine with Python 3.13, physical or virtual. No real-time constraint. |
|---|---|
| Compute node | Debian 13 with Docker. Isolated cores and memory bandwidth matter more than raw clock speed. |
| 2110 node | An Intel E810 network card for the media plane, hugepages, isolated cores, PTP access. Required only for nodes carrying 2110 ports. |
| GPU | An optional NVIDIA card. It offloads the CPU: NVENC hardware encoding for outputs and monitoring, accelerated composition. One node therefore sustains more containers. |
| RDMA | RoCE-capable cards for bus replication between nodes. |
| Network | A media plane carrying multicast and PTP, a segment for containers, a control plane. |
The infrastructure guide in the repository details CPU, memory, network card and redundancy choices, along with the points that make an installation fail.
Read the detail at the source.
The infrastructure guide, the install guide, the node-agent contract and the high-availability documentation are all versioned with the code.