Version 26.08

Flussonic 26.08: Catena migrates itself off Flussonic v3, and Watcher stops keeping quiet about a missing archive

Why Catena is not "Flussonic with a cluster"

Flussonic Media Server was written as software for one server. Everything in it is arranged around the machine: the configuration lives there, the stream belongs to it, the archive is written to its disks. Clustering came later and stayed limited — in essence it is a set of agreements between separate servers, each of which still lives its own life. Such an installation grows badly: every new machine is one more configuration to remember and one more server to log into in order to find out what is going on.

Catena is built on Sapsan — the new Flussonic streaming core written in Rust — and is designed cluster first. The unit of management here is the cluster, not the server, and you can see it in every feature:

The second thing that sets Catena apart is introspection at a level our products have never had. Not "log into each server and read the logs", but a single interface that answers questions about the whole installation: a dashboard with viewer and traffic charts and a heat map of stream errors; sessions one by one — who exactly is watching right now and who watched yesterday; the history of layouter decisions with reasons; source diagnostics and streamer diagnostics.

A telling example is live monitoring of backup sources. Ask yourself: how do you find out today that a channel's backup input is actually dead? The usual answer is that you do not — while the primary source is on air nobody touches the backup, and its health stays a matter of faith right up to the moment you need it. Catena probes the backup while it waits: the input card shows Ready — probed and able to take the load — or Never probed, and you see it on the sources tab straight away instead of during an incident. The same tab shows more than "frames or no frames": MPEG-TS continuity errors, bitrate falling below the floor, audio gone, timeline quality.

At the same time the control plane never sits on the media path: losing central is a management outage, not an on-air one — streams keep broadcasting.

And we help you move. The import wizard takes the configuration of a running Flussonic Media Server, shows a plan before applying it and a report afterwards. But the tool is only part of it: tell us about your installation and we will plan the migration together — what moves first, how the air is verified, and when the viewers are switched over.

Here is what we did for Catena

Moving off Flussonic v3 with a wizard instead of by hand. A customer running Flussonic Media Server had neither a migration procedure nor a tool: moving the configuration meant retyping hundreds of streams, with the risk of silently losing a setting whose loss you discover on air. Catena's console now has an import wizard: it reads the source configuration over the API and turns it into streams, template sections and authorization backends in the new format. First you get a plan — what exactly will move and what will be lost — and only then the apply step; afterwards you receive a report grouped by category, with a reason for every field that did not move, and a count of the streams that actually came up. The import has been verified against a production router's configuration. The full procedure, including switching viewers over and rolling back, is described in Migrating from Flussonic Media Server.

An installation that leaves you with a working product. There used to be a wall of manual work between apt install catena and a running service: the package did not create the PostgreSQL role and database, did not write the connection string, did not create an operator account and did not even start the service on a clean install. Now the package does all of it — the quickstart takes a clean machine to a playing stream, and installing for production covers what ships, where the secrets live, how to attach an external PostgreSQL and which ports open. A cluster node is installed with its own catena-streamer package, which asks for the central address during installation; enter an address without a scheme and you get a clear error instead of a node that silently fails to come up — see adding a streamer. The box is now called by its own name: systemctl status catena. For docker deployments there are product images built in layers, so an update does not pull the whole distribution again.

HTTPS without rolling certificates out by hand. The product now has a built-in ACME client: a streamer orders and renews its Let's Encrypt certificate itself, central included. No more distributing certificates across 10–100 nodes manually, and central never holds anybody else's private keys. As a side effect, the port and TLS of the local node are now edited from the console rather than by editing YAML on the box. Issuing prerequisites, the TLS-ALPN-01 check and the reasons a certificate does not get issued are all in HTTPS certificate.

Stream templates. "By the third stream I was already tired of clicking through the settings" — that is a literal quote from the ticket. Catena brings back the notion of a reusable default: the transcoder, archive, thumbnails and source timeouts are configured once in a template, and uniform channels are created from it. The resolution rule is simple and free of surprises: a stream's own section wins over the template's entirely.

Playback authorization: as in Flussonic, only faster. Backends written for Flussonic work with Catena without a single change — same request, same headers, here is how to attach one. You do not have to rewrite your storefront to migrate. And for those who care about start-up speed there is a second scheme: the storefront creates the session before playback and hands the viewer a ticket that the streamer validates locally, without calling anywhere. Your backend stops sitting on the critical path: neither channel-switching speed nor start-up reliability depend on it any more. A ticket's scope is expressed with a content label, so a ticket "for 300 channels" does not carry a list of 300 names and is not reissued when the package line-up changes. An overview of both ways is in Protecting playback.

MPTS ingest: program selection and one capture per multiplex. MPEG-TS over UDP used to be read as SPTS only: the program number was dropped and frames from every program in the multiplex were merged into one mess — a black screen in HLS. The source now has a Program (PNR) field, and several streams can capture the same multicast: the trunk arrives at the server once rather than once per channel. On a typical multiplex that saves hundreds of megabits of inbound traffic. Attaching a multicast source has a page of its own. On top of that, the MPEG-2 elementary stream is now parsed — without it, broadcast and satellite trunks simply could not be taken in.

MoQ: delivery over the protocol the industry is moving to. Media over QUIC is what the consortium around the IETF is putting in place of the "HLS for scale, WebRTC for latency" split. The idea is to have both at once: sub-second latency together with ordinary cacheable delivery through the network, rather than a separate peer-to-peer path per viewer. Catena delivers live over MOQT (draft-19, CMAF/CMSF): the streamer opens a QUIC listener, the browser arrives over WebTransport and plays — no plugins, no gateways. Internally the stream is cut not into whole fragments but into the same parts as in LL-HLS, so low latency comes out of the design rather than out of buffer tuning. This is a first implementation and delivery only: MoQ ingest and relay fan-out across the cluster are the next steps. But you can try it on your own channel today — it is enabled with a listener in the streamer configuration.

RTP push and archive playback over RTSP. MPEG-TS push now speaks RTP as well as bare UDP: typical hardware receivers accept exactly that, and lossy networks ask for it too. Separately, the archive can now be served over RTSP with Range: clock= — the one standardised way third-party city surveillance systems read somebody else's archive. Until now that integration was impossible in principle.

Broadcast subtitles as an ordinary track. CEA-608/708 closed captions travelling inside the picture are now turned into a WebVTT track that every OTT player understands. A subscriber in your application sees the same subtitles as a viewer of the same channel over cable — and accessibility requirements (CVAA in the US, the European Accessibility Act in Europe) are met without a second input or manual work. Multiple languages come for free: broadcasters often put two or three language services into one channel, and each becomes its own entry in the subtitle menu. In detail: Closed captions of a broadcast channel.

Subtitles arrive on air in several different ways, and we reduce them to a single form. CEA-608/708 closed captions inside video frames work today. DVB subtitles arrive as pictures, so the text has to be recognised — DVB OCR ships in the next version. The point of all of this is that the output has one shape: wherever the subtitles came from, the viewer gets an ordinary WebVTT track, and you need neither a second input nor a separate pipeline per broadcast format.

The transcoder: denser and seamless. With MBR, one input frame used to be decoded as many times as you had output qualities: on an FHD/HD/SD set the worker ran at 0.7–0.8× real time, the live edge fell behind and players buffered. Now the input is decoded once and the decoded frame is handed to every encoder. Encoding on a graphics card has arrived: with NVIDIA the whole video path — decode, scale and encode — moves onto the card, and the card is chosen explicitly or automatically, the least loaded one. Reconfiguration also stopped being destructive: the transcoder no longer rebuilds itself over noise such as measured bitrate, and when it genuinely has to reconfigure — the source changed resolution live, say — it happens without lost frames, a forced IDR or a DTS break. The quality ladder, audio rules and presets are in Transcoding and MBR.

Fewer artefacts for the viewer. Live DASH used to fall apart seconds after the transcoder was switched on: the tracks of one stream were cut on grids that did not agree, the rounding error accumulated, and the live edge drifted within a second — the grids are aligned now. In LL-HLS, discontinuities are numbered once and never renumbered after the fact, so hls.js no longer dies with discontinuity sequence mismatch; the preview track stopped producing false discontinuities that left the player with an empty buffer. A stream whose encoder inserted unscheduled IDRs no longer shatters into 32–64 ms segments. A change of program description in the PAT no longer drops a half-assembled frame — which used to give an outwardly healthy segment with a hole in the GOP, playback stuck in Chromium and a hole in the archive forever. And the multi-second audio freezes after every input switch are gone as well.

