2026-06-02

Correção de fragmentação RTP H.264 FU-A: Por que seu vídeo RTSP está quebrado (perda de pacote, remontagem NAL)

Corrigir vídeo RTSP quebrado da fragmentação H.264 FU-A RTP. Cobre fragmentos ausentes, bugs de bits de início/fim, falhas de remontagem NAL, perda de pacotes, MTU e erros de decodificador com comandos de diagnóstico reais.

O H.264 sobre RTP quebra de maneiras que parecem bugs de decodificador, mas na verdade são problemas de empacotamento. A sessão RTSP funciona. DESCRIBE retorna SDP válido. A CONFIGURAÇÃO foi bem-sucedida. PLAY retorna 200 OK. Os pacotes RTP chegam com o tipo de carga correto mapeado para H.264. Ainda assim, o vídeo mostra corrupção de blocos, congelamentos, quadros pretos ou erros de decodificador.

Os erros são assim nos seus registros:

[h264 @ 0x...] invalid NAL unit size
[h264 @ 0x...] missing picture in access unit
[h264 @ 0x...] non-existing PPS 0 referenced
[h264 @ 0x...] decode_slice_header error
[h264 @ 0x...] no frame!

The fast answer

Why fragmentation exists

The structure of an FU-A packet

Each FU-A RTP packet contains:

Byte 0: FU indicator
  bit 7: F (forbidden_zero_bit) — normally 0
  bits 6-5: NRI (nal_ref_idc) — priority
  bits 4-0: Type = 28 (FU-A)
Byte 1: FU header
  bit 7: S (Start) — 1 for first fragment
  bit 6: E (End) — 1 for last fragment
  bit 5: R (Reserved) — always 0
  bits 4-0: Type — original NAL unit type (1=non-IDR, 5=IDR, 7=SPS, 8=PPS)
Byte 2+: Fragment payload — the actual NAL unit data

Uma sequência FU-A completa para uma unidade NAL:

Packet 1: FU indicator (type=28) | FU header (S=1, E=0, type=5) | payload[0..N]
Packet 2: FU indicator (type=28) | FU header (S=0, E=0, type=5) | payload[N+1..M]
Packet 3: FU indicator (type=28) | FU header (S=0, E=0, type=5) | payload[M+1..P]
Packet 4: FU indicator (type=28) | FU header (S=0, E=1, type=5) | payload[P+1..END]

The RTP marker bit

Failure modes: what breaks and why

Failure 1: Missing middle fragment

Expected:  1000(S)  1001(M)  1002(M)  1003(E|marker)
Received:  1000(S)  1001(M)  [LOST]   1003(E|marker)

O remontador vê um fragmento inicial, um fragmento intermediário e, em seguida, um fragmento final — mas os bytes de carga útil não se conectam. A unidade NAL remontada apresenta uma lacuna.

Sintomas:

Bloqueie a corrupção em uma faixa horizontal do quadro
O decodificador relata "tamanho de unidade NAL inválido"
Corrupção limitada a uma unidade de acesso (eliminada no próximo IDR)

Falha 2: Fragmento inicial ausente

Expected:  1000(S)  1001(M)  1002(E)
Received:  [LOST]   1001(M)  1002(E)

Failure 3: Missing end fragment

Expected:  1000(S)  1001(M)  1002(E|marker)
Received:  1000(S)  1001(M)  [LOST]

O remontador nunca vê o fragmento final. O limite da unidade NAL nunca é confirmado. O decodificador espera por mais dados que nunca chegam.

Sintomas:

O vídeo congela
O decodificador relata “imagem faltando na unidade de acesso”
A reprodução é interrompida até a próxima unidade de acesso completo chegar

Falha 4: Fragmentos fora de ordem

Expected:  1000(S)  1001(M)  1002(E)
Received:  1000(S)  1002(E)  1001(M)

Diagnostic workflow

Step 1: Confirm H.264 payload mapping

m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=4D0029;sprop-parameter-sets=...

packetization-mode=1 significa modo não intercalado (FU-A é suportado)
packetization-mode=0 significa modo de unidade NAL única (sem fragmentação - muito limitada)

Etapa 2: rastrear números de sequência RTP

Na sua captura, observe os números de sequência RTP da trilha de vídeo. Lacunas indicam perda de pacotes:

Seq 1000: FU-A Start, NAL type 5 (IDR)
Seq 1001: FU-A middle
Seq 1003: FU-A End, marker=1   ← gap at 1002

Step 3: Inspect FU-A headers

Byte 0 (FU indicator):
  0x7C = NRI=3, Type=28 (FU-A)

Byte 1 (cabeçalho FU):
  0x85 = S=1, E=0, R=0, Tipo=5 (fatia IDR) ← fragmento inicial do IDR
  0x45 = S=0, E=0, R=0, Tipo=5 ← fragmento do meio
  0x65 = S=0, E=1, R=0, Tipo=5 ← fragmento final; marcador apenas se esta NAL encerrar a unidade de acesso

Valores errados para procurar:

S=1 em um pacote não iniciado → confusão do remontador
Marcador definido antes de E=1 → limite falso da unidade de acesso
E=1 sem marcador pode ser válido se outra unidade NAL vier em seguida
Alterações de tipo no meio da sequência → bug do codificador ou corrupção de fluxo

Etapa 4: verifique a remontagem completa

Para cada unidade NAL:

Encontre o fragmento inicial (S=1)
Siga os números de sequência consecutivos até o fragmento final (E=1)
Contar fragmentos; verifique se não há lacunas na sequência
Compare o marcador com o limite da unidade de acesso; não o exija em todo fragmento final FU-A
Verifique se todos os fragmentos têm o mesmo carimbo de data/hora e tipo de NAL

Passo 5: Compare modos de transporte

Execute o mesmo fluxo em UDP e TCP intercalados. Se o vídeo estiver limpo no TCP, mas corrompido no UDP, o problema é a perda de pacotes de rede, e não problemas de codificador ou decodificador.

Etapa 6: análise de IDR versus não IDR

Os quadros IDR são maiores e requerem mais fragmentos FU-A por unidade NAL. Mais fragmentos = mais exposição à perda de pacotes. Se a corrupção aparecer principalmente nas mudanças de cena ou a cada poucos segundos (no intervalo do IDR), os quadros do IDR serão as vítimas.

Opções de correção:

Diminua o tamanho do quadro IDR (reduza a resolução ou taxa de bits para quadros-chave)
Aumente o intervalo IDR (menos quadros grandes, mas recuperação mais lenta de perdas)
Reduza o MTU para FU-A no codificador (mais fragmentos, mas cada um é menor e tem menos probabilidade de acionar a fragmentação de IP)

Estratégias de recuperação

Na remontagem

Descarte totalmente as unidades de acesso danificadas em vez de alimentar dados parciais para o decodificador
Solicite um novo quadro IDR via RTCP (se suportado pela câmera)
Aguarde o próximo quadro IDR (o decodificador se recuperará automaticamente)

No codificador

Reduza o limite de tamanho da unidade NAL para reduzir fragmentos por unidade de acesso
Use intra-atualização periódica em vez de quadros IDR completos (quadros-chave menores)
Habilite FEC (correção direta de erros) se a pilha RTP suportar

Na rede

Mude de UDP para TCP intercalado se a perda de pacotes for inevitável
Certifique-se de que a descoberta de MTU do caminho funcione (evite a fragmentação de IP)
Priorize o tráfego RTP em links congestionados

Quando não é FU-A

Nem toda corrupção do H.264 é fragmentação FU-A. Verificar:

SPS/PPS ausente: Erros de decodificador como "PPS inexistente" — verifique SDP sprop-parameter-sets
Perfil/nível errado: O decodificador não consegue lidar com a complexidade do stream
Erro no codificador: O codificador produz sintaxe de unidade NAL inválida
Corrupção de fluxo de bits na origem: O codificador da câmera está quebrado, não a rede

Se os pacotes RTP chegarem com números de sequência perfeitos e cabeçalhos FU-A corretos, mas o decodificador ainda falhar, o problema está no próprio fluxo de bits H.264, não no transporte.

Evidência reproduzível para “Correção de fragmentação RTP H.264 FU-A: Por que seu vídeo RTSP está quebrado (perda de pacote, remontagem NAL)”

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 “Correção de fragmentação RTP H.264 FU-A: Por que seu vídeo RTSP está quebrado (perda de pacote, remontagem NAL)”, 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.

Resposta direta e limite de aceitação

A resposta curta para “Correção de fragmentação RTP H.264 FU-A: Por que seu vídeo RTSP está quebrado (perda de pacote, remontagem NAL)” é: Corrigir vídeo RTSP quebrado da fragmentação H.264 FU-A RTP. Cobre fragmentos ausentes, bugs de bits de início/fim, falhas de remontagem NAL, perda de pacotes, MTU e erros de decodificador com comandos de diagnóstico reais. Trate essa frase como um resultado a verificar, não como promessa para qualquer entrada, dispositivo, projeto ou ambiente. Um resultado completo registra estado inicial, ação exata, saída visível e condição que comprova a conclusão da tarefa no RTSP Inspector.

Procedimento orientado por evidências

Comece com um caso pequeno e repetível antes de alterar um projeto completo. Registre versão do aplicativo, sistema operacional, identidade da entrada ou dispositivo, configurações relevantes e resultado esperado. Execute uma ação deliberada, preserve a primeira transição inesperada e compare com um caso conhecido quando possível. Alterar vários controles ao mesmo tempo esconde qual condição criou ou corrigiu o problema.

Ponto de controle 1: Correção de fragmentação RTP H.264 FU-A: Por que seu vídeo RTSP está quebrado (perda de pa

Verifique “Correção de fragmentação RTP H.264 FU-A: Por que seu vídeo RTSP está quebrado (perda de pacote, remontagem NAL)” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 2: Corrigir vídeo RTSP quebrado da fragmentação H.264 FU-A RTP. Cobre fragmentos ausentes, bu

Quando “Corrigir vídeo RTSP quebrado da fragmentação H.264 FU-A RTP. Cobre fragmentos ausentes, bugs de bits de início/fim, falhas de remontagem NAL, perda de” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 3: The fast answer

Verifique “The fast answer” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 4: Why fragmentation exists

Quando “Why fragmentation exists” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 5: The structure of an FU-A packet

Verifique “The structure of an FU-A packet” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 6: The RTP marker bit

Quando “The RTP marker bit” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 7: Failure modes: what breaks and why

Verifique “Failure modes: what breaks and why” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 8: Failure 1: Missing middle fragment

Quando “Failure 1: Missing middle fragment” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Ponto de controle 9: Falha 2: Fragmento inicial ausente

Verifique “Falha 2: Fragmento inicial ausente” com a menor entrada representativa. Mantenha configurações não relacionadas, repita a mesma ação e confira o resultado após reabrir ou reconectar. Uma captura isolada é mais fraca que um registro com entrada, configuração, ação, saída e horário.

Ponto de controle 10: Failure 3: Missing end fragment

Quando “Failure 3: Missing end fragment” for ambíguo, compare um caso bom e outro falho sob condições equivalentes. Marque a primeira diferença significativa, não todos os sintomas posteriores. Esse limite costuma produzir uma solicitação de suporte mais clara e um experimento mais seguro.

Matriz de aceitação

Ponto	Evidência a manter	Condição de aprovação
Correção de fragmentação RTP H.264 FU-A: Por que seu vídeo RTSP está quebrado (perda de pacote, remontagem NAL)	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Corrigir vídeo RTSP quebrado da fragmentação H.264 FU-A RTP. Cobre fragmentos ausentes, bugs de bits de início/fim, falh	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
The fast answer	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Why fragmentation exists	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
The structure of an FU-A packet	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
The RTP marker bit	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado

Isolamento, recuperação e entrega

Pare no primeiro limite que falhar. Preserve fonte, projeto, sessão ou captura, duplique antes de edição destrutiva e altere uma variável por experimento. Repetir um fluxo amplo depois de várias mudanças pode gerar outro resultado sem explicar o motivo.

Separe ausência de evidência de evidência de ausência. Uma tela vazia pode indicar entrada, escopo, filtro, permissão, dispositivo, intervalo ou estado incorreto. Verifique aquisição ou importação antes de interpretar decoder, editor, relatório ou exportação.

Antes da entrega, reabra o artefato e examine início, ponto de decisão e final. Registre versão, plataforma, configuração, expectativa, observação e reprodução mínima. Remova ou oculte dados sensíveis e confirme a autorização do destinatário.

Perguntas e respostas

Qual é a maneira confiável mais rápida de começar?

Use o menor caso representativo, escreva o resultado esperado e altere uma variável. Confirme o caminho básico antes de adicionar filtros, efeitos, edições, automação ou uma fonte maior.

Quais evidências devem ser salvas?

Mantenha identidade da entrada, versão, plataforma, configurações, ação exata, primeira transição inesperada e saída final. Feche e reabra projeto, sessão, relatório ou exportação antes de tratá-lo como durável.

Quando o procedimento deve ser repetido?

Repita após mudanças relevantes no aplicativo, sistema, driver, firmware, modelo, fonte ou fluxo. Preserve o caso aceito anterior como referência sem alterações.

Quando a tarefa está pronta para entrega?

Quando outra pessoa autorizada identifica a entrada, repete a ação, vê o mesmo resultado, entende os limites restantes e abre o artefato sem depender de estado local não documentado.

Guias relacionados

Estas páginas no mesmo idioma cobrem etapas próximas sem alterar o proprietário canônico deste assunto: