Functional characteristics¶

This page is the map of the whole product: what Catena does for an operator today and what it is going to do. It is a reference, not a tutorial — each capability is one line, and the pages of this manual describe the ones you can already use.

Catena has two layers, and they are licensed separately: you can take the delivery engine alone and add the subscriber service when you need it.

The delivery engine takes channels in, processes them, records the archive and serves viewers. If you already run a portal or middleware, this is the layer you connect to it.
The subscriber service turns those channels into a product: portals, packages, the guide, subscribers, and the apps they watch on.

How to read the status¶

Status	Meaning
available	Works in the current release, documented or being documented
in progress	Being built right now — the screen or the API may be incomplete
planned	Decided and on the roadmap, not started

No dates or version numbers are given here on purpose: a capability map that promises quarters goes stale faster than it gets read. Ask your account manager for timing.

The delivery engine¶

Ingest¶

Capability	Status	What it is
Sources over RTMP, RTSP, MPEG-TS (UDP and HTTP), HLS, M4F	available	The usual ways a channel arrives from a headend or a partner
Multicast ingest	available	Take SPTS straight off the operator network
SRT ingest	available	Take a feed over a lossy link, with a passphrase
Publishing point	available	The far side pushes into Catena instead of being pulled
Synthetic source	available	Built-in generator to prove the path before a real feed exists
Backup sources with priority	available	An ordered list; the channel moves to the next one when a source dies
Backup file	available	A clip goes to air when every source is down
Source quality thresholds	available	Timeouts, bitrate floor and ceiling, MPEG-TS continuity errors
Source state with a reason	available	Working, degraded or dead — and why, per source
MPTS ingest with program selection	planned	Take one multiplex and pick the programs out of it
DVB-C/T/S capture cards	planned	Channels taken straight off a cable, terrestrial or satellite tuner

Processing¶

Capability	Status	What it is
Transcoding to H.264 and H.265	available	Bring any source to what viewers' devices actually decode
ABR ladder	available	Several renditions per channel: resolution, bitrate, GOP, resize strategy per rung
Track selection by id or by language	available	How each input is turned into an output
Per-track audio encoding	available	Different codec and bitrate per audio track
Thumbnails	available	Frames for seek previews and channel tiles, from keyframes or over HTTP
Automatic subtitles from speech	in progress	Speech recognition turns audio into a subtitle track
Subtitle handling: DVB, teletext, CEA-608 to WebVTT	in progress	Carry broadcast subtitles through to formats OTT players understand
Hardware transcoding: NVENC, Quick Sync	planned	GPU density for channel farms instead of CPU-only encoding
Deinterlace	planned	Interlaced broadcast feeds to progressive for OTT devices
Logo overlay and burned-in text	planned	Station bug and on-screen text, including a running clock
Loudness normalisation	planned	Bring channels to a common loudness instead of a manual gain knob
SCTE-35 markers	planned	Read splice markers and re-emit them across output protocols

Archive, catch-up and timeshift¶

Capability	Status	What it is
Archive recording	available	Record a channel with a depth and size limit
Archive across several disks	available	Several mount points per streamer, with mount checking and disk state
Archive playback by time range	available	Play any past interval by its UTC boundaries
Catch-up by programme	planned	The viewer picks a programme from the guide and it plays from its start
Startover and pause live	planned	Jump to the beginning of what is on now, and pause a live channel
Relative and absolute timeshift	planned	Play a fixed number of seconds behind live, or from a wall-clock moment
Time-zone shifted channel	planned	A separate "+2 hours" feed, read from the archive once and served to everyone
Network PVR	planned	Subscriber-requested recordings kept beyond the channel's own retention
Protected archive ranges	planned	Pin an interval so retention will not delete it
Archive replication between streamers	planned	A recording survives losing the machine that made it
Archive in S3	planned	Push depth into object storage instead of local disks
SSD cache for hot archive	planned	Prime-time catch-up served off SSD without paying for an all-SSD archive

Delivery¶

