2026-06-18

Solução de problemas de fluxo RTSP: o guia completo de diagnóstico para fluxos de câmera

Fluxo de trabalho completo de diagnóstico RTSP: camada de conexão, erros de plano de controle (400/401/404/454/461/500/503), falhas de plano de mídia (H.264/H.265/RTP/RTCP), gerenciamento de sessão e comparação com Wireshark/VLC. Cada problema RTSP mapeado para uma página de diagnóstico.

Esta é a página central para diagnósticos de fluxo de câmera RTSP. Todo problema RTSP segue um padrão – ele falha na camada de conexão, no plano de controle ou no plano de mídia. Este guia mapeia cada falha comum para uma página de diagnóstico específica e informa quais evidências coletar.

Triagem rápida: onde está a falha?

Antes de ler qualquer página específica, determine qual camada está falhando:

O cliente consegue alcançar a câmera? → Problemas na camada de conexão
DESCRIBE retorna SDP válido? → Problemas no plano de controle
Os pacotes RTP chegam e são decodificados corretamente? → Problemas no plano de mídia

Se você não sabe qual camada está falhando, comece com o fluxo de trabalho de diagnóstico sistemático.

Connection layer: reaching the camera

These problems happen before any RTSP command is sent. TCP handshake fails, TLS negotiation fails, or the network path is blocked.

RTSP connects but no video — The most common symptom. Camera appears online but no media stream.
RTSP over TLS (RTSPS) debugging — TLS certificate errors, handshake failures, cipher suite negotiation.

Plano de controle: erros de comando RTSP

Estes são erros de nível de protocolo retornados pela câmera em resposta a DESCRIBE, SETUP ou PLAY. O código de erro informa exatamente o que deu errado.

400 Solicitação incorreta

RTSP 400 Bad Request: DESCRIBE failed — URL malformado, cabeçalhos não suportados, interferência de proxy. Abrange os formatos de URL Axis, Dahua e Hikvision.

401 Não autorizado

Loop de autenticação RTSP 401 — Digest vs autenticação básica, parâmetros nonce/realm, por que a autenticação é bem-sucedida no VLC, mas falha no seu aplicativo.
aprofundamento da autenticação de resumo RTSP — Expiração de nonce, correspondência de domínio, tratamento obsoleto=true.
Diagnóstico de URL da câmera 401/404 — Quando o URL funciona em um cliente, mas não em outro.

404 não encontrado

Diagnóstico de URL da câmera 401/404 — Caminho de transmissão incorreto, formatos de URL específicos da câmera.
URL de controle agregado e configuração de SDP 404 — Quando o URL de controle no SDP não corresponde ao URL DESCRIBE.

454 Sessão não encontrada

Sessão RTSP 454 não encontrada — Incompatibilidade de ID de sessão, sessões expiradas, PLAY antes de SETUP.

461 Transporte Não Suportado

RTSP 461 Transporte não suportado: SETUP falhou — Negociação de transporte UDP vs TCP, ffmpeg "método SETUP falhou: 461", erros de integração Fragate/Scrypted/NVR.

Erros de servidor 500/503

Erro interno do servidor RTSP 500 — Falha no lado da câmera. Quando concluir que o firmware da câmera está com defeito.
Serviço RTSP 503 indisponível — Esgotamento dos recursos da câmera, muitos fluxos simultâneos, limites de largura de banda.

Transporte e redes

UDP RTP bloqueado por firewall/NAT — O controle RTSP funciona, mas a mídia UDP RTP está bloqueada. Regras de firewall, passagem NAT, configuração de porta do protocolo RTSP, fallback intercalado TCP.
Incompatibilidade de canal intercalado TCP — Quando canais RTP/RTCP intercalados não correspondem entre cliente e servidor.
Resposta do servidor de transporte não correspondente — O servidor responde com parâmetros de transporte diferentes dos solicitados.
Depuração UDP multicast — Configuração multicast RTSP/RTP, IGMP, TTL e infraestrutura de rede.
Tempo limite de RTSP: UDP vs TCP intercalado — Por que o tempo limite dos streams é diferente em UDP vs TCP.

Media plane: RTP, codec, and payload problems

Control plane works perfectly — DESCRIBE returns SDP, SETUP succeeds, PLAY returns 200 OK — but video is broken. These are media plane problems.

RTP packet analysis

RTP dynamic payload type mismatch — "Unknown write" RTP/NDPI errors. How to map dynamic payload IDs to SDP rtpmap lines.
RTP packet loss diagnosis — RTP error in primary stream. Freezes, macroblocks, decoder errors. Read sequence numbers and RTCP reports to find the loss.
RTP timestamp drift — Audio/video sync loss, frame timing errors, clock rate mismatch.
RTP marker bit and frame boundaries — How the RTP marker bit signals H.264 access unit boundaries.
RTP sequence number wraparound — 16-bit sequence number rollover and how to detect actual loss vs wraparound.
RTP SSRC change mid-stream — When the camera changes SSRC mid-stream and the client loses sync.

