Video wall for broadcast monitoring: MCR, PCR

Two walls in one room: signal QC vs operational monitoring

Every broadcast facility above a certain scale ends up with two distinct monitoring tiers, even if both tiers physically share the same wall surface. The split is not cosmetic — it drives every downstream decision about hardware, software, and procurement.

Primary monitoring sits on the signal path. It answers: is this stream broadcast-correct? Lipsync within tolerance, loudness compliant with ITU-R BS.1770 or ATSC A/85, PSI/SI tables present, no freeze, no black, PSNR not drifting, NMOS IS-05 connections in the right state. Primary monitoring measures in real time at sub-frame latency and feeds compliance evidence that legal, regulatory, and customer SLAs depend on.

Secondary monitoring sits one step removed from the signal path. It answers: what is the operations team seeing and reacting to? Encoder confidence outputs, transmission queue depth, CDN edge stats, programme/preview rotations, social channels, off-air confidence monitors, contributor and guest feeds, ad-insertion dashboards. Secondary monitoring tolerates more latency, demands more source variety, and changes more often than primary.

Procurement that conflates the two ends up either over-spending on a probe-grade wall for operational content or under-spending on a flexible wall for compliance-critical signal QC. The first step in any tender is naming which tier the wall is for, or — more often — drawing the line that splits the wall surface between the two.

What goes on a broadcast monitoring wall

Typical source mix for a mid-tier MCR wall driving 16-24 displays:

• On-air programme outputs (4-8 feeds). Often via a hardware multiviewer output rather than directly — the multiviewer composites with overlays (lipsync indicators, loudness bars, ID strap) which the wall renders as one composite per channel.
• Encoder confidence outputs (4-8 feeds). HEVC/AVC encoder web UIs or RTSP confidence streams from the transmission encoders. Operators need to see the encoded result, not just the source.
• Transmission status dashboards (2-4 web sources). Grafana, Prometheus, NMS panels showing transport bandwidth, multicast joins, satellite link state, redundancy posture.
• CDN edge stats (1-2 web sources). Akamai, Cloudflare, Fastly portals — QoE metrics, error rates by region, cache hit ratios.
• Social and audience monitoring (1-2 web sources). X/Twitter brand mentions, Hootsuite, audience tools — the comms team usually owns these but the MCR sees them too during live events.
• Probe / compliance output (1-2 feeds). Telestream Sentry (formerly Tektronix), Bridge VB440, or Telestream PRISM web UIs showing compliance alerts by channel.
• Off-air confidence (2-4 feeds). Receivers tuned to the actual on-air transmission (terrestrial, satellite, OTT) so operators see what viewers see, not what the playout server thinks it sent.

The pattern that breaks naive video-wall sizing: most of those sources are web UIs and dashboards, not video. A wall spec'd assuming "16 channels of video in" misses that much of the surface is rendered web content, which has very different bandwidth, latency, and compositor requirements.

The hardware-multiviewer legacy

Broadcast monitoring went hardware-first for sound reasons. The hardware multiviewer category — Evertz VIP-X, Tag Video Systems, Cobalt Digital, Lawo V_matrix, Grass Valley Kaleido, Bridge Technologies, Telestream — solved problems that mattered:

• Deterministic sub-frame latency. FPGA-based composition with guaranteed timing. Software renderers on general-purpose CPU / GPU can hit similar latency in good conditions but cannot guarantee it under load.
• Native SDI / ST 2110 input. Direct ingest of SDI baseband and ST 2110-20/-30/-40 flows without an intermediate gateway. Critical for primary signal-correct monitoring.
• Built-in probe functions. Lipsync detection, loudness integration, freeze/black detection, PSI/SI parsing, EAS state, A/85 or R128 loudness compliance — built into the multiviewer firmware, not bolted on separately.
• Certification track record. Vendors with 15-25 year deployment history in Tier 1 broadcasters, with field-tested behaviour in incident conditions. Procurement teams will not gamble compliance evidence on a new entrant.

None of these go away in 2026. What is changing is the share of the wall they occupy.

Evertz multiviewer alternative and Imagine multiviewer alternative

Buyers searching for an Evertz multiviewer alternative or an Imagine multiviewer alternative are usually describing one of two different projects. The first is a primary broadcast signal-QC replacement: SDI or ST 2110 ingest, deterministic composition, loudness and lip-sync measurement, freeze/black detection, and compliance evidence. That is still a hardware multiviewer or probe decision.

The second project is a secondary MCR or PCR operations wall around the multiviewer: encoder web UIs, CDN telemetry, transmission queues, off-air confidence feeds, monitoring dashboards, social/audience tools, and incident panels. For that workload, a software wall is a legitimate alternative to expanding the legacy multiviewer estate, because most sources are browser, RTSP, NDI, HDMI capture, or IP-KVM rather than native baseband signal inputs.

