2026-06-02

ONVIF funciona, mas o URL RTSP falha: encontrando o caminho real do fluxo da câmera

Por que a descoberta ONVIF pode funcionar enquanto o fluxo RTSP falha e como depurar perfis de câmera, URLs de mídia, autenticação, transporte e evidências SDP.

É comum que uma câmera IP apareça corretamente na descoberta ONVIF enquanto a URL RTSP ainda falha. O dispositivo fica visível na rede, o nome e o modelo da câmera são detectados, talvez até os perfis sejam listados, mas o fluxo de vídeo real não abre. Os usuários pesquisam “ONVIF funciona, mas o RTSP falha”, “câmera descoberta, mas não há vídeo RTSP” ou “como encontrar o URL RTSP do ONVIF” porque o sucesso da descoberta parece garantir o sucesso do streaming.

Isso não acontece.

ONVIF e RTSP estão relacionados em muitos fluxos de trabalho de câmeras, mas não são o mesmo protocolo e não provam a mesma coisa. O ONVIF pode informar que existe uma câmera e pode fornecer um perfil de mídia. O RTSP ainda deve autenticar, descrever o fluxo, negociar o transporte, configurar trilhas RTP e entregar pacotes de mídia.

O RTSP Inspector concentra-se na segunda metade: o que realmente acontece quando um URL RTSP específico é usado.

O que o ONVIF prova

A descoberta do ONVIF pode provar que:

A câmera responde ao WS-Discovery.
A câmera expõe um endpoint de serviço ONVIF.
O cliente pode acessar a interface de gerenciamento da câmera.
A câmera pode ter um ou mais perfis de mídia.
O dispositivo pode relatar URIs de fluxo por meio de serviços de mídia ONVIF.

Isso é útil, mas não é o mesmo que provar que o fluxo RTSP funciona. A descoberta ONVIF pode usar uma porta diferente, um comportamento de autenticação diferente e um caminho de serviço diferente do RTSP.

Uma câmera pode passar na descoberta ONVIF e ainda assim falhar no RTSP porque:

O RTSP está desativado nas configurações da câmera.
A conta ONVIF não possui permissão RTSP.
O URI do fluxo retornado está incompleto ou é apenas interno.
A porta RTSP está bloqueada por um firewall.
A câmera requer transporte intercalado TCP, mas o cliente tenta UDP.
O perfil aponta para H.265 mas o cliente espera H.264.
O caminho do canal NVR está errado.
A câmera retorna SDP, mas não envia pacotes RTP.

O URI do fluxo ONVIF pode não ser diretamente utilizável

Algumas câmeras retornam um URI RTSP por meio do ONVIF que parece utilizável, mas ainda precisa de modificação. Por exemplo:

rtsp://192.168.1.50/Streaming/Channels/101

The real usable URL may need:

ONVIF profile does not guarantee codec support

The symptom may be:

RTSP Inspector helps by separating the layers:

RTSP transport can fail after ONVIF succeeds

This is common when:

Authentication can differ between ONVIF and RTSP

You may see:

RTSP/1.0 401 Unauthorized
WWW-Authenticate: Digest realm="IP Camera", nonce="..."

mesmo que a descoberta do ONVIF tenha funcionado. Isso significa que o serviço RTSP está solicitando credenciais. Se o cliente enviar credenciais e a câmera continuar retornando 401, verifique as permissões da conta, autenticação Digest, codificação de URL e direitos do canal.

Os NVRs tornam isso mais confuso porque o dispositivo ONVIF pode ser o NVR, enquanto o caminho do fluxo RTSP faz referência a um canal de câmera atrás do NVR. A conta pode ter permissão para consultar o NVR, mas não transmitir o fluxo principal do canal 1.

Confusão de stream principal e substream

Muitas câmeras expõem vários perfis:

Fluxo principal: alta resolução, alta taxa de bits, geralmente H.265.
Sub-stream: resolução mais baixa, taxa de bits mais baixa, geralmente H.264.
Fluxo móvel: tamanho de quadro pequeno e taxa de quadros mais baixa.

ONVIF pode retornar um desses perfis por padrão. O URL RTSP copiado de um fórum ou PDF de fornecedor pode apontar para outro. Se o fluxo principal for H.265, mas o cliente suportar apenas H.264, o fluxo secundário poderá funcionar enquanto o fluxo principal falhar.

Pesquisas como "O fluxo principal RTSP não funciona, o fluxo secundário funciona" geralmente pertencem a esta categoria. O problema não é a descoberta. É seleção de perfil, seleção de codec, taxa de bits ou comportamento de transporte.

Como depurar ONVIF funciona, mas o RTSP falha

Use uma lista de verificação em camadas:

Confirme se o serviço RTSP da câmera está ativado.
Confirme se a porta RTSP, geralmente 554, pode ser acessada pelo cliente.
Obtenha o perfil de mídia ONVIF e transmita o URI.
Normalize o URL RTSP para o caminho de rede que você está realmente usando.
Adicione credenciais com cuidado e codifique caracteres especiais em URL.
Execute RTSP OPTIONS e DESCRIBE.
Inspecione desafios e respostas de autenticação.
Inspecione o SDP para codec, tipo de carga útil, taxa de clock e URLs de controle de rastreamento.
Compare o transporte intercalado UDP e TCP.
Confirme se os pacotes RTP chegam após PLAY.
Verifique a continuidade da sequência RTP, carimbos de data/hora e tipo de carga útil.
Teste o stream principal e o stream secundário separadamente.

Esta lista de verificação evita um erro comum: tratar o sucesso da descoberta do ONVIF como prova de que o streaming de mídia deve funcionar automaticamente.

O que o rastreamento RTSP deve mostrar

Um fluxo RTSP saudável geralmente se parece com:

OPTIONS rtsp://camera/stream RTSP/1.0
RTSP/1.0 200 OK

DESCRIBE rtsp://camera/stream RTSP/1.0
RTSP/1.0 200 OK
Content-Type: application/sdp

SETUP rtsp://camera/stream/trackID=1 RTSP/1.0
RTSP/1.0 200 OK
Transport: RTP/AVP/TCP;unicast;interleaved=0-1

PLAY rtsp://camera/stream RTSP/1.0
RTSP/1.0 200 OK

Final diagnosis

Evidência reproduzível para “ONVIF funciona, mas o URL RTSP falha: encontrando o caminho real do fluxo da 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 “ONVIF funciona, mas o URL RTSP falha: encontrando o caminho real do fluxo da 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 “ONVIF funciona, mas o URL RTSP falha: encontrando o caminho real do fluxo da câmera” é: Por que a descoberta ONVIF pode funcionar enquanto o fluxo RTSP falha e como depurar perfis de câmera, URLs de mídia, autenticação, transporte e evidências SDP. 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: ONVIF funciona, mas o URL RTSP falha: encontrando o caminho real do fluxo da câmera

Encerre “ONVIF funciona, mas o URL RTSP falha: encontrando o caminho real do fluxo da câmera” 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 2: Por que a descoberta ONVIF pode funcionar enquanto o fluxo RTSP falha e como depurar perfi

Para “Por que a descoberta ONVIF pode funcionar enquanto o fluxo RTSP falha e como depurar perfis de câmera, URLs de mídia, autenticação, transporte e evidê”, 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 3: O que o ONVIF prova

Encerre “O que o ONVIF prova” 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 4: O URI do fluxo ONVIF pode não ser diretamente utilizável

Para “O URI do fluxo ONVIF pode não ser diretamente utilizável”, 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 5: ONVIF profile does not guarantee codec support

Encerre “ONVIF profile does not guarantee codec support” 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 6: RTSP transport can fail after ONVIF succeeds

Para “RTSP transport can fail after ONVIF succeeds”, 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 7: Authentication can differ between ONVIF and RTSP

Encerre “Authentication can differ between ONVIF and RTSP” 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 8: Confusão de stream principal e substream

Para “Confusão de stream principal e substream”, 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 9: Como depurar ONVIF funciona, mas o RTSP falha

Encerre “Como depurar ONVIF funciona, mas o RTSP falha” 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 10: O que o rastreamento RTSP deve mostrar

Para “O que o rastreamento RTSP deve mostrar”, 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.

Matriz de aceitação

Ponto	Evidência a manter	Condição de aprovação
ONVIF funciona, mas o URL RTSP falha: encontrando o caminho real do fluxo da câmera	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Por que a descoberta ONVIF pode funcionar enquanto o fluxo RTSP falha e como depurar perfis de câmera, URLs de mídia, au	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
O que o ONVIF prova	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
O URI do fluxo ONVIF pode não ser diretamente utilizável	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
ONVIF profile does not guarantee codec support	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
RTSP transport can fail after ONVIF succeeds	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: