Version 26.09

Flussonic 26.09: DRM und ein eigenes Portal in Catena, SDI, ST 2110 und RIST in Mcaster, und der Watcher-Rekorder wechselt per Knopfdruck auf den neuen Kern

Vier Produkte, ein Kern

Catena, Mcaster, Agora und Watcher sind vier verschiedene Produkte mit vier verschiedenen Kunden: ein OTT-Betreiber, ein Kopfstationstechniker, ein Unternehmen mit eigenem Fernsehen und ein Sicherheitsintegrator. Innen drin steckt derselbe Motor: Sapsan, unser in Rust geschriebener Streaming-Kern.

Deshalb beginnen diese Release Notes beim Kern. Alles aus dem ersten Abschnitt ist in allen vier Produkten gleichzeitig angekommen — und aus demselben Grund sorgt ein Fund auf einem Rekorder mit neuntausend Kameras am Ende dafür, dass ein Fernsehkanal schneller startet.

Das haben wir für den Streaming-Kern Sapsan getan

Sechzigmal mehr WebRTC-Zuschauer. WebRTC war unser schwächster Auslieferungsweg. Ein Knoten hielt 200–300 gleichzeitige WHEP-Sitzungen und etwa 0,9 Gbit/s und nahm danach schlicht keine Zuschauer mehr an: Bei fünfhundert Sitzungen fielen 448 von 500 mit Zeitüberschreitung heraus, während der Prozess 330% der 7200% nutzte, die die Maschine hatte. Es fehlte nicht an Leistung — das gesamte WebRTC-Subsystem war eine einzige Aufgabe, die alle Sitzungen unter einer Sperre durchlief, sodass das Anlegen einer Sitzung hinter der Auslieferung an alle anderen in der Schlange stand.

Jetzt leben die Sitzungen in Shards mit eigenen Schleifen, und die Zahlen haben die Größenordnung gewechselt. Ein Knoten trägt 18.000 gleichzeitige Zuschauer bei 32 Gbit/s oder 16.000 schwerere bei 42,9 Gbit/s — im eingeschwungenen Zustand, ohne Ausfälle. Der Speicher pro Zuschauer sank von 3,8 MB auf 0,6–0,7 MB, und die Warteschlange hat nun eine harte Grenze: Früher belegten sechstausend Zuschauer 53 GB und trieben die Maschine in den Swap.

Ein praktischer Hinweis, falls Sie die eigene Maschine vermessen: Die unter Linux voreingestellte Queueing-Disziplin fq kostet davon rund 8 Gbit/s — der Wechsel auf pfifo_fast holt sie zurück.

Getrennt davon: Verwaiste WHEP-Sitzungen lebten früher ewig. Wer den Tab schloss, hinterließ eine Sitzung, die weiter CPU verbrannte und mit 80 MB/s Speicher fraß, bis der Prozess abgeschossen wurde. Solche Sitzungen werden jetzt selbst eingesammelt.

Über 100 Gbit/s HLS aus einer Maschine. Wir wollten 100 Gbit/s durch die Netzwerkkarte ziehen und haben es geschafft — danach war der PCIe-3.0-Steckplatz des Prüfstands die Grenze, nicht die Software. Über Loopback, ohne Kabel im Weg, lieferte derselbe Server 376 Gbit/s unverschlüsseltes HTTP und 242 Gbit/s über TLS aus. Die praktische Lesart ist nicht die Zahl selbst: Auf gewöhnlicher Hardware ist der Auslieferungsweg nicht das, was Ihnen zuerst ausgeht.

Lesen von fMP4. Ticket #5350 — „Aufnahme von MPEG-DASH-/HLS-fMP4-Quellen“ — wurde im März 2018 angelegt und sammelte rund fünfzig Kundenanfragen, die längste solche Liste in unserem Tracker. Es verlangt eine Sache, nicht zwei: Eine moderne, über Playlist ausgelieferte Quelle legt in ihre Segmente fragmentiertes MP4 und nicht MPEG-TS — und genau fMP4 konnten wir nicht lesen. Jeder Aggregator, jedes fremde CDN und jeder Zulieferer, dem niemand einen UDP- oder SRT-Port öffnet, veröffentlicht CMAF, und bis jetzt hatten wir darauf nichts zu antworten.

Eine Regel bestimmt den Start, und sie sollte man kennen. Die Aufnahme beginnt beim ersten Segment, das nach dem Verbinden erscheint — alles, was schon im Playlist-Fenster lag, ist Geschichte. Sonst kippte eine Quelle mit einem minutenlangen Fenster eine Minute vergangenes Medium in wenigen Sekunden in Ihren Kanal, und zwar bei jedem Neuverbinden erneut. Dieselbe Regel deckt eine tote Quelle ab: Eine Playlist, die eine beendete Ausstrahlung hinterlassen hat, bringt nie ein neues Segment hervor, also startet die Aufnahme schlicht nicht — statt dass der Stream auf einem abgelaufenen Fenster gesund aussieht.

Die Untertitel sind fertig. In 26.08 haben wir Closed Captions nach CEA-608/708 als WebVTT ausgeliefert und die Erkennung von DVB-Untertiteln für die nächste Version versprochen. Hier ist sie — und mit ihr der Teletext, die zweithäufigste Untertitelform im europäischen Rundfunk und die einzige, bei der der Text bereits als Text ankommt.

Das alles folgt jetzt einem einzigen Entwurf: Jeder Texterzeuger — der Teletext-Dekoder, die DVB-Texterkennung, die Closed Captions, die Spracherkennung — schreibt in eine kanonische Schicht, und der Zuschauer erhält immer eine gewöhnliche WebVTT-Spur. Wie es im Kanal auch ankam, der Abonnent in Ihrer Anwendung sieht dasselbe Untertitelmenü wie ein Kabelzuschauer, und Barrierefreiheitsanforderungen werden ohne zweiten Eingang und ohne eigene Kette je Format erfüllt. Nebenbei wurde der Teletext-Dekoder an zwei Stellen repariert, die ihn unbrauchbar machten: eine falsche Bitreihenfolge im Hamming-Code (Seite 888 wurde als 811 gelesen) und fehlende nationale Zeichensätze, die Umlaute und Kyrillisch zu Müll machten.

Hardware-Transkodierung auf NVIDIA. Der gesamte Videoweg — dekodieren, skalieren, kodieren — wandert auf die Karte, explizit oder automatisch gewählt, sodass die Zahl der Kanäle je Server nicht mehr davon abhängt, wie viele CPU-Kerne Sie gekauft haben.

Unterwegs sind wir endlich einem Fehler auf den Grund gegangen, der uns schon zu Flussonic-Zeiten plagte. Er war am Ende nicht unserer: Es ist ein Defekt im Treiber von NVIDIA selbst, und NVIDIA hat ihn als Bug 6610402 aufgenommen. Solange er nicht an der Quelle behoben ist, liefern wir eine Umgehung aus — er erreicht Ihre Installation also nicht mehr.

Ein Verteiler, der die Arbeit übernimmt, die Sie sonst von Hand machen. Zu entscheiden, welcher Knoten welchen Stream führt, muss jemand tun — und jedes Mal neu, wenn eine Maschine dazukommt, geleert, überlastet oder verloren wird. Bei ein paar Servern behält man das im Kopf. Bei hundert nicht mehr, und der Preis eines Fehlers ist ein Kanal, der nicht sendet. Der Verteiler von Catena entscheidet das jetzt nach 129 Regeln, die in einem Regelwerk stehen, bevor sie Code werden, und die Tests werden gegen dasselbe Dokument geprüft.

Was er abdeckt, in den Begriffen des Betreibers. Anforderungen, die eine Platzierung nie verletzen darf: Namensraum, Pflicht-Tags, ein Stream, der eine Grafikkarte braucht, nur auf einen Knoten, der eine hat, ein Stream mit Archiv nur auf einen Knoten mit Archivspeicher, ein Limit an Streams je Knoten. Präferenzen, die Gleichstände auflösen. Neuzuweisung, wenn ein Knoten offline geht, geleert wird oder den Cluster verlässt — während ein absichtlich eingefrorener Knoten genau das behält, was er trägt. Überlast mit festgelegter Entlastungsreihenfolge: Prozessor über 90%, Netz über 95% des Knotenlimits, Archiv über seiner Schwelle; zuerst wird das Netz entlastet, Archivkopien ziehen vor der Aufnahme um, der schwerste Stream zuerst. Und die Rollen jenseits der Aufnahme: Archivkopien, Archivreste auf Maschinen, die den Stream nicht mehr führen, Live-Auslieferung auf Edges, Timeshift-Streams nahe dem Archiv, das sie wiedergeben.

