Źródło NDI może nie pojawiać się na liście, być widoczne, lecz nie móc się połączyć, albo być połączone bez użytecznego obrazu czy dźwięku. Zacznij od widocznego objawu:
- Brak źródła: sprawdź nadajnik, interfejs i metodę wykrywania.
- Źródło jest na liście, brak połączenia: sprawdź transport mediów, porty i trasę.
- Połączono, ale brak obrazu lub dźwięku: sprawdź odebrane media i dekoder.
Podczas wszystkich kontroli używaj tego samego nadajnika i odbiornika. Zanotuj ich nazwy źródeł, wersje NDI, interfejsy sieciowe oraz czas każdej próby, aby móc porównać wyniki.
Gdy brakuje źródła NDI, najpierw potwierdź wykrywanie
Potwierdź, że aplikacja lub urządzenie nadawcze działa i ma włączone wyjście NDI. Następnie sprawdź, czy odbiornik nasłuchuje na zamierzonym interfejsie i czy oba punkty końcowe należą do oczekiwanej grupy NDI. Źródło niewidoczne w jednej aplikacji, lecz widoczne w narzędziu diagnostycznym NDI, może oznaczać problem aplikacji, środowiska uruchomieniowego lub konfiguracji, a nie ogólną awarię wykrywania w sieci.
Domyślnie NDI używa mDNS do bezkonfiguracyjnego wykrywania. Jego adres multicast IPv4 to 224.0.0.251 na UDP 5353, a ruch jest ograniczony do jednej fizycznej lub logicznej sieci LAN. W systemie Windows profil sieci publicznej może blokować odpowiedzi mDNS wymagane przez NDI; w zarządzanych sieciach domenowych administrator musi zezwolić na ruch wykrywania. Zobacz oficjalną dokumentację NDI mDNS.
W środowisku izolowanym, routowanym lub chmurowym wybierz udokumentowany projekt wykrywania, zamiast zakładać, że multicast je przekroczy. Ręczny wpis hosta może odpytać zdalną maszynę przez TCP 5960, ale pomaga odbiornikowi tylko znaleźć źródła na tej maszynie. Nie ustanawia łączności mediów ani nie tworzy przepustowości sieciowej.
Skonfiguruj Discovery Server na nadajniku i odbiorniku
NDI Discovery Server to scentralizowany rejestr dla instalacji, w których mDNS jest niepożądany lub niedostępny. Domyślny nasłuch odbywa się na TCP 5959; usługę można powiązać z wybranym adresem albo skonfigurować dla innego portu. Klienci muszą używać tego samego adresu i portu serwera, które przewiduje wdrożenie.
Istotny szczegół zależy od roli. Nadajnik skonfigurowany z Discovery Server nie ogłasza się przez mDNS; jest widoczny dla wyszukiwarek i odbiorników skonfigurowanych dla tego serwera. Wyszukiwarki i odbiorniki mogą również używać mDNS dla lokalnych maszyn, które nie są skonfigurowane z Discovery Server. Traktuj to jako wybór projektowy, a nie przełącznik ustawiany na jednym hoście i pomijany później.
NDI 5 dokumentuje rozdzielane przecinkami adresy Discovery Server dla obsługiwanych klientów. Przetestuj dokładny nadajnik, odbiornik i wersję NDI podczas awarii serwera: nowsze implementacje nasłuchujące odbiornika mogą wymagać logiki klienta wykrywającej awarię serwera i ponawiającej połączenie. Omówienie Discovery Server oraz jego dokumentacja konfiguracji są źródłem prawdy dla zainstalowanej wersji.
Użyj reguły portu pasującej do trybu NDI
Poniższa tabela ma charakter funkcjonalny; nie jest zgodą na dopuszczenie nieograniczonego zakresu między każdym hostem. Zastosuj regułę w kierunku, strefie i dla liczby połączeń używanych przez wdrożony nadajnik oraz odbiornik. Przed utworzeniem reguły minimalnych uprawnień potwierdź zainstalowaną wersję NDI i wybrany tryb odbioru.
| Funkcja | Oficjalna reguła portu | Co dowodzi wynik |
|---|---|---|
| Wykrywanie mDNS | UDP 5353; multicast IPv4 224.0.0.251 | Ruch wykrywania jest obecny w tej sieci LAN, nie że media są użyteczne. |
| Discovery Server | Domyślnie TCP 5959; konfigurowalny | Klient może dotrzeć do punktu rejestru, nie że ma strumień. |
| Ręczne zapytanie hosta | TCP 5960 | Zdalny host można odpytać o źródła. |
| Podstawowe media TCP | TCP 5961 i wyżej; co najmniej jeden port na połączenie | Użyj, gdy wybrany tryb połączenia korzysta z podstawowego TCP. |
| NDI 5+ Reliable UDP | UDP 5960 i wyżej; współdzielony z TCP, jeden port na proces NDI | Współdzielenie połączeń zmienia założenie dotyczące liczby. |
| Odbiór Multi-TCP lub UDP | TCP/UDP 6960 i wyżej; co najmniej jeden port na połączenie | Reguła mediów po stronie odbiornika dla tego trybu. |
| Wysyłanie Multi-TCP, unicast UDP lub multicast UDP | TCP/UDP 7960 i wyżej; co najmniej jeden port na połączenie | Reguła mediów po stronie nadajnika dla tego trybu. |
Aktualna dokumentacja NDI podaje, że wersje 4.6 i nowsze nie używają już portów efemerycznych. Pełna dokumentacja portów NDI powinna towarzyszyć każdej zmianie firewalla.
Sprawdź podsieci i interfejsy sieciowe
mDNS ma granicę LAN; routing, przekaźniki multicast i działanie VPN nie zmieniają go w ogólną usługę wykrywania przez sieci routowane. Gdy źródło i odbiornik znajdują się w odrębnych kontrolowanych sieciach, użyj Discovery Server lub udokumentowanej metody ręcznego adresowania danego produktu.
Na hoście z wieloma interfejsami zapisz, który interfejs obsługuje wykrywanie, a który przesyła media. Adapter zarządzania, połączenie Wi-Fi lub VPN może sprawić, że źródło pojawi się z niewłaściwej sieci albo odpowiedzi wyjdą trasą, której odbiornik nie może użyć. Nadaj interfejsowi mediów stałe adresowanie, unikaj zduplikowanych nazw maszyn i ustaw deterministyczny priorytet interfejsów przed wydarzeniem.
Źródło jest na liście, ale nie ma obrazu ani dźwięku
Źródło na liście oznacza, że odbiornik uzyskał ogłoszenie źródła lub wpis rejestru. Nie dowodzi, że wybrany transport może się otworzyć, że ścieżka zwrotna jest dozwolona ani że odbiornik może zdekodować wideo. Sprawdź aktywny URL i port źródła, stan połączenia, tryb odbioru, obecność wideo, obecność audio oraz wyrenderowane wyjście.
Aktualne narzędzie NDI Discovery może wyświetlać zarejestrowane nadajniki, adres/port źródła oraz dane monitorowania odbiornika, w tym stan połączenia, tryb odbioru i obecność wideo lub audio. Użyj tych danych, aby wybrać następny krok. Sonda TCP na porcie 5959 dowodzi jedynie osiągalności Discovery Server, a nie sesji mediów NDI.
Sprawdź, czy mDNS dociera do tego interfejsu Linux
sudo tcpdump -ni <media-interface> udp port 5353Oczekiwany wynik: pakiety mDNS pojawiają się, gdy wykrywanie jest aktywne na tym interfejsie. Pakiety te potwierdzają ruch wykrywania na tym interfejsie, a nie dostęp do wybranych portów mediów. Przechwytywanie pakietów i diagnostykę firewalla wykonuj wyłącznie z upoważnieniem wymaganym dla tej sieci produkcyjnej.
Sprawdź osiągalność Discovery Server z systemu Windows
Test-NetConnection <discovery-server> -Port 5959Oczekiwany wynik: udane połączenie TCP ze skonfigurowanym adresem i portem serwera. Potwierdza to osiągalny nasłuch TCP. Sprawdź rejestrację, członkostwo w grupie i dostarczanie mediów w aplikacji NDI.
Sprawdź wykryte źródła w Callaba
Callaba Cloud NDI daje operatorowi miejsce do konfigurowania wykrywania, interfejsów i adapterów, a przepływ pracy wykrytych urządzeń może pokazać bieżący inwentarz. Pomaga to odróżnić zapisany wpis urządzenia od źródła aktualnie wykrytego przez wybraną instancję. Sprawdź wybrane źródło zarówno na końcowym odbiorniku, jak i w inwentarzu.
Gdy źródło jest aktualne, a ścieżka mediów została zweryfikowana, skonfiguruj adapter NDI lub zadanie podrzędne rzeczywiście potrzebne w produkcji. Sprawdź jego wyjście osobno w odbiorniku docelowym; wynik wykrywania jest informacją do tej decyzji, a nie testem akceptacyjnym.
Zapisz działającą konfigurację
- Brak źródła: potwierdź wyjście nadajnika, grupę, wybraną kartę NIC oraz konfigurację mDNS lub Discovery Server.
- Źródło na liście, brak sesji: zapisz adres źródła, tryb transportu i aktywną regułę mediów; sprawdź firewall punktu końcowego i routing w obu kierunkach.
- Sesja, brak użytecznych klatek: sprawdź tryb odbioru, bitrate, obecność wideo/audio, zgodność dekodowania i faktycznie wyrenderowane wyjście.
- Przed akceptacją: powtórz udaną ścieżkę na interfejsach produkcyjnych i zapisz konfigurację, nazwę źródła oraz dowody do runbooka.
Następne kroki
Użyj Cloud NDI, aby skonfigurować zamierzoną ścieżkę wykrywania i interfejsu, a następnie przeczytaj dokumentację wykrytych urządzeń, gdy przepływ pracy wymaga kontroli inwentarza. Test akceptacyjny produkcji zachowaj na końcowym odbiorniku: płynnie zmieniający się obraz, oczekiwany dźwięk i wybrana ścieżka wyjścia.
