Protocol Rtsp pentru camere ip. Difuzarea unui flux video de la o cameră IP utilizând WebRTC

Dacă întâmpinați dificultăți la configurarea sau utilizarea produsului, vă rugăm să consultați întrebările frecvente și întrebările frecvente.

Cum să obțineți licența cadou REVISOR VMS?

Urmați instrucțiunile pentru a obține licența cadou Revisor VMS. Descărcați instrucțiuni.

Am o cameră IP RedLine de 1,3 MP. Încerc să instalez ActiveX, dar primesc o eroare „HTTP 404 - Not Found”, ce ar trebui să fac?

Modulul ActiveX nu este încorporat în camerele video de 1,3 megapixeli, acesta trebuie instalat de pe discul care vine cu kit-ul sau descărcat din link

Pentru camere de 4MP:

rtsp://admin:123456@adresa-IP:554/ch01/0 - firul principal

rtsp://admin:123456@IP-address:554/ch01/1 - flux suplimentar

rtsp://admin:123456@adresa-IP:554/streaming/mjpeg - flux mjpeg

Pentru camere de 1,3 MP și 2 MP

rtsp://admin:123456@adresa-IP:554/streaming/video0 - fluxul principal

rtsp://admin:123456@IP-address:554/streaming/video1 - flux suplimentar

Ce software este potrivit pentru dispozitivele mobile?

Ce porturi sunt necesare pentru a funcționa prin rețea?

80 - interfață web

Flux 554-rtsp (video).

4900 - mob. port

9988 - Pentru conexiuni client la camere IP de 4MP

Ce ar trebui să fac dacă sunetul nu funcționează la reportofon sau în software-ul terță parte?

Pentru a transmite sunetul, trebuie să activați transmisia audio în setările din fila NETWORK - flux RTSP.

Cantitatea de spațiu ocupată depinde de calitatea înregistrării selectată și de frecvența mișcării (când se înregistrează prin detectare). Pentru a calcula arhiva, puteți utiliza software-ul Disk calculator.

Cum să găsiți o cameră IP într-o rețea locală?

Instalați software-ul și rulați ca administrator. În fereastra care apare, veți vedea o listă de echipamente conectate la rețeaua locală.

Pentru a modifica setările de rețea, selectați echipamentul în câmpul de sus și specificați setările rețelei (adresă IP, mască, gateway) în câmpul de jos, introduceți numele de utilizator, parola și faceți clic pe butonul Modificare. În viitor, trebuie să utilizați IP-ul specificat pentru a vă conecta.

Pentru camere IP de 1,3 MP și 2 MP recomandat de utilizat

Cum se adaugă o cameră IP de 1,3 MP la CVMS?

Dacă camera se află în rețeaua locală, atunci în modul vizualizare, în meniul Dispozitive (din stânga), faceți clic dreapta și selectați „Căutare rapidă”, apoi selectați camera dorită și specificați parola.

Dacă conexiunea se va face prin Internet, atunci în modul de vizualizare, în meniul Dispozitive (din stânga), faceți clic dreapta și selectați „Adăugați dispozitiv” și introduceți datele pentru conectare, TREBUIE SĂ SPECIFICA PORTUL TCP (implicit 1115)

Este posibil ca manualul care vine cu camera CCTV să nu conțină întotdeauna informații despre protocolul RTSP, conform căruia dispozitivul funcționează. Cu toate acestea, există un număr mare de cazuri când este necesară utilizarea acestui protocol, așa că devine necesară aflarea adresei acestuia.

Proprietarul unui sistem de supraveghere video poate avea nevoie să cunoască fluxul RTSP în diferite situații:

pentru a conecta camera video la serverul cloud;
pentru a configura transmiterea de informații video către site-ul web;
pentru a reda videoclipuri în fluxul playerului pe diferite dispozitive - telefon mobil, laptop sau tabletă.

Pentru ce este protocolul RTSP?

Numele protocolului RTSP se traduce prin control online. Astfel, Real Time Streaming Protocol ajută la gestionarea streamingului video online. Acest protocol este foarte des folosit în supravegherea video IP, deoarece conține o descriere a comenzilor necesare.

Protocolul RTSP permite proprietarului unei camere de securitate să rezolve câteva funcții importante:

