Configurer, découvrir, relier et superviser NDI depuis une seule interface

Callaba transforme une production live issue de NDI en workflow cloud ou auto-hébergé exploitable : reliez les sources à une frontière contrôlée, vérifiez-les dans le Multiview du navigateur, enregistrez le programme et routez-le vers la destination suivante.

Commencez par le produit et le chemin du signal, pas par l'API. Dans le tableau de bord Callaba authentifié, les opérateurs peuvent définir le nom de la machine, les adresses du Discovery Server et les IP source explicites, puis utiliser l'importation JSON et l'éditeur intégrés pour configurer les réglages NDI avancés sans passer par un terminal. Conservez NDI dans le réseau de production administré, là où il est le plus performant ; utilisez SRT ou un pont compatible sur les segments WAN imprévisibles et confiez à Callaba la réception, la supervision, l'enregistrement, le routage, la lecture et la reprise après ce point de transfert.

Ce qu'est NDI aujourd'hui

NDI (Network Device Interface) est très utilisé dans les workflows de production et AV pour transporter des sources vidéo et audio sur IP sans la complexité du câblage SDI traditionnel. En pratique :

• Il convient parfaitement au routage rapide des sources dans les réseaux administrés.
• Il prend en charge des configurations flexibles de studio et de production distante.
• Il exige néanmoins une conception réseau rigoureuse pour rester stable à grande échelle.

Pour une introduction ciblée et le contexte cloud, consultez ce qu'est le NDI cloud et comment l'utiliser.

Là où NDI est le plus performant

• Production multicaméra et multisource dans des environnements LAN contrôlés.
• Routage simple des sources pour la commutation et la supervision live.
• Mise en service rapide lorsque les équipes ont besoin de plus de souplesse qu'avec un câblage fixe.
• Workflows opérationnels où la rapidité de découverte et de routage des sources est déterminante.

Là où NDI échoue le plus souvent

• Conception réseau non planifiée, avec des problèmes de VLAN, multicast ou capacité.
• Switches surchargés ou hypothèses erronées sur la stabilité de l'uplink.
• Absence de fallback lorsqu'un chemin de source critique tombe en panne.
• Appliquer les conditions d'un LAN à des scénarios WAN sans modèle de pont.

Pour connaître les bases réseau qui évitent de nombreux incidents, utilisez configurer un réseau NDI fonctionnel.

Le streaming NDI en pratique

Le streaming NDI est plus fiable lorsque l'équipe standardise trois éléments : le nommage des sources, la responsabilité des routes et les contrôles preflight. Sans cela, le dépannage devient chaotique pendant les sessions live.

Consultez cette page détaillée pour le contexte opérationnel : streaming NDI.

Preflight NDI minimal

• Vérifiez que toutes les sources NDI attendues sont visibles et correctement nommées.
• Validez la synchronisation entre les principaux chemins de scène.
• Contrôlez la marge réseau avant d'activer tous les graphismes et overlays.
• Confirmez qu'une source de fallback existe pour les flux caméra ou programme critiques.

NDI ou SRT : différence pratique

Comparer NDI et SRT ne consiste pas à désigner un vainqueur. Ils répondent à des contextes de transport différents. NDI est souvent plus performant dans les réseaux de production contrôlés ; SRT convient généralement mieux à la contribution sur un Internet instable lorsqu'une résistance à la perte de paquets est nécessaire.

Si vos sources sont distribuées ou distantes sur des réseaux imprévisibles, utilisez un pont au lieu de supposer que du NDI pur sur WAN se comportera comme sur un LAN local. Référence pratique : configurer un pont NDI sur SRT et de SRT vers NDI cloud.

NDI ou RTMP : des rôles différents

NDI et RTMP ne se remplacent généralement pas directement. NDI sert souvent de couche de transport interne à la production ; RTMP est fréquemment orienté ingest et distribution dans de nombreux chemins de publication. Pour le contexte de l'ingest RTMP, consultez RTMP et ce qu'est un serveur RTMP.

Dans de nombreuses architectures réelles, NDI gère les workflows internes des sources et RTMP la publication vers des endpoints externes. Une séparation claire des rôles réduit la confusion et le temps de réponse aux incidents.

Workflow NDI pour les équipes de streaming live

Un workflow NDI utilisable pour des diffusions récurrentes :

1. Preflight : visibilité et nommage des sources, synchronisation et contrôle des routes.
2. Préparation : exécutez un chemin de production privé avec des scènes réelles.
3. En direct : supervisez la continuité et la stabilité des sources.
4. Reprise : appliquez d'abord la source ou la route de fallback.
5. Revue : consignez le premier signal de panne et une amélioration.

Cette séquence est simple, mais elle évite la plupart des incidents opérationnels évitables.

De NDI vers YouTube et les plateformes externes

Publier des workflows issus de NDI vers des plateformes externes exige généralement une conversion à la frontière. Stabilisez d'abord la production NDI interne, puis définissez les chemins de publication sortants. Exemple : diffuser NDI sur YouTube.

N'optimisez pas la publication sortante avant d'avoir prouvé la stabilité des sources internes. De nombreuses équipes inversent cet ordre et finissent par diagnostiquer la mauvaise couche.

Architectures de référence

Architecture A : priorité au réseau de production local

Sources NDI dans un réseau administré, commutation et composition en production locale, puis chemin de publication sortant contrôlé. Idéal pour des environnements stables on-premise ou proches d'un studio.

Architecture B : contribution distante hybride

La contribution distante utilise SRT lorsque nécessaire, puis est convertie en sources de production détectables par NDI. Cette architecture convient aux équipes qui recherchent à la fois la résilience sur Internet et la souplesse de production NDI. Consultez convertir SRT en appareils NDI détectables dans le cloud.

Architecture C : NDI pour la collaboration et les appels

Les flux NDI sont reliés aux workflows de collaboration ou d'appel lorsque nécessaire. C'est utile pour une production distribuée avec des opérations interactives. Références : envoyer NDI vers des appels vidéo et créer des sorties NDI à partir des participants d'un appel vidéo.

Dépannage pratique

Problème : une source apparaît et disparaît aléatoirement

Vérifiez la segmentation réseau, la charge des switches, les réglages de découverte et la stabilité de l'hôte. Validez avec moins de sources avant de remonter en charge.

Problème : dérive audio/vidéo entre les sources

Utilisez les contrôles de synchronisation et une stratégie de timestamps. Référence pratique : synchroniser les streams NDI en définissant l'offset de timestamp.

Problème : la qualité baisse pendant les passages chargés

Mesurez la marge réseau avec la charge complète des scènes, réduisez ensuite la pression des sources et recommencez le test. Évitez de modifier trop de variables à la fois.

Problème : la qualité du pont WAN est instable

Déplacez les segments instables vers un transport conçu à cet effet, par exemple une contribution SRT, puis remappez-les vers NDI à des frontières contrôlées.

Règles opérationnelles rapides

• Une seule norme de nommage pour toutes les sources NDI.
• Un chemin de fallback pour chaque chaîne de sources critique.
• Un responsable des changements de route pendant les fenêtres live.
• Une revue après opération avec une amélioration concrète.

Ces quatre règles suffisent à réduire une grande partie des incidents NDI récurrents.

Les KPI qui comptent

• Fiabilité du démarrage dans les cohortes de clients cibles.
• Qualité de la continuité et durée des interruptions.
• Temps de reprise après une panne de source ou de route.
• Temps de réponse de l'opérateur entre l'alerte et l'atténuation.

Suivez ces données par classe d'événement. Un tableau de bord KPI unique masque souvent le vrai problème.

Ce que le produit Callaba apporte à un workflow NDI

Callaba comprend la découverte NDI, les adaptateurs, la configuration réseau et les réglages du tableau de bord avec contrôle d'accès, ainsi que Multiview, l'enregistrement, le routage et la lecture. Les opérateurs peuvent configurer la couche NDI de Callaba dans l'UI, sans modifier les fichiers de l'hôte ni utiliser un terminal ; le contrôle externe des caméras et le mélangeur de production restent séparés.

Configurer le réseau NDI depuis l'UI Callaba

Utilisez NDI Tools → NDI configuration pour définir le nom de la machine, une ou plusieurs adresses de Discovery Server et les adresses IP source explicites auxquelles Callaba doit se lier. Pour les options avancées du SDK, importez une configuration JSON ou TXT, ou modifiez le JSON dans le même écran, puis enregistrez-le depuis le tableau de bord.

L'authentification du tableau de bord et les rôles applicatifs déterminent qui peut modifier ces réglages. Les groupes de réception et d'envoi NDI peuvent limiter la visibilité de la découverte, mais ne remplacent ni l'authentification utilisateur, ni le chiffrement, ni un firewall ; conservez les ACL et la segmentation réseau.

Consultez le guide de configuration du réseau NDI ou la référence de l'API de configuration NDI pour accéder à la couche suivante.

• Déploiement cloud ou auto-hébergé : démarrez rapidement ou conservez la couche de réception et d'opérations média sur une infrastructure que vous contrôlez.
• Multiview dans le navigateur : offre aux opérateurs un contrôle visuel partagé sans considérer un socket vert comme la preuve d'une vidéo et d'un audio exploitables.
• Enregistrement et lecture : conservez le programme reçu et validez le fichier indépendamment de l'aperçu live.
• Routage et frontières de protocole : conservez NDI local, contribution WAN résiliente, publication sur les plateformes et lecture pour les spectateurs dans leurs couches respectives.

Deux façons de lancer le produit

Utilisez le guide de lancement dans le cloud lorsque la rapidité et l'infrastructure administrée sont prioritaires. Utilisez le guide d'installation auto-hébergée sous Linux lorsque l'infrastructure, l'emplacement des données ou la proximité réseau doivent rester sous votre contrôle. Validez la même source réelle issue de NDI avec les deux approches.

Utiliser Multiview comme surface d'acceptation

Ouvrez la démo Multiview en direct pour découvrir l'interface destinée à l'opérateur, puis créez une vue d'acceptation privée pour les flux de production. Vérifiez la vidéo, l'audio, l'identité de la source, la continuité, l'enregistrement et au moins une destination downstream.

L'automatisation par API constitue la seconde couche

Une fois le workflow produit validé, utilisez l' API Callaba Engine pour automatiser les endpoints, routes, enregistrements, players et contrôles opérationnels. Ne commencez pas par les objets API avant que la responsabilité des sources, les frontières de transport et le comportement de reprise aient passé une répétition complète.

Questions fréquentes

NDI convient-il à la contribution distante sur Internet ?

NDI est le plus performant dans les réseaux contrôlés. Pour une contribution sur Internet instable, utilisez un modèle de pont avec un transport résilient sur les segments distants.

Dois-je utiliser SRT si j'utilise déjà NDI ?

Pas toujours. SRT devient nécessaire lorsque les conditions de contribution distante sont variables et qu'un comportement de reprise plus robuste est requis sur les chemins Internet.

NDI est-il meilleur que RTMP ?

Ils interviennent généralement sur des couches différentes. NDI est souvent le transport interne de production ; RTMP est souvent le transport à la frontière d'ingest ou de publication.

Quelle est l'amélioration la plus rapide pour la fiabilité NDI ?

Standardisez le nommage des sources, exécutez toujours les contrôles preflight et définissez un fallback chemin de source pour chaque flux critique.

Comment faire évoluer les opérations NDI ?

Faites d'abord évoluer le processus : responsabilité des rôles, fenêtres de changement et cycles cohérents de revue après opération.

Étape suivante

Choisissez une branche de ce hub NDI, effectuez une répétition complète avec la charge réelle des sources et ne promouvez que les changements qui améliorent les métriques de continuité dans des sessions réelles.

Notes pratiques pour l'équipe

À mesure que l'équipe grandit, la plupart des incidents NDI ne sont plus des mystères techniques. Ils proviennent de noms incohérents, de responsabilités floues et de changements de route non testés à l'approche des fenêtres live. Gardez un modèle opérationnel simple et strict. Cela suffit généralement pour passer d'expériences instables à une production prévisible.

Planification de la bande passante et de la capacité pour NDI

