2026-06-03

Depuração de sincronização de áudio/vídeo RTCP CNAME e RTSP: carimbos de data/hora RTP, relatórios de remetente, sincronização labial e desvio de trilha

Como depurar RTCP CNAME, mapeamento de carimbo de data/hora RTP, relatórios de remetente, sincronização de áudio/vídeo, desvio de sincronização labial e problemas de temporização de câmera RTSP multitrilha.

Os fluxos RTSP com áudio e vídeo podem se conectar com sucesso e ainda assim ficar inutilizáveis se o áudio e o vídeo se separarem. Os usuários pesquisam "Áudio e vídeo RTSP fora de sincronia", "Sincronização labial RTCP CNAME", "Desvio de carimbo de data/hora RTP", "Atraso de áudio da câmera", "Sincronização de relatório de remetente RTCP" e "Vídeo RTSP antes do áudio" quando a reprodução começa, mas o tempo parece errado.

O RTSP Inspector é útil porque este é um problema de temporização de protocolo. A evidência importante não é apenas a mídia decodificada. É a relação entre carimbos de data/hora RTP, relatórios de remetente RTCP, valores SSRC, valores CNAME, relógios de rastreamento e tempo de chegada.

Por que os carimbos de data/hora RTP por si só não são suficientes

Os carimbos de data/hora RTP são relativos a cada relógio de mídia. Uma trilha de vídeo pode usar um clock de 90 kHz. Uma trilha de áudio pode usar 8 kHz, 16 kHz, 44,1 kHz ou 48 kHz dependendo do codec e do SDP.

Isso significa que isso não é suficiente:

video RTP timestamp: 900000
audio RTP timestamp: 480000

What RTCP Sender Reports provide

A useful report should show:

What CNAME is for

Failures include:

Lip sync drift

Immediate offset suggests:

Gradual drift suggests:

Wrong clock rate in SDP

Evidence:

RTCP blocked by transport path

Symptoms:

Gateway and restreamer issues

Problems include:

Debug checklist

Use this workflow:

Final diagnosis

Evidência reproduzível para “Depuração de sincronização de áudio/vídeo RTCP CNAME e RTSP: carimbos de data/hora RTP, relatórios de remetente, sincronização labial e desvio de trilha”

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 “Depuração de sincronização de áudio/vídeo RTCP CNAME e RTSP: carimbos de data/hora RTP, relatórios de remetente, sincronização labial e desvio de trilha”, 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 “Depuração de sincronização de áudio/vídeo RTCP CNAME e RTSP: carimbos de data/hora RTP, relatórios de remetente, sincronização labial e desvio de trilha”, 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.

Registro da mudança e teste de regressão

Transforme a correção em registro repetível: valor anterior e novo, local da configuração, hora da reconexão e efeito esperado nos pacotes. Em TCP interleaved não basta “a imagem apareceu”; a mídia deve deixar de depender de portas UDP e surgir nos canais negociados. Se control URL mudou, SETUP deve usar o caminho novo e PLAY e keepalive devem preservar a mesma Session.

Quando for seguro, faça um controle negativo. Restaure o valor anterior em ambiente de teste ou compare uma captura antiga com entradas iguais; a mesma fronteira deve falhar. Isso evita confundir reinício, cache ou mudança de rede não documentada com a solução. Em câmera de produção, use evidência histórica e não provoque a queda.

Mantenha a conexão além de keepalive e Session timeout. Observe OPTIONS ou GET_PARAMETER e a coerência de CSeq e Session. Em RTP compare perda, duplicatas e reordenação em janelas iguais antes e depois. Para codec abra conexão nova e espere o primeiro IDR; decoder já inicializado pode esconder parâmetros iniciais ausentes.

Limite a afirmação: “main stream TCP verificado dez minutos com este cliente” é melhor que “RTSP corrigido”. Informe faixa, transporte, codec, cliente e duração. Áudio, sub stream e reconexão após perda de rede ficam abertos se não foram testados.

Separe fatos e recomendação. Fatos são respostas, pacotes e medidas; recomendação propõe mudança em câmera, firewall ou cliente. Outra equipe deve aceitar os fatos mesmo escolhendo outra solução. Termine com responsável, próxima ação e critério, entregando o intervalo pela guia de relatórios RTSP.

Faça a revisão final em uma cópia exportada, não de memória. Outra pessoa deve localizar a última operação correta, o primeiro pacote que mudou o veredito e a razão para excluir uma alternativa usando intervalo, campos e links internos. Registre versões de câmera e cliente quando conhecidas, mas não trate a versão sozinha como causa. Informe também o ponto de captura: um pacote ausente junto ao cliente pode existir na saída do servidor. Se os pontos diferirem, o trecho entre eles vira o próximo escopo. Termine com data, duração e resultado explícito: aprovado, falho ou pendente com motivo. Preserve o filtro de captura e a diferença de relógio entre os hosts; sem isso, duas observações do mesmo evento podem parecer incompatíveis apenas por usarem filtros ou referências de tempo diferentes. Execute o mesmo procedimento mais uma vez e registre qualquer divergência antes de declarar o caso encerrado.