Sorge spesso la domanda: come collegare una telecamera IP all'NVR se non è nell'elenco di compatibilità?

Ci sono due opzioni ONVIF e RTSP

Iniziamo con il protocollo ONVIF (Open Network Video Interface Forum).

ONVIF è un protocollo comune per l'interoperabilità di telecamere IP, NVR, software, nel caso in cui tutti i dispositivi provengano da produttori diversi. ONVIF può essere paragonato all'inglese per la comunicazione internazionale tra le persone.

Assicurati che i dispositivi collegati supportino ONVIF, su alcuni dispositivi ONVIF potrebbe essere disabilitato per impostazione predefinita.
Oppure l'autorizzazione ONVIF può essere disabilitata, il che significa che il login/password sarà sempre quello predefinito
indipendentemente dal login/password per il WEB

Vale anche la pena notare che alcuni dispositivi utilizzanoporta separata per lavorare con il protocollo ONVIF

In alcuni casi, la password ONVIF può differire dalla password per l'accesso al WEB.

Cosa è disponibile quando si è connessi tramite ONVIF?

Scoperta del dispositivo

Trasferimento dati video

Ricezione e trasmissione di dati audio

Controllo PTZ (PTZ)

Analisi video (ad es. rilevamento del movimento)

Queste opzioni dipendono dalla compatibilità delle versioni del protocollo ONVIF. In alcuni casi, alcuni dei parametri non sono disponibili o funzionano in modo errato.

K e utilizzando ONVIF

Nei registratori SNR e Dahua, il protocollo ONVIF si trova nella scheda Dispositivo remoto, riga Produttore

Selezionare il canale a cui verrà collegato il dispositivo

Dalla scheda Produttore selezionare ONVIF

Specificare indirizzo IP dispositivi

RTSP la porta rimane predefinita

Le fotocamere usano ONVIF porta 8080
(dal 2017, sui nuovi modelli ONVIF, il port è stato modificato in 80 per la serie Alpha, Mira)
Telecamere OMNY Base utilizzo ONVIF porta 80, nel registrar è specificata come porta HTTP

Nome

Parola d'ordine in base ai parametri del dispositivo

canale remoto il valore predefinito è 1. Se il dispositivo è multicanale, viene indicato il numero del canale.

Buffer del decodificatore— buffering del flusso video con valore temporale

tipo di serverc'è una scelta di TCP, UDP Schedule

TCP- stabilisce una connessione tra mittente e destinatario, fa in modo che tutti i dati raggiungano il destinatario senza modifiche e nella sequenza desiderata, regola inoltre la velocità di trasmissione.

A differenza del TCP, UDP non stabilisce una connessione preliminare, ma inizia semplicemente a trasmettere i dati. UDP non tiene traccia dei dati ricevuti e non li duplica in caso di perdita o errore.

UDP è meno affidabile di TCP. Ma d'altra parte, fornisce uno streaming più veloce grazie all'assenza di ritrasmissione dei pacchetti persi.

Programma— rilevamento automatico del tipo.

Ecco come appaiono i dispositivi connessi in Dahua

Lo stato verde indica che il DVR e la telecamera sono collegati correttamente

Lo stato rosso indica che ci sono problemi di connessione. Ad esempio, la porta di connessione non è corretta.

Il secondo modo per connettersi è RTSP(Protocollo di streaming in tempo reale)

RTSPun protocollo di streaming in tempo reale che descrive i comandi per il controllo di un flusso video.

Con l'aiuto di questi comandi, il flusso video viene trasmesso dalla sorgente al destinatario.

ad esempio da una telecamera IP a un DVR o un server.

Cosa è disponibile quando ci si connette tramite RTSP?

Trasferimento dati video

Ricezione e trasmissione di dati audio

vantaggiodi questo protocollo di trasferimento in quanto non richiede compatibilità di versione.

Oggi, RTSP è supportato da quasi tutte le telecamere IP e NVR.

svantaggi protocollo è che nient'altro è disponibile tranne la trasmissione di dati video e audio.

Diamo un'occhiata a un esempio di collegamento di una fotocamera a e utilizzando RTSP

RTSP che si trova nella scheda Dispositivo remoto, riga Produttore, nel registro SNR e Dahua è presentato comeGenerale

Selezionare il canale a cui verrà collegato il dispositivo

Indir- qui inseriamo la stringa di query con cui la telecamera ritorna di base Flusso RTSP da alto risoluzione.

URL aggiuntivo - qui immettere la stringa di query in base alla quale la telecamera restituisce aggiuntivo Flusso RTSP da Bassa risoluzione.

Esempio di richiesta:

rtsp://172.16.31.61/1 flusso principale

rtsp://172.16.31.61/2 flusso aggiuntivo

Perché hai bisogno di un flusso aggiuntivo?

Su un monitor locale collegato a un registratore multi-immagine, il registratore utilizza un thread aggiuntivo per risparmiare risorse. Ad esempio, nelle immagini piccole di 16 finestre non è affatto necessario decodificare la risoluzione Full HD, è sufficiente D1. Bene, se in questo caso hai aperto finestre 1/4/8, il flusso principale viene decodificato ad alta risoluzione.

Nomein base ai parametri del dispositivo

Parola d'ordine in base ai parametri del dispositivo

Buffer del decodificatorebuffering del flusso video con valore temporale

tipo di server- TCP, UDP, Schedule (simile al protocollo ONVIF)

Questo articolo risponde alle domande più comuni come:

La telecamera IP è compatibile con l'NVR?

E se è compatibile, come si connette!?

Protocollo RTSP

RTSP (Real Time Streaming Protocol, o, in russo, protocollo di streaming in tempo reale) è un protocollo applicativo che descrive i comandi per il controllo di un flusso video. Con questi comandi possiamo “ordinare” la telecamera o il server, ad esempio, per avviare la trasmissione di un flusso video. Un esempio di richiesta per avviare la riproduzione è simile al seguente: PLAY rtsp://192.168.0.200/h264 RTSP/1.0

Cioè, RTSP è solo un insieme di comandi per controllare il flusso video. Facciamo un esperimento. Per fare ciò, abbiamo bisogno di una telecamera IP che supporti il ​​protocollo RTSP e il suo indirizzo RTSP. Questo indirizzo assomiglia a questo rtsp:// /mpeg. Può essere trovato nel manuale della fotocamera o nella descrizione dell'API. Per comodità, elencheremo gli indirizzi RTSP per un certo numero di telecamere popolari nella tabella. Dopo aver conosciuto l'indirizzo RTSP della telecamera, apriamo un lettore standard che supporta RTSP. Può essere uno dei seguenti programmi: Windows Media Player, QuickTime, Media Player Classic, VLC media player, RealPlayer, MPlayer. Abbiamo scelto QuickTime. Apri il menu "File > Apri URL" e inserisci il nostro indirizzo RTSP. Successivamente, QuickTime si collegherà alla fotocamera e riprodurrà "video live". I dispositivi di registrazione che operano nei sistemi di videosorveglianza IP ricevono il video dalle telecamere utilizzando il protocollo HTTP, ovvero nello stesso modo in cui scarichiamo le immagini JPEG dai siti Web, o come flusso tramite RTSP, ovvero nello stesso modo in cui lo abbiamo ricevuto utilizzando lo standard giocatore nell'ultimo esempio. Nelle impostazioni delle telecamere IP, l'opzione di trasferimento dei dati in streaming può essere definita RTSP su TCP, RTSP su UDP o semplicemente RTP. Quindi, RTSP è un insieme di comandi per il controllo del flusso. Ma cosa significano le altre abbreviazioni: TCP, UDP, RTP? TCP, UDP e RTP sono meccanismi di trasporto (protocolli) che trasmettono effettivamente video.

protocollo TCP

Diciamo che abbiamo scelto il metodo RSTP su TCP e vogliamo iniziare a trasmettere un flusso video. Cosa accadrà a livello dei meccanismi di trasporto? In precedenza, con l'aiuto di diversi comandi, verrà stabilita una connessione tra il mittente e il destinatario. Successivamente, inizierà il trasferimento dei dati video. Allo stesso tempo, i meccanismi TCP

farà in modo che tutti i dati raggiungano il destinatario inalterati e nella corretta sequenza. TCP regolerà anche la velocità di trasmissione in modo che il trasmettitore non invii dati più intensamente di quanto il ricevitore possa elaborarli, ad esempio,

UDP è un'alternativa al protocollo di trasporto TCP. A differenza di TCP, UDP non stabilisce una preconnessione, ma inizia semplicemente a trasmettere i dati. UDP non si assicura che i dati vengano ricevuti e non li duplica se le parti sono mancanti o ricevute con errori. UDP meno

affidabile di TCP. Ma d'altra parte, fornisce uno streaming più veloce a causa dell'assenza di un meccanismo per ritrasmettere i pacchetti persi. La differenza tra i protocolli TCP e UTP può essere illustrata dal seguente esempio. Due amici si incontrano. Opzione TCP:

Ivan: Ciao! Chiacchieriamo?" (la connessione è stabilita)
Simone: "Ciao! Andiamo!" (la connessione è stabilita)
Ivan: “Ieri ero in negozio. Capisci?" (trasferimento dati)
Simone: "Sì!" (la conferma)
Ivan: “Stavano scaricando nuove attrezzature. Capisci?" (trasferimento dati)
Semyon: "No" (conferma)
Ivan: “Stavano scaricando nuove attrezzature. Capisci?" (ritrasmissione)
Simone: "Sì!" (la conferma)
Ivan: “Domani ci sarò di nuovo. Capisci?" (trasferimento dati)
Simone: "Sì!" (la conferma)
variante UDP
Ivan: Ciao! Ieri sono andato in negozio” (trasmissione dati)
Ivan: “Stavano scaricando nuove attrezzature” (trasmissione dati)
Ivan: “Domani ci sarò di nuovo” (trasmissione dati)
Ivan: "Posso farti i prezzi" (trasmissione dati)
Ivan: "Hanno promesso sconti per buoni volumi" (trasmissione dati)
Ivan: "Se vuoi chiama - andiamo insieme" (trasmissione dati)
Semyon: "Sì, chiamo" (trasmissione dati)

Puoi anche vedere la differenza nei protocolli eseguendo il seguente esperimento: prova a impostare la fotocamera su RTSP su modalità TCP e agita la mano davanti all'obiettivo: vedrai un ritardo sullo schermo monitor. Ora esegui lo stesso test in modalità RTSP su UDP. Il ritardo sarà minore. Diversi fattori influenzano il tempo di ritardo: il formato di compressione, la potenza del computer, il protocollo di trasmissione e le caratteristiche del software coinvolto nella decodifica video.

RTP (Real-time Transport Protocol) o protocollo di trasporto in tempo reale in russo. Questo protocollo è specificamente progettato per trasmettere il traffico in tempo reale. Consente di monitorare la sincronizzazione dei dati trasmessi, regolare la sequenza di consegna dei pacchetti ed è quindi più adatto di altri alla trasmissione di dati video e audio. In generale, è preferibile utilizzare RTP o UDP per trasmettere un flusso video. Il lavoro tramite TCP è giustificato solo se dobbiamo lavorare con reti problematiche, poiché il protocollo TCP sarà in grado di correggere errori e guasti che si verificano durante il trasferimento dei dati.

RTSP (protocollo di streaming in tempo reale)è un protocollo di streaming in tempo reale che contiene un semplice insieme di comandi di base per il controllo di un flusso video.

Collegamento di sorgenti RTSP e telecamere IP in una videoconferenza

Il protocollo RTSP consente a qualsiasi utente TrueConf di connettersi a videocamere IP e altre fonti di contenuto multimediale che trasmettono utilizzando questo protocollo per monitorare oggetti remoti. Inoltre, l'utente può connettersi a tali telecamere per trasmettere immagini durante una videoconferenza.

Grazie al supporto del protocollo RTSP, gli utenti di TrueConf Server possono non solo connettersi a telecamere IP, ma anche trasmettere videoconferenze a lettori RTSP e server multimediali. Ulteriori informazioni sulle trasmissioni RTSP.

Vantaggi dell'utilizzo di telecamere IP con soluzioni software TrueConf

• Installando una telecamera IP in un ufficio o in un'officina industriale e collegandola ad essa in qualsiasi momento, potrai monitorare il processo produttivo della tua azienda.
• È possibile eseguire il monitoraggio 24 ore su 24 di oggetti remoti. Ad esempio, se stai andando in vacanza e non vuoi lasciare il tuo appartamento incustodito, installa lì una o più telecamere IP. Effettuando una chiamata a una di queste telecamere dal tuo PC con l'applicazione client TrueConf installata, puoi connetterti al tuo appartamento in qualsiasi momento e vedere cosa sta succedendo lì in tempo reale.
• Le applicazioni client TrueConf per Windows, Linux e macOS offrono a tutti gli utenti la possibilità di registrare videoconferenze, grazie alle quali è possibile registrare qualsiasi evento durante la videosorveglianza e riceverne prove documentali.

Secondo alcuni dati, ad oggi, il mondo ha installato centinaia di milioni Telecamere IP per la videosorveglianza. Tuttavia, lontano da tutti, il ritardo nella riproduzione video è fondamentale. La videosorveglianza, di regola, avviene "staticamente": il flusso viene registrato in memoria e può essere analizzato per il movimento. Per la videosorveglianza sono state sviluppate molte soluzioni software e hardware che svolgono egregiamente il loro lavoro.

In questo articolo, esamineremo un'applicazione leggermente diversa. Telecamere IP, ovvero l'utilizzo nelle trasmissioni online, ove richiesto basso ritardo di comunicazione.

Prima di tutto chiariamo un possibile malinteso nella terminologia relativa a webcam e telecamere IP.

Webcamè un dispositivo di acquisizione video che non dispone di un proprio processore e interfaccia di rete. La webcam richiede la connessione a un computer, smartphone o altro dispositivo dotato di scheda di rete e processore.

Telecamera IPè un dispositivo autonomo che dispone di una propria scheda di rete e processore per comprimere il video acquisito e inviarlo alla rete. Pertanto, la telecamera IP è un mini-computer autonomo che si connette completamente alla rete e non ha bisogno di essere collegato a un altro dispositivo e può trasmettere direttamente alla rete.

Bassa latenza(bassa latenza) è un requisito abbastanza raro per le telecamere IP e le trasmissioni online. La necessità di lavorare con una bassa latenza appare, ad esempio, se la sorgente del flusso video interagisce attivamente con gli spettatori di questo flusso.

Molto spesso, è necessaria una bassa latenza nei casi d'uso di gioco. Gli esempi includono: asta di video in tempo reale, casinò video con croupier dal vivo, programma TV online interattivo con host, telecomando di un quadrirotore, ecc.

Un dealer di casinò online dal vivo al lavoro.

Una normale telecamera IP RTSP, di norma, inserisce il video H.264 codec e può operare in due modalità di trasporto dati: interfogliato e non intercalato.

Modalità interfogliato il più popolare e conveniente, perché in questa modalità, i dati video vengono trasmessi tramite protocollo TCP all'interno della connessione di rete alla telecamera. Per distribuire da una telecamera IP all'interleaved, è sufficiente aprire/inoltrare una porta RTSP della telecamera (ad esempio, 554) verso l'esterno. Il giocatore deve solo connettersi alla telecamera tramite TCP e raccogliere il flusso già all'interno di questa connessione.

La seconda modalità operativa della fotocamera è non intercalato. In questo caso, la connessione viene stabilita utilizzando il protocollo RTSP/TCP, e il traffico va già separatamente, secondo il protocollo RTP/UDP al di fuori del canale TCP creato.

Modalità non intercalato più favorevole per la trasmissione di video con un ritardo minimo, poiché utilizza il protocollo RTP/UDP, ma allo stesso tempo è più problematico se il giocatore si trova dietro NAT.

Quando si connette alla telecamera IP di un lettore situata dietro NAT, il lettore deve sapere quali indirizzi IP esterni e quali porte può utilizzare per ricevere traffico audio e video. Queste porte sono specificate nel testo SDP config che viene inviato alla telecamera quando viene stabilita una connessione RTSP. Se il NAT è stato aperto correttamente e sono stati definiti gli indirizzi IP e le porte corretti, tutto funzionerà.

Quindi, per acquisire video dalla fotocamera con un ritardo minimo, è necessario utilizzare non interlacciato modalità e ricevere traffico video su UDP.

I browser non supportano direttamente lo stack del protocollo RTSP/UDP, ma supportano lo stack del protocollo della tecnologia incorporata WebRTC.

Le tecnologie del browser e della fotocamera sono molto simili, in particolare SRTPè crittografato RTP. Ma per una corretta distribuzione ai browser, una telecamera IP avrebbe bisogno di un supporto parziale per lo stack WebRTC.

Per eliminare questa incompatibilità è necessario un server di inoltro intermedio, che farà da ponte tra i protocolli della telecamera IP ei protocolli del browser.

Il server prende il flusso dalla telecamera IP a se stesso RTP/UDP e lo fornisce ai browser collegati tramite WebRTC.

La tecnologia WebRTC funziona secondo il protocollo UDP e quindi garantisce una bassa latenza nella direzione Server > Browser. La telecamera IP funziona anche sul protocollo RTP/UDP e fornisce una bassa latenza nella direzione Fotocamera > Server.

La telecamera può fornire un numero limitato di flussi, a causa delle risorse e della larghezza di banda limitate. L'utilizzo di un server intermedio consente di scalare la trasmissione da una telecamera IP a un numero elevato di spettatori.

D'altra parte, quando si utilizza il server, sono abilitate due gambe di comunicazione:
1) Tra visualizzatori e server
2) Tra server e telecamera
Tale topologia ha una serie di "caratteristiche" o "insidie". Li elenchiamo di seguito.

Trappola n. 1 - Codec

I codec utilizzati possono rappresentare un ostacolo alla bassa latenza e causare un degrado delle prestazioni complessive del sistema.

Ad esempio, se la fotocamera fornisce un flusso video a 720p in H.264 e un browser Chrome è connesso a uno smartphone Android che supporta solo VP8.

Quando la transcodifica è abilitata, è necessario creare una sessione di transcodifica per ciascuna delle telecamere IP collegate, che esegue la decodifica H.264 e codifica VP8. In questo caso, un server con doppio processore a 16 core sarà in grado di servire solo 10-15 telecamere IP, con un calcolo approssimativo di 1 telecamera per core fisico.

Pertanto, se le capacità del server non consentono la transcodifica del numero pianificato di telecamere, è necessario evitare la transcodifica. Ad esempio, servi solo browser con supporto H.264 e offri il resto per utilizzare un'applicazione mobile nativa per iOS o Android, dove è disponibile il supporto per il codec H.264.

Come opzione per bypassare la transcodifica in un browser mobile, puoi utilizzare HLS. Ma lo streaming HTTP non è affatto a bassa latenza e al momento non può essere utilizzato per lo streaming interattivo.

Insidia n. 2 - Bitrate e perdita della fotocamera

Il protocollo UDP aiuta a far fronte al ritardo, ma consente la perdita di pacchetti video. Pertanto, nonostante la bassa latenza, con grandi perdite di rete tra la fotocamera e il server, l'immagine potrebbe essere danneggiata.

Per eliminare le perdite, è necessario assicurarsi che il flusso video generato dalla telecamera abbia una velocità in bit che rientri nella larghezza di banda allocata tra la telecamera e il server.

Insidia n. 3 - Bitrate e perdita dello spettatore

Ogni visualizzatore di trasmissioni che si connette al server ha anche una determinata larghezza di banda per il download.

Se la telecamera IP invia un flusso che supera le capacità del canale visualizzatore (ad esempio, la telecamera invia 1 Mbps e lo spettatore può solo accettare 500 kbps), ci saranno grandi perdite su questo canale e, di conseguenza, fregi video o forti artefatti.

In questo caso, ci sono tre opzioni:

1. Transcodifica il flusso video individualmente per ogni visualizzatore al bitrate richiesto.
2. Transcodifica i flussi non per ogni connesso, ma per un gruppo di un gruppo di visualizzatori.
3. Prepara in anticipo i flussi dalla fotocamera in diverse risoluzioni e bitrate.

Prima opzione con transcodifica per ogni visualizzatore non è adatto, poiché consumerà risorse della CPU già con 10-15 visualizzatori collegati. Anche se va notato che questa opzione fornisce la massima flessibilità con il massimo carico della CPU. Quelli. questo è l'ideale, ad esempio, se stai trasmettendo in streaming solo a 10 persone geograficamente distribuite, ognuna di esse riceve un bitrate dinamico e ognuna di esse necessita di un ritardo minimo.

Seconda opzione consiste nel ridurre il carico sulla CPU del server utilizzando i gruppi di transcodifica. Il server crea diversi gruppi per bitrate, ad esempio due:

• 200 Kbps
• 1 Mbps

Se lo spettatore non ha abbastanza larghezza di banda, passa al gruppo in cui può comodamente ricevere il flusso video. Pertanto, il numero di sessioni di transcodifica non è uguale al numero di visualizzatori come nel primo caso, ma è un numero fisso, ad esempio 2, se i gruppi di transcodifica Due.

Terza opzione comporta un rifiuto completo della transcodifica lato server e l'utilizzo di flussi video già preparati in varie risoluzioni e bit rate. In questo caso, la telecamera è configurata per emettere due o tre flussi con risoluzioni e bit rate diversi e gli spettatori passano da uno all'altro a seconda della larghezza di banda.

In questo caso, il carico di transcodifica sul server scompare e si sposta sulla telecamera stessa, perché la telecamera è ora obbligata a codificare due o più flussi invece di uno.

Di conseguenza, abbiamo considerato tre opzioni per adattarci alla larghezza di banda degli spettatori. Se assumiamo che una sessione di transcodifica richieda 1 core del server, otteniamo la seguente tabella di carico della CPU:

La tabella mostra che possiamo spostare il carico di transcodifica sulla telecamera o trasferire la transcodifica al server. Le opzioni 2 e 3 sembrano essere le più ottimali.

Test di RTSP come WebRTC

È tempo di eseguire alcuni test per rivelare il quadro reale di ciò che sta accadendo. Prendiamo una vera telecamera IP e la testiamo per misurare la latenza di trasmissione.

Prendiamo un'antica telecamera IP per il test Collegamento D DCS-2103 con il supporto RTSP e codec H.264 e G.711.

Dato che la fotocamera è rimasta a lungo in un armadio con altri dispositivi e cavi utili, ho dovuto inviarla a Ripristina premendo e tenendo premuto il pulsante sul retro della fotocamera per 10 secondi.

Dopo la connessione alla rete, la luce verde sulla telecamera si è accesa e il router ha rilevato un altro dispositivo sulla rete locale con un indirizzo IP di 192.168.1.37.

Andiamo all'interfaccia web della fotocamera e impostiamo i codec e la risoluzione per il test:

Quindi, vai alle impostazioni di rete e scopri l'indirizzo RTSP della telecamera. In questo caso, l'indirizzo RTSP live1.sdp, cioè. La fotocamera è disponibile all'indirizzo rtsp://192.168.1.37/live1.sdp

L'accessibilità della fotocamera può essere facilmente verificata lettore VLC. Media - Apri flusso di rete.

Ci siamo assicurati che la fotocamera funzioni e fornisca video tramite RTSP.

Useremo Web Call Server 5 come server per i test. Questo è un server di streaming con supporto RTSP e WebRTC protocolli. Si collegherà alla telecamera IP tramite RTSP e prendi il flusso video. Distribuire ulteriormente il flusso di WebRTC.

Dopo l'installazione, è necessario impostare il server in modalità RTSP non intercalato di cui abbiamo discusso sopra. Questo può essere fatto aggiungendo l'impostazione

rtsp_interleaved_mode=falso
Questa impostazione viene aggiunta alla configurazione flashphoner.properties e richiede il riavvio del server:

Riavvio del server delle chiamate web del servizio
Pertanto, abbiamo un server che funziona secondo lo schema non interleaved, riceve i pacchetti dalla telecamera IP tramite UDP e quindi distribuisce tramite WebRTC (UDP).

Il server di prova si trova su un server VPS situato nel data center di Francoforte, dispone di 2 core e 2 gigabyte di RAM.

La telecamera si trova sulla rete locale in 192.168.1.37.

Pertanto, la prima cosa che dobbiamo fare è inoltrare la porta 554 a 192.168.1.37 per l'ingresso TCP/RTSP connessioni in modo che il server possa connettersi alla nostra telecamera IP. Per fare ciò, aggiungi solo una regola nelle impostazioni del router:

La regola dice al router di reindirizzare tutto il traffico in entrata sulla porta 554 a 37, l'indirizzo IP.

Se hai un NAT amichevole e conosci l'indirizzo IP esterno, puoi iniziare a testare con il server.

Il lettore demo standard nel browser Google Chrome ha il seguente aspetto:

Per iniziare a riprodurre uno stream RTSP, devi solo inserire il suo indirizzo nel campo Flusso.
In questo caso, l'indirizzo del flusso: rtsp://ip-cam/live1.sdp
Qui telecamera IP questo è l'indirizzo IP esterno della tua fotocamera. Il server proverà a stabilire una connessione a questo indirizzo.

VLC vs test di latenza WebRTC

Dopo aver configurato la telecamera IP e testato VLC, configurare il server e testarlo RTSP flusso attraverso il server con distribuzione da WebRTC, possiamo finalmente confrontare i ritardi.

Per fare ciò, utilizzeremo un timer che mostrerà frazioni di secondo sullo schermo del monitor. Attiva il timer e riproduci lo streaming video contemporaneamente VLC in locale e sul browser Firefox tramite un server remoto.

Eseguire il ping sul server 100 ms.
Ping localmente 1 ms.

Il primo test del timer si presenta così:
Su uno sfondo nero c'è il timer originale, che mostra un ritardo zero. Sinistra VLC, sulla destra Firefox ricevere WebRTC flusso da un server remoto.

	Zero	VLC	Firefox, WCS
Tempo	50.559	49.791	50.238
latenza ms	0	768	321

In questo test, vediamo un ritardo VLC il doppio del ritardo Firefox + Server di chiamata Web, nonostante il video in VLC venga riprodotto sulla rete locale e il video visualizzato in Firefox passi attraverso un server in un data center in Germania e ritorni indietro. Questa discrepanza potrebbe essere dovuta al fatto che VLC funziona su TCP (modalità interleaved) e include alcuni buffer aggiuntivi per una riproduzione video fluida.

Abbiamo fatto alcuni scatti per catturare i valori di ritardo.