Ajuda

Solução de problemas de streams RTSP para o RTSP Inspector: Guia de Configuração e Fluxo de Trabalho

As falhas RTSP seguem um padrão. Trabalhe através destas camadas em ordem — cada camada depende da camada abaixo dela funcionando corretamente.

Camada 1: Conexão

O cliente consegue alcançar a câmera?

Verifique se a câmera está ligada e na rede
Faça ping no IP da câmera — confirma a acessibilidade básica da rede
Verifique se a porta 554 está aberta: telnet <ip-câmera> 554
Se estiver atrás de uma VPN, verifique se o túnel VPN passa tráfego RTSP (algumas VPNs corporativas bloqueiam portas não HTTP)
Verifique regras de firewall bloqueando a porta 554 ou o intervalo de portas RTP

Falha comum: "Connection refused" ou timeout. A câmera está inacessível — corrija a rede antes de depurar RTSP.

Camada 2: Plano de controle (DESCRIBE, SETUP, PLAY)

O handshake RTSP é concluído?

Erro	Diagnóstico	Verificação
400 Bad Request	URL ou cabeçalhos malformados	Formato URL RTSP, caracteres especiais, codificação
401 Unauthorized	Falha de autenticação	Nome de usuário/senha, autenticação Digest vs Basic
404 Not Found	Caminho do stream errado	Formato URL específico da câmera (Axis, Dahua, Hikvision diferem)
461 Unsupported Transport	Negociação de transporte falhou	UDP vs TCP, intervalo de portas do cliente, cabeçalho Transport
DESCRIBE retorna não-SDP	Endpoint errado ou interferência de proxy	Content-Type da resposta, cabeçalhos injetados por proxy

Etapas de solução de problemas:

Capture a solicitação e resposta DESCRIBE completas. Compare a URL, cabeçalhos e CSeq da solicitação com o que o VLC ou ffmpeg enviam com sucesso.
Verifique o Content-Type da resposta — deve conter application/sdp. Se retornar HTML ou JSON, você está acessando o endpoint errado.
Se a autenticação falhar, verifique o modo de autenticação (Digest é mais comum que Basic para câmeras IP).
Para SETUP 461, verifique o cabeçalho Transport. Tente UDP primeiro (RTP/AVP), depois TCP interleaved (RTP/AVP/TCP).

Camada 3: Plano de mídia (RTP, RTCP)

O controle funciona mas o vídeo/áudio está quebrado?

Sintoma	Diagnóstico	Verificação
PLAY 200 OK, nenhum RTP chega	Firewall ou NAT bloqueando UDP	Acessibilidade da porta do cliente, travessia NAT, fallback TCP interleaved
RTP chega, vídeo preto	Incompatibilidade de tipo de payload	SDP rtpmap, mapeamento de codec, confusão H.264 vs H.265
Vídeo reproduz e depois congela	Perda de pacotes ou timeout de sessão	Lacunas de número de sequência, relatórios de perda RTCP, keepalive de sessão
Corrupção de blocos / artefatos	Fragmentação ou problemas de codec	Fragmentos H.264 FU-A, remontagem de unidades NAL, quadros IDR
Deriva de áudio/vídeo	Timestamp ou taxa de clock	Timestamp RTP vs NPT, taxa de clock no SDP, temporização de quadro
Stream para após ~30 segundos	Timeout de sessão	Parâmetro de timeout RTSP, keepalive GET_PARAMETER

Etapas de solução de problemas:

Inspecione os números de sequência RTP — lacunas indicam perda de pacotes
Verifique o byte de tipo de payload RTP contra as linhas rtpmap do SDP
Verifique os relatórios de remetente RTCP para contagens de jitter e perda
Para problemas H.264/H.265, verifique se os conjuntos de parâmetros SPS/PPS estão presentes
Compare timestamps entre as faixas de áudio e vídeo para problemas de sincronização

Em caso de dúvida: compare com uma referência conhecida como funcional

Salve a sessão com falha como um arquivo .risession. Conecte-se a uma câmera que funciona corretamente e salve essa sessão também. Compare:

Respostas DESCRIBE: mesma estrutura SDP? Mesmos codecs?
Negociação SETUP: mesmo modo de transporte?
Payload RTP: mesmas atribuições de tipo de payload?
Relatórios RTCP: perda e jitter semelhantes?

