Tier-1 broadcasters: hardware encoding vs cloud software
More live video workflow notes and product updates.
Broadcast architecture decision guide
Hardware encoding or cloud software? Design the boundary, not the slogan
Tier-1 broadcasters rarely need to choose “all hardware” or “all cloud.” A dependable design keeps deterministic signal acquisition and facility timing where they are required, then places routing, monitoring, recording, recovery, and distribution where teams can operate them effectively. The right split comes from failure domains, latency, I/O, capacity, security, and operational responsibility—not from a universal claim that one platform model is more modern.
The decision in one minute
Keep dedicated hardware at the edge when the job depends on physical SDI or ST 2110 interfaces, frame-accurate timing, deterministic appliance behavior, dense encode/decode capacity, or operation during loss of cloud connectivity. Use software and cloud infrastructure where rapid deployment, regional placement, elastic event capacity, browser operations, remote collaboration, or programmable routing create a real operating advantage.
Most serious live systems are hybrid: a known appliance or production system creates the contribution feed; resilient IP transport crosses the boundary; software receives, monitors, routes, records, or repackages the program. The architecture is successful when the team can prove and recover each boundary independently.
The two lanes represent separately engineered contribution paths. They do not promise hitless protection or measured latency. Motion is disabled when reduced motion is requested.
Compare architectures by operating consequence
| Decision | Dedicated hardware is strong when | Cloud/software is strong when | Evidence required |
|---|---|---|---|
| Signal boundary | Native SDI, ST 2110, genlock, PTP, or deterministic local I/O is mandatory. | The source already exists as a supported IP contribution feed. | Exact input/output, codec, raster, audio, timing, and conversion map. |
| Latency | The local processing budget is tightly bounded and measured. | Regional placement and transport recovery matter more than minimum device delay. | Glass-to-glass test across the production route, not a vendor component number. |
| Capacity | Channel count and formats are stable enough to justify reserved appliances. | Events, regions, or channel counts vary and infrastructure can be provisioned safely. | Worst-case channel, codec, bitrate, CPU/GPU, storage, and network test. |
| Failure recovery | Local operation must continue through WAN or cloud loss. | A second region or software node can reduce a meaningful failure domain. | Power, network, DNS, identity, state, storage, and operator recovery drills. |
| Change control | Long validation cycles and fixed-purpose operation are acceptable. | New routes, events, and integrations must be created repeatedly. | Version pinning, rollback, configuration backup, and acceptance criteria. |
| Economics | High sustained utilization makes owned capacity predictable. | Short-lived or regional demand avoids permanently idle equipment. | Three-year TCO including people, support, egress, facilities, spares, and refresh. |
Three architectures worth testing
Hardware contribution, software control
A broadcast encoder creates an SRT feed at the venue. Callaba receives it on AWS or self-hosted infrastructure, shows it in Multiview, and attaches routing or recording. This keeps physical I/O in an appliance while giving distributed operators a browser control surface.
Facility gateway, regional cloud operation
A controlled gateway converts or routes the required plant output into an approved contribution format. Software runs near remote operators or delivery services. The gateway is an explicit boundary; it is not hidden behind a claim that the cloud “supports” every plant protocol.
Self-hosted software inside the production network
Callaba runs on Linux infrastructure selected by the broadcaster. This can keep media, storage, and network control inside a private environment while retaining the same product model. The operator remains responsible for capacity, firewalling, upgrades, and host recovery.
Cloud proof before permanent architecture
A limited event or rehearsal validates ingest, operator access, routing, recording, and recovery before capital or migration decisions. A successful proof answers a defined question; it is not permission to skip security, load, or failover testing.
Build a latency budget that names every stage
“Low latency” is not a test plan. Measure acquisition, encode, transport buffer, network path, receive, decode, processing, packaging, player buffer, and display. If the path includes an ST 2110-to-SRT gateway, measure that conversion. If viewers use HLS, the player and packaging budget can dominate even when contribution is fast. If the operator uses Multiview, measure its monitoring delay separately from the audience path.
Use the real event geography and expected congestion. A laboratory result inside one data center does not predict a contribution from a remote venue. Record median behavior, outliers, recovery time, and the operational effect of packet loss. The chosen SRT latency is a recovery trade-off, not a quality score.
Turn reliability into testable failure domains
A second encoder does not protect a shared camera or switcher. A second cloud instance does not protect a shared DNS or identity dependency. Two network circuits entering the same building duct are not independent. Draw power, clock, source, encoder, switch, ISP, region, storage, control, and operator access on one page. Then decide which failures the service must survive and which require a controlled outage.
For Callaba, test the boundaries the product can operate: incoming contribution visibility, source identity, Multiview proof, manual or configured failover behavior, recording finalization, routing, browser access, and recovery after node or network interruption. The live video failover product page describes the available primary/alternate workflow; it does not remove the need to prove the surrounding infrastructure.
A useful broadcast bake-off
- Freeze one source package: codec, raster, frame rate, audio layout, bitrate, identifiers, and expected outputs.
- Run hardware and software paths from the same production source where possible. Avoid comparing different cameras, encoders, networks, and delivery players as if only the platform changed.
- Measure end-to-end delay, picture continuity, audio, reconnect behavior, operator actions, and the time required to create a new destination.
- Interrupt one dependency at a time: source, encoder, circuit, listener, compute node, storage, and operator session. Record detection and recovery time.
- Load the system to the approved maximum with realistic codecs and outputs. Include recording and monitoring, not only ingest.
- Repeat after restart and rollback. A configuration that survives only while the original engineer’s browser remains open is not production-ready.
Troubleshooting architectural symptoms
The cloud path works in rehearsal but fails at the venue
Compare the real egress policy, DNS, MTU, route, sustained bandwidth, and congestion with the lab. Do not start by changing codecs if the contribution endpoint is unreachable.
The appliance is stable, but remote operators cannot act
Separate media health from the control surface. Test browser access, identity, permissions, state synchronization, and the action required to switch or record.
A backup path carries the same failure
Find the shared dependency: source, power, switch, carrier, gateway, DNS, region, or policy. Rename the design “alternate route” until independence is demonstrated.
Costs rise after moving to cloud
Break out idle compute, oversized instances, storage retention, transfer, logging, and manual operations. Compare like-for-like availability and support rather than raw server price.
ST 2110 media cannot be attached directly
Return to the defined gateway boundary. Verify the required receiver, sender, NMOS behavior, PTP domain, multicast policy, and the contribution format Callaba will actually receive.
Monitoring is green while viewers see a fault
Identify which boundary was monitored. Transport state, decoded Multiview, recording, packaging, CDN, and player are different proofs and need separate acceptance checks.
Questions for an RFP or architecture review
- Which exact signal formats and interfaces enter and leave each boundary?
- What survives WAN loss, node loss, region loss, control loss, and storage loss?
- Who can create, start, stop, route, record, and share a feed?
- Which actions are manual, automatic, or API-driven, and how are they audited?
- What evidence proves source, transport, decoded media, recording, and audience delivery?
- Can the broadcaster run the same operating model in cloud and on infrastructure it controls?
- What is the rollback when a firmware, application, or configuration change fails?
For deployment choices, compare the Callaba cloud and self-hosted operating models and the Linux installation path. API automation belongs after the visual workflow and recovery procedure are accepted.
Primary standards references
Use the current publications from SMPTE for ST 2110 and the AMWA NMOS specification library for plant-level requirements. Vendor and cloud documentation can describe individual components, but the broadcaster’s tested system design remains the source of truth for interoperability and recovery.
Prove one hybrid production boundary
Start with a known contribution feed, place Callaba where the operating team needs it, and test monitoring, recovery, routing, and recording against explicit acceptance criteria.
Build a Callaba cloud proof