Flussonic 26.08 : Catena migre elle-même depuis Flussonic v3, et Watcher cesse de se taire sur une archive manquante

Pourquoi Catena n'est pas « Flussonic avec un cluster »

Flussonic Media Server a été écrit comme un logiciel pour un serveur. Tout y est organisé autour de la machine : la configuration y réside, le flux lui appartient, l'archive s'écrit sur ses disques. Les fonctions de cluster sont arrivées ensuite et sont restées limitées — au fond, ce sont des accords entre serveurs distincts, dont chacun continue de vivre sa propre vie. Une telle installation grandit mal : chaque nouvelle machine, c'est une configuration de plus à retenir et un serveur de plus sur lequel se connecter pour savoir ce qui s'y passe.

Catena est bâtie sur Sapsan — le nouveau cœur de streaming de Flussonic écrit en Rust — et conçue cluster first. L'unité de gestion ici, c'est le cluster et non le serveur, et cela se voit dans chaque fonction :

Un flux se crée dans le cluster, pas sur une machine. Vous ajoutez un flux au lieu de choisir où il tournera : central détient la configuration de tous les flux, et le layouter décide sur quel streamer il démarre. Le flux est prévu dès l'origine pour se déplacer : vous pouvez retirer une machine du cluster ou en ajouter une nouvelle, et la répartition se recalcule d'elle-même, sans réécrire les réglages. Et les déplacements restent prévisibles : la répartition ne change que si son entrée change, et chaque décision est consignée avec son motif.
La VOD couvre d'emblée tout le cluster. Un seul catalogue dans central, téléversement depuis le navigateur sans choisir ni nœud ni disque, et l'actif part tout seul là où il y a de la place.
L'archive aussi est en cluster. Le DVR du cluster répond à la question de l'espace disponible et de ce qui l'occupe sur toutes les machines à la fois, tandis que les edges mettent en cache l'archive d'autrui sans enregistrer la leur.
Spectateurs, accès et certificats vivent au niveau de l'installation. Les zones CDN répartissent les spectateurs par géographie, une seule politique d'accès couvre toute l'installation, et chaque streamer émet lui-même son certificat HTTPS.

La deuxième chose qui distingue Catena, c'est une introspection de l'état à un niveau que nos produits n'ont jamais eu. Non pas « connectez-vous à chaque serveur et lisez les logs », mais une interface unique qui répond pour toute l'installation : un tableau de bord avec les courbes de spectateurs et de trafic et une carte de chaleur des erreurs ; les sessions une par une — qui regarde exactement en ce moment et qui regardait hier ; l'historique des décisions du layouter avec leurs motifs ; le diagnostic de la source et le diagnostic du streamer.

Un exemple parlant : la surveillance en direct des sources de secours. Posez-vous la question : comment savez-vous aujourd'hui que l'entrée de secours d'une chaîne est réellement morte ? La réponse habituelle, c'est que vous ne le savez pas — tant que la source principale est à l'antenne, personne ne touche au secours, et son bon état reste affaire de foi jusqu'au moment précis où l'on en a besoin. Catena teste le secours pendant qu'il attend : la carte de l'entrée affiche « Prêt » — testé et capable de reprendre la charge — ou « Non testé », et cela se voit dans l'onglet des sources tout de suite, et non au moment de la panne. On y voit aussi mieux que « des images ou pas » : erreurs de continuité MPEG-TS, chute du débit, son disparu, qualité de la ligne temporelle.

Et le plan de contrôle ne se met jamais sur le chemin du média : la perte de central est une panne de gestion, pas d'antenne — les flux continuent d'émettre.

Et nous aidons à franchir le pas. L'assistant d'import reprend la configuration d'un Flussonic Media Server en fonctionnement, affiche un plan avant application et un rapport après. Mais l'outil n'est qu'une partie : parlez-nous de votre installation et nous planifierons la migration ensemble — ce qui part en premier, comment l'antenne est vérifiée et à quel moment les spectateurs basculent.

Voici ce que nous avons fait pour Catena

