Version 26.08

Flussonic 26.08: Catena migriert sich selbst von Flussonic v3, und Watcher schweigt nicht mehr über ein fehlendes Archiv

Warum Catena nicht «Flussonic mit Cluster» ist

Flussonic Media Server wurde als Software für einen Server geschrieben. Alles darin dreht sich um die Maschine: Die Konfiguration liegt dort, der Stream gehört ihr, das Archiv wird auf ihre Platten geschrieben. Cluster-Funktionen kamen später und blieben begrenzt — im Kern sind sie eine Reihe von Absprachen zwischen einzelnen Servern, von denen jeder weiterhin sein eigenes Leben führt. Eine solche Installation wächst schlecht: Jede neue Maschine ist eine weitere Konfiguration, die man sich merken muss, und ein weiterer Server, auf den man sich einloggen muss, um zu erfahren, was dort passiert.

Catena ist auf Sapsan gebaut — dem neuen, in Rust geschriebenen Streaming-Kern von Flussonic — und cluster first entworfen. Die Verwaltungseinheit ist hier der Cluster, nicht der Server, und das zeigt sich in jeder Funktion:

Das Zweite, was Catena auszeichnet, ist Introspektion des Zustands auf einem Niveau, das unsere Produkte nie hatten. Nicht «loggen Sie sich auf jedem Server ein und lesen Sie die Logs», sondern eine einzige Oberfläche, die Fragen zur gesamten Installation beantwortet: ein Dashboard mit Zuschauer- und Traffic-Kurven und einer Heatmap der Fehler; Sitzungen einzeln — wer genau gerade zusieht und wer gestern zusah; die Entscheidungshistorie des Layouters mit Begründungen; Quellendiagnose und Streamer-Diagnose.

Ein aussagekräftiges Beispiel ist die Live-Überwachung der Backup-Quellen. Fragen Sie sich: Woran erkennen Sie heute, dass der Backup-Eingang eines Kanals tatsächlich tot ist? Die übliche Antwort lautet: gar nicht — solange die Hauptquelle auf Sendung ist, rührt niemand das Backup an, und dessen Funktionsfähigkeit bleibt eine Glaubensfrage bis genau zu dem Moment, in dem man es braucht. Catena prüft das Backup, während es wartet: Die Karte des Eingangs zeigt «Bereit» — geprüft und in der Lage, die Last zu übernehmen — oder «Nicht geprüft», und das sieht man im Tab der Quellen sofort und nicht erst im Störfall. Dort sieht man auch mehr als «Frames vorhanden oder nicht»: MPEG-TS-Kontinuitätsfehler, Bitratenabfall, verschwundenen Ton, Qualität der Zeitachse.

Dabei steht die Steuerungsebene nie im Medienpfad: Ein Ausfall von Central ist eine Störung der Verwaltung, nicht der Sendung — die Streams senden weiter.

Und wir helfen beim Umstieg. Der Import-Assistent übernimmt die Konfiguration eines laufenden Flussonic Media Server, zeigt einen Plan vor dem Anwenden und einen Bericht danach. Doch das Werkzeug ist nur ein Teil: Erzählen Sie uns von Ihrer Installation, und wir planen den Umstieg gemeinsam — was zuerst umzieht, wie die Sendung geprüft wird und wann die Zuschauer wechseln.

Das haben wir für Catena gemacht

Der Umstieg von Flussonic v3 — mit Assistent statt von Hand. Ein Kunde mit laufendem Flussonic Media Server hatte bislang weder ein Umstiegsverfahren noch ein Werkzeug: Die Konfiguration zu übertragen bedeutete, Hunderte Streams abzutippen, mit dem Risiko, still eine Einstellung zu verlieren, deren Verlust man erst auf Sendung bemerkt. Jetzt hat die Catena-Konsole einen Import-Assistenten: Er liest die Quellkonfiguration über die API und macht daraus Streams, Vorlagenabschnitte und Autorisierungs-Backends im neuen Format. Zuerst erscheint ein Plan — was genau umzieht und was verloren geht — und erst danach das Anwenden; nach dem Import erhalten Sie einen Bericht nach Kategorien, mit Begründung zu jedem nicht übernommenen Feld, und die Zahl der tatsächlich gestarteten Streams. Der Import wurde an der Konfiguration eines produktiven Routers geprüft. Das gesamte Verfahren, samt Umschalten der Zuschauer und Rückweg, steht unter Umstieg von Flussonic Media Server.

