Historique des versions

version 2.0.2.362 Beta

06.09.2026

• Menu du module CI — le menu propre du module est lu : état de la carte, abonnements, numéro de série, saisie du PIN et entrées de service sont accessibles directement depuis l’écran matériel — la même chose que le module afficherait sur l’écran d’un téléviseur. La carte d’identité du module y est apparue également — fabricant, code produit et type d’application EN 50221 — et le nœud décode son nom, si bien que les noms cyrilliques n’arrivent plus déformés (Menu du module).

• Désembrouillage par un module CI distinct — un module logé dans un lecteur de cartes autonome dessert n’importe quelle entrée d’un flux, et pas seulement la réception depuis une carte DVB : tout le transport de l’entrée le traverse, tandis que la liste des programmes indique seulement lesquels désembrouiller. Le slot est attribué sur l’entrée elle-même, et c’est là aussi que l’on voit quelle entrée l’occupe (CI/CAM sur une entrée de flux).

• Plusieurs slots CI sur une même entrée — un multiplex est conduit successivement à travers plusieurs modules, avec son propre jeu de programmes pour chaque slot. La fréquence d’horloge du bus CI est choisie d’après le débit réel de l’entrée, et un slot resté occupé se libère sur demande depuis l’écran du matériel.

• Tables de service lors du démultiplexage — les tables de réseau et d’heure ainsi que les autres PID de service du multiplex d’origine obéissent désormais aux mêmes clés mpegts-filter-nit, mpegts-filter-tdt, mpegts-filter-unnecessary et mpegts-filter-cat que sur les autres chemins, au lieu d’être écartées sans condition. La valeur par défaut a changé du même coup : un flux extrait d’un multiplex porte les tables de réseau et d’heure qu’il ne portait pas auparavant — un récepteur situé derrière un tel flux, et un module CI en premier lieu, s’attend à les voir. Le comportement antérieur se rétablit avec mpegts-filter-nit.

• Une discontinuité PCR ne vide plus le tampon de gigue — une entrée ayant capté un saut de PCR en avant déplace le point de synchronisation à la volée, sans purger la file ; la discontinuité coûte donc un seul accroc au lieu d’un remplissage du tampon. La fenêtre au-delà de laquelle un saut compte comme une discontinuité est choisie automatiquement (Synchronisation).

• Démarrage rapide d’une entrée HLS — une playlist en direct est reprise par la fin : seuls les derniers segments nécessaires à la gigue configurée entrent dans la file, et non toute la fenêtre ; l’entrée passe donc à l’antenne avec un retard de quelques segments au lieu d’une fenêtre de playlist entière. Une playlist achevée (VOD) est toujours lue depuis le début.

• Suppression du battement des alertes — une alerte déclenchée et résolue encore et encore est repliée en un incident unique : le nœud la maintient pendant l’accalmie et ne la ferme que lorsque le battement a réellement cessé. Une tempête de répétitions ne se répand ni dans le journal ni par les canaux externes. Une source de battement une fois identifiée le reste après l’accalmie : sa série suivante est maintenue dès la première répétition.

• Modification d’une chaîne EPG — une chaîne reçoit un identifiant XMLTV distinct du nom affiché ainsi que des libellés par langue, et une chaîne devenue inutile se supprime entièrement : ses libellés, ses événements et son appartenance à des ensembles disparaissent avec elle.

• Autres améliorations et corrections de bogues.

version 2.0.2.335 Beta

27.08.2026

• Meshwork (multidomaine) — plusieurs serveurs sont regroupés en domaines nommés, et le domaine sert de frontière d’isolation : l’appartenance des nœuds, le catalogue des ressources et les alertes ne se propagent qu’à l’intérieur de leur propre domaine, rien n’est transmis entre les domaines. Un nœud peut appartenir à plusieurs domaines à la fois sans mélanger leurs données. Pour plus de détails — Meshwork.

• Découverte automatique des nœuds — il suffit de définir le domaine et un seul point d’entrée : les nœuds échangent des listes de voisins et construisent d’eux-mêmes un réseau maillé complet de liaisons directes. La clé de domaine commune est produite automatiquement et n’est transmise que par un canal protégé — TLS ou un segment de réseau local de confiance.

• Bibliothèque de ressources répartie — les sorties UDP, RTP, Pro-MPEG et RIST, les entrées multicast UDP, RTP et RIST, ainsi que les liaisons PS1 et SRT sont publiées dans le catalogue commun du domaine (/data/library) : une liste unique des groupes multicast, des ports, des VLAN, des sources SSM et des liaisons point-à-point, avec indication du nœud et du flux. Le catalogue montre quelles adresses et quels ports sont déjà occupés, et une nouvelle entrée s’y raccorde directement — en choisissant un flux déjà diffusé sur un autre nœud du domaine, sans saisir l’adresse à la main.

• Aperçu des nœuds du domaine — pour chaque nœud sont affichés l’état, l’heure du dernier contact, le rôle, la région, la version du build, le temps de fonctionnement depuis le démarrage, la charge CPU, le trafic par interface physique et le nombre de flux à l’antenne ; pour chaque liaison inter-nœuds PS1 ou SRT — le débit, le RTT, la part de retransmissions et de pertes et un verdict sur son état. Un nœud tombé ne disparaît pas de la liste : il y reste sept jours comme injoignable, avec son alerte, et un nœud mis hors service est retiré de l’aperçu par une commande dédiée.

• Fonctionnement derrière un NAT — un nœud placé derrière un NAT participe pleinement au domaine et sans redirection des ports entrants : il se connecte lui-même, son point d’accès public est reconstitué à partir de l’adresse effectivement observée et du port annoncé, et son état est relayé par les voisins sur un saut — le nœud est visible même pour ceux qui ne peuvent pas s’adresser à lui directement.

• Nom du nœud issu du certificat — un nœud dont le nom d’hôte n’est pas défini annonce à ses pairs le nom couvert par son propre certificat, et seulement après que ce nom se résout à nouveau vers lui ; le résultat du contrôle est visible dans les données du serveur sous cert-host et cert-host-refused.

• Connexion automatique des liaisons à l’intérieur du domaine — les liaisons PS1 et SRT entre nœuds d’un même domaine ne demandent pas de créer un identifiant et un mot de passe pour chaque liaison : du côté appelant (entrée PS1, entrée SRT, sortie SRT en mode caller), il suffit d’activer le paramètre « Meshwork peer auth » et l’autorisation s’effectue au moyen du secret de domaine commun. Le nœud partenaire confirmé et son flux apparaissent dans la bibliothèque de ressources et dans la liste des sessions.

• Low-Latency HLS et MPEG-DASH sur CMAF — nouveau mode de diffusion « OTT / LL-HLS / DASH » : le multiplexeur intégré produit du MP4 fragmenté (CMAF), au-dessus duquel MPEG-DASH est servi sur /dash et Low-Latency HLS sur /llhls ; les ensembles adaptatifs sont également constitués pour ces formats. Pour plus de détails — Modes de diffusion.

• Faible latence LL-HLS — la playlist média est découpée en parts, le rechargement bloquant de la playlist et l’indication de préchargement sont mis en œuvre, de sorte que le lecteur démarre la lecture sans attendre qu’un segment complet soit prêt. Les segments CMAF portent le Producer Reference Time, le manifeste DASH annonce UTCTiming et la latence cible, et le paramètre « Durée cible de la part LL (ms) » est appliqué à chaud, sans redémarrer le flux.

• HTTP/3 (QUIC) — HLS, MPEG-DASH, LL-HLS et MPEG-TS over HTTP sont diffusés sur QUIC sur un port UDP dédié, avec 0-RTT facultatif ; le client demande le passage à QUIC par le paramètre ?h3. QUIC ne fonctionne que sur TLS : TLS désactivé, l’écouteur n’est pas ouvert ni proposé au client, et son état réel est visible dans les données du serveur HTTP et non seulement dans le paramètre. Les routes d’administration restent uniquement en TCP.

• Alignement des segments sur les IDR — le segmenteur distingue une image IDR d’une image I ordinaire : sur les sources à closed-GOP, chaque segment commence par un point d’entrée complet, ce qui permet au lecteur d’ouvrir le flux sur n’importe quel segment ; sur les sources à open-GOP, la frontière est l’image I la plus proche.

• Protection du contenu (DRM) — la diffusion OTT d’un flux peut être chiffrée : HLS AES-128 avec une clé fournie par le serveur lui-même ou par un serveur de clés externe et avec une rotation facultative par fenêtres temporelles, ou bien MPEG Common Encryption (ISO/IEC 23001-7) selon les schémas cenc et cbcs pour CMAF et DASH. Le chiffrement est effectué une seule fois, au moment de la formation du segment, si bien que l’archive DVR est conservée chiffrée et survit à un nombre quelconque de rotations de clé. Pour plus de détails — Protection du contenu (DRM).

• Chaque connexion MPEG-TS over HTTP est une session distincte — la liste des clients du flux comporte désormais une ligne par connexion avec son propre sess-id, le détail est accessible à /data/stream/http-clients/<sess-id>, une connexion isolée se ferme par POST /data/kick?sess-id=<id>, et la limite max-conn est respectée aussi pour des valeurs supérieures à un.

• DVR (archive réseau) — chaque canal OTT est écrit sur disque en parallèle de la diffusion, avec la même segmentation et sans enregistreur distinct ; en mode faible latence, l’archive est tenue sur deux lignes, MPEG-TS et CMAF, de sorte que l’enregistrement est disponible dans le même conteneur que la diffusion en direct. Pour plus de détails — DVR.

• Lecture de l’archive (VOD) — l’archive est servie sur les mêmes URL HLS, DASH et LL-HLS que la diffusion en direct : t=<temps> active le mode VOD et fixe le début de la fenêtre, d=<secondes> en donne la durée. La playlist HLS est alors close, le manifeste DASH statique, les interruptions d’enregistrement sont présentées comme des périodes distinctes ; les ensembles adaptatifs lisent l’archive avec les mêmes paramètres.

• Catch-up par EPG — au lieu de t et d, il suffit de transmettre epg=<temps> : le serveur trouve lui-même, sur la chaîne EPG associée, l’émission diffusée à cet instant et en prend le début et la durée comme bornes de la fenêtre de lecture.

• Sous-titres dans l’archive — les pistes WebVTT sont écrites sur disque avec les segments et sont restituées en VOD sur les mêmes URL ; les fenêtres sans réplique n’occupent aucun espace disque.

