Eine NDI-Quelle kann in der Liste fehlen, sichtbar sein aber keine Verbindung herstellen, oder verbunden sein ohne nutzbares Bild oder Ton. Beginnen Sie mit dem beobachteten Symptom:
- Quelle fehlt: Sender, Schnittstelle und Erkennungsmethode prüfen.
- Quelle gelistet, keine Verbindung: Medientransport, Ports und Route prüfen.
- Verbunden, aber kein Bild oder Ton: empfangene Medien und Decoder prüfen.
Verwenden Sie bei allen Prüfungen denselben Sender und Empfänger. Notieren Sie Quellnamen, NDI-Versionen, Netzwerkschnittstellen und die Zeit jedes Tests, damit sich Ergebnisse vergleichen lassen.
Fehlt eine NDI-Quelle, weisen Sie zuerst die Erkennung nach
Bestätigen Sie, dass die Senderanwendung oder das Gerät läuft und sein NDI-Ausgang aktiviert ist. Prüfen Sie dann, ob der Empfänger auf der vorgesehenen Schnittstelle sucht und beide Endpunkte zur erwarteten NDI-Gruppe gehören. Eine Quelle, die in einer Anwendung fehlt, aber in einem NDI-Diagnosewerkzeug sichtbar ist, kann auf ein Anwendungs-, Runtime- oder Konfigurationsproblem hinweisen und nicht auf einen netzwerkweiten Erkennungsfehler.
Standardmäßig nutzt NDI mDNS für die konfigurationsfreie Erkennung. Die IPv4-Multicast-Adresse ist 224.0.0.251 auf UDP 5353 und auf ein physisches oder logisches LAN beschränkt. Unter Windows kann ein öffentliches Netzwerkprofil die von NDI benötigten mDNS-Antworten verhindern; in verwalteten Domänennetzwerken muss die Administration den Erkennungsverkehr erlauben. Siehe die offizielle NDI-mDNS-Referenz.
Wählen Sie für eine isolierte, geroutete oder Cloud-Umgebung ein dokumentiertes Erkennungsdesign, statt anzunehmen, dass Multicast sie durchquert. Ein manueller Hosteintrag kann einen entfernten Rechner auf TCP 5960 abfragen, hilft aber nur einem Empfänger, die Quellen auf diesem Rechner zu finden. Er stellt weder Medienkonnektivität her noch schafft er Netzwerkkapazität.
Discovery Server auf Sender und Empfänger konfigurieren
NDI Discovery Server ist ein zentralisiertes Register für Installationen, in denen mDNS unerwünscht oder nicht verfügbar ist. Sein Standard-Listener ist TCP 5959; der Dienst kann an eine gewählte Adresse gebunden oder mit einem anderen Port konfiguriert werden. Clients müssen dieselbe Serveradresse und denselben Port verwenden, die für die jeweilige Bereitstellung vorgesehen sind.
Entscheidend ist die jeweilige Rolle. Ein mit Discovery Server konfigurierter Sender kündigt sich nicht über mDNS an; er ist für Suchclients und Empfänger sichtbar, die für diesen Server konfiguriert sind. Suchclients und Empfänger können weiterhin mDNS für lokale Rechner verwenden, die nicht für Discovery Server eingerichtet sind. Behandeln Sie dies als Designentscheidung, nicht als Schalter, den man auf einem Host umlegt und dann vergisst.
NDI 5 dokumentiert kommagetrennte Discovery-Server-Adressen für unterstützte Clients. Testen Sie den genauen Sender, Empfänger und die NDI-Version bei einem Serverausfall: Neuere Receiver-Listener-Implementierungen können Clientlogik erfordern, die einen ausgefallenen Server erkennt und die Verbindung wiederherstellt. Die Discovery-Server-Übersicht und ihre Konfigurationsreferenz sind die maßgeblichen Quellen für die installierte Version.
Nutzen Sie die zum NDI-Modus passende Portregel
Die folgende Tabelle ist funktional zu lesen, nicht als Erlaubnis, zwischen allen Hosts einen uneingeschränkten Bereich freizugeben. Wenden Sie die Regel in Richtung, Zone und Verbindungsanzahl des eingesetzten Senders und Empfängers an. Bestätigen Sie installierte NDI-Version und ausgewählten Empfangsmodus, bevor Sie eine Least-Privilege-Regel erstellen.
| Funktion | Offizielle Portregel | Was das Ergebnis belegt |
|---|---|---|
| mDNS-Erkennung | UDP 5353; IPv4-Multicast 224.0.0.251 | Erkennungsverkehr ist in diesem LAN vorhanden, nicht dass Medien nutzbar sind. |
| Discovery Server | Standardmäßig TCP 5959; konfigurierbar | Ein Client erreicht den Registerendpunkt, nicht dass er einen Stream hat. |
| Manuelle Hostabfrage | TCP 5960 | Ein entfernter Host kann nach Quellen abgefragt werden. |
| Basis-TCP-Medien | TCP 5961 und höher; mindestens ein Port pro Verbindung | Verwenden, wenn der gewählte Modus Basis-TCP nutzt. |
| NDI 5+ Reliable UDP | UDP 5960 und höher; gemeinsam mit TCP, ein Port pro NDI-Prozess | Verbindungsfreigabe ändert die Annahme zur Anzahl. |
| Multi-TCP- oder UDP-Empfang | TCP/UDP 6960 und höher; mindestens ein Port pro Verbindung | Empfängerseitige Medienregel für diesen Modus. |
| Multi-TCP-, Unicast-UDP- oder Multicast-UDP-Senden | TCP/UDP 7960 und höher; mindestens ein Port pro Verbindung | Senderseitige Medienregel für diesen Modus. |
Die aktuelle NDI-Dokumentation sagt, dass Versionen 4.6 und neuer keine ephemeren Ports mehr nutzen. Die vollständige NDI-Portreferenz sollte jede Firewall-Änderung begleiten.
Subnetze und Netzwerkschnittstellen prüfen
mDNS hat eine LAN-Grenze; Routing, Multicast-Relays und VPN-Verhalten machen daraus keinen allgemeinen gerouteten Erkennungsdienst. Nutzen Sie Discovery Server oder die dokumentierte Methode zur manuellen Adressierung des jeweiligen Produkts, wenn Quelle und Empfänger in getrennten kontrollierten Netzwerken liegen.
Notieren Sie bei einem Host mit mehreren Schnittstellen, welche Schnittstelle für die Erkennung zuständig ist und welche die Medien überträgt. Ein Verwaltungsadapter, eine WLAN-Verbindung oder ein VPN kann eine Quelle aus dem falschen Netz erscheinen lassen oder Antworten über eine Route senden lassen, die der Empfänger nicht nutzen kann. Weisen Sie der Medienschnittstelle eine stabile Adresse zu, vermeiden Sie doppelte Rechnernamen und legen Sie die Schnittstellenpräferenz vor dem Ereignis eindeutig fest.
Quelle gelistet, aber kein Bild oder Ton
Eine gelistete Quelle bedeutet, dass der Empfänger eine Quellenankündigung oder einen Registereintrag erhalten hat. Das beweist weder, dass sich der ausgewählte Transport öffnen kann, dass der Rückweg erlaubt ist, noch dass der Empfänger das Video dekodieren kann. Prüfen Sie aktive Quell-URL und Port, Verbindungsstatus, Empfangsmodus, Vorhandensein von Video und Audio sowie die gerenderte Ausgabe.
Das aktuelle NDI-Discovery-Tool kann registrierte Sender, Quelladresse/-port und Empfängerüberwachungsdaten einschließlich Verbindungsstatus, Empfangsmodus sowie Video- oder Audiopräsenz anzeigen. Nutzen Sie diese Hinweise für den nächsten Test. Ein TCP-Test auf Port 5959 beweist nur die Erreichbarkeit des Discovery Server, keine NDI-Mediensitzung.
Prüfen, ob mDNS diese Linux-Schnittstelle erreicht
sudo tcpdump -ni <media-interface> udp port 5353Erwartetes Ergebnis: Während die Erkennung auf dieser Schnittstelle aktiv ist, erscheinen mDNS-Pakete. Diese Pakete bestätigen Erkennungsverkehr an dieser Schnittstelle, nicht den Zugriff auf die gewählten Medienports. Führen Sie Paketmitschnitt und Firewall-Diagnose nur mit der für das Produktionsnetz erforderlichen Autorisierung aus.
Discovery-Server-Erreichbarkeit von Windows prüfen
Test-NetConnection <discovery-server> -Port 5959Erwartetes Ergebnis: eine erfolgreiche TCP-Verbindung zur konfigurierten Serveradresse und zum Port. Das bestätigt einen erreichbaren TCP-Listener. Prüfen Sie Registrierung, Gruppenmitgliedschaft und Medienübertragung in der NDI-Anwendung.
Erkannte Quellen in Callaba prüfen
Callaba Cloud NDI bietet Operatoren einen Ort, um Erkennung, Schnittstellen und Adapter zu konfigurieren; sein Workflow für erkannte Geräte kann das aktuelle Inventar anzeigen. Das hilft dabei, einen gespeicherten Geräteeintrag von einer Quelle zu unterscheiden, die von der gewählten Instanz gerade erkannt wird. Prüfen Sie die gewählte Quelle am finalen Empfänger ebenso wie im Inventar.
Sobald die Quelle verfügbar ist und der Medienweg verifiziert wurde, konfigurieren Sie den NDI-Adapter oder den nachgelagerten Job, den die Produktion tatsächlich braucht. Prüfen Sie dessen Ausgabe separat am Ziel-Empfänger; ein Erkennungsergebnis ist eine Grundlage für diese Entscheidung, nicht der Abnahmetest.
Die funktionierende Konfiguration dokumentieren
- Quelle fehlt: Senderausgabe, Gruppe, ausgewählte NIC und mDNS- oder Discovery-Server-Konfiguration nachweisen.
- Quelle gelistet, keine Sitzung: Quelladresse, Transportmodus und aktive Medienregel dokumentieren; Endpoint-Firewall und Routing in beide Richtungen prüfen.
- Sitzung, keine nutzbaren Frames: Empfangsmodus, Bitrate, Video-/Audiopräsenz, Dekodierkompatibilität und tatsächlich gerenderte Ausgabe prüfen.
- Vor Abnahme: den erfolgreichen Weg auf den Produktionsschnittstellen wiederholen und Konfiguration, Quellname und Nachweise für das Runbook dokumentieren.
Nächste Schritte
Nutzen Sie Cloud NDI, um die vorgesehene Erkennungs- und Schnittstellenroute zu konfigurieren, und lesen Sie anschließend die Referenz zu erkannten Geräten, wenn der Workflow eine Inventarprüfung braucht. Führen Sie den Produktionsabnahmetest am finalen Empfänger durch: fortlaufendes Bild, erwarteter Ton und der ausgewählte Ausgabepfad.
