Version 26.09

Flussonic 26.09 : le DRM et une vitrine propre dans Catena, SDI, ST 2110 et RIST dans Mcaster, et l'enregistreur Watcher passe au nouveau cœur d'un simple bouton

Quatre produits, un seul cœur

Catena, Mcaster, Agora et Watcher sont quatre produits différents avec quatre clients différents : un opérateur OTT, un ingénieur de tête de réseau, une entreprise qui diffuse en interne et un intégrateur de sûreté. À l'intérieur, c'est le même moteur : Sapsan, notre cœur de streaming écrit en Rust.

C'est pourquoi ces notes de version commencent par le cœur. Tout ce qui figure dans la première section est arrivé dans les quatre produits d'un coup — et c'est aussi pour cela qu'une découverte faite sur un enregistreur de neuf mille caméras finit par faire démarrer plus vite une chaîne de télévision.

Voici ce que nous avons fait pour le cœur de streaming Sapsan

Soixante fois plus de spectateurs WebRTC. WebRTC était notre voie de diffusion la plus faible. Un nœud tenait 200–300 sessions WHEP simultanées et environ 0,9 Gbit/s, puis cessait tout simplement d'accepter des spectateurs : à cinq cents sessions, 448 sur 500 tombaient sur expiration de délai alors que le processus utilisait 330 % des 7 200 % dont disposait la machine. Ce n'était pas un manque de puissance : tout le sous-système WebRTC était une seule tâche parcourant toutes les sessions sous un unique verrou, si bien que créer une session faisait la queue derrière la diffusion à toutes les autres.

Les sessions vivent maintenant dans des partitions avec leurs propres boucles, et les chiffres ont changé d'ordre de grandeur. Un nœud tient 18 000 spectateurs simultanés à 32 Gbit/s, ou 16 000 plus lourds à 42,9 Gbit/s — en régime établi, sans aucune déconnexion. La mémoire par spectateur est passée de 3,8 Mo à 0,6–0,7 Mo, et la file d'attente a désormais une limite ferme : six mille spectateurs occupaient auparavant 53 Go et poussaient la machine dans le swap.

Une note pratique si vous comptez mesurer votre propre machine : la discipline de file fq que Linux applique par défaut coûte environ 8 Gbit/s sur ce chiffre, et la remplacer par pfifo_fast les récupère.

Séparément : les sessions WHEP abandonnées vivaient éternellement. Un spectateur qui fermait l'onglet laissait une session qui continuait à brûler du processeur et à grossir en mémoire à 80 Mo/s jusqu'à ce que le processus soit tué. Ces sessions sont désormais récupérées d'elles-mêmes.

Plus de 100 Gbit/s de HLS depuis une machine. Nous voulions tirer 100 Gbit/s à travers la carte réseau et nous y sommes parvenus — après quoi la limite est devenue le connecteur PCIe 3.0 du banc, et non le logiciel. En loopback, sans le câble dans le chemin, le même serveur a délivré 376 Gbit/s de HTTP en clair et 242 Gbit/s sur TLS. La lecture pratique n'est pas le chiffre lui-même : sur du matériel ordinaire, la voie de diffusion n'est pas ce qui vous manquera en premier.

Lecture du fMP4. Le ticket #5350 — « capture de sources MPEG-DASH / HLS fMP4 » — a été ouvert en mars 2018 et a accumulé une cinquantaine de demandes clients, la plus longue liste de ce genre dans notre outil de suivi. Il demande une seule chose, pas deux : une source moderne livrée par liste de lecture met dans ses segments du MP4 fragmenté, et non du MPEG-TS, et c'est précisément le fMP4 que nous ne savions pas lire. Tout agrégateur, tout CDN tiers et tout contributeur à qui l'on n'ouvre pas de port UDP ou SRT publie du CMAF, et jusqu'ici nous n'avions rien à répondre.

Une seule règle gouverne le démarrage, et elle mérite d'être connue. La capture commence au premier segment apparu après la connexion : tout ce qui se trouvait déjà dans la fenêtre de la liste est de l'histoire. Sinon, une source dont la fenêtre fait une minute déverserait une minute de média passé dans votre chaîne en quelques secondes, et recommencerait à chaque reconnexion. La même règle couvre une source morte : une liste laissée par une diffusion terminée ne produit jamais de nouveau segment, donc la capture ne démarre tout simplement pas, au lieu que le flux reste là à paraître sain sur une fenêtre périmée.

Les sous-titres, terminés. En 26.08 nous avons livré les sous-titres codés CEA-608/708 en WebVTT et promis la reconnaissance des sous-titres DVB pour la version suivante. La voici — et avec elle le télétexte, deuxième forme de sous-titre de la diffusion européenne et la seule où le texte arrive déjà sous forme de texte.

Tout cela suit désormais une conception unique : chaque producteur de texte — le décodeur télétexte, l'OCR DVB, les sous-titres codés, la reconnaissance vocale — écrit dans une seule couche canonique, et le spectateur reçoit toujours une piste WebVTT ordinaire. Quelle qu'ait été la forme d'origine, l'abonné de votre application voit le même menu de sous-titres qu'un téléspectateur du câble, et les exigences d'accessibilité sont satisfaites sans deuxième entrée ni chaîne distincte par format. Au passage, le décodeur télétexte a été corrigé à deux endroits qui le rendaient inutilisable : une erreur d'ordre des bits du code de Hamming (la page 888 était lue 811) et l'absence de jeux de caractères nationaux, qui transformait trémas et cyrillique en charabia.

Transcodage matériel sur NVIDIA. Tout le chemin vidéo — décoder, redimensionner, encoder — passe sur la carte, choisie explicitement ou automatiquement, si bien que le nombre de chaînes qu'un serveur porte cesse d'être une question de cœurs de processeur achetés.

En chemin, nous avons enfin mis la main sur un bogue qui nous embêtait depuis l'époque de Flussonic. Il s'est avéré ne pas être le nôtre : c'est un défaut du pilote de NVIDIA lui-même, et NVIDIA l'a enregistré sous le numéro Bug 6610402. Tant qu'il n'est pas corrigé à la source, nous livrons un contournement — il n'atteint donc plus votre installation.

Un répartiteur qui fait le travail que vous feriez sinon à la main. Décider quel nœud exécute quel flux, il faut bien que quelqu'un le fasse — et le refasse chaque fois qu'une machine est ajoutée, vidée, surchargée ou perdue. Sur quelques serveurs, cela tient dans la tête. Sur cent, non, et le prix d'une erreur est une chaîne hors antenne. Le répartiteur de Catena en décide désormais selon 129 règles, écrites dans un document de politique avant d'être du code, et les tests sont confrontés à ce même document.

Ce qu'il couvre, dans les termes de l'exploitant. Des exigences qu'un placement ne peut jamais enfreindre : espace de noms, étiquettes obligatoires, un flux qui a besoin d'une carte graphique uniquement sur un nœud qui en possède une, un flux avec archive uniquement sur un nœud doté d'un stockage d'archive, une limite de flux par nœud. Des préférences qui départagent. La réaffectation quand un nœud tombe, est vidé ou quitte la grappe — tandis qu'un nœud délibérément gelé conserve exactement ce qu'il porte. La surcharge, avec un ordre de délestage défini : processeur au-dessus de 90 %, réseau au-dessus de 95 % de la limite du nœud, archive au-dessus de son seuil ; le réseau est délesté en premier, les copies d'archive bougent avant la capture, le flux le plus lourd part le premier. Et les rôles au-delà de la capture : copies d'archive, restes d'archive sur des machines qui n'exécutent plus le flux, diffusion en direct sur les périphéries, flux décalés placés près de l'archive qu'ils rejouent.