Eine Installation, nach der das Produkt läuft. Zwischen apt install catena und einem laufenden Dienst stand früher eine Mauer aus Handarbeit: Das Paket legte weder PostgreSQL-Rolle noch Datenbank an, schrieb keine Verbindungszeichenfolge, legte kein Betreiberkonto an und startete den Dienst bei einer sauberen Installation nicht einmal. Jetzt erledigt das alles das Paket — der Schnellstart bringt eine saubere Maschine bis zum spielenden Stream, und die Installation für den Produktivbetrieb erklärt den Lieferumfang, wo die Geheimnisse liegen, wie man ein externes PostgreSQL anbindet und welche Ports geöffnet werden. Ein Cluster-Knoten wird mit dem eigenen Paket catena-streamer installiert, das während der Installation nach der Central-Adresse fragt; wird sie ohne Schema eingegeben, sehen Sie einen verständlichen Fehler statt eines Knotens, der still nicht hochkommt — siehe Streamer hinzufügen. Und die Box heißt jetzt nach ihrem eigenen Namen: systemctl status catena. Für Docker-Deployments gibt es Produkt-Images, die in Schichten gebaut sind — ein Update lädt nicht die ganze Distribution erneut.

HTTPS ohne manuelles Ausrollen von Zertifikaten. Das Produkt hat jetzt einen eingebauten ACME-Client: Der Streamer bestellt und erneuert sein Let's-Encrypt-Zertifikat selbst, Central eingeschlossen. Zertifikate von Hand auf 10–100 Knoten zu verteilen ist nicht mehr nötig, und Central hält keine fremden privaten Schlüssel. Nebenbei werden Port und TLS des lokalen Knotens jetzt aus der Konsole bearbeitet und nicht per YAML-Datei auf der Box. Voraussetzungen der Ausstellung, die TLS-ALPN-01-Prüfung und die Gründe, warum ein Zertifikat nicht ausgestellt wird, stehen im HTTPS-Zertifikat.

Stream-Vorlagen. «Beim dritten Stream hatte ich es satt, mich durch die Einstellungen zu klicken» — das ist ein wörtliches Zitat aus dem Ticket. Catena bringt den Begriff der wiederverwendbaren Voreinstellung zurück: Transcoder, Archiv, Vorschaubilder und Quellen-Timeouts werden einmal in einer Vorlage konfiguriert, und gleichartige Kanäle entstehen daraus. Die Auflösungsregel ist einfach und ohne Überraschungen: Der eigene Abschnitt des Streams gewinnt vollständig gegen den der Vorlage.

Wiedergabe-Autorisierung: wie bei Flussonic, nur schneller. Backends, die für Flussonic geschrieben wurden, funktionieren mit Catena ohne eine einzige Änderung — gleiche Anfrage, gleiche Header, so bindet man sie an. Sie müssen Ihr Portal für den Umstieg nicht umschreiben. Und wem die Startgeschwindigkeit wichtig ist, dem steht ein zweites Verfahren offen: Das Portal legt die Sitzung vor der Wiedergabe an und gibt dem Zuschauer ein Ticket, das der Streamer lokal prüft, ohne irgendwohin zu rufen. Ihr Backend steht damit nicht mehr im kritischen Pfad: Weder die Umschaltgeschwindigkeit noch die Zuverlässigkeit des Starts hängen noch von ihm ab. Der Geltungsbereich des Tickets wird über ein Inhalts-Label ausgedrückt, deshalb schleppt ein Ticket «für 300 Kanäle» keine Liste mit 300 Namen mit sich und wird bei geänderter Paketzusammensetzung nicht neu ausgestellt. Ein Überblick über beide Wege steht unter Wiedergabe schützen.

MPTS-Empfang: Programmauswahl und eine Aufnahme pro Multiplex. Früher wurde MPEG-TS über UDP nur als SPTS gelesen: Die Programmnummer fiel weg, und die Frames aller Programme des Multiplex verschmolzen zu einem Brei — schwarzer Bildschirm in HLS. Jetzt hat die Quelle das Feld «Programm (PNR)», und mehrere Streams können denselben Multicast aufnehmen: Der Stamm kommt einmal am Server an statt einmal pro Kanal. Bei einem typischen Multiplex spart das Hunderte Megabit eingehenden Traffic. Wie eine Multicast-Quelle angebunden wird, hat eine eigene Seite. Zusätzlich wird jetzt der MPEG-2-Elementarstrom geparst — ohne ihn konnten Sende- und Satellitenstämme schlicht nicht angenommen werden.

MoQ: Auslieferung über das Protokoll, zu dem die Branche wechselt. Media over QUIC ist das, was das Konsortium rund um die IETF an die Stelle der Aufteilung «HLS für Skalierung, WebRTC für Latenz» setzt. Die Idee ist, beides zugleich zu haben: Latenz unter einer Sekunde und dabei die gewohnte, cachebare Auslieferung über das Netz statt eines separaten Peer-to-Peer-Pfades je Zuschauer. Catena liefert live über MOQT aus (draft-19, CMAF/CMSF): Der Streamer öffnet einen QUIC-Listener, der Browser kommt über WebTransport und spielt — ohne Plugins und ohne Gateways. Intern wird der Strom nicht in ganze Fragmente zerlegt, sondern in dieselben Teile wie bei LL-HLS, sodass die niedrige Latenz aus der Konstruktion folgt und nicht aus dem Justieren von Puffern. Das ist eine erste Umsetzung und vorerst nur Auslieferung: MoQ-Empfang und Relay-Verteilung über den Cluster sind die nächsten Schritte. Ausprobieren können Sie es auf Ihrem Kanal aber schon heute — aktiviert wird es mit einem Listener in der Streamer-Konfiguration.

RTP-Push und Archivwiedergabe über RTSP. Der MPEG-TS-Push spricht jetzt auch RTP und nicht nur nacktes UDP: Übliche Hardware-Empfänger nehmen genau das an, und verlustbehaftete Netze verlangen es ebenfalls. Getrennt davon gibt es jetzt die Archivausgabe über RTSP mit Range: clock= — die einzige standardisierte Art, wie fremde städtische Videoüberwachungssysteme ein fremdes Archiv lesen. Bisher war eine solche Integration grundsätzlich unmöglich.

Sendungsuntertitel als gewöhnliche Spur. Die im Bild mitreisenden Closed Captions CEA-608/708 werden jetzt in eine WebVTT-Spur verwandelt, die jeder OTT-Player versteht. Der Abonnent sieht in Ihrer App dieselben Untertitel wie der Zuschauer desselben Kanals über Kabel — und die Barrierefreiheitsanforderungen (CVAA in den USA, European Accessibility Act in Europa) werden ohne zweiten Eingang und ohne Handarbeit erfüllt. Mehrsprachigkeit gibt es gratis dazu: Sender legen oft zwei oder drei Sprachdienste in einen Kanal, und jeder wird zu einem eigenen Eintrag im Untertitelmenü. Ausführlich: Closed Captions eines Sendekanals.

Untertitel kommen auf Sendung auf verschiedenen Wegen an, und wir führen sie auf eine Form zurück. Closed Captions CEA-608/708 in den Videoframes funktionieren heute. DVB-Untertitel kommen als Bilder an, der Text muss also erkannt werden — DVB OCR erscheint in der nächsten Version. Der Sinn der ganzen Arbeit ist, dass am Ausgang die Form eine einzige ist: Woher die Untertitel auch kommen, der Zuschauer bekommt eine gewöhnliche WebVTT-Spur, und Sie brauchen weder einen zweiten Eingang noch eine eigene Verarbeitungskette je Sendeformat.

Der Transcoder: dichter und ohne Nahtstellen. Bei MBR wurde ein Eingangsframe so oft decodiert, wie Sie Ausgangsqualitäten hatten: Bei einem FHD/HD/SD-Satz lief der Worker mit 0,7–0,8× Echtzeit, die Live-Kante fiel zurück und die Player pufferten. Jetzt wird der Eingang einmal decodiert, und das decodierte Bild geht an alle Encoder. Es gibt nun die Kodierung auf der Grafikkarte: Bei NVIDIA wandert der gesamte Videopfad — Decodieren, Skalieren, Kodieren — auf die Karte, und die Karte wird explizit oder automatisch gewählt, die am wenigsten ausgelastete. Auch das Rekonfigurieren ist nicht mehr zerstörerisch: Der Transcoder baut sich nicht mehr wegen Rauschens wie der gemessenen Bitrate neu auf, und wenn wirklich rekonfiguriert werden muss — die Quelle hat etwa live die Auflösung gewechselt —, geschieht das ohne verlorene Frames, erzwungenes IDR und DTS-Bruch. Qualitätsleiter, Audioregeln und Presets stehen unter Transcoding und MBR.

Weniger Artefakte für den Zuschauer. Live-DASH fiel wenige Sekunden nach dem Einschalten des Transcoders auseinander: Die Spuren eines Streams wurden auf Rastern geschnitten, die nicht zueinander passten, der Rundungsfehler summierte sich, und die Sendekante wanderte im Sekundenbereich — jetzt sind die Raster aufeinander abgestimmt. In LL-HLS werden Diskontinuitäten einmal nummeriert und nicht nachträglich umnummeriert, sodass hls.js nicht mehr mit discontinuity sequence mismatch abstürzt; die Vorschauspur erzeugt keine falschen Diskontinuitäten mehr, die den Player mit leerem Puffer stehen ließen. Ein Strom, dessen Encoder außerplanmäßige IDRs einfügte, zerfällt nicht mehr in Segmente von 32–64 ms. Ein Wechsel der Programmbeschreibung in der PAT lässt kein halb zusammengesetztes Bild mehr fallen — früher ergab das ein äußerlich gesundes Segment mit einem Loch im GOP, hängende Wiedergabe in Chromium und ein Loch im Archiv für immer. Und die mehrsekündigen Tonaussetzer nach jedem Eingangswechsel sind ebenfalls verschwunden.

Man sieht, was passiert. Das Dashboard beantwortet die Frage «ist alles in Ordnung» mit Kacheln, Zuschauer- und Traffic-Kurven und einer Heatmap der Fehler. Sitzungen sind einzeln sichtbar: nicht «so und so viele Zuschauer», sondern wer genau diesen Stream gerade sieht und wer ihn kürzlich gesehen hat — die Historie geht nicht mehr verloren. Die Quellendiagnose zeigt mehr als «Frames vorhanden oder nicht»: MPEG-TS-Kontinuitätsfehler, Bitratenabfälle, verschwundenen Ton; der Failover kehrt jetzt erst nach einem sauberen Fenster zur bevorzugten Quelle zurück und nicht schon beim ersten Frame. Ist eine DVR-Platte nicht eingehängt oder steckt im Pfad ein Tippfehler, sieht man das in der Oberfläche statt in einer WARN-Zeile im Log. Und wenn ein Streamer gespeicherte Einstellungen nicht angewandt hat, erreicht der Grund jetzt die Konsole — siehe Streamer-Diagnose.

Dreißigtausend Zuschauer von einem einzigen Knoten. Das ist wohl die Zahl dieses Releases. Über Protokolle mit niedriger Latenz — HTTP MPEG-TS, RTSP — stieß Flussonic bei etwa ein- bis zweitausend gleichzeitigen Clients pro Server an die Grenze; darüber begannen Abbrüche. Catena 26.08 hält 30.000 gleichzeitige Zuschauer auf einem Knoten über dieselben Protokolle.

Die Ursache lag in der Sitzungsbuchhaltung. Alle Sitzungen eines Knotens lebten in einer Tabelle unter einem gemeinsamen Lock, und beide heißen Pfade liefen zugleich hinein: Socket-Sitzungen — und genau das sind die Protokolle mit niedriger Latenz — melden übertragene Bytes einmal pro Sekunde je Sitzung, während HTTP-Zuschauer ihren Eintrag bei jeder Segmentanfrage suchen. Bei dreißigtausend Sitzungen ergab das über sechsundzwanzigtausend Lock-Übernahmen pro Sekunde. Dabei leistete das Lock nur etwa 13% der Zeit nützliche Arbeit — das System stand nicht aus Kraftmangel, sondern weil es hinter sich selbst Schlange stand: Die Wartezeit erreichte im Mittel eine Sekunde und im Spitzenwert fast zwölf Sekunden.

Bezahlt hat die Schlange nicht das Monitoring, sondern der Zuschauer. Solange eine Sitzung auf das Lock wartet, leert sie den Frame-Ring nicht, und ein Ring auf einem Live-Stream hält Sekunden — ein Abonnent, der in der Schlange stand, fiel komplett heraus. Auf der Empfangsseite sah das wie Lücken von 700 ms aus, und eine Quelle, die fünfzehn Gigabit ziehen sollte, zog drei. Jetzt sind die Sitzungen in einen spaltenorientierten Speicher mit getrennten Partitionen umgezogen, die Byte-Buchhaltung wurde vor der Änderung durch Tests abgesichert, und die Schlange ist verschwunden — zusammen mit der Decke von fünfzehnhundert Clients.

Die Fortschritte betreffen nicht nur die Auslieferung, sondern auch die Aufzeichnung. Die andere Hälfte derselben Arbeit ist eine dauerhafte Aufzeichnung von 20 Gigabit pro Sekunde und Server. In Kameras übersetzt sind das 10.000 Kameras mittlerer Auflösung auf einer Maschine, die durchgehend aufzeichnen — kein Spitzenwert für eine Vorführung, sondern der Betriebszustand, in dem der Server lebt. Für einen Betreiber ändert das die Projektarithmetik: Wo sich früher für das Archiv ein Rack ansammelte, genügen jetzt einige Maschinen, und der Zustand der Platten und die Belegung des Platzes sind im gesamten Cluster auf einmal sichtbar.

Das Archiv im Cluster. Ein Stream auf einer Edge hat jetzt einen Archiv-Cache — ein eigener Schalter, der keine Aufzeichnung verlangt: Der Origin schreibt das Archiv, während Edges näher an den Zuschauern das vorhalten, was tatsächlich gesehen wird, sodass Lesezugriffe die Platten des Origin kaum noch erreichen. Wie viel der Cache belegt hat und wie hoch die Trefferquote ist, steht im Abschnitt Cluster-DVR, der zugleich die Frage «wo ist der Platz geblieben» bei einer Installation mit Dutzenden Platten beantwortet. Nach Geografie verteilen CDN-Zonen die Zuschauer.

VOD wurde clusterweit. Datei-VOD lebte früher auf Ebene eines einzelnen Knotens: Um ein Asset auszuliefern, musste man wissen, auf welcher Maschine und in welchem Verzeichnis es liegt. Jetzt führt Central den VOD-Katalog für den ganzen Cluster, und Dateien lassen sich direkt aus dem Browser hochladen — ohne Knoten und Platte zu wählen: Das Asset geht auf den Speicher mit dem meisten freien Platz, und die Bytes fließen direkt zum Streamer, an der Steuerungsebene vorbei. Portale, die selbst hochladen, bekommen Upload-Token. Und die zwei Dinge, für die migrierende Kunden früher ihre Inhalte neu packten, funktionieren jetzt unverändert: MBR wird aus Nachbardateien zusammengesetzt, und externe Untertitel werden aus der daneben liegenden Datei übernommen — movie.mp4 und movie.srt spielen ohne Konvertierung.

Watcher zieht auf die Technologie von Catena um

Das Wichtigste zu Watcher in diesem Release ist keine einzelne Funktion, sondern eine Richtung. Watcher hat den Umzug auf denselben Kern begonnen, auf dem Catena aufgebaut ist: Die Medienschicht ist nicht länger Flussonic Media Server, sondern wird Sapsan. In 26.08 ist der erste sichtbare Schritt getan — die Medienschicht hat einen eigenen Namen bekommen: das Paket und das Docker-Image watcher-streamer, hinter dem sich die Engine austauschen lässt, ohne Installationsbefehle, Dokumentation und Ihre Playbooks anzufassen.

Was Ihnen das bringt. Sapsan ist in Rust geschrieben und auf Dichten anderer Größenordnung ausgelegt: Eine dauerhafte Aufzeichnung von 20 Gigabit pro Sekunde und Server sind 10.000 Kameras mittlerer Auflösung auf einer Maschine. Im Zuge des Umzugs erwarten wir eine um ein Vielfaches geringere Ressourcennutzung für dieselbe Installation: weniger Maschinen für dieselbe Kamerazahl, weniger Rack, eine kleinere Rechnung für Strom und Wartung. Dazu alles, was oben im Catena-Abschnitt beschrieben ist — die Zustands-Introspektion und das Cluster-Modell, die die heutige Medienschicht nicht hat.