• Stockages DVR — les stockages peuvent être multiples, chacun avec sa propre limite de remplissage et son propre ordre de nettoyage. La profondeur de l’archive (« Rétention (heures) », jusqu’à 90 jours) et le minimum protégé sont définis séparément pour chaque flux, et le nettoyage par espace libre ne touche ni le minimum protégé ni les fenêtres des sessions VOD ouvertes.

• Moniteur DVR — un écran dédié affiche l’état et le remplissage des stockages, le volume et la profondeur de l’archive par flux ainsi que les temps de lecture et d’écriture, tandis que l’histogramme de couverture (/data/dvrstat) signale non seulement les trous de l’archive mais aussi leur cause — coupure de l’entrée, changement de PMT, embrouillage, déclenchement du nettoyage. C’est également depuis cet écran que sont effacés l’archive d’un flux donné et les répertoires des flux supprimés.

• Une panne de disque d’archive n’arrête plus le nœud — une erreur de service de l’archive DVR se limite au stockage et à l’étape où elle est survenue : les autres flux et les autres lignes d’enregistrement continuent, et l’archive touchée est marquée comme nécessitant une reconstruction.

• Alerteur — nouveau service d’alertes : chaque défaillance devient un incident qui est déclenché, mis à jour et résolu automatiquement, tandis que l’ensemble actif dédupliqué n’affiche que ce qui se produit à l’instant présent. La gravité est définie sur une échelle unique — de l’information jusqu’à la nécessité d’une action de l’administrateur ; un tel incident n’est résolu que par l’acquittement de l’opérateur. Pour plus de détails — Alertes (alerter).

• Catalogue des codes d’alerte — plus de cinquante types d’incidents dans une seule liste : les flux et leurs entrées et sorties, les violations de TR 101 290, les ressources du nœud, les stockages et la santé de l’enregistrement DVR, la réception DVB et CI/CAM, les transcodeurs, l’OTT, les certificats et les nœuds du domaine. Les seuils de déclenchement se règlent dans la section des alertes.

• Livraison externe des alertes — les alertes sortent de la console web : par courrier électronique en SMTP (STARTTLS, implicit TLS, AUTH), par message Telegram et par le lancement d’une commande arbitraire, à laquelle l’incident est transmis dans des variables d’environnement et sous forme de JSON complet sur l’entrée standard. Chaque canal possède son propre interrupteur et son propre seuil de gravité.

• Alertes à l’échelle du domaine — l’opérateur de permanence voit les alertes de n’importe quel nœud depuis n’importe quel autre : l’ensemble actif se propage avec le keep-alive et est résolu dès qu’il disparaît à la source, et chaque ligne indique le nœud source. Les alertes matérielles et système restent locales par défaut et ne sont promues à l’échelle du domaine que par un paramètre distinct.

• Journal en base de données — les messages du service sont écrits dans SQLite : enregistrements typés avec source et niveau de gravité, regroupement des répétitions consécutives en une seule ligne avec compteur, limitation de la conservation par durée et par volume. Contrairement à l’ensemble actif des alertes, le journal survit à un redémarrage.

• Interrupteur général des notifications — enable désactivé dans les paramètres de l’alerteur, le nœud ne lève aucune alerte propre et n’envoie rien vers l’extérieur, y compris les alertes reçues de ses pairs du domaine ; dans la liste et dans le flux d’événements ne restent que les alertes des pairs diffusées dans le domaine.

• La gravité d’une alerte d’entrée-sortie suit les conséquences — une entrée qui tombe alors qu’elle ne porte pas le flux est marquée Error, tandis qu’une entrée porteuse, toute sortie et une panne sans antenne sont marquées Critical ; l’évaluation est recalculée tant que l’alerte est ouverte et suit le basculement sur la réserve.

• Couleur dans les notifications externes — un marqueur de couleur du niveau a été ajouté au texte du message (rouge pour les erreurs, jaune pour les avertissements, vert pour la levée, bleu pour l’information), et le courrier part en deux variantes à la fois : texte brut et HTML avec un bandeau coloré.

• Les notifications Telegram survivent à une tempête — les alertes accumulées sont regroupées dans le plus petit nombre de messages que la limite de 4096 caractères autorise, et sur une réponse de limitation de débit le nœud attend le délai indiqué et réémet au lieu d’abandonner la notification.

• Le délai de notification s’étend à l’entrée de réserve — l’avertissement indiquant qu’un flux fonctionne sur son entrée de réserve n’est levé que si la situation a duré plus que alert-delay ; une source qui se rétablit puis retombe ne produit donc plus une série de levées et de retraits. Avec alert-delay à zéro, le comportement est inchangé.

• Moniteur TR 101 290 — contrôle continu de la conformité du flux d’entrée à la norme : un verdict unique (« Normal », « Problème », « Vérification… ») et un rapport structuré par priorités 1, 2 et 3, où sont indiqués pour chaque indicateur la clause de la norme, la valeur mesurée et la limite. Un multiplex MPTS est évalué dans son ensemble — sur tous les PID, tous les programmes et toutes les tables SI. Le flux est automatiquement classé comme CBR ou VBR, et les contrôles qui n’ont de sens qu’à débit constant ne sont pas évalués sur une source VBR et ne produisent pas de faux déclenchements. Pour plus de détails — Moniteur TR 101 290.

• Dérive de l’oscillateur de référence — l’écart systématique de la fréquence d’horloge de la source est mesuré par régression linéaire en ppm, pour une tolérance ISO/IEC 13818-1 de ±30 ppm, et est présenté comme une métrique distincte. Une dérive lente est compensée par de légers micro-décalages du point de synchronisation (« Compensation de la dérive de synchronisation », activée par défaut), ce qui évite les à-coups en sortie.