Un chiffre mérite d'être dit franchement : sur l'année écoulée, 96 % des signalements clients que nous avons reçus au sujet du répartiteur se sont révélés être une erreur de configuration côté client, et non un défaut du répartiteur. Le moteur était rarement en cause ; ce qui manquait, c'était de pouvoir voir pourquoi il avait décidé ce qu'il avait décidé. C'est cette moitié que cette version referme : chaque affectation porte désormais la raison pour laquelle elle a été prise, et la console dispose d'une page listant les exécutions, les affectations et les contraintes qui n'ont pas pu être satisfaites.

Administrateurs, rôles et une révocation qui révoque. Jusqu'ici, l'accès de gestion était un mot de passe partagé et une clé statique : impossible d'ajouter un second administrateur, de le limiter ou de couper l'accès à une personne sans changer le secret de tout le monde. Il existe désormais un vrai registre de comptes administrateur avec des rôles. Et désactiver un compte interrompt le travail immédiatement : auparavant seule la connexion était révoquée, tandis qu'un jeton déjà émis continuait à créer des flux et à modifier des nœuds pendant un quart d'heure.

On voit davantage de ce qui se passe. Le graphique d'erreurs d'un flux se décompose en lignes par type d'erreur, et les défaillances au niveau connexion — une session SRT qui se coupe, une requête HTTP refusée par une source HLS — sont comptées pour la première fois, si bien qu'une panne complète de la source est enfin visible sur le graphique et non seulement dans le journal. Vers Retroview partent désormais la télémétrie de qualité des sources, les statistiques serveur, l'inventaire et la charge des cartes graphiques et les compteurs du transcodeur. Lorsqu'un nœud refuse d'appliquer la configuration que vous avez enregistrée, la raison parvient à la console au lieu de rester dans le journal local de la machine. Et sur les installations à plusieurs dizaines de disques, l'espace occupé est ventilé en archive courante, enregistrements orphelins et le reste, de sorte que « où est passé l'espace » a une réponse.

Voici ce que nous avons fait pour Catena

Le DRM, et donc la diffusion payante. C'est la plus grande lacune qui retenait les opérateurs sur Flussonic Media Server. Catena savait déchiffrer une entrée protégée, mais pas protéger ce qu'elle diffusait, et ne remplaçait donc Flussonic sur aucune chaîne payante. Désormais si. Les flux sont chiffrés en CMAF cbcs, et une seule copie chiffrée sert HLS/fMP4 pour FairPlay et DASH pour Widevine et PlayReady : pas besoin d'empaqueter deux fois. Les clés viennent soit de votre propre serveur de clés via SPEKE v1 ou v2, soit de la configuration pour les essais.

La conception en cluster compte ici autant que la cryptographie. Le chiffrement a lieu à la sortie du nœud qui a capté la source, et non à l'écriture : l'archive reste en clair, si bien que rembobinage, vignettes, transcodage et analyse continuent de fonctionner. Les nœuds de périphérie ne reçoivent que le texte chiffré : la clé et les identifiants du serveur de clés ne quittent jamais le nœud de capture et n'apparaissent pas dans la configuration d'une périphérie. Et à l'import d'une configuration Flussonic v3, un flux comportant une section drm arrive désactivé, pour qu'une migration de masse ne se mette pas silencieusement à diffuser en clair une chaîne premium.

Une vitrine avec un vrai guide des programmes. L'application spectateur de Catena — celle que vos abonnés ouvrent sur le téléviseur ou dans le navigateur — a rejoint le nouveau cœur avec le backend dont elle a besoin. L'abonné se connecte avec son propre jeton, reçoit la liste des chaînes auxquelles il a droit avec des adresses de lecture prêtes à l'emploi, et un billet de lecture accompagne la liste : c'est ainsi que fonctionnent la limite d'appareils simultanés et la révocation, sans que la vitrine ait à connaître la moindre clé interne.

