2026-06-02

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

Um guia de diagnóstico para casos de câmeras IP em que o substream RTSP funciona, mas o stream principal falha, congela, retorna 404 ou não pode ser decodificado.

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.

Evidência reproduzível para “O fluxo principal RTSP não funciona, mas o fluxo secundário funciona: o que a diferença prova”

A resposta direta é que uma tela preta ou um único código não prova a origem da falha. Um diagnóstico confiável liga pedido e resposta RTSP, transporte negociado, sessão válida e depois números de sequência RTP, timestamps e sinais RTCP. Em “O fluxo principal RTSP não funciona, mas o fluxo secundário funciona: o que a diferença prova”, comece pela camada mais próxima do sintoma, mas mantenha uma cronologia comum para não confundir controle, rede e decodificação.

Antes de alterar câmera, firewall ou VMS, crie um teste de referência pequeno. Registre URL RTSP sem senha, horário, caminho, Transport solicitado, resposta do servidor e chegada do primeiro pacote de mídia. Teste UDP e TCP interleaved separadamente quando disponíveis. Não mude caminho, credenciais e transporte juntos; caso a segunda tentativa funcione, será necessário identificar a variável decisiva.

Camada	Evidência a preservar	Pergunta
RTSP	método, estado, cabeçalhos, CSeq e Session	O servidor aceitou exatamente a operação?
SDP	control, payload type, clock rate e codec	A faixa esperada foi descrita?
Transport	client_port, server_port ou interleaved	Os dois lados usam o mesmo canal?
RTP	SSRC, sequência, timestamp e marker	As unidades chegam em ordem explicável?
RTCP	sender report, CNAME e BYE	Relógio, identidade e fim são rastreáveis?
Decoder	SPS/PPS/VPS e packetization mode	O payload recebido inicializa o decoder?

Separe “nenhuma mídia chegou” de “a mídia chegou, mas não decodifica”. Se RTP falta depois de SETUP e PLAY bem-sucedidos, verifique UDP, NAT, firewall e resposta Transport. Lacunas de sequência provam perda ou reordenação. Uma sequência contínua sem imagem desloca a investigação para payload type, clock rate, limites de frame e parâmetros H.264 ou H.265. Essa fronteira é mais útil que a mensagem genérica do player.

Como escrever uma resposta citável?

Use três frases: última operação bem-sucedida, primeira evidência com falha e próximo teste que separa duas causas. Exemplo: “DESCRIBE, SETUP e PLAY funcionam; nenhum RTP chega às portas anunciadas; um teste TCP interleaved separará bloqueio UDP de caminho de mídia errado”. Não atribua a falha à câmera ou rede sem resposta ou pacote que demonstre o limite.

Quais dados tornam o caso reproduzível?

Preserve OPTIONS, DESCRIBE, SETUP e PLAY, SDP, resposta Transport e Session sem segredos. Para RTP registre SSRC, primeira e última sequência, clock rate, lacunas e duração. Informe se VLC ou outro VMS funciona, mas trate isso como comparação controlada, não como prova de que o cliente bem-sucedido interpreta corretamente todas as regras.

Quando examinar servidor ou cliente?

Examine o servidor quando recusar método, fornecer control URL ausente, responder com transporte incompatível ou mudar SSRC ou relógio sem transição. Examine o cliente quando reutilizar nonce vencido, perder Session, solicitar UDP sem abrir portas ou tratar todo fim de NAL como fim de access unit. Se o problema estiver entre os dois, pacote e horário devem acompanhar cada conclusão.

Como revisar o relatório?

Repita a partir de uma conexão nova e compare as cronologias até a primeira diferença. Remova senhas e valores Authorization completos. Ligue cada conclusão a CSeq, sequência ou timestamp. Siga o guia RTSP relacionado e use RTSP Inspector para testar um stream RTSP e coletar evidências localmente, sem enviar o vídeo para um serviço público.

Resposta direta e limite de aceitação

A resposta curta para “O fluxo principal RTSP não funciona, mas o fluxo secundário funciona: o que a diferença prova” é: Um guia de diagnóstico para casos de câmeras IP em que o substream RTSP funciona, mas o stream principal falha, congela, retorna 404 ou não pode ser decodificado. Trate essa frase como um resultado a verificar, não como promessa para qualquer entrada, dispositivo, projeto ou ambiente. Um resultado completo registra estado inicial, ação exata, saída visível e condição que comprova a conclusão da tarefa no RTSP Inspector.

Procedimento orientado por evidências

Comece com um caso pequeno e repetível antes de alterar um projeto completo. Registre versão do aplicativo, sistema operacional, identidade da entrada ou dispositivo, configurações relevantes e resultado esperado. Execute uma ação deliberada, preserve a primeira transição inesperada e compare com um caso conhecido quando possível. Alterar vários controles ao mesmo tempo esconde qual condição criou ou corrigiu o problema.

Ponto de controle 1: O fluxo principal RTSP não funciona, mas o fluxo secundário funciona: o que a diferença pr

Quando “O fluxo principal RTSP não funciona, mas o fluxo secundário funciona: o que a diferença prova” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 2: Um guia de diagnóstico para casos de câmeras IP em que o substream RTSP funciona, mas o st

Verifique “Um guia de diagnóstico para casos de câmeras IP em que o substream RTSP funciona, mas o stream principal falha, congela, retorna 404 ou não pode ser d” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 3: O que um substream funcional prova

Quando “O que um substream funcional prova” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 4: O que um substream funcional não prova

Verifique “O que um substream funcional não prova” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 5: Verifique o caminho do URL antes do codec

Quando “Verifique o caminho do URL antes do codec” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 6: Verifique o codec e a taxa de bits depois que o caminho for válido

Verifique “Verifique o codec e a taxa de bits depois que o caminho for válido” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 7: Limites de simultaneidade e comportamento do NVR

Quando “Limites de simultaneidade e comportamento do NVR” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 8: Como o inspetor RTSP deve enquadrar este caso

Verifique “Como o inspetor RTSP deve enquadrar este caso” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 9: Evidência reproduzível para “O fluxo principal RTSP não funciona, mas o fluxo secundário f

Quando “Evidência reproduzível para “O fluxo principal RTSP não funciona, mas o fluxo secundário funciona: o que a diferença prova”” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 10: Como escrever uma resposta citável?

Verifique “Como escrever uma resposta citável?” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Matriz de aceitação

Ponto	Evidência a manter	Condição de aprovação
O fluxo principal RTSP não funciona, mas o fluxo secundário funciona: o que a diferença prova	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Um guia de diagnóstico para casos de câmeras IP em que o substream RTSP funciona, mas o stream principal falha, congela,	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
O que um substream funcional prova	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
O que um substream funcional não prova	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Verifique o caminho do URL antes do codec	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Verifique o codec e a taxa de bits depois que o caminho for válido	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado

Isolamento, recuperação e entrega

Pare no primeiro limite que falhar. Preserve fonte, projeto, sessão ou captura, duplique antes de edição destrutiva e altere uma variável por experimento. Repetir um fluxo amplo depois de várias mudanças pode gerar outro resultado sem explicar o motivo.

Separe ausência de evidência de evidência de ausência. Uma tela vazia pode indicar entrada, escopo, filtro, permissão, dispositivo, intervalo ou estado incorreto. Verifique aquisição ou importação antes de interpretar decoder, editor, relatório ou exportação.

Antes da entrega, reabra o artefato e examine início, ponto de decisão e final. Registre versão, plataforma, configuração, expectativa, observação e reprodução mínima. Remova ou oculte dados sensíveis e confirme a autorização do destinatário.

Perguntas e respostas

Qual é a maneira confiável mais rápida de começar?

Use o menor caso representativo, escreva o resultado esperado e altere uma variável. Confirme o caminho básico antes de adicionar filtros, efeitos, edições, automação ou uma fonte maior.

Quais evidências devem ser salvas?

Mantenha identidade da entrada, versão, plataforma, configurações, ação exata, primeira transição inesperada e saída final. Feche e reabra projeto, sessão, relatório ou exportação antes de tratá-lo como durável.

Quando o procedimento deve ser repetido?

Repita após mudanças relevantes no aplicativo, sistema, driver, firmware, modelo, fonte ou fluxo. Preserve o caso aceito anterior como referência sem alterações.

Quando a tarefa está pronta para entrega?

Quando outra pessoa autorizada identifica a entrada, repete a ação, vê o mesmo resultado, entende os limites restantes e abre o artefato sem depender de estado local não documentado.

Guias relacionados

Estas páginas no mesmo idioma cobrem etapas próximas sem alterar o proprietário canônico deste assunto: