Il flusso RTSP H.265 non funziona: quando riportare la videocamera a H.264

Perché gli streaming delle telecamere H.265 RTSP spesso falliscono nei browser, negli NVR, nei sistemi di analisi e nei restreamer e come dimostrare se il fallback H.264 è la soluzione giusta.

H265, H264, RTSP, HEVC, tipo di flusso non supportato

"Stream H.265 RTSP non funzionante" è una delle ricerche di risoluzione dei problemi della fotocamera con l'intento più elevato perché lo streaming spesso funziona in un posto e fallisce in un altro. VLC potrebbe riprodurlo. Un'app mobile potrebbe mostrarlo. Un browser, NVR, pipeline di analisi, integrazione Home Assistant, bridge WebRTC o restreamer potrebbero non funzionare con "tipo di flusso non supportato", "codec non corrispondente", "impossibile scrivere intestazione", "nessun video" o uno spinner di caricamento permanente.

L'errore non è sempre la sessione RTSP. H.265, chiamato anche HEVC, è un limite di supporto codec. RTSP può consegnarlo correttamente mentre il sistema ricevente non è ancora in grado di decodificarlo, impacchettarlo, visualizzarlo o riprodurlo in streaming.

Il successo di RTSP non significa supporto codec

Un client RTSP può completare con successo:

  • "OPZIONI".
  • "DESCRIVERE".
  • "IMPOSTAZIONE".
  • "GIOCA".
  • Consegna RTP

e ancora non riesco a mostrare il video. Se SDP pubblicizza l'arrivo di pacchetti H.265 e RTP, il trasporto potrebbe funzionare correttamente. Il prodotto downstream potrebbe semplicemente non supportare H.265 in quel percorso.

Ciò è importante perché gli utenti spesso descrivono il problema come "RTSP non funzionante". La diagnosi migliore è "Il trasporto RTSP funziona, ma il codec pubblicizzato non è supportato o non è pronto per la decodifica per questo consumatore".

Perché H.265 fallisce più spesso di H.264

H.265 è efficiente, soprattutto per le fotocamere ad alta risoluzione, ma il supporto non è uniforme. Molti percorsi browser non gestiscono bene H.265 grezzo. Alcuni NVR possono registrare H.265 ma non visualizzarne l'anteprima in modo coerente. Alcune pipeline di analisi richiedono H.264 perché lo richiedono l'accelerazione hardware, l'estrazione dei frame o l'output del contenitore. Alcuni restreamer necessitano di transcodifica o configurazione speciale.

Modalità di guasto comuni:

  • l'anteprima del browser non viene caricata
  • il flusso secondario a bassa risoluzione funziona ma il flusso principale fallisce
  • il flusso principale è H.265 mentre il flusso secondario è H.264
  • L'NVR registra ma la visualizzazione live non funziona
  • L'output RTMP/FLV rifiuta HEVC
  • Il bridge WebRTC non può corrispondere ai codec
  • il servizio di analisi accetta solo H.264

Questi sono limiti di compatibilità del prodotto, non una prova che la fotocamera sia offline.

Ispezionare l'SDP prima di modificare le impostazioni

Prima di modificare le impostazioni della fotocamera, ispezionare l'SDP:

  • a=rtpmap pubblicizza H265, H264 o un altro codec?
  • il flusso principale differisce dal flusso secondario?
  • sono visibili i parametri H.265 VPS/SPS/PPS?
  • il tipo di carico utile rimane coerente in RTP?
  • l'RTP arriva dopo "PLAY"?
  • l'errore si verifica prima o dopo la consegna dei media?

Se SDP indica H.265 e la piattaforma di destinazione prevede H.264, l'azione successiva non è il debug del firewall. Si tratta della selezione del profilo di flusso, della modifica del codec o della transcodifica.

Il flusso principale e quello secondario sono spesso l'indizio

Molte fotocamere espongono:

  • flusso principale: alta risoluzione, H.265
  • flusso secondario: bassa risoluzione, H.264

Questo spiega perché il flusso secondario funziona mentre il flusso principale fallisce. Il flusso secondario dimostra la raggiungibilità e le credenziali RTSP. Ciò non dimostra che il consumatore supporti il ​​codec del flusso principale.

Un buon rapporto confronta:

  • flusso principale SDP
  • sottoflusso SDP
  • nomi dei codec
  • resolution
  • bitrate
  • Continuità RTP
  • disponibilità del decodificatore

Se solo H.265 fallisce, le prove indicano il supporto del codec o la pacchettizzazione H.265 piuttosto che la sintassi dell'URL RTSP.

Quando il fallback H.264 è la soluzione pratica

Il passaggio dal profilo della fotocamera a H.264 è spesso la soluzione più rapida quando:

  • il prodotto di destinazione non supporta H.265
  • l'anteprima dal vivo è basata su browser
  • è richiesto il ristreaming in RTMP/FLV
  • la pipeline di analisi richiede frame H.264
  • il percorso di decodifica hardware è sconosciuto
  • il caso di supporto necessita di un'ampia compatibilità

H.265 può ancora essere utile per l'efficienza della registrazione o dell'archiviazione. L'architettura pratica può utilizzare H.264 per l'acquisizione/rilevamento in tempo reale e H.265 per la registrazione tramite telecamera locale, ove supportato.

Dove si adatta l'ispettore RTSP

RTSP Inspector non tenta di transcodificare o riprodurre ogni flusso. Il suo compito è dimostrare il contratto di flusso:

  • Il controllo RTSP è riuscito
  • SDP pubblicizzava H.265 o H.264
  • RTP è arrivato o non è arrivato
  • l'evidenza del parametro codec era presente o mancante
  • un errore a valle è probabilmente dovuto al supporto del codec, alla perdita di pacchetti o alla mancata corrispondenza dei metadati

Per ricerche come "Stream H.265 RTSP non funzionante", "telecamera con tipo di streaming non supportato" o "H.265 funziona in VLC ma non in NVR", questa prova impedisce un debug sprecato. La soluzione potrebbe essere il fallback H.264, non un altro giocatore.