IPTV platform · one product
Catena
Television that runs on your network
A hand-managed fleet of media servers needs a dedicated engineer, and the glue you wrote yourself gets rewritten every time you grow. Catena is one managed cluster: ingest, transcode, archive, and TV delivery to set-top boxes, phones, and Smart TVs — with subscriber packages, EPG, and billing integration. On your own hardware, starting from one Ubuntu server.
The first three figures come from one installation — a Northern European IPTV operator that replaced 36 hand-managed nodes with Catena. The 100 Gbit/s is a separate measurement on a single streamer: Xeon Gold 6240, 64 GB RAM, PCIe gen3. See the case study →
Case study
36 to 20 nodes: an IPTV operator on Catena
A regional IPTV operator in Northern Europe, 163 channels and 80,000 viewers, moved off a fleet of Flussonic Media Server nodes it had been holding together by hand.
Before
163 channels for 80,000 viewers on 36 standalone Flussonic Media Server nodes. Media Server had no real clustering, so the team wrote its own: regional placement and separate monitoring for every node. Maintenance took a dedicated person, and finding a fault meant walking the servers one by one.
After
- 36 → 20 servers, the same 163 channels and 80,000 viewers
- 70% of the operations engineer's time freed
- One console points straight at the fault — no walk through 36 servers
- Migration took about a month, channel by channel, without taking viewers off air
A different shape of the same engine: a hotel chain in Cyprus serves guests around 2,000 channels without feeding them into every hotel. Read the hotel case →
scenarios
Where are your viewers?
One product, one engine. The answer decides the scenario — on your ISP network or over the open internet.
On your ISP network — IPTV
Subscribers on FTTH or a private IP network, including migration from DVB-C cable: engine plus production IPTV middleware — set-top boxes, packages, EPG, billing sync.
Cable→IPTV scenarioOver the internet — OTT
The same engine for live and catch-up at scale. The portal, apps, and monetization stay yours or a partner's.
OTT scenarioMiddleware already chosen?
Keep a stalker-like portal or your own apps — connect Catena underneath as the delivery engine over API, without replacing the product layer.
what to pick
If your job is a different one
Said up front, so a call does not end with «this is not for us». In these cases you need another product of ours, not Catena.
No home viewers, channels come from SDI/ASI. If there are no subscribers at the end of the line and the job is to take SDI or ASI and prepare TV channels around the clock, that is Mcaster
You broadcast inside your own company. Live streams to every employee, private streams, emergency notification and training in a closed perimeter — that is Agora
You need an engine, not a packaged product. Catena comes with a fixed pipeline. If you are building your own product on top of a streaming core, that is Sapsan
pipeline
From any source to every screen
Four stages of one product. Channels go in from the operator network or a content provider — and come out as a TV service for subscribers.
Ingest
Multicast straight off the operator network, SRT over lossy links, feeds from content providers. Source priorities per channel with automatic failover.
What changes: a dead source is swapped without a human — nobody gets woken up to switch an input by hand.
Works when: a channel has a second source that fails independently of the first.
channel-sourceTranscode
A quality ladder from 2160 to 360 with a unified GOP — or take a ready-made ladder from the encoder without spending a single CPU core.
What changes: channels that already arrive with a usable ladder skip the transcoder — the same machine carries more of them.
Works when: the encoder keeps a consistent GOP across qualities; a mismatched one makes switching between them ragged.
transcoderRecord
Catch-up and rewind on every channel. The archive writes across independent disks: losing a disk costs only that disk's share, not the archive.
What changes: a failed disk becomes a scheduled replacement instead of a night-time incident.
Works when: archive depth and channel count are sized to the disks you actually have.
dvrDeliver
HLS and DASH for every device, viewer routing by network zones, session authorization — you always know who is watching and from where.
What changes: a complaint about a channel is answered from the console — who watched it, from where, and on which streamer — instead of by grepping logs.
Works when: viewers reach the streamers through Catena's session authorization rather than a bypass route.
cdn-zonesarchitecture
One brain. Any number of streamers.
Catena is a managed cluster, not a pile of media servers. One console, one API, one desired state — and machines that do the heavy lifting.
central
The control plane: configuration of every channel, statistics, web console, and API. Its only state is PostgreSQL — an intact database backup is an intact installation.
database-backuplayouter
Decides which channel runs on which streamer — predictably and with recorded reasons. You can always answer "why is this channel here".
layouterstreamers
Servers that ingest, transcode, record, and serve viewers. They keep no configuration of their own — they receive it from central.
streamersA streamer needs central to change its configuration — not to work.
failover
Kill the control plane. The air stays on.
A central outage is a management incident, never an on-air one. Channels keep broadcasting, DVR keeps recording, viewers keep watching. When central returns, the cluster knits itself back together — no restarts.
The air continues
A streamer restarted during the outage comes back instantly: warm start from the local cache of its applied configuration, without waiting for a single answer from central.
central-outageChannels move on
The layouter re-plans the lost machine's channels onto the surviving streamers automatically. Every move is journaled with its reason.
reliabilityInputs switch carefully
Ordered source priorities: a dead source switches immediately, a degraded one only if something better exists. A recovered primary must first serve a clean window — no flapping.
input-failoverday two
Healthy is gray-green
Daily work happens in one console. The operator opens the dashboard and reads it at a glance: any red spot means work, everything else means coffee.
Live registry. Streamer telemetry every 2.5 seconds, per-channel error heatmap, disk and certificate warnings before they become incidents. dashboard
Sessions. Who is watching, which channel, from which streamer — with force-close when you need it. sessions
Your monitoring, not ours. Prometheus-compatible metrics and a Grafana data source built in; Retroview for deep stream analysis.
Upgrades on your schedule. apt install the new version, restart at a moment you choose — warm start brings channels back right after. One machine at a time across the cluster. The database keeps an N−1/N−2 compatibility window, so a staged upgrade can be rolled back without restoring a backup. upgrade
scaling
Growth means adding machines
The smallest installation is one machine running everything. When it gets tight, you add streamers through a join window in the UI — the installation you have stays where it is, nothing gets rebuilt.
- Permit join opens a one-hour window; the new machine enters with a token — no config file editing. Unattended rollout via Ansible is supported. add-streamer
- Retiring a machine is just as deliberate: revoke access, delete with channel re-planning, or purge permanently. remove-streamer
- Plain Ubuntu, deb packages, systemd. No orchestrator to learn before you can broadcast television. One command takes a bare Ubuntu box to a playing channel: apt install catena. install
adoption
How you get there — and what happens after
Catena goes in beside the service you run today, not instead of it. Channels move in groups, and a group that misbehaves goes back.
Pilot
One or two channels on Catena next to the setup you already run. The portal hands out links to the pilot only — nobody else is affected.
Move in groups
Channels migrate by group or by region. If a group does not behave, it goes back to the old setup — the move is reversible at every step.
The portal stays
Your portal, apps, and billing stay where they are — only the access hand-off is re-pointed. Subscribers watch the way they always have.
Retire the old fleet
Machines freed by the move get re-used in new roles rather than written off.
In the Northern European installation the whole move took about a month, channel by channel, without taking viewers off air. See the case study →
Support from the vendor. Your ticket is registered and diagnosed; a confirmed defect goes to the development team and comes back to you as part of a release, with notice of the fix.
Upgrading stays your decision. Catena never updates itself — there is no forced-update mechanism. The version changes only when your administrator changes it, through the package manager.
procurement
What you actually buy
A subscription to the platform, not licences for servers.
Channels and viewers. The price follows the number of channels and the number of viewers — what you actually put on air, not the size of your machine fleet.
Servers are not charged for. You run as many machines as suits your delivery. Adding a streamer, spreading the load across sites, or keeping spare capacity does not change the subscription.
Start with a pilot region
Tell us about your network, channel list, and subscriber count. Our engineers will lay out the architecture, server sizing, and a phased launch — in parallel with the service you run today. We agree up front on the metrics that decide whether the pilot succeeded.
Counting the money first? What the move actually costs →