date de difuzare folosind VLC;
difuzați videoclipuri către resursele și platformele dvs.;
configurați NVR-video recordere;
conectați o cameră de supraveghere video cu stocare virtuală;
adăugați o cameră video la aplicațiile mobile bazate pe Android sau iOS.

În același timp, nu este foarte ușor și destul de dificil pentru mulți utilizatori de sisteme de supraveghere video să deschidă un flux RTSP.

Aflați adresa RTSP a unei camere de supraveghere

Există mai multe opțiuni care vă permit să aflați fluxul RTSP al camerei video atunci când nu este specificat în instrucțiunile corespunzătoare.

Un număr mare de camere IP vândute în Rusia includ elemente XMEye chinezești. Aceste componente pot fi văzute chiar și la producătorii autohtoni de camere precum Vesta, HiQ, SVplus și altele asemenea. Camera unor astfel de modele va avea următorul format de flux RTSP:

rtsp://192.168.132.32:554/user=admin&password=12345&channel=1&stream=0.cgi

Această adresă conține componente precum:

192.168.132.32 – adresa IP directă a dispozitivului;
554 – port protocol (implicit are numărul 554, dar acest parametru poate fi modificat în setările dispozitivului);
admin - autentificarea camerei de supraveghere;
12355 – parola de conectare a utilizatorului.

În cazul în care alte componente sunt prezente în camera video IP, va trebui să utilizați una dintre cele două opțiuni enumerate mai jos.

Prima opțiune este cea mai simplificată. Pentru a afla fluxul RTSP de la o cameră de supraveghere, trebuie să contactați producătorul sau furnizorul acestui dispozitiv. La cerere, aceștia vor putea oferi formatul fluxului dorit și chiar și vânzătorii chinezi pot oferi acest serviciu - din fabrici din China sau site-ul AliExpress.

A doua opțiune este utilizarea software-ului specializat. Această metodă poate ajuta atunci când un non-proprietar al sistemului de supraveghere video nu are capacitatea sau dorința de a solicita adresa fluxului RTSP de la furnizor. Apoi o puteți face singur cu ajutorul unui software.

Mai întâi va trebui să descărcați un program numit One Device Manager. După instalare, acest software vă va ajuta să aflați adresa RTSP.

De regulă, majoritatea camerelor video acceptă protocolul onvif, așa că nu ar trebui să existe dificultăți la utilizarea software-ului. O nuanță importantă - pentru o funcționare corectă, trebuie să conectați un laptop sau un computer pe care va fi instalat programul, precum și dispozitivul IP în sine, la aceeași rețea locală.

Pe web, puteți găsi liste întregi care conțin adresele fluxurilor RTSP, deoarece aceste date depind de ce marcă produce camera de supraveghere video.

Cum se deschide un flux RTSP într-o cameră video?

Când adresa fluxului RTSP devine cunoscută proprietarului sistemului de urmărire, acesta poate primi informații video de la camera IP. Pentru a deschide o transmisie video în flux, va trebui să efectuați următoarea listă de pași:

setați o adresă IP permanentă pentru camera video și comandați-o de la un furnizor de internet;
transferați cererile locale venite de la camera video în portul RTSP;
trece un test de performanță.

O adresă statică poate fi configurată utilizând programul IP Hunter sau vă puteți contacta ISP-ul și le cereți să furnizeze o adresă IP permanentă ca opțiune suplimentară. După aceea, trebuie să configurați porturile de redirecționare și redirecționare către portul RTSP de la porturile locale ale camerei video. Apoi puteți trece la verificarea fluxului.

Pentru a înțelege dacă legătura RTSP funcționează, puteți deschide playerul VLC și îl verificați acolo. Pentru a face acest lucru, în meniul principal al playerului, trebuie să faceți clic pe categoria „Media” și să selectați elementul „Open URL”. Apoi, trebuie să accesați fila „Rețea” a ferestrei „Sursă” și să specificați linkul.

Rezolvarea problemei difuzării online de la o cameră IP, în general, nu necesită utilizarea WebRTC. Camera în sine este un server, are o adresă IP și poate fi conectată direct la un router pentru a distribui conținut video. Deci, de ce să folosiți tehnologia WebRTC?

Există cel puțin două motive pentru aceasta:

1. Pe măsură ce numărul de telespectatori ai unei transmisii Ethernet crește, mai întâi va exista o lipsă de grosime a canalului, iar apoi resursele camerei în sine.

2. După cum am menționat mai sus, camera IP este un server. Dar prin ce protocoale va putea ea să dea videoclipul browserului desktop? Dispozitiv mobil? Cel mai probabil va fi streaming HTTP, unde cadrele video sau imaginile JPEG sunt transmise prin HTTP. Streamingul HTTP nu este bine potrivit pentru streaming video în timp real, deși funcționează bine în videoclipurile la cerere, unde interactivitatea și latența în flux nu sunt deosebit de importante. De fapt, dacă vizionați un film, amânarea videoclipului cu câteva secunde nu va înrăutăți situația, cu excepția cazului în care vizionați filmul în același timp cu altcineva. "Oh nu! Jack a ucis-o! - Alice îi scrie un spoiler în chat lui Bob cu 10 secunde înainte de deznodământul tragic.

Sau va fi RTSP/RTP și H.264, caz în care un plugin pentru player video, cum ar fi VLC sau QuickTime, trebuie instalat în browser. Un astfel de plugin va prelua și va reda videoclipul, la fel ca playerul însuși. Dar avem cu adevărat nevoie de un streaming real bazat pe browser, fără a instala cârje / pluginuri suplimentare.

Mai întâi, să adulmecăm camera IP pentru a afla ce anume trimite acest dispozitiv către browser. Ca subiect de testare va exista o cameră D-Link DCS 7010L:

Puteți citi mai multe despre instalarea și configurarea camerei de mai jos, dar aici vom vedea doar ce folosește pentru streaming video. Când intri în panoul de administrare al camerei prin interfața web, vedem ceva de genul acesta (scuze pentru peisaj):

Imaginea se deschide în toate browserele și în mod uniform podlagivaet, aproximativ o dată pe secundă. Avand in vedere ca atat camera cat si laptopul pe care urmarim streamul sunt conectate la acelasi router, totul ar trebui sa fie lin si frumos, dar nu este asa. Similar cu HTTP. Rulați Wireshark pentru a confirma presupunerile noastre:

Aici vedem o secvență de fragmente TCP lungi de 1514 octeți

Și un HTTP 200 final OK cu lungimea JPEG primit:

Nu avem nevoie de acest streaming. Nu este fluid, atrage solicitări HTTP. Câte astfel de solicitări pe secundă poate rezista camera? Există motive să credem că la 10 spectatori și mai devreme, camera va fi îndoită în siguranță sau va începe să se defecteze îngrozitor și să dea diapozitive.

Dacă ne uităm la HTML-ul paginii de administrare a camerei, vom vedea următorul cod interesant:

Dacă(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=""; dacă (g_isIPv6) //pentru că ipv6 nu acceptă rtsp.var host = g_netip;else var host = g_host;o+=""; //alertă(o); DW(o); )

RTSP/RTP este exact ceea ce aveți nevoie pentru redarea corectă a videoclipurilor. Dar va funcționa într-un browser? - Nu. Dar dacă instalați pluginul QuickTime - totul va funcționa. Dar facem streaming pur bazat pe browser.

Aici poate fi menționat și Flash Player, care poate primi un flux RTMP convertit din RTSP, RTP, H.264 printr-un server adecvat precum Wowza. Dar Flash Player, după cum știți, este și un plugin de browser, deși este incomparabil mai popular decât VLC sau QuickTime.

În acest caz, vom testa aceeași re-streaming RTSP/RTP, dar un browser compatibil WebRTC va fi folosit ca dispozitiv de redare fără pluginuri suplimentare de browser și alte cârje. Vom configura un server de retransmisie care va prelua fluxul de la camera IP și îl va trimite pe Internet unui număr arbitrar de utilizatori care utilizează browsere activate pentru WebRTC.

Conectarea unei camere IP

După cum am menționat mai sus, pentru testare a fost aleasă o cameră IP simplă D-Link DCS-7010L. Criteriul cheie de selecție aici a fost suportul dispozitivului pentru protocolul RTSP, deoarece prin acesta serverul nostru va prelua fluxul video de la cameră.

Conectam camera la router cu cordonul de corecție inclus. După pornirea alimentării și conectarea la router, camera a luat o adresă IP prin DHCP, în cazul nostru a fost 192.168.1.34 (Dacă mergeți la setările routerului, veți vedea că dispozitivul DCS 7010L este conectat - acesta este aceasta). Este timpul să testăm camera.

Deschideți adresa IP specificată în browser 192.168.1.34 pentru a ajunge la interfața web pentru administratorul camerei. În mod implicit, nu există nicio parolă.

După cum puteți vedea, videoclipul de la cameră este difuzat corect în panoul de administrare. În același timp, se observă blocajele periodice. Acesta este ceea ce vom remedia folosind WebRTC.

Configurarea camerei

În primul rând, în setările camerei, dezactivăm autentificarea - ca parte a testării, vom oferi fluxul tuturor celor care solicită. Pentru a face acest lucru, în interfața web a camerei, accesați setările Configurare-Rețeași setați valoarea opțiunii Autentificare în Dezactivare.

În același loc, verificăm valoarea portului de protocol RTSP, implicit este 554. Formatul videoclipului transmis este determinat de profilul utilizat. Puteți seta până la trei dintre ele în cameră, noi îl vom folosi pe primul, live1.sdp - implicit este setat să folosească H.264 pentru video și G.711 pentru audio. Puteți modifica setările dacă este necesar în secțiune Configurare-Audio și Video.

Acum puteți verifica funcționarea camerei prin RTSP. Deschideți VLC Player (puteți folosi oricare altul care acceptă RTSP - QuickTime, Windows Media Player, RealPlayer etc.) și în dialogul Open URL setați adresa RTSP a camerei: rtsp://192.168.1.34/live1.sdp

Ei bine, totul funcționează așa cum ar trebui. Camera redă corect fluxul video în player prin protocolul RTSP.

Apropo, fluxul este reprodus destul de lin și fără artefacte. Ne așteptăm la același lucru de la WebRTC.

Instalare server

Deci, camera este instalată, testată cu playere desktop și gata de transmisie prin server. Folosind whatismyip.com, determinăm adresa IP externă a camerei. În cazul nostru a fost 178.51.142.223. Rămâne să îi spunem routerului că atunci când accesează prin RTSP pe portul 554, solicitările de intrare sunt transmise către camera IP.

Punem setările corespunzătoare în router...

...și verificați adresa IP externă și portul RTSP folosind telnet:

Telnet 178.51.142.223 554

După ce ne asigurăm că există un răspuns pe acest port, trecem la instalarea serverului WebRTC.

Un server virtual pe Centos pe 64 de biți pe Amazon EC2 va fi responsabil pentru găzduire.
Pentru a nu avea probleme de performanță, am ales instanța m3.medium cu un singur VCPU:

Da, da, există și Linode și DigitalOcean, dar în acest caz am vrut să Amazon.
Privind în viitor, voi scrie că în panoul de control Amazon EC2, trebuie să adăugați mai multe reguli (porturi înainte), fără de care exemplul nu va funcționa. Acestea sunt porturi pentru trafic WebRTC (SRTP, RTCP, ICE) și porturi pentru trafic RTSP/RTP. Dacă încercați, regulile Amazon ar trebui să aibă ceva similar pentru traficul de intrare:

Cu DigitalOcean, apropo, totul va fi mai ușor, doar deschideți aceste porturi pe firewall sau opriți-l pe acesta din urmă. Conform ultimei experiențe în operarea instanțelor DO, ei încă oferă o adresă IP statică și nu se deranjează cu NAT-urile, ceea ce înseamnă că redirecționarea portului, ca în cazul Amazon, nu este necesară.

Vom folosi Flashphoner WebRTC Media & Broadcasting Server ca un software de server care transmite un flux RTSP/RTP către WebRTC. Serverul de streaming este foarte asemănător cu Wowza, care poate transmite RTSP/RTP în Flash. Singura diferență este că acest flux va fi dat către WebRTC, nu Flash. Acestea. va trece un DTLS onest între browser și server, se va stabili o sesiune SRTP și fluxul codificat în VP8 va merge la vizualizator.

Avem nevoie de acces SSH pentru a instala.

Sub spoiler - o descriere detaliată a comenzilor executate

1. Descărcați arhiva de instalare a serverului:
$wget flashphoner.com/downloads/builds/WCS/3.0/x8664/wcs3_video_vp8/FlashphonerMediaServerWebRTC-3.0/FlashphonerMediaServerWebRTC-3.0.868.tar.gz
2. Desfăşurat:
$tar -xzf FlashphonerMediaServerWebRTC-3.0.868.tar.gz
3. Instalat:
$cd FlashphonerMediaServerWebRTC-3.0.868
$./install.sh
În timpul procesului de instalare a fost introdusă adresa IP externă a serverului: 54.186.112.111 și 172.31.20.65 intern (cel care este IP Privat).
4. A pornit serverul:
$service webcallserver pornire
5. Verificat jurnalele:
$tail - f /usr/local/FlashphonerWebCallServer/logs/server_logs/flashphoner.log
6. Ne-am asigurat că serverul a pornit și este gata de lucru:
$ps aux | grep Flashphoner
7. Apache instalat și lansat:
$yum instalează httpd
$service httpd start
8. A descărcat fișierele web și le-am plasat în folderul standard Apache /var/www/html
cd /var/www/html
$wget github.com/flashphoner/flashphoner_client/archive/wcs_media_client.zip
$unzip webrtc_media_client.zip
9. Introduceți adresa IP a serverului în configurația flashphoner.xml:
10. A oprit firewall-ul.
$service iptables se opreste

În teorie, în loc de punctul 10, ar fi corect să setăm toate porturile și regulile de firewall necesare, dar în scopuri de testare, am decis să dezactivăm pur și simplu firewall-ul.

Ajustarea serverului

Amintiți-vă că structura transmisiei noastre WebRTC este următoarea:

Am instalat deja elementele principale ale acestei diagrame, rămâne să stabilim „săgețile” interacțiunilor.

Conexiunea dintre browser și serverul WebRTC este asigurată de un client web, care este disponibil pe github :. Un set de fișiere JS, CSS și HTML este pur și simplu aruncat în /var/www/htmlîn etapa de instalare (vezi paragraful 9 de mai sus sub spoiler).

Interacțiunea dintre browser și server este configurată în fișierul XML de configurare flashphoner.xml. Trebuie să introduceți adresa IP a serverului acolo, astfel încât clientul web să se poată conecta la serverul WebRTC prin HTML5 Websockets (punctul 9 de mai sus).

Configurarea serverului se termină aici, puteți verifica funcționarea acestuia:

Deschidem pagina client web index.html în browser (pentru aceasta, Apache a fost instalat pe același server Amazon cu comanda yum -y instalează httpd):

54.186.112.111/wcs_media_client/?id=rtsp://webrtc-ipcam.ddns.net/live1.sdp

Aici webrtc-ipcam.ddns.net este un domeniu gratuit obținut prin serverul DNS dinamic noip.com , care se referă la adresa noastră IP externă. I-am spus routerului să redirecționeze cererile RTSP către 192.168.1.34 conform regulilor NAT (vezi și mai sus).
Parametru id=rtsp://webrtc-ipcam.ddns.net/live1.sdp specifică adresa URL a fluxului de redat. Serverul WebRTC va solicita fluxuri de la cameră, le va procesa și le va trimite browserului pentru redare prin WebRTC. Poate că routerul tău acceptă DDNS. Dacă nu, atunci camera IP în sine are un astfel de suport:

Și așa arată suportul DDNS în router însuși:

Acum puteți începe să testați și să evaluați rezultatele.

Testare

După deschiderea linkului în browser, se realizează o conexiune la serverul WebRTC, care trimite o solicitare camerei IP pentru a primi un flux video. Întregul proces durează câteva secunde.

În acest moment, browserul se conectează la server prin intermediul socket-urilor web, apoi serverul solicită camera IP prin RTSP, primește fluxul H.264 prin RTP și îl transcodează în VP8 / SRTP - care este redat în cele din urmă de browserul WebRTC.

În partea de jos a videoclipului, este afișată adresa URL a fluxului video, care poate fi copiată și deschisă pentru vizionare din alt browser sau filă.

Suntem convinși că acesta este într-adevăr WebRTC.

Dintr-o dată, am fost înșelați, iar videoclipul de la camera IP este din nou trimis prin HTTP? Să nu ne uităm cu mâna pe poză, ci să verificăm ce fel de trafic primim de fapt. Desigur, pornim din nou Wireshark și consola de depanare în Chrome. În consola Chrome a browserului, putem observa următoarele:

De data aceasta nu există nicio pâlpâire și nicio imagine HTTP nu este vizibilă. Tot ce vedem de data aceasta sunt cadre Websocket și cele mai multe dintre ele sunt tipuri de ping/pong pentru a menține o sesiune Websocket. Cadre interesante: connect, prepareRtspSession și onReadyToPlay - aceasta este ordinea în care se stabilește o conexiune la server: mai întâi o conexiune Websocket și apoi o cerere de stream pentru redare.

Și iată ce arată chrome://webrtc-internals

Conform graficelor, avem un bitrate de la camera IP de 1Mbps. Există și trafic de ieșire, cel mai probabil acestea sunt pachete RTCP și ICE. RTT pentru serverul Amazon este de aproximativ 300 de milisecunde.

Acum să ne uităm la Wireshark, traficul UDP de la adresa IP a serverului este clar vizibil acolo. În imaginea de mai jos, pachete de 1468 de octeți. Acesta este WebRTC. Mai exact, pachetele SRTP poartă cadre video VP8, pe care le putem observa pe ecranul browserului. În plus, solicitările STUN omit (cel mai mic pachet din imagine) - acesta este WebRTC ICE care verifică cu atenție conexiunea.

De asemenea, merită remarcată latența relativ scăzută (ping-ul către centrul de date a fost de aproximativ 250 ms) a redării video. WebRTC funcționează prin SRTP/UDP, care este cea mai rapidă modalitate de a livra pachete, spre deosebire de HTTP, RTMP și alte metode de streaming asemănătoare TCP. Acestea. latența văzută de ochi ar trebui să fie RTT + buffering-ul browserului, timpul de decodare și redare. Vizual, în acest caz este - ochiul aproape că nu vede întârzierea, este mai mică de 500 de milisecunde.

Următorul test este conectarea altor spectatori. Am putut deschide 10 ferestre Chrome și fiecare dintre ele arăta o imagine. În același timp, Chrome însuși a început să se tocească puțin. La deschiderea celei de-a 11-a ferestre pe alt computer, redarea a rămas fără probleme.

Despre WebRTC pe dispozitive mobile

După cum știți, WebRTC este acceptat de browserele Chrome și Firefox pe platforma Android.
Să verificăm dacă emisiunea noastră va fi afișată acolo:

În imaginea telefonului HTC, videoclipul de la cameră este afișat în browserul Firefox. Nu există diferențe în ceea ce privește fluiditatea redării de pe desktop.

Concluzie

Drept urmare, am reușit să lansăm o transmisie WebRTC live de la o cameră IP către mai multe browsere cu un efort minim. Nu au fost necesare tamburine sau știință rachetă - doar cunoștințe de bază despre Linux și consola SSH.

Calitatea difuzării a fost la un nivel acceptabil, iar întârzierea redării era invizibilă pentru ochi.

Rezumând, putem spune că emisiunile WebRTC bazate pe browser au dreptul de a exista, deoarece. în cazul nostru, WebRTC nu mai este o cârjă sau un plugin, ci o adevărată platformă pentru redarea videoclipurilor în browser.

De ce nu vedem adoptarea pe scară largă a WebRTC?

Frâna principală, probabil, este lipsa codecurilor. Comunitatea WebRTC și furnizorii ar trebui să facă un efort pentru a introduce codecul H.264 în WebRTC. Nu există nimic de spus împotriva VP8, dar de ce să renunți la milioane de dispozitive și software compatibile care funcționează cu H.264? Brevete, astfel de brevete...

În al doilea rând, nu suport complet în browsere. Cu IE și Safari, de exemplu, întrebarea rămâne deschisă și acolo va trebui să treci la alt tip de streaming sau să folosești un plugin precum webrtc4all.

Așadar, în viitor, sperăm să vedem mai multe soluții interesante care nu vor necesita transcodare și conversie a fluxului, iar majoritatea browserelor vor putea reda fluxuri de pe diverse dispozitive direct.