• Keep Evertz / Imagine hardware where signal correctness is the deliverable. On-air QC, legal loudness, ST 2110 plant monitoring, and SLA evidence belong in the primary chain.
• Use software where operational context is the deliverable. Dashboards, web tools, off-air confidence, post-QC views, and incident status benefit more from flexible layouts and lower TCO than from another fixed multiviewer card.
• Bridge the two tiers deliberately. Render the upstream multiviewer or probe output as one approved confidence source on the software wall, then surround it with the operational views the broadcast team needs.

Software-defined broadcast monitoring in 2026

Three structural changes shifted the balance over the last three years:

• Source mix moved off SDI. Encoder confidence, transmission dashboards, CDN portals, social monitoring — none of these are SDI sources. They are web UIs, RTSP streams, REST APIs rendered as dashboards. Hardware multiviewers that excel at SDI add little value here.
• NMOS reached production. NMOS IS-04 discovery and IS-05 connection management became the default management overlay for ST 2110 plant. Software walls that speak NMOS can take their place on an NMOS bus alongside the rest of the plant.
• First IPMX-certified products at ISE 2026. See the IPMX vs ST 2110 vs SDVoE article for the standards detail. The practical broadcast consequence: ST-2110-family transport now runs on 1 GbE plant with JPEG XS compression, and the boundary between broadcast plant and ProAV control room starts to blur. Monitoring walls that can ingest IPMX cover both worlds.

The result is a two-tier wall as the emerging default: a hardware multiviewer section for primary signal-correct monitoring, and a software-defined section for everything else, both physically on the same wall surface with the operator not caring which tier rendered which tile.

What to spec for each tier

Tender language that consistently produces the right outcome:

For the primary QC tier: require ST 2110-20/-30/-40 native input, NMOS IS-04 + IS-05 conformance, lipsync detection conformant to ITU-R BT.1359, loudness measurement to ITU-R BS.1770 (with ATSC A/85 or EBU R128 as the downstream profile depending on territory), freeze and black detection thresholds with sub-frame response time, and EAS state monitoring where applicable. Specify hardware multiviewer or a software stack with explicit FPGA offload — and ask for deployment references in matching tier and territory.

For the secondary operations tier: require flexible source mixing across at least NDI, NDI HX, RTSP, HDMI capture, and browser-rendered web sources. Specify operator control surface (browser-based is the modern default; tablet or touchscreen control as a delta), layout persistence across operator shifts, role-based access with audit log, and a REST or WebSocket API for automated layout switching driven by playout automation or incident response.

For both tiers: air-gap capability if the facility carries critical-infrastructure or government content, IPMX-readiness on a stated roadmap timeline, and a published TCO across at least five years including software refresh, hardware replacement, and support escalation tiers.

Where Craft Wall fits in a broadcast facility

Honest scope: Craft Wall sits in the secondary operational tier of a broadcast facility, not the primary signal-QC tier. It is appropriate for:

• MCR operations walls. Encoder dashboards, transmission queue state, CDN telemetry, off-air confidence rotation, incident-response panels, social and audience monitoring during live events.
• Transmission room walls. Satellite link state, redundancy posture, multicast and PIM tables, transport NMS panels.
• Studio support walls. Talent feeds, autocue mirrors, social feeds for hosts, off-studio references for floor managers.
• Outside broadcast (OB) vehicle support walls. Secondary monitoring from a standard Linux server with an NVIDIA GPU installed in the OB van, adjacent to the primary FPGA-multiviewer rack.
• Post and edit suite walls. Reference monitors, render farm telemetry, asset management dashboards.

Not appropriate, as of 2026: primary on-air signal-correct monitoring of ST 2110 plant requiring sub-frame lipsync and loudness measurement. For that tier, an Evertz VIP, Tag Video Systems, Telestream Sentry, Cobalt Digital, or Telestream PRISM stack remains the right tool, and Craft Wall sits one tier downstream rendering the probe outputs and dashboards on the operational wall.

Procurement decision tree

Three questions resolve most broadcast monitoring wall decisions:

• Does this wall carry compliance evidence? Yes → hardware multiviewer for the compliance tier, software wall for the rest. No → software wall covers it.
• Is the source mix mostly SDI / ST 2110 or mostly IP / web? Mostly SDI / ST 2110 → hardware multiviewer leads, software wall as adjunct. Mostly IP / web → software wall leads, hardware multiviewer optional for any compliance pockets.
• What is the 5-year TCO horizon? Hardware multiviewers refresh on a 7-10 year cycle with substantial CAPEX per chassis. Software walls refresh on commodity server hardware cycles with a perpetual or per-display software licence. See TCO breakdown for the comparable maths in a control-room context — the same structure applies to broadcast secondary walls.

Read next

For the standards backbone that drives all of this, see IPMX vs SMPTE ST 2110 vs SDVoE. For the operational-walls cousin in a different vertical, the NOC reference architecture documents source mix and failover for a telco NOC at similar scale — much of the secondary-tier engineering carries over. For the hybrid-cloud question many broadcasters are asking — where does plant end and cloud begin — the hybrid cloud video wall architecture article splits the responsibilities. For security and audit language in regulated broadcast or public-sector facilities, add the video wall compliance guide to the procurement pack.