• Modèle de tampon T-STD — analyse du tampon vidéo du décodeur de référence selon ISO/IEC 13818-1, avec compteurs de débordements et de sous-alimentations pour MPEG-2, H.264 et HEVC ; le comptage suit l’horloge PCR et la vitesse de vidage s’ajuste au débit vidéo réel. Activé par le paramètre « Analyser le tampon vidéo T-STD ».

• Analyse pour l’insertion publicitaire — interprétation des sections SCTE-35 avec les événements de raccord, les points de raccord de la couche transport avec anticipation configurable et les marques d’accès aléatoire. Les données sont affichées dans les statistiques du flux lorsque l’analyse approfondie est activée.

• Assistant de réclamation — pour un flux présentant des violations persistantes, une consigne textuelle prête à l’emploi est constituée pour un chat IA, à partir de laquelle celui-ci rédige une lettre de réclamation formelle au fournisseur du flux : liste des violations persistantes, valeurs mesurées, clauses de la norme et impact sur le décodeur. La consigne est fournie par la requête GET /data/stream/<id>/ai-complaint-prompt ; le nom du flux et l’adresse de la source ne sont pas inclus dans le texte.

• CI/CAM (EN 50221) — hôte Common Interface intégré : détection du module, lecture de son nom et de la liste des CA_system_id pris en charge, sélection des programmes à désembrouiller et transmission du CA_PMT pour chacun d’eux. Un module combiné au récepteur DVB désembrouille les programmes sélectionnés du multiplex reçu en ligne, plusieurs à la fois ; l’état des slots et le verdict pour chaque programme sont visibles dans l’interface.

• Désembrouilleur logiciel BISS-1 / BISS-E — il s’applique non seulement à la réception depuis une carte DVB, mais aussi à toute entrée de flux : la clé est définie pour le SPTS entier ou par programme du multiplex et se change à chaud, sans redémarrer l’entrée. Lors d’une réception depuis une carte DVB, le résultat est en outre vérifié sur le flux lui-même, si bien qu’une clé erronée ne se présente pas comme un désembrouillage réussi mais déclenche une alerte dédiée.

• Nettoyage de l’accès conditionnel à la réception DVB — un paramètre distinct de l’adaptateur supprime du multiplex reçu par une carte DVB les PID ECM et EMM, et retire de la PMT les descripteurs CA des programmes en clair : un flux FTA propre poursuit son chemin dans la chaîne. En cas de perte de la clé, la signalisation d’accès conditionnel est rétablie afin qu’un récepteur situé plus loin dans la chaîne puisse redemander l’accès.

• Télémétrie du transcodeur — pour chaque encodeur sont publiées les informations média de la sortie réencodée : format d’image, codec vidéo, ensemble des codecs audio et débit courant ; pour chaque processus — la charge CPU et la mémoire occupée.

• RTMP et RTMPS — une chaîne est publiée vers n’importe quel récepteur RTMP, y compris YouTube et Facebook : vidéo H.264 ou HEVC (HEVC via Enhanced RTMP) et une seule piste AAC ; pour rtmps://, le nœud se connecte en tant que client TLS. Dans l’autre sens, l’entrée récupère elle-même le flux depuis une source rtmp:// ou rtmps:// et remultiplexe le FLV en MPEG-TS.

• Basculement de source sans coupure — lors du changement de l’entrée active sur l’émetteur, les peers PS1 en réception ne se reconnectent pas : la numérotation et les marques temporelles restent continues, une pointe de file d’attente est absorbée par l’abandon des paquets les plus anciens, et le manque est comblé par la retransmission normale.

• Retransmission adaptative PS1 — le récepteur mesure le RTT réel jusqu’à l’émetteur et ajuste lui-même les intervalles de demandes de répétition ; le RTT mesuré, l’intervalle de redemande courant et l’indication d’une latence trop faible sont reportés dans les statistiques de la liaison. La latence du tunnel de réception se définit directement en millisecondes, au lieu de l’ancien multiplicateur du RTT.

• États « Reconnexion » et « Action administrateur » — une entrée ou une sortie ayant perdu sa source est rouverte sur place et reste à l’état « Reconnexion » pendant toute la durée des tentatives, ne levant qu’un seul avertissement par épisode au lieu d’un message à chaque tentative. Une cause qu’une nouvelle tentative ne permet pas de lever — port occupé, interface absente, données qui ne sont pas du MPEG-TS, échec SRT sur le chiffrement — fait passer l’entrée ou la sortie à l’état « Action administrateur » avec une alerte persistante, tandis qu’une modification des paramètres est appliquée immédiatement.

• Date de la dernière erreur — l’heure de la dernière erreur d’une entrée ou d’une sortie est publiée à côté de son texte (last-error-ts, le même champ existe aussi dans le flux d’événements), de sorte qu’une cause ancienne restée sur une entrée en pause se distingue de la panne en cours.

• Diagnostic lorsque le contenu de l’entrée est inexploitable — le message sur la perte de synchronisation MPEG-TS nomme la cause probable : des paquets ont été trouvés mais sont décalés d’un nombre d’octets connu, ou bien il n’y a aucune structure MPEG-TS ; pour les entrées PS1 et Pro-MPEG, une indication sur la phrase secrète de chiffrement est ajoutée.

• Taille réelle du tampon de réception — l’entrée publie socket-buffer-actual, la taille accordée par le noyau, tandis que socket-buffer-size ne reste qu’une demande, rabotée par la limite système ; l’écart est donc visible immédiatement au lieu de se manifester par des pertes à haut débit.

• Multiplexeur MPTS : identité d’origine — les programmes peuvent conserver leurs PID d’origine et l’ordre des programmes dans la PAT, la SDT et la NIT se définit manuellement, si bien qu’un multiplex est migré vers Perfect Streamer sans changer l’identité du flux pour les équipements de réception. Les programmes avec embrouillage TS sont migrés avec leurs marques temporelles d’origine.

• Numérotation automatique des PID pour le SPTS — enable-autopid avec autopid-base déplace tout le programme dans une fenêtre prévisible de 64 identifiants, en commençant par la PMT, puis la vidéo, l’audio et les autres flux élémentaires dans l’ordre de la table source ; un programme qui ne tient pas dans la fenêtre conserve intégralement ses PID d’origine.

• La taille du datagramme se règle sur toutes les sorties — le paramètre packets s’applique désormais non seulement en SRT mais aussi sur les sorties UDP, RTP, Pro-MPEG et RIST, et pour la sortie vers un fichier ou vers le flux standard il fixe la taille du bloc écrit. Les valeurs par défaut reprennent le comportement antérieur, une configuration dans laquelle le paramètre n’a jamais été défini ne change donc pas ; une valeur enregistrée différente de la valeur par défaut était ignorée par les versions antérieures et prend désormais effet dès le premier redémarrage — vérifiez-la avant la mise à jour.

• Intégration avec une facturation externe — chaque session de spectateur est autorisée dans un système de facturation ou de CRM externe, maintenue par une réautorisation périodique et signalée à ce même système à son terme : cycle de vie Start / Interim / Stop dans le style RADIUS, la révocation d’un abonnement interrompt la session en pleine visualisation. L’OTT, le peering PS1 et les sorties SRT sont couverts, et le système de facturation lui-même se raccorde au moyen de modèles de requête et d’analyse de la réponse, sans modification logicielle.

• Client ACME intégré (Let’s Encrypt) — émission et renouvellement automatique des certificats pour le serveur web, le serveur HTTP/OTT et le serveur EPG : un certificat est commandé pour chaque nom d’hôte configuré, le renouvellement est vérifié quotidiennement et une alerte est déclenchée en cas d’échec. Une autorité de certification arbitraire et la liaison de compte externe sont prises en charge, et un nouveau certificat est appliqué sans redémarrer le service.

• Arrêt rapide du service — l’arrêt n’attend plus un client qui a cessé de lire les données : à charge égale, le nœud se termine en 2–4 secondes au lieu d’environ une minute, un redémarrage prend donc quelques secondes et ne laisse pas l’antenne sans diffusion.

• pss_lic 2.0 — l’utilitaire en ligne de commande de gestion de la licence est passé aux commandes apply, c2v, fingerprint, recipient, keys, detach, rehost et cancel avec des options longues : il applique une mise à jour de licence reçue, exporte l’état de la clé pour le fournisseur et transfère la licence d’un nœud à l’autre, y compris temporairement, et il accepte tout fichier sur l’entrée standard et écrit sur la sortie standard. En détail — pss_lic.

• Modification manuelle du fichier de configuration — un JSON Schema pour pss.json (strict et compatible) est publié avec la documentation, accompagné d’un guide pas à pas pour modifier et transporter le fichier : la configuration d’un nœud arrêté peut désormais être modifiée directement et transportée entre installations et versions après vérification du résultat avec le schéma, alors que l’API HTTP était auparavant le seul moyen pris en charge. En détail — Le fichier de configuration pss.json.

• Nouvelle interface web — la gestion du nœud est passée à une nouvelle console, qui s’ouvre à l’adresse du nœud (chemin /admin) : vue d’ensemble, flux, supervision du système, DVB, DVR, transcodeurs, clients, journal, alertes et tous les paramètres du serveur. Des schémas dédiés montrent la topologie du domaine Meshwork et la chaîne du flux sélectionné, des entrées jusqu’aux sorties. L’ancienne interface est conservée à l’adresse /classic. Pour plus de détails — Interface web.

• Authentification unique dans le domaine — un compte peut être autorisé à se connecter automatiquement : après une seule connexion par mot de passe, le navigateur ouvre le panneau de ce nœud sans formulaire de connexion pendant 14 jours et survit à un redémarrage. Suivre un lien depuis ce panneau transmet la session à un nœud voisin du domaine si les conditions du transfert sont remplies (Serveur web et comptes) ; une adresse de voisin saisie à la main ne transmet pas la session. Un script ou un panneau tiers présente la même clé dans l’en-tête X-Auth-Token ou le paramètre auth-token, et un administrateur révoque la connexion automatique dans tout le domaine d’un coup.

• CORS pour l’API d’administration — les nœuds d’un même domaine Meshwork sont autorisés sans aucun réglage, les autres origines se déclarent dans web-server/cors-origin (la valeur * autorise toute origine, none désactive le mécanisme), de sorte que l’interface d’un nœud s’adresse à l’API d’un autre ; une requête inter-domaines doit porter le jeton explicitement — le cookie et Digest n’y ont pas d’effet.