Eine Zahl gehört klar gesagt: Im vergangenen Jahr erwiesen sich 96% der Kundenmeldungen zum Verteiler als Konfigurationsfehler auf Kundenseite und nicht als Defekt des Verteilers. Der Motor war selten das Problem — es fehlte etwas anderes: die Möglichkeit zu sehen, warum er so entschieden hat. Genau diese Hälfte schließt diese Version: Jede Zuweisung trägt jetzt den Grund, aus dem sie getroffen wurde, und die Konsole hat eine Seite mit den Läufen, den Zuweisungen und den Einschränkungen, die nicht erfüllt werden konnten.

Administratoren, Rollen und ein Entzug, der entzieht. Bislang war der Verwaltungszugang ein gemeinsames Passwort und ein statischer Schlüssel: Man konnte keinen zweiten Administrator anlegen, ihn nicht einschränken und einer Person den Zugang nicht abschneiden, ohne allen das Geheimnis zu wechseln. Jetzt gibt es ein richtiges Register von Administratorkonten mit Rollen. Und das Deaktivieren eines Kontos beendet die Arbeit sofort — früher wurde nur die Anmeldung entzogen, während ein bereits ausgestelltes Token noch bis zu fünfzehn Minuten Streams anlegte und Knoten bearbeitete.

Man sieht mehr von dem, was passiert. Die Fehlerkurve eines Streams zerfällt in Linien je Fehlerart, und Ausfälle auf Verbindungsebene — eine abbrechende SRT-Sitzung, eine von einer HLS-Quelle abgelehnte HTTP-Anfrage — werden überhaupt erstmals gezählt, sodass ein vollständiger Quellenausfall endlich in der Kurve sichtbar ist und nicht nur im Log. Nach Retroview gehen nun Qualitätstelemetrie der Quellen, Serverstatistik, Bestand und Auslastung der Grafikkarten sowie Transkoder-Zähler. Weigert sich ein Knoten, die von Ihnen gespeicherte Konfiguration anzuwenden, erreicht der Grund die Konsole, statt im lokalen Log der Maschine zu bleiben. Und auf Installationen mit Dutzenden Festplatten wird der belegte Platz in aktuelles Archiv, verwaiste Aufzeichnungen und den Rest aufgeteilt, sodass „wohin ist der Platz gegangen“ eine Antwort hat.

Das haben wir für Catena getan

DRM, und damit bezahltes Fernsehen. Das ist die größte Lücke, die Betreiber bei Flussonic Media Server gehalten hat. Catena konnte einen geschützten Eingang entschlüsseln, aber nicht schützen, was es auslieferte — und ersetzte Flussonic deshalb auf keinem Bezahlkanal. Jetzt schon. Streams werden mit CMAF cbcs verschlüsselt, und eine verschlüsselte Kopie bedient HLS/fMP4 für FairPlay und DASH für Widevine und PlayReady: Zweimal packen entfällt. Die Schlüssel kommen entweder von Ihrem eigenen Schlüsselserver über SPEKE v1 oder v2 oder zum Ausprobieren aus der Konfiguration.

Der Clusterentwurf zählt hier nicht weniger als die Kryptografie. Verschlüsselt wird am Ausgang des Knotens, der die Quelle aufgenommen hat, nicht beim Schreiben: Das Archiv bleibt unverschlüsselt, sodass Rückspulen, Vorschaubilder, Transkodierung und Analytik weiter funktionieren. Edges erhalten nur den Geheimtext — Schlüssel und Zugangsdaten des Schlüsselservers verlassen den aufnehmenden Knoten nie und tauchen in der Konfiguration eines Edge nicht auf. Und beim Import einer Konfiguration aus Flussonic v3 kommt ein Stream mit drm-Abschnitt deaktiviert an, damit eine Massenmigration nicht stillschweigend anfängt, einen Premiumkanal unverschlüsselt auszustrahlen.

Ein Portal mit echter Programmzeitschrift. Die Zuschaueranwendung von Catena — die, die Ihre Abonnenten am Fernseher oder im Browser öffnen — ist zusammen mit dem Backend, das sie braucht, auf den neuen Kern gezogen. Der Abonnent meldet sich mit seinem eigenen Token an, erhält die Liste der Kanäle, auf die er Anspruch hat, mit fertigen Wiedergabeadressen, und mit der Liste kommt ein Wiedergabeticket: So funktionieren Gerätelimit und Entzug, ohne dass das Portal etwas über interne Schlüssel wissen muss.

Dahinter liegt eine Programmzeitschrift, die es zuvor in keiner Form gab. Central besitzt jetzt die XMLTV-Quellen, lädt sie nach Zeitplan, speichert das Raster und übergibt es sowohl dem Portal als auch dem MPEG-TS-Ausgang als EIT. Zwei praktische Anmerkungen: Der Import filtert die Sendungen auf die Kanäle herunter, die Sie tatsächlich verknüpft haben — die echte Anbieterdatei, gegen die wir getestet haben, enthielt anderthalb Millionen Sendungen auf 4.054 Kanälen, von denen 95% der Zeilen nie jemand liest — und die heruntergeladene Datei bleibt erhalten, sodass das Verknüpfen eines neuen Kanals sofort neu importiert.

Wenn Sie bereits eine Middleware haben. Viele unserer Kunden verkaufen eine eigene, und Catena tritt nicht gegen sie an. In dieser Aufstellung ist Catena das, worauf Ihre Middleware zeigt: eine einzige Wiedergabeadresse, mit im Cluster redundantem Ausgleich — davor steht also kein separater Hardware-Balancer, den man kaufen, ins Rack schrauben und am Leben halten muss. Das Portal oben ist für Betreiber, die noch keine Middleware haben und nicht damit anfangen möchten, eine zu bauen.

Timeshift-Kanäle. „Kanal +2“ als vollwertiger Kanal. Rückspulen gab es schon, aber Rückspulen ist ein Parameter in der URL des Players: Die verschobene Fassung hatte keinen eigenen Namen, keine Zeile in der Kanalliste, keine Sitzungen und keine Statistik und ließ sich weder pushen noch schützen noch einer CDN-Zone zuweisen. Jetzt ist ein Timeshift-Kanal ein gewöhnlicher Stream mit einer ungewöhnlichen Quelle und erbt damit kostenlos seine Zuschauer-URLs, seine Sitzungen, sein DRM und seine Pushes. Eine Aufnahme und ein tiefes Archiv decken Ihre Zeitzonen ab, statt je Zone ein eigenes Regionalsignal zu empfangen.

Die letzten zwei Formatlücken. Catena nimmt DASH-Quellen auf — die andere Hälfte desselben Tickets, auf demselben oben beschriebenen fMP4-Leser. HLS und DASH zusammen decken die CMAF-Origins, die DVB-I-Gateways und die Cloud-Packager ab, die nur eines von beiden veröffentlichen. DASH unterscheidet sich in genau einem, ehrlichen Punkt: Ein Manifest zählt nicht auf, was da ist, sondern gibt eine Startzeit und eine Vorlage, sodass sich aus der Wanduhr errechnet, welches Segment schon verfügbar ist, statt es aus einer Liste zu lesen. Und am Ausgang wird HLS auch im MPEG-TS-Container ausgeliefert, unter eigener Adresse, für ältere Player und Set-Top-Boxen, die nichts anderes annehmen. Zusammen beseitigen sie die letzten beiden Antworten der Art „Flussonic konnte das und Catena nicht“ — am Eingang wie am Ausgang.

VOD ist keine Handarbeit mehr. Ein Cluster-VOD-Katalog konnte eine Datei annehmen und abspielen, aber alles, was eine hochgeladene Datei zu einem Dienst macht — die Qualitätsleiter für MBR, der SMIL-Deskriptor, das Schicksal des Originals — wurde auf jedem Knoten von Hand erledigt. Jetzt hängt eine Transkodierungsvorlage am Asset, der Auftrag entsteht beim Bestätigen des Uploads, Central wählt den ausführenden Knoten, und das Ergebnis kommt als gewöhnliche Datei in den Katalog zurück. Vorlagen, Aufträge und ihr Fortschritt leben in der Konsole und nicht in curl. Und MBR, aus benachbarten Dateien zusammengesetzt, plus externe Untertitel neben dem Video bedeuten, dass ein migrierender Kunde seine Bibliothek nicht neu packen muss.

Aus Edges wurden echte Edges. Ein Edge-Knoten lieferte früher nur Archiv aus: Live und Rückspulen hielt man von ihm fern, weil ein Stream auf einem Edge ewig vom Origin gezogen hätte — ob ihn jemand schaut oder nicht. Beide Gründe sind weg. Streams auf einem Edge werden bei Bedarf hochgefahren, wenn ein Zuschauer kommt, und bei Leerlauf beendet, und die Knoten tauschen Live über unser eigenes internes Protokoll aus, statt auf RTMP oder SRT mit einem zusätzlichen Remux abzufallen. So wandert die gesamte Zuschauerlast, Live eingeschlossen, vom aufnehmenden Knoten auf die Edges.

Was Sie beim Wechsel von Flussonic Media Server zu Catena gewinnen

Catena ist von Anfang an als Cluster gebaut: Sie legen einen Stream an, statt ihm eine Maschine auszusuchen; Archiv und VOD-Katalog gehören dem ganzen Cluster; die gesamte Installation sieht man von einer Stelle aus. Diesen Punkt haben wir in 26.08 ausgeführt, und er gilt weiter. Geändert hat sich in 26.09 etwas anderes: Die Liste dessen, was Flussonic konnte und Catena nicht, ist praktisch leer.

Das haben wir für Mcaster getan

Die Rundfunkeingänge, alle. Mcaster ist die Kopfstation: Das Signal kommt von einem Satellitenempfänger, aus einem Nachbarnetz, von einem Partner oder aus dem eigenen Playout. Diese Version schließt die Eingänge, die nur das Erlang-Flussonic hatte.

SDI von DekTec-Karten läuft als eigener Prozess je Kartenport, der mit dem Streamer über gemeinsamen Speicher spricht: Ein Ausfall auf Treiberebene reißt eine Aufnahme mit, nicht den ganzen Medienserver — was angesichts der Absturzgeschichte von DTAPI keine theoretische Sorge ist. Er deembeddet Mehrkanalton, holt VANC heraus und berechnet ausgerichtete Zeitstempel selbst. Die Konsole zeigt jetzt, welche Karten tatsächlich in der Maschine stecken, wie viele Ports jede hat, in welcher Firmwarevariante sie sind und welche Streams sie schon belegt haben. Das ist kein Schmuck: Auf einer DTA-2178 wird jeder Kanal per Firmware als Ein- oder Ausgang festgelegt, und ein Port, der gerade Ausgang ist, antwortet auf einen Aufnahmeversuch mit „belegt“ — woraufhin der Techniker einen fremden Prozess sucht, den es nicht gibt.

SMPTE ST 2110 wird vollständig empfangen: Video 2110-20, Ton 2110-30 und Hilfsdaten 2110-40, dazu ein NMOS-Knoten, der die Empfänger über IS-04 und IS-05 veröffentlicht, damit ein fremder Controller sie schalten kann. Der Empfang läuft in einem eigenen Systemthread, der Pakete in Bündeln liest: Zeilensprung-HD mit 10 Bit sind 130 MB/s und rund 90.000 Pakete pro Sekunde auf einer einzigen Spur, und das ist keine Arbeit für einen Allzweck-Scheduler. Auch MXL, die EBU-Austauschschicht über gemeinsamen Speicher, wird gelesen — für Installationen, in denen die Nachbarn in der Kette das Signal so übergeben.

RIST kommt als eigene Implementierung: Empfang und Senden, Unicast und Multicast, mit erneuter Übertragung und den Zählern, mit denen sich belegen lässt, dass die Strecke sich benimmt. Der Wert ist eher kaufmännisch als technisch: RIST ist das einzige zuverlässige Übertragungsprotokoll, das ein Branchengremium veröffentlicht hat und kein einzelner Hersteller, deshalb steht es in Ausschreibungen als eigene Anforderungszeile — und auf eine solche Ausschreibung konnten wir bislang überhaupt nicht antworten.

Ein Transportstrom, den man vertraglich übergeben kann. Der ausgehende MPEG-TS war bisher „nimm es oder lass es“: Programmnummer fest auf 1, PIDs automatisch vergeben, gar keine SDT. Jetzt lassen sich PID-Belegung, Programmnummer und Dienstname je Ziel setzen. Der unmittelbare Anlass war ein Kunde, der einen Kanal von uns und von einem Ersatzanbieter bekommt und dessen Umschalter verlangt, dass die PIDs beider Ströme übereinstimmen. Aber dieselbe Kontrolle verlangen auch ein Multiplex, ein IRD, die Überwachung eines NOC oder das technische Pflichtenheft eines Zulieferungsvertrags.

Bedingter Zugriff. Simulcrypt-Verwürfelung am SPTS-Ausgang: ohne Karte kein Bild, mit Karte schon. Konfigurierbar war das nur durch Bearbeiten eines Dokuments von Hand, wo ein falsches Hex-Feld „die Karte ignoriert EMM stillschweigend“ bedeutet und Tage am Prüfstand kostet. Jetzt gibt es dafür ein ordentliches Formular.

Kunden, und was jeder gekauft hat. Danach haben Mcaster-Betreiber am direktesten gefragt. Sie verkaufen keinen Stream, sondern einen Dienst: diesen Kanal, so zugestellt, an dieses Unternehmen. Konfiguration und Überwachung kannten nur Streams, also gab es beim Anruf eines Kunden nichts anzusehen: Was hat er gekauft, welcher Teil davon liegt, und wessen Ausfall ist das.

Jetzt steht der Verkauf dort, wo die Zustellung lebt. Ein Unicast-Push oder ein SRT-Wiedergabeport trägt die Kennung des Kunden, dem er gehört, und ein statisches Token je Stream erlaubt, einem Käufer einmalig einen Link zu geben und seinen Verbrauch ihm zuzurechnen. Multicast-Pushes tragen bewusst keinen Eigentümer: In der Gruppe sind viele Empfänger, geschaltet wird im Netz, und ein einzelnes Feld beschreibt das nicht ehrlich. Darüber liegt die Zustellstatistik je Ziel: Status mit benanntem Fehlergrund, Rate, Bytes, Neuverbindungen, Neuübertragungen. Dabei wurde auch Schlimmeres behoben: Ein scheiternder Push meldete sich manchmal als laufend, mit leerem Fehler und steigendem Neuverbindungszähler, sodass die Konsole dem Betreiber versicherte, die Zustellung lebe, während kein einziges Byte hinausging.

Wer was geändert hat. Central hält den Sollzustand der Installation — Konfiguration von Streams und Knoten, CDN-Zonen, Administratorkonten, Lebenszyklus der Knoten — und hielt bislang nicht fest, wer ihn änderte. Bei mehr als einem Operator im Dienst lässt sich ein Vorfall dadurch gar nicht aufklären: Fragen wie „wer hat diesen Stream gelöscht“ und „wann und von wem wurde dieser Knoten entzogen“ hatten überhaupt keine Antwort. Jetzt haben sie eine: Akteur, Aktion, Zeitpunkt.

Ein eigenes Paket, und ein Cluster, der ein Produkt bleibt. Es gibt jetzt ein Paket mcaster-streamer. Davor existierte genau ein Knotenpaket, nämlich das von Catena, und die Mcaster-Konsole zeigte einen Beitrittsbefehl mit den Pfaden von Catena — wer ihm folgte, installierte einen Knoten des falschen Produkts, ohne dass unterwegs irgendetwas gemeckert hätte. Ein Cluster aus Maschinen zweier Produkte ist nichts Exotisches, sondern ein stiller Störfall, von dem man erst viel später erfährt. Jetzt wird der Beitritt eines fremden Produktknotens mit klarer Begründung abgelehnt.

Was Sie beim Wechsel von Flussonic Media Server zu Mcaster gewinnen

Eine Kopfstation misst man daran, was sie annehmen kann und was sie über das Ausgelieferte belegen kann. Genau dort landet 26.09:

Das haben wir für Agora getan

Agora ist Unternehmensfernsehen: eigene interne Kanäle, für die Ausstrahlung vorbereitete Studiosignale, Betriebsversammlungen und Webinare, den Mitarbeitern über das Firmennetz zugestellt. In 26.09 bekommt es ein eigenes Gesicht auf der gemeinsamen Plattform — eine eigene Konsole, einen eigenen Satz von Bereichen, eine eigene Produktidentität —, während die fachlichen Funktionen in den folgenden Versionen auf den neuen Kern ziehen.

Zwei Stücke der Kernarbeit treffen genau ihren Anwendungsfall.

Auslieferung mit niedriger Latenz, die skaliert. Die oben beschriebene WebRTC-Arbeit ist genau das, was Unternehmensfernsehen braucht: Eine Betriebsversammlung sind einige tausend Menschen, die gleichzeitig dasselbe sehen, mit weniger als einer Sekunde Latenz, innerhalb eines Netzes. Der Sprung von 200–300 gleichzeitigen Sitzungen pro Knoten auf 18.000 verändert, was eine Übertragung an die gesamte Belegschaft an Hardware kostet — von einem Rack auf eine Maschine.

Veröffentlichen über SRT. Ein Studio, ein Besprechungsraum oder ein Laptop mit OBS können jetzt über SRT in den Cluster senden, empfangen auf dem Knoten, den sie anwählen, mit Verschlüsselung und Verlustausgleich am Eingang. Das ist der gewöhnliche Weg, auf dem eine interne Veranstaltung die Plattform erreicht.

Das haben wir für Watcher getan

