--- title: Analyse des flux url: https://doc.pstreamer.tv/fr/manual/stream_analyze.html lang: fr product: Perfect Streamer version: 1.13.3.445 --- # Analyse des flux L’analyseur de flux du streamer mesure et analyse divers paramètres du flux MPEG-TS, ce qui permet d’en évaluer la qualité. **Input speed** — débit (bitrate) du flux en `kbps`. Mesuré après le filtrage par marques PCR. Affiché sous forme de graphique qui montre aussi le bitrate de sortie après le synchroniseur. **Raw data speed** — le débit de réception des données sur le protocole choisi. **Overhead** — le pourcentage ajouté correspondant à la surcharge du protocole. **CC errors** — pertes de paquets (CC, discontinuité). Des compteurs par intervalle ainsi qu’un compteur cumulé sur le stream uptime sont affichés. Un graphique d’historique est également présenté. **Scrambled** — compteurs des paquets MPEG-TS ES chiffrés. Une valeur ≠ 0 indique des défaillances de décryptage des chaînes cryptées. **Sync by** — source de synchronisation — PCR. **PCR interval** — intervalle entre les marques PCR. Recommandé : pas plus de 50 ms. **PCR jitter** — caractérise la précision de synchronisation du flux de sortie ; mesuré comme l’écart entre le PCR et le temps réel. **Analyze PCR PMT Gap** — activé via un paramètre dédié. L’écart entre PCR et PTS/DTS est analysé pour chaque ES. L’historique est affiché sous forme de graphique. Un écart excessif peut entraîner des problèmes sur les lecteurs disposant d’un faible buffer de synchronisation. L’analyse est activée par le paramètre **Analyze PAT/PMT/KF**. **PAT interval** et **PMT interval** — l’intervalle entre les tables PAT (PMT) est mesuré. Recommandé : pas plus de 500 ms. L’analyse s’active via le réglage **Analyze PAT/PMT/KF**. **Key Frame interval** (intervalle GOP) — l’intervalle entre images clés (débuts de GOP). Pour les lecteurs se branchant aléatoirement sur le flux, il est recommandé de ne pas dépasser 1 s. L’analyse est activée par le paramètre **Analyze PAT/PMT/KF**. **IDR interval** — l’intervalle entre les trames IDR, qui sont de véritables points d’accès aléatoire (*SPS / PPS / IDR*). Il n’est affiché que si la source diffuse avec IDR. Si **IDR interval** correspond approximativement à **Key Frame interval**, le flux est en *closed-GOP* : chaque GOP s’ouvre sur un point d’entrée complet et le lecteur peut démarrer depuis n’importe quel segment. Si la métrique est absente, le flux est en *open-GOP* sans IDR — il y a des images clés, mais ce ne sont pas des points d’entrée complets. Ce rapport rend immédiatement visible le type de structure GOP de la source. L’analyse est activée par le paramètre **Analyze PAT/PMT/KF**. **PAT/KF interval** — mesure l’intervalle moyen entre le début et la fin de la séquence PAT/PMT/SPS/PPS/KF. Il conditionne le temps de démarrage de la lecture pour les lecteurs qui se branchent aléatoirement sur le flux. La mesure est prise au début du KF dans le flux, le temps de démarrage réel du lecteur sera donc plus long. L’analyse est activée par le paramètre **Analyze PAT/PMT/KF**. Activer **Analyze PAT/PMT/KF** lance l’analyseur de flux en continu, ce qui augmente la charge CPU. # Gestion du jitter Plusieurs paramètres du flux permettent de gérer le jitter : - **Jitter Compensation Delay (ms)** — fonction de compensation du jitter réseau ; définit la taille du buffer. Description détaillée : [https://forum.pstreamer.tv/viewtopic.php?t=25](https://forum.pstreamer.tv/viewtopic.php?t=25) - **Jitter Auto sync** — applique 2000 ms pour les protocoles TCP (HTTP, HLS) ; pour les protocoles UDP, la valeur reste à 500 ms. - **Limit PCR gap (ms)** — vérifie le saut maximal du PCR ; au-delà, une resynchronisation est effectuée. Si des erreurs *PCR Accuracy* apparaissent après le transcodeur, il faut définir un débit régulier au moyen du *stuffing* pour le flux encodé en suivant le chemin : « **input** — **transcoder** — **Align Total Bitrate** ». Le débit doit être réglé de manière à être garanti supérieur au débit de la vidéo et de l’audio. # PCR drift La métrique *PCR drift* mesure la dérive systématique de la fréquence d’horloge de la source par rapport au temps réel et s’exprime en *ppm* (parts-per-million). Contrairement au *PCR jitter* instantané, qui capture l’oscillation des estampilles individuelles, *PCR drift* caractérise précisément la dérive long terme du quartz de l’encodeur — un décalage stable qui s’accumule sur des minutes et des heures. La mesure est effectuée par régression linéaire sur les paires (temps *PCR* cumulé en secondes, temps de réception en secondes). Le bruit de mesure décroît en `1/T^1.5` à mesure que la fenêtre grandit, de sorte qu’un verdict fiable n’est possible que sur de longs intervalles. La fenêtre s’étend automatiquement jusqu’à 300 *secondes* (fenêtre d’acceptation du produit ; la norme **TR 101 290** ne fixe pas l’intervalle d’observation), après quoi un ré-ancrage glissant avec une limite de 6 *heures* est appliqué — ceci élimine la perte de précision due au débordement de la mantisse `float64`. Les statistiques **XML** du flux exportent : - `pcr-drift-ppm` — verdict actuel de la régression ; - `pcr-drift-window-s` — longueur de la fenêtre sur laquelle le verdict a été calculé ; - `pcr-drift-samples` — nombre de points dans la régression. La tolérance définie par **ISO/IEC 13818-1** §2.4.2.1 est de ±30 *ppm*. En cas de dépassement soutenu (voir la section sur les alertes ci-dessous), un attribut dédié `pcr-drift-alert` est positionné, et après 300 *secondes* de violation continue — `pcr-drift-alert-acceptance` (niveau d’acceptation ; la fenêtre de 300 secondes est une valeur produit, dans l’esprit des mesures à long terme de **TR 101 290**). L’exposition de *PCR drift* dans un attribut autonome (et non dans le `tr101290-alert` commun) est intentionnelle : la dérive de quartz est un problème d’encodeur en amont, pas du récepteur, et l’opérateur doit la voir séparément, non mélangée aux erreurs d’intégrité du transport. # PCR accuracy La métrique *PCR accuracy* (section P2.3 de **TR 101 290**) mesure la précision de l’insertion des estampilles *PCR* dans le flux de transport. Selon la spécification, la valeur de chaque *PCR* doit correspondre au moment effectif de son passage par le multiplexeur avec une erreur n’excédant pas ±500 *ns*. La mesure est obtenue comme *résidu* (*residual*) d’une régression linéaire sur une fenêtre glissante de 30 *s*. La taille de la fenêtre est choisie pour capturer le cycle de répétition *PCR* complet (≤40 *ms* selon la spécification) avec une large marge, tout en réagissant rapidement à une dégradation de la qualité d’insertion. Les statistiques **XML** du flux exportent `pcr-accuracy-max-ns` — la valeur de crête du résidu sur la fenêtre. En cas de dépassement de ±500 *ns*, le jeton `pcr-acc` est ajouté à l’attribut commun `tr101290-alert`. La mesure n’a de sens que pour les multiplex **CBR** : en **VBR**, les intervalles entre *PCR* peuvent diverger de la tendance linéaire estimée sans enfreindre la norme. L’analyseur désactive automatiquement le jeton `pcr-acc` pour les flux classés *vbr* (voir la section sur le détecteur de mode). # Compensateur de dérive PCR Si la *PCR drift* de la source se situe dans la tolérance **ISO/IEC 13818-1** mais reste non nulle, le flux de sortie « s’éloigne » lentement par rapport au temps réseau du récepteur. Sur un lecteur avec un petit tampon, cela se traduit par une désynchronisation cumulative ou des saccades périodiques à la lecture. Le compensateur élimine la dérive sans resynchronisation brutale : les paquets sortants reçoivent un micro-décalage de ~11.1 *µs* (durée d’un paquet *TS* de 188 octets à 100 *Mbps*), et la décision « un décalage est-il nécessaire » est prise sur la différence effective entre le temps réseau et le rythme *PCR*. Le resync dur (`Limit PCR gap`) demeure en repli pour les ruptures de flux — le compensateur opère à une échelle plus fine et préserve la continuité. Paramètres sous **stream** : - *Sync Drift Compensation* — active/désactive le compensateur. Activé par défaut. - *Sync Drift Soft Window* — fenêtre souple à l’intérieur de laquelle les corrections sont appliquées une par une (1–60000 *ms*, par défaut 500). La borne supérieure est limitée à `8 × Sync Disc Window`, au-delà de laquelle un resync brutal est jugé nécessaire. Les statistiques **XML** exportent `slew-adjust-count` — le compteur des corrections depuis `reset-stat`. Une croissance brutale de ce compteur signifie que la source est sortie de sa tolérance ou possède un quartz instable. # Analyseur de tampon vidéo T-STD Le modèle **T-STD** (*Target Decoder*) est défini dans **ISO/IEC 13818-1** §2.4.2. Il s’agit du modèle de référence du tampon récepteur : s’il est respecté, le flux est garanti d’être lisible par tout décodeur matériel conforme. L’analyseur modélise le tampon `MBn` (multiplex buffer pour la vidéo) et vérifie que : - le tampon ne déborde pas (overflow → l’encodeur est tenu de jeter des trames) ; - le tampon ne se vide pas (underflow → le décodeur affiche un gel ou des artefacts). Activé par le paramètre *Analyze T-STD video* (désactivé par défaut — ajoute une charge CPU dans le chemin de traitement chaud). Types d’ES vidéo pris en charge (`stream_type`) : - `0x01` / `0x02` — MPEG-2 video, capacité 750 *KB* ; - `0x10` — MPEG-4 part 2, capacité 750 *KB* ; - `0x1B` — H.264 / AVC, capacité 3 *MB* ; - `0x24` / `0x25` — HEVC, capacité 3.75 *MB*. Le débit de vidage (*drain rate*) est ajusté de manière adaptative au débit vidéo effectif : on utilise une moyenne mobile à pondération exponentielle (EMA) avec `α=0.2` sur une fenêtre de 5 *s*. Sans adaptation, le modèle produit rapidement de faux underflows sur toute vidéo *VBR*. Le tampon est vidé selon les tops **PCR** (90 *kHz*) et non selon l’heure système de l’hôte — ce qui rend l’analyse robuste face aux pauses de l’OS et aux fluctuations de charge CPU. L’heure réelle de l’hôte n’est utilisée que pour vérifier le compensateur de dérive, jamais pour T-STD. Les statistiques **XML** exportent : - `tstd-video-cap` — capacité du modèle en octets ; - `tstd-video-drain-bps` — débit de vidage adapté courant, *bytes/s* ; - `tstd-video-overflows` — compteur de débordements depuis `reset-stat` ; - `tstd-video-underflows` — compteur de sous-utilisations ; - `tstd-video-max-fill` — remplissage de crête en octets. Pour tout compteur non nul (`overflows > 0` ou `underflows > 0`), le jeton `tstd-video` est ajouté au `tr101290-alert` commun. Comme pour `pcr-acc`, le jeton ne s’applique qu’aux flux **CBR** — pour un multiplex **VBR**, des creux transitoires du tampon sont admis. # Détecteur de mode de débit du multiplex Une partie des tests **TR 101 290** n’a de sens qu’en mode **CBR** (débit de multiplex constant). Afin d’éviter de fausses alertes sur les canaux **VBR**, l’analyseur détermine automatiquement le mode de la source et exporte le verdict dans l’attribut `bitrate-mode-detected`. Algorithme : comparaison des débits moyens sur deux fenêtres — 5 *s* et 60 *s*. Si l’écart dépasse 20 %, le flux est étiqueté `vbr` ; s’il reste en deçà, `cbr`. Tant que la statistique n’est pas constituée (~70 *s* depuis le démarrage ou `reset-stat`), le verdict est `unknown` et les tests réservés au **CBR** (`pcr-acc`, `tstd-video`) sont temporairement supprimés. Valeurs de l’attribut : - `cbr` — débit constant, tous les tests actifs ; - `vbr` — débit variable, `pcr-acc` et `tstd-video` sont désactivés ; - `unknown` — données insuffisantes, les tests réservés au **CBR** sont suspendus. # Alertes TR 101 290 L’attribut agrégé `tr101290-alert` combine plusieurs détecteurs de conformité **TR 101 290**. Si au moins un est actif à l’instant courant, l’attribut contient une liste de jetons séparés par des espaces ; si aucun ne l’est, l’attribut est absent du **XML**. Jetons possibles et leur signification : - `pcr-int` — dépassement de l’intervalle entre *PCR* (section 5.2.4 de **TR 101 290**, limite 40 *ms*, recommandation ≤25 *ms*) ; - `pcr-acc` — précision d’insertion *PCR* dépassée (section 5.2.5, ±500 *ns*, **CBR**-only) ; - `pcr-disc` — un resync brutal sur *PCR* a été détecté (section 5.2.4, `PCR_discontinuity_indicator_error`) ; - `pat-int` — dépassement de l’intervalle *PAT* (section 5.1.3, limite 500 *ms*, requiert *Analyze PAT/PMT/KF*) ; - `pmt-int` — dépassement de l’intervalle *PMT* (section 5.1.5, limite 500 *ms*, requiert *Analyze PAT/PMT/KF*) ; - `tstd-video` — un débordement ou une sous-utilisation du modèle **T-STD** a été détecté (section 5.3.16, requiert *Analyze T-STD video*, **CBR**-only). Pour éviter le scintillement de l’indicateur sur de brèves rafales, une logique de debounce est appliquée : un jeton n’entre dans `tr101290-alert` que s’il s’est déclenché pendant au moins 30 des 60 dernières secondes. Cela s’applique uniformément à tous les jetons. L’attribut `tr101290-alert-acceptance` est également exporté — une copie de l’attribut dans laquelle un jeton n’apparaît qu’après 300 *secondes* de violation continue (niveau d’acceptation ; l’intervalle est une valeur produit, le standard **TR 101 290** ne le normalise pas). C’est la métrique agrégée « finale » pour la recette technique du canal. L’indication `pcr-drift` est délibérément séparée dans son propre `pcr-drift-alert` (+ `pcr-drift-alert-acceptance`). La dérive de quartz est un problème d’encodeur en amont, elle est indépendante de l’intégrité du transport et doit être classifiée séparément. # Assistant IA pour les réclamations Si des alertes *TR 101 290* ou *PCR drift* se déclenchent sur un canal, l’opérateur peut obtenir en une seule commande un prompt anglais prêt à l’emploi pour un chat IA, qui rédigera une lettre de réclamation officielle au fournisseur amont du flux. Endpoint : `GET /data/stream//ai-complaint-prompt`. Disponible avec le rôle *Viewer* (comme toutes les requêtes GET sous `/data/*`). Retourne `text/plain; charset=utf-8`. Pour **MPTS**, un 404 est renvoyé — les métriques *T-STD* / *PCR drift* ne s’appliquent qu’aux **SPTS**. Le prompt est compatible avec tout chat IA moderne : « ChatGPT », « Claude », « DeepSeek », « Qwen », « Doubao ». Le ton de la lettre est professionnel, sans accusations ; la fin du prompt propose un choix de langue pour le document final : anglais, russe, chinois simplifié, ou toute autre langue au choix de l’opérateur. Contenu du prompt : - nom et paramètres mesurés du flux ; - la liste de tous les jetons *TR 101 290* et *PCR drift* actifs avec les références correspondantes du standard ; - valeurs numériques et seuils ; - l’impact de chaque erreur sur le côté décodeur. Ce qui **n’apparaît pas** dans le prompt : le nom du flux, l’ID, l’URI source. Ces champs sont remplacés par le placeholder `` — l’opérateur les renseigne lui-même avant l’envoi, afin de ne pas les divulguer à un service IA tiers.