Capability	Status	What it is
HLS and LL-HLS	available	The default way viewers watch, and its low-latency variant
DASH	available	The second manifest format, for devices that prefer it
MPEG-TS and fMP4 output	available	Plain transport for STBs and for other servers
Built-in player	available	Watch a channel from the console without setting up anything
CDN zones	available	Viewers are routed by their IP to the streamers of their zone
Load balancer	available	The player asks one address and is sent to the streamer that carries the channel
Multicast output	planned	Serve your own subscribers on a managed network by pushing channels into multicast groups
Thumbnail tracks in manifests	planned	Scrub previews in the player's timeline
Track filtering in the URL	planned	Ask for a specific subset of video, audio and subtitle tracks
Geo-aware routing	planned	Pick an edge by the viewer's geography, not only by their subnet
Smooth Streaming (MSS)	planned	Legacy device and PlayReady path

Access and protection¶

Capability	Status	What it is
Operator login and API keys	available	Credentials for the console and bearer keys for the management API
Join tokens and streamer keys	available	How a machine is admitted to the cluster and how it authenticates afterwards
Playback authorization backends	in progress	Catena asks your service whether a session may play; the screen exists, the API is being migrated
Signed playback links	planned	A hashed link with an expiry and an optional IP binding, checked without calling anyone
Several authorization sources at once	planned	Ask more than one backend in parallel; the first "yes" wins
Concurrent session limit	planned	Cap the streams one subscriber may run, and catch shared passwords
Geographic restrictions	planned	Enforce territorial rights on playback
Domain lock, CORS and IP lists	planned	Restrict where a stream may be embedded and who may request it
DRM: Widevine, PlayReady, FairPlay	planned	Studio-grade protection with keys from your DRM vendor over CPIX
DRM over archive and VOD	planned	The same protection on catch-up and on files, with key rotation

Advertising¶

Capability	Status	What it is
Server-side ad insertion	planned	Ads stitched into the stream, so ad blockers do not see a separate request
Insertion on SCTE-35 cues	planned	Replace the breaks the broadcaster already marks
Insertion on a schedule	planned	Breaks where the source carries no markers
Ad decision by your backend	planned	Which creative a given viewer sees is your system's call
Impression tracking	planned	Per-viewer records of what was actually shown

Cluster and resilience¶

Capability	Status	What it is
Streamer registry	available	Every machine, its state and its telemetry in one screen
Joining a streamer	available	A time-boxed window and a token instead of editing files
Automatic channel placement	available	Central decides which streamer runs which channel
Placement history and reasons	available	Why a channel is where it is, and what moved it
Recovery from a streamer loss	available	Channels of a dead machine are re-planned onto the survivors
Configuration delivery	available	Central holds the settings and tracks desired, synced and applied per streamer
Channel limit per streamer	planned	Cap how much one machine takes; zero keeps it in the cluster but empty
Database backup and restore	planned	A supported procedure instead of a hand-written `pg_dump`
Capacity planning guidance	planned	How much headroom a cluster needs to survive losing a machine

Observability and operation¶

Capability	Status	What it is
Dashboard	available	The whole installation on one screen: machines, channels, traffic, errors
Streamer telemetry	available	CPU, network, running channels, archive capacity, uptime, last contact
Live viewer sessions	available	Who is watching what, from which streamer, with filters and a force-close
Session history	available	Closed sessions with duration, bytes and the reason they ended
Built-in metrics server	available	Prometheus-compatible queries and a Grafana data source, without extra parts
Structured logs and traces	available	Machine-readable logs and OpenTelemetry traces for tracking a request
Retroview	available	Vendor cloud monitoring with long history and curated alerts
Log screen in the console	planned	Reading cluster logs without a shell
Alerts by email, Telegram, webhook	planned	Being told about a dead channel instead of noticing it
SNMP	planned	Integration with an existing NOC
Events and webhooks	planned	Push what happened into your systems, with retries
Player-side quality telemetry	planned	Rebuffering, start time and errors as the viewer's device sees them

The subscriber service¶

This layer is what turns a stream into a television product. Take it if you have no operator TV system; skip it and connect your own portal over the API if you already have one.

Portals and multi-tenancy¶

Capability	Status	What it is
Portal as a tenant	planned	Separate subscribers, channels and packages on shared infrastructure
Portal branding	planned	Logo and names used in the apps and the store listings
Own domain per portal	planned	Each brand answers on its own address
Own API key per portal	planned	Integrations are scoped to one tenant
One source, several portals	planned	The same feed serves several brands and is ingested once

Channels, packages and the guide¶

Capability	Status	What it is
Channel templates	in progress	Settings written once and applied to hundreds of channels
Channel catalogue	planned	Title, logo and guide binding on top of the technical stream
Packages	planned	Named bundles of channels — the thing a subscriber actually buys
Free packages	planned	Channels every subscriber gets without a subscription
Guide from XMLTV	planned	Import the schedule from your provider, refreshed automatically
Guide from the transport stream	planned	Take EPG out of DVB EIT when there is no XMLTV feed
Guide import diagnostics	planned	What was fetched, what changed, what failed and when
Programme API	planned	Query the schedule for apps and integrations

Subscribers and subscriptions¶

Capability	Status	What it is
Subscriber accounts	planned	The person who watches, and what they are entitled to
Login by phone and SMS code	planned	No passwords for the viewer
Registration on first login	planned	The account appears when someone first signs in, if you allow it
Playback token per subscriber	planned	What the streamer checks before letting a session play
Subscriptions to packages	planned	Access granted and revoked immediately
Blocking a subscriber	planned	Cut access without losing the account and its history
Trial and promotional periods	planned	Time-boxed access as a feature, not a cron script
Billing integration	planned	Your billing drives subscriptions over the API and webhooks

Viewer applications¶

Capability	Status	What it is
Android TV and set-top box app	planned	The main screen for an operator's subscribers
Web player for viewers	planned	Watching without installing anything
Operator branding	planned	The app carries your name, logo and store listing
Channel list with now and next	planned	What is on, and what is on after it
Catch-up from the guide	planned	Pick a past programme and watch it from the start

Analytics and audit¶

Capability	Status	What it is
Viewing sessions	available	The live and historical record of who watched what
Audience per channel	planned	Ranking and trends rather than raw sessions
Traffic per subscriber	planned	Bytes attributable to a subscriber, for billing
Operations audit log	planned	Who changed what, and when — including subscription changes

Operator staff and permissions¶

Capability	Status	What it is
Operator credentials	available	One login pair and API keys for the whole installation
Several staff accounts	planned	Named people instead of a shared password
Permission scopes	planned	Separate rights over infrastructure, content and subscribers

Integration¶

Capability	Status	What it is
Management API	available	Everything the console does, available to your systems
Connecting a third-party portal	available	Keep the portal you have and drive Catena over the API
OpenAPI schema and SDKs	in progress	Generated clients instead of hand-written HTTP calls
External channel provisioning	planned	Catena asks your service which channels should exist and matches it
Outbound webhooks	planned	Events pushed to your systems, with retries

What Catena does not do¶

These are deliberately outside the product. Naming them saves a discovery call:

Cameras, surveillance, exporting recordings and proxied viewing — connecting cameras (including reaching ones with no public address through an agent), cutting a piece of the archive out into an MP4 file, and proxying playback through the control server are Watcher.
WebRTC and NDI — publishing over WHIP, playback over WHEP, NDI ingest and the products built around them are Agora.
Baseband, sending channels onward and the DVB transport multiplex — SDI, ASI and ST-2110 ingest, pushing channels out to third parties over RTMP, SRT or MPEG-TS, and building an MPTS with SI/NIT/SDT tables and logical channel numbers are Mcaster. Catena keeps the two directions it needs for its own service: taking a feed in over SRT, and pushing out to multicast for its own subscribers.
Conditional access for broadcast — CAS and scrambling for cable and satellite estates. On a managed network, isolation and DRM cover the same ground differently.
Billing and tariffs — Catena knows who is entitled to what, never what it costs. Prices, invoices and payments live in your billing system, which drives Catena over the API.