H.265 RTSP Stream não funciona: quando mudar a câmera de volta para H.264

"Fluxo H.265 RTSP não funciona" é uma das pesquisas de solução de problemas de câmera com maior intenção, porque o fluxo geralmente funciona em um lugar e falha em outro. VLC pode reproduzi-lo. Um aplicativo móvel pode mostrar isso. Um navegador, NVR, pipeline de análise, integração do Home Assistant, ponte WebRTC ou restreamer podem falhar com "tipo de fluxo não suportado", "codec não correspondente", "não foi possível escrever o cabeçalho", "sem vídeo" ou um botão giratório de carregamento permanente.

A falha nem sempre é a sessão RTSP. H.265, também chamado de HEVC, é um limite de suporte de codec. O RTSP pode entregá-lo corretamente enquanto o sistema receptor ainda não consegue decodificá-lo, empacotá-lo, exibi-lo ou transmiti-lo novamente.

O sucesso do RTSP não significa suporte a codec

Um cliente RTSP pode concluir com êxito:

• OPÇÕES
• DESCREVA
• CONFIGURAÇÃO
• JOGAR
• Entrega RTP

e ainda não consegue mostrar o vídeo. Se o SDP anunciar a chegada de pacotes H.265 e RTP, o transporte poderá funcionar bem. O produto downstream pode simplesmente não suportar H.265 nesse caminho.

Isso é importante porque os usuários costumam descrever o problema como “RTSP não funciona”. O melhor diagnóstico é "O transporte RTSP funciona, mas o codec anunciado não é compatível ou não está pronto para decodificação para este consumidor".

Por que o H.265 falha com mais frequência do que o H.264

O H.265 é eficiente, especialmente para câmeras de alta resolução, mas o suporte é irregular. Muitos caminhos de navegador não suportam bem o H.265 bruto. Alguns NVRs podem gravar H.265, mas não visualizá-lo de forma consistente. Alguns pipelines de análise exigem H.264 porque a aceleração de hardware, a extração de quadros ou a saída do contêiner exigem isso. Alguns restreamers precisam de transcodificação ou configuração especial.

Modos de falha comuns:

• a visualização do navegador não carrega
• o substream de baixa resolução funciona, mas o stream principal falha
• o fluxo principal é H.265 enquanto o fluxo secundário é H.264
• Registros NVR, mas a visualização ao vivo falha
• Saída RTMP/FLV rejeita HEVC
• A ponte WebRTC não pode corresponder aos codecs
• o serviço de análise aceita apenas H.264

Esses são limites de compatibilidade do produto e não são prova de que a câmera está off-line.

Inspecione o SDP antes de alterar as configurações

Antes de alterar as configurações da câmera, inspecione o SDP:

• a=rtpmap anuncia H265, H264 ou outro codec?
• o stream principal é diferente do stream secundário?
• os parâmetros H.265 VPS/SPS/PPS são visíveis?
• o tipo de carga útil permanece consistente no RTP?
• o RTP chega depois de PLAY?
• a falha ocorre antes ou depois da entrega da mídia?

Se o SDP disser H.265 e a plataforma de destino esperar H.264, a próxima ação não será a depuração do firewall. É seleção de perfil de fluxo, alteração de codec ou transcodificação.

Fluxo principal versus fluxo secundário costuma ser a pista

Muitas câmeras expõem:

• fluxo principal: alta resolução, H.265
• substream: baixa resolução, H.264

Isso explica por que o fluxo secundário funciona enquanto o fluxo principal falha. O substream prova a acessibilidade e as credenciais do RTSP. Isso não prova que o consumidor suporta o codec de fluxo principal.

Um bom relatório compara:

• fluxo principal SDP
• subfluxo SDP
• nomes de codecs
• resolution
• bitrate
• Continuidade RTP
• prontidão do decodificador

Se apenas o H.265 falhar, as evidências apontam para suporte a codec ou empacotamento H.265 em vez de sintaxe de URL RTSP.

Quando o H.264 Fallback é a solução prática

Mudar o perfil da câmera para H.264 costuma ser a solução mais rápida quando:

• o produto alvo não suporta H.265
• a visualização ao vivo é baseada no navegador
• é necessário retransmitir para RTMP/FLV
• pipeline de análise requer quadros H.264
• o caminho de decodificação de hardware é desconhecido
• o caso de suporte precisa de ampla compatibilidade

O H.265 ainda pode ser útil para eficiência de gravação ou armazenamento. A arquitetura prática pode usar H.264 para ingestão/detecção ao vivo e H.265 para gravação de câmera local, quando houver suporte.

Onde o inspetor RTSP se encaixa

O RTSP Inspector não está tentando transcodificar ou reproduzir todos os fluxos. Seu trabalho é provar o contrato de stream:

• Controle RTSP bem-sucedido
• SDP anunciou H.265 ou H.264
• A RTP chegou ou não chegou
• evidência de parâmetro de codec estava presente ou ausente
• falha downstream é provável suporte de codec, perda de pacotes ou incompatibilidade de metadados

Para pesquisas como "stream H.265 RTSP não funciona", "câmera de tipo de stream não suportada" ou "H.265 funciona em VLC, mas não em NVR", essa evidência evita desperdício de depuração. A correção pode ser o substituto do H.264, não outro player.