--- title: Stream-Analyse url: https://doc.pstreamer.tv/de/manual/stream_analyze.html lang: de product: Perfect Streamer version: 1.13.3.445 --- # 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](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//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 `` ersetzt — der Betreiber trägt sie vor dem Versand selbst ein, damit sie nicht an einen Drittanbieter-KI-Dienst gelangen.