How Callaba Supported a Champions League Broadcast Workflow
More live video workflow notes and product updates.
I’m Iurii Pakholkov, software engineer and founder of Callaba. I built Callaba to give broadcast and AV teams one place to receive, inspect, route, process, record, and deliver live video without locking the workflow to one deployment model. In 2025, Callaba was used in the video path supporting a UEFA Champions League broadcast. The milestone mattered because it tested the same product principles behind Callaba in a demanding live-production setting: make the signal visible, keep the routing understandable, and leave operators in control.
This is a founder account and a product case study. It does not claim that Callaba produced the entire broadcast, replace every component in the production chain, or disclose a customer’s private topology. The linked recording is the public evidence for the event; the workflow below explains the verified Callaba product layers that broadcast teams can evaluate for their own systems.
What the 2025 milestone actually demonstrates
A high-profile event does not become simple because the audience is large. Operators still need to answer practical questions: Is media arriving? Is the bitrate stable? Which source is active? Where is the feed going? What happens when the primary path drops? Callaba is designed around those operational decisions.
The public evidence is a recording connected to the Champions League workflow. It supports the event account; it is not an independent performance audit. No unpublished customer name, private configuration, latency figure, uptime percentage, or cost comparison is introduced here.
The product layers behind a controlled live workflow
1. Receive contribution feeds
Callaba SRT Server receives reliable contribution feeds and exposes connection and transport health to operators. Callaba RTMP Server covers RTMP and RTMPS ingest, access control, guest publishing, and real-time connection visibility. Teams can use either protocol layer without making the API the first thing an operator has to understand.
2. See the workflow before viewers see a problem
Callaba Multiview brings several live inputs into one browser-based operator surface. A team can inspect feeds and use the same interface for manual switching. Where a production needs a prepared recovery path, Callaba Live Video Failover supports automatic and manual source switching within the documented product boundary.
3. Route, process, and deliver the selected signal
Multistreaming sends one reviewed input to several destinations. Live Video Transcoding prepares the codecs, resolutions, or bitrate variants required downstream. Recording, browser playback, and storage can be attached as separate product modules instead of being hidden inside one opaque pipeline.
4. Choose the deployment boundary
The same product story can start in the cloud or on Linux infrastructure controlled by the team. Cloud launch is useful for a fast proof of workflow; self-hosted Callaba is the path for teams that need direct infrastructure, network, and data-placement control. The correct choice depends on the production, security, support, and capacity requirements — not on a universal claim that one model is always better.
Why I built Callaba this way
My original frustration was not with one protocol. It was with the amount of operational context lost between separate tools. A contribution receiver knew about the incoming transport. A transcoder knew about the media job. A player knew about delivery. The operator still had to reconstruct the full story while a live event was running.
Callaba grew around a different product principle: keep the modules composable, but make their relationship visible. A broadcaster can start with one SRT or RTMP feed, add monitoring, introduce a backup source, route an output, record it, and automate the workflow only when automation is useful. The product remains the first layer; the Callaba Engine API is the second layer for teams that need repeatable control or integration.
A practical evaluation path for broadcast teams
- Start with a real contribution feed. Use the protocol and encoder already present in the production, then verify that the Callaba receiver shows an active connection and media health.
- Make the signal observable. Add the feed to Multiview and decide which status, bitrate, connection, and operator information the team needs during a live window.
- Test failure deliberately. Prepare a backup live source or file, interrupt the primary source in a controlled environment, and verify detection, switching, manual override, and recovery behavior before an event.
- Add only the outputs the production needs. Route, transcode, record, restream, or expose browser playback as explicit workflow decisions.
- Repeat the test in the chosen deployment model. Confirm network rules, capacity, access, storage, and operational ownership in cloud or self-hosted infrastructure.
What I took from the experience
The Champions League workflow was meaningful to me because it connected years of product work with a real broadcast context. The useful lesson was not that one event proves every deployment. It was that a modular system can stay understandable even as the production becomes more demanding.
That remains the direction for Callaba: product workflows first, APIs second; cloud and self-hosted deployment choices; visible signal health; deliberate recovery; and fewer hidden steps between contribution and delivery. If your team is evaluating a similar path, begin with one feed and one measurable outcome, then add complexity only after the first path is observable and tested.
