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 folosit foarte des î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 unui software 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ă.
Listele întregi pot fi găsite pe web 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, va exista mai întâi o lipsă tot mai mare de grosime a canalului și apoi de 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 foarte potrivit pentru streaming video în timp real, deși funcționează bine pentru videoclipuri 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 trebuie instalat în browser un plugin de player video precum VLC sau QuickTime. 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 în 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 releu care va prelua fluxul de la camera IP și îl va trimite pe Internet unui număr arbitrar de utilizatori care utilizează browsere compatibile cu 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 difuzare 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 către Flash. Acestea. va trece un DTLS onest între browser și server, se va stabili o sesiune SRTP și fluxul codificat în VP8 va ajunge 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. Verificați 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 de traducere a adresei de rețea 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 trimis din nou 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, nimic nu pâlpâie și nicio imagine nu este vizibilă, transmisă prin HTTP. Tot ce vedem de data aceasta sunt cadre Websocket și majoritatea 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
Ca rezultat, am reușit să lansăm o transmisie WebRTC live de la o cameră IP către mai multe browsere cu 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ă de redare a videoclipurilor în browser.
De ce nu vedem adoptarea pe scară largă a WebRTC?
Frâna principală, poate, 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 fluxurilor, iar majoritatea browserelor vor putea reda fluxuri de pe diverse dispozitive direct.
Apare adesea întrebarea: Cum se conectează o cameră ip la NVR dacă nu este în lista de compatibilitate?
Există două opțiuni ONVIF și RTSP
Să începem cu protocolul ONVIF (Open Network Video Interface Forum).
ONVIF este un protocol comun pentru interoperabilitatea camerelor IP, NVR-urilor, software-ului, în cazul în care toate dispozitivele sunt de la diferiți producători. ONVIF poate fi comparat cu limba engleză pentru comunicarea internațională între oameni.
Asigurați-vă că dispozitivele conectate acceptă ONVIF, pe unele dispozitive ONVIF poate fi dezactivat implicit.
Sau autorizarea ONVIF poate fi dezactivată, ceea ce înseamnă că login/parola va fi întotdeauna implicită
indiferent de autentificare/parolă pentru WEB 
De asemenea, este de remarcat faptul că unele dispozitive folosescport separat pentru lucru sub protocolul ONVIF
În unele cazuri, parola ONVIF poate diferi de parola pentru accesul WEB.
Ce este disponibil atunci când este conectat prin ONVIF?
Descoperirea dispozitivului
Transfer de date video
Recepția și transmiterea datelor audio
control PTZ (PTZ)
Analize video (de exemplu, detectarea mișcării)
Aceste opțiuni depind de compatibilitatea versiunilor de protocol ONVIF. În unele cazuri, unii dintre parametri nu sunt disponibili sau funcționează incorect.
K și folosind ONVIF
În înregistratoarele SNR și Dahua, protocolul ONVIF se află în fila Dispozitiv la distanță, linia Producător
Selectați canalul la care va fi conectat dispozitivul
Din fila Producător, selectați ONVIF
Specifica adresa IP dispozitive
RTSP portul rămâne implicit
Utilizarea camerelor ONVIF portul 8080
(din 2017, pe modelele noi ONVIF, portul a fost schimbat la 80 pentru seria Alpha, Mira)
Camere OMNY Baza utilizare ONVIF portul 80, în registrator este specificat ca port HTTP
Nume
Parola conform parametrilor dispozitivului
canal la distanță implicit este 1. Dacă dispozitivul este multicanal, este indicat numărul canalului.
Buffer decodor— tamponarea fluxului video cu valoarea timpului
tip de serverexistă o alegere între TCP, UDP Schedule
TCP- stabileste o legatura intre expeditor si destinatar, se asigura ca toate datele ajung fara modificari la destinatar si in ordinea dorita, regleaza si viteza de transmisie.
Spre deosebire de TCP, UDP nu stabilește o conexiune preliminară, ci pur și simplu începe transmiterea datelor. UDP nu ține evidența datelor primite și nu le dublează în caz de pierdere sau eroare.
UDP este mai puțin fiabil decât TCP. Dar, pe de altă parte, oferă streaming mai rapid din cauza absenței retransmiterii pachetelor pierdute.
Programa— detectarea automată a tipului.
Așa arată dispozitivele conectate în Dahua
Starea verde înseamnă că DVR-ul și camera sunt conectate cu succes
Starea roșie înseamnă că există probleme de conexiune. De exemplu, portul de conectare este incorect.
Al doilea mod de conectare este RTSP(Protocol de streaming în timp real) 
RTSPun protocol de streaming în timp real care descrie comenzi pentru controlul unui flux video.
Cu ajutorul acestor comenzi, fluxul video este difuzat de la sursă la destinatar.
de exemplu de la o cameră IP la un DVR sau un server.
Ce este disponibil la conectarea prin RTSP?
Transfer de date video
Recepția și transmiterea datelor audio
avantaja acestui protocol de transfer, deoarece nu necesită compatibilitate cu versiunea.
Astăzi, RTSP este acceptat de aproape toate camerele IP și NVR-urile.
dezavantaje protocolul este că nimic altceva nu este disponibil cu excepția transmiterii de date video și audio.
Să ne uităm la un exemplu de conectare a unei camere la și folosind RTSP
.jpg)
RTSP situat pe fila Dispozitiv la distanță, linia Producător, în registratorul SNR și Dahua este prezentat caGeneral
Selectați canalul la care va fi conectat dispozitivul
Adresă URL- aici introducem sirul de interogare prin care revine camera de bază Flux RTSP de la înalt rezoluţie.
URL suplimentar - Aici introduceți șirul de interogare prin care se întoarce camera adiţional Flux RTSP de la rezolutie scazuta.
Exemplu de solicitare:
rtsp://172.16.31.61/1 flux principal
rtsp://172.16.31.61/2 flux suplimentar
De ce aveți nevoie de un flux suplimentar?
Pe un monitor local conectat la un reportofon cu mai multe imagini, reportofonul folosește un fir suplimentar pentru a economisi resurse. De exemplu, în imaginile mici de 16 ferestre nu este deloc necesară decodarea rezoluției Full HD, D1 este suficient. Ei bine, dacă ați deschis ferestre 1/4/8 în acest caz, fluxul principal este decodat cu rezoluție înaltă.
Numeconform parametrilor dispozitivului
Parola conform parametrilor dispozitivului
Buffer decodortamponarea fluxului video cu valoarea timpului
tip de server- TCP, UDP, Schedule (similar cu protocolul ONVIF)
Acest articol răspunde la cele mai frecvente întrebări, cum ar fi:
Camera IP este compatibilă cu NVR-ul?
Și dacă este compatibil, cum se conectează !?
Protocolul RTSP
RTSP (Protocol de streaming în timp real sau, în rusă, protocol de streaming în timp real) este un protocol de aplicație care descrie comenzi pentru controlul unui flux video. Cu aceste comenzi, putem „ordona” camerei sau serverului, de exemplu, să înceapă difuzarea unui flux video. Un exemplu de solicitare de pornire a redării arată astfel: PLAY rtsp://192.168.0.200/h264 RTSP/1.0
Adică, RTSP este doar un set de comenzi pentru controlul fluxului video. Să facem un experiment. Pentru a face acest lucru, avem nevoie de o cameră IP care acceptă protocolul RTSP și adresa sa RTSP. Această adresă arată cam așa rtsp://
Protocolul TCP
Să presupunem că am ales metoda RSTP peste TCP și dorim să începem să transmitem un flux video. Ce se va întâmpla la nivelul mecanismelor de transport? In prealabil, cu ajutorul mai multor comenzi, se va stabili o legatura intre expeditor si destinatar. După aceea, va începe transferul de date video. În același timp, mecanismele TCP
se va asigura că toate datele ajung la destinatar neschimbate și în ordinea corectă. De asemenea, TCP va regla rata de transmisie, astfel încât transmițătorul să nu trimită date mai intens decât le poate procesa receptorul, de exemplu,
UDP este o alternativă la protocolul de transport TCP. Spre deosebire de TCP, UDP nu stabilește o pre-conectare, ci pur și simplu începe să transmită date. UDP nu se asigură că datele sunt primite și nu le dublează dacă piese lipsesc sau primite cu erori. UDP mai puțin
fiabil decât TCP. Dar, pe de altă parte, oferă streaming mai rapid datorită absenței unui mecanism de retransmitere a pachetelor pierdute. Diferența dintre protocoalele TCP și UTP poate fi ilustrată prin următorul exemplu. Doi prieteni se întâlnesc. Opțiunea TCP:
Ivan: Buna! Să stăm de vorbă?” (conexiunea este stabilită)
Simon: „Bună! Haideti!" (conexiunea este stabilită)
Ivan: „Ieri am fost în magazin. Înțelegi?" (transfer de date)
Simon: "Da!" (confirmarea)
Ivan: „Descărcau echipamente noi. Înțelegi?" (transfer de date)
Semyon: „Nu” (confirmare)
Ivan: „Descărcau echipamente noi. Înțelegi?" (retransmisie)
Simon: "Da!" (confirmarea)
Ivan: „Mâine voi fi din nou acolo. Înțelegi?" (transfer de date)
Simon: "Da!" (confirmarea)
Varianta UDP
Ivan: Buna! Am fost ieri la magazin” (transmitere de date)
Ivan: „Descărcau echipamente noi” (transmitere de date)
Ivan: „Mâine voi fi din nou acolo” (transmitere de date)
Ivan: „Pot să-ți aduc prețuri” (transmitere de date)
Ivan: „Au promis reduceri pentru volume bune” (transmitere de date)
Ivan: „Dacă vrei, sună – mergem împreună” (transmitere de date)
Semyon: „Da, o să sun” (transmitere de date)
De asemenea, puteți vedea diferența dintre protocoale făcând următorul experiment: încercați să setați camera la modul RTSP prin TCP și fluturați mâna în fața obiectivului - veți vedea o întârziere pe ecranul monitorului. Acum rulați același test în RTSP prin modul UDP. Întârzierea va fi mai mică. Mai mulți factori afectează timpul de întârziere: formatul de compresie, puterea computerului, protocolul de transmisie și caracteristicile software-ului implicat în decodarea video.
RTP (Protocol de transport în timp real) sau protocol de transport în timp real în limba rusă. Acest protocol este conceput special pentru a transmite trafic în timp real. Vă permite să monitorizați sincronizarea datelor transmise, să ajustați secvența de livrare a pachetelor și, prin urmare, este mai potrivit decât altele pentru transmiterea datelor video și audio. În general, este de preferat să utilizați fie RTP, fie UDP pentru a transmite un flux video. Lucrul prin TCP este justificat doar dacă trebuie să lucrăm cu rețele problematice, deoarece protocolul TCP va putea corecta erorile și eșecurile care apar în timpul transferului de date.
Cum să verificați capacitatea de a difuza un flux RTSP de la o cameră IP în diferite browsere web
Să verificăm afișarea fluxului video RTSP în browserele Chrome, Firefox, Safari pe desktop-uri cu Windows, Mac OS X, Linux și dispozitive mobile care rulează Android și iOS
Verificarea fluxului RTSP în VLC
Pentru a vă asigura rapid că fluxul RTSP este disponibil și transmite în flux video, deschideți-l în playerul VLC. Dacă fluxul este reprodus corect, trecem la testarea interfeței web. Puteți obține adresa URL RTSP în panoul de control al camerei IP sau puteți utiliza un flux video RTSP disponibil public, cum ar fi acesta: rtsp://b1.dnsdojo.com:1935/live/sys3.stream
Testarea fluxului RTSP-WebRTC în browserele Google Chrome și Mozilla Firefox
Ne asigurăm că același flux RTSP este redat pe o pagină HTML obișnuită în browserele Chrome și Firefox.
1. Descărcați interfața demo de la , meniul „Demo / Streaming Min”. Aceasta este o interfață web HTML5 minimă care utilizează tehnologia WebRTC pentru a afișa un flux video RTSP în browserele Chrome și Firefox.
2. Stabiliți conexiunea cu Web Call Server
3. Introduceți adresa RTSP a camerei și începeți redarea fluxului:
Drept urmare, am testat cu succes redarea unui flux RTSP în browserul Google Chrome. Un test similar poate fi făcut cu browserele Firefox și Opera pe acele platforme desktop și mobile care acceptă tehnologia WebRTC în browsere.
Testarea fluxului RTSP-Websocket în browserul Safari sub iOS și Mac OS X
Browserele de pe dispozitivele iOS nu acceptă tehnologia WebRTC. Din acest motiv, se folosește un player separat „WS Player Min”, care preia fluxul prin protocolul Websocket și îl redă în elementul HTML5-Canvas al browserului.
1. Ca și în cazul Chrome, trebuie să deschideți pagina de interfață demonstrativă, dar selectați un alt element de meniu:
2. După aceea, stabiliți o conexiune cu Web Call Server
3. Introduceți adresa cunoscută anterior a transmisiei RTSP și redați fluxul video:
Astfel, capacitatea de a vizualiza traficul convertit utilizând Web Call Server RTSP pe majoritatea browserelor web obișnuite, inclusiv pe cele mai populare platforme mobile, a fost demonstrată mai sus.
Următorul pas este să adăugați un player HTML5 RTSP pe propriul site web. Procesul de adăugare este descris în detaliu în secțiunea adiacentă Implementare.
Videoclipuri care descriu procesul de testare a playerului RTSP-WebRTC și RTSP-Websocket
Player RTSP-WebRTC pentru Chrome și Firefox
RTSP Websocket Player pentru iOS Safari
Descărcați Web Call Server 5
Cerințe de sistem: Linux x86_64, 1 nucleu CPU, 2 Gb RAM, Java
Instalare:
- wget https://website/download-wcs5.2-server.tar.gz
- Dezambalați și instalați folosind scriptul „install.sh”.
- Porniți serverul cu comanda „service webcallserver start”.
- Deschideți interfața web https://host:8444 și activați-vă licența
Dacă utilizați servere Amazon EC2, nu trebuie să descărcați nimic.
