In short
A video wall sizing project should start with video wall source count, not with panel brand. Count the dashboards, cameras, KVM sessions, maps, incident boards, web applications, HDMI capture feeds, and standby layouts that operators need during a real event. Display count comes next: 8 displays, 16 displays, video wall 64 displays, and video wall 8K all mean different things once source mix, canvas resolution, and operator workflow are included.
Video wall sizing: start with sources, not panels
The common mistake is sizing the wall as "N panels with a controller". That works for signage, but it underspecifies a control room. A NOC, SOC, utility dispatch room, or command center is constrained by the number of live systems that must remain visible together, how often operators promote a source, and whether a failed source should degrade locally or disturb the whole canvas.
Start the sizing worksheet with source classes: browser dashboards, RTSP / NDI cameras, HDMI capture, IP-KVM, VNC / RDP, static media, GIS maps, SIEM panels, SCADA summaries, ticket queues, and fallback status pages. Then tag each source as always-live, incident-only, standby, or promoted. That simple split makes the hardware plan more reliable than a display count alone.
Video wall source count: live, standby, and promoted
Video wall source count is not just the number of cables plugged into a controller. In a software-defined wall, it is the number of logical sources the platform must authenticate, render, refresh, switch, log, and recover. A 16-display wall may have 14 sources visible in the quiet layout, 26 sources defined in presets, and 40 sources available to operators during an incident.
- Always-live sources: monitoring dashboards, alarm queues, camera mosaics, and common operating picture views that stay on the wall for the whole shift.
- Standby sources: backup cameras, drill layouts, briefing slides, status pages, or alternate dashboards that must be ready without rebuilding the room.
- Promoted sources: incident views, KVM sessions, packet captures, outage maps, or SIEM searches that become large for a short window and then leave the canvas.
For NOC rooms, the companion NOC video wall reference architecture maps this to Grafana, Splunk, SolarWinds, CCTV, and IP-KVM. For security rooms, use the SOC and SIEM video wall guide. For SCADA-heavy rooms, use the utility control room wall guide.
8 displays, 16 displays, and 64 displays
Display count changes the engineering problem, but not in a linear way. The jump from 8 to 16 displays is usually about operator readability and source density. The jump to video wall 64 displays is about governance: multiple zones, named presets, operator roles, source ownership, and refresh procedure.
| Wall size | Typical source planning question | Risk to check |
|---|---|---|
| 8 displays | Which 8-12 sources must stay readable from the operator row? | Overbuying controller hardware for a room that mostly renders web dashboards. |
| 16 displays | Which 20-30 defined sources must be grouped into shift, incident, and briefing presets? | Treating source promotion as an AV task instead of an operator workflow. |
| 64 displays | Which zones, roles, and ownership rules prevent one team from breaking another team's wall area? | Letting display count hide source, authentication, network, and GPU limits. |
For a cost view, model each display count in the video wall TCO calculator before locking the bill of materials. The same 16-panel room can price very differently as a hardware controller, per-display subscription, or local software-defined wall.
Video wall 8K: canvas resolution vs source resolution
A video wall 8K requirement should be written carefully. It may mean an 8K physical canvas, one 8K source, multiple 4K dashboards arranged across an 8K area, or an operator expectation that small text remains readable at distance. These are different technical requirements.
For control rooms, the practical question is usually canvas composition: how many browser dashboards, camera streams, maps, and KVM windows can the wall render while preserving text legibility? An 8K canvas does not require every source to be 8K. It does require clear rules for scaling, refresh rate, source priority, and where high-detail views are promoted during an incident.
Source transport and server implications
Source transport determines server shape. Browser dashboards stress CPU, memory, authentication, and browser lifecycle. RTSP and NDI camera feeds stress decode paths and network throughput. HDMI capture adds card count, slot planning, cable routes, and signal fallback. IP-KVM adds security and access control. AV-over-IP adds network design and multicast rules.
This is where software-defined architecture changes the sizing conversation. Instead of buying fixed-input appliances, the buyer sizes a Linux GPU server, capture cards where needed, network ports, storage for logs and presets, and the operational process for adding sources. If the room is restricted, pair this with the air-gap video wall guide.
Useful background definitions: AV-over-IP, IP-KVM, NDI, and dvLED.
Video wall requirements specification
A strong video wall requirements specification turns sizing into testable language. It should define display count, physical layout, canvas resolution, source count, source classes, live-source budget, standby-source budget, promoted-source behaviour, operator roles, audit logs, failover behaviour, supported transports, and the TCO horizon.
- "The wall shall support at least 24 defined sources, with 16 visible simultaneously and 8 standby sources available in named presets."
- "Operators shall be able to promote a source, restore a preset, and recover a failed dashboard from the browser UI without AV administrator access."
- "The system shall support browser dashboards, RTSP or NDI video, HDMI capture where required, and remote desktops (RDP / VNC) for approved operator workstations."
- "The supplier shall price the same room for 5 years, including licence, support, server hardware, capture hardware, commissioning, and refresh assumptions."
Video wall tender language
Good video wall tender language avoids locking the buyer into a controller family before the source plan is known. Specify outcomes: visible source count, operator workflow, supported transports, failover, auditability, and lifecycle cost. Only name a specific appliance class when sub-frame latency, baseband signal processing, or an existing standard requires it.
If the tender currently says "hardware controller with X inputs and Y outputs", ask whether the actual workload is browser dashboards, cameras, maps, and KVM. If it is, compare the hardware path with a software-defined option in the Datapath Fx4 alternative and the broader best video wall software shortlist.
Where Craft Wall fits
Craft Wall fits sizing projects where the display wall is mostly browser dashboards, IP video, HDMI capture, operator workstations promoted over RDP / VNC, local layouts, and predictable TCO. It is priced as a perpetual software licence for the wall server rather than as a per-display subscription, so the economics become clearer as display count and source count grow.
It is not the right layer for primary certified control actions, broadcast signal QC, or sub-frame baseband switching. In those cases, keep the primary chain on its certified system and use the wall as the shared visualization layer around it.
Read next
Use this sizing guide with the video wall TCO calculator, the NOC reference architecture, the research data center wall guide, the video wall RBAC, SSO, and API guide, the command center video wall guide, the stadium and sports venue control room guide, the boardroom AV video wall checklist, the software vs hardware TCO breakdown, and the Userful alternative before writing the final procurement spec.