Un assistant d'import de la configuration Flussonic v3 : plan avant, rapport après.
apt install catena donne un service qui tourne : base, compte opérateur, démarrage.
Des certificats Let's Encrypt que chaque nœud émet pour lui-même.
Des modèles : plus besoin de recliquer transcodeur et DVR sur chaque chaîne.
Une autorisation de lecture compatible avec les backends Flussonic, et des billets émis à l'avance.
La sélection de programme en MPTS et une seule capture du multiplex pour toutes ses chaînes.
Le transcodage matériel NVIDIA et un seul décodage pour toutes les qualités du MBR.
30 000 spectateurs simultanés depuis un nœud en HTTP MPEG-TS et RTSP, au lieu de mille ou deux mille.
Un enregistrement soutenu de 20 gigabits par seconde et par serveur : cela fait 10 000 caméras de résolution moyenne.
La diffusion live en MoQ : MOQT draft-19, navigateur en WebTransport, latence sous la seconde.
Les sous-titres de diffusion en une seule piste WebVTT : CEA-608/708 maintenant, DVB OCR à la prochaine version.
Le catalogue VOD est devenu clusterisé : téléversement depuis le navigateur, MBR à partir de fichiers voisins, sous-titres externes.
Moins de coutures pour le spectateur : segmenteur, LL-HLS, transcodeur, MPEG-TS.
On voit ce qui se passe : tableau de bord, sessions, qualité des sources, disques DVR.

Le passage depuis Flussonic v3, par assistant et non à la main. Un client faisant tourner Flussonic Media Server n'avait jusqu'ici ni procédure de migration ni outil : transférer la configuration signifiait retaper des centaines de flux, avec le risque de perdre en silence un réglage dont on découvre la perte une fois à l'antenne. La console Catena dispose désormais d'un assistant d'import : il lit la configuration source via l'API et la transforme en flux, sections de modèle et backends d'autorisation au nouveau format. On voit d'abord un plan — ce qui migre exactement et ce qui se perd — et seulement ensuite l'application ; après l'import, vous recevez un rapport par catégories, avec le motif pour chaque champ non repris, et le compte des flux réellement démarrés. L'import a été vérifié sur la configuration d'un routeur en production. La procédure complète, y compris la bascule des spectateurs et le retour arrière, est décrite dans Passer de Flussonic Media Server.

Une installation après laquelle le produit fonctionne. Entre apt install catena et un service qui tourne se dressait auparavant un mur de travail manuel : le paquet ne créait ni le rôle ni la base PostgreSQL, n'écrivait pas la chaîne de connexion, ne créait pas de compte opérateur et ne démarrait même pas le service sur une installation propre. Le paquet fait désormais tout cela — le démarrage rapide mène une machine vierge jusqu'à un flux qui joue, et l'installation en production détaille ce qui est livré, où vivent les secrets, comment brancher un PostgreSQL externe et quels ports s'ouvrent. Un nœud de cluster s'installe avec son propre paquet catena-streamer, qui demande l'adresse de central pendant l'installation ; saisie sans schéma, elle donne une erreur claire au lieu d'un nœud qui ne démarre pas en silence — voir ajouter un streamer. Et la machine porte désormais son propre nom : systemctl status catena. Pour ceux qui déploient en docker, il existe des images produit construites en couches : une mise à jour ne retélécharge pas toute la distribution.

HTTPS sans déployer les certificats à la main. Le produit intègre désormais un client ACME : le streamer commande et renouvelle lui-même son certificat Let's Encrypt, central compris. Plus besoin de distribuer des certificats à la main sur 10 à 100 nœuds, et central ne conserve aucune clé privée d'autrui. Au passage, le port et le TLS du nœud local se modifient depuis la console et non plus en éditant du YAML sur la machine. Les prérequis d'émission, la vérification TLS-ALPN-01 et les raisons pour lesquelles un certificat n'est pas émis figurent dans Certificat HTTPS.

Modèles de flux. « Au troisième flux, j'en avais déjà assez de cliquer partout dans les réglages » — c'est une citation littérale du ticket. Catena rétablit la notion de valeur par défaut réutilisable : transcodeur, archive, vignettes et délais des sources se configurent une fois dans un modèle, et les chaînes identiques se créent à partir de lui. La règle de résolution est simple et sans surprise : la section propre au flux l'emporte entièrement sur celle du modèle.

Autorisation de lecture : comme chez Flussonic, mais plus rapide. Les backends écrits pour Flussonic fonctionnent avec Catena sans la moindre modification — même requête, mêmes en-têtes, voici comment les brancher. Nul besoin de réécrire votre vitrine pour migrer. Et pour qui tient à la vitesse de démarrage, il existe un second schéma : la vitrine crée la session avant la lecture et remet au spectateur un billet que le streamer valide localement, sans appeler personne. Votre backend cesse d'être sur le chemin critique : ni la vitesse de changement de chaîne ni la fiabilité du démarrage n'en dépendent plus. La portée du billet s'exprime par une étiquette de contenu, si bien qu'un billet « pour 300 chaînes » ne transporte pas une liste de 300 noms et n'est pas réémis quand la composition du bouquet change. Un aperçu des deux voies figure dans Protéger la lecture.

Réception MPTS : sélection de programme et une capture par multiplex. Auparavant, le MPEG-TS sur UDP n'était lu que comme du SPTS : le numéro de programme était jeté et les images de tous les programmes du multiplex se mélangeaient en une bouillie — écran noir en HLS. La source dispose maintenant du champ « Programme (PNR) », et plusieurs flux peuvent capter le même multicast : le tronc arrive une fois sur le serveur, et non une fois par chaîne. Sur un multiplex typique, cela économise des centaines de mégabits de trafic entrant. Le branchement d'une source multicast a sa propre page. À cela s'ajoute l'analyse du flux élémentaire MPEG-2 : sans elle, les troncs hertziens et satellite ne pouvaient tout simplement pas être pris.

MoQ : diffusion sur le protocole vers lequel l'industrie se déplace. Media over QUIC, c'est ce que le consortium autour de l'IETF met à la place du partage « HLS pour l'échelle, WebRTC pour la latence ». L'idée est d'avoir les deux à la fois : une latence sous la seconde et, en même temps, une distribution ordinaire et cachable par le réseau, plutôt qu'un chemin pair-à-pair séparé pour chaque spectateur. Catena diffuse le live en MOQT (draft-19, CMAF/CMSF) : le streamer ouvre un listener QUIC, le navigateur arrive en WebTransport et lit — sans plugin ni passerelle. À l'intérieur, le flux est découpé non pas en fragments entiers, mais dans les mêmes parties qu'en LL-HLS, de sorte que la faible latence découle de la conception et non d'un réglage de tampons. C'est une première implémentation, et pour l'instant uniquement en diffusion : la réception en MoQ et la distribution relais dans le cluster sont les étapes suivantes. Mais vous pouvez l'essayer sur votre chaîne dès aujourd'hui : cela s'active par un listener dans la configuration du streamer.

Push RTP et lecture de l'archive en RTSP. Le push MPEG-TS parle désormais RTP et non plus seulement UDP brut : les récepteurs matériels courants acceptent précisément cela, et les réseaux à pertes le réclament aussi. Séparément, l'archive peut maintenant être servie en RTSP avec Range: clock= — la seule façon normalisée dont les systèmes municipaux de vidéosurveillance tiers lisent une archive qui ne leur appartient pas. Jusqu'ici, une telle intégration était impossible par principe.

Les sous-titres de diffusion comme une piste ordinaire. Les sous-titres codés CEA-608/708 qui voyagent à l'intérieur de l'image se transforment maintenant en une piste WebVTT que tous les lecteurs OTT comprennent. L'abonné voit dans votre application les mêmes sous-titres que le spectateur de la même chaîne par le câble — et les exigences d'accessibilité (CVAA aux États-Unis, European Accessibility Act en Europe) sont satisfaites sans seconde entrée ni travail manuel. Le multilinguisme vient gratuitement : le diffuseur met souvent deux ou trois services linguistiques dans une chaîne, et chacun devient une entrée du menu des sous-titres. En détail : Sous-titres codés d'une chaîne de diffusion.