You can see what is happening. The dashboard answers the "is everything all right" question with tiles, viewer and traffic charts and a heat map of errors. Sessions are visible one by one: not "so many viewers", but who exactly is watching this stream right now and who watched recently — the history is no longer lost. Source diagnostics shows more than "frames or no frames": MPEG-TS continuity errors, bitrate drops, audio gone; failover now returns to the priority source only after a clean window rather than on the first frame. If a DVR disk is unmounted or there is a typo in the path, you see it in the interface instead of a WARN line in a log. And if a streamer did not apply saved settings, the reason now reaches the console — see Streamer diagnostics.

Thirty thousand viewers from a single node. This is arguably the number of the release. Over low-latency protocols — HTTP MPEG-TS, RTSP — Flussonic hit a ceiling of roughly one to two thousand concurrent clients per server; beyond that, viewers started dropping. Catena 26.08 holds 30,000 concurrent viewers on one node over the same protocols.

The cause was session accounting. All of a node's sessions lived in one table under a shared lock, and both hot paths went into it at once: socket sessions — which is exactly what the low-latency protocols are — report transferred bytes once per second each, while HTTP viewers look up their record on every segment request. At thirty thousand sessions that meant over twenty-six thousand lock acquisitions per second. The lock itself was doing useful work about 13% of the time — the system was not short of power, it was queueing behind itself: the wait reached a second on average and almost twelve seconds at peak.

It was not monitoring that paid for the queue, it was the viewer. While a session waits for the lock it does not drain the frame ring, and a ring on a live stream lasts seconds — a subscriber stuck in the queue dropped out entirely. On ingest it looked like 700 ms gaps, and a source that should have pulled fifteen gigabits pulled three. Sessions have now moved to columnar storage with separate partitions, byte accounting was covered by tests before the change, and the queue is gone along with the ceiling of fifteen hundred clients.

Not only delivery: recording, too. The other half of the same work is sustained recording of 20 gigabits per second per server. Translated into cameras, that is 10,000 mid-resolution cameras on one machine recording continuously — not a peak figure for a demo, but the regime the server lives in. For an operator it changes the arithmetic of a project: where the archive used to add up to a rack, a few machines are now enough, and the state of the disks and what occupies the space is visible across the whole cluster at once.

The archive in a cluster. A stream on an edge now has an archive cache — a separate switch that does not require recording: the origin writes the archive while edges closer to the viewers keep what is actually being watched, and reads almost stop reaching the origin's disks. How much the cache took and what the hit rate is are in the Cluster DVR section, which also answers "where did the space go" on an installation with dozens of disks. Viewers are spread by geography with CDN zones.

VOD went cluster-wide. File VOD used to live at single-node level: to serve an asset you had to know which machine and which directory it was on. Now central keeps the VOD catalogue for the whole cluster, and you can upload files straight from the browser without choosing a node or a disk: the asset goes to the storage with the most free space, and the bytes travel directly to the streamer, bypassing the control plane. Portals doing their own uploads get upload tokens. And the two things migrating customers used to repackage their content for now work as they are: MBR is assembled from sibling files, and external subtitles are picked up from the file next to the video — movie.mp4 and movie.srt play without conversion.

Watcher is moving to Catena's technology

The main Watcher news in this release is not a feature but a direction. Watcher has begun moving to the same core Catena is built on: the media layer stops being Flussonic Media Server and becomes Sapsan. In 26.08 the first visible step is done — the media layer got a name of its own: the watcher-streamer package and docker image, behind which the engine can be replaced without touching installation commands, documentation or your playbooks.

What this gives you. Sapsan is written in Rust and is built for densities of a different order: sustained recording of 20 gigabits per second per server is 10,000 mid-resolution cameras on one machine. As the migration proceeds we expect a several-fold reduction in resources for the same installation: fewer machines for the same number of cameras, less rack space, a smaller bill for power and maintenance. Plus everything described above in the Catena section — state introspection and a cluster model that today's media layer does not have.

The migration will be gradual and free of surprises for running installations. But if you would like a product of a different calibre sooner, we invite you into the early adoption programme: we will look at your installation together, plan the migration and carry it out with our participation.

Here is what we did for Watcher

An NVR no longer keeps quiet when the archive is not being written. This is the nastiest scenario of all: in the app the cameras are green, live video is there, and the archive has not been written for days — the disk, the DVR or the recording has stopped. The customer finds out at the moment the archive is needed: after a theft, a dispute or a "who drove through here". The difference from "the NVR is offline" is fundamental: offline is at least visible, while "online but nothing is being recorded" is a false sense of security. Watcher now watches for this and warns.

Notifications when an NVR breaks — and when it recovers. A user used to learn that an NVR had broken only by opening the list of NVRs. Now organization admins receive a push with the reason — the network between the cloud and the NVR is unavailable, the NVR stopped answering the API — and when it comes back, a recovery notification arrives. Push delivery on the backend was made common to all notification types: delivery is retried on failure, and stale subscriptions no longer clog the queue.

You can see where the archive goes and how intact it is. For every camera on an NVR you can now see how much space its archive takes: you can tune retention instead of buying disks. And, most importantly, you can see the state of the archive: "we keep 30 days" and "over those 30 days the archive added up to 25 with holes" are different things, and the difference no longer hides. Archive integrity is now indicated, and archive depth is counted per stream.

Watcher's media layer got its own name. There is now a watcher-streamer package and a flussonic/watcher-streamer docker image. That closes two things. First: on cluster media nodes, which were installed with apt install flussonic, the media server admin UI was exposed — it is now closed in both the package and the docker delivery. Second: for a video surveillance system the engine is an implementation detail, and there is no reason to say it out loud in installation commands and playbooks. The media layer now has a permanent name behind which the engine can change.

The first install stopped failing, and upgrades became verifiable. The all-in-one install failed on the very first apt install and required running the installation a second time — reproduced consistently on clean Ubuntu 22.04 and 24.04. The cause has been found and fixed. Separately we took on the database migrations: the chain had grown to 193 revisions, a first install spent over forty seconds on them, and — worst of all — an upgrade with real data from old versions was not verified by anything at all. A clean install now comes from a schema snapshot, and the migrations themselves are covered by tests.

Resources no longer leak, and lists no longer crawl. The stream list method left uncommitted transactions in PostgreSQL: connections got stuck in idle in transaction, memory leaked, CPU load grew and the service went down — fixed. Separately we took on interface speed on large installations: a customer with 1,100+ cameras could not scroll through the list to check the cameras' state by their previews — the page stopped responding. The camera list, folder opening, scrolling and folder search have all been sped up.

Permissions and accounts. Organization users could be granted fewer permissions than ordinary users; both places now work the same way. You can leave a note on an organization user, and changing an organization owner and listing organizations by camera permissions have been fixed.

The new player with a debug panel. The new player got a debug panel with charts and an event timeline. When a "it stutters" complaint arrives you no longer have to take it on faith: you can see what actually happened to playback.

26.08 is the last release with API v2 support. This is arguably the most important item for anyone with their own integrations: v2 is switched off in the next version. The warning is now shown right in the interface — email campaigns do not work for this, and we need to know the administrator has seen it.

The good news is that there is somewhere to move right now: everything that was in v2 is already in API v3 — there is nothing to wait for and no missing endpoints to negotiate. If you have a custom integration, a billing system or a mobile application on v2, write to us: we will look at your calls and help move them to v3 before support ends.

Flussonic Media Server

This release brings one change to Media Server, and a useful one for anyone with many cameras: debouncing of repeated motion detector triggers. A badly configured camera — sensitivity set too high, or a zone covering swaying branches — can emit a stream of "motion started" events without pause, and on a large installation such cameras together buried the management server under thousands of events and pinned its CPU. Repeated triggers are now collapsed, so you can sort out individual cameras calmly rather than in firefighting mode.

And something worth saying plainly: the phase of active development of Flussonic Media Server is over. The product stays supported and we will keep issuing minimal security updates, but there will be no new capabilities in it — all development goes into the products on the new core.

So we invite you to start planning the move. If you do video surveillance, that means Watcher, which began moving to the same core in this very release; if you do television and OTT, it means Catena, which already has a configuration import wizard with a plan before and a report after. A migration is more than a tool, so we take part in it ourselves: tell us about your installation and we will decide together what moves first and how the air is verified along the way.