Une source NDI peut manquer dans la liste, être visible sans pouvoir se connecter, ou être connectée sans image ni son utilisables. Commencez par le symptôme observé :
- Source absente : vérifiez l’émetteur, l’interface et la méthode de découverte.
- Source répertoriée, aucune connexion : vérifiez le transport média, les ports et le routage.
- Connectée, mais sans image ni audio : examinez les médias reçus et le décodeur.
Utilisez le même émetteur et le même récepteur pendant tous les contrôles. Notez leurs noms de source, versions NDI, interfaces réseau et l’heure de chaque test afin de pouvoir comparer les résultats.
Lorsqu’une source NDI est absente, établissez d’abord la découverte
Confirmez que l’application ou l’appareil émetteur est en marche et que sa sortie NDI est activée. Vérifiez ensuite que le récepteur écoute sur l’interface prévue et que les deux extrémités appartiennent au groupe NDI attendu. Une source absente d’une application mais visible dans un outil de diagnostic NDI peut indiquer un problème d’application, d’environnement d’exécution ou de configuration, et non une défaillance générale de la découverte réseau.
Par défaut, NDI utilise mDNS pour la découverte sans configuration. Son adresse multicast IPv4 est 224.0.0.251 sur UDP 5353, et son périmètre se limite à un seul LAN physique ou logique. Sous Windows, un profil réseau Public peut empêcher les réponses mDNS nécessaires à NDI ; dans un réseau de domaine administré, l’administrateur doit autoriser le trafic de découverte. Consultez la référence mDNS officielle de NDI.
Dans un environnement isolé, routé ou cloud, choisissez une architecture de découverte documentée plutôt que de supposer que le multicast le traversera. Une entrée d’hôte manuelle peut interroger une machine distante en TCP 5960, mais elle aide seulement un récepteur à trouver les sources de cette machine. Elle n’établit pas la connectivité média et ne crée pas de capacité réseau.
Configurez Discovery Server sur l’émetteur et le récepteur
NDI Discovery Server est un registre centralisé pour les installations où mDNS est indésirable ou indisponible. Son écoute par défaut utilise TCP 5959, et le service peut être lié à une adresse choisie ou configuré sur un autre port. Les clients doivent utiliser l’adresse et le port du même serveur que ceux prévus par le déploiement.
Le point important dépend du rôle. Un émetteur configuré avec Discovery Server ne s’annonce pas via mDNS ; cet émetteur est visible pour les détecteurs et récepteurs configurés pour ce serveur. Les détecteurs et récepteurs peuvent aussi utiliser mDNS pour les machines locales non configurées avec Discovery Server. Considérez cela comme un choix d’architecture, pas comme un interrupteur à appliquer à un seul hôte puis à oublier.
NDI 5 documente les adresses Discovery Server séparées par des virgules pour les clients pris en charge. Testez l’émetteur, le récepteur et la version NDI exacts lors d’une perte du serveur : les implémentations plus récentes de récepteur-auditeur peuvent exiger une logique client qui détecte un serveur défaillant et se reconnecte. La présentation de Discovery Server et sa référence de configuration font foi pour la version installée.
Utilisez la règle de port correspondant au mode NDI
Le tableau suivant est fonctionnel ; il ne donne pas l’autorisation d’ouvrir une plage sans restriction entre tous les hôtes. Appliquez la règle dans le sens, la zone et avec le nombre de connexions utilisés par l’émetteur et le récepteur déployés. Confirmez la version NDI installée et le mode de réception sélectionné avant de définir une règle de moindre privilège.
| Fonction | Règle de port officielle | Ce que le résultat établit |
|---|---|---|
| Découverte mDNS | UDP 5353 ; multicast IPv4 224.0.0.251 | Le trafic de découverte est présent sur ce LAN, pas que le média est utilisable. |
| Discovery Server | TCP 5959 par défaut ; configurable | Un client peut joindre le point de terminaison du registre, pas qu’il dispose d’un flux. |
| Interrogation d’hôte manuelle | TCP 5960 | Un hôte distant peut être interrogé sur ses sources. |
| Média TCP de base | TCP 5961 et suivants ; au moins un port par connexion | À utiliser lorsque le mode de connexion sélectionné utilise le TCP de base. |
| UDP fiable NDI 5+ | UDP 5960 et suivants ; partagé avec TCP, un port par processus NDI | Le partage de connexion modifie l’hypothèse sur le nombre de ports. |
| Réception Multi-TCP ou UDP | TCP/UDP 6960 et suivants ; au moins un port par connexion | Règle média côté récepteur pour ce mode. |
| Émission Multi-TCP, UDP unicast ou UDP multicast | TCP/UDP 7960 et suivants ; au moins un port par connexion | Règle média côté émetteur pour ce mode. |
La documentation NDI actuelle indique que les versions 4.6 et ultérieures n’utilisent plus de ports éphémères. La référence complète des ports NDI doit accompagner toute modification du pare-feu.
Vérifiez les sous-réseaux et les interfaces réseau
mDNS a une limite de LAN ; le routage, les relais multicast et le comportement des VPN n’en font pas un service de découverte routé général. Utilisez Discovery Server ou la méthode documentée d’adressage manuel du produit concerné lorsque la source et le récepteur se trouvent sur des réseaux contrôlés distincts.
Sur un hôte multi-raccordé, consignez l’interface qui porte la découverte et celle qui transporte le média. Un adaptateur de gestion, une connexion Wi-Fi ou un VPN peut faire apparaître une source depuis le mauvais réseau ou faire partir les réponses par une route que le récepteur ne peut pas utiliser. Attribuez une adresse stable à l’interface média, évitez les noms de machines en double et rendez la préférence d’interface déterministe avant l’événement.
Source répertoriée mais sans image ni son
Une source répertoriée signifie que le récepteur a obtenu une annonce de source ou une entrée de registre. Cela ne prouve pas que le transport sélectionné peut s’ouvrir, que le chemin de retour est autorisé ou que le récepteur peut décoder la vidéo. Examinez l’URL et le port de la source active, l’état de connexion, le mode de réception, la présence de vidéo, la présence d’audio et la sortie rendue.
L’outil NDI Discovery actuel peut afficher les émetteurs enregistrés, l’adresse/le port de la source et des données de suivi du récepteur, notamment l’état de connexion, le mode de réception et la présence de vidéo ou d’audio. Utilisez ces éléments pour choisir le contrôle suivant. Une sonde TCP sur le port 5959 établit uniquement la joignabilité de Discovery Server ; elle ne prouve pas une session média NDI.
Vérifier si mDNS atteint cette interface Linux
sudo tcpdump -ni <media-interface> udp port 5353Résultat attendu : des paquets mDNS apparaissent tandis que la découverte est active sur cette interface. Ces paquets confirment le trafic de découverte sur cette interface, et non l’accès aux ports média sélectionnés. Exécutez la capture de paquets et les diagnostics de pare-feu uniquement avec l’autorisation requise pour ce réseau de production.
Vérifier la joignabilité de Discovery Server depuis Windows
Test-NetConnection <discovery-server> -Port 5959Résultat attendu : une connexion TCP réussie à l’adresse et au port du serveur configuré. Cela confirme l’accessibilité d’un écouteur TCP. Vérifiez l’enregistrement, l’appartenance au groupe et la livraison média dans l’application NDI.
Vérifiez les sources découvertes dans Callaba
Callaba Cloud NDI donne à l’opérateur un endroit pour configurer la découverte, les interfaces et les adaptateurs, et son workflow des appareils découverts peut afficher l’inventaire actuel. C’est utile pour distinguer une entrée d’appareil enregistrée d’une source actuellement découverte par l’instance sélectionnée. Vérifiez la source sélectionnée au récepteur final ainsi que dans l’inventaire.
Une fois la source à jour et le chemin média vérifié, configurez l’adaptateur NDI ou la tâche aval dont la production a réellement besoin. Contrôlez sa sortie séparément dans le récepteur cible ; un résultat de découverte est une donnée d’entrée pour cette décision, pas le test d’acceptation.
Consignez la configuration fonctionnelle
- Source absente : établissez la sortie de l’émetteur, le groupe, la carte réseau sélectionnée et la configuration mDNS ou Discovery Server.
- Source répertoriée, aucune session : consignez l’adresse de la source, le mode de transport et la règle média active ; examinez le pare-feu des extrémités et le routage dans les deux sens.
- Session, sans images utilisables : examinez le mode de réception, le débit binaire, la présence vidéo/audio, la compatibilité de décodage et la sortie réellement rendue.
- Avant l’acceptation : répétez le chemin concluant sur les interfaces de production et consignez la configuration, le nom de la source et les éléments de preuve pour le runbook.
Étapes suivantes
Utilisez Cloud NDI pour configurer le chemin de découverte et d’interface prévu, puis consultez la référence des appareils découverts lorsque le workflow requiert un contrôle d’inventaire. Conservez le test d’acceptation de production au récepteur final : image en mouvement, audio attendu et chemin de sortie sélectionné.
