2026-06-02

Correção de desvio de carimbo de data/hora RTSP: incompatibilidade de taxa de clock RTP, sincronização de áudio/vídeo e erros de tempo de quadro

Corrige o desvio do carimbo de data/hora RTSP que causa perda de sincronização de áudio/vídeo. Cobre incompatibilidade de taxa de clock RTP, jitter, tempo de quadro, carimbos de data/hora não monotônicos e instabilidade de reprodução de fluxo de câmera.

Um fluxo de câmera RTSP pode se conectar com êxito, autenticar corretamente, retornar SDP válido, enviar pacotes RTP e ainda assim se comportar mal. O vídeo pode lentamente ficar para trás em tempo real. Áudio e vídeo podem ficar fora de sincronia. Os frames podem chegar, mas serem reproduzidos de forma desigual. Um gravador pode criar arquivos com duração estranha. Um jogador pode mostrar avisos de jitter, stutter, "timestamp não monotônico", "DTS inválido", "salto de timestamp RTP" ou "incompatibilidade de taxa de clock".

Os usuários procuram por "desvio de carimbo de data/hora RTP", "sincronização de áudio e vídeo da câmera RTSP", "taxa de clock RTP errada", "carimbo de data e hora de interrupção do fluxo RTSP" e "problema de temporização do quadro do fluxo da câmera" quando a conexão de rede funciona, mas a linha do tempo da mídia não.

Este é exatamente o tipo de problema em que um teste apenas para jogadores é muito superficial. O player pode ocultar a linha do tempo do pacote atrás do buffer e da decodificação. O RTSP Inspector é útil porque o tempo RTP é uma evidência de protocolo: tipo de carga útil, carimbo de data/hora RTP, número de sequência, bit do marcador, taxa de clock SDP, relatórios de remetente RTCP, jitter e mapeamento de relógio de parede, tudo isso importa.

Os carimbos de data e hora RTP não são carimbos de data e hora de relógio de parede

Um carimbo de data/hora RTP é um valor de clock de mídia, não um carimbo de data/hora Unix. Para vídeo H.264, o SDP geralmente declara um clock de 90 kHz:

a=rtpmap:96 H264/90000

90000 / 30 = 3000

Para vídeo de 25 fps, o incremento geralmente é de 3600:

90000 / 25 = 3600

SDP clock rate is the first clue

m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
m=audio 0 RTP/AVP 97
a=rtpmap:97 MPEG4-GENERIC/48000/2

Se o SDP disser que H.264 usa 90000, o cliente deverá interpretar os carimbos de data e hora RTP do vídeo com esse relógio. Se o SDP estiver ausente, malformado ou inconsistente com o comportamento da carga útil, o cliente poderá adivinhar incorretamente.

Problemas comuns de temporização do SDP incluem:

a=rtpmap ausente para o tipo de carga dinâmica.
Taxa de clock de áudio errada.
Tipo de carga reutilizado de forma inconsistente.
O firmware da câmera declara 90.000, mas envia incrementos de carimbo de data/hora que não correspondem à taxa de quadros.
A configuração AAC não corresponde à taxa de amostragem real.
Várias faixas usam atributos de controle confusos ou duplicados.

O Inspetor RTSP deve ajudar a preservar o SDP ao lado da evidência RTP porque a linha do tempo RTP não pode ser interpretada corretamente sem ela.

Número de sequência versus carimbo de data/hora

Os números de sequência e carimbos de data/hora RTP respondem a perguntas diferentes.

O número de sequência ajuda a detectar perda e ordenação de pacotes:

O pacote 1024 chegou?
O pacote 1025 chegou?
O pacote 1026 chegou antes de 1025?
Estão faltando pacotes?

O carimbo de data/hora RTP ajuda a interpretar o tempo da mídia:

Quais pacotes pertencem ao mesmo quadro de vídeo?
Quanto tempo de mídia passou entre os frames?
A câmera saltou para frente ou para trás?
O áudio está avançando na taxa esperada?
O horário da mídia corresponde ao horário do relógio de parede?

Um fluxo pode ter continuidade de sequência perfeita e ainda assim ter carimbos de data/hora quebrados. Também pode haver alguma perda de pacotes, enquanto os carimbos de data e hora permanecem consistentes.

Limites de bits do marcador e quadros de vídeo

Para muitas cargas de vídeo RTP, o bit marcador indica um limite de quadro. Com o H.264, vários pacotes RTP podem transportar fragmentos de um quadro de vídeo. Eles compartilham o mesmo carimbo de data/hora RTP e o bit marcador geralmente aparece no último pacote da unidade de acesso.

Se os carimbos de data e hora mudarem com muita frequência, não com frequência suficiente, ou se o comportamento do marcador for inconsistente, a reconstrução do quadro poderá se tornar instável.

Os sintomas incluem:

Vídeo travado sem perda visível de pacotes.
O decodificador recebe quadros incompletos.
O gravador cria uma duração de quadro incorreta.
A reprodução acelera ou desacelera.
Os carimbos de data/hora do quadro não são monotônicos.

É por isso que uma ferramenta de diagnóstico deve mostrar metadados RTP em nível de pacote, não apenas quadros decodificados.

Desvio de sincronização de áudio/vídeo

A sincronização de áudio e vídeo depende do mapeamento do carimbo de data/hora RTP de cada faixa de mídia para uma base de tempo compartilhada. Os relatórios de remetente RTCP são frequentemente usados para isso. Um relatório do remetente pode mapear o carimbo de data/hora RTP para o horário NTP:

RTCP SR:
NTP timestamp: wall-clock reference
RTP timestamp: media timestamp at that reference

Audio/video drift can happen when:

Timestamp jumps

Look for:

Questions to separate them:

Checklist for RTP timestamp drift

Use this workflow:

What to include in a useful report

Final diagnosis

Evidência reproduzível para “Correção de desvio de carimbo de data/hora RTSP: incompatibilidade de taxa de clock RTP, sincronização de áudio/vídeo e erros de tempo de quadro”

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 “Correção de desvio de carimbo de data/hora RTSP: incompatibilidade de taxa de clock RTP, sincronização de áudio/vídeo e erros de tempo de quadro”, 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 “Correção de desvio de carimbo de data/hora RTSP: incompatibilidade de taxa de clock RTP, sincronização de áudio/vídeo e erros de tempo de quadro”, 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.