ST 2110 in the Cloud: Practical Bridge Patterns for Hybrid Broadcast Facilities

Tim Tselikovski -

ST 2110 changed the plant. Cloud changes the boundary.

SMPTE ST 2110 moved professional media away from SDI-style black boxes and toward separate video, audio, and ancillary essence flows over IP. That gives broadcasters more routing flexibility inside a facility.

Cloud workflows create a different question:

How do you connect a tightly timed on-prem ST 2110 environment to elastic cloud tools that do not share the same network, clock, or operational model?

The answer usually involves a bridge. Sometimes that bridge uses uncompressed IP. More often, it uses a gateway, compression, and clear timing rules.

Start with the facility reality

An ST 2110 plant depends on timing. PTP keeps devices aligned. Network design matters. Multicast matters. Operators expect deterministic behavior.

The public cloud does not behave like a broadcast spine. You cannot assume native multicast across every service. You cannot assume the same timing model. You cannot move raw uncompressed 1080p or UHD feeds casually between locations without serious bandwidth and cost planning.

That does not block cloud production. It means you need a boundary layer.

Pattern 1: ST 2110 on-prem, compressed contribution to cloud

This pattern fits many teams.

Keep ST 2110 inside the facility. Use a gateway at the edge to create compressed streams for cloud production, monitoring, recording, or processing.

Common transport options:

  • SRT for reliable contribution
  • RIST for standards-oriented contribution
  • JPEG XS for low-latency, visually lossless compression
  • H.264 or HEVC for lower-bandwidth monitoring
  • WebRTC for browser preview

Use this pattern when the cloud needs selected feeds, not the whole plant.

Example:

A broadcaster sends clean feed, program, and two iso feeds from an ST 2110 facility to a cloud clipping and remote monitoring system. The facility keeps native ST 2110 routing on-prem. The cloud receives compressed streams and sends WebRTC previews to producers.

That design keeps the plant stable and gives remote teams access.

Pattern 2: Cloud production with ST 2110 at the edge

Some productions put switching, graphics, replay, or monitoring in the cloud. Cameras still connect at the venue through SDI, NDI, or ST 2110 gear.

The edge device converts local sources to cloud-friendly contribution streams. The cloud handles the production layer. The output returns to distribution, master control, or the venue.

Use this pattern for:

  • Remote sports production
  • Pop-up channels
  • Regionalized live events
  • Remote producer workflows
  • Cloud replay or clipping

The hard parts: timing, audio sync, return feeds, and operator confidence. Solve those before you add features.

Pattern 3: ST 2110 island with cloud control

Not every cloud workflow moves media into the cloud. Sometimes the media stays on-prem, while control, automation, monitoring, logging, or orchestration runs remotely.

Use this pattern when:

  • The plant must keep full-quality local media
  • Network egress costs would hurt
  • Operators need remote access
  • Compliance or rights rules limit cloud media storage
  • Existing routers and devices already support the job

The cloud layer can still add value through scheduling, telemetry, alerting, asset metadata, and remote operation.

Timing does not forgive guesses

ST 2110 systems need a clock plan. Hybrid systems need a boundary plan.

Ask:

  • Where does PTP live?
  • Which devices need PTP?
  • Where do we convert to compressed transport?
  • How do we handle frame alignment after decode?
  • How do we verify lip sync?
  • What does the operator see when timing drifts?

Do not bury timing inside vendor slides. Put it in the architecture diagram.

JPEG XS deserves a look

JPEG XS fits hybrid broadcast because it offers low-latency compression at high visual quality. It can reduce bandwidth while keeping a production-friendly picture.

Use it when:

  • You need better quality than typical long-GOP contribution
  • Latency matters
  • Bandwidth costs still matter
  • The receiving side supports it
  • You want a cleaner bridge between professional IP media and cloud workflows

JPEG XS does not replace H.264, HEVC, SRT, WebRTC, or ST 2110. It gives engineers another bridge option when quality and delay both matter.

Monitoring must cross the boundary

Hybrid workflows need monitoring on both sides.

On-prem:

  • PTP status
  • Packet loss
  • Flow health
  • Multicast behavior
  • Device status
  • Audio alignment

Transport:

  • Bitrate
  • Latency
  • Jitter
  • Retransmissions
  • Decoder errors
  • Link failover

Cloud:

  • Ingest status
  • Processing delay
  • Stream health
  • Viewer preview health
  • Recording status
  • Alert routing

One green light does not prove the workflow works. Give operators a view across the whole path.

Where Medialooks fits

Medialooks Video SDK supports developers who need to bridge professional broadcast I/O and software workflows. Teams can build apps that ingest, process, play, record, and stream across SDI, NDI, SRT, WebRTC, files, and related media paths.

The ST 2110 Compatibility Pack gives teams a path to bring ST 2110 into custom software workflows without treating the standard as a separate universe.

Hybrid broadcast needs practical bridges. Keep the facility stable. Move the right feeds. Monitor the boundary.