SDP, H.264 e H.265 em diagnósticos RTSP: os metadados que decidem se o vídeo pode ser iniciado

Muitas falhas de RTSP são descritas como “o fluxo da câmera não é reproduzido”. Essa frase esconde o limite de diagnóstico mais importante: "o que a câmera alegou no SDP e a carga útil da mídia correspondeu a essa afirmação?" O SDP costuma ser a primeira evidência estruturada disponível em uma sessão RTSP. Ele declara trilhas de mídia, tipos de carga útil, nomes de codecs, taxas de clock, URLs de controle e parâmetros específicos de codecs. Se o SDP estiver errado, incompleto ou não for suportado pelo consumidor, um fluxo poderá falhar antes que o primeiro quadro seja decodificado.

O que o SDP deve provar

Após DESCRIBE, um cliente deve saber se o fluxo contém vídeo, qual tipo de carga mapeia para qual codec e como a trilha de mídia deve ser configurada. Para diagnóstico da câmera, inspecione:

• seção de mídia m=video
• URL da faixa a=control
• Tipo de carga útil a=rtpmap e nome do codec
• Parâmetros do codec a=fmtp
• H.264 sprop-parameter-sets quando presente
• Sinalização H.265 VPS/SPS/PPS quando disponível
• se a taxa de clock anunciada é esperada

Se o SDP anunciar H.264, mas a câmera enviar outra coisa, o receptor não está sendo irracional. Se o SDP omitir evidências de parâmetros essenciais e o fluxo nunca as enviar na banda, o decodificador poderá não ter informações suficientes para começar.

Conjuntos de parâmetros H.264 não são evidências opcionais

Os decodificadores H.264 precisam de informações de parâmetros de sequência e imagem. Nas implantações de câmeras RTSP, essa evidência pode aparecer no SDP, em cargas RTP em banda ou em ambos. Os problemas aparecem quando uma câmera assume que o receptor já sabe algo que não sabe.

Um registro de diagnóstico limpo responde:

• o SPS estava visível?
• o PPS estava visível?
• as cargas úteis incluíam um quadro IDR?
• a transmissão começou no meio do GOP?
• o ID do nível do perfil parecia plausível?
• o modo de empacotamento correspondeu à estrutura de carga útil observada?

Isto é especialmente importante quando um jogador trabalha e outro não. Um visualizador tolerante pode sobreviver a metadados questionáveis. Um pipeline de gravação, análise ou conformidade pode rejeitá-lo.

H.265 adiciona mais limites de compatibilidade

O H.265 é comum em câmeras modernas, especialmente quando a largura de banda é importante, mas tem suporte menos universal do que o H.264 em ferramentas mais antigas e consumidores incorporados. O H.265 também traz evidências de VPS além de SPS e PPS. Uma implantação que diz apenas "RTSP funciona" ainda pode falhar porque o perfil real do codec ou a entrega de parâmetros estão fora do limite suportado do consumidor.

Para equipes de campo, um artigo, ticket ou relatório útil não deve dizer apenas “mudar para H.264”. Deve explicar o porquê:

• o consumidor atual não tem suporte H.265
• os conjuntos de parâmetros H.265 estão ausentes ou atrasados
• o tipo de carga útil não corresponde ao mapeamento de codec esperado
• o fluxo é válido, mas está fora do limite do produto
• o perfil da câmera deve ser alterado para este fluxo de trabalho

Esse nível de clareza evita alterações repetidas por tentativa e erro.

SDP deve ser comparado com RTP

O SDP é uma reivindicação. RTP é a evidência que se segue. Os dois devem ser comparados.

Exemplos:

• O SDP afirma que o tipo de carga útil 96 é H.264, mas o RTP chega com um tipo de carga útil diferente.
• SDP contém uma trilha de vídeo, mas nenhum RTP segue PLAY.
• O SDP diz H.265, mas o produto downstream suporta apenas H.264.
• O SDP omite conjuntos de parâmetros e o RTP nunca os envia antes dos slices.
• O RTP chega, mas a estrutura da unidade NAL é inconsistente com o codec anunciado.

Esses casos exigem próximas ações diferentes. Sem comparar SDP e RTP, todos eles parecem a mesma falha vaga de “sem vídeo”.

Por que o inspetor RTSP revela esta evidência

O RTSP Inspector foi projetado para engenheiros de fluxo, fornecedores de câmeras e integradores de CFTV que precisam de evidências repetíveis. Intencionalmente, não é um reprodutor de mídia genérico. Sua função é inspecionar o caminho de controle RTSP, os metadados SDP, o fluxo RTP/RTCP e a prontidão H.264/H.265.

Isso torna o resultado útil em conversas de suporte:

• fornecedor de câmera: consertar SDP ou empacotamento
• equipe de rede: corrigir caminho de entrega RTP
• Equipe VMS: ajuste o perfil de codec suportado
• integrador de campo: alterar perfil de fluxo ou modo de transporte
• cliente: entenda por que a reprodução não é prova da integridade do protocolo

Nos diagnósticos RTSP, o SDP não é um texto clichê. É o primeiro contrato que o stream oferece. Se esse contrato for quebrado, o resto do pipeline estará adivinhando.