Uma fonte NDI pode não aparecer na lista, aparecer mas não conseguir se conectar, ou conectar sem imagem ou som utilizáveis. Comece pelo sintoma observado:
- Fonte ausente: verifique o emissor, a interface e o método de descoberta.
- Fonte listada, sem conexão: verifique o transporte de mídia, as portas e a rota.
- Conectada, mas sem imagem ou áudio: inspecione a mídia recebida e o decodificador.
Use o mesmo emissor e receptor em todas as verificações. Anote os nomes das fontes, as versões do NDI, as interfaces de rede e o horário de cada teste para poder comparar os resultados.
Quando uma fonte NDI está ausente, comprove primeiro a descoberta
Confirme que o aplicativo ou dispositivo emissor está em execução e tem a saída NDI ativada. Em seguida, verifique se o receptor está observando a interface pretendida e se os dois extremos pertencem ao grupo NDI esperado. Uma fonte ausente em um aplicativo mas visível em uma ferramenta de diagnóstico NDI pode indicar problema de aplicativo/runtime ou configuração, não uma falha de descoberta em toda a rede.
Por padrão, o NDI usa mDNS para descoberta sem configuração. Seu endereço multicast IPv4 é 224.0.0.251 em UDP 5353, e ele fica limitado a uma única LAN física ou lógica. No Windows, um perfil de rede Público pode impedir as respostas mDNS de que o NDI precisa; em redes de domínio gerenciadas, o administrador deve permitir o tráfego de descoberta. Consulte a referência oficial de mDNS do NDI.
Em ambiente isolado, roteado ou em nuvem, escolha um projeto de descoberta documentado em vez de supor que o multicast o atravessará. Uma entrada manual de host pode consultar uma máquina remota por TCP 5960, mas só ajuda o receptor a encontrar as fontes nessa máquina. Ela não estabelece conectividade de mídia nem cria capacidade de rede.
Configure o Discovery Server no emissor e no receptor
O NDI Discovery Server é um registro centralizado para instalações onde o mDNS é indesejável ou indisponível. Seu listener padrão é TCP 5959, e o serviço pode ser vinculado a um endereço escolhido ou configurado para outra porta. Os clientes devem usar o mesmo endereço e porta de servidor previstos pela implantação.
O detalhe importante é específico da função. Um emissor configurado com o Discovery Server não anuncia por mDNS; esse emissor fica visível para finders e receptores configurados para esse servidor. Finders e receptores também podem usar mDNS para máquinas locais que não estão configuradas para o Discovery Server. Trate isso como uma escolha de projeto, não como um botão a aplicar em um host e esquecer.
O NDI 5 documenta endereços do Discovery Server separados por vírgula para clientes compatíveis. Teste o emissor, o receptor e a versão do NDI exatos diante de uma perda de servidor: implementações mais novas de receiver-listener podem exigir lógica de cliente para detectar o servidor com falha e reconectar. A visão geral do Discovery Server e sua referência de configuração são a fonte de verdade para a versão instalada.
Use a regra de portas correspondente ao modo NDI
Não libere faixa irrestrita entre hosts: aplique a regra na direção, zona e quantidade de conexões do emissor e receptor implantados, após confirmar versão NDI e modo de recepção para uma regra de mínimo privilégio.
| Função | Regra oficial | O que prova |
|---|---|---|
| Descoberta mDNS | UDP 5353; multicast IPv4 224.0.0.251 | Há descoberta na LAN, não mídia utilizável. |
| Discovery Server | TCP 5959 padrão; configurável | O cliente alcança o registro, não um stream. |
| Consulta manual | TCP 5960 | Consulta fontes de host remoto. |
| Mídia TCP base | TCP 5961 e acima; uma porta por conexão | Para modo TCP base. |
| UDP confiável NDI 5+ | UDP 5960 e acima; compartilhado com TCP, uma porta por processo NDI | Compartilhamento altera a contagem. |
| Recepção Multi-TCP ou UDP | TCP/UDP 6960 e acima; uma porta por conexão | Regra de mídia do receptor. |
| Envio Multi-TCP, UDP unicast ou multicast | TCP/UDP 7960 e acima; uma porta por conexão | Regra de mídia do emissor. |
NDI informa que 4.6+ não usa portas efêmeras; consulte a referência de portas NDI em toda mudança de firewall.
Verifique sub-redes e interfaces de rede
O mDNS tem um limite de LAN; roteamento, relés multicast e comportamento de VPN não o transformam em um serviço geral de descoberta roteada. Use o Discovery Server ou o método documentado de endereçamento manual do produto participante quando a fonte e o receptor estiverem em redes controladas separadas.
Em um host com várias interfaces, registre qual interface é responsável pela descoberta e qual transporta a mídia. Um adaptador de gerenciamento, conexão Wi-Fi ou VPN pode fazer uma fonte aparecer na rede errada ou fazer respostas saírem por uma rota que o receptor não consegue usar. Dê endereçamento estável à interface de mídia, evite nomes de máquina duplicados e torne a preferência de interface determinística antes do evento.
Fonte listada, mas sem imagem ou som
Uma fonte listada significa que o receptor obteve um anúncio de fonte ou uma entrada de registro. Isso não prova que o transporte selecionado consegue abrir, que o caminho de retorno é permitido ou que o receptor consegue decodificar o vídeo. Inspecione a URL e a porta ativas da fonte, o estado da conexão, o modo de recepção, a presença de vídeo, a presença de áudio e a saída renderizada.
A ferramenta NDI Discovery atual pode exibir emissores registrados, endereço/porta da fonte e dados de monitoramento do receptor, incluindo estado da conexão, modo de recepção e presença de vídeo ou áudio. Use essa evidência para selecionar a próxima verificação. Uma sonda TCP para a porta 5959 comprova somente a acessibilidade ao Discovery Server; não comprova uma sessão de mídia NDI.
Verifique se o mDNS chega a esta interface Linux
sudo tcpdump -ni <media-interface> udp port 5353Resultado esperado: pacotes mDNS aparecem enquanto a descoberta está ativa nessa interface. Esses pacotes confirmam o tráfego de descoberta nessa interface, não o acesso às portas de mídia selecionadas. Execute captura de pacotes e diagnóstico de firewall somente com a autorização exigida para essa rede de produção.
Verifique a acessibilidade do Discovery Server a partir do Windows
Test-NetConnection <discovery-server> -Port 5959Resultado esperado: uma conexão TCP bem-sucedida ao endereço e à porta configurados do servidor. Isso confirma um listener TCP acessível. Verifique registro, participação em grupo e entrega de mídia no aplicativo NDI.
Verifique fontes descobertas no Callaba
Callaba Cloud NDI oferece ao operador um local para configurar descoberta, interfaces e adaptadores, e seu fluxo de dispositivos descobertos pode mostrar o inventário atual. Isso é útil para separar uma entrada de dispositivo salva de uma fonte que está sendo descoberta pela instância selecionada. Verifique a fonte selecionada no receptor final, bem como no inventário.
Quando a fonte estiver atual e o caminho de mídia tiver sido verificado, configure o adaptador NDI ou o trabalho downstream de que a produção realmente precisa. Verifique sua saída separadamente no receptor de destino; um resultado de descoberta é uma entrada para essa decisão, não o teste de aceitação.
Registre a configuração funcional
- Fonte ausente: prove saída, grupo, NIC, mDNS ou Discovery Server.
- Listada, sem sessão: registre endereço, modo e regra; inspecione firewall e rota nos dois sentidos.
- Sessão sem quadros: verifique modo, bitrate, vídeo/áudio, decodificação e saída.
- Antes da aceitação: repita nas interfaces de produção e registre configuração, nome e evidência no runbook.
Próximos passos
Use Cloud NDI para configurar descoberta e interface, depois leia a referência de dispositivos descobertos para inventário. A aceitação permanece no receptor final: imagem avançando, áudio esperado e caminho de saída selecionado.
