For twenty years, the video wall was the one part of the NOC you could not run yourself: a proprietary controller appliance, input cards, output cards, a support contract, and often a vendor engineer for every significant change.
That era is quietly ending.
A modern NOC video wall can run on a commodity Linux server with a capable GPU. The wall becomes an IT workload, with everything that implies for architecture, monitoring, redundancy, and lifecycle management.
Disclosure: I work on Craft Wall, one of the software platforms in this space. This article focuses on the architecture and the cost model, not a sales pitch. The underlying dataset is published under CC BY 4.0, so you can rerun the calculations with your own numbers.
What the system actually has to do
Marketing photos usually show operators looking at a glowing wall. The real engineering requirements are more specific:
- 16–30 live sources rendered simultaneously, 24/7, for years
- Multi-operator control, so one operator can rearrange part of the canvas while another controls a different region
- Browser-based operation with no client software installed on operator workstations
- Failure containment, so one broken dashboard or camera feed cannot take the entire wall down
A real NOC wall must keep Grafana, Splunk, SolarWinds, camera feeds, ticket queues, and IP-KVM sessions running together on one canvas.
If it cannot do that, it is closer to a digital-signage player than a NOC video wall.
What actually goes on the wall
A mid-size telecom or data-center NOC usually converges on five source layers:
| Layer | Typical count | Examples |
|---|---|---|
| Network-health dashboards | 4–8 | PRTG, SolarWinds, Zabbix |
| Metrics and alerting panels | 2–4 | Grafana, Prometheus |
| SIEM and security panels | 2–4 | Splunk, QRadar |
| Tickets and escalation | 1–2 | ServiceNow, Jira, on-call board |
| Visual context | 4–8 | CCTV, rack cameras, RTSP streams, site systems |
This leads to two important architectural consequences.
The browser is a first-class source
Most NOC content is delivered through web dashboards.
The wall software therefore needs actual browser rendering with:
- service-account authentication
- automatic refresh control
- session persistence
- defined behavior for stale or unavailable data
- independent recovery for each browser source
A screenshot slideshow is not enough.
Multiple transport types are unavoidable
A typical NOC wall may need to handle:
- browser dashboards
- RTSP camera streams
- NDI sources
- HDMI capture
- IP-KVM sessions
- RDP or jump-host consoles
- local applications
RTSP and NDI decoding must be handled efficiently, ideally on the GPU and across many simultaneous streams.
If every transport requires a separate paid module, the bill of materials grows quickly.
Three ways to build a NOC video wall
1. Hardware controller
This is the traditional Datapath, Barco, or RGB Spectrum approach.
It is deterministic and familiar, but it usually comes with:
- high initial hardware cost
- source limits defined by card slots
- proprietary expansion cards
- vendor-dependent maintenance
- forced replacement when the appliance reaches end of life
2. Cloud-managed AV-over-IP
This approach often has a relatively low entry price and is licensed per display.
The trade-off is that the wall may depend on:
- a reliable external network path
- a remote control plane
- recurring subscription payments
- licensing that scales directly with the number of displays
The annual fee continues for as long as the wall remains in service.
3. Software on commodity Linux and GPU hardware
This is the category Craft Wall belongs to, alongside other software-based video wall platforms such as Hiperwall and VuWall.
The usual model is:
- standard server hardware
- commodity GPUs
- perpetual software licensing
- no per-display subscription
- support for on-premises and air-gapped deployments
The trade-off is straightforward: it becomes your server to operate.
For a NOC or DevOps team, that is often an advantage rather than a problem.
What changes when the wall becomes a Linux workload
Moving the video wall onto commodity Linux hardware changes the operating model.
The wall can now be managed with the same practices used for other production infrastructure:
- services supervised and restarted automatically
- system and application logs collected centrally
- CPU, RAM, GPU, temperature, storage, and network utilization monitored
- configuration backed up and versioned
- health checks connected to the existing monitoring stack
- updates tested on the standby node before reaching production
- hardware replaced without waiting for a proprietary appliance lifecycle
The monitoring baseline should include:
- CPU and memory utilization
- GPU utilization and VRAM consumption
- GPU temperature and throttling state
- dropped frames and decoder errors
- source reconnect attempts
- network throughput and packet loss
- application process health
- storage capacity and log growth
- primary and standby synchronization status
This does not make the wall maintenance-free. It makes the maintenance visible, automatable, and understandable to the team already operating the NOC.
Failure modes matter more than the demo
A NOC video wall is a 24/7 production system. It should be designed around at least four failure classes.
A source process fails
Each source should run independently and restart automatically.
The blast radius must be limited to one cell or one source, not the entire wall.
A source remains unavailable
The affected cell should fall back to defined content or geometry instead of becoming a permanent black rectangle.
Operators must be able to distinguish between:
- an unavailable source
- stale data
- an authentication failure
- an intentionally disabled source
The server fails
A hot-standby server should maintain a synchronized copy of scenes, layouts, and source configuration.
If the primary server fails, the standby should take over within seconds without requiring operator action.
The system becomes saturated
Incident conditions often create the highest load at exactly the worst time.
If GPU, CPU, or network capacity becomes saturated, the platform should support priority-based degradation:
- critical sources retain full resolution and quality
- secondary sources reduce bitrate, frame rate, or resolution
- essential incident information remains visible
If a vendor cannot explain exactly what happens in each of these four situations, that is already a useful answer.
A rough 16-display bill of materials
A typical software-defined deployment might include:
- 16 professional displays
- one commodity Linux server
- one RTX-class GPU
- approximately 0.45 kW server power draw
- one 10GbE network interface
- an optional second identical server for hot standby
- browser-based operator workstations
The controller software should not care which display manufacturer you use.
Operator workstations should require no dedicated client installation and no per-seat license.
The five-year cost
The full model includes five cost categories, an 8% NPV calculation, and sensitivity analysis.
The dataset is published under CC BY 4.0:
Five-year video wall TCO dataset: DOI 10.5281/zenodo.20650637
Here is the baseline example for a 16-display, 24-source video wall:
| Architecture | Acquisition cost | Five-year TCO |
|---|---|---|
| Perpetual software on a commodity server | ~$8,700 | ~$13,000 |
| Hardware controller with chassis and cards | ~$20,000 | ~$34,600 |
| Per-display subscription at $500/display/year | ~$6,000 | ~$40,300 |
The dominant variable is the number of displays multiplied by the annual per-display fee.
At 32 displays, the subscription component roughly doubles. The perpetual-software path changes much less because the license is not directly tied to every physical display.
These baseline figures compare the controller paths and exclude the display panels themselves. A higher-availability deployment with a hot-standby server, additional KVM endpoints, and extended support will have a higher total, which is why the full reference architecture may show a different worked BOM.
Cost is not the only consideration. Frame-accurate broadcast switching, mandatory redundancy architectures, or classified air-gapped environments can legitimately change the ranking.
But if none of those requirements applies, a low initial price should not determine a five-year infrastructure decision.
You can test the numbers using the public video wall TCO calculator.
The short evaluation checklist
- Define the deployment model: cloud, on-premises, or air-gapped.
- Count sources by type: dashboards, SIEM, tickets, cameras, KVM, and remote desktops.
- Require browser-based multi-operator control with authentication and audit logging.
- Ask what happens during each of the four failure scenarios.
- Monitor the wall as production Linux infrastructure.
- Calculate the full five-year cost using your own display count, subscription quote, electricity price, and support costs.
The complete architecture, worked bill of materials, failover model, and integration notes are available here:
NOC Video Wall Reference Architecture
Editorial note: The technical argument and cost model were written and fact-checked by the author. AI assistance was used for English-language editing and Markdown formatting.
Top comments (0)