Versionsverlauf

Version 2.0.0.206 Beta

25.07.2026

  • Meshwork (Multi-Domain) — mehrere Server werden zu benannten Domains zusammengeschlossen, und die Domain dient als Isolationsgrenze: die Mitgliedschaft der Knoten, der Ressourcenkatalog und die Alerts verbreiten sich nur innerhalb der eigenen Domain, zwischen den Domains wird nichts übertragen. Ein Knoten kann gleichzeitig mehreren Domains angehören, ohne deren Daten zu vermischen. Ausführlich — Meshwork.

  • Automatische Knotenerkennung — es genügt, die Domain und einen einzigen Einstiegspunkt anzugeben: die Knoten tauschen Nachbarlisten aus und bauen selbstständig ein vollvermaschtes Netz direkter Verbindungen auf. Der gemeinsame Domain-Schlüssel wird automatisch erzeugt und ausschließlich über einen geschützten Kanal übertragen — TLS oder ein vertrauenswürdiges Segment des lokalen Netzes.

  • Verteilte Ressourcenbibliothek — die Ausgänge UDP, RTP, Pro-MPEG und RIST, die Multicast-Eingänge UDP, RTP und RIST sowie die PS1- und SRT-Verbindungen werden im gemeinsamen Katalog der Domain (/data/library) veröffentlicht: eine einheitliche Liste der Multicast-Gruppen, Ports, VLANs, SSM-Quellen und Punkt-zu-Punkt-Verbindungen mit Angabe von Knoten und Stream. Am Katalog ist ersichtlich, welche Adressen und Ports bereits belegt sind, und ein neuer Eingang wird direkt daraus angebunden — durch Auswahl eines Streams, der auf einem anderen Knoten der Domain bereits ausgeliefert wird, ohne die Adresse manuell einzugeben.

  • Übersicht der Domain-Knoten — zu jedem Knoten werden Status, Zeitpunkt des letzten Kontakts, Rolle, Region, Build-Version, CPU-Auslastung, Datenverkehr je physischer Schnittstelle und die Anzahl der Streams auf Sendung angezeigt, zu jeder Verbindung zwischen Knoten über PS1 oder SRT — Bitrate, RTT, Anteil der Wiederholungen und Verluste sowie das Zustandsurteil.

  • Betrieb hinter NAT — ein Knoten hinter NAT nimmt vollwertig und ohne Weiterleitung eingehender Ports an der Domain teil: er baut die Verbindung selbst auf, sein öffentlicher Zugangspunkt wird aus der tatsächlich sichtbaren Adresse und dem angekündigten Port abgeleitet, und seinen Zustand geben die Nachbarn einen Hop weiter — der Knoten ist auch für diejenigen sichtbar, die ihn nicht direkt erreichen können.

  • Automatische Anmeldung der Verbindungen innerhalb der Domain — für PS1- und SRT-Verbindungen zwischen Knoten derselben Domain müssen nicht für jede Verbindung Benutzername und Passwort angelegt werden: auf der rufenden Seite (PS1-Eingang, SRT-Eingang, SRT-Ausgang im caller-Modus) genügt es, die Einstellung „Meshwork peer auth“ zu aktivieren, und die Autorisierung erfolgt über das gemeinsame Domain-Geheimnis. Der bestätigte Partnerknoten und dessen Stream sind in der Ressourcenbibliothek und in der Sitzungsliste sichtbar.

  • Low-Latency HLS und MPEG-DASH über CMAF — der neue Auslieferungsmodus „OTT / LL-HLS / DASH“: der integrierte Multiplexer erzeugt fragmentiertes MP4 (CMAF), über das MPEG-DASH unter /dash und Low-Latency HLS unter /llhls ausgeliefert werden; adaptive Bundles werden auch für diese Formate zusammengestellt. Ausführlich — Auslieferungsmodi.

  • Geringe Latenz bei LL-HLS — die Medien-Wiedergabeliste wird in Teile zerlegt, das blockierende Neuladen der Wiedergabeliste und der Preload-Hinweis werden eingesetzt, sodass der Player mit der Wiedergabe beginnt, ohne die Fertigstellung eines vollständigen Segments abzuwarten. Die CMAF-Segmente führen Producer Reference Time mit, das DASH-Manifest kündigt UTCTiming und die Ziellatenz an, und die Einstellung „LL-Part-Zieldauer (ms)“ wird im laufenden Betrieb wirksam, ohne den Stream neu zu starten.

  • HTTP/3 (QUIC) — HLS, MPEG-DASH, LL-HLS und MPEG-TS over HTTP werden über QUIC auf einem separaten UDP-Port ausgeliefert, mit optionalem 0-RTT; den Wechsel zu QUIC fordert der Client mit dem Parameter ?h3 an. Die administrativen Routen bleiben ausschließlich auf TCP.

  • Segmentausrichtung an IDR — der Segmentierer unterscheidet ein IDR- von einem gewöhnlichen I-Frame: bei Quellen mit closed-GOP beginnt jedes Segment mit einem vollwertigen Einstiegspunkt, sodass der Player den Stream an jedem beliebigen Segment öffnet; bei Quellen mit open-GOP dient das nächstgelegene I-Frame als Grenze.

  • Inhaltsschutz (DRM) — die OTT-Auslieferung eines Streams kann verschlüsselt werden: HLS AES-128 mit einem Schlüssel vom Server selbst oder von einem externen Key-Server und mit optionaler Rotation nach Zeitfenstern, oder MPEG Common Encryption (ISO/IEC 23001-7) nach den Schemata cenc und cbcs für CMAF und DASH. Die Verschlüsselung erfolgt einmalig, im Moment der Segmentbildung, daher wird das DVR-Archiv verschlüsselt gespeichert und über beliebig viele Schlüsselwechsel hinweg wiedergegeben. Ausführlich — Inhaltsschutz (DRM).

  • DVR (Netzwerkarchiv) — jeder OTT-Kanal wird parallel zur Auslieferung auf die Festplatte geschrieben, mit derselben Segmentierung und ohne separaten Rekorder; im Modus geringer Latenz wird das Archiv in zwei Linien geführt, MPEG-TS und CMAF, sodass die Aufzeichnung im selben Container wie die Live-Ausstrahlung verfügbar ist. Ausführlich — DVR.

  • Archivwiedergabe (VOD) — das Archiv wird über dieselben HLS-, DASH- und LL-HLS-URL ausgeliefert wie die Live-Ausstrahlung: t=<Zeit> schaltet den VOD-Modus ein und legt den Beginn des Fensters fest, d=<Sekunden> dessen Dauer. Die HLS-Wiedergabeliste ist dabei geschlossen, das DASH-Manifest statisch, Aufzeichnungslücken werden als separate Perioden ausgewiesen; adaptive Bundles geben das Archiv mit denselben Parametern wieder.

  • Catch-up über EPG — statt t und d genügt es, epg=<Zeit> zu übergeben: der Server findet auf dem verknüpften EPG-Kanal selbst die zu diesem Zeitpunkt laufende Sendung und übernimmt deren Beginn und Dauer als Grenzen des Wiedergabefensters.

  • Untertitel im Archiv — WebVTT-Spuren werden zusammen mit den Segmenten auf die Festplatte geschrieben und in VOD über dieselben URL wiedergegeben; Fenster ohne Untertitelzeilen belegen keinen Speicherplatz auf der Festplatte.

  • DVR-Speicher — es kann mehrere Speicher geben, jeder mit einer eigenen Füllgrenze und einer eigenen Bereinigungsreihenfolge. Die Archivtiefe („Aufbewahrung (Stunden)“, bis zu 90 Tage) und das geschützte Minimum werden für jeden Stream separat festgelegt, und die Bereinigung nach freiem Speicherplatz rührt weder das geschützte Minimum noch die Fenster offener VOD-Sitzungen an.

  • DVR-Monitor — ein separater Bildschirm zeigt Zustand und Füllung der Speicher, Umfang und Tiefe des Archivs je Stream sowie die Lese- und Schreiblatenzen, und das Abdeckungshistogramm (/data/dvrstat) markiert nicht nur die Lücken im Archiv, sondern auch deren Ursache — Abriss des Eingangs, PMT-Wechsel, Verwürfelung, Auslösen der Bereinigung. Von hier aus werden auch das Archiv eines einzelnen Streams und die Verzeichnisse gelöschter Streams entfernt.

  • Alerter — der neue Benachrichtigungsdienst: jede Störung wird zu einem Vorfall, der automatisch ausgelöst, aktualisiert und behoben wird, und der deduplizierte aktive Satz zeigt nur das, was gerade geschieht. Der Schweregrad wird über eine einheitliche Skala festgelegt — von rein informativ bis hin zu „erfordert einen Administrator-Eingriff“; ein solcher Vorfall wird durch die Bestätigung des Bedieners behoben. Ausführlich — Benachrichtigungen (Alerter).

  • Katalog der Alert-Codes — mehr als fünfzig Vorfalltypen in einer einzigen Liste: Streams samt ihren Eingängen und Ausgängen, Verstöße gegen TR 101 290, Ressourcen des Knotens, DVR-Speicher und Zustand der Aufnahme, DVB- und CI/CAM-Empfang, Transcoder, OTT, Zertifikate und Knoten der Domain. Die Auslöseschwellen werden im Benachrichtigungsbereich konfiguriert.

  • Externe Zustellung von Benachrichtigungen — die Alerts verlassen die Web-Konsole: per E-Mail über SMTP (STARTTLS, implicit TLS, AUTH), per Nachricht an Telegram und durch den Start eines beliebigen Befehls, dem der Vorfall über Umgebungsvariablen und als vollständiges JSON auf der Standardeingabe übergeben wird. Jeder Kanal hat einen eigenen Schalter und einen eigenen Schweregrad-Schwellenwert.

  • Alerts der gesamten Domain — der Diensthabende sieht die Alerts jedes Knotens von jedem anderen aus: der aktive Satz wird zusammen mit dem Keep-alive repliziert und wird sofort behoben, sobald er an der Quelle verschwunden ist, und in jeder Zeile ist der Ursprungsknoten angegeben. Hardware- und System-Alerts bleiben standardmäßig lokal und werden über eine separate Einstellung auf die Domänenebene angehoben.

  • Protokoll in der Datenbank — die Meldungen des Dienstes werden in SQLite geschrieben: typisierte Einträge mit Quelle und Schweregrad, Zusammenfassung aufeinanderfolgender Wiederholungen zu einer Zeile mit Zähler, Begrenzung der Aufbewahrung nach Dauer und nach Umfang. Im Unterschied zum aktiven Alert-Satz übersteht das Protokoll einen Neustart.

  • TR 101 290-Monitor — die fortlaufende Kontrolle der Konformität des Eingangsstreams mit dem Standard: ein einziges Urteil („Gut“, „Schlecht“, „Prüfung läuft…“) und ein strukturierter Bericht nach den Prioritäten 1, 2 und 3, in dem für jeden Indikator der Abschnitt des Standards, der gemessene Wert und der Grenzwert angegeben sind. Ein MPTS-Multiplex wird als Ganzes bewertet — über alle PID, Programme und SI-Tabellen. Der Stream wird automatisch als CBR oder VBR klassifiziert, und die Prüfungen, die nur bei konstanter Bitrate sinnvoll sind, werden auf einer VBR-Quelle nicht bewertet und erzeugen keine Fehlauslösungen. Ausführlich — TR 101 290-Monitor.

  • Drift des Referenzoszillators — das systematische Weglaufen der Taktfrequenz der Quelle wird durch lineare Regression in ppm bei einer Toleranz von ±30 ppm nach ISO/IEC 13818-1 gemessen und als separate Metrik ausgegeben. Ein langsames Weglaufen wird durch sanfte Mikroverschiebungen des Synchronisationspunkts ausgeglichen („Sync-Drift-Kompensation“, standardmäßig aktiviert), sodass es am Ausgang keine Sprünge gibt.

  • T-STD-Puffermodell — die Analyse des Videopuffers des Referenzdecoders nach ISO/IEC 13818-1 mit Zählern für Überläufe und Unterläufe für MPEG-2, H.264 und HEVC; die Zeitrechnung erfolgt nach der PCR-Uhr, und die Entleerungsrate richtet sich nach der tatsächlichen Videobitrate. Wird über die Einstellung „T-STD-Videopuffer analysieren“ aktiviert.

  • Analyse für die Werbeeinblendung — die Auswertung von SCTE-35-Sektionen mit Splice-Ereignissen, Splice-Punkte auf Transportebene mit konfigurierbarer Vorabbenachrichtigung sowie Random-Access-Marken. Die Daten werden bei aktivierter Tiefenanalyse in der Stream-Statistik ausgegeben.

  • Reklamationsassistent — für einen Stream mit anhaltenden Verstößen wird ein fertiger Aufgabentext für einen KI-Chat erzeugt, aus dem dieser ein förmliches Reklamationsschreiben an den Anbieter des Streams verfasst: die Liste der anhaltenden Verstöße, die gemessenen Werte, die Abschnitte des Standards und die Auswirkung auf den Decoder. Der Aufgabentext wird über die Anfrage GET /data/stream/<id>/ai-complaint-prompt ausgeliefert; der Name des Streams und die Adresse der Quelle werden nicht in den Text aufgenommen.

  • CI/CAM (EN 50221) — ein integrierter Common-Interface-Host: Erkennung des Moduls, Auslesen seines Namens und der Liste der unterstützten CA_system_id, Auswahl der zu entschlüsselnden Programme und Übergabe der CA_PMT für jedes von ihnen. Ein mit dem DVB-Empfänger kombiniertes Modul entschlüsselt die ausgewählten Programme des empfangenen Multiplexes inline, mehrere gleichzeitig; der Zustand der Slots und das Urteil zu jedem Programm sind in der Oberfläche sichtbar.

  • Software-Entschlüssler BISS-1 / BISS-E — wird nicht nur auf den Empfang von einer DVB-Karte angewendet, sondern auf jeden Stream-Eingang: der Schlüssel wird für das gesamte SPTS oder je Programm des Multiplexes festgelegt und im laufenden Betrieb geändert, ohne den Eingang neu zu starten. Beim Empfang von einer DVB-Karte wird das Ergebnis zusätzlich anhand des Streams selbst geprüft, sodass ein falscher Schlüssel nicht wie eine erfolgreiche Entschlüsselung aussieht, sondern einen eigenen Alert auslöst.

  • Bereinigung des bedingten Zugriffs beim DVB-Empfang — aus einem von einer DVB-Karte empfangenen Multiplex werden über eine separate Adaptereinstellung die ECM- und EMM-PID entfernt und aus der PMT die CA-Deskriptoren der offenen Programme: weiter im Signalweg läuft ein sauberer FTA-Stream. Bei Verlust des Schlüssels kehrt die Signalisierung des bedingten Zugriffs zurück, damit ein weiter unten in der Kette liegender Empfänger den Zugriff erneut anfordern kann.

  • Transcoder-Telemetrie — zu jedem Encoder werden die Medieninformationen des transcodierten Ausgangs veröffentlicht: Bildformat, Videocodec, Satz der Audiocodecs und aktuelle Bitrate, und zu jedem Prozess — CPU-Auslastung und belegter Speicher.

  • RTMP und RTMPS — ein Kanal wird an einen beliebigen RTMP-Empfänger veröffentlicht, einschließlich YouTube und Facebook: Video in H.264 oder HEVC (HEVC — über Enhanced RTMP) und eine AAC-Spur; für rtmps:// verbindet sich der Knoten als TLS-Client. In der Gegenrichtung holt der Eingang den Stream selbst von einer Quelle rtmp:// oder rtmps:// und remultiplexiert FLV nach MPEG-TS.

  • Nahtlose Quellenumschaltung — beim Wechsel des aktiven Eingangs am Sender verbinden sich die empfangenden PS1-Peers nicht neu: Nummerierung und Zeitstempel bleiben durchgängig, ein Warteschlangenstoß wird durch das Verwerfen der ältesten Pakete abgefangen, und die Lücke wird durch die reguläre Retransmission nachgeholt.

  • Adaptive PS1-Retransmission — der Empfänger misst die tatsächliche RTT zum Sender und passt die Intervalle der Wiederholungsanfragen selbst daran an; die gemessene RTT, das aktuelle Intervall der erneuten Anfrage und das Merkmal einer zu geringen Latenz werden in der Verbindungsstatistik ausgegeben. Die Latenz des Empfangstunnels wird direkt in Millisekunden festgelegt statt wie bisher als Vielfaches der RTT.

  • Die Zustände „Verbindung wird wiederhergestellt“ und „Admin-Aktion“ — ein Eingang oder Ausgang, der seine Quelle verloren hat, wird an Ort und Stelle wieder geöffnet und bleibt für die gesamte Dauer der Versuche im Zustand „Verbindung wird wiederhergestellt“, wobei er eine Warnung je Episode auslöst statt einer Meldung bei jedem Versuch. Eine Ursache, die sich durch Wiederholung nicht beheben lässt — ein belegter Port, eine fehlende Schnittstelle, Daten, die kein MPEG-TS sind, ein SRT-Fehlschlag bei der Verschlüsselung —, versetzt der Knoten in den Zustand „Admin-Aktion“ mit einem haftenden Alert, während eine Änderung der Einstellungen sofort wirksam wird.

  • MPTS-Multiplexer: ursprüngliche Identität — die Programme können ihre ursprünglichen PID behalten, und die Reihenfolge der Programme in PAT, SDT und NIT wird manuell festgelegt, sodass ein Multiplex ohne Änderung der Stream-Identität für die Empfangsgeräte auf Perfect Streamer migriert wird. Programme mit TS-Verwürfelung werden mit ihren ursprünglichen Zeitstempeln übernommen.

  • Integration mit externem Billing — jede Zuschauersitzung wird in einem externen Billing- oder CRM-System autorisiert, durch periodische Re-Autorisierung gehalten und nach ihrem Ende demselben System gemeldet: ein Lebenszyklus Start / Interim / Stop im RADIUS-Stil, ein Widerruf des Abonnements bricht die Sitzung mitten im Betrachten ab. Erfasst sind OTT, das PS1-Peering und die SRT-Ausgänge, und das Billing-System selbst wird über Vorlagen für die Anfrage und die Auswertung der Antwort angebunden, ohne Anpassung der Software.

  • Integrierter ACME-Client (Let’s Encrypt) — Ausstellung und automatische Verlängerung der Zertifikate für den Webserver, den HTTP/OTT-Server und den EPG-Server: ein Zertifikat wird für jeden konfigurierten Hostnamen bestellt, die Verlängerung wird täglich geprüft, bei einem Fehlschlag wird ein Alert ausgelöst. Unterstützt werden eine beliebige Zertifizierungsstelle und die externe Kontobindung, und ein neues Zertifikat wird ohne Neustart des Dienstes wirksam.

  • Neue Weboberfläche — die Verwaltung des Knotens wurde auf eine neue Konsole umgestellt, die unter der Adresse des Knotens geöffnet wird (Pfad /admin): Übersicht, Streams, Systemüberwachung, DVB, DVR, Transcoder, Clients, Protokoll, Alerts und alle Servereinstellungen. Eigene Diagramme zeigen die Topologie der Meshwork-Domain und den Signalweg des ausgewählten Streams von den Eingängen bis zu den Ausgängen. Die frühere Oberfläche bleibt unter /classic erhalten. Ausführlich — Weboberfläche.

  • Aktualisierung in Echtzeit — der Knoten liefert seinen Zustand als Ereignisstrom unter /data/events: beim Verbinden trifft eine vollständige Momentaufnahme ein, danach werden im Sekundentakt die Frames der Streams, der Systemressourcen, der Clients und der DVB-Adapter aktualisiert, während Alerts und Zustandswechsel als Ereignisse eintreffen. Die Oberfläche und externe Dashboards arbeiten ohne periodische Abfrage.

  • Kontextbezogene Hilfe — jeder Bildschirm und jedes wichtige Fenster der neuen Oberfläche verfügt über einen Hilfeaufruf, der genau den Dokumentationsabschnitt zu dem öffnet, was gerade geöffnet ist: die allgemeine Hilfeschaltfläche für den Bildschirm, die Schaltfläche „?“ in der Fensterkopfzeile für dieses Fenster. Der Abschnitt wird in der Sprache der Oberfläche geöffnet.

  • Sprachen, Designs und Layouts — die Oberfläche ist in sechs Sprachen übersetzt (Russisch, Englisch, Deutsch, Französisch, Spanisch, Portugiesisch), unterstützt ein helles und ein dunkles Design und passt die Layoutdichte selbst an Telefon, Tablet, Arbeitsplatzrechner und Videowand an.

  • Weitere Verbesserungen und Fehlerbehebungen.