Historique des versions

version 2.0.0.206 Beta

25.07.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, 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, le taux de retransmissions et de pertes et le verdict d’état.

  • 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.

  • 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 servis au-dessus de QUIC sur un port UDP distinct, avec 0-RTT facultatif ; le client demande le passage à QUIC au moyen du paramètre ?h3. 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 se lit à travers un nombre quelconque de changements de clé. Pour plus de détails — Protection du contenu (DRM).

  • 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.

  • 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.

  • 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.

  • 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.

  • 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.

  • 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.

  • 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.

  • Autres améliorations et corrections de bogues.