• Jeton de sa propre session — GET /data/auth-token renvoie au client son propre jeton et sa date d’expiration absolue, et le champ web-login-expires a été ajouté à /data/server, de sorte que l’interface indique jusqu’à quand la connexion est valable sans lire le jeton lui-même.

• Fin d’une session d’ouverture automatique — POST /data/auth-tokens/revoke?login=<login> ferme toutes les sessions actives d’un compte, et ?id=<hex> en ferme une, par l’identifiant issu de la liste des sessions ; la réponse indique le nombre de sessions fermées, et la révocation se propage à tout le domaine.

• Motif du refus lors du passage à un nœud voisin — si le passage n’a pas donné d’ouverture automatique, le nœud renvoie dans l’adresse un paramètre jump valant no-session, foreign-domain, autologin-off ou token-refused, au lieu d’afficher silencieusement le formulaire de mot de passe.

• Mise à jour en temps réel — le nœud publie son état sous forme de flux d’événements sur /data/events : à la connexion, un instantané complet est reçu, puis les instantanés des flux, des ressources système, des clients et des adaptateurs DVB sont rafraîchis une fois par seconde, tandis que les alertes et les changements d’état arrivent sous forme d’événements. L’interface et les tableaux de bord externes fonctionnent sans interrogation périodique.

• Aide contextuelle — chaque écran et chaque fenêtre importante de la nouvelle interface disposent d’un appel à l’aide qui ouvre la section de documentation correspondant précisément à ce qui est ouvert à cet instant : le bouton d’aide général pour l’écran, le bouton « ? » dans l’en-tête de la fenêtre pour cette fenêtre. La section s’ouvre dans la langue de l’interface.

• Langues, thèmes et dispositions — l’interface est traduite en six langues (russe, anglais, allemand, français, espagnol, portugais), prend en charge un thème clair et un thème sombre et adapte d’elle-même la densité de la disposition au téléphone, à la tablette, au poste de travail et au mur d’images.

• Accès sans limite du nombre de connexions — les limites de connexions du destinataire ont acquis un troisième état, « Sans limite », à côté de « Protocole interdit » et de « Au plus » avec un nombre ; auparavant, un accès illimité se représentait par un nombre délibérément grand. Zéro signifie toujours l’interdiction du protocole, si bien que le sens des réglages enregistrés ne change pas après la mise à jour. En détail — Utilisateur : ajout et modification.

• La modification de l’accès aux flux n’affecte pas les sessions étrangères — ajouter un flux à la liste des flux autorisés et revenir à une liste vide ne rompent aucune session, tandis que restreindre la liste ferme les sessions PS1 et SRT uniquement sur les flux qui en sont sortis. Auparavant, toute modification de la liste coupait le compte entièrement sur tous les protocoles.

• Activation de la licence depuis l’interface web — l’écran « Licence » s’est doté d’une section « Activation » : l’export de l’état de la clé pour le fournisseur — sous forme de fichier C2V ou vers le presse-papiers — et l’application de la clé V2C reçue, par fichier ou par collage du texte. L’application de la clé redémarre le nœud. En détail — Licence.

• Avertissement d’expiration de la licence — le nœud déclenche une alerte deux semaines avant la fin du terme et l’élève au niveau nécessitant une intervention une fois le terme échu. L’alerte est répliquée à l’échelle du domaine, si bien que la licence expirante d’un voisin est visible depuis n’importe quel nœud (Alertes (alerter)).

• Une licence jugée non authentique arrête le nœud — un nœud dont la licence est jugée non authentique lève une alerte nécessitant une action de l’administrateur, redémarre le service, et le démarrage est refusé : le service reste arrêté tant qu’une licence authentique n’est pas présente sur le nœud. L’alerte est répliquée à l’échelle du domaine (Alertes (alerter)).

• Repli sur la dernière configuration fonctionnelle — le nœud conserve une copie des paramètres avec lesquels il a démarré proprement la dernière fois et, lorsque pss.json est inacceptable, il démarre sur cette copie — avec tous ses flux, et non sur les paramètres par défaut, qui ne contiennent aucun flux. L’archive des fichiers rejetés a été mise en ordre : noms en UTC, suffixe numérique au lieu d’un écrasement lorsque deux échecs tombent dans la même seconde, les vingt copies les plus récentes ; l’alerte nomme directement le chemin de la copie archivée. En détail — Comportement au démarrage et en cas d’erreurs de configuration.

• La priorité des entrées se modifie à la souris et au clavier — un administrateur peut réordonner les entrées d’un flux par glisser-déposer ou avec Alt+↑ et Alt+↓, dans l’onglet « Entrées » de l’éditeur et dans la ligne dépliée de la liste des flux (sur téléphone, l’ordre est seulement affiché) ; une entrée ajoutée se place toujours en dernier et ne remplace jamais l’entrée principale (Flux).

• Le numéro d’une entrée est sa place dans la liste de redondance — un seul et même numéro figure désormais dans la ligne du flux, dans la ligne dépliée, dans l’éditeur et dans le texte de l’alerte. Les entrées de même valeur de priorité conservent l’ordre dans lequel elles sont enregistrées, y compris lors des modifications ultérieures des paramètres (Redondance des sources).

• La défaillance d’une entrée abandonnée se lit comme un historique — l’entrée que le flux a quittée pour une entrée de secours est arrêtée mais conserve sa cause : l’interface l’affiche en ligne atténuée avec un âge, et non comme une défaillance en cours, et l’alerte sur l’erreur de cette entrée est levée. La cause est alors la sienne, de niveau transport, si l’entrée a eu le temps de la signaler elle-même (Redondance des sources).

• Tri de la liste des clients — sur l’écran « Clients », l’en-tête de colonne trie la liste : les colonnes numériques s’ouvrent en ordre décroissant, les colonnes textuelles de A à Z, et un troisième clic rétablit l’ordre du nœud. C’est toute la liste trouvée qui est triée, et non la page affichée (Clients).

• Accès au flux depuis l’écran des transcodeurs — la ligne du décodeur et de chaque encodeur a reçu un bouton qui ouvre la liste des flux sur le flux concerné. Disponible dans tous les rôles (Transcodeurs).

• Le programme du démultiplexeur se choisit dans une liste, y compris pour un adaptateur DVB — un adaptateur en marche publie son multiplex, et le champ « PNR » propose ses programmes avec leurs noms, y compris les programmes internes T2-MI sous leurs numéros composites (Démultiplexeur (demuxer)). L’adaptateur d’une entrée dvb se choisit lui aussi par son nom au lieu d’être saisi comme numéro d’enregistrement (Adaptateur DVB (dvb)).

• La réception DVB ne dépend plus de la version compilée — le type d’entrée dvb et la section des adaptateurs DVB sont disponibles sur tout nœud ; la seule condition est un frontend détecté et un pilote qui permette au service de l’ouvrir (Récepteur DVB).

• Le scanner DVB cède le tuner à un adaptateur configuré — un multiplex trouvé peut être appliqué sans attendre la fin du passage : l’adaptateur prend le tuner et démarre en une seconde environ, tandis que le balayage se termine comme annulé en conservant ses résultats à l’écran. Un passage s’arrête avec le bouton « Stop » et par la fermeture de la fenêtre (Balayage).

• Les panneaux de la vue d’ensemble du nœud suivent la présence du sous-système — « Transcodeurs » et « Adaptateurs DVB » apparaissent dans la vue d’ensemble là où le matériel ou les instances existent, ou là où il y a une défaillance à signaler. Sur un nœud sans transcodeurs et sans tuner, ces panneaux sont absents, et l’accès à leurs sections depuis la vue d’ensemble l’est aussi (Vue d’ensemble du nœud).

• Adresses des interfaces dans le moniteur système — la carte « Réseau » et les graphiques d’historique portent l’adresse IPv4 de l’interface lorsque le nœud la communique, VLAN imbriqués compris (Moniteur système).

• Le chemin d’un stockage DVR s’écrit sans séparateur final — l’interface et l’API HTTP rejettent une telle valeur : deux écritures d’un même répertoire passeraient le contrôle d’unicité comme deux stockages distincts (Stockages DVR).

• Le paquet exige le service de protection 10.33 ou plus récent — pstreamer fournit les bibliothèques de nouvelle génération du système de protection, et un aksusbd plus ancien ne les accepte pas (Configuration système requise). Le service se trouve dans le même dépôt et s’installe avec le paquet, mais sa mise à jour est irréversible, quel que soit le type de clé — la marche à suivre et ses conséquences sont décrites sur les pages d’installation (Installation sur les systèmes de la famille RHEL, Installation sur les systèmes de la famille Debian).

• Sélection explicite du PLP en DVB-T2 — le champ « Stream id (ISI/PLP) » a reçu une valeur « auto » (-1) : aucun filtre n’est appliqué, le tuner prend le flux par défaut du pilote, et un nouvel adaptateur est créé exactement ainsi. Un zéro explicite est de ce fait devenu une véritable sélection du flux zéro et non plus « non défini » ; un adaptateur dont le zéro est enregistré dans les paramètres ne recevra donc, après mise à jour du nœud, que ce flux (Adaptateurs).

• Le scanner trouve les PLP — le champ « Sonder les PLP jusqu’à » balaie les PLP des transpondeurs DVB-T2 et affiche chaque PLP trouvé sur une ligne distincte avec sa propre liste de programmes ; le numéro est repris dans l’adaptateur créé, et les statistiques de l’adaptateur ont reçu une ligne « PLP / ISI » (Balayage).

• Recherche dans les catalogues du scanner — des centaines de satellites et de bandes régionales sont triés par nom et filtrés par une chaîne de recherche ; une ligne déjà sélectionnée ne disparaît pas de la liste, quoi que l’on saisisse (Scan DVB).

• Correction de la référence PCR dans la PMT — un nouveau paramètre MPEG-TS pour les sources dont la table ne déclare pas de PCR utilisable : le nœud déclare dans la PMT le PID sur lequel la PCR est réellement transportée (Modification du flux).

• Reconstruction de la mémoire de gigue après un creux de la source — une entrée qui a survécu à un arrêt de sa source ne poursuit plus avec une file presque vide en transmettant aux sorties chaque à-coup suivant : le nœud reconstruit la mémoire tampon une seule fois, au prix d’une unique coupure (Synchronisation).

• Mode de contrôle du débit du codeur vidéo — le transcodeur a reçu le choix entre un débit constant et deux modes variables : le nombre indiqué se lit soit comme le débit moyen (les pics atteignent une fois et demie cette valeur), soit comme un plafond strict (le débit moyen représente alors les deux tiers de celui-ci). Il n’y a toujours qu’un seul nombre — le codeur déduit lui-même la seconde limite d’un rapport pic/moyenne fixe de 1,5. Dans les modes variables, le codeur cesse de bourrer le flux élémentaire ; l’économie de bande passante n’est donc obtenue que là où le flux récepteur ne réaligne pas le débit (Paramètres de l’encodeur).

• Un redémarrage du transcodeur est expliqué dans le journal — chaque redémarrage du processus fils nomme sa cause et son code de sortie au niveau « Notification », et non en silence dans la trace. Par ailleurs, le nœud a cessé de rouvrir indéfiniment un canal qui ne répond pas : après deux tentatives infructueuses, il demande un nouveau processus (Supervision).

• Un flux supprimé reste visible dans l’éditeur ouvert — si un flux est supprimé du nœud alors que son éditeur ou son schéma de traitement est ouvert, le nœud le signale sur une ligne dédiée, et l’enregistrement devient indisponible avec la même raison énoncée à côté du bouton. Auparavant, toutes les listes d’un tel flux se vidaient simplement, ce qui ressemblait à un flux sans entrées ni sorties configurées (Configurer le flux).

• Un enregistrement refusé nomme sa cause — au lieu d’une phrase générale valable pour tous les cas, le formulaire indique ce qui a précisément fait obstacle : un délai d’attente de réponse dépassé, une interdiction liée au rôle, ou le refus du nœud lui-même, dans ses propres termes.

• Libellés et choix des PID dans les règles de filtrage — chaque numéro est libellé avec son type et son codec et, sur un multiplex, également avec le programme auquel il appartient ; la ligne d’ajout a reçu la liste des PID que la source transporte réellement. La saisie manuelle demeure : le transport peut porter un PID à propos duquel rien n’a été décodé (Éditeur d’entrée et de sortie).

• Les écrans DVB affichent le numéro de programme adressable — pour un service situé dans une porteuse T2-MI, la liste des programmes de l’adaptateur et ses statistiques portent le PNR composite, celui-là même par lequel le programme est adressé dans les sélecteurs du démultiplexeur, de BISS et de CAM. Son numéro propre à l’intérieur de la porteuse se répète sur chaque porteuse d’un transpondeur à groupes en miroir et ne désigne rien (Statistiques de l’adaptateur).

• Un slot BISS est toujours proposé sous forme de liste — les programmes en clair y figurent en dernier, marqués · clear ·, si bien que sur un multiplex sans un seul programme chiffré la liste n’est plus vide : la clé est souvent saisie à l’avance, et un feed événementiel est en clair entre les événements (Désembrouillage).

• Des statistiques du flux vers le transcodeur et vers sa source — si l’entrée active d’un flux a été créée par un transcodeur, sa valeur est devenue un lien vers l’écran des transcodeurs avec la ligne de l’instance concernée dépliée, et une pastille portant le nom du flux que cette instance décode est apparue à côté. Les deux liens sont accessibles dans tous les rôles (Statistiques du flux).

• Limites des exécutions dans le journal — chaque démarrage du service est marqué dans le fil par une ligne dédiée portant l’instant du démarrage et la version compilée sur laquelle l’exécution a démarré : l’exécution en cours affiche à côté sa durée de fonctionnement, les précédentes indiquent combien de temps elles ont tourné et combien de temps le nœud est resté à l’arrêt avant le démarrage suivant, et une exécution terminée sans arrêt régulier est signalée à part. Le séparateur est posé même lorsque le filtre par gravité est actif (Journaux).

• Limite de taille de la base de statistiques — la base de métriques est bornée non seulement par la fenêtre de conservation, mais aussi par la taille. Le nœud rend compte du dernier nettoyage — combien d’historique subsiste, quelle est la taille de la base et combien de temps le nettoyage a pris — et indique explicitement si la limite de taille s’est avérée plus stricte que la fenêtre configurée (Paramètres du serveur).

• Les valeurs ramenées aux bornes au chargement sont annoncées aussitôt — si le nœud, en lisant les paramètres, a ramené une valeur à la limite admissible, il l’indique à l’écran dès le démarrage et non seulement par une ligne dans le journal (Comportement au démarrage et en cas d’erreurs de configuration).

• Une licence d’une génération obsolète n’est pas acceptée — un nœud muni d’une licence authentique de la génération précédente ne démarre pas et lève une alerte distincte. Il ne s’agit ni d’un terme échu ni d’une contrefaçon : la génération 2 n’est acceptée que comme licence d’essai temporaire, aussi une licence perpétuelle de cette génération est-elle rejetée d’emblée au lieu de vivre jusqu’à sa date (Catalogue des codes d’alerte).

• Le bourrage automatique calcule sa cible d’après le contenu — en mode de débit automatique, le nœud part du débit réel du contenu et non de sa propre sortie ; la cible ne dérive donc plus vers le haut sans revenir et redescend dès que le contenu tient de nouveau dans le débit configuré (Gestion du débit).

• La fenêtre de compensation de dérive est proportionnée à la mémoire tampon — la fenêtre souple est plafonnée au quart de la taille cible de la mémoire de gigue, sans jamais descendre sous 100 ms : une entrée dotée de la mémoire tampon standard ne fonctionne plus sans marge, la compensation rattrape la synchronisation plus tôt, et la reconstruction d’urgence de la mémoire tampon en cas d’épuisement se déclenche enfin (Synchronisation).

• Autres améliorations et corrections de bogues.