Risolvere il problema della trasmissione online da una telecamera IP, in generale, non richiede l'uso di WebRTC. La telecamera stessa è un server, ha un indirizzo IP e può essere collegata direttamente a un router per distribuire contenuti video. Allora perché utilizzare la tecnologia WebRTC?
Ci sono almeno due ragioni per questo:
1. Con l'aumentare del numero di spettatori di una trasmissione Ethernet, prima si verificherà una crescente carenza di spessore del canale e poi delle risorse della telecamera stessa.
2. Come accennato in precedenza, la telecamera IP è un server. Ma con quali protocolli sarà in grado di fornire il video al browser desktop? Dispositivo mobile? Molto probabilmente sarà lo streaming HTTP, in cui i fotogrammi video o le immagini JPEG vengono trasmessi tramite HTTP. Lo streaming HTTP, come sai, non è del tutto adatto streaming video in tempo reale, anche se funziona bene nei video on demand, dove l'interattività e la latenza del flusso non sono particolarmente importanti. Infatti, se stai guardando un film, ritardare il video di qualche secondo non peggiorerà le cose, a meno che tu non stia guardando il film contemporaneamente a qualcun altro. "Oh no! Jack l'ha uccisa! - Alice scrive uno spoiler in chat a Bob 10 secondi prima del tragico epilogo.
Oppure sarà RTSP/RTP e H.264, nel qual caso è necessario installare nel browser un plug-in del lettore video come VLC o QuickTime. Tale plug-in raccoglierà e riprodurrà il video, proprio come il lettore stesso. Ma abbiamo davvero bisogno di un vero streaming basato su browser senza installare stampelle / plug-in aggiuntivi.
Per prima cosa, annusiamo la telecamera IP per scoprire cosa invia esattamente questo dispositivo verso il browser. Come soggetto di prova ci sarà una fotocamera D-Link DCS 7010L:
Puoi leggere ulteriori informazioni sull'installazione e la configurazione della videocamera di seguito, ma qui vedremo solo cosa utilizza per lo streaming video. Quando entri nel pannello di amministrazione della videocamera attraverso l'interfaccia web, vediamo qualcosa del genere (scusa per il panorama):
L'immagine si apre in tutti i browser e in modo uniforme podlagivaet, circa una volta al secondo. Considerando che sia la telecamera che il laptop su cui stiamo guardando lo streaming sono collegati allo stesso router, tutto dovrebbe essere fluido e bello, ma non lo è. Simile a HTTP. Esegui Wireshark per confermare le nostre ipotesi:
Qui vediamo una sequenza di frammenti TCP lunghi 1514 byte
E un HTTP 200 finale OK con la lunghezza del JPEG ricevuto:
Non abbiamo bisogno di questo streaming. Non fluido, estrae le richieste HTTP. Quante richieste di questo tipo al secondo può sopportare la telecamera? C'è motivo di credere che a 10 spettatori e prima, la telecamera sarà piegata in modo sicuro o inizierà a presentare problemi terribili e distribuirà diapositive.
Se guardi dentro Pagine HTML pannello di amministrazione della telecamera, vedremo questo codice interessante:
If(browser_IE) DW(""); else ( if(mpMode == 1) var RTSPName = g_RTSPName1; else if(mpMode == 2) var RTSPName = g_RTSPName2; else if(mpMode == 3) var RTSPName = g_RTSPName3; var o=""; if (g_isIPv6) //perché ipv6 non supporta rtsp.var host = g_netip;else var host = g_host;o+=""; //avviso(o); DW(o); )
RTSP/RTP è proprio ciò di cui hai bisogno per una corretta riproduzione video. Ma funzionerà in un browser? - Non. Ma se installi il plug-in QuickTime, tutto funzionerà. Ma stiamo facendo streaming puramente basato su browser.
Qui puoi anche menzionare Flash Player, che può ricevere un flusso RTMP convertito da RTSP, RTP, H.264 attraverso un server adatto come Wowza. Ma Flash Player, come sai, è anche un plug-in del browser, sebbene sia incomparabilmente più popolare di VLC o QuickTime.
In questo caso, testeremo lo stesso re-streaming RTSP/RTP, ma verrà utilizzato un browser compatibile con WebRTC come dispositivo di riproduzione senza plug-in del browser aggiuntivi e altre stampelle. Installeremo un server di inoltro che prenderà il flusso dalla telecamera IP e lo invierà a Internet a un numero arbitrario di utenti che utilizzano browser abilitati per WebRTC.
Collegamento di una telecamera IP
Come accennato in precedenza, per il test è stata scelta una semplice telecamera IP D-Link DCS-7010L. Il criterio di selezione chiave qui era il supporto del dispositivo per il protocollo RTSP, poiché è attraverso di esso che il nostro server prenderà il flusso video dalla telecamera.Colleghiamo la telecamera al router con il cavo patch incluso. Dopo aver acceso l'alimentazione e aver effettuato la connessione al router, la telecamera ha preso un indirizzo IP tramite DHCP, nel nostro caso era 192.168.1.34 (Se vai alle impostazioni del router, vedrai che il dispositivo DCS 7010L è connesso - questo è esso). È ora di testare la fotocamera.
Aprire l'indirizzo IP specificato nel browser 192.168.1.34 per accedere all'interfaccia web dell'amministratore della telecamera. Per impostazione predefinita, non esiste una password.
Come puoi vedere, il video della videocamera viene trasmesso correttamente nel pannello di amministrazione. Allo stesso tempo, si notano inceppamenti periodici. Questo è ciò che risolveremo utilizzando WebRTC.
Configurazione della fotocamera
Innanzitutto, nelle impostazioni della fotocamera, disabilitiamo l'autenticazione: come parte del test, forniremo lo streaming a tutti coloro che lo richiedono. Per fare ciò, nell'interfaccia web della telecamera, vai alle impostazioni Setup-Network e impostare il valore dell'opzione Autenticazione in Disabilita.Nello stesso posto, controlliamo il valore della porta del protocollo RTSP, per impostazione predefinita è 554. Il formato del video trasmesso è determinato dal profilo utilizzato. Puoi impostarne fino a tre nella fotocamera, useremo il primo, live1.sdp - per impostazione predefinita è impostato per utilizzare H.264 per il video e G.711 per l'audio. È possibile modificare le impostazioni, se necessario, nella sezione Setup-Audio e Video.
Ora puoi controllare il funzionamento della telecamera tramite RTSP. Apri VLC Player (puoi usare qualsiasi altro che supporti RTSP - QuickTime, Windows media Player, RealPlayer, ecc.) e nella finestra di dialogo Apri URL impostare l'indirizzo RTSP della telecamera: rtsp://192.168.1.34/live1.sdp
Bene, tutto funziona come dovrebbe. La telecamera riproduce correttamente il flusso video nel lettore tramite il protocollo RTSP.
A proposito, il flusso viene riprodotto in modo abbastanza fluido e senza artefatti. Ci aspettiamo lo stesso da WebRTC.
Installazione del server
Quindi, la telecamera è installata, testata con lettori desktop e pronta per trasmettere tramite il server. Utilizzando whatismyip.com, determiniamo l'indirizzo IP esterno della telecamera. Nel nostro caso era 178.51.142.223. Resta da dire al router che quando si accede tramite RTSP sulla porta 554, le richieste in arrivo vengono trasmesse alla telecamera IP.Martelliamo le impostazioni appropriate nel router ...
...e controlla l'indirizzo IP esterno e la porta RTSP usando telnet:
Telnet 178.51.142.223 554
Dopo esserci assicurati che ci sia una risposta su questa porta, procediamo con l'installazione del server WebRTC.
Un server virtuale su Centos 64 bit su Amazon EC2 sarà responsabile dell'hosting.
Per non avere problemi di prestazioni, abbiamo scelto l'istanza m3.medium con una VCPU:
Sì, sì, ci sono anche Linode e DigitalOcean, ma in questo caso ho voluto Amazon.
Guardando al futuro, scriverò che nel pannello di controllo di Amazon EC2 è necessario aggiungere diverse regole (porte di inoltro), senza le quali l'esempio non funzionerà. Queste sono porte per il traffico WebRTC (SRTP, RTCP, ICE) e porte per il traffico RTSP/RTP. Se ci provi, le regole di Amazon dovrebbero avere qualcosa di simile per il traffico in entrata:
Con DigitalOcean, tra l'altro, tutto sarà più semplice, basta aprire queste porte sul firewall o attutire quest'ultimo. Secondo l'ultima esperienza nel funzionamento delle istanze DO, forniscono comunque un indirizzo IP statico e non si preoccupano dei NAT, il che significa che il port forwarding, come nel caso di Amazon, non è necessario.
Utilizzeremo WebRTC Media & Broadcasting Server di Flashphoner come software server che trasmette un flusso RTSP/RTP a WebRTC. Il server di streaming è molto simile a Wowza, che può eseguire lo streaming RTSP/RTP su Flash. L'unica differenza è che questo flusso verrà assegnato a WebRTC, non a Flash. Quelli. un DTLS onesto passerà tra il browser e il server, verrà stabilita una sessione SRTP e lo stream codificato in VP8 andrà al visualizzatore.
Abbiamo bisogno dell'accesso SSH per l'installazione.
Sotto lo spoiler: una descrizione dettagliata dei comandi eseguiti
1. Scarica l'archivio di installazione del server:
$wget flashphoner.com/downloads/builds/WCS/3.0/x8664/wcs3_video_vp8/FlashphonerMediaServerWebRTC-3.0/FlashphonerMediaServerWebRTC-3.0.868.tar.gz
2. Distribuito:
$tar -xzf FlashphonerMediaServerWebRTC-3.0.868.tar.gz
3. Installato:
$cd FlashphonerMediaServerWebRTC-3.0.868
$./install.sh
Durante il processo di installazione è stato inserito l'indirizzo IP esterno del server: 54.186.112.111 e interno 172.31.20.65 (quello che è IP privato).
4. Avviato il server:
Avvio di $service webcallserver
5. Controllato i log:
$tail - f /usr/local/FlashphonerWebCallServer/logs/server_logs/flashphoner.log
6. Ci siamo assicurati che il server sia avviato e pronto per funzionare:
$ps ausiliario | grep Flashphone
7. Apache installato e avviato:
$yum installa httpd
$servizio httpd start
8. Ho scaricato i file web e li ho inseriti cartella standard apache /var/www/html
cd /var/www/html
$wget github.com/flashphoner/flashphoner_client/archive/wcs_media_client.zip
$ decomprimi webrtc_media_client.zip
9. Immettere l'indirizzo IP del server nella configurazione flashphoner.xml:
10. Arrestato il firewall.
$servizio iptables si interrompe
In teoria, invece del punto 10, sarebbe corretto impostare tutte le porte necessarie e le regole del firewall, ma a scopo di test abbiamo deciso di disabilitare semplicemente il firewall.
Ottimizzazione del server
Ricordiamo che la struttura della nostra trasmissione WebRTC è la seguente:
Abbiamo già installato gli elementi principali di questo diagramma, resta da stabilire le "frecce" delle interazioni.
La connessione tra il browser e il server WebRTC è fornita da un client web, disponibile su github :. Viene semplicemente inserito un set di file JS, CSS e HTML /var/www/html in fase di installazione (vedi paragrafo 9 sopra sotto lo spoiler).
L'interazione tra il browser e il server è configurata nel file XML di configurazione flashphoner.xml. È necessario inserire l'indirizzo IP del server in modo che il client Web possa connettersi al server WebRTC tramite Websocket HTML5 (punto 9 sopra).
La configurazione del server termina qui, puoi verificarne il funzionamento:
Apriamo la pagina del client web index.html nel browser (per questo, Apache è stato installato sullo stesso server Amazon con il comando yum -y installa httpd):
54.186.112.111/wcs_media_client/?id=rtsp://webrtc-ipcam.ddns.net/live1.sdp
Qui webrtc-ipcam.ddns.netè un dominio gratuito ottenuto tramite il server DNS dinamico noip.com, che fa riferimento al nostro indirizzo IP esterno. Abbiamo detto al router di reindirizzare le richieste RTSP a 192.168.1.1. Indirizzi NAT(vedi anche sopra).
Parametro id=rtsp://webrtc-ipcam.ddns.net/live1.sdp specifica l'URL del flusso da riprodurre. Il server WebRTC richiederà i flussi dalla telecamera, li elaborerà e li invierà al browser per la riproduzione tramite WebRTC. Forse il tuo router supporta DDNS. In caso contrario, la telecamera IP stessa ha tale supporto:
Ed ecco come appare il supporto DDNS nel router stesso:
Ora puoi iniziare a testare e valutare i risultati.
Test
Dopo aver aperto il collegamento nel browser, viene stabilita una connessione al server WebRTC, che invia una richiesta alla telecamera IP per ricevere un flusso video. L'intero processo richiede pochi secondi.
A questo punto, il browser si connette al server tramite websocket, quindi il server richiede la telecamera IP tramite RTSP, riceve il flusso H.264 tramite RTP e lo transcodifica in VP8 / SRTP, che viene infine riprodotto dal browser WebRTC.
Nella parte inferiore del video viene visualizzato l'URL del flusso video, che può essere copiato e aperto per la visualizzazione da un altro browser o scheda.
Siamo convinti che questo sia davvero WebRTC.
All'improvviso siamo stati ingannati e il video della telecamera IP viene nuovamente inviato tramite HTTP? Non guardiamo pigramente l'immagine, ma controlliamo che tipo di traffico riceviamo effettivamente. Ovviamente, riavviamo Wireshark e la console di debug in Chrome. Nella console di Chrome del browser, possiamo osservare quanto segue:
Questa volta, niente sfarfallio e nessuna immagine è visibile, trasmessa su HTTP. Tutto ciò che vediamo questa volta sono frame Websocket e la maggior parte di essi sono tipi ping/pong per mantenere una sessione Websocket. Frame interessanti: connect, prepareRtspSession e onReadyToPlay: questo è l'ordine in cui viene stabilita una connessione al server: prima una connessione Websocket, quindi una richiesta di streaming per la riproduzione.
Ed ecco cosa mostra chrome://webrtc-internals
Secondo i grafici, abbiamo un bitrate dalla telecamera IP di 1Mbps. C'è anche traffico in uscita, molto probabilmente si tratta di pacchetti RTCP e ICE. RTT al server Amazon è di circa 300 millisecondi.
Ora diamo un'occhiata a Wireshark, il traffico UDP dall'indirizzo IP del server è chiaramente visibile lì. Nell'immagine sotto, pacchetti di 1468 byte. Questo è WebRTC. Più precisamente, i pacchetti SRTP trasportano frame video VP8, che possiamo osservare sullo schermo del browser. Inoltre, le richieste STUN vengono saltate (il pacchetto più basso nell'immagine): questo è WebRTC ICE che controlla attentamente la connessione.
Vale anche la pena notare la latenza relativamente bassa (il ping al data center era di circa 250 ms) della riproduzione video. WebRTC funziona su SRTP/UDP, che, qualunque cosa si possa dire, è il massimo modo veloce consegna dei pacchetti, al contrario di HTTP, RTMP e altri metodi di streaming simili a TCP. Quelli. la latenza vista dall'occhio dovrebbe essere RTT + buffering del browser, decodifica e tempo di riproduzione. Visivamente, in questo caso lo è: l'occhio quasi non vede il ritardo, è inferiore a 500 millisecondi.
Il prossimo test è connettere altri spettatori. Sono stato in grado di aprire 10 finestre di Chrome e ognuna di esse mostrava un'immagine. Allo stesso tempo, lo stesso Chrome ha iniziato a smussarsi un po'. Quando si apre l'undicesima finestra su un altro computer, la riproduzione è rimasta fluida.
Informazioni su WebRTC sui dispositivi mobili
Come sai, WebRTC è supportato dai browser Chrome e Firefox sulla piattaforma Android.Controlliamo se la nostra trasmissione verrà visualizzata lì:
Sull'immagine telefono htc, il video della videocamera viene visualizzato nel browser Firefox. Non ci sono differenze nella fluidità della riproduzione dal desktop.
Conclusione
Di conseguenza, siamo riusciti a lanciare una trasmissione in diretta WebRTC da una telecamera IP a diversi browser con il minimo sforzo. Non sono stati richiesti tamburelli o scienza missilistica: solo una conoscenza di base di Linux e della console SSH.La qualità della trasmissione era a un livello accettabile e il ritardo di riproduzione era invisibile agli occhi.
Riassumendo, possiamo dire che le trasmissioni WebRTC basate su browser hanno il diritto di esistere, perché. nel nostro caso WebRTC non è più una stampella o un plugin, ma una vera e propria piattaforma per la riproduzione di video nel browser.
Perché non vediamo l'adozione diffusa di WebRTC?
Il freno principale, forse, è la mancanza di codec. La comunità e i fornitori di WebRTC dovrebbero fare uno sforzo per introdurre il codec H.264 in WebRTC. Non c'è niente da dire contro VP8, ma perché rinunciare a milioni di dispositivi e software compatibili che funzionano con H.264? Brevetti, tali brevetti...In secondo luogo, non pieno supporto nei browser. Con IE e Safari, ad esempio, la questione rimane aperta e lì dovrai passare a un altro tipo di streaming o utilizzare un plugin come webrtc4all.
Quindi, in futuro, speriamo di vedere soluzioni più interessanti che non richiedano la transcodifica e la conversione dello streaming e la maggior parte dei browser sarà in grado di riprodurre gli streaming con vari dispositivi già direttamente.
Come verificare la possibilità di trasmissione Flusso RTSP da una telecamera IP in vari browser web
Controlliamo la visualizzazione del flusso video RTSP nei browser Chrome, Firefox, Safari su desktop con Windows, Mac OS X, Linux e dispositivi mobili con Android e iOS
Controllo del flusso RTSP in VLC
Per assicurarti rapidamente che lo stream RTSP sia disponibile e stia trasmettendo video in streaming, aprilo nel lettore VLC. Se lo stream viene riprodotto correttamente, si procede al test dell'interfaccia web. È possibile ottenere l'URL RTSP nel pannello di controllo della telecamera IP o utilizzare alcuni flussi video RTSP disponibili pubblicamente, come questo: rtsp://b1.dnsdojo.com:1935/live/sys3.stream
Test del flusso RTSP-WebRTC nei browser Google Chrome e MozillaFirefox
Ci assicuriamo che lo stesso flusso RTSP venga riprodotto su una normale pagina HTML in Browser Chrome e Firefox.
1. Scarica l'interfaccia demo su , menu "Demo / Streaming Min". Questa è un'interfaccia Web HTML5 minima che utilizza la tecnologia WebRTC per visualizzare un flusso video RTSP nei browser Chrome e Firefox.
2. Stabilire la connessione con Web Call Server
3. Immettere l'indirizzo RTSP della telecamera e avviare la riproduzione in streaming:
Di conseguenza, abbiamo controllato con successo la riproduzione del flusso RTSP Navigatore Google Cromo. Un test simile può essere eseguito con i browser Firefox e Opera su quelle piattaforme desktop e mobili che supportano la tecnologia WebRTC nei browser.
Test del flusso RTSP-Websocket in entrata Navigatore Safari per iOS e Mac OS X
I browser sui dispositivi iOS non supportano la tecnologia WebRTC. Per questo motivo viene utilizzato un lettore separato "WS Player Min", che prende lo stream tramite il protocollo Websocket e lo riproduce nell'elemento HTML5-Canvas del browser.
1. Come nel caso di Chrome, devi aprire la pagina dell'interfaccia demo, ma selezionare un'altra voce di menu:
2. Successivamente, stabilire una connessione con Web Call Server
3. Immettere l'indirizzo precedentemente noto della trasmissione RTSP e riprodurre il flusso video:
Pertanto, la possibilità di visualizzare il traffico RTSP convertito utilizzando Web Call Server sulla maggior parte dei comuni browser web, anche sulle piattaforme mobili più diffuse.
Il prossimo passo è aggiungere un lettore RTSP HTML5 al tuo sito web. Il processo di aggiunta è descritto in dettaglio nella sezione adiacente Implementazione.
Video che descrivono il processo di test del lettore RTSP-WebRTC e RTSP-Websocket
Lettore RTSP-WebRTC per Chrome e Firefox
Lettore Websocket RTSP per iOS Safari
Scarica Web Call Server 5
Requisiti di sistema: Linux x86_64, CPU 1 core, 2 Gb RAM, Java
Installazione:
- wget https://sitoweb/download-wcs5.2-server.tar.gz
- Disimballare e installare utilizzando lo script "install.sh".
- Avviare il server con il comando "service webcallserver start".
- Apri l'interfaccia web https://host:8444 e attiva la tua licenza
Se utilizzi i server Amazon EC2, non è necessario scaricare nulla.
Secondo alcuni dati, ad oggi, il mondo ha installato centinaia di milioni Telecamere IP per videosorveglianza. Tuttavia, non tutti, il ritardo nella riproduzione video è fondamentale. La videosorveglianza, di norma, 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 bene il loro lavoro.
In questo articolo, esamineremo un'applicazione leggermente diversa. Telecamere IP, vale a dire l'uso 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 processore e di un'interfaccia di rete propri. La webcam deve essere collegata a un computer, smartphone o altro dispositivo dotato di scheda di rete e processore.
Telecamera IPè un dispositivo autonomo dotato di scheda di rete e processore propri 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 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: aste di video dal vivo, video casinò con croupier dal vivo, programmi TV interattivi dal vivo con presentatore, telecomando quadricottero, ecc.
Un rivenditore 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 interlacciato.
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 a 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 interlacciato. 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 interlacciato più favorevole per la trasmissione di video con ritardo minimo, in quanto utilizza il protocollo RTP/UDP, ma allo stesso tempo è più problematico se il giocatore si trova dietro NAT.
Quando ci si connette alla telecamera IP di un lettore situata dietro NAT, il lettore deve sapere quali indirizzi IP e porte esterni 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 definiti gli indirizzi IP e le porte corretti, allora tutto funzionerà.
Quindi, per riprendere video dalla fotocamera con un ritardo minimo, è necessario utilizzare non intercalato modalità e ricevere il 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 fungerà da ponte tra i protocolli della telecamera IP ei protocolli del browser.
Il server prende il flusso dalla telecamera IP a se stesso tramite RTP/UDP e lo fornisce ai browser connessi tramite WebRTC.
La tecnologia WebRTC funziona secondo il protocollo UDP e quindi garantisce una bassa latenza nella direzione Server > Navigatore. La telecamera IP funziona anche sul protocollo RTP/UDP e fornisce una bassa latenza nella direzione Telecamera > 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 ridimensionare la trasmissione da una telecamera IP a grande numero spettatori.
Invece, 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.
Insidia n. 1 - Codec
I codec utilizzati possono essere un ostacolo alla bassa latenza e causare un degrado delle prestazioni complessive del sistema.Ad esempio, se una videocamera invia un flusso video a 720p in H.264 e un browser Chrome è connesso a Smartphone Android con supporto solo per 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 in VP8. In questo caso, un server dual-processor 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, la transcodifica dovrebbe essere evitata. Ad esempio, servi solo browser con supporto H.264 e offri il resto per l'uso nativo app mobile per iOS o Android, dove è presente il supporto per il codec H.264.
Come opzione per aggirare la transcodifica in un browser mobile, puoi utilizzare HLS. Ma lo streaming HTTP non è affatto a bassa latenza e attualmente 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 telecamera e il server, l'immagine potrebbe essere danneggiata.
Per eliminare le perdite, è necessario assicurarsi che il flusso video generato dalla telecamera abbia un bit rate che rientri nella larghezza di banda allocata tra la telecamera e il server.
Insidia n. 3 - Bitrate e perdita del visualizzatore
Ogni spettatore di trasmissione che si connette al server ha anche una certa larghezza di banda per il download.Se la telecamera IP invia un flusso che supera le capacità del canale del visualizzatore (ad esempio, la telecamera invia 1Mbps e lo spettatore può solo accettare 500 kbps), quindi ci saranno grandi perdite su questo canale e, di conseguenza, fregi video o forti artefatti.
In questo caso, ci sono tre opzioni:
- Transcodifica il flusso video individualmente per ciascun visualizzatore al bitrate richiesto.
- Transcodifica flussi non per ogni connesso, ma per un gruppo di un gruppo di spettatori.
- Prepara in anticipo i flussi dalla videocamera in diverse risoluzioni e bitrate.
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
- 1Mbps
Terza opzione comporta un completo rifiuto 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 un flusso all'altro in base alla loro larghezza di banda.
In questo caso, il carico di transcodifica sul server scompare e si sposta sulla telecamera stessa, perché la telecamera è ora costretta a codificare due o più flussi invece di uno.
Di conseguenza, abbiamo preso in considerazione tre opzioni per l'adattamento alla larghezza di banda degli spettatori. Se assumiamo che una sessione di transcodifica richieda 1 core del server, otteniamo la seguente tabella del carico della CPU:
La tabella mostra che possiamo trasferire il carico di transcodifica alla telecamera o trasferire la transcodifica al server. Le opzioni 2 e 3 sembrano essere le più ottimali.
Testare RTSP come WebRTC
È tempo di eseguire alcuni test per rivelare il quadro reale di ciò che sta accadendo. Prendiamo una vera telecamera IP e testiamola 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.
Poiché la fotocamera è rimasta a lungo in un armadio con altri dispositivi e cavi utili, ho dovuto inviarla a Ripristina tenendo premuto il pulsante sul retro della fotocamera per 10 secondi.
Dopo la connessione alla rete, sulla videocamera si è accesa una luce verde e il router ha rilevato l'ingresso di un altro dispositivo rete locale con indirizzo IP 192.168.1.37.
Andiamo all'interfaccia web della fotocamera e impostiamo i codec e la risoluzione per il test:
Successivamente, andiamo a impostazioni di rete e scopri l'indirizzo RTSP della telecamera. In questo caso, l'indirizzo RTSP live1.sdp, cioè. La fotocamera è disponibile su rtsp://192.168.1.37/live1.sdp
L'accessibilità della fotocamera può essere facilmente verificata con Lettore VLC. File multimediali: apri il flusso di rete.
Ci siamo assicurati che la videocamera 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 prendere il flusso video. Distribuisci ulteriormente il flusso di WebRTC.
Dopo l'installazione, è necessario impostare il server in modalità RTSP non interlacciato 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 servizio webcallserver
Pertanto, abbiamo un server che funziona secondo lo schema non interlacciato, riceve i pacchetti dalla telecamera IP tramite UDP e quindi li distribuisce tramite WebRTC (UDP).
Il server di prova si trova su un server VPS situato nel data center di Francoforte, ha 2 core e 2 gigabyte di RAM.
La telecamera si trova sulla rete locale all'indirizzo 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 indica al router di reindirizzare tutto il traffico in entrata sulla porta 554 alla 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 questo aspetto:
Per iniziare a riprodurre uno streaming 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 telecamera. Il server tenterà di stabilire una connessione a questo indirizzo.
Test di latenza VLC vs WebRTC
Dopo aver configurato la telecamera IP e testato VLC, configurare il server e testarlo RTSP flusso attraverso il server con distribuzione da parte di 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 il flusso video contemporaneamente VLC localmente e sul browser Firefox tramite un server remoto.
Eseguire il ping al server 100ms.
Eseguire il ping a livello locale 1ms.
Il primo test del timer si presenta così:
Su uno sfondo nero è il timer originale, che mostra zero ritardo. Sono partiti VLC, sulla destra Firefox ricezione WebRTC streaming da un server remoto.
| Zero | VLC | Firefox, WCS | |
| Volta | 50.559 | 49.791 | 50.238 |
| latenza ms | 0 | 768 | 321 |
Abbiamo effettuato alcuni scatti per acquisire i valori di ritardo.
RTSP (protocollo di streaming in tempo reale)è un protocollo di streaming in tempo reale che contiene un semplice insieme di comandi di base per controllare il 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 contenuti multimediali 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 media server. Ulteriori informazioni sulle trasmissioni RTSP.
Vantaggi dell'utilizzo di telecamere IP con le soluzioni software TrueConf
- Installando una telecamera IP in un ufficio o in un'officina industriale e collegandosi ad essa in qualsiasi momento opportuno, è possibile monitorare il processo produttivo della propria azienda.
- È possibile condurre 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 forniscono a tutti gli utenti la possibilità di registrare videoconferenze, grazie alle quali è possibile registrare eventuali eventi durante la videosorveglianza e riceverne prove documentali.
Comoda visualizzazione di trasmissioni video o può essere configurata utilizzando lettori multimediali software sul tuo personal computer. Oggi vedremo come impostare un flusso RTSP per apparecchiature di rete Dahua Technology in uno dei più popolari VLC Media Player.
RTSP (Real Time Streaming Protocol - protocollo di streaming in tempo reale) è un protocollo che consente all'utente di riprodurre in remoto un flusso di dati multimediali (audio e video) utilizzando un collegamento ipertestuale e un lettore multimediale (nel nostro caso, VLC Media Player).
Se devi configurare un flusso video, procedi nel seguente modo:
- Prima di tutto, devi scaricare e installare VLC Media Player, che è disponibile gratuitamente sul sito ufficiale.
- Fare clic sulla voce di menu Media (Media) - Apri flusso di rete (Apri URL).
- accedere Indirizzo di rete RTSP alla linea consultiva.
- Premere il pulsante di riproduzione quando l'immagine video appare sullo schermo.
Decrittazione dei collegamenti RTSP
Esempio:
rtsp:// :@:/cam/realmonitor?channel= &sottotipo=
Dove :
rtsp://amministratore: [e-mail protetta]:554/cam/realmonitor?channel=1&subtype=1
Le videocamere IP Dahua Technology supportano i protocolli di trasferimento dati TCP e UDP. Se la porta 554 è stata modificata, modificarla nel campo corrispondente delle impostazioni della telecamera (interfaccia web).
In caso di problemi con l'impostazione di un flusso RTSP, fare riferimento alla sezione appropriata.