Vizualizați camere ip prin rtsp. Supraveghere video RTSP

Potrivit unor date, până în prezent, lumea s-a instalat sute de milioane Camere IP pentru supraveghere video. Cu toate acestea, departe de toate, întârzierea redării video este critică. Supravegherea video, de regulă, are loc „static” - fluxul este înregistrat în depozit și poate fi analizat pentru mișcare. Pentru supravegherea video au fost dezvoltate multe soluții software și hardware care își fac treaba bine.

În acest articol, ne vom uita la o aplicație ușor diferită. camere IP, și anume utilizarea în emisiuni online, acolo unde este necesar întârziere redusă de comunicare.

În primul rând, să lămurim o posibilă neînțelegere în terminologia despre camerele web și camerele IP.

Cameră web este un dispozitiv de captură video care nu are propriul procesor și interfață de rețea. Camera web necesită conectarea la un computer, smartphone sau alt dispozitiv care are o placă de rețea și un procesor.

Cameră IP este un dispozitiv autonom care are propria placă de rețea și procesor pentru a comprima videoclipul capturat și a-l trimite în rețea. Astfel, camera IP este un mini-computer de sine stătător care se conectează complet la rețea și nu trebuie să fie conectată la un alt dispozitiv și poate transmite direct în rețea.

Latenta scazuta(latența scăzută) este o cerință destul de rară pentru camerele IP și transmisiile online. Necesitatea de a lucra cu latență scăzută apare, de exemplu, dacă sursa fluxului video interacționează activ cu spectatorii acestui flux.

Cel mai adesea, este necesară o latență scăzută în cazurile de utilizare a jocurilor. Exemplele includ: licitație video în timp real, cazinou video cu dealer live, emisiune TV interactivă online cu o gazdă, control de la distanță a unui quadcopter etc.

Un dealer de cazinou online live la locul de muncă.

O cameră IP RTSP obișnuită, de regulă, presează videoclipul H.264 codec și poate funcționa în două moduri de transport de date: intercalatȘi neintercalat.

Modul intercalat cel mai popular și convenabil, deoarece în acest mod, datele video sunt transmise prin protocolul TCP în cadrul conexiunii de rețea la cameră. Pentru a distribui de la o cameră IP la intercalată, trebuie doar să deschideți / redirecționați un port RTSP al camerei (de exemplu, 554) către exterior. Jucătorul trebuie doar să se conecteze la cameră prin TCP și să preia fluxul deja în interiorul acestei conexiuni.

Al doilea mod de operare al camerei este neintercalat. În acest caz, conexiunea se stabilește folosind protocolul RTSP/TCP, iar traficul merge deja separat, conform protocolului RTP/UDPîn afara canalului TCP creat.

Modul neintercalat mai favorabil pentru difuzarea video cu întârziere minimă, deoarece utilizează protocolul RTP/UDP, dar în același timp este mai problematic dacă jucătorul este situat în spate NAT.

Când se conectează la camera IP a unui jucător situată în spatele NAT, jucătorul trebuie să știe ce adrese IP și porturi externe poate folosi pentru a primi trafic audio și video. Aceste porturi sunt specificate în textul SDP config care este trimis către cameră atunci când se stabilește o conexiune RTSP. Dacă NAT-ul a fost deschis corect și sunt definite adresele IP și porturile corecte, atunci totul va funcționa.

Deci, pentru a realiza videoclipuri de la cameră cu întârziere minimă, trebuie să utilizați non-interleave modul și primiți trafic video prin UDP.

Browserele nu acceptă direct stiva de protocoale RTSP/UDP, dar acceptă stiva de protocoale de tehnologie încorporată WebRTC.

Tehnologiile browserului și ale camerei sunt foarte asemănătoare, în special SRTP este criptat RTP. Dar pentru distribuirea corectă către browsere, o cameră IP ar avea nevoie de suport parțial pentru stiva WebRTC.

Pentru a elimina această incompatibilitate, este necesar un server de releu intermediar, care va fi o punte între protocoalele camerei IP și protocoalele browserului.

Serverul preia fluxul de la camera IP la sine RTP/UDPși îl oferă browserelor conectate prin WebRTC.

Tehnologia WebRTC funcționează conform protocolului UDPși asigură astfel o latență scăzută în direcție Server > Browser. Camera IP funcționează și pe protocol RTP/UDPși oferă o latență scăzută în direcție Cameră > Server.

Camera poate oferi un număr limitat de fluxuri, datorită resurselor și lățimii de bandă limitate. Utilizarea unui server intermediar vă permite să scalați transmisia de la o cameră IP la un număr mare de telespectatori.

Pe de altă parte, când se utilizează serverul, sunt activate două segmente de comunicare:
1) Între spectatori și server
2) Între server și cameră
O astfel de topologie are o serie de „trăsături” sau „capcane”. Le enumerăm mai jos.

Capcana #1 - Codec-uri

Codecurile utilizate pot fi un obstacol în calea latenței scăzute și pot provoca o degradare a performanței generale a sistemului.

De exemplu, dacă camera oferă un flux video de 720p în H.264 și un browser Chrome este conectat la un smartphone Android care acceptă doar VP8.

Când transcodarea este activată, trebuie creată o sesiune de transcodare pentru fiecare dintre camerele IP conectate, care decodifică H.264și codifică în VP8. În acest caz, un server cu dublu procesor cu 16 nuclee va putea deservi doar 10-15 camere IP, cu un calcul aproximativ de 1 cameră pe nucleu fizic.

Prin urmare, dacă capacitățile serverului nu permit transcodarea numărului planificat de camere, atunci transcodarea ar trebui evitată. De exemplu, serviți numai browsere cu suport H.264 și oferiți-le pentru restul să folosească o aplicație mobilă nativă pentru iOS sau Android, unde există suport pentru codecul H.264.

Ca opțiune pentru a ocoli transcodarea într-un browser mobil, puteți utiliza HLS. Dar streamingul HTTP nu are deloc o latență scăzută și nu poate fi utilizat în prezent pentru streaming interactiv.

Capcana #2 - Rata de biți și pierderea camerei

Protocolul UDP ajută la a face față întârzierii, dar permite pierderea pachetelor video. Prin urmare, în ciuda latenței scăzute, cu pierderi mari de rețea între cameră și server, imaginea poate fi coruptă.

Pentru a elimina pierderile, trebuie să vă asigurați că fluxul video generat de cameră are o rată de biți care se încadrează în lățimea de bandă alocată între cameră și server.

Capcana #3 - Rata de biți și pierdere a vizualizatorului

Fiecare vizualizator de difuzare care se conectează la server are, de asemenea, o anumită lățime de bandă de descărcare.

Dacă camera IP trimite un flux care depășește capacitățile canalului de vizualizare (de exemplu, camera trimite 1 Mbps, iar spectatorul poate doar să accepte 500 kbps), atunci vor exista pierderi mari pe acest canal și, ca urmare, frize video sau artefacte puternice.

În acest caz, există trei opțiuni:

1. Transcodează fluxul video individual pentru fiecare spectator la rata de biți necesară.
2. Transcodificarea fluxurilor nu pentru fiecare conectat, ci pentru un grup dintr-un grup de spectatori.
3. Pregătiți în avans fluxurile de la cameră în mai multe rezoluții și rate de biți.

Prima varianta cu transcodare pentru fiecare vizualizator nu este potrivit, deoarece va folosi resursele CPU deja cu 10-15 vizualizatori conectați. Deși trebuie menționat că această opțiune oferă flexibilitate maximă cu sarcina maximă a CPU. Acestea. acest lucru este ideal, de exemplu, dacă transmiteți în flux la doar 10 persoane distribuite geografic, fiecare dintre ele primește un bitrate dinamic și fiecare dintre ei are nevoie de o întârziere minimă.

A doua varianta este de a reduce sarcina CPU-ului serverului folosind grupuri de transcodare. Serverul creează mai multe grupuri după rata de biți, de exemplu două:

• 200 Kbps
• 1 Mbps

Dacă spectatorul nu are suficientă lățime de bandă, trece la grupul în care poate primi confortabil fluxul video. Astfel, numărul de sesiuni de transcodare nu este egal cu numărul de telespectatori ca în primul caz, ci este un număr fix, de exemplu 2, dacă se transcodează grupuri. Două.

A treia opțiune implică o respingere completă a transcodării pe partea de server și utilizarea fluxurilor video deja pregătite în diferite rezoluții și rate de biți. În acest caz, camera este configurată să scoată două sau trei fluxuri cu rezoluții și rate de biți diferite, iar telespectatorii comută între aceste fluxuri în funcție de lățimea de bandă.