Der Umzug wird schrittweise verlaufen und für laufende Installationen ohne Überraschungen. Wenn Sie ein Produkt anderer Güte aber früher haben möchten, laden wir Sie in das Early-Adoption-Programm ein: Wir sehen uns Ihre Installation gemeinsam an, planen die Migration und führen sie mit unserer Beteiligung durch.

Das haben wir für Watcher gemacht

Ein Rekorder schweigt nicht mehr, wenn das Archiv nicht geschrieben wird. Das ist das unangenehmste aller Szenarien: In der App sind die Kameras grün, es gibt Livebild, und das Archiv wird seit Tagen nicht geschrieben — Platte, DVR oder Aufzeichnung stehen. Der Kunde erfährt davon in dem Moment, in dem das Archiv gebraucht wird: nach einem Diebstahl, einem Streit oder einem «wer ist hier durchgefahren». Der Unterschied zu «Rekorder offline» ist grundsätzlich: Offline sieht man wenigstens, während «online, aber nichts wird aufgezeichnet» ein falsches Sicherheitsgefühl ist. Watcher achtet jetzt darauf und warnt.

Meldungen über den Ausfall eines Rekorders — und über seine Erholung. Früher erfuhr ein Nutzer vom Ausfall eines Rekorders nur, wenn er die Rekorderliste öffnete. Jetzt erhalten die Administratoren der Organisation einen Push mit dem Grund — das Netz zwischen Cloud und Rekorder ist nicht erreichbar, der Rekorder antwortet nicht mehr über die API — und wenn er wieder hochkommt, folgt eine Erholungsmeldung. Die Zustellmechanik für Push wurde im Backend für alle Benachrichtigungsarten vereinheitlicht: Die Zustellung wird bei Fehlschlag wiederholt, und abgelaufene Abonnements verstopfen die Warteschlange nicht mehr.

Man sieht, wohin das Archiv geht und wie lückenlos es ist. Für jede Kamera am Rekorder sieht man jetzt, wie viel Platz ihr Archiv belegt: Man kann die Aufbewahrung nachjustieren, statt Platten zu kaufen. Und vor allem sieht man den Zustand des Archivs: «wir bewahren 30 Tage» und «in diesen 30 Tagen kamen 25 mit Löchern zusammen» sind zweierlei, und der Unterschied versteckt sich nicht mehr. Es gibt jetzt eine Anzeige der Archivintegrität, und die Archivtiefe wird je Stream einzeln gerechnet.

Die Medienschicht von Watcher hat einen eigenen Namen bekommen. Es gibt jetzt das Paket watcher-streamer und das Docker-Image flussonic/watcher-streamer. Damit sind zwei Dinge erledigt. Erstens: Auf Cluster-Medienknoten, die mit apt install flussonic installiert wurden, war die Admin-Oberfläche des Medienservers offen — sie ist jetzt sowohl in der Paket- als auch in der Docker-Auslieferung geschlossen. Zweitens: Für ein Videoüberwachungssystem ist die Engine ein Implementierungsdetail, und es gibt keinen Grund, sie in Installationsbefehlen und Playbooks laut auszusprechen. Die Medienschicht hat nun einen festen Namen, hinter dem die Engine wechseln kann.

Die erste Installation scheitert nicht mehr, und Upgrades wurden überprüfbar. Die All-in-one-Installation scheiterte schon beim ersten apt install und verlangte, die Installation ein zweites Mal zu starten — reproduzierbar auf sauberem Ubuntu 22.04 und 24.04. Die Ursache ist gefunden und behoben. Getrennt davon haben wir uns die Datenbankmigrationen vorgenommen: Die Kette war auf 193 Revisionen angewachsen, eine Erstinstallation verbrachte darin über vierzig Sekunden, und — am schlimmsten — ein Upgrade mit echten Daten aus alten Versionen wurde durch gar nichts geprüft. Eine saubere Installation kommt jetzt aus einem Schema-Snapshot, und die Migrationen selbst sind durch Tests abgedeckt.

Ressourcen laufen nicht mehr aus, und Listen kriechen nicht mehr. Die Methode für die Stream-Liste ließ in PostgreSQL nicht abgeschlossene Transaktionen zurück: Verbindungen blieben in idle in transaction hängen, Speicher lief aus, die CPU-Last stieg und der Dienst fiel aus — behoben. Getrennt davon haben wir uns die Geschwindigkeit der Oberfläche bei großen Installationen vorgenommen: Ein Kunde mit über 1.100 Kameras konnte die Liste nicht durchblättern, um den Zustand der Kameras an den Vorschaubildern zu prüfen — die Seite reagierte nicht mehr. Kameraliste, Öffnen von Ordnern, Scrollen und Ordnersuche wurden beschleunigt.

Rechte und Konten. Organisationsbenutzern konnte man weniger Rechte geben als gewöhnlichen Benutzern; jetzt funktionieren beide Stellen gleich. An einem Organisationsbenutzer lässt sich eine Notiz hinterlassen, und der Wechsel des Organisationseigentümers sowie die Ausgabe der Organisationen nach Kamerarechten sind repariert.

Der neue Player mit Debug-Panel. Der neue Player hat ein Debug-Panel mit Diagrammen und einer Ereignis-Zeitachse bekommen. Kommt die Beschwerde «es ruckelt», muss man sie nicht mehr auf Treu und Glauben hinnehmen: Man sieht, was mit der Wiedergabe tatsächlich passiert ist.

26.08 ist das letzte Release mit Unterstützung für API v2. Das ist wohl der wichtigste Punkt für alle mit eigenen Integrationen: In der nächsten Version wird v2 abgeschaltet. Der Hinweis wird jetzt direkt in der Oberfläche angezeigt — E-Mail-Aussendungen funktionieren dafür nicht, und uns ist wichtig zu wissen, dass der Administrator ihn gesehen hat.

Die gute Nachricht: Es gibt schon jetzt ein Ziel für den Wechsel — alles, was es in v2 gab, ist bereits in API v3 vorhanden. Es gibt nichts abzuwarten und keine fehlenden Endpunkte zu verhandeln. Wenn Sie eine eigene Integration, ein Abrechnungssystem oder eine mobile App auf v2 haben, schreiben Sie uns: Wir sehen uns Ihre Aufrufe an und helfen, sie auf v3 zu bringen, bevor die Unterstützung endet.

Flussonic Media Server

Dieses Release bringt für Media Server eine einzige Änderung, aber eine nützliche für alle mit vielen Kameras: Entprellen wiederholter Auslösungen des Bewegungsmelders. Eine schlecht konfigurierte Kamera — zu hohe Empfindlichkeit oder eine Zone über schwankenden Ästen — kann ohne Unterlass einen Strom von «Bewegung begonnen»-Ereignissen ausstoßen, und in einer großen Installation begruben solche Kameras zusammen den Verwaltungsserver unter Tausenden Ereignissen und trieben ihn an die CPU-Grenze. Wiederholte Auslösungen werden jetzt zusammengefasst, sodass man die Konfiguration einzelner Kameras in Ruhe angehen kann statt im Feuerwehrmodus.

Und etwas, das man klar sagen sollte: Die Phase der aktiven Weiterentwicklung von Flussonic Media Server ist beendet. Das Produkt bleibt im Support, und wir werden weiterhin minimale Sicherheitsupdates veröffentlichen, aber neue Funktionen wird es darin nicht geben — die gesamte Entwicklung fließt in die Produkte auf dem neuen Kern.

Deshalb laden wir Sie ein, den Wechsel zu planen. Wenn Sie Videoüberwachung betreiben, führt der Weg zu Watcher, der in eben diesem Release begonnen hat, auf denselben Kern umzuziehen; wenn Sie Fernsehen und OTT betreiben, führt er zu Catena, das bereits einen Assistenten für den Konfigurationsimport mit Plan davor und Bericht danach hat. Eine Migration ist mehr als ein Werkzeug, deshalb beteiligen wir uns selbst daran: Erzählen Sie uns von Ihrer Installation, und wir entscheiden gemeinsam, was zuerst umzieht und wie unterwegs die Sendung geprüft wird.