Derrière elle se trouve un guide des programmes qui n'existait auparavant sous aucune forme. Central possède désormais les sources XMLTV, les télécharge selon un calendrier, conserve la grille et la remet aussi bien à la vitrine qu'à la sortie MPEG-TS sous forme d'EIT. Deux remarques pratiques : l'import filtre les programmes sur les chaînes que vous avez réellement associées — le fichier réel d'un fournisseur sur lequel nous avons testé contenait un million et demi de programmes répartis sur 4 054 chaînes, dont personne ne lira jamais 95 % des lignes — et le fichier téléchargé est conservé, si bien qu'associer une nouvelle chaîne réimporte immédiatement.

Si vous avez déjà un middleware. Beaucoup de nos clients vendent le leur, et Catena ne leur fait pas concurrence. Dans ce montage, Catena est ce vers quoi pointe votre middleware : une seule adresse de lecture, avec une répartition redondée à l'intérieur de la grappe — il n'y a donc pas devant elle de répartiteur matériel séparé à acheter, à monter en baie et à maintenir en vie. La vitrine ci-dessus s'adresse aux opérateurs qui n'ont pas encore de middleware et préfèrent ne pas commencer par en construire un.

Chaînes en décalage horaire. « Chaîne +2 » comme chaîne à part entière. Le rembobinage existait déjà, mais le rembobinage est un paramètre dans l'URL du lecteur : la version décalée n'avait pas de nom propre, pas de ligne dans la liste des chaînes, pas de sessions ni de statistiques, et ne pouvait être ni poussée, ni protégée, ni confiée à une zone CDN. Désormais une chaîne décalée est un flux ordinaire avec une source inhabituelle, et hérite donc gratuitement de ses URL spectateur, de ses sessions, de son DRM et de ses envois. Une capture et une archive profonde couvrent vos fuseaux horaires, au lieu de recevoir un signal régional par fuseau.

Les deux dernières lacunes de format. Catena capte les sources DASH — l'autre moitié du même ticket, tournant sur le même lecteur fMP4 décrit plus haut. HLS et DASH couvrent ensemble les origines CMAF, les passerelles DVB-I et les empaqueteurs cloud qui ne publient que l'un des deux. Le DASH diffère sur un point, et il est honnête : un manifeste n'énumère pas ce qui existe, il donne une heure de départ et un gabarit, si bien que le segment déjà disponible se calcule à partir de l'horloge murale au lieu de se lire dans une liste. Et en sortie, le HLS est servi aussi en conteneur MPEG-TS, à sa propre adresse, pour les lecteurs et décodeurs anciens qui n'acceptent rien d'autre. Ensemble, ils suppriment les deux dernières réponses du type « Flussonic savait le faire et Catena non », en entrée comme en sortie.

La VOD a cessé d'être du travail manuel. Un catalogue VOD de cluster savait accepter un fichier et le lire, mais tout ce qui transforme un fichier téléversé en service — l'échelle de qualités pour le MBR, le descripteur SMIL, le sort de l'original — se faisait à la main sur chaque nœud. Désormais un modèle de transcodage est attaché à la ressource, la tâche naît à la validation du téléversement, Central choisit le nœud qui l'exécute, et le résultat revient au catalogue comme un fichier ordinaire. Les modèles, les tâches et leur progression vivent dans la console et non dans curl. Et le MBR assemblé à partir de fichiers voisins, plus les sous-titres externes ramassés à côté de la vidéo, font qu'un client qui migre n'a pas à ré-empaqueter sa bibliothèque.

Les périphéries sont devenues de vraies périphéries. Un nœud de périphérie ne servait auparavant que l'archive : le direct et le rembobinage en étaient tenus à l'écart, parce qu'un flux sur une périphérie aurait tiré de l'origine éternellement, que quelqu'un le regarde ou non. Les deux raisons ont disparu. Les flux sur une périphérie se lèvent à la demande lorsqu'un spectateur arrive et s'éteignent à l'inactivité, et les nœuds s'échangent le direct via notre propre protocole interne, sans se rabattre sur RTMP ou SRT avec un remultiplexage supplémentaire. Ainsi toute la charge spectateur, direct compris, quitte le nœud de capture pour les périphéries.

