RTSP conecta, mas não mostra vídeo: o que inspecionar antes de culpar o player

Um dos tickets de suporte de câmera mais comuns parece simples: "o URL RTSP conecta, a autenticação é bem-sucedida, mas o visualizador não mostra nenhum vídeo. O instinto natural é tentar outro jogador. Isso pode ser útil, mas não responde à questão de engenharia: o fluxo falhou no controle RTSP, na negociação SDP, na entrega RTP ou na prontidão do codec?" Para integradores de CFTV, engenheiros de VMS e fornecedores de câmeras, essa distinção é importante. Um jogador pode ocultar a perda de pacotes, reutilizar o estado antigo do decodificador ou tentar novamente os modos de transporte silenciosamente. Um relatório de diagnóstico deve explicar qual parte do riacho foi comprovadamente saudável e qual parte não foi.

Separe o sucesso do controle do sucesso da mídia

RTSP é um protocolo de controle. Uma sequência DESCRIBE, SETUP e PLAY bem-sucedida prova que a câmera aceitou a sessão. Isso não prova que os pacotes RTP chegaram. Também não prova que a carga útil seja realmente H.264 ou H.265 no formato anunciado pelo SDP.

Registros úteis de primeira passagem:

• os códigos de status RTSP para OPTIONS, DESCRIBE, SETUP e PLAY
• se o corpo do SDP contém uma seção de mídia de vídeo
• o tipo de carga negociado para a trilha de vídeo
• se os pacotes RTP chegam depois de PLAY
• se o carimbo de data/hora RTP e os números de sequência avançam
• se a primeira carga de vídeo contém evidências de parâmetros de codec

Se o controle for bem-sucedido, mas nenhum RTP chegar, o problema geralmente é transporte, firewall, NAT, modo de câmera ou disponibilidade de fluxo no servidor. Se o RTP chegar, mas não houver vídeo pronto para decodificação, o problema mudará para carga útil, empacotamento ou metadados de codec.

Por que o SDP é o primeiro limite de evidência

O SDP informa ao cliente o que a câmera afirma que enviará. Para H.264, os engenheiros procuram valores rtpmap e fmtp, como modo de empacotamento, ID de nível de perfil e sprop-parameter-sets. Para H.265, o SDP pode transportar informações de VPS, SPS e PPS de maneira diferente, e muitos consumidores têm limites de suporte mais rígidos.

Quando o SDP diz H.264, mas os bytes de mídia não contêm a estrutura de unidade NAL esperada, a falha não é um “problema do jogador” genérico. É uma incompatibilidade entre os metadados anunciados e a realidade da carga útil. Quando o SDP omite conjuntos de parâmetros e o fluxo RTP nunca os envia na banda, um decodificador pode esperar para sempre.

É por isso que um fluxo de trabalho de inspeção RTSP deve manter o SDP ao lado das evidências da mídia, e não enterrado no registro do jogador.

A chegada da RTP não é suficiente

Mesmo quando os pacotes RTP chegam, o vídeo ainda pode falhar. Os quadros H.264 e H.265 geralmente dependem de pacotes anteriores. Um pacote perdido pode tornar a próxima fatia indecodificável. A entrega fora de ordem pode parecer corrupção. Uma carga útil que inicia no meio do GOP pode não estar pronta para decodificação até que o próximo quadro-chave e conjunto de parâmetros apareçam.

A evidência mínima a ser coletada é:

• Continuidade da sequência RTP
• progressão do carimbo de data/hora
• comportamento do bit marcador
• consistência do tipo de carga útil
• Categorias de unidades H.264 ou H.265 NAL
• SPS, PPS e para visibilidade H.265 VPS
• preparação do primeiro quadro-chave

Isso explica por que “o VLC reproduz” e “nosso pipeline de análise o rejeita” podem ser ambos verdadeiros. Alguns espectadores se recuperam agressivamente. Os sistemas de engenharia muitas vezes precisam de evidências claras e padronizadas.

TCP versus UDP é uma escolha de diagnóstico

Mudar o transporte RTSP de UDP para TCP é uma etapa comum de solução de problemas, mas não deve ser tratada como uma panaceia. A intercalação TCP pode evitar portas UDP bloqueadas e reduzir a perda de pacotes causada pela política de rede. Ele também pode ocultar se o caminho UDP pretendido da implantação funciona.

Um bom relatório de campo registra ambas as tentativas:

• RTSP sobre TCP intercalado: a mídia chega?
• RTP sobre unicast UDP: os pacotes chegam nas portas negociadas?
• RTCP: o feedback do remetente mostra o tempo e a contagem de pacotes?

Se o TCP funcionar e o UDP falhar, a resposta provavelmente não será o suporte ao codec. Provavelmente é caminho de rede, firewall, NAT ou alocação de porta. Se ambos os transportes entregarem RTP, mas a decodificação ainda falhar, inspecione a estrutura do codec.

Onde o inspetor RTSP se encaixa

O RTSP Inspector foi desenvolvido exatamente para esse limite. Não está tentando se tornar um reprodutor de vídeo ou NVR. Ele captura as evidências em torno da sessão RTSP, SDP, fluxo RTP/RTCP e prontidão H.264/H.265 para que um engenheiro possa explicar por que "conectado" não se tornou "vídeo utilizável".

A saída útil não é uma captura de tela de uma janela preta do player. É uma resposta repetível:

• Controle RTSP bem-sucedido
• SDP anunciou este codec e tipo de carga útil
• A RTP chegou ou não
• a sequência do pacote era contínua ou quebrada
• evidência de parâmetro de codec estava presente ou ausente
• a próxima ação pertence à rede, configuração da câmera, firmware ou consumidor de fluxo

Essa é a diferença entre assistir a um stream e diagnosticá-lo.