Erro de RTP na correção de fluxo primário: diagnosticar perda de pacotes, congelamentos de câmera e macroblocos em RTSP

Quando o fluxo de uma câmera IP congela, falha ou produz erros no decodificador H.264, o sintoma visível geralmente é tardio. A causa geralmente aparece no início da sequência RTP. Um pacote RTP ausente pode remover uma fatia de dados de vídeo da qual dependem os quadros posteriores. No momento em que o jogador registra um erro de decodificação, a evidência da rede já pode ter desaparecido.

É por isso que a solução de problemas de RTP deve começar com números de sequência, carimbos de data e hora, tipo de carga útil, comportamento do marcador e estrutura do codec antes de alterar as configurações aleatórias da câmera.

O que as lacunas na sequência RTP lhe dizem

Cada pacote RTP carrega um número de sequência. Para um fluxo constante, a sequência deve avançar de forma previsível. Uma lacuna significa que um ou mais pacotes não chegaram. Um salto para trás pode indicar reordenamento, entrega duplicada, comportamento de reinicialização ou problemas de limite de captura.

As questões práticas são:

• quantos pacotes estavam faltando?
• a perda aconteceu uma vez ou repetidamente?
• isso ocorreu perto de quadros-chave?
• os relatórios do remetente RTCP continuaram?
• a sessão de controle RTSP permaneceu ativa?
• a falha do decodificador aconteceu após o intervalo?

Essa evidência pode separar a perda de rede dos bugs de carga útil da câmera. Se as lacunas na sequência estiverem alinhadas com a corrupção visual, o caso será mais forte. Se a continuidade da sequência for perfeita, mas a carga estiver malformada, o diagnóstico passará para o comportamento do codificador ou de empacotamento.

Por que H.264 e H.265 são sensíveis a perdas

O vídeo compactado não é uma lista de imagens independentes. Os interquadros dependem de referenciais. Uma pequena perda de pacote pode danificar mais do que o pacote imediato. Os fluxos H.264 e H.265 também podem contar com conjuntos de parâmetros como SPS e PPS, e H.265 adiciona VPS. Se eles estiverem faltando, atrasados ​​ou corrompidos, o software downstream poderá rejeitar o fluxo mesmo quando um visualizador tolerante parecer se recuperar.

Os sintomas comuns incluem:

• macroblocos ou artefatos em bloco
• congela seguido por recuperação repentina
• Erros de decodificador de estilo "referência ausente"
• o fluxo é iniciado, mas nenhum quadro fica pronto para decodificação
• corrupção repetida após cenas com muito movimento

Estes sintomas não são suficientes por si só. As evidências de RTP e codec os tornam acionáveis.

Não confunda Jitter com Perda

Jitter significa que os pacotes chegam com tempo irregular. Perda significa que os pacotes não chegam. Ambos podem causar falhas visíveis ao usuário, mas exigem soluções diferentes.

Para jitter, inspecione a progressão do carimbo de data/hora e o tempo de chegada. Para perdas, inspecione as lacunas de sequência. Para erros de firmware da câmera, inspecione a consistência da carga útil e a estrutura NAL. Um relatório de campo que diz apenas "o fluxo está instável" não informa ao engenheiro de rede, ao engenheiro de firmware ou ao fornecedor de VMS o que mudar.

O melhor relatório diz:

• Gap de sequência RTP de N para N+M
• salto de timestamp observado no mesmo ponto
• A sessão RTSP permaneceu estabelecida
• o tipo de carga útil permaneceu estável
• A fatia H.264 estava incompleta
• próximo quadro IDR restaurou a prontidão do decodificador

Esse é um artefato de suporte muito mais forte.

UDP e TCP contam histórias diferentes

O RTSP normalmente transporta RTP por UDP ou por TCP intercalado. O UDP expõe diretamente a perda de pacotes. O TCP pode fazer com que os caminhos UDP bloqueados desapareçam, mas pode introduzir latência e não prova que o caminho de implantação pretendido está íntegro.

Para diagnóstico, compare os dois modos:

• O UDP falha com lacunas de sequência: inspecione perda de rede, switches, Wi-Fi, firewall, NAT ou comportamento de envio de câmera.
• O UDP não recebe RTP: inspecione as portas negociadas e a política de firewall.
• O TCP funciona, mas o UDP falha: caminho de rede suspeito em vez de codec.
• ambos os modos mostram carga útil malformada: codificador de câmera suspeito, perfil de fluxo ou firmware.

A escolha do transporte é uma evidência, não apenas uma caixa de seleção do jogador.

Como o Inspetor RTSP enquadra o problema

O RTSP Inspector concentra-se na evidência do protocolo em vez da reprodução. Ele captura observações RTSP, RTP, RTCP e codec para que um caso de suporte possa ser reproduzido e explicado. Isso é importante quando o mesmo fluxo se comporta de maneira diferente no VLC, no FFmpeg, em um NVR, em um serviço de ingestão de nuvem e em um pipeline de análise.

O objetivo não é afirmar que todos os fluxos podem ser corrigidos localmente. O objetivo é identificar o dono da falha:

• caminho de rede
• configuração da câmera
• empacotamento de firmware
• suporte ao decodificador downstream
• limite de codec não suportado
• incompatibilidade esperada de implantação UDP/TCP

A perda de RTP não é apenas um sintoma de vídeo. É um evento de protocolo mensurável. Depois de medido, a conversa sobre solução de problemas se torna muito mais curta.