În acest caz, sarcina de transcodare de pe server dispare și trece la camera în sine, deoarece camera este acum forțată să codifice două sau mai multe fluxuri în loc de unul.

Drept urmare, am luat în considerare trei opțiuni pentru ajustarea la lățimea de bandă a telespectatorilor. Dacă presupunem că o sesiune de transcodare necesită 1 nucleu de server, atunci obținem următorul tabel de încărcare CPU:

Tabelul arată că putem transfera încărcarea de transcodare către cameră sau să transferăm transcodarea pe server. Opțiunile 2 și 3 par a fi cele mai optime.

Testarea RTSP ca WebRTC

Este timpul să rulați câteva teste pentru a dezvălui imaginea reală a ceea ce se întâmplă. Să luăm o cameră IP reală și să o testăm pentru a măsura latența de difuzare.

Să luăm o cameră IP veche pentru testare D-link DCS-2103 cu sprijinul RTSPși codecuri H.264 și G.711.

Deoarece camera a stat mult timp într-un dulap cu alte dispozitive și fire utile, a trebuit să o trimit la resetare apăsând și menținând apăsat butonul de pe spatele camerei timp de 10 secunde.

După conectarea la rețea, ledul verde de pe cameră s-a aprins și routerul a văzut un alt dispozitiv din rețeaua locală cu o adresă IP de 192.168.1.37.

Mergem la interfața web a camerei și setăm codecurile și rezoluția pentru testare:

Apoi, accesați setările de rețea și aflați adresa RTSP a camerei. În acest caz, adresa RTSP live1.sdp, adică Camera este disponibilă la rtsp://192.168.1.37/live1.sdp

Accesibilitatea camerei poate fi verificată cu ușurință player VLC. Media - Deschideți fluxul de rețea.

Ne-am asigurat că camera funcționează și dă video prin RTSP.

Vom folosi Web Call Server 5 ca server pentru testare. Acesta este un server de streaming cu suport RTSP și WebRTC protocoale. Se va conecta la camera IP prin RTSPși luați fluxul video. Distribuiți în continuare fluxul prin WebRTC.

După instalare, trebuie să comutați serverul în modul RTSP neintercalat despre care am discutat mai sus. Acest lucru se poate face prin adăugarea setării

rtsp_interleaved_mode=fals
Această setare este adăugată la configurația flashphoner.properties și necesită o repornire a serverului:

Reporniți serviciul webcallserver
Astfel, avem un server care funcționează conform schemei non-interleaved, primește pachete de la camera IP prin UDP și apoi le distribuie prin WebRTC (UDP).

Serverul de testare este situat pe un server VPS situat în centrul de date din Frankfurt, are 2 nuclee și 2 gigabytes de RAM.

Camera se află în rețeaua locală la 192.168.1.37.

Prin urmare, primul lucru pe care trebuie să-l facem este să redirecționăm portul 554 la 192.168.1.37 pentru intrare. TCP/RTSP conexiuni astfel încât serverul să se poată conecta la camera noastră IP. Pentru a face acest lucru, adăugați o singură regulă în setările routerului:

Regula îi spune routerului să redirecționeze tot traficul de intrare pe portul 554 la 37 - adresa IP.

Dacă aveți un NAT prietenos și cunoașteți adresa IP externă, atunci puteți începe testarea cu serverul.

Playerul demo standard din browserul Google Chrome arată astfel:

Pentru a începe să redați un flux RTSP, trebuie doar să introduceți adresa acestuia în câmp Curent.
În acest caz, adresa fluxului: rtsp://ip-cam/live1.sdp
Aici camera ip aceasta este adresa IP externă a camerei dvs. Serverul va încerca să stabilească o conexiune la această adresă.

Testarea latenței VLC vs WebRTC

După ce am configurat camera IP și am testat VLC, configurați serverul și testați RTSP flux prin server cu distribuție prin WebRTC, putem compara în sfârșit întârzierile.

Pentru a face acest lucru, vom folosi un cronometru care va afișa fracțiuni de secundă pe ecranul monitorului. Porniți temporizatorul și redați fluxul video simultan VLC localși în browserul Firefox printr-un server la distanță.

Ping la server 100 ms.
Ping local 1 ms.

Primul test de cronometru arată astfel:
Pe un fundal negru este cronometrul original, care arată zero întârziere. Stânga VLC, pe dreapta Firefox primind WebRTC stream de pe un server la distanță.

	Zero	VLC	Firefox, WCS
Timp	50.559	49.791	50.238
latență ms	0	768	321

La acest test, vedem o întârziere VLC de două ori mai lungă decât întârzierea Firefox + Web Call Server, în ciuda faptului că videoclipul în VLC este redat în rețeaua locală, iar videoclipul care este afișat în Firefox trece printr-un server dintr-un centru de date din Germania și se întoarce înapoi. Această discrepanță se poate datora faptului că VLC funcționează peste TCP (modul intercalat) și include câteva buffer-uri suplimentare pentru o redare fluidă a videoclipurilor.

Am făcut câteva fotografii pentru a surprinde valorile de întârziere.

RTSP (Protocol de streaming în timp real) este un protocol de streaming în timp real care conține un set simplu de comenzi de bază pentru controlul unui flux video.

Conectarea surselor RTSP și a camerelor IP într-o conferință video

Protocolul RTSP permite oricărui utilizator TrueConf să se conecteze la camere video IP și alte surse de conținut media care difuzează folosind acest protocol pentru a monitoriza obiectele de la distanță. De asemenea, utilizatorul se poate conecta la astfel de camere pentru a difuza imagini în timpul unei conferințe video.

Datorită suportului protocolului RTSP, utilizatorii TrueConf Server nu se pot conecta doar la camere IP, ci și pot transmite conferințe video către playere RTSP și servere media. Citiți mai multe despre emisiunile RTSP.

Beneficiile utilizării camerelor IP cu soluții software TrueConf

• Instalând o cameră IP într-un birou sau atelier industrial și conectându-vă la aceasta în orice moment convenabil, puteți monitoriza procesul de producție al companiei dumneavoastră.
• Puteți efectua monitorizarea non-stop a obiectelor de la distanță. De exemplu, dacă plecați în vacanță și nu doriți să vă lăsați apartamentul nesupravegheat, instalați acolo una sau mai multe camere IP. Făcând un apel către una dintre aceste camere de pe computer cu aplicația client TrueConf instalată, vă puteți conecta oricând la apartamentul dvs. și puteți vedea ce se întâmplă acolo în timp real.
• Aplicațiile client TrueConf pentru Windows, Linux și macOS oferă tuturor utilizatorilor posibilitatea de a înregistra conferințe video, datorită cărora puteți înregistra orice evenimente în timpul supravegherii video și puteți primi dovezi documentare ale acestora.

Vizualizarea confortabilă a transmisiunilor video sau poate fi configurată folosind playere multimedia software de pe computerul personal. Astăzi vom analiza cum să configurați un flux RTSP pentru echipamentele de rețea Dahua Technology într-unul dintre cele mai populare VLC Media Player.

RTSP (Real Time Streaming Protocol - protocol de streaming în timp real) este un protocol care permite utilizatorului să redea de la distanță un flux de date multimedia (audio și video) folosind un hyperlink și un player multimedia (în cazul nostru, VLC Media Player).

Dacă trebuie să configurați un flux video, utilizați următorii pași:

1. În primul rând, trebuie să descărcați și să instalați VLC Media Player, care este disponibil gratuit pe site-ul oficial.
2. Faceți clic pe elementul de meniu Media (Media) - Open Network Stream (Open URL).
3. Introduceți adresa rețelei RTSP în linia promptă.
4. Apăsați butonul de redare când imaginea video apare pe ecran.

Decriptarea legăturii RTSP

Exemplu:

rtsp:// :@:/cam/realmonitor?channel= &subtip=

Unde :

: Nume de utilizator (autentificare).

: parola.

: adresa IP a camerei de rețea.

: Portul 554 este setat implicit. Această valoare poate fi ignorată.

: numărul canalului. Numerotarea începe de la 1.

: tipul fluxului. Sens Firul principal este 0, firul secundar 1 este 1, firul secundar 2 este 2. De exemplu, referința pentru firul secundar numărul 1 ar fi:

rtsp://admin: [email protected]:554/cam/realmonitor?channel=1&subtype=1

Camerele video IP Dahua Technology acceptă protocoale de transfer de date TCP și UDP. Dacă portul 554 a fost modificat, schimbați-l în câmpul corespunzător al setărilor camerei (interfață web).

Dacă întâmpinați probleme cu configurarea unui flux RTSP, vă rugăm să consultați secțiunea corespunzătoare.