H.264 SPS/PPS ausente em fluxos RTSP: por que o VLC é reproduzido, mas o FFmpeg ou o Analytics falham

Um padrão frustrante de falha de RTSP é familiar aos engenheiros de câmera: "o VLC reproduz o stream, mas o FFmpeg, um VMS, um pipeline de análise ou um serviço de ingestão de nuvem falha com erros de decodificador. O tópico de suporte muitas vezes se torna um debate sobre qual ferramenta é “certa”. A melhor questão é se o fluxo fornece evidências suficientes de parâmetros H.264 para um novo decodificador." H.264 precisa de conjuntos de parâmetros de sequência e conjuntos de parâmetros de imagem. Os engenheiros geralmente os chamam de SPS e PPS. Eles descrevem como o fluxo de bits deve ser decodificado: "perfil, nível, dimensões, comportamento de referência e estrutura da imagem. Sem eles, um decodificador pode ver os dados da fatia, mas ainda não ter um contexto válido para transformá-los em quadros."

Onde o SPS e o PPS podem aparecer

Nas implantações RTSP, as evidências SPS/PPS podem aparecer em mais de um lugar:

• SDP conjuntos de parâmetros sprop
• cargas úteis RTP em banda antes das fatias
• repetido antes dos quadros-chave
• armazenado em cache por um jogador tolerante de uma sessão anterior
• entregue somente após aguardar o próximo IDR

Isso explica o problema de "funcionar em um visualizador". Um jogador pode reutilizar o estado, esperar mais, recuperar referências perdidas ou aplicar ocultação de erros. Um serviço de ingestão estrito pode começar com um decodificador vazio e rejeitar o fluxo até que o SPS/PPS e um quadro-chave utilizável cheguem.

O que o erro realmente significa

Mensagens como "imagem ausente na unidade de acesso", "erro de cabeçalho de fatia de decodificação", "PPS inexistente referenciado" ou "aguardando SPS/PPS" não significam automaticamente que a câmera está quebrada. Eles significam que o decodificador não tinha o contexto de parâmetro necessário no ponto em que tentou decodificar.

As questões diagnósticas são:

• o SDP incluiu sprop-parameter-sets?
• foram SPS e PPS vistos na carga útil RTP?
• eles chegaram antes da primeira fatia?
• um quadro IDR apareceu após os conjuntos de parâmetros?
• a perda de pacotes removeu o pacote do conjunto de parâmetros?
• a transmissão começou no meio do GOP?
• o tipo de carga útil era consistente com o SDP?

Depois que essas perguntas forem respondidas, a próxima ação ficará mais clara.

Por que o início do fluxo Mid-GOP é arriscado

Muitas câmeras começam a enviar a partir da posição atual do codificador quando o cliente RTSP se conecta. Se o cliente ingressar no meio do GOP, ele poderá receber entre quadros antes de um quadro-chave. Se o fluxo também não repetir SPS/PPS regularmente, o decodificador poderá esperar ou falhar até o próximo limite adequado.

Para software de monitoramento, isso pode ser parecido com:

• tela preta por vários segundos
• o primeiro quadro aparece somente após o intervalo do movimento ou do quadro-chave
• pipeline de análise recusa o fluxo
• o restreamer é iniciado, mas os clientes downstream falham
• recuperação ocasional após reconectar

A correção pode ser do lado da câmera: reduzir o intervalo do quadro-chave, repetir conjuntos de parâmetros, usar um perfil de fluxo diferente ou mudar de H.265 para H.264 se o produto downstream tiver suporte mais estrito.

SDP é uma reivindicação; RTP é a prova

Alguns sistemas de câmeras anunciam SPS/PPS em SDP. Outros esperam que o decodificador espere por unidades NAL dentro da banda. Alguns fazem as duas coisas. Alguns não fazem nenhuma das duas coisas corretamente. Um relatório de diagnóstico deve comparar a reclamação com a carga útil.

Evidências úteis incluem:

• conjuntos de parâmetros base64 no SDP
• Tipos de unidades H.264 NAL observados em RTP
• primeiro índice de pacotes SPS/PPS
• primeiro índice de pacotes IDR
• perda de pacotes antes da prontidão do quadro-chave
• status de prontidão do decodificador

Isto é muito mais forte do que “tentar outro jogador”. Ele informa ao fornecedor se deve alterar o SDP, as configurações do codificador ou o comportamento de empacotamento.

Onde o inspetor RTSP se encaixa

O RTSP Inspector foi projetado para inspecionar RTSP, SDP, RTP/RTCP e estrutura de codec sem fingir que a reprodução é o diagnóstico. Para casos SPS/PPS ausentes, o produto deve ajudar os engenheiros a mostrar:

• o stream foi conectado com sucesso
• SDP carregava ou não conjuntos de parâmetros
• RTP entregou ou não conjuntos de parâmetros
• a perda de pacotes afetou ou não o primeiro limite de decodificação
• a falha pertence aos metadados de fluxo, entrega de rede, suporte ao decodificador ou configuração da câmera

Este é o tipo de evidência que resolve o argumento “VLC funciona”. O funcionamento do VLC é uma informação útil. Não é prova de que o fluxo seja limpo para todos os consumidores.

Se sua consulta de pesquisa for "RTSP funciona em VLC, mas FFmpeg falha", inspecione SPS/PPS, quadros-chave, perda de pacotes e SDP antes de culpar o sistema downstream.