2026-06-02

Cabeçalho de intervalo RTSP e npt = agora: depuração de erros de hora de início de reprodução ao vivo, retomada e busca de câmera

Como solucionar problemas de cabeçalhos de intervalo RTSP, npt=now, reprodução de câmera ao vivo, comportamento de retomada, horário de início incorreto, busca inválida, solicitações PLAY e tempo de resposta do servidor.

RTSP PLAY parece simples até que uma câmera, NVR ou servidor de mídia interprete o horário de início de forma diferente do cliente. Uma transmissão ao vivo pode começar tarde, reiniciar de um ponto inesperado, falhar após pausa/retomada ou retornar um erro quando o cliente envia um cabeçalho Range. Os usuários pesquisam por "Intervalo RTSP npt agora", "Hora de início do RTSP PLAY", "Início errado da transmissão ao vivo RTSP", "Busca RTSP não funciona" e "Câmera retoma fluxo RTSP" quando o fluxo se conecta, mas o tempo de reprodução se comporta incorretamente.

O cabeçalho Range é uma instrução de temporização da camada de controle. Não é o mesmo que carimbo de data/hora RTP, horário do relógio de parede ou carimbo de data/hora do arquivo do gravador. O RTSP Inspector é útil porque esse problema está na sequência do método RTSP e deve ser comparado com o tempo de mídia RTP/RTCP após PLAY.

O que intervalo significa em RTSP

Durante PLAY, um cliente pode enviar:

PLAY rtsp://camera/stream RTSP/1.0
Session: 12345678
Range: npt=now-

For a live stream, npt=now- usually means "start playing from the current live point." Some clients omit the Range header. Some send npt=0.000-. Some NVRs use clock-based ranges for recorded playback.

Different RTSP servers vary in how strictly they interpret these values.

Live stream vs recorded stream

Live streams and recorded streams have different expectations:

Live camera stream: current live media point.
NVR playback: requested recording time range.
Media file: offset into stored content.
Replay server: session-specific timeline.

A Range value that is valid for a file may be invalid for a live camera. A Range value that works for one NVR may not work for another vendor.

Common symptoms

Range-related problems include:

PLAY fails only when Range is present.
Stream starts but with long delay.
Resume after pause fails.
Client receives old buffered video.
NVR playback starts at wrong time.
RTP timestamps jump after resume.
Camera ignores Range but returns 200 OK.
Server returns invalid Range response.

The player may show this as buffering or black video, but the root evidence is in PLAY.

Server response matters

After PLAY, the server may return a Range header:

RTSP/1.0 200 OK
Range: npt=0.000-
RTP-Info: url=...;seq=...;rtptime=...

RTP-Info pode mapear a resposta do controle para a sequência RTP inicial e valores de carimbo de data / hora. Se o RTP-Info estiver ausente, errado ou inconsistente, os clientes poderão ter dificuldade para alinhar o tempo da mídia.

Inspecionar:

Faixa enviada pelo cliente.
Intervalo retornado pelo servidor.
Sequência RTP-Info e rtptime.
Primeira sequência RTP após PLAY.
Primeiro carimbo de data/hora RTP após PLAY.

Pausar e retomar

Algumas câmeras suportam PAUSE; outros não oferecem suporte adequado para transmissões ao vivo. Um cliente pode pausar e posteriormente enviar PLAY com um valor Range que o servidor trata como uma busca. O servidor pode rejeitá-lo ou reiniciar o stream.

Se o currículo quebrar, compare o primeiro PLAY com o currículo PLAY.

Lista de verificação de depuração

Use este processo:

Capture a solicitação e resposta PLAY.
Verifique se o cliente envia Range.
Registre o valor exato: npt=now-, npt=0-, faixa de clock ou ausente.
Verifique o intervalo de resposta do servidor e RTP-Info.
Compare a primeira sequência/carimbo de data/hora RTP após PLAY.
Teste com e sem Range se o cliente permitir.
Teste a transmissão ao vivo e a reprodução gravada separadamente.
Verifique a sequência do método de pausa/retomada.
Evite culpar o RTP até que o tempo do PLAY seja compreendido.
Preserve todo o fluxo de controle RTSP para diagnóstico do fornecedor.

Diagnóstico final

Problemas de intervalo RTSP são problemas de temporização de controle de reprodução. O stream pode ser autenticado e configurado corretamente, mas PLAY ainda pode começar do ponto errado ou falhar porque o servidor não aceita o intervalo solicitado.

O RTSP Inspector ajuda mostrando Range, RTP-Info e os primeiros pacotes RTP juntos, para que problemas de horário de início de reprodução ao vivo possam ser diagnosticados a partir de evidências de protocolo.

Evidência reproduzível para “Cabeçalho de intervalo RTSP e npt = agora: depuração de erros de hora de início de reprodução ao vivo, retomada e busca 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 “Cabeçalho de intervalo RTSP e npt = agora: depuração de erros de hora de início de reprodução ao vivo, retomada e busca 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.

Da observação ao veredito por camada

Em “Cabeçalho de intervalo RTSP e npt = agora: depuração de erros de hora de início de reprodução ao vivo, retomada e busca de câmera”, escreva primeiro a observação e depois a interpretação. Outra pessoa deve localizar a observação na captura: estado RTSP ligado a CSeq, valor SDP, resposta Transport, lacuna de sequência, mudança de SSRC ou diferença entre RTP timestamp e RTCP sender report. “O servidor está lento” ou “o codec é incompatível” continua hipótese até que uma prova específica a explique melhor que as alternativas.

Divida o fluxo em fronteiras. Primeiro TCP abre; depois OPTIONS ou DESCRIBE é aceito. SDP deve descrever faixa utilizável, control URL, payload type e clock rate. SETUP precisa de resposta Transport compatível e PLAY de Session válida. Só então vêm chegada RTP, ordem, tempo e preparo do decoder. Pare na primeira fronteira sem prova de sucesso.

Mantenha fonte e intervalo constantes nas comparações. UDP contra TCP interleaved usa caminho e credenciais iguais. Main stream contra sub stream preserva cliente e transporte. Ao comparar VLC com VMS, registre métodos, cabeçalhos e URL reais. Diferença em control URL, Authorization, Session ou keepalive pode explicar o resultado melhor que o nome do programa.

Matriz de exclusão

Comece com duas hipóteses. Sem mídia, UDP pode estar bloqueado ou o servidor pode enviar a outras portas. TCP interleaved testa a primeira; comparar oferta e resposta Transport, IP e portas testa a segunda. Para imagem corrompida, RTP sequence separa perda de inicialização incompleta, enquanto SPS/PPS/VPS antes do primeiro frame testa os parâmetros codec.

Para cada hipótese anote prova favorável e prova que pode refutá-la. Uma afirmação que nenhum pacote consegue negar é ampla demais. “NAT descarta UDP” é refutada por RTP na porta do cliente. “Faltam parâmetros H.264” é refutada por SPS e PPS válidos antes de IDR. Assim o relatório mantém prioridade.

Não misturar relógios

RTSP CSeq ordena transações, RTP sequence ordena pacotes, RTP timestamp expressa tempo de amostra e capture clock expressa chegada ao ponto observado. Não são o mesmo relógio. Variação de chegada não prova drift; salto timestamp não prova perda sem sequência. RTCP sender report liga relógios RTP de áudio e vídeo a uma referência comum.

Pacote de aceitação

Encerre quando a correção se repetir em conexão nova com uma mudança documentada. O relatório informa entradas, última fronteira correta, primeira prova falha, alteração, resultado e testes abertos. Anexe transcript curto ou estatísticas focadas. Oculte segredos, mas preserve CSeq, Session limpa, SSRC e intervalo.

Use a solução de problemas RTSP para reconstruir o fluxo e os relatórios do RTSP Inspector para entregar a fronteira à equipe de câmera, rede ou VMS.