Les problèmes de qualité NDI sont souvent des problèmes de capacité déguisés. Avant les productions importantes, estimez le nombre de sources, la plage de bitrate prévue et la charge maximale des transitions. La planification doit aussi intégrer les facteurs non vidéo : trafic de contrôle, overhead de supervision et services en arrière-plan partageant les ressources réseau.

Contrôles pratiques de capacité :

• Mesurez l'utilisation réseau de référence sans transition active du programme.
• Mesurez l'utilisation maximale pendant des cycles complets de changement de scène.
• Consignez l'endroit où apparaissent en premier les pertes de paquets sous charge.
• Définissez une marge d'exploitation sûre, pas seulement la capacité maximale théorique.

Cela rend la montée en charge prévisible et réduit les baisses de qualité « aléatoires » pendant les pics d'un événement.

Sécurité et bonne gestion des accès

Les discussions sur NDI se concentrent souvent sur les performances et négligent le contrôle d'accès. En production, l'exposition des sources et les changements de route non autorisés peuvent créer des risques de qualité et de conformité. Limitez la visibilité des sources aux opérateurs et aux environnements nécessaires.

• Utilisez un accès basé sur les rôles pour les outils de configuration des sources et des routes.
• Séparez les espaces de noms des sources de test et de production.
• Consignez les changements de route critiques avec un timestamp et un responsable.
• Révisez les privilèges d'accès avant les événements à fort impact.

Ces petits contrôles évitent ensuite des fenêtres d'incident beaucoup plus longues.

NDI pour les chaînes 24/7 et de longue durée

Pour les chaînes de longue durée, la discipline de fiabilité compte plus que l'étendue des fonctions. Gardez les graphes de scène légers, standardisez les procédures de redémarrage et surveillez les indicateurs de dérive pendant les longues exécutions. Les stratégies continues sont plus faciles à appliquer lorsque les chaînes sont traitées comme des services répétables et non comme des diffusions uniques.

Checklist de longue durée :

• Contrôles planifiés de la présence des sources et de la cohérence des timestamps.
• Fenêtres de redémarrage définies avec peu d'impact sur le public.
• Alertes automatiques en cas de perte de source et de dégradation durable de la continuité.
• Un chemin de rollback testé vers un ensemble de profils connu et stable.

Modèle de formation des opérateurs

De nombreuses équipes sous-estiment la formation comme levier de fiabilité. Les nouveaux opérateurs ne doivent pas commencer avec une documentation dispersée. Créez un seul parcours d'intégration concis : règles de nommage des sources, responsabilité des routes, fiche preflight, procédure de fallback et format du rapport post-opération. Cela réduit considérablement les erreurs live évitables.

Utilisez de courts exercices pratiques :

• Rétablissez le service avec une source critique manquante.
• Appliquez la route de fallback dans le délai de réponse cible.
• Validez la reprise à la fois dans les contrôles et du côté spectateur.

Checklist de déploiement avant la promotion en production

1. Confirmez que tous les noms de sources respectent la norme et correspondent au runbook.
2. Effectuez une répétition complète avec des overlays réels et des contrôles sur différents clients.
3. Vérifiez les chemins de pont pour la contribution distante lorsqu'ils sont nécessaires.
4. Validez les délais de fallback et de reprise avec un responsable désigné.
5. Gelez les changements non critiques avant la fenêtre de l'événement.

Une promotion sans cette checklist produit souvent des premières exécutions instables et des cycles répétés de hotfix.

Modèle de revue après opération

• Quel a été le premier problème visible par l'utilisateur ?
• Quelle source ou route est tombée en panne en premier ?
• Quelle action a rétabli le service le plus rapidement ?
• Combien de temps a-t-il fallu pour retrouver l'objectif de continuité ?
• Quelle règle du workflow changera avant la prochaine diffusion ?

Gardez cette revue brève et obligatoire. La répétition crée la fiabilité.

Matrice de décision courte

Utilisez cette matrice rapide lors de la planification :