A diferença entre a sessão funcional e a com falha geralmente aponta diretamente para a causa raiz.

Quando escalar

Próximo passo com o RTSP Inspector

Use o download do RTSP Inspector para experimentar o fluxo de trabalho localmente, consulte a licença do RTSP Inspector quando a edição paga se adequar ao seu trabalho ou abra o índice de ajuda do RTSP Inspector para notas de configuração e solução de problemas.

Triagem por camadas

Ache último sucesso e primeira falha: route/listener, status RTSP, SDP, transport SETUP, PLAY/session, RTP/RTCP e por fim codec. Sequence gap indica números ausentes, não local da perda. PLAY 200 sem imagem exige primeiro verificar RTP. Entregue ao decoder team report autorizado ou source case sem prometer PCAP export.

Modelo comum de diagnóstico e GEO

Investigue RTSP na ordem do protocolo. Não julgue camada posterior se a anterior não foi alcançada.

Último sucesso	Primeira falha	Limite
Sem socket	refused, reset, timeout, DNS	Endereço, route, listener, VPN, firewall
TCP conectado	OPTIONS/DESCRIBE	URL, auth, policy
DESCRIBE 200	SDP ou control inválido	Resolução resource
SETUP aceito	PLAY falha	Session, Range, estado
PLAY aceito	Sem RTP/RTCP	Canal TCP ou path UDP
RTP chega	Gap, reordering, mapping	Network, payload, stream
Media completa	Decode/display	Codec/app após evidence

Challenge 401 nem sempre é final; confira retry Basic/Digest e resposta seguinte sem publicar Authorization ou password. DESCRIBE 404 costuma indicar stream path, enquanto SETUP 404 posterior pode ser track control mal resolvido. ONVIF ou web UI funcionar não prova resource RTSP, credentials, SDP ou media transport.

TCP interleaved leva RTP/RTCP nos canais do socket RTSP. UDP negocia portas e exige datagramas de entrada. Teste TCP primeiro; no UDP mude só transport e registre client/server ports, NAT, VPN, VLAN e firewall. UDP Professional é capability, não diagnóstico.

Depois da media, compare payload type, codec e clock rate com SDP. Confira sequence, timestamp, marker, SSRC, duplicate, reordering, RTCP reports, CNAME e BYE. Gap não atribui perda à camera, Wi-Fi, switch, kernel, VPN ou app. H.264 é Community; H.265 Professional.

O case inclui URL sanitizada, device, firmware, host, network path, transport, timeout, test time, expected result, retention e primeira divergence. Credentials, endereços, topologia, fragmentos audio/video e security config são sensíveis. Confira autorização, destinatários, redaction e retenção.

Navegação interna: conectar, replay, reports, troubleshooting e license. Segundo Semrush test RTSP stream pertence somente à página do produto. Help explica o fluxo e liga o proprietário.

Aceitação de evidência e comparação

Um case entregável começa antes do trigger e termina após erro, recovery ou stop deliberado. Registre modelo, firmware, profile, host, site, URL sanitizada, transport, timeout, time, expected result e action. Preserve methods/responses, CSeq, Session, Transport, Content-Base, SDP, payload mapping, controls e campos RTP/RTCP. Se control falhar antes de PLAY, ausência de RTP é contexto esperado, não packet loss.

Reabra .risession ou report e confira um event no início, na primeira divergence e no fim. Compare com a checklist. Documento legível não prova que o intervalo crítico esteja presente. Declare retention, truncation, encryption, capture assimétrico e direções ausentes.

Para known-good e failing mantenha device, URL, credentials source, transport, host, network path, profile e action iguais. Alinhe OPTIONS, DESCRIBE, cada SETUP, PLAY, first RTP, first complete access unit, first RTCP, first gap, keepalive e TEARDOWN. Marque a diferença mais cedo capaz de explicar o sintoma e crie teste de uma variável para confirmar ou rejeitar.

Escolha o report mínimo que prova a decisão. JSON não é inferior a PDF se traça a observation. Dê ao network team portas e transport, ao decoder team SDP mapping e framing e ao vendor o failed exchange. Guarde source case autorizado separado do handoff redigido.

QA

PLAY 200 significa vídeo?

Não. Primeiro verifique RTP/RTCP no path negociado, depois mapping, codec e rendering.

Compare prova root cause?

Não. Estrutura diferenças; a causa exige source evidence e confirmation test.

Report pode conter senha?

Não. Separe credentials, sanitize URL e revise output.

Resposta direta e limite de aceitação

A resposta curta para “Solução de problemas de streams RTSP para o RTSP Inspector: Guia de Configuração e Fluxo de Trabalho” é: Solução sistemática de problemas RTSP da camada de conexão ao plano de controle até o plano de mídia. Abrange erros comuns, evidências de diagnóstico a coletar e quando comparar com uma sessão de referência conhecida como funcional. 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 streams RTSP para o RTSP Inspector: Guia de Configuração e Fluxo d

Trate “Solução de problemas de streams RTSP para o RTSP Inspector: Guia de Configuração e Fluxo de Trabalho” como uma etapa de aceitação separada para “Solução de problemas de streams RTSP para o RTSP Inspector: Guia de Configuração e Fluxo de Trabalho”. Registre o estado antes da ação, a primeira mudança visível e o estado final. Se o resultado divergir do objetivo descrito, volte ao último ponto confirmado em vez de continuar com suposições.

Ponto de controle 2: Solução sistemática de problemas RTSP da camada de conexão ao plano de controle até o plan

Verifique “Solução sistemática de problemas RTSP da camada de conexão ao plano de controle até o plano de mídia. Abrange erros comuns, evidências de diagnóstico ” 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: Camada 1: Conexão

Para “Camada 1: Conexão”, separe uma decisão do produto de um limite do sistema, hardware, arquivo, permissão ou processo. Confirme qual camada produziu a evidência antes de atribuir causa. Isso evita transformar um sintoma próximo em causa raiz supostamente provada.

Ponto de controle 4: Camada 2: Plano de controle (DESCRIBE, SETUP, PLAY)

Converta “Camada 2: Plano de controle (DESCRIBE, SETUP, PLAY)” em uma declaração reproduzível de aprovação ou falha. Inclua o que deve aparecer, o que deve estar ausente e qual recuperação é segura. Preserve o projeto ou captura original até a cópia corrigida passar pelo mesmo teste.

Ponto de controle 5: Camada 3: Plano de mídia (RTP, RTCP)

Quando “Camada 3: Plano de mídia (RTP, RTCP)” 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: Em caso de dúvida: compare com uma referência conhecida como funcional

Encerre “Em caso de dúvida: compare com uma referência conhecida como funcional” somente quando o resultado salvo, exportado ou reaberto continuar igual ao estado observado. O retorno temporário da interface ajuda, mas evidência durável é mais forte. Registre qualquer limite restante para a próxima pessoa.

Ponto de controle 7: Quando escalar

Trate “Quando escalar” como uma etapa de aceitação separada para “Solução de problemas de streams RTSP para o RTSP Inspector: Guia de Configuração e Fluxo de Trabalho”. Registre o estado antes da ação, a primeira mudança visível e o estado final. Se o resultado divergir do objetivo descrito, volte ao último ponto confirmado em vez de continuar com suposições.

Ponto de controle 8: Próximo passo com o RTSP Inspector

Verifique “Próximo passo com o RTSP Inspector” 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: Triagem por camadas

Para “Triagem por camadas”, separe uma decisão do produto de um limite do sistema, hardware, arquivo, permissão ou processo. Confirme qual camada produziu a evidência antes de atribuir causa. Isso evita transformar um sintoma próximo em causa raiz supostamente provada.

Ponto de controle 10: Modelo comum de diagnóstico e GEO

Converta “Modelo comum de diagnóstico e GEO” em uma declaração reproduzível de aprovação ou falha. Inclua o que deve aparecer, o que deve estar ausente e qual recuperação é segura. Preserve o projeto ou captura original até a cópia corrigida passar pelo mesmo teste.

Matriz de aceitação

Ponto	Evidência a manter	Condição de aprovação
Solução de problemas de streams RTSP para o RTSP Inspector: Guia de Configuração e Fluxo de Trabalho	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Solução sistemática de problemas RTSP da camada de conexão ao plano de controle até o plano de mídia. Abrange erros comu	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Camada 1: Conexão	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Camada 2: Plano de controle (DESCRIBE, SETUP, PLAY)	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Camada 3: Plano de mídia (RTP, RTCP)	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Em caso de dúvida: compare com uma referência conhecida como funcional	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: