Una fonte NDI può non comparire nell’elenco, essere visibile ma non riuscire a connettersi, oppure essere connessa senza immagini o audio utilizzabili. Partite dal sintomo che osservate:
- Fonte assente: controllate il mittente, l’interfaccia e il metodo di individuazione.
- Fonte elencata, nessuna connessione: controllate il trasporto dei media, le porte e il percorso.
- Connessa, ma senza immagini o audio: esaminate i media ricevuti e il decoder.
Usate lo stesso mittente e ricevitore durante tutti i controlli. Annotate i nomi delle fonti, le versioni NDI, le interfacce di rete e l’ora di ciascun test per poter confrontare i risultati.
Quando manca una fonte NDI, provate prima l’individuazione
Confermate che l’applicazione o il dispositivo mittente sia in esecuzione e abbia abilitato l’uscita NDI. Quindi verificate che il ricevitore stia cercando sull’interfaccia prevista e che entrambi gli endpoint appartengano al gruppo NDI atteso. Una fonte assente in un’applicazione ma visibile in uno strumento diagnostico NDI può indicare un problema dell’applicazione, del runtime o della configurazione, non un guasto dell’individuazione a livello di rete.
Per impostazione predefinita, NDI usa mDNS per l’individuazione senza configurazione. Il suo indirizzo multicast IPv4 è 224.0.0.251 su UDP 5353 ed è limitato a una sola LAN fisica o logica. In Windows, un profilo di rete Pubblico può impedire le risposte mDNS necessarie a NDI; nelle reti di dominio gestite, l’amministratore deve consentire il traffico di individuazione. Consultate il riferimento mDNS ufficiale di NDI.
In un ambiente isolato, instradato o cloud, scegliete un progetto di individuazione documentato invece di presumere che il multicast lo attraversi. Una voce host manuale può interrogare una macchina remota su TCP 5960, ma aiuta soltanto un ricevitore a trovare le fonti su quella macchina. Non stabilisce la connettività dei media né crea capacità di rete.
Configurate Discovery Server sul mittente e sul ricevitore
NDI Discovery Server è un registro centralizzato per installazioni in cui mDNS è indesiderato o non disponibile. Il listener predefinito è TCP 5959, e il servizio può essere associato a un indirizzo scelto o configurato su una porta diversa. I client devono usare lo stesso indirizzo e porta del server previsti dalla distribuzione.
Il dettaglio importante dipende dal ruolo. Un mittente configurato con Discovery Server non si annuncia tramite mDNS; quel mittente è visibile a finder e ricevitori configurati per quel server. Finder e ricevitori possono anche usare mDNS per macchine locali che non sono configurate per Discovery Server. Consideratela una scelta progettuale, non un interruttore da applicare a un host e poi dimenticare.
NDI 5 documenta indirizzi Discovery Server separati da virgole per i client supportati. Testate il mittente, il ricevitore e la versione NDI esatti in caso di perdita del server: le implementazioni più recenti di receiver-listener possono richiedere una logica client che rilevi un server non disponibile e si riconnetta. La panoramica di Discovery Server e il suo riferimento di configurazione sono la fonte autorevole per la versione installata.
Usate la regola delle porte che corrisponde al modo NDI
Quella che segue è una tabella funzionale, non un’autorizzazione a consentire un intervallo senza restrizioni tra ogni host. Applicate la regola nella direzione, nella zona e con il numero di connessioni usati dal mittente e dal ricevitore distribuiti. Confermate la versione NDI installata e la modalità di ricezione selezionata prima di creare una regola di privilegio minimo.
| Funzione | Regola ufficiale delle porte | Cosa dimostra il risultato |
|---|---|---|
| Individuazione mDNS | UDP 5353; multicast IPv4 224.0.0.251 | Il traffico di individuazione è presente su quella LAN, non che i media siano utilizzabili. |
| Discovery Server | TCP 5959 per impostazione predefinita; configurabile | Un client può raggiungere l’endpoint del registro, non che disponga di uno stream. |
| Query host manuale | TCP 5960 | Un host remoto può essere interrogato sulle fonti. |
| Media TCP di base | TCP 5961 e successivi; almeno una porta per connessione | Da usare quando la modalità di connessione selezionata usa TCP di base. |
| UDP affidabile NDI 5+ | UDP 5960 e successivi; condiviso con TCP, una porta per processo NDI | La condivisione della connessione modifica l’ipotesi sul conteggio. |
| Ricezione Multi-TCP o UDP | TCP/UDP 6960 e successivi; almeno una porta per connessione | Regola media lato ricevitore per quella modalità. |
| Invio Multi-TCP, UDP unicast o UDP multicast | TCP/UDP 7960 e successivi; almeno una porta per connessione | Regola media lato mittente per quella modalità. |
La documentazione NDI corrente afferma che le versioni 4.6 e successive non usano più porte effimere. Il riferimento completo alle porte NDI deve accompagnare ogni modifica del firewall.
Controllate subnet e interfacce di rete
mDNS ha un confine LAN; routing, relè multicast e comportamento delle VPN non lo trasformano in un servizio generale di individuazione instradato. Usate Discovery Server o il metodo di indirizzamento manuale documentato del prodotto interessato quando fonte e ricevitore si trovano su reti controllate separate.
Su un host con più interfacce, registrate quale interfaccia gestisce l’individuazione e quale trasporta i media. Un adattatore di gestione, una connessione Wi-Fi o una VPN può far apparire una fonte dalla rete sbagliata o far uscire le risposte su un percorso che il ricevitore non può usare. Assegnate indirizzi stabili all’interfaccia media, evitate nomi di macchine duplicati e rendete deterministica la preferenza dell’interfaccia prima dell’evento.
Fonte elencata ma senza immagini o audio
Una fonte elencata significa che il ricevitore ha ottenuto un annuncio della fonte o una voce del registro. Non dimostra che il trasporto selezionato possa aprirsi, che il percorso di ritorno sia consentito o che il ricevitore possa decodificare il video. Esaminate l’URL e la porta della fonte attiva, lo stato della connessione, la modalità di ricezione, la presenza del video, la presenza dell’audio e l’output renderizzato.
Lo strumento NDI Discovery corrente può visualizzare mittenti registrati, indirizzo/porta della fonte e dati di monitoraggio del ricevitore, inclusi stato della connessione, modalità di ricezione e presenza di video o audio. Usate queste evidenze per scegliere il controllo successivo. Una sonda TCP sulla porta 5959 dimostra solo la raggiungibilità di Discovery Server; non dimostra una sessione media NDI.
Controllare se mDNS raggiunge questa interfaccia Linux
sudo tcpdump -ni <media-interface> udp port 5353Risultato atteso: i pacchetti mDNS compaiono mentre l’individuazione è attiva su quell’interfaccia. Questi pacchetti confermano il traffico di individuazione su questa interfaccia, non l’accesso alle porte media selezionate. Eseguite acquisizioni di pacchetti e diagnostica del firewall solo con l’autorizzazione richiesta per quella rete di produzione.
Controllare la raggiungibilità di Discovery Server da Windows
Test-NetConnection <discovery-server> -Port 5959Risultato atteso: una connessione TCP riuscita all’indirizzo e alla porta del server configurato. Questo conferma un listener TCP raggiungibile. Controllate registrazione, appartenenza al gruppo e consegna dei media nell’applicazione NDI.
Controllate le fonti individuate in Callaba
Callaba Cloud NDI offre all’operatore un punto in cui configurare individuazione, interfacce e adattatori, e il suo flusso di lavoro dei dispositivi individuati può mostrare l’inventario corrente. È utile per distinguere una voce di dispositivo salvata da una fonte attualmente individuata dall’istanza selezionata. Controllate la fonte selezionata nel ricevitore finale oltre che nell’inventario.
Una volta che la fonte è aggiornata e il percorso media è stato verificato, configurate l’adattatore NDI o il job a valle di cui la produzione ha effettivamente bisogno. Controllate il suo output separatamente nel ricevitore di destinazione; un risultato di individuazione è un input per quella decisione, non il test di accettazione.
Registrate la configurazione funzionante
- Fonte assente: provate l’output del mittente, il gruppo, la NIC selezionata e la configurazione mDNS o Discovery Server.
- Fonte elencata, nessuna sessione: registrate indirizzo della fonte, modalità di trasporto e regola media attiva; esaminate firewall degli endpoint e routing in entrambe le direzioni.
- Sessione, nessun fotogramma utilizzabile: esaminate modalità di ricezione, bitrate, presenza video/audio, compatibilità di decodifica e output effettivamente renderizzato.
- Prima dell’accettazione: ripetete il percorso riuscito sulle interfacce di produzione e registrate configurazione, nome della fonte ed evidenze per il runbook.
Passaggi successivi
Usate Cloud NDI per configurare il percorso di individuazione e di interfaccia previsto, quindi consultate il riferimento dei dispositivi individuati quando il flusso di lavoro richiede un controllo dell’inventario. Mantenete il test di accettazione della produzione sul ricevitore finale: immagini in movimento, audio previsto e percorso di output selezionato.