Ce que vous gagnez en passant de Flussonic Media Server à Catena

Catena est conçue en cluster dès l'origine : vous ajoutez un flux au lieu de lui choisir une machine, l'archive et le catalogue VOD appartiennent à tout le cluster, et l'installation entière se voit depuis un seul endroit. Nous avons développé cet argument en 26.08 et il n'a pas changé. Ce qui a changé en 26.09, c'est autre chose : la liste de ce que Flussonic faisait et que Catena ne faisait pas est pratiquement épuisée.

Voici ce que nous avons fait pour Mcaster

Les entrées de diffusion, toutes. Mcaster est la tête de réseau : le signal arrive d'un récepteur satellite, d'un réseau voisin, d'un partenaire ou de votre propre régie. Cette version ferme les entrées que seul le Flussonic en Erlang possédait.

Le SDI depuis des cartes DekTec tourne comme un processus distinct par port de carte, dialoguant avec le streamer par mémoire partagée : une panne au niveau du pilote emporte une capture et non le serveur média entier — ce qui, vu l'historique des plantages de DTAPI, n'est pas une inquiétude théorique. Il désincruste l'audio multicanal, extrait le VANC et calcule lui-même des horodatages alignés. La console montre désormais quelles cartes se trouvent réellement dans la machine, combien de ports chacune possède, dans quelle variante de micrologiciel elles sont et quels flux les ont déjà prises. Ce n'est pas décoratif : sur une DTA-2178, chaque canal est affecté par le micrologiciel en entrée ou en sortie, et un port qui est actuellement une sortie répond à une tentative de capture par « occupé », après quoi l'ingénieur part chercher un processus étranger qui n'existe pas.

SMPTE ST 2110 est reçu en entier : vidéo 2110-20, audio 2110-30 et données auxiliaires 2110-40, plus un nœud NMOS publiant les récepteurs via IS-04 et IS-05 pour qu'un contrôleur tiers puisse les commuter. La réception tourne dans un fil système dédié lisant les paquets par lots : de la HD entrelacée en 10 bits, ce sont 130 Mo/s et environ 90 000 paquets par seconde sur une seule piste, et ce n'est pas un travail pour un ordonnanceur généraliste. MXL, la couche d'échange par mémoire partagée de l'UER, est également lue, pour les installations où les fonctions voisines de la chaîne remettent le signal ainsi.

RIST arrive sous forme d'implémentation propre : réception et envoi, unidiffusion et multidiffusion, avec retransmission et les compteurs nécessaires pour prouver que la liaison se tient. La valeur est plus commerciale que technique : RIST est le seul protocole de livraison fiable publié par un organisme de la profession et non par un seul fabricant, il figure donc dans les appels d'offres comme ligne d'exigence — et jusqu'ici nous ne pouvions pas y répondre du tout.

Un flux de transport que l'on peut livrer sous contrat. Le MPEG-TS sortant était auparavant à prendre ou à laisser : numéro de programme figé à 1, PID attribués automatiquement, aucune SDT. On peut désormais fixer la table des PID, le numéro de programme et le nom du service par destination. Le cas immédiat était un client recevant une chaîne de notre part et d'un fournisseur de secours, dont le commutateur de secours exige que les PID des deux flux coïncident. Mais ce même contrôle est ce que réclament un multiplex, un IRD, la supervision d'un NOC ou le cahier des charges d'un contrat de contribution.

Accès conditionnel. Embrouillage Simulcrypt sur la sortie SPTS : sans carte pas d'image, avec carte oui. Cela ne se configurait qu'en éditant un document à la main, où un champ hexadécimal erroné signifie « la carte ignore les EMM en silence » et coûte des jours de banc d'essai. Il y a maintenant un formulaire digne de ce nom.

Les clients, et ce que chacun a acheté. C'est ce que les opérateurs Mcaster ont demandé le plus directement. Vous ne vendez pas un flux, vous vendez un service : cette chaîne, livrée ainsi, à cette entreprise. La configuration et la supervision ne connaissaient que des flux, si bien qu'à l'appel d'un client il n'y avait rien à regarder : qu'a-t-il acheté, quelle partie est tombée, et de qui est cette panne.

Désormais la vente est consignée là où vit la livraison. Un envoi en unidiffusion ou un port SRT de lecture porte l'identifiant du client auquel il appartient, et un jeton statique par flux permet de donner un lien une fois pour toutes à un acheteur et de lui rattacher sa consommation. Les envois en multidiffusion ne portent délibérément pas de propriétaire : les destinataires du groupe sont multiples, la commutation est réseau, et un champ unique ne décrit pas cela honnêtement. Par-dessus vient la statistique de livraison par destination : état avec motif de panne nommé, débit, octets, reconnexions, retransmissions. Au passage, une chose pire a été corrigée : un envoi en échec se déclarait parfois en marche, avec une erreur vide et un compteur de reconnexions qui grimpait, si bien que la console assurait à l'opérateur que la livraison était vivante alors qu'il n'en sortait pas un octet.

Qui a changé quoi. Central détient l'état souhaité de l'installation — configuration des flux et des nœuds, zones CDN, comptes administrateur, cycle de vie des nœuds — et n'enregistrait jusqu'ici pas qui le modifiait. Avec plus d'un opérateur de garde, un incident en devient impossible à instruire : des questions comme « qui a supprimé ce flux » ou « quand et par qui ce nœud a-t-il été révoqué » n'avaient aucune réponse. Elles en ont une désormais : acteur, action, moment.

Un paquet propre, et un cluster qui reste un seul produit. Il existe désormais un paquet mcaster-streamer. Auparavant, le seul paquet de nœud existant était celui de Catena, et la console Mcaster affichait une commande d'adhésion câblée sur les chemins de Catena — l'opérateur qui la suivait installait donc un nœud du mauvais produit, sans que rien ne proteste en chemin. Un cluster fait de machines de deux produits n'est pas exotique : c'est une panne silencieuse dont on s'aperçoit bien plus tard. Désormais l'adhésion d'un nœud d'un autre produit est refusée avec un motif clair.

Ce que vous gagnez en passant de Flussonic Media Server à Mcaster

Une tête de réseau se juge à ce qu'elle sait recevoir et à ce qu'elle sait prouver de ce qu'elle a livré. C'est exactement là qu'atterrit la 26.09 :

Voici ce que nous avons fait pour Agora

Agora, c'est la télévision d'entreprise : vos propres chaînes internes, des signaux de studio préparés pour la diffusion, des réunions plénières et des webinaires livrés aux collaborateurs par le réseau de l'entreprise. En 26.09, elle acquiert son propre visage sur la plateforme commune — sa console, son ensemble de rubriques, son identité de produit — tandis que les fonctions métier rejoindront le nouveau cœur dans les versions suivantes.

Deux morceaux du travail de cœur tombent en plein dans son cas d'usage.

Une diffusion à faible latence qui passe à l'échelle. Le travail WebRTC décrit plus haut est exactement ce dont la diffusion d'entreprise a besoin : une réunion plénière, ce sont quelques milliers de personnes qui regardent la même chose en même temps, à moins d'une seconde de latence, à l'intérieur d'un réseau. Passer de 200–300 sessions simultanées par nœud à 18 000 change ce que coûte à une entreprise, en matériel, une diffusion à tout l'effectif — d'une baie à une machine.

Publication par SRT. Un studio, une salle de réunion ou un portable avec OBS peuvent désormais publier dans le cluster par SRT, la réception se faisant sur le nœud appelé, avec chiffrement et récupération des pertes en entrée. C'est la manière ordinaire dont un événement interne parvient à la plateforme.

Voici ce que nous avons fait pour Watcher

L'enregistreur passe au nouveau cœur, et il n'y faut pas d'ingénieur. En 26.08, la couche média avait reçu un nom propre, le paquet watcher-streamer, derrière lequel le moteur pouvait être remplacé. Cette version le remplace, et le fait par le seul canal dont un enregistreur sur le terrain dispose réellement : le bouton de mise à jour dans le cloud.

