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
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 depuisreset-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-accettstd-videosont 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/<id>/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 <Stream Designation> — l’opérateur les renseigne lui-même avant l’envoi, afin de ne pas les divulguer à un service IA tiers.