Der Rekorder wechselt auf den neuen Kern, und ein Techniker ist dafür nicht nötig. In 26.08 bekam die Medienschicht einen eigenen Namen, das Paket watcher-streamer, hinter dem sich der Motor austauschen ließ. Diese Version tauscht ihn aus, und zwar über den einzigen Kanal, den ein Rekorder im Feld wirklich hat: die Update-Schaltfläche in der Cloud.

Bislang bedeutete der Wechsel des Medienservers auf einem Rekorder einen Techniker per SSH, der ein Migrationsskript ausführte, das die Plattenaufteilung auslas, eine Konfiguration erzeugte und den Containerstapel von Hand neu baute. So etwas erreicht die Kiste eines Kunden nie. Jetzt reist der neue Medienserver wie alles andere: Update drücken, der Rekorder holt sich den neuen Stapel, und ein Fehlschlag in einem der Schritte fällt automatisch auf den vorherigen zurück. Die kistenspezifischen Werte, die das schwierig machten — Clusterschlüssel, Zugangsdaten der Verwaltung, Streamername, Plattenaufteilung —, werden jetzt auf der Kiste selbst zusammengesetzt, statt in eine Datei eingebacken zu werden, die der ganzen Flotte über eine öffentliche Adresse ausgeliefert wird.

Was Sie dafür bekommen, ist Dichte. Der neue Kern ist der, der zwanzig Gigabit pro Sekunde und Server aufzeichnet, und im Verlauf der Migration erwarten wir eine mehrfache Senkung des Ressourcenbedarfs für dieselbe Installation: weniger Maschinen für dieselben Kameras, weniger Platz im Rack, eine kleinere Stromrechnung.

Die Kameraaufnahme wurde deutlich zuverlässiger, und wir haben es zufällig gefunden. Auf der Jagd nach Aufzeichnungsverlusten auf einem Rekorder mit zehntausend Streams fiel uns auf, dass einige Fragmente zehnmal kleiner lieferten als die übrigen; wir sahen bei der Kamera nach, und die Kamera war in Ordnung. Das Problem lag darin, wie wir fragmentierte RTP-Pakete auf dem RTSP-Weg zu Bildern zusammensetzten.

Die Messungen sind eindeutig. Bei derselben Kamera und demselben Prüfstand erzeugte der Juli-Build 438.453 kaputte Bilder von 4.600.555 — 9,55%. Nach der Korrektur: 6 Fehler von 272.591 Bildern, 0,002%. Auf dem empfangenden Rekorder, mit 10.000 Streams über eine Stunde, fiel der Medianverlust des Archivs von 15.236 auf 2 Fragmente pro Sekunde, und die Zahl der Streams, die überhaupt etwas verloren, von 2.815 auf 2.

Wenn Sie Kameras über RTSP betreiben — also wenn Sie Kameras betreiben —, ist das die wertvollste Zeile dieser Version.

Die Aufzeichnung wirft keine Daten mehr weg, während Speicher frei ist. Ein geschlossenes Fragment lebte an genau einer Stelle, und das Auslieferungsfenster verdrängte Fragmente nach Stückzahl. Blieb der Schreiber ein paar zurück, war das Datum für immer verloren. Auf einem Rekorder mit neuntausend Kameras waren das 898.501 verlorene Fragmente in zehn Minuten, bei 42 von 125 GB der Maschine ungenutzt. Jetzt haben Auslieferung und Haltbarkeit getrennte Budgets, die Schreibwarteschlange hält eigene Verweise und ist in Bytes begrenzt, und ein Fragment kann nur verloren gehen, wenn der Speicher wirklich ausgeht. Nebenbei senkte allein das Ausrichten der Schreibvorgänge auf 4-KB-Blockgrenzen die Verluste von 5.524 auf 8.

Der Rekorder besitzt seine Kameras. Die Konfiguration glich sich in zwei unsymmetrischen Richtungen ab, und beide taten echten Nutzern weh: Eine auf dem Rekorder angelegte Kamera erschien nicht in der Cloud, bis jemand die Schaltfläche „synchronisieren“ fand, und ein Hintergrundabruf aus der Cloud alle sechzig Sekunden überschrieb lokale Änderungen stillschweigend. Die Architektur ist jetzt klar benannt: Der Rekorder ist die einzige Wahrheitsquelle für die Konfiguration seiner Kameras, die Cloud ist ein nicht zerstörender Spiegel. Solange die Verbindung steht, darf man aus der Cloud bearbeiten; ohne Verbindung nicht — statt Änderungen zu machen, die danach still verschwinden.

API v2 ist abgeschaltet. Wir haben in 26.08 gesagt, dass sie es sein wird, und sie ist es: Die v2-Endpunkte antworten mit einem Hinweis. Da wir wissen, dass einige Abrechnungssysteme noch darauf laufen, bleibt ein Konfigurationsschalter, um sie für den Übergang wieder einzuschalten. Betrachten Sie das als Frist, nicht als Begnadigung.

Alles, was v2 bot, ist bereits in v3. Von denen, die den Umzug versucht haben, haben wir gelernt, dass das Problem nicht ein fehlender Endpunkt ist, sondern eine fehlende Abfolge: Einen Benutzer, eine Organisation und einen Ordner anzulegen ist eine Kette von Aufrufen, in der jede Kennung aus der vorherigen Antwort stammt, und ein ausgelassener Schritt ergibt entweder ein 403 oder einen Abonnenten mit Administratorrechten. Deshalb schreiben wir genau diese Anleitung „so kommen Sie auf v3“ für Abrechnungsintegrationen. Wenn Sie eine eigene Integration auf v2 haben, schreiben Sie uns, und wir sehen Ihre Aufrufe gemeinsam durch.

Der neue Player, und der Rest. Der Player bekam einen Kalender, Qualitätswechsel, Auswahl auf der Zeitleiste mit Export des gewählten Abschnitts, Unterstützung für Mosaike und ein vom Player getrenntes Debug-Panel; auf Rekordern ist er jetzt Standard. Daneben: Die vollständige Organisationsliste eines Benutzers wird ganz statt gekürzt angezeigt, der Dialog mit den Archivinformationen zeigt echte Zahlen, auf der Mosaikseite wurden Seitennavigation und Löschschaltfläche repariert, eine Prognose der Plattennutzung, die Central in Wahrheit nicht berechnen kann, wurde entfernt statt irreführend stehen gelassen, und ein Scheduler, der nach einem Redis-Neustart still alle periodischen Aufgaben einstellte, bemerkt das jetzt und stellt sich selbst wieder her.

Villapass. Das auf Watcher aufgebaute Zutrittsprodukt für Wohnsiedlungen ist in dieser Version erwachsen geworden. Bewohner werden nach Grundstück gruppiert, statt einzeln zu existieren, sodass eine Einschränkung — dieses Grundstück darf keine Gästeausweise ausstellen — dort sitzt, wo sie hingehört. Der Bewohner meldet sich mit Telefonnummer und SMS-Code an, nicht mit einer E-Mail und einem Passwort, die ihm nie jemand gegeben hat. Die Schrankensteuerung meldet zurück: welches Auto durchgefahren ist, wann, in welche Richtung und mit welchem Ausweis — was ein Durchfahrtsjournal erst möglich macht, und dafür gibt es jetzt eine Ansicht mit Suche nach Kennzeichen und nach Ausweis. Der Vorsitzende kann zwischen den eigenen Ausweisen und denen der ganzen Gemeinschaft umschalten, statt immer alle zu sehen. Und die Betreiberverwaltung zeigt endlich, wie es jeder Siedlung geht — Bewohner, Grundstücke, in dieser Woche ausgestellte Ausweise und wie lange der letzte Austausch mit der Schranke her ist — statt einer nackten Namensliste.

Flussonic Media Server

Nichts Neues, und das mit Absicht. Wie wir in 26.08 gesagt haben, ist die Phase der aktiven Entwicklung von Flussonic Media Server beendet: Das Produkt bleibt unterstützt und wir veröffentlichen minimale Sicherheitsupdates, aber die gesamte Entwicklung fließt in die Produkte auf dem neuen Kern.

Diese Version ist ein guter Moment, den Umzug zu planen, denn die Gründe zu warten sind praktisch aufgebraucht. Wenn Sie Fernsehen und OTT machen, ist das Catena — das seit 26.09 DRM, eine Programmzeitschrift, auf Wunsch eine eigene Middleware, Timeshift-Kanäle, fMP4-Aufnahme über HLS und DASH, MPEG-TS-Ausgabe für alte Set-Top-Boxen und ein Werkzeug hat, das Ihr bestehendes Archiv an Ort und Stelle liest. Wenn Sie eine Kopfstation betreiben, ist das Mcaster: SDI, ST 2110, MXL, RIST, volle PSI/SI-Kontrolle und bedingter Zugriff. Wenn Sie Videoüberwachung machen, ist das Watcher, dessen Rekorder in genau dieser Version begonnen haben, auf den neuen Kern zu ziehen.

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 Ausstrahlung geprüft wird.