Risoluzione dei problemi del flusso RTSP: la guida diagnostica completa per i flussi della telecamera
Flusso di lavoro diagnostico RTSP completo: livello di connessione, errori del piano di controllo (400/401/404/454/461/500/503), errori del piano multimediale (H.264/H.265/RTP/RTCP), gestione delle sessioni e confronto con Wireshark/VLC. Ogni problema RTSP mappato su una pagina di diagnostica.
Questa è la pagina dell'hub per la diagnostica del flusso della telecamera RTSP. Ogni problema RTSP segue uno schema: "fallisce a livello di connessione, piano di controllo o piano multimediale. Questa guida mappa ogni errore comune in una pagina diagnostica specifica e indica quali prove raccogliere."
Triage rapido: "dov'è il fallimento?"
Prima di leggere qualsiasi pagina specifica, determina quale livello non funziona: ""
- Il client riesce a raggiungere la telecamera? → Problemi al livello di connessione
- DESCRIBE restituisce un SDP valido? → Problemi del piano di controllo
- I pacchetti RTP arrivano e vengono decodificati correttamente? → Problemi sul piano multimediale
Se non sai quale livello non funziona, inizia con il flusso di lavoro diagnostico sistematico.
Connection layer: reaching the camera
These problems happen before any RTSP command is sent. TCP handshake fails, TLS negotiation fails, or the network path is blocked.
RTSP connects but no video — The most common symptom. Camera appears online but no media stream.
RTSP over TLS (RTSPS) debugging — TLS certificate errors, handshake failures, cipher suite negotiation.
Piano di controllo: errori di comando RTSP
Si tratta di errori a livello di protocollo restituiti dalla fotocamera in risposta a DESCRIBE, SETUP o PLAY. Il codice di errore ti dice esattamente cosa è andato storto.
400 Richiesta errata
- RTSP 400 Bad Request: DESCRIBE fail: URL non valido, intestazioni non supportate, interferenza del proxy. Copre i formati URL Axis, Dahua e Hikvision.
401 Non autorizzato
Loop di autenticazione RTSP 401 — Digest vs autenticazione di base, parametri nonce/realm, perché l'autenticazione riesce in VLC ma fallisce nella tua app.
Approfondimento sull'autenticazione digest RTSP — Scadenza nonce, corrispondenza realm, gestione stale=true.
Diagnostica URL telecamera 401/404: quando l'URL funziona in un client ma non in un altro.
404 Non trovato
Diagnostica URL telecamera 401/404: percorso di streaming errato, formati URL specifici della telecamera.
URL di controllo aggregato e SDP SETUP 404 — Quando l'URL di controllo in SDP non corrisponde all'URL DESCRIBE.
454 Sessione non trovata
- Sessione RTSP 454 non trovata: mancata corrispondenza dell'ID sessione, sessioni scadute, RIPRODUZIONE prima della CONFIGURAZIONE.
461 Trasporto non supportato
- Trasporto non supportato RTSP 461: SETUP non riuscito — Negoziazione del trasporto UDP vs TCP, ffmpeg "metodo SETUP non riuscito: 461", errori di integrazione Frigate/Scrypted/NVR.
Errori del server 500/503
Errore server interno RTSP 500: errore lato telecamera. Quando concludere che il firmware della fotocamera è difettoso.
Servizio RTSP 503 non disponibile: esaurimento delle risorse della fotocamera, troppi flussi simultanei, limiti di larghezza di banda.
Trasporti e reti
RTP UDP bloccato da firewall/NAT: il controllo RTSP funziona ma il supporto UDP RTP è bloccato. Regole firewall, attraversamento NAT, configurazione porta protocollo RTSP, fallback TCP interleaved.
Mancata corrispondenza del canale interleaved TCP — Quando i canali RTP/RTCP interleaved non corrispondono tra client e server.
Risposta del server di trasporto non corrispondente: il server risponde con parametri di trasporto diversi da quelli richiesti.
Debug UDP multicast — Configurazione multicast RTSP/RTP, IGMP, TTL e infrastruttura di rete.
Timeout RTSP: UDP vs TCP interleaved — Perché il timeout dello streaming avviene in modo diverso su UDP rispetto a TCP.
Media plane: RTP, codec, and payload problems
Control plane works perfectly — DESCRIBE returns SDP, SETUP succeeds, PLAY returns 200 OK — but video is broken. These are media plane problems.
RTP packet analysis
RTP dynamic payload type mismatch — "Unknown write" RTP/NDPI errors. How to map dynamic payload IDs to SDP rtpmap lines.
RTP packet loss diagnosis — RTP error in primary stream. Freezes, macroblocks, decoder errors. Read sequence numbers and RTCP reports to find the loss.
RTP timestamp drift — Audio/video sync loss, frame timing errors, clock rate mismatch.
RTP marker bit and frame boundaries — How the RTP marker bit signals H.264 access unit boundaries.
RTP sequence number wraparound — 16-bit sequence number rollover and how to detect actual loss vs wraparound.
RTP SSRC change mid-stream — When the camera changes SSRC mid-stream and the client loses sync.
H.264 and H.265 codec issues
H.264 FU-A fragmentation and reassembly — Missing fragments, start/end bit bugs, NAL unit reassembly failures, "invalid NAL unit" errors.
H.264 packetization mode 0 vs 1 — Single NAL vs non-interleaved mode. SDP parameter configuration.
H.264 SPS/PPS missing — Decoder errors when parameter sets are missing from SDP or RTP stream.
H.265 stream not working — H.265/HEVC failures and H.264 fallback behavior.
SDP H.264/H.265 diagnostics — Reading SDP for H.264/H.265: profile-level-id, sprop-parameter-sets, packetization-mode.
Audio and metadata tracks
- Audio track AAC unknown track SDP — AAC audio tracks appearing as "unknown" in clients.
ONVIF and camera-specific
ONVIF works but RTSP URL fails — ONVIF discovery succeeds but direct RTSP connection fails.
Main stream vs sub stream — When the main stream works but the sub stream doesn't, or vice versa.
RTCP e gestione delle sessioni
Rapporti mittente RTCP: jitter e perdita: lettura dei pacchetti RTCP SR per comprendere la qualità della rete dal punto di vista della telecamera.
RTCP BYE: lo streaming termina in modo imprevisto — Quando la telecamera invia RTCP BYE e termina lo streaming.
RTCP CNAME e sincronizzazione audio/video — Utilizzo di RTCP CNAME per sincronizzare tracce audio e video.
RTSP TEARDOWN e pulizia della sessione: perdite di risorse della fotocamera, errori di riconnessione, stato di flusso occupato.
Timeout sessione RTSP e keepalive — Perché gli streaming si interrompono dopo circa 30 secondi e come mantenerli attivi.
Intestazione range RTSP e NPT — Controllo della posizione di riproduzione con i parametri Range e NPT.
Intestazione scala RTSP e riproduzione di trucchi: avanzamento veloce, riavvolgimento e controllo della velocità tramite intestazione scala.
Comparison and alternatives
RTSP Inspector vs Wireshark/VLC/ONVIF Device Manager — When to use a dedicated RTSP diagnostic tool vs a general network analyzer.
Wireshark RTSP alternative — Why RTSP diagnostics need more than packet capture.
Iniziare
Nuovo nella diagnostica RTSP? Inizia qui:
- Flusso di lavoro diagnostico sistematico — Il modello a tre livelli e la raccolta delle prove.
- Connetti a uno streaming — Configurazione della tua prima connessione RTSP.
- Guida alla risoluzione dei problemi — Errori comuni e relative soluzioni.
Prova riproducibile per «Risoluzione dei problemi del flusso RTSP: la guida diagnostica completa per i flussi della telecamera»
La risposta diretta è che una schermata nera o un solo codice non dimostra l’origine del guasto. Una diagnosi affidabile collega richiesta e risposta RTSP, trasporto negoziato, sessione valida e poi numeri di sequenza RTP, timestamp e segnali RTCP. Per «Risoluzione dei problemi del flusso RTSP: la guida diagnostica completa per i flussi della telecamera» parti dal livello più vicino al sintomo visibile, ma conserva una cronologia comune per non confondere controllo, rete e decodifica.
Prima di cambiare camera, firewall o VMS, crea un test di base piccolo. Registra URL RTSP senza password, ora, percorso, trasporto richiesto, risposta del server e momento del primo pacchetto multimediale. Prova separatamente UDP e TCP interleaved quando disponibili. Non cambiare insieme percorso, credenziali e trasporto: se il secondo tentativo funziona, devi poter identificare la variabile decisiva.
| Livello | Evidenza da conservare | Domanda |
|---|---|---|
| RTSP | metodo, stato, header, CSeq e Session | Il server ha accettato proprio questa operazione? |
| SDP | control, payload type, clock rate e codec | È descritta la traccia attesa? |
| Transport | client_port, server_port o interleaved | I due estremi usano lo stesso canale? |
| RTP | SSRC, sequenza, timestamp e marker | Le unità arrivano in ordine spiegabile? |
| RTCP | sender report, CNAME e BYE | Orologio, identità e fine sono tracciabili? |
| Decoder | SPS/PPS/VPS e packetization mode | Il payload ricevuto può inizializzare il decoder? |
Separa «nessun media ricevuto» da «media ricevuto ma non decodificabile». Se RTP manca dopo SETUP e PLAY riusciti, verifica UDP, NAT, firewall e risposta Transport. Buchi nella sequenza provano perdita o riordinamento. Una sequenza continua senza immagine sposta l’indagine su payload type, clock rate, confini del frame e parametri H.264 o H.265. Questo confine è più utile del messaggio generico del player.
Come si scrive una risposta citabile?
Usa tre frasi: ultima operazione riuscita, prima evidenza fallita, prossimo test che separa due cause. Esempio: «DESCRIBE, SETUP e PLAY riescono; nessun RTP arriva alle porte annunciate; una prova TCP interleaved separerà blocco UDP e percorso media errato». Non attribuire il guasto a camera o rete senza una risposta o un pacchetto che dimostri il confine.
Quali dati rendono il caso riproducibile?
Conserva OPTIONS, DESCRIBE, SETUP e PLAY, SDP, risposta Transport e Session ripulita. Per RTP annota SSRC, prima e ultima sequenza, clock rate, buchi e durata. Indica se VLC o un altro VMS funziona, ma usalo come confronto controllato, non come prova che il client riuscito interpreti correttamente ogni regola.
Quando controllare server o client?
Controlla il server se rifiuta un metodo, fornisce un control URL assente, restituisce un trasporto incompatibile o cambia SSRC o clock senza transizione. Controlla il client se riusa un nonce scaduto, perde Session, richiede UDP senza aprire le porte o tratta ogni fine NAL come fine access unit. Se il difetto è intermedio, pacchetto e tempo devono accompagnare ogni conclusione.
Come verificare il rapporto?
Ripeti da una connessione nuova e confronta le cronologie fino alla prima differenza. Rimuovi password e valori Authorization completi. Collega ogni conclusione a CSeq, sequenza o timestamp. Segui la guida RTSP correlata e usa RTSP Inspector per testare uno stream RTSP e raccogliere prove localmente, senza caricare il video su un servizio pubblico.
<!-- rtsp-localized-evidence-foundation-v1:end --><!-- rtsp-localized-layer-verdicts-v1:start -->Dall’osservazione al verdetto per livello
In «Risoluzione dei problemi del flusso RTSP: la guida diagnostica completa per i flussi della telecamera» scrivi prima l’osservazione e poi l’interpretazione. Un’altra persona deve poter ritrovare l’osservazione nella cattura: stato RTSP legato a CSeq, valore SDP, risposta Transport, buco di sequenza, cambio SSRC o differenza tra RTP timestamp e RTCP sender report. “Il server è lento” o “il codec è incompatibile” resta un’ipotesi finché una prova precisa non la rende migliore delle alternative.
Dividi il percorso in confini. Prima si apre TCP, poi vengono accettati OPTIONS o DESCRIBE. SDP deve descrivere una traccia utilizzabile con control URL, payload type e clock rate. SETUP richiede una risposta Transport compatibile e PLAY una Session valida. Solo dopo vengono arrivo RTP, ordine, tempo e preparazione del decoder. Fermati al primo confine senza prova di successo.
Mantieni fonte e intervallo costanti nei confronti. UDP contro TCP interleaved usa lo stesso percorso e le stesse credenziali. Main stream contro sub stream conserva client e trasporto. Confrontando VLC e VMS, registra metodi, header e URL reali; differenze in control URL, Authorization, Session o keepalive possono spiegare il risultato più del nome del programma.
Matrice di esclusione
Parti da due ipotesi. Se non arriva media, UDP può essere bloccato oppure il server può inviare ad altre porte. TCP interleaved verifica la prima; confrontare offerta e risposta Transport, IP e porte verifica la seconda. Per immagine corrotta, la sequenza RTP separa perdita da inizializzazione incompleta, mentre SPS/PPS/VPS prima del primo frame verifica i parametri codec.
Per ogni ipotesi annota una prova favorevole e una che potrebbe smentirla. Un’affermazione che nessun pacchetto può negare è troppo ampia. “NAT elimina UDP” è smentita da RTP sulla porta client. “Mancano parametri H.264” è smentita da SPS e PPS validi prima di IDR. Il rapporto resta così prioritario.
Leggere il tempo senza conclusioni eccessive
RTSP CSeq ordina transazioni, RTP sequence ordina pacchetti, RTP timestamp esprime il tempo di campionamento e l’orologio di cattura l’arrivo al punto osservato. Non sono lo stesso orologio. Variazione di arrivo non prova drift; salto timestamp non prova perdita senza sequenza. RTCP sender report collega orologi RTP audio e video a un riferimento comune.
Pacchetto di accettazione
Chiudi il caso quando la correzione si ripete su una connessione nuova con una sola modifica documentata. Il rapporto indica input, ultimo confine riuscito, prima prova fallita, modifica, risultato e test aperti. Allega un breve transcript o statistiche mirate. Nascondi i segreti, ma conserva CSeq, Session ripulita, SSRC e intervallo.
Usa la risoluzione problemi RTSP per ricostruire il flusso e i report di RTSP Inspector per consegnare il confine al team camera, rete o VMS.
<!-- rtsp-localized-layer-verdicts-v1:end -->