2026-06-03

Modo de empacotamento RTP H.264 0 vs 1 em RTSP SDP: NAL único, FU-A, STAP-A e compatibilidade de câmera

Como depurar o modo de empacotamento H.264 no SDP RTSP, modo de empacotamento = 0 vs 1, pacotes NAL únicos, fragmentação FU-A, agregação STAP-A e compatibilidade com decodificador de câmera.

H.264 sobre RTP não é apenas “enviar pacotes de vídeo”. O modo de empacotamento do SDP controla como as unidades NAL podem ser transportadas. Os usuários procuram por "modo de empacotamento H264 0", "modo de empacotamento H264 1", "RTSP FU-A não suportado", "modo de unidade NAL única", "STAP-A RTP H264" e "modo de empacotamento SDP da câmera H264" quando um cliente decodifica o fluxo e outro falha.

O RTSP Inspector é útil porque o modo de empacotamento é um problema de compatibilidade de SDP e RTP. Um player só pode mostrar vídeo preto. O rastreamento pode mostrar se o fluxo anunciou o modo 0, mas usou fragmentação, ou o modo 1 anunciado, mas o receptor aceitou apenas pacotes NAL únicos.

Por que o modo de empacotamento é importante

As cargas H.264 RTP podem ser enviadas de diferentes maneiras:

Pacotes unitários NAL únicos.
Unidades de fragmentação como FU-A.
Pacotes de agregação como STAP-A.

A linha SDP fmtp pode incluir:

a=fmtp:96 packetization-mode=1;profile-level-id=42e01f;sprop-parameter-sets=...

packetization-mode=0

Symptoms when mode 0 is involved:

packetization-mode=1

Evidence to check:

Missing packetization-mode

This creates compatibility reports like:

FU-A fragmentation evidence

STAP-A aggregation evidence

Potential issues:

MTU and keyframe problems

Evidence:

Debug checklist

Use this process:

Final diagnosis

Evidência reproduzível para “Modo de empacotamento RTP H.264 0 vs 1 em RTSP SDP: NAL único, FU-A, STAP-A e compatibilidade de câmera”

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 “Modo de empacotamento RTP H.264 0 vs 1 em RTSP SDP: NAL único, FU-A, STAP-A e compatibilidade de câmera”, 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 “Modo de empacotamento RTP H.264 0 vs 1 em RTSP SDP: NAL único, FU-A, STAP-A e compatibilidade de câmera”, 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.