Stream-Analyse

Der Streamer-Analyzer misst und analysiert verschiedene Parameter des MPEG-TS-Streams, was eine Qualitätsbewertung ermöglicht.

Input speed — Stream-Rate (Bitrate) in kbps. Wird nach der Filterung anhand der PCR-Marken gemessen. Wird als Diagramm dargestellt, das auch die Ausgangsbitrate nach dem Synchronisierer zeigt.

Raw data speed — die Empfangsdatenrate über das gewählte Protokoll. Overhead — der prozentuale Aufschlag für den Protokolloverhead.

CC errors — Paketverluste (CC, Discontinuity). Es werden Intervallzähler sowie ein kumulativer Zähler über die Stream-Uptime angezeigt. Zusätzlich wird eine grafische Historie dargestellt.

Scrambled — Zähler verschlüsselter MPEG-TS-ES-Pakete. Werte ≠ 0 bedeuten Ausfälle beim Entschlüsseln verschlüsselter Kanäle.

Sync by — Synchronisationsquelle — PCR.

PCR interval — Intervall zwischen PCR-Marken. Empfohlen: nicht mehr als 50 ms.

PCR jitter — Maß für die Synchronisationsgenauigkeit des Ausgangsstreams; gemessen als Differenz zwischen PCR und Echtzeit.

Analyze PCR PMT Gap — wird über eine eigene Einstellung aktiviert. Analysiert wird die Abweichung zwischen PCR und PTS/DTS für jeden ES. Die Historie wird grafisch dargestellt. Eine zu große Abweichung kann auf Playern mit kleinem Synchronisationspuffer zu Problemen führen. Die Analyse wird über die Einstellung Analyze PAT/PMT/KF aktiviert.

PAT interval und PMT interval — es wird das Intervall zwischen PAT-(PMT-)Tabellen gemessen. Empfohlen: nicht mehr als 500 ms. Die Analyse wird über die Einstellung Analyze PAT/PMT/KF aktiviert.

Key Frame interval (GOP-Intervall) — das Intervall zwischen Keyframes (GOP-Anfängen). Für Player, die an beliebiger Stelle in den Stream einsteigen, werden maximal 1 s empfohlen. Die Analyse wird über die Einstellung Analyze PAT/PMT/KF aktiviert.

IDR interval — das Intervall zwischen IDR-Frames, die echte Random-Access-Punkte sind (SPS / PPS / IDR). Es wird nur angezeigt, wenn die Quelle mit IDR sendet. Stimmt IDR interval ungefähr mit Key Frame interval überein, hat der Stream closed-GOP: Jeder GOP beginnt mit einem vollständigen Einstiegspunkt, und der Player kann ab jedem Segment starten. Fehlt die Metrik, ist der Stream open-GOP ohne IDR — es gibt Keyframes, sie sind aber keine vollständigen Einstiegspunkte. Aus diesem Verhältnis ist der GOP-Strukturtyp der Quelle sofort ersichtlich. Die Analyse wird über die Einstellung Analyze PAT/PMT/KF aktiviert.

PAT/KF interval — misst das mittlere Intervall zwischen Anfang und Ende der PAT/PMT/SPS/PPS/KF-Sequenz. Davon hängt die Startzeit der Wiedergabe für Player ab, die an beliebiger Stelle in den Stream einsteigen. Gemessen wird ab dem Beginn des KF im Stream; die tatsächliche Startzeit des Players ist daher länger. Die Analyse wird über die Einstellung Analyze PAT/PMT/KF aktiviert.

Aktivieren von Analyze PAT/PMT/KF schaltet den Stream-Analyzer dauerhaft ein, was die CPU-Last erhöht.

Jitter-Steuerung

Für die Jitter-Steuerung gibt es im Stream mehrere Einstellungen:

  • Jitter Compensation Delay (ms) — Funktion zur Kompensation des Netzwerk-Jitters; legt die Buffergröße fest. Ausführliche Beschreibung: https://forum.pstreamer.tv/viewtopic.php?t=25

  • Jitter Auto sync — setzt 2000 ms für TCP-basierte Protokolle (HTTP, HLS); für UDP-Protokolle bleibt der Wert bei 500 ms.

  • Limit PCR gap (ms) — prüft, wie weit der PCR springen darf; bei Überschreitung erfolgt eine Resynchronisation.