À l'antenne, les sous-titres arrivent de plusieurs façons, et nous les ramenons à une forme unique. Les sous-titres codés CEA-608/708 à l'intérieur des images fonctionnent dès aujourd'hui. Les sous-titres DVB arrivent sous forme d'images, il faut donc en reconnaître le texte : le DVB OCR sort à la prochaine version. Tout l'intérêt de ce travail, c'est qu'à la sortie la forme est unique : d'où que viennent les sous-titres, le spectateur reçoit une piste WebVTT ordinaire, et vous n'avez besoin ni d'une seconde entrée ni d'une chaîne de traitement distincte par format de diffusion.

Le transcodeur : plus dense et sans couture. En MBR, une image d'entrée était décodée autant de fois que vous aviez de qualités de sortie : sur un ensemble FHD/HD/SD, le worker tournait à 0,7–0,8× le temps réel, le bord live prenait du retard et les lecteurs mettaient en tampon. Désormais l'entrée est décodée une fois et l'image décodée est distribuée à tous les encodeurs. L'encodage sur carte graphique est arrivé : avec NVIDIA, toute la chaîne vidéo — décodage, mise à l'échelle et encodage — part sur la carte, et la carte est choisie explicitement ou automatiquement, la moins chargée. Et la reconfiguration a cessé d'être destructrice : le transcodeur ne se reconstruit plus sur du bruit comme le débit mesuré, et quand il faut vraiment reconfigurer — la source a changé de résolution en direct, par exemple — cela se passe sans images perdues, sans IDR forcé et sans rupture de DTS. L'échelle de qualités, les règles audio et les préréglages figurent dans Transcodage et MBR.

Moins d'artefacts pour le spectateur. Le DASH live s'effondrait quelques secondes après l'activation du transcodeur : les pistes d'un même flux étaient découpées sur des grilles qui ne concordaient pas, l'erreur d'arrondi s'accumulait et le bord d'antenne dérivait dans la seconde — les grilles sont désormais alignées. En LL-HLS, les discontinuités sont numérotées une fois et jamais renumérotées après coup, si bien que hls.js ne meurt plus avec discontinuity sequence mismatch ; la piste de vignettes a cessé de produire de fausses discontinuités qui laissaient le lecteur avec un tampon vide. Un flux dont l'encodeur insérait des IDR imprévus ne se disloque plus en segments de 32 à 64 ms. Un changement de description de programme dans la PAT ne fait plus tomber une image à moitié assemblée — cela donnait auparavant un segment sain en apparence avec un trou dans le GOP, une lecture bloquée dans Chromium et un trou définitif dans l'archive. Et les gels du son de plusieurs secondes après chaque bascule d'entrée ont eux aussi disparu.

On voit ce qui se passe. Le tableau de bord répond à la question « est-ce que tout va bien » par des tuiles, des courbes de spectateurs et de trafic et une carte de chaleur des erreurs. Les sessions sont visibles une par une : non pas « tant de spectateurs », mais qui regarde précisément ce flux en ce moment et qui l'a regardé récemment — l'historique ne se perd plus. Le diagnostic de la source montre mieux que « des images ou pas » : erreurs de continuité MPEG-TS, chutes de débit, son disparu ; le secours ne revient à la source prioritaire qu'après une fenêtre propre, et non dès la première image. Si un disque DVR est démonté ou s'il y a une faute de frappe dans le chemin, cela se voit dans l'interface et non dans une ligne WARN d'un log. Et si un streamer n'a pas appliqué les réglages enregistrés, le motif remonte jusqu'à la console — voir Diagnostic du streamer.

Trente mille spectateurs depuis un seul nœud. C'est sans doute le chiffre de cette version. Sur les protocoles à faible latence — HTTP MPEG-TS, RTSP — Flussonic butait autour de mille à deux mille clients simultanés par serveur : au-delà, les décrochages commençaient. Catena 26.08 tient 30 000 spectateurs simultanés sur un nœud avec les mêmes protocoles.