H.264 and H.265 codec issues

H.264 FU-A fragmentation and reassembly — Missing fragments, start/end bit bugs, NAL unit reassembly failures, "invalid NAL unit" errors.
H.264 packetization mode 0 vs 1 — Single NAL vs non-interleaved mode. SDP parameter configuration.
H.264 SPS/PPS missing — Decoder errors when parameter sets are missing from SDP or RTP stream.
H.265 stream not working — H.265/HEVC failures and H.264 fallback behavior.
SDP H.264/H.265 diagnostics — Reading SDP for H.264/H.265: profile-level-id, sprop-parameter-sets, packetization-mode.

Audio and metadata tracks

Audio track AAC unknown track SDP — AAC audio tracks appearing as "unknown" in clients.

ONVIF and camera-specific

ONVIF works but RTSP URL fails — ONVIF discovery succeeds but direct RTSP connection fails.
Main stream vs sub stream — When the main stream works but the sub stream doesn't, or vice versa.

RTCP e gerenciamento de sessão

Relatórios do remetente RTCP: jitter e perda — Leitura de pacotes RTCP SR para entender a qualidade da rede da perspectiva da câmera.
RTCP BYE: stream termina inesperadamente — Quando a câmera envia RTCP BYE e encerra o stream.
RTCP CNAME e sincronização de áudio/vídeo — Usando RTCP CNAME para sincronizar trilhas de áudio e vídeo.
RTSP TEARDOWN e limpeza de sessão — Vazamentos de recursos da câmera, falhas de reconexão, estado de fluxo ocupado.
Tempo limite da sessão RTSP e keepalive — Por que os streams param após aproximadamente 30 segundos e como mantê-los ativos.
RTSP Range header e NPT — Controlando a posição de reprodução com parâmetros Range e NPT.
Cabeçalho de escala RTSP e reprodução de truque — Avanço rápido, retrocesso e controle de velocidade por meio do cabeçalho de escala.

Comparison and alternatives

RTSP Inspector vs Wireshark/VLC/ONVIF Device Manager — When to use a dedicated RTSP diagnostic tool vs a general network analyzer.
Wireshark RTSP alternative — Why RTSP diagnostics need more than packet capture.

Começando

Novo no diagnóstico RTSP? Comece aqui:

Fluxo de trabalho de diagnóstico sistemático — O modelo de três camadas e coleta de evidências.
Conectar a um stream — Configurando sua primeira conexão RTSP.
Guia de solução de problemas — Falhas comuns e suas correções.

Evidência reproduzível para “Solução de problemas de fluxo RTSP: o guia completo de diagnóstico para fluxos de câmera”

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 “Solução de problemas de fluxo RTSP: o guia completo de diagnóstico para fluxos de câmera”, 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 “Solução de problemas de fluxo RTSP: o guia completo de diagnóstico para fluxos de câmera” é: Fluxo de trabalho completo de diagnóstico RTSP: camada de conexão, erros de plano de controle (400/401/404/454/461/500/503), falhas de plano de mídia (H.264/H.265/RTP/RTCP), gerenciamento de sessão e comparação com Wireshark/VLC. Cada problema RTSP mapeado para uma página de diagnóstico. 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: Solução de problemas de fluxo RTSP: o guia completo de diagnóstico para fluxos de câmera

Verifique “Solução de problemas de fluxo RTSP: o guia completo de diagnóstico para fluxos de câmera” 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 2: Fluxo de trabalho completo de diagnóstico RTSP: camada de conexão, erros de plano de contr

Quando “Fluxo de trabalho completo de diagnóstico RTSP: camada de conexão, erros de plano de controle (400/401/404/454/461/500/503), falhas de plano de mídia ” 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 3: Triagem rápida: onde está a falha?

Verifique “Triagem rápida: onde está a falha?” 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 4: Connection layer: reaching the camera

Quando “Connection layer: reaching the camera” 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 5: Plano de controle: erros de comando RTSP

Verifique “Plano de controle: erros de comando RTSP” 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 6: 400 Solicitação incorreta

Quando “400 Solicitação incorreta” 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 7: 401 Não autorizado

Verifique “401 Não autorizado” 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 8: 404 não encontrado

Quando “404 não encontrado” 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 9: 454 Sessão não encontrada

Verifique “454 Sessão não encontrada” 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 10: 461 Transporte Não Suportado

Quando “461 Transporte Não Suportado” 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.

Matriz de aceitação

Ponto	Evidência a manter	Condição de aprovação
Solução de problemas de fluxo RTSP: o guia completo de diagnóstico para fluxos de câmera	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Fluxo de trabalho completo de diagnóstico RTSP: camada de conexão, erros de plano de controle (400/401/404/454/461/500/5	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Triagem rápida: onde está a falha?	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Connection layer: reaching the camera	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Plano de controle: erros de comando RTSP	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
400 Solicitação incorreta	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: