2026-06-02

Como corrigir erros RTP / NDPI de 'gravação desconhecida' - tipo de carga útil dinâmica e mapeamento SDP em fluxos RTSP

Depure erros RTP/NDPI de 'gravação desconhecida' em capturas RTSP mapeando tipos de carga útil RTP dinâmica de volta para linhas SDP rtpmap e fmtp. Abrange metadados H.264, H.265, AAC, ONVIF, IDs de carga útil e erros de despacketizer.

Uma sessão RTSP pode parecer íntegra até que o analisador de mídia tente entender os pacotes RTP. DESCRIBE retorna SDP. SETUP foi bem-sucedido. PLAY foi bem-sucedido. Chegam pacotes RTP. Em seguida, o aplicativo ou classificador de pacotes relata gravação desconhecida, carga útil RTP desconhecida, NDPI desconhecido, tipo de carga útil não suportado, depacketizer não encontrado, mapeamento de codec inválido, nenhum decodificador para tipo de carga útil 96 ou stream contém trilha desconhecida.

Esses erros geralmente significam que os bytes estão presentes, mas o analisador não pode mapear um tipo de carga RTP para o codec e rastrear a definição do SDP. No RTSP, o tipo de carga 96 não é automaticamente H.264. É um ID dinâmico local da sessão. Você tem que ler o SDP.

Resposta rápida: verifique o SDP antes de culpar o NDPI ou a câmera

Se uma captura disser gravação desconhecida / RTP / NDPI, comece aqui:

Encontre a resposta RTSP DESCRIBE.
Copie o SDP.
Encontre cada linha de mídia m= e seus números de carga útil.
Para cada carga dinâmica (96-127), encontre a linha a=rtpmap:<id> correspondente.
Verifique a linha a=fmtp:<id> para parâmetros de codec.
Compare o byte do tipo de carga útil do pacote RTP com esse mapeamento SDP.

Se os pacotes RTP usarem o tipo de carga 96 e o SDP disser a=rtpmap:96 H265/90000, um analisador que espera H.264 reportará um absurdo. Se o SDP tiver a=rtpmap:96 vnd.onvif.metadata/90000, a carga desconhecida não é vídeo; são metadados ONVIF e não devem interromper a reprodução.

É por isso que um rótulo genérico de DPI como “NDPI desconhecido” não é suficiente. Os mecanismos DPI veem os bytes do pacote. Eles nem sempre têm o contexto do plano de controle RTSP necessário para interpretar IDs de carga dinâmica local da sessão. Para RTSP, o plano de controle e o plano de mídia devem ser lidos juntos.

Este é um problema de interpretação de protocolo. O RTSP Inspector é útil porque mantém as evidências SDP e RTP juntas. Você não pode interpretar corretamente os IDs de carga RTP dinâmicos sem o SDP que os define.

Tipos de carga estática versus dinâmica

Alguns tipos de carga RTP são estáticos. Outros são dinâmicos. Os tipos de carga dinâmica geralmente ficam no intervalo 96-127 e devem ser mapeados pelo SDP.

Exemplo:

m=video 0 RTP/AVP 96
a=rtpmap:96 H264/90000

Here, payload type 96 means H.264 for this session. In another stream, payload type 96 could mean H.265, AAC, metadata, or something vendor-specific. The number alone is not enough.

If a client assumes payload type 96 is always H.264, it will eventually fail.

SDP rtpmap is required for dynamic payloads

For dynamic payload types, SDP should include a=rtpmap:

a=rtpmap:96 H264/90000
a=rtpmap:97 MPEG4-GENERIC/48000/2
a=rtpmap:98 H265/90000

Se faltar rtpmap no SDP, o cliente pode não saber qual despacketizer usar. Algumas câmeras produzem SDP incompleto. Alguns relés ou proxies alteram o SDP. Alguns clientes analisam apenas trilhas comuns e ignoram trilhas de metadados.

Resultados comuns:

A carga útil do vídeo chega, mas não é decodificada.
A faixa de áudio é ignorada.
O rastreamento de metadados ONVIF aciona erros de carga útil desconhecidos.
H.265 é confundido com H.264.
A taxa de clock AAC ou a contagem de canais estão erradas.

Mudanças no tipo de carga útil entre sessões

Não codifique IDs de carga dinâmica. Uma câmera pode atribuir diferentes números de carga útil após reinicialização, alteração de perfil, atualização de firmware ou alteração de caminho de fluxo.

Por exemplo:

Session A: payload 96 = H264
Session B: payload 96 = H265
Session C: payload 97 = H264, payload 96 = metadata

The correct behavior is to parse SDP per session and bind RTP packet payload IDs to that session's mapping.

H.264 and H.265 confusion

H.264 and H.265 both often use 90 kHz RTP clocks, but their packetization and codec configuration are different. A client using the H.264 depacketizer for H.265 packets will not produce valid video.

Symptoms:

RTP packets arrive.
Payload type is dynamic.
SDP says H265 but client expects H264.
Decoder reports invalid NAL units.
Video is black or never starts.

Always check SDP before concluding that the camera "sends bad video."

AAC and MPEG4-GENERIC

Audio tracks can be just as tricky. AAC over RTP often uses MPEG4-GENERIC with parameters such as mode, config, sizeLength, indexLength, and profile-level-id.

If the client ignores fmtp, audio may fail even though packets arrive.

Relevant SDP:

a=rtpmap:97 MPEG4-GENERIC/48000/2
a=fmtp:97 streamtype=5; profile-level-id=1; mode=AAC-hbr; config=...

Tipo de carga útil, taxa de clock, canais e parâmetros de FTP são importantes.

Rastreamentos de metadados e extensões de fornecedores

Metadados ONVIF, sobreposições de análises, rastreamentos de eventos privados e cargas específicas de fornecedores podem aparecer no SDP. Um media player pode não saber o que fazer com eles.

Isso não é necessariamente uma falha de fluxo. Isso pode significar que o cliente deve ignorar faixas que não sejam de mídia não suportadas enquanto ainda processa vídeo e áudio. Mas se o cliente tratar metadados desconhecidos como fatais, a reprodução poderá falhar.

O RTSP Inspector deve ajudar a identificar o tipo de trilha, o mapeamento de carga útil e se as cargas desconhecidas são vídeo, áudio, metadados ou dados privados.

Lista de verificação de depuração

Use este processo:

Capture o SDP retornado por DESCRIBE.
Liste todas as seções de mídia m=.
Liste todos os tipos de carga dinâmica.
Mapeie IDs de carga útil com a=rtpmap.
Inspecione a=fmtp para configuração do codec.
Compare os valores do tipo de carga útil do pacote RTP com o SDP.
Verifique se os IDs de carga mudam entre as sessões.
Separe vídeo, áudio, metadados e faixas privadas.
Confirme se o cliente possui um desempacotador para cada codec necessário.
Ignore faixas opcionais não suportadas somente se o aplicativo puder fazer isso com segurança.

Diagnóstico final

A incompatibilidade de tipo de carga dinâmica RTP ocorre quando o cliente não consegue mapear pacotes RTP recebidos para o codec ou trilha correto. A solução é tratar o SDP como a autoridade para a sessão: analisar rtpmap, analisar fmtp, vincular IDs de carga útil por sessão e distinguir as trilhas de mídia necessárias dos metadados opcionais.

O RTSP Inspector oferece suporte a esse fluxo de trabalho baseado em evidências, mostrando SDP e RTP lado a lado, para que problemas de carga útil possam ser diagnosticados antes de culpar a câmera, o decodificador ou a rede.

Evidência reproduzível para “Como corrigir erros RTP / NDPI de 'gravação desconhecida' - tipo de carga útil dinâmica e mapeamento SDP em fluxos RTSP”

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 “Como corrigir erros RTP / NDPI de 'gravação desconhecida' - tipo de carga útil dinâmica e mapeamento SDP em fluxos RTSP”, 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 “Como corrigir erros RTP / NDPI de 'gravação desconhecida' - tipo de carga útil dinâmica e mapeamento SDP em fluxos RTSP” é: Depure erros RTP/NDPI de 'gravação desconhecida' em capturas RTSP mapeando tipos de carga útil RTP dinâmica de volta para linhas SDP rtpmap e fmtp. Abrange metadados H.264, H.265, AAC, ONVIF, IDs de carga útil e erros de despacketizer. 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: Como corrigir erros RTP / NDPI de 'gravação desconhecida' - tipo de carga útil dinâmica e

Encerre “Como corrigir erros RTP / NDPI de 'gravação desconhecida' - tipo de carga útil dinâmica e mapeamento SDP em fluxos RTSP” somente quando o resultado salvo, exportado ou reaberto continuar igual ao estado observado. O retorno temporário da interface ajuda, mas evidência durável é mais forte. Registre qualquer limite restante para a próxima pessoa.

Ponto de controle 2: Depure erros RTP/NDPI de 'gravação desconhecida' em capturas RTSP mapeando tipos de carga

Para “Depure erros RTP/NDPI de 'gravação desconhecida' em capturas RTSP mapeando tipos de carga útil RTP dinâmica de volta para linhas SDP rtpmap e fmtp. Ab”, separe uma decisão do produto de um limite do sistema, hardware, arquivo, permissão ou processo. Confirme qual camada produziu a evidência antes de atribuir causa. Isso evita transformar um sintoma próximo em causa raiz supostamente provada.

Ponto de controle 3: Resposta rápida: verifique o SDP antes de culpar o NDPI ou a câmera

Encerre “Resposta rápida: verifique o SDP antes de culpar o NDPI ou a câmera” somente quando o resultado salvo, exportado ou reaberto continuar igual ao estado observado. O retorno temporário da interface ajuda, mas evidência durável é mais forte. Registre qualquer limite restante para a próxima pessoa.

Ponto de controle 4: Tipos de carga estática versus dinâmica

Para “Tipos de carga estática versus dinâmica”, separe uma decisão do produto de um limite do sistema, hardware, arquivo, permissão ou processo. Confirme qual camada produziu a evidência antes de atribuir causa. Isso evita transformar um sintoma próximo em causa raiz supostamente provada.

Ponto de controle 5: SDP rtpmap is required for dynamic payloads

Encerre “SDP rtpmap is required for dynamic payloads” somente quando o resultado salvo, exportado ou reaberto continuar igual ao estado observado. O retorno temporário da interface ajuda, mas evidência durável é mais forte. Registre qualquer limite restante para a próxima pessoa.

Ponto de controle 6: Mudanças no tipo de carga útil entre sessões

Para “Mudanças no tipo de carga útil entre sessões”, separe uma decisão do produto de um limite do sistema, hardware, arquivo, permissão ou processo. Confirme qual camada produziu a evidência antes de atribuir causa. Isso evita transformar um sintoma próximo em causa raiz supostamente provada.

Ponto de controle 7: H.264 and H.265 confusion

Encerre “H.264 and H.265 confusion” somente quando o resultado salvo, exportado ou reaberto continuar igual ao estado observado. O retorno temporário da interface ajuda, mas evidência durável é mais forte. Registre qualquer limite restante para a próxima pessoa.

Ponto de controle 8: AAC and MPEG4-GENERIC

Para “AAC and MPEG4-GENERIC”, separe uma decisão do produto de um limite do sistema, hardware, arquivo, permissão ou processo. Confirme qual camada produziu a evidência antes de atribuir causa. Isso evita transformar um sintoma próximo em causa raiz supostamente provada.

Ponto de controle 9: Rastreamentos de metadados e extensões de fornecedores

Encerre “Rastreamentos de metadados e extensões de fornecedores” somente quando o resultado salvo, exportado ou reaberto continuar igual ao estado observado. O retorno temporário da interface ajuda, mas evidência durável é mais forte. Registre qualquer limite restante para a próxima pessoa.

Ponto de controle 10: Lista de verificação de depuração

Para “Lista de verificação de depuração”, separe uma decisão do produto de um limite do sistema, hardware, arquivo, permissão ou processo. Confirme qual camada produziu a evidência antes de atribuir causa. Isso evita transformar um sintoma próximo em causa raiz supostamente provada.

Matriz de aceitação

Ponto	Evidência a manter	Condição de aprovação
Como corrigir erros RTP / NDPI de 'gravação desconhecida' - tipo de carga útil dinâmica e mapeamento SDP em fluxos RTSP	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Depure erros RTP/NDPI de 'gravação desconhecida' em capturas RTSP mapeando tipos de carga útil RTP dinâmica de volta par	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Resposta rápida: verifique o SDP antes de culpar o NDPI ou a câmera	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Tipos de carga estática versus dinâmica	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
SDP rtpmap is required for dynamic payloads	Estado inicial, uma ação e estado resultante	Outra pessoa reproduz o resultado declarado
Mudanças no tipo de carga útil entre sessões	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: