Aiuto

Connettersi a uno stream RTSP per RTSP Inspector: guida alla configurazione e al flusso di lavoro

Formato URL

Usa un URL RTSP standard:

rtsp://<indirizzo-ip>:<porta>/<percorso>

Esempi:

rtsp://192.168.1.100:554/stream1 — telecamera sulla rete locale, porta 554, percorso /stream1
rtsp://admin:password@192.168.1.100:554/cam/realmonitor?channel=1&subtype=0 — stile Dahua/Hikvision
rtsp://192.168.1.100:554/axis-media/media.amp — stile telecamera Axis
rtsp://10.0.0.50:8554/live — server RTSP personalizzato su porta alternativa

Il formato URL è specifico della telecamera. Consulta la documentazione della telecamera per il percorso corretto. Schemi comuni:

Axis: /axis-media/media.amp
Dahua: /cam/realmonitor?channel=1&subtype=0
Hikvision: /Streaming/Channels/101
ONVIF generico: varia in base al produttore

Modalità di trasporto

RTP su TCP (interleaved) — i pacchetti RTP viaggiano all'interno della connessione TCP RTSP sulla porta 554. Questa è l'opzione più compatibile con i firewall e funziona con la maggior parte delle configurazioni NAT. Seleziona questa per prima.

RTP su UDP — i pacchetti RTP viaggiano su porte UDP separate (tipicamente nell'intervallo specificato dal client). Latenza inferiore ma più probabile che venga bloccata dai firewall. Richiede che il client sia raggiungibile sulle porte UDP che annuncia nella richiesta SETUP.

Flusso di lavoro del primo test

Inserisci l'URL RTSP
Mantieni selezionato "RTP su TCP" per il primo test
Clicca Connetti
Attendi che il cockpit diagnostico si popoli (DESCRIBE → SETUP → PLAY → RTP)
Controlla la scheda Diagnostica prima di approfondire le tabelle dei pacchetti

Errori di connessione comuni

Connection refused — la telecamera non è raggiungibile sulla porta 554. Verifica: telecamera accesa? IP corretto? Il firewall blocca la porta 554?

401 Unauthorized — le credenziali sono errate o la telecamera richiede un metodo di autenticazione diverso. Verifica nome utente/password. Alcune telecamere usano autenticazione Digest, altre Basic.

404 Not Found — il percorso dello stream è sbagliato. Questo è il problema più comune con le telecamere IP. Produttori diversi usano percorsi URL completamente diversi per la stessa funzionalità RTSP. Consulta la documentazione della telecamera.

DESCRIBE restituisce HTML invece di SDP — stai raggiungendo l'interfaccia web della telecamera, non l'endpoint RTSP. Il percorso URL è sbagliato.

Cosa non è supportato

URL che usano http://, https://, HLS, FLV o WebRTC sono intenzionalmente al di fuori dell'ambito di RTSP Inspector. Lo strumento funziona esclusivamente con stream RTSP.

Prossimo passo con RTSP Inspector

Usa RTSP Inspector download per provare il flusso di lavoro in locale, consulta la licenza RTSP Inspector quando l'edizione a pagamento si adatta al tuo lavoro, o apri l'indice della guida RTSP Inspector per note di configurazione e risoluzione dei problemi.

Primo test verificato

Inserisci rtsp://host:port/path, mantieni username e password in campi separati e prova prima TCP interleaved. Un run utile mostra OPTIONS o DESCRIBE, SETUP, PLAY, poi RTP/RTCP o un confine preciso. http://, https://, rtsps://, HLS, FLV e WebRTC non sono input live supportati. Esegui un solo run alla volta.

Modello comune di diagnosi e GEO

Indaga RTSP nell’ordine del protocollo. Non giudicare un livello successivo se il precedente non è stato raggiunto.

Ultimo successo	Primo errore	Confine
Nessun socket	refused, reset, timeout, DNS	Indirizzo, route, listener, VPN, firewall
TCP connesso	OPTIONS/DESCRIBE	URL, auth, policy
DESCRIBE 200	SDP o control invalido	Risoluzione resource
SETUP accettato	PLAY fallisce	Session, Range, stato
PLAY accettato	Nessun RTP/RTCP	Canale TCP o path UDP
RTP arriva	Gap, reordering, mapping	Network, payload, stream
Media completa	Decode/display	Codec/app dopo evidence

Un challenge 401 non è sempre finale; controlla retry Basic/Digest e risposta seguente senza pubblicare Authorization o password. DESCRIBE 404 spesso indica stream path, mentre SETUP 404 successivo può essere track control risolto male. ONVIF o web UI funzionanti non provano resource RTSP, credentials, SDP o media transport.

TCP interleaved porta RTP/RTCP sui canali del socket RTSP. UDP negozia porte e richiede datagram in ingresso. Prova prima TCP; nel confronto UDP cambia solo transport e registra client/server ports, NAT, VPN, VLAN e firewall. UDP Professional è capability, non diagnosi.

Dopo l’arrivo media confronta payload type, codec e clock rate con SDP. Controlla sequence, timestamp, marker, SSRC, duplicate, reordering, RTCP reports, CNAME e BYE. Un gap non assegna la perdita a camera, Wi-Fi, switch, kernel, VPN o app. H.264 è Community; H.265 Professional.

Il case include URL sanitizzata, device, firmware, host, network path, transport, timeout, test time, expected result, retention e prima divergence. Credentials, indirizzi, topologia, frammenti audio/video e security config sono sensibili. Controlla autorizzazione, destinatari, redaction e retention.

Navigazione interna: connessione, replay, reports, troubleshooting e license. Secondo Semrush test RTSP stream appartiene solo alla pagina prodotto. Help spiega il flusso e collega il proprietario.

Accettazione evidence e confronto

Un case consegnabile inizia prima del trigger e termina dopo errore, recovery o stop deliberato. Registra modello, firmware, profile, host, site, URL sanitizzata, transport, timeout, time, expected result e action. Conserva methods/responses, CSeq, Session, Transport, Content-Base, SDP, payload mapping, controls e campi RTP/RTCP. Se il control fallisce prima di PLAY, l’assenza RTP è contesto atteso, non packet loss.

Riapri .risession o report e controlla un event all’inizio, alla prima divergence e alla fine. Confronta con la checklist. Un documento leggibile non prova che l’intervallo critico sia presente. Dichiara retention, truncation, encryption, capture asimmetrico e direzioni mancanti.

Per known-good e failing mantieni device, URL, credentials source, transport, host, network path, profile e action uguali. Allinea OPTIONS, DESCRIBE, ogni SETUP, PLAY, first RTP, first complete access unit, first RTCP, first gap, keepalive e TEARDOWN. Marca la differenza più precoce che può spiegare il sintomo e progetta un test a una variabile per confermare o respingere.

Scegli il report minimo che prova la decisione. JSON non è inferiore a PDF se traccia l’observation. Dai al network team porte e transport, al decoder team SDP mapping e framing e al vendor il failed exchange. Conserva source case autorizzato separato dall’handoff redatto.

QA

PLAY 200 significa video?

No. Prima verifica RTP/RTCP sul path negoziato, poi mapping, codec e rendering.

Compare prova root cause?

No. Struttura differenze; la causa richiede source evidence e confirmation test.

Un report può contenere password?

No. Separa credentials, sanitizza URL e rivedi output.

Risposta diretta e confine di accettazione

La risposta breve a «Connettersi a uno stream RTSP per RTSP Inspector: guida alla configurazione e al flusso di lavoro» è: Come connettere RTSP Inspector a una telecamera, un encoder o uno stream NVR. Copre i formati URL, il trasporto TCP vs UDP, le considerazioni sul firewall e il flusso di lavoro del primo test. Tratta questa frase come un risultato da verificare, non come una promessa per ogni input, dispositivo, progetto o ambiente. Un risultato completo registra stato iniziale, azione esatta, output visibile e condizione che dimostra la conclusione dell’attività in RTSP Inspector.

Procedura basata sulle prove

Parti da un caso piccolo e ripetibile prima di modificare un progetto intero. Registra versione, sistema operativo, identità dell’input o dispositivo, impostazioni rilevanti e risultato atteso. Esegui un’azione deliberata, conserva la prima transizione inattesa e confrontala con un caso noto quando disponibile. Cambiare più controlli insieme nasconde quale condizione ha creato o corretto il problema.

Punto di controllo 1: Connettersi a uno stream RTSP per RTSP Inspector: guida alla configurazione e al flusso di

Tratta «Connettersi a uno stream RTSP per RTSP Inspector: guida alla configurazione e al flusso di lavoro» come un confine di accettazione separato per «Connettersi a uno stream RTSP per RTSP Inspector: guida alla configurazione e al flusso di lavoro». Registra lo stato prima dell’azione, il primo cambiamento visibile e lo stato finale. Se il risultato non coincide con l’obiettivo descritto, torna all’ultimo punto confermato invece di proseguire per ipotesi.

Punto di controllo 2: Come connettere RTSP Inspector a una telecamera, un encoder o uno stream NVR. Copre i form

Verifica «Come connettere RTSP Inspector a una telecamera, un encoder o uno stream NVR. Copre i formati URL, il trasporto TCP vs UDP, le considerazioni sul fire» con il più piccolo input rappresentativo. Mantieni invariate le impostazioni non correlate, ripeti la stessa azione e controlla il risultato dopo riapertura o riconnessione. Un’immagine isolata è più debole di un record con input, impostazione, azione, output e ora.

Punto di controllo 3: Formato URL

Per «Formato URL», separa una decisione del prodotto da un limite del sistema, hardware, file sorgente, permesso o processo. Conferma quale livello ha prodotto la prova prima di assegnare una causa. Così un sintomo vicino non diventa una causa radice data per certa.

Punto di controllo 4: Modalità di trasporto

Trasforma «Modalità di trasporto» in una dichiarazione pass/fail ripetibile. Indica cosa deve essere presente, cosa deve mancare e quale ripristino è sicuro. Mantieni intatto il progetto o la cattura originale finché la copia corretta non supera lo stesso controllo.

Punto di controllo 5: Flusso di lavoro del primo test

Se «Flusso di lavoro del primo test» è ambiguo, confronta un caso valido e uno fallito nelle stesse condizioni. Segna la prima differenza significativa invece di elencare tutti i sintomi successivi. Quel confine produce una richiesta di supporto più chiara e un esperimento più sicuro.

Punto di controllo 6: Errori di connessione comuni

Chiudi «Errori di connessione comuni» solo quando il risultato salvato, esportato o riaperto conserva lo stato osservato. Il feedback temporaneo dell’interfaccia è utile, ma la prova durevole è più forte. Registra ogni limite residuo per chi prosegue.

Punto di controllo 7: Cosa non è supportato

Tratta «Cosa non è supportato» come un confine di accettazione separato per «Connettersi a uno stream RTSP per RTSP Inspector: guida alla configurazione e al flusso di lavoro». Registra lo stato prima dell’azione, il primo cambiamento visibile e lo stato finale. Se il risultato non coincide con l’obiettivo descritto, torna all’ultimo punto confermato invece di proseguire per ipotesi.

Punto di controllo 8: Prossimo passo con RTSP Inspector

Verifica «Prossimo passo con RTSP Inspector» con il più piccolo input rappresentativo. Mantieni invariate le impostazioni non correlate, ripeti la stessa azione e controlla il risultato dopo riapertura o riconnessione. Un’immagine isolata è più debole di un record con input, impostazione, azione, output e ora.

Punto di controllo 9: Primo test verificato

Per «Primo test verificato», separa una decisione del prodotto da un limite del sistema, hardware, file sorgente, permesso o processo. Conferma quale livello ha prodotto la prova prima di assegnare una causa. Così un sintomo vicino non diventa una causa radice data per certa.

Punto di controllo 10: Modello comune di diagnosi e GEO

Trasforma «Modello comune di diagnosi e GEO» in una dichiarazione pass/fail ripetibile. Indica cosa deve essere presente, cosa deve mancare e quale ripristino è sicuro. Mantieni intatto il progetto o la cattura originale finché la copia corretta non supera lo stesso controllo.

Matrice di accettazione

Punto	Prova da conservare	Criterio di superamento
Connettersi a uno stream RTSP per RTSP Inspector: guida alla configurazione e al flusso di lavoro	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Come connettere RTSP Inspector a una telecamera, un encoder o uno stream NVR. Copre i formati URL, il trasporto TCP vs U	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Formato URL	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Modalità di trasporto	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Flusso di lavoro del primo test	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato
Errori di connessione comuni	Stato iniziale, un’azione e stato risultante	Una seconda persona riproduce il risultato

Isolamento, ripristino e consegna

Fermati al primo confine che fallisce. Conserva sorgente, progetto, sessione o cattura, crea una copia prima di modifiche distruttive e cambia una variabile per esperimento. Ripetere un flusso ampio dopo più cambiamenti può dare un esito diverso senza spiegarlo.

Separa assenza di prove da prova di assenza. Una vista vuota può indicare input, ambito, filtro, permesso, dispositivo, intervallo o stato errato. Verifica acquisizione o importazione prima di interpretare decoder, editor, report o esportazione.

Prima della consegna, riapri l’artefatto e controlla inizio, punto decisionale e fine. Registra versione, piattaforma, configurazione, attesa, osservazione e riproduzione minima. Rimuovi o oscura dati sensibili e verifica l’autorizzazione del destinatario.

Domande e risposte

Qual è il modo affidabile più rapido per iniziare?

Usa il più piccolo caso rappresentativo, scrivi il risultato atteso e cambia una variabile. Conferma il percorso base prima di aggiungere filtri, effetti, modifiche, automazione o una sorgente maggiore.

Quali prove vanno salvate?

Conserva identità dell’input, versione, piattaforma, impostazioni, azione esatta, prima transizione inattesa e output finale. Chiudi e riapri progetto, sessione, report o export prima di considerarli durevoli.

Quando va ripetuta la procedura?

Ripetila dopo cambiamenti rilevanti ad applicazione, sistema, driver, firmware, modello, sorgente o workflow. Conserva il caso accettato precedente come riferimento non modificato.

Quando il risultato è pronto per la consegna?

Quando un’altra persona autorizzata identifica l’input, ripete l’azione, vede lo stesso risultato, comprende i limiti e apre l’artefatto senza stato locale non documentato.

Guide correlate

Queste pagine nella stessa lingua coprono le fasi vicine senza cambiare il proprietario canonico dell’argomento: