O fluxo principal RTSP não funciona, mas o fluxo secundário funciona: o que a diferença prova

Uma consulta de pesquisa de câmera IP muito comum é “O fluxo principal RTSP não funciona, mas o fluxo secundário funciona”. O sintoma é específico o suficiente para ser útil. Se o substream funcionar, a câmera está acessível, as credenciais provavelmente estão corretas, o serviço RTSP está ativado e pelo menos um perfil de vídeo está acessível. O problema não é mais “RTSP quebrado”. O problema é a diferença entre os perfis de fluxo.

O stream principal e o substream geralmente diferem em resolução, taxa de bits, codec, intervalo GOP, tamanho da carga útil e, às vezes, até caminho do URL. Um substream pode ser H.264 em baixa resolução, enquanto o stream principal é H.265, 4K, alta taxa de bits ou restrito a menos sessões simultâneas. Um NVR pode expor diferentes caminhos da própria câmera. ONVIF pode retornar um URL ativo de baixa qualidade, enquanto o URL de gravação ou perfil principal requer um caminho separado.

A pergunta diagnóstica útil é: o que o fluxo secundário em funcionamento prova e o que não prova?

O que um substream funcional prova

Se o substream puder ser aberto por RTSP, normalmente você poderá dizer:

• o endereço IP da câmera está acessível
• a porta RTSP está aberta
• a autenticação funciona para pelo menos um fluxo
• o cliente pode analisar respostas RTSP básicas
• DESCRIBE, SETUP e PLAY podem ter sucesso em pelo menos um perfil
• A entrega RTP é possível para pelo menos uma faixa de mídia

Essa é uma evidência valiosa. Isso restringe a pesquisa. Você não deve continuar depurando a acessibilidade básica da rede após esse ponto, a menos que o fluxo principal use um host, porta, modo de transporte ou caminho NVR diferente.

O que um substream funcional não prova

Um substream funcional não prova:

• o caminho do URL do stream principal está correto
• o fluxo principal está ativado
• o codec de fluxo principal é suportado
• a taxa de bits do fluxo principal pode cruzar a rede
• o fluxo principal está disponível para vários clientes
• o fluxo principal envia evidências SPS/PPS ou VPS/SPS/PPS prontas para decodificação
• o NVR expõe o fluxo principal da câmera pelo mesmo caminho

É por isso que "VLC pode abrir o substream" não é suficiente para um VMS, sistema analítico ou pipeline de restreaming que precisa do stream principal.

Verifique o caminho do URL antes do codec

Muitas famílias de câmeras usam padrões de caminho diferentes para fluxos principais e secundários. Alguns usam profile1 e profile2. Alguns usam /Streaming/Channels/101 e /Streaming/Channels/102. Alguns usam main, sub, video1, video2 ou nomes de acesso específicos do fornecedor. Alguns NVRs expõem canais de maneira diferente dos URLs diretos da câmera.

Se o stream principal retornar 404 Not Found, inspecione:

• URI de solicitação exata enviada em DESCRIBE
• se o caminho do URL corresponde ao modelo do fornecedor
• número do canal
• número do fluxo
• token de perfil descoberto pelo ONVIF
• se o stream está ativado na interface da web da câmera
• se o URL é direcionado ao IP da câmera ou ao IP do NVR

Não trate um 404 como perda de pacotes. A RTP ainda não começou.

Verifique o codec e a taxa de bits depois que o caminho for válido

Se o fluxo principal retornar SDP e iniciar RTP, mas ainda não mostrar vídeo, passe para codec e evidência de mídia.

As falhas do fluxo principal geralmente vêm de:

• H.265 selecionado enquanto o consumidor espera H.264
• faltando evidência H.264 SPS/PPS ou H.265 VPS/SPS/PPS
• intervalo de quadro-chave muito longo
• alta perda de taxa de bits por Wi-Fi ou uplink fraco
• fragmentação e perda de pacotes em movimento
• perfil ou nível do decodificador não suportado pelo sistema downstream

Nesta fase, o relatório deve incluir SDP, tipo de carga útil, continuidade da sequência RTP, evidência da unidade NAL do codec e se o primeiro limite de decodificação foi alcançado.

Limites de simultaneidade e comportamento do NVR

Alguns DVRs, NVRs ou versões de firmware de câmera de baixo custo limitam o acesso ao fluxo principal. O fluxo secundário pode permanecer disponível enquanto o fluxo principal já estiver consumido pela exibição local, gravação, aplicativo do fornecedor ou outro cliente. Isso pode parecer um problema de URL mesmo quando o caminho está correto.

Verificações úteis:

• desconectar outros espectadores
• testar IP direto da câmera versus IP NVR
• compare o fluxo principal da interface da web da câmera
• menor taxa de bits ou resolução do fluxo principal
• mudar o codec de fluxo principal de H.265 para H.264
• teste RTSP sobre TCP intercalado e UDP separadamente

Se a redução da taxa de bits resolver o problema, a falha original poderá ser a capacidade de transporte e não a sintaxe do URL.

Como o inspetor RTSP deve enquadrar este caso

O RTSP Inspector é mais forte quando explica o limite:

• o caminho de controle do substream foi bem-sucedido
• o caminho de controle do fluxo principal falha com o código de status
• fluxo principal retorna SDP, mas não RTP
• RTP do fluxo principal chega com perda de pacotes
• os metadados do codec de fluxo principal estão ausentes ou não são suportados
• o fluxo principal é H.265, enquanto o consumidor precisa de H.264

Essa é a diferença entre “fluxo principal quebrado” e um relatório de suporte útil. A próxima ação correta pode ser pesquisa de URL do fornecedor, configuração de perfil de fluxo, alteração de codec, redução de taxa de bits, atualização de firmware ou reparo de caminho de rede.

Se sua pesquisa exata for "O substream RTSP funciona, mas o stream principal não", comece comparando métodos RTSP, SDP, codec, transporte e simultaneidade. O subfluxo de trabalho não é o fim do diagnóstico. É a amostra de controle.