Jusqu'ici, changer le serveur média d'un enregistreur signifiait un ingénieur en SSH lançant un script de migration qui relevait la disposition des disques, générait une configuration et reconstruisait la pile de conteneurs à la main. Cela n'atteint jamais le boîtier d'un client. Désormais le nouveau serveur média voyage comme tout le reste : on appuie sur mettre à jour, l'enregistreur récupère la nouvelle pile, et un échec de l'une des étapes revient automatiquement à la précédente. Les valeurs propres à chaque boîtier qui rendaient cela difficile — clé de cluster, identifiants d'administration, nom du streamer, disposition des disques — sont désormais assemblées sur le boîtier lui-même, au lieu d'être figées dans un fichier servi à toute la flotte depuis une adresse publique.

Ce que vous y gagnez, c'est de la densité. Le nouveau cœur est celui qui enregistre vingt gigabits par seconde et par serveur, et à mesure que la migration avancera nous attendons une réduction des ressources d'un facteur plusieurs pour la même installation : moins de machines pour les mêmes caméras, moins de place en baie, une facture d'électricité plus faible.

La capture des caméras est devenue nettement plus fiable, et nous l'avons découvert par hasard. En traquant des pertes d'enregistrement sur un enregistreur à dix mille flux, nous avons remarqué que certains produisaient des fragments dix fois plus petits que les autres, nous sommes allés voir la caméra, et la caméra allait bien. Le problème était dans la façon dont nous assemblions les paquets RTP fragmentés en images sur le chemin RTSP.

Les mesures sont sans appel. Sur la même caméra et le même banc, la compilation de juillet produisait 438 453 images cassées sur 4 600 555 — soit 9,55 %. Après correction : 6 erreurs sur 272 591 images, soit 0,002 %. Sur l'enregistreur récepteur, avec 10 000 flux pendant une heure, la perte médiane d'archive est tombée de 15 236 à 2 fragments par seconde, et le nombre de flux perdant quoi que ce soit de 2 815 à 2.

Si vous exploitez des caméras en RTSP — c'est-à-dire si vous exploitez des caméras —, c'est la ligne la plus précieuse de cette version.

L'enregistrement a cessé de jeter des données alors que la mémoire est libre. Un fragment fermé vivait à un seul endroit, et la fenêtre de diffusion évinçait les fragments au nombre. Si l'écrivain disque prenait quelques fragments de retard, la donnée était perdue à jamais. Sur un enregistreur à neuf mille caméras, cela faisait 898 501 fragments perdus en dix minutes, avec 42 Go des 125 de la machine inutilisés. Désormais diffusion et durabilité ont des budgets séparés, la file d'écriture conserve ses propres références et est limitée en octets, et un fragment ne peut se perdre que lorsque la mémoire manque réellement. Au passage, aligner les écritures sur des limites de blocs de 4 Ko a à lui seul ramené les pertes de 5 524 à 8.

L'enregistreur est propriétaire de ses caméras. La configuration se synchronisait dans deux directions asymétriques, et les deux faisaient mal à de vrais utilisateurs : une caméra créée sur l'enregistreur n'apparaissait pas dans le cloud tant que quelqu'un n'avait pas trouvé le bouton « synchroniser », et une lecture de fond depuis le cloud toutes les soixante secondes écrasait silencieusement les modifications locales. L'architecture est maintenant énoncée clairement : l'enregistreur est l'unique source de vérité de la configuration de ses caméras, le cloud est un miroir non destructif. Tant que la liaison tient, on peut modifier depuis le cloud ; sans liaison, non — plutôt que de faire des modifications qui disparaîtront ensuite en silence.

L'API v2 est coupée. Nous avions dit en 26.08 qu'elle le serait, et elle l'est : les points d'entrée v2 répondent par un avertissement. Comme nous savons que certains systèmes de facturation y sont encore, un indicateur de configuration permet de la rallumer le temps de la transition. Voyez-y une échéance, pas une grâce.

Tout ce qu'offrait la v2 est déjà dans la v3. Ce que nous avons appris de ceux qui ont tenté la migration, c'est que le problème n'est pas un point d'entrée manquant mais une séquence manquante : créer un utilisateur, une organisation et un dossier est une chaîne d'appels où chaque identifiant provient de la réponse précédente, et une étape sautée donne soit un 403, soit un abonné doté des droits d'administrateur. C'est pourquoi nous rédigeons ce guide « comment passer à la v3 » pour les intégrations de facturation. Si vous avez une intégration propre en v2, écrivez-nous et nous examinerons vos appels avec vous.

Le nouveau lecteur, et le reste. Le lecteur a gagné un calendrier, le changement de qualité, la sélection sur la ligne de temps avec export de l'intervalle choisi, la prise en charge des mosaïques et un panneau de débogage séparé du lecteur lui-même ; sur les enregistreurs, il est désormais celui par défaut. À côté de cela : la liste complète des organisations d'un utilisateur s'affiche entière et non tronquée, la fenêtre d'information sur l'archive donne de vrais chiffres, la pagination et le bouton de suppression ont été corrigés sur la page des mosaïques, une prévision d'utilisation des disques que Central ne sait en réalité pas calculer a été retirée plutôt que laissée à induire en erreur, et un ordonnanceur qui cessait silencieusement d'exécuter toutes les tâches périodiques après un redémarrage de Redis s'en aperçoit désormais et se rétablit tout seul.

Villapass. Le produit de contrôle d'accès pour résidences bâti sur Watcher a mûri dans cette version. Les résidents sont regroupés par parcelle au lieu d'exister isolément, si bien qu'une restriction — cette parcelle ne peut pas émettre de laissez-passer visiteur — se pose là où elle doit être. Le résident se connecte avec son numéro de téléphone et un code par SMS, et non avec un courriel et un mot de passe que personne ne lui a donnés. Le système de barrière rend compte : quelle voiture est passée, quand, dans quel sens et avec quel laissez-passer — ce qui rend possible un journal des passages, et il existe maintenant un écran qui l'affiche, avec recherche par plaque et par laissez-passer. Le président peut basculer entre ses propres laissez-passer et ceux de toute la copropriété, au lieu de voir toujours ceux de tout le monde. Et la console de l'exploitant montre enfin comment se porte chaque résidence — résidents, parcelles, laissez-passer émis cette semaine et ancienneté du dernier échange avec la barrière — au lieu d'une liste de noms toute nue.

Flussonic Media Server

Rien de neuf, et c'est délibéré. Comme nous l'avons dit en 26.08, la phase de développement actif de Flussonic Media Server est terminée : le produit reste maintenu et nous publions des mises à jour de sécurité minimales, mais tout le développement va aux produits bâtis sur le nouveau cœur.

Cette version est un bon moment pour commencer à planifier le déménagement, car les raisons d'attendre sont pratiquement épuisées. Si vous faites de la télévision et de l'OTT, c'est Catena — qui depuis la 26.09 dispose du DRM, d'un guide des programmes, d'un middleware maison si vous en voulez un, de chaînes décalées, de la capture fMP4 sur HLS et DASH, d'une sortie MPEG-TS pour les décodeurs anciens et d'un outil qui lit votre archive existante sur place. Si vous exploitez une tête de réseau, c'est Mcaster : SDI, ST 2110, MXL, RIST, contrôle complet des PSI/SI et accès conditionnel. Si vous faites de la vidéosurveillance, c'est Watcher, dont les enregistreurs ont commencé à migrer vers le nouveau cœur dans cette version même.

Une migration, c'est plus qu'un outil, aussi y prenons-nous part nous-mêmes : parlez-nous de votre installation et nous déciderons ensemble de ce qui déménage en premier et de la façon dont l'antenne est vérifiée en chemin.