La cause tenait à la comptabilité des sessions. Toutes les sessions d'un nœud vivaient dans une table sous un verrou commun, et les deux chemins chauds y passaient en même temps : les sessions socket — c'est-à-dire précisément les protocoles à faible latence — signalent les octets transférés une fois par seconde chacune, tandis que les spectateurs HTTP cherchent leur enregistrement à chaque requête de segment. À trente mille sessions, cela faisait plus de vingt-six mille prises de verrou par seconde. Or le verrou n'effectuait un travail utile qu'environ 13 % du temps : le système ne s'arrêtait pas faute de puissance, mais parce qu'il faisait la queue derrière lui-même — l'attente atteignait une seconde en moyenne et près de douze secondes en pointe.

Ce n'est pas la supervision qui payait cette file, c'est le spectateur. Tant qu'une session attend le verrou, elle ne vide pas l'anneau d'images, et un anneau sur un flux live dure quelques secondes : un abonné coincé dans la file décrochait complètement. Côté réception, cela se traduisait par des coupures de 700 ms, et une source censée tirer quinze gigabits n'en tirait que trois. Les sessions ont désormais migré vers un stockage en colonnes avec des partitions séparées, la comptabilité des octets a été couverte par des tests avant la modification, et la file a disparu en même temps que le plafond de mille cinq cents clients.

Les avancées ne concernent pas que la diffusion, mais aussi l'enregistrement. L'autre moitié du même travail, c'est un enregistrement soutenu de 20 gigabits par seconde et par serveur. Traduit en caméras, cela fait 10 000 caméras de résolution moyenne sur une seule machine, en enregistrement continu — non pas une valeur de pointe pour une démonstration, mais le régime dans lequel le serveur vit. Pour un opérateur, cela change l'arithmétique du projet : là où l'archive réclamait auparavant une baie entière, quelques machines suffisent désormais, et l'état des disques et l'occupation de l'espace se voient sur tout le cluster d'un coup.

L'archive dans le cluster. Un flux sur un edge dispose maintenant d'un cache d'archive — un interrupteur distinct qui n'exige pas d'enregistrer : l'origin écrit l'archive tandis que les edges, plus proches des spectateurs, gardent ce qui est réellement regardé, si bien que les lectures n'atteignent presque plus les disques de l'origin. Ce que le cache occupe et son taux de succès figurent dans la section DVR du cluster, qui répond au passage à la question « où est passé l'espace » sur une installation aux dizaines de disques. Les spectateurs sont répartis par géographie par les zones CDN.

La VOD est devenue clusterisée. La VOD de fichiers vivait auparavant au niveau d'un seul nœud : pour servir un actif, il fallait savoir sur quelle machine et dans quel répertoire il se trouvait. Désormais central tient le catalogue VOD pour tout le cluster, et les fichiers se téléversent directement depuis le navigateur, sans choisir ni nœud ni disque : l'actif part vers le stockage le plus libre, et les octets vont droit au streamer, sans passer par le plan de contrôle. Les portails qui téléversent eux-mêmes reçoivent des jetons d'envoi. Et les deux choses pour lesquelles les clients en migration reconditionnaient leur contenu fonctionnent maintenant telles quelles : le MBR s'assemble à partir de fichiers voisins, et les sous-titres externes sont repris du fichier voisin — movie.mp4 et movie.srt se lisent sans conversion.

Watcher passe à la technologie de Catena

L'essentiel au sujet de Watcher dans cette version n'est pas une fonction, mais une direction. Watcher a commencé à migrer vers le cœur sur lequel Catena est bâtie : la couche média cesse d'être Flussonic Media Server pour devenir Sapsan. En 26.08, le premier pas visible est franchi — la couche média a désormais son propre nom : le paquet et l'image docker watcher-streamer, derrière lesquels le moteur peut changer sans toucher aux commandes d'installation, à la documentation ni à vos playbooks.

Ce que cela vous apporte. Sapsan est écrit en Rust et prévu pour des densités d'un autre ordre : un enregistrement soutenu de 20 gigabits par seconde et par serveur, ce sont 10 000 caméras de résolution moyenne sur une machine. À mesure que la migration avance, nous attendons une réduction des ressources d'un facteur plusieurs fois pour la même installation : moins de machines pour le même nombre de caméras, moins de baies, une facture d'électricité et de maintenance plus basse. Plus tout ce qui est décrit ci-dessus dans la section Catena — l'introspection de l'état et le modèle en cluster que la couche média actuelle n'a pas.

La migration sera progressive et sans surprise pour les installations en service. Mais si vous souhaitez un produit d'un autre calibre plus tôt, nous vous invitons dans le programme d'adoption anticipée : nous examinerons ensemble votre installation, planifierons la migration et la mènerons avec notre participation.

Voici ce que nous avons fait pour Watcher

Des alertes indiquant que l'enregistreur n'écrit pas son archive — avant que l'enregistrement ne serve.
Des notifications push quand un enregistreur tombe en panne et quand il se rétablit, avec le motif.
On voit combien d'archive consomme chaque caméra et à quel point elle est complète.
Un paquet et une image docker dédiés à la couche média watcher-streamer.
La première installation all-in-one n'échoue plus, et les mises à niveau de la base sont couvertes par des tests.
Les droits de l'utilisateur d'organisation ont rejoint ceux de l'utilisateur ordinaire.
26.08 est la dernière version prenant en charge l'API v2 : tout le nécessaire est déjà dans la v3, et nous aidons à basculer.

L'enregistreur ne se tait plus quand l'archive ne s'écrit pas. C'est le pire de tous les scénarios : dans l'application les caméras sont vertes, la vidéo en direct est là, et l'archive n'est plus écrite depuis des jours — le disque, le DVR ou l'enregistrement se sont arrêtés. Le client l'apprend au moment où l'archive devient nécessaire : après un vol, un litige ou un « qui est passé par là ». La différence avec « l'enregistreur est hors ligne » est fondamentale : hors ligne, cela se voit au moins, tandis que « en ligne mais rien n'est enregistré » est un faux sentiment de sécurité. Watcher y veille désormais et prévient.

Alertes de panne de l'enregistreur — et de son rétablissement. Auparavant, l'utilisateur n'apprenait la panne d'un enregistreur qu'en ouvrant la liste des enregistreurs. Désormais les administrateurs de l'organisation reçoivent un push avec le motif — le réseau entre le cloud et l'enregistreur est indisponible, l'enregistreur ne répond plus à l'API — et lorsqu'il repart, une notification de rétablissement arrive. La mécanique de distribution des push côté backend a été rendue commune à tous les types de notification : la distribution est réessayée en cas d'échec, et les abonnements périmés n'encombrent plus la file.

On voit où part l'archive et à quel point elle est complète. Pour chaque caméra de l'enregistreur, on voit maintenant l'espace occupé par son archive : on peut ajuster la rétention plutôt qu'acheter des disques. Et surtout, on voit l'état de l'archive : « nous gardons 30 jours » et « sur ces 30 jours, l'archive en a réuni 25 avec des trous » sont deux choses différentes, et l'écart ne se cache plus. Une indication d'intégrité de l'archive est apparue, et la profondeur est comptée flux par flux.

La couche média de Watcher a désormais son nom. Le paquet watcher-streamer et l'image docker flussonic/watcher-streamer sont apparus. Cela règle deux choses. La première : sur les nœuds média de cluster, installés par apt install flussonic, l'interface d'administration du serveur média était exposée — elle est maintenant fermée aussi bien dans la livraison par paquet que dans celle par docker. La seconde : pour un système de vidéosurveillance, le moteur est un détail d'implémentation, et il n'y a pas de raison de le prononcer à voix haute dans les commandes d'installation et les playbooks. La couche média porte désormais un nom permanent derrière lequel le moteur peut changer.

La première installation a cessé d'échouer, et la mise à niveau est devenue vérifiable. L'installation all-in-one échouait dès le premier apt install et obligeait à relancer l'installation une seconde fois — reproduit de façon constante sur des Ubuntu 22.04 et 24.04 vierges. La cause a été trouvée et corrigée. Séparément, nous nous sommes attaqués aux migrations de la base : la chaîne avait grandi jusqu'à 193 révisions, une première installation y passait plus de quarante secondes, et — le pire — une mise à niveau avec de vraies données depuis d'anciennes versions n'était vérifiée par rien du tout. Une installation propre part désormais d'un instantané du schéma, et les migrations elles-mêmes sont couvertes par des tests.

Les ressources ne fuient plus, et les listes ne rament plus. La méthode renvoyant la liste des flux laissait des transactions non closes dans PostgreSQL : les connexions restaient collées en idle in transaction, la mémoire fuyait, la charge CPU montait et le service tombait — corrigé. Séparément, nous nous sommes attaqués à la vitesse de l'interface sur les grandes installations : un client avec plus de 1 100 caméras ne pouvait pas parcourir la liste pour vérifier l'état des caméras d'après leurs vignettes — la page cessait de répondre. La liste des caméras, l'ouverture des dossiers, le défilement et la recherche par dossiers ont été accélérés.

Droits et comptes. Les utilisateurs d'organisation pouvaient recevoir moins de droits que les utilisateurs ordinaires ; les deux endroits fonctionnent désormais de la même façon. On peut laisser une note sur un utilisateur d'organisation, et le changement de propriétaire d'une organisation ainsi que la liste des organisations selon les droits sur les caméras ont été réparés.

Le nouveau lecteur avec panneau de débogage. Le nouveau lecteur dispose désormais d'un panneau de débogage avec des courbes et une chronologie des événements. Quand arrive une plainte « ça saccade », il n'est plus nécessaire de la croire sur parole : on voit ce qui s'est réellement passé à la lecture.

26.08 est la dernière version prenant en charge l'API v2. C'est sans doute le point le plus important pour ceux qui ont leurs propres intégrations : la v2 est coupée à la version suivante. L'avertissement s'affiche maintenant directement dans l'interface — les campagnes par e-mail ne fonctionnent pas pour cela, et il nous importe de savoir que l'administrateur l'a vu.

La bonne nouvelle, c'est qu'il y a déjà où aller : tout ce qui existait en v2 se trouve déjà dans l'API v3 — rien à attendre, aucun point d'entrée manquant à négocier. Si vous avez une intégration maison, une facturation ou une application mobile sur la v2, écrivez-nous : nous examinerons vos appels et aiderons à les porter vers la v3 avant la fin du support.

Flussonic Media Server

Cette version apporte à Media Server une seule modification, mais utile à qui possède beaucoup de caméras : l'anti-rebond des déclenchements répétés du détecteur de mouvement. Une caméra mal réglée — sensibilité trop élevée, ou zone couvrant des branches qui bougent — peut émettre sans arrêt un flot d'événements « mouvement commencé », et sur une grande installation ces caméras ensemble ensevelissaient le serveur de gestion sous des milliers d'événements et le clouaient au processeur. Les déclenchements répétés sont maintenant regroupés, ce qui permet de régler les caméras une à une tranquillement plutôt que dans l'urgence.

Et une chose qu'il faut dire clairement : la phase de développement actif de Flussonic Media Server est terminée. Le produit reste pris en charge et nous continuerons de publier des mises à jour de sécurité minimales, mais il n'y aura pas de nouvelles fonctions dedans — tout le développement va aux produits bâtis sur le nouveau cœur.

Nous vous invitons donc à planifier la bascule. Si vous faites de la vidéosurveillance, votre destination est Watcher, qui a commencé dans cette version même à migrer vers ce cœur ; si vous faites de la télévision et de l'OTT, c'est Catena, qui dispose déjà d'un assistant d'import de configuration avec plan avant et rapport après. Une migration, c'est plus qu'un outil, alors nous y participons nous-mêmes : parlez-nous de votre installation et nous déciderons ensemble de ce qui part en premier et de la façon de vérifier l'antenne en chemin.