Treten nach dem Transkoder PCR Accuracy-Fehler auf, müssen Sie für den codierten Stream über stuffing eine gleichmäßige Bitrate auf folgendem Pfad festlegen: „input — transcoder — Align Total Bitrate“. Die Geschwindigkeit muss garantiert höher als die Bitrate von Video und Audio gewählt werden.

PCR drift

Die Metrik PCR drift misst die systematische Abweichung der Quelltaktfrequenz gegenüber der Echtzeit und wird in ppm (parts-per-million) angegeben. Im Gegensatz zum momentanen PCR jitter, der das Zittern einzelner Zeitstempel erfasst, charakterisiert PCR drift gerade den Langzeit-Drift des Encoder-Quarzes — eine stetige Abweichung, die sich über Minuten und Stunden akkumuliert.

Die Messung erfolgt durch lineare Regression über Paare (kumulierte PCR-Zeit in Sekunden, Empfangszeit in Sekunden). Das Messrauschen sinkt mit wachsendem Fenster wie 1/T^1.5, sodass ein belastbares Urteil nur über lange Intervalle möglich ist. Das Fenster wird automatisch bis auf 300 Sekunden erweitert (Abnahmefenster des Produkts; der Standard TR 101 290 legt das Beobachtungsintervall nicht fest), danach wird eine gleitende Neuverankerung mit einem Limit von 6 Stunden angewendet — dadurch wird ein Präzisionsverlust durch Überlauf der float64-Mantisse ausgeschlossen.

In der XML-Statistik des Streams werden exportiert:

  • pcr-drift-ppm — aktuelles Regressionsurteil;

  • pcr-drift-window-s — Länge des Fensters, über das das Urteil berechnet wurde;

  • pcr-drift-samples — Anzahl der Punkte in der Regression.

Die in ISO/IEC 13818-1 §2.4.2.1 festgelegte Toleranz beträgt ±30 ppm. Bei anhaltender Überschreitung (siehe Abschnitt zu Alarmen unten) wird ein separates Attribut pcr-drift-alert gesetzt, und nach 300 Sekunden ununterbrochener Verletzung — pcr-drift-alert-acceptance (Abnahmestufe; das 300-Sekunden-Fenster ist ein Produktwert, im Sinne der Langzeitmessungen von TR 101 290).

Die Auslagerung von PCR drift in ein eigenes Attribut (statt in das gemeinsame tr101290-alert) ist beabsichtigt: Quarzdrift ist ein Problem des Upstream-Encoders, nicht des Empfängers, und der Betreiber muss es getrennt sehen, nicht mit Transportintegritätsfehlern vermischt.

PCR accuracy

Die Metrik PCR accuracy (Abschnitt P2.3 in TR 101 290) misst die Genauigkeit der Einfügung von PCR-Zeitstempeln in den Transportstrom. Laut Spezifikation muss der Wert jedes PCR mit dem tatsächlichen Zeitpunkt seines Durchgangs durch den Multiplexer mit einer Abweichung von höchstens ±500 ns übereinstimmen.

Die Messung wird als Residual einer linearen Regression auf einem gleitenden Fenster von 30 s ermittelt. Die Fenstergröße ist so gewählt, dass der gesamte PCR-Wiederholzyklus (≤40 ms laut Spezifikation) mit großem Reservepuffer erfasst wird, ohne die schnelle Reaktion auf eine Verschlechterung der Einfügequalität zu opfern.

In der XML-Statistik des Streams wird pcr-accuracy-max-ns exportiert — der Spitzenwert des Residuals über das Fenster. Bei Überschreitung von ±500 ns wird dem gemeinsamen Attribut tr101290-alert das Token pcr-acc hinzugefügt.

Die Messung ist nur für CBR-Multiplexe sinnvoll: bei VBR können die Intervalle zwischen PCR vom errechneten linearen Trend abweichen, ohne den Standard zu verletzen. Der Analysator deaktiviert das Token pcr-acc automatisch für Streams, die als vbr klassifiziert sind (siehe Abschnitt zum Modus-Detektor).

PCR-Drift-Kompensator

Liegt der PCR drift der Quelle innerhalb der ISO/IEC 13818-1-Toleranz, ist er jedoch nicht null, so „läuft“ der Ausgangsstrom langsam gegenüber der Netzwerkzeit des Empfängers weg. Bei einem Player mit kleinem Puffer äußert sich dies als akkumulierender Synchronisationsverlust oder periodische Wiedergaberuckler.

Der Kompensator beseitigt den Drift ohne harte Resynchronisation: ausgehende Pakete erhalten einen Mikroversatz von ~11.1 µs (Dauer eines einzelnen 188-Byte-TS-Pakets bei 100 Mbps), und die Entscheidung „ist ein Versatz nötig“ wird anhand der tatsächlichen Differenz zwischen Netzwerkzeit und PCR-Takt getroffen. Harte Resyncs (Limit PCR gap) bleiben als Fallback für Strom­abbrüche bestehen — der Kompensator arbeitet auf einer feineren Skala und erhält die Kontinuität.

Einstellungen unter stream:

  • Sync Drift Compensation — aktiviert/deaktiviert den Kompensator. Standardmäßig aktiviert.

  • Sync Drift Soft Window — weiches Fenster, innerhalb dessen Korrekturen einzeln angewendet werden (1–60000 ms, Standard 500). Die obere Grenze ist durch 8 × Sync Disc Window begrenzt, ab dem ein harter Resync als fällig betrachtet wird.

In der XML-Statistik wird slew-adjust-count exportiert — der Zähler der Korrekturen seit reset-stat. Ein abrupter Anstieg dieses Zählers bedeutet, dass die Quelle entweder ihren Toleranzbereich verlassen hat oder einen instabilen Quarz besitzt.

T-STD Video-Pufferanalysator

Das T-STD-Modell (Target Decoder) ist in ISO/IEC 13818-1 §2.4.2 beschrieben. Es ist das Referenzmodell des Empfänger-Puffers: wird es eingehalten, ist garantiert, dass der Strom auf jedem konformen Hardware-Decoder wiedergegeben werden kann.

Der Analysator modelliert den MBn-Puffer (Multiplex-Buffer für Video) und prüft, dass:

  • der Puffer nicht überläuft (overflow → der Encoder muss Frames verwerfen);

  • der Puffer nicht leerläuft (underflow → der Decoder zeigt eine Pause oder Artefakte).

Wird durch die Einstellung Analyze T-STD video aktiviert (standardmäßig deaktiviert — verursacht CPU-Last im heißen Verarbeitungspfad).

Unterstützte Video-ES-Typen (stream_type):

  • 0x01 / 0x02 — MPEG-2 video, Kapazität 750 KB;

  • 0x10 — MPEG-4 part 2, Kapazität 750 KB;

  • 0x1B — H.264 / AVC, Kapazität 3 MB;

  • 0x24 / 0x25 — HEVC, Kapazität 3.75 MB.

Die Abflussrate (drain rate) wird adaptiv an die tatsächliche Video-Bitrate angepasst: verwendet wird ein exponentiell gewichteter gleitender Mittelwert (EMA) mit α=0.2 über ein 5-s-Fenster. Ohne Adaption liefert das Modell auf jedem VBR-Video schnell falsche Underflows.

Der Puffer wird nach PCR-Takten (90 kHz) entleert, nicht nach der Hostsystemzeit — dies macht die Analyse robust gegenüber Betriebssystem-Pausen und CPU-Lastschwankungen. Die Host-Echtzeit wird ausschließlich zur Verifikation des Drift-Kompensators verwendet, nicht für T-STD.

In der XML-Statistik werden exportiert:

  • tstd-video-cap — Modellkapazität in Bytes;

  • tstd-video-drain-bps — aktuelle adaptierte Abflussrate, bytes/s;

  • tstd-video-overflows — Überlaufzähler seit reset-stat;

  • tstd-video-underflows — Unterlaufzähler;

  • tstd-video-max-fill — Spitzenfüllung in Bytes.

Bei jedem von Null verschiedenen Zähler (overflows > 0 oder underflows > 0) wird dem gemeinsamen tr101290-alert das Token tstd-video hinzugefügt. Wie bei pcr-acc gilt das Token nur für CBR-Streams — bei einem VBR-Multiplex sind transiente Puffereinbrüche zulässig.

Multiplex-Bitratenmodus-Detektor

Ein Teil der TR 101 290-Tests ist nur im CBR-Modus (konstante Multiplex-Bitrate) sinnvoll. Um keine falschen Alarme an VBR-Kanälen auszulösen, bestimmt der Analysator automatisch den Quellmodus und exportiert das Urteil in das Attribut bitrate-mode-detected.

Algorithmus: Vergleich der mittleren Bitraten über zwei Fenster — 5 s und 60 s. Übersteigt die Abweichung 20 %, wird der Strom als vbr markiert; bleibt sie darunter, als cbr. Bis genügend Statistik akkumuliert ist (~70 s ab Start oder reset-stat), ist das Urteil unknown und die CBR-only Tests (pcr-acc, tstd-video) sind vorübergehend unterdrückt.

Attributwerte:

  • cbr — konstante Bitrate, alle Tests aktiv;

  • vbr — variable Bitrate, pcr-acc und tstd-video sind deaktiviert;

  • unknown — unzureichende Daten, CBR-only Tests sind ausgesetzt.

TR 101 290 Alarme

Das Sammelattribut tr101290-alert vereint mehrere Konformitätsdetektoren nach TR 101 290. Spricht zum aktuellen Zeitpunkt mindestens einer an, enthält das Attribut eine durch Leerzeichen getrennte Token-Liste; spricht keiner an, fehlt das Attribut im XML.

Mögliche Token und ihre Bedeutung:

  • pcr-int — Überschreitung des Intervalls zwischen PCR (Abschnitt 5.2.4 von TR 101 290, Grenzwert 40 ms, Empfehlung ≤25 ms);

  • pcr-acc — Überschreitung der PCR-Einfügegenauigkeit (Abschnitt 5.2.5, ±500 ns, CBR-only);

  • pcr-disc — ein harter Resync über PCR wurde erkannt (Abschnitt 5.2.4, PCR_discontinuity_indicator_error);

  • pat-int — Überschreitung des PAT-Intervalls (Abschnitt 5.1.3, Grenzwert 500 ms, erfordert Analyze PAT/PMT/KF);

  • pmt-int — Überschreitung des PMT-Intervalls (Abschnitt 5.1.5, Grenzwert 500 ms, erfordert Analyze PAT/PMT/KF);

  • tstd-video — ein Über- oder Unterlauf des T-STD-Modells wurde erkannt (Abschnitt 5.3.16, erfordert Analyze T-STD video, CBR-only).

Um ein Flackern der Anzeige bei kurzen Spitzen zu vermeiden, wird eine Debounce-Logik angewendet: ein Token gelangt nur dann in tr101290-alert, wenn es mindestens 30 der letzten 60 Sekunden lang ausgelöst hat. Dies gilt einheitlich für alle Token.

Zusätzlich wird tr101290-alert-acceptance exportiert — eine Kopie des Attributs, in die ein Token erst nach 300 Sekunden ununterbrochener Verletzung gelangt (Abnahmestufe; das Intervall ist ein Produktwert, der Standard TR 101 290 normiert es nicht). Es ist die „endgültige“ Sammelmetrik für die technische Abnahme des Kanals.

Die pcr-drift-Anzeige wird absichtlich in ein eigenes pcr-drift-alert (+ pcr-drift-alert-acceptance) ausgelagert. Quarzdrift ist ein Problem des Upstream-Encoders, sie ist unabhängig von der Transportintegrität und muss separat klassifiziert werden.

KI-Reklamationsassistent

Falls bei einem Kanal TR 101 290- oder PCR drift-Alarme ausgelöst werden, kann der Betreiber mit einem einzigen Befehl einen fertigen englischsprachigen Prompt für einen KI-Chat abrufen, der ein formelles Reklamationsschreiben an den Upstream-Stream-Anbieter formuliert.

Endpoint: GET /data/stream/<id>/ai-complaint-prompt. Verfügbar mit der Rolle Viewer (wie alle GET-Anfragen unter /data/*). Liefert text/plain; charset=utf-8. Für MPTS wird 404 zurückgegeben — die Metriken T-STD / PCR drift sind nur auf SPTS anwendbar.

Der Prompt ist mit jedem modernen KI-Chat kompatibel: „ChatGPT“, „Claude“, „DeepSeek“, „Qwen“, „Doubao“. Der Ton des Schreibens ist sachlich, ohne Anschuldigungen; am Ende des Prompts wird die Sprache des fertigen Dokuments wählbar gemacht: Englisch, Russisch, vereinfachtes Chinesisch oder jede andere nach Wahl des Betreibers.

Inhalt des Prompts:

  • Name und gemessene Parameter des Streams;

  • die Liste aller aktiven TR 101 290- und PCR drift-Token mit den zugehörigen Standardverweisen;

  • Zahlenwerte und Schwellwerte;

  • die Auswirkung jedes Fehlers auf der Decoder-Seite.

Was nicht in den Prompt aufgenommen wird: Streamname, ID, Quell-URI. Diese Felder werden durch den Platzhalter <Stream Designation> ersetzt — der Betreiber trägt sie vor dem Versand selbst ein, damit sie nicht an einen Drittanbieter-KI-Dienst gelangen.