• Studio local, réseau contrôlé : un workflow NDI-first est généralement efficace.
• Contribution distante instable : utilisez un pont SRT pour renforcer la résilience du transport.
• Chemin critique pour l'interaction : routez vers une branche WebRTC lorsque nécessaire.
• Compatibilité de publication sur les plateformes : conservez la frontière RTMP là où elle est requise.

Cette matrice simple évite les mauvais usages de protocoles et ancre les décisions d'architecture dans les contraintes réelles.

Règle pratique finale

Utilisez NDI là où il est le plus performant : des workflows de sources flexibles sur des réseaux administrés avec des opérations rigoureuses. Ne comptez pas uniquement sur NDI pour chaque problème de transport distant. Gardez des frontières claires, des runbooks courts et des chemins de fallback testés. Cette combinaison transforme NDI d'un puissant outil de démonstration en système de production stable.

Contrôle de cinq minutes avant la mise à l'antenne

Avant toute session importante, effectuez un contrôle rapide : confirmez la présence des sources NDI critiques, vérifiez l'audio sur au moins deux destinations, déclenchez une transition de scène planifiée sous charge, testez une source de fallback et validez le démarrage côté spectateur depuis un second client. Cela ne prend que quelques minutes et évite de nombreux échecs dus à une dérive des sources ou à des routes mal configurées.

Séquence de reprise rapide

Lorsqu'un chemin NDI se dégrade pendant la production live, suivez un ordre fixe : basculez vers la source de fallback, validez la continuité côté spectateur, puis examinez les diagnostics réseau et source. Évitez les réglages profonds pendant que le public subit l'impact. Rétablissez d'abord, optimisez ensuite. Cette règle réduit nettement la durée des incidents.

Guide de choix du produit

Considérer un serveur NDI cloud comme une frontière de production contrôlée

Le produit NDI de Callaba relie la production orientée NDI à une contribution routée, à la supervision et à la reprise. Il ne promet pas que la découverte locale traversera Internet public sans changement ; définissez la frontière réseau et utilisez entre les sites un transport adapté tel que SRT.

Éléments à valider dans un workflow de passerelle NDI

• Domaine de découverte : Documentez quelles sources NDI doivent être détectables dans chaque segment réseau et évitez de dépendre de la découverte multicast à travers des liens WAN non contrôlés.
• Point de transfert du transport : Mesurez localement la bande passante et les pertes, puis utilisez un chemin de contribution supervisé lorsque la vidéo doit traverser des sites, des réseaux cloud ou des firewalls.
• Acceptation par l'opérateur : Confirmez le nommage et la découverte des sources dans Callaba ; validez l'audio, la synchronisation et la reprise dans les outils de production downstream avant que le flux n'entre dans le conducteur live.

L'automatisation vient ensuite. Construisez et validez d'abord le pont dans le produit Callaba. Utilisez l'automatisation par API comme seconde couche pour les routes répétables une fois le réseau et les conventions de nommage stabilisés.

Questions sur les serveurs et ponts NDI

Quel est le rôle d'un serveur NDI dans un workflow cloud ?

Il fournit un point contrôlé pour relier, router et observer les flux de production. La découverte et le transport réseau exigent toujours une conception explicite, surtout lorsque les sources et les opérateurs se trouvent sur des sites différents.

Un pont NDI peut-il fonctionner sur Internet public ?

Ne supposez pas que la découverte NDI locale traversera Internet. Transportez le média sur un chemin adapté au WAN, tel que SRT, puis exposez-le au domaine NDI prévu à destination.

Comment dimensionner une passerelle NDI ?

Inventoriez les sources simultanées, les formats, la bande passante et tout traitement de conversion ou d'enregistrement. Testez la composition maximale du programme avec de la marge au lieu d'extrapoler à partir d'une seule source inactive.

Continuer avec le workflow approprié

• Fondamentaux du NDI cloud
• Convertir SRT en appareils NDI cloud

Valider la frontière NDI avec une source réelle

Routez un flux de production via Callaba, vérifiez la découverte et l'état de la route, puis utilisez la démo Multiview séparée pour examiner l'interface d'opérations live de Callaba avant de choisir un déploiement cloud ou Linux.

Lancer Callaba dans le cloud · Installer Callaba sous Linux · Ouvrir la démo Multiview en direct