O sursă NDI poate lipsi din listă, poate fi vizibilă fără să se poată conecta sau poate fi conectată fără imagine ori sunet utilizabil. Începeți cu simptomul observat:
- Sursă lipsă: verificați emițătorul, interfața și metoda de descoperire.
- Sursă listată, fără conexiune: verificați transportul media, porturile și ruta.
- Conectată, dar fără imagine sau audio: inspectați media recepționată și decodorul.
Folosiți același emițător și același receptor pentru toate verificările. Notați numele surselor, versiunile NDI, interfețele de rețea și ora fiecărui test, astfel încât să puteți compara rezultatele.
Când o sursă NDI lipsește, demonstrați mai întâi descoperirea
Confirmați că aplicația sau dispozitivul emițător rulează și are ieșirea NDI activată. Apoi verificați că receptorul urmărește interfața intenționată și că ambele capete aparțin grupului NDI așteptat. O sursă absentă într-o aplicație, dar vizibilă într-un instrument de diagnostic NDI, poate indica o problemă de aplicație/runtime sau configurare, nu o defecțiune de descoperire la nivelul întregii rețele.
Implicit, NDI folosește mDNS pentru descoperire fără configurare. Adresa sa multicast IPv4 este 224.0.0.251 pe UDP 5353 și este limitată la o singură LAN fizică sau logică. În Windows, un profil de rețea Public poate împiedica răspunsurile mDNS de care NDI are nevoie; în rețele de domeniu administrate, administratorul trebuie să permită traficul de descoperire. Consultați referința oficială NDI mDNS.
Pentru un mediu izolat, rutat sau cloud, alegeți o arhitectură de descoperire documentată în loc să presupuneți că multicastul o va traversa. O intrare manuală de host poate interoga o mașină la distanță pe TCP 5960, însă ajută receptorul să găsească numai sursele de pe acea mașină. Nu stabilește conectivitatea media și nu creează capacitate de rețea.
Configurați Discovery Server la emițător și receptor
NDI Discovery Server este un registru centralizat pentru instalații în care mDNS este nedorit sau indisponibil. Listenerul său implicit este TCP 5959, iar serviciul poate fi asociat unei adrese alese sau configurat pentru un alt port. Clienții trebuie să utilizeze aceeași adresă de server și același port prevăzute de implementare.
Detaliul important depinde de rol. Un emițător configurat cu Discovery Server nu se anunță prin mDNS; acel emițător este vizibil pentru finders și receptoarele configurate pentru acel server. Finders și receptoarele pot folosi, de asemenea, mDNS pentru mașinile locale care nu sunt configurate pentru Discovery Server. Tratați aceasta ca pe o alegere de proiectare, nu ca pe un comutator aplicat unui singur host și apoi uitat.
NDI 5 documentează adrese Discovery Server separate prin virgulă pentru clienții acceptați. Testați emițătorul, receptorul și versiunea NDI exacte în condițiile unei pierderi de server: implementările mai noi de receiver-listener pot necesita logică de client pentru a detecta un server eșuat și a se reconecta. Prezentarea Discovery Server și referința sa de configurare sunt sursa de adevăr pentru versiunea instalată.
Folosiți regula de port potrivită modului NDI
Acesta este un tabel funcțional, nu permisiunea de a permite un interval nerestricționat între hosturi. Aplicați regula în direcția, zona și numărul de conexiuni utilizate și confirmați versiunea NDI și modul de recepție înaintea unei reguli cu privilegiu minim.
| Funcție | Regulă oficială | Ce demonstrează |
|---|---|---|
| Descoperire mDNS | UDP 5353; multicast IPv4 224.0.0.251 | Trafic de descoperire în LAN, nu media utilizabilă. |
| Discovery Server | TCP 5959 implicit; configurabil | Clientul atinge registrul, nu un flux. |
| Interogare manuală host | TCP 5960 | Un host la distanță poate fi întrebat despre surse. |
| Media TCP de bază | TCP 5961 și peste; un port pe conexiune | Pentru modul TCP de bază. |
| UDP fiabil NDI 5+ | UDP 5960 și peste; partajat cu TCP, un port pe proces NDI | Partajarea schimbă numărul presupus. |
| Recepție Multi-TCP sau UDP | TCP/UDP 6960 și peste; un port pe conexiune | Regula media pentru receptor. |
| Trimitere Multi-TCP, UDP unicast sau multicast | TCP/UDP 7960 și peste; un port pe conexiune | Regula media pentru emițător. |
Documentația NDI actuală spune că versiunile 4.6+ nu mai folosesc porturi efemere. Includeți referința completă de porturi NDI la orice modificare de firewall.
Verificați subrețelele și interfețele de rețea
mDNS are o limită de LAN; rutarea, releele multicast și comportamentul VPN nu îl transformă într-un serviciu general de descoperire rutată. Folosiți Discovery Server sau metoda documentată de adresare manuală a produsului participant atunci când sursa și receptorul sunt în rețele controlate separate.
Pe un host cu mai multe interfețe, înregistrați care interfață deține descoperirea și care transportă media. Un adaptor de management, o conexiune Wi-Fi sau un VPN poate face ca o sursă să apară din rețeaua greșită ori ca răspunsurile să plece pe o rută pe care receptorul nu o poate utiliza. Dați interfeței media adresare stabilă, evitați numele de mașină duplicate și faceți preferința de interfață deterministă înainte de eveniment.
Sursă listată, dar fără imagine sau sunet
O sursă listată înseamnă că receptorul a obținut un anunț de sursă sau o intrare în registru. Nu demonstrează că transportul selectat se poate deschide, că este permisă calea de retur sau că receptorul poate decoda videoclipul. Inspectați URL-ul și portul active ale sursei, starea conexiunii, modul de recepție, prezența video, prezența audio și ieșirea redată.
Instrumentul NDI Discovery actual poate afișa emițători înregistrați, adresa/portul sursei și date de monitorizare a receptorului, inclusiv starea conexiunii, modul de recepție și prezența video sau audio. Folosiți aceste dovezi pentru a alege următoarea verificare. O probă TCP la portul 5959 demonstrează numai accesibilitatea la Discovery Server; nu demonstrează o sesiune media NDI.
Verificați dacă mDNS ajunge la această interfață Linux
sudo tcpdump -ni <media-interface> udp port 5353Rezultat așteptat: pachetele mDNS apar în timp ce descoperirea este activă pe acea interfață. Aceste pachete confirmă traficul de descoperire la această interfață, nu accesul la porturile media selectate. Efectuați captura de pachete și diagnosticarea firewallului numai cu autorizația cerută pentru acea rețea de producție.
Verificați accesibilitatea Discovery Server din Windows
Test-NetConnection <discovery-server> -Port 5959Rezultat așteptat: o conexiune TCP reușită la adresa și portul configurate ale serverului. Aceasta confirmă un listener TCP accesibil. Verificați înregistrarea, apartenența la grup și livrarea media în aplicația NDI.
Verificați sursele descoperite în Callaba
Callaba Cloud NDI oferă operatorului un loc pentru configurarea descoperirii, interfețelor și adaptoarelor, iar fluxul său de dispozitive descoperite poate arăta inventarul curent. Acest lucru este util pentru a separa o intrare de dispozitiv salvată de o sursă descoperită în prezent de instanța selectată. Verificați sursa selectată la receptorul final, precum și în inventar.
După ce sursa este actuală și traseul media a fost verificat, configurați adaptorul NDI sau lucrarea downstream de care producția are nevoie cu adevărat. Verificați ieșirea sa separat în receptorul țintă; un rezultat de descoperire este o intrare pentru acea decizie, nu testul de acceptanță.
Înregistrați configurația funcțională
- Sursă lipsă: demonstrați ieșirea, grupul, NIC-ul și mDNS sau Discovery Server.
- Listată, fără sesiune: notați adresă, mod și regulă; inspectați firewall și rutarea în ambele direcții.
- Sesiune fără cadre utile: inspectați modul, bitrate, video/audio, decodarea și ieșirea redată.
- Înainte de acceptare: repetați traseul pe interfețele de producție și înregistrați configurația, numele și dovezile în runbook.
Pașii următori
Folosiți Cloud NDI pentru traseul de descoperire și interfață, apoi citiți referința dispozitivelor descoperite pentru inventar. Testul de acceptanță rămâne la receptorul final: imagine în mișcare, audio așteptat și traseul de ieșire selectat.
