Potrivit unor rapoarte, astăzi există sute de milioane Camere IP pentru supraveghere video. Cu toate acestea, întârzierea redării videoclipurilor nu este critică pentru toți. Supravegherea video are loc de obicei „static” - fluxul este înregistrat în depozit și poate fi analizat pentru mișcare. Există multe soluții software și hardware dezvoltate pentru supravegherea video care își fac bine treaba.

În acest articol ne vom uita la o aplicație ușor diferită camere IP, și anume aplicare în emisiunile online unde se cere latență scăzută de comunicare.

În primul rând, să lămurim orice posibilă neînțelegere în terminologia despre camere web și camere 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 comprimarea videoclipurilor capturate și trimiterea acestuia în rețea. Astfel, o cameră IP este un mini-computer autonom care se conectează complet la rețea și nu necesită conexiune 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. Astfel de exemple includ: o licitație video în timp real, un cazinou video cu un dealer live, o emisiune TV interactivă online cu o gazdă, controlul de la distanță al unui quadcopter etc.

Dealer de cazinou online live la locul de muncă.

O cameră IP RTSP obișnuită transmite, de obicei, videoclipuri 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 TCP în cadrul conexiunii de rețea către 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 se poate conecta la cameră doar prin TCP și poate prelua fluxul în cadrul 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 separat, conform protocolului RTP/UDPîn afara canalului TCP creat.

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

Când se conectează la o cameră IP a unui player care se află î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 au fost determinate adresele IP și porturile corecte, atunci totul va funcționa.

Deci, pentru a prelua 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 nativă WebRTC.

Tehnologiile browserului și ale camerei sunt foarte asemănătoare, în special SRTP este criptat RTP. Dar pentru distribuirea corectă către browsere, camera 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 acționa ca o punte între protocoalele camerei IP și protocoalele browserului.

Serverul preia fluxul de la camera IP prin RTP/UDPși îl trimite către browserele conectate prin WebRTC.

Tehnologia WebRTC funcționează conform protocolului UDPși astfel asigură o întârziere redusă în direcție Server > Browser. Camera IP funcționează și folosind protocolul RTP/UDPși oferă o întârziere redusă în direcție Cameră > Server.

Camera poate scoate un număr limitat de fluxuri din cauza 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ă un server, sunt activate două segmente de comunicare:
1) Între spectatori și server
2) Între server și cameră
Această 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 performanței cu latență scăzută și pot degrada performanța generală a sistemului.

De exemplu, dacă camera redă un flux video de 720p în H.264 și este conectat un browser Chrome pe un smartphone Android cu doar suport 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, la o rată aproximativă de 1 cameră pe nucleu fizic.

Prin urmare, dacă capacitatea serverului nu permite transcodarea numărului planificat de camere, atunci transcodarea ar trebui evitată. De exemplu, serviți numai browsere care acceptă H.264 și oferiți altora să folosească o aplicație mobilă nativă pentru iOS sau Android care acceptă codecul H.264.

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

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

Protocolul UDP ajută la gestionarea latenței, dar permite pierderea pachetelor video. Prin urmare, în ciuda latenței scăzute, dacă există pierderi mari în rețea între cameră și server, imaginea poate fi deteriorată.

Pentru a elimina pierderile, trebuie să vă asigurați că fluxul video generat de cameră are un bitrate care se încadrează în lățimea de bandă dedicată dintre cameră și server.

Capcana #3 - Rata de biți și pierderi ale vizualizatorului

Fiecare vizualizator de difuzare conectat la server are și o anumită lățime de bandă la Descărcare.

Dacă camera IP trimite un flux care depășește capacitățile canalului spectatorului (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, înghețuri 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 persoană conectată, ci pentru un grup de spectatori.
3. Pregătiți în avans fluxurile camerei în mai multe rezoluții și rate de biți.

Prima varianta cu transcodare nu este potrivit pentru fiecare vizualizator, deoarece va consuma resurse CPU chiar și cu 10-15 vizualizatori conectați. Deși trebuie menționat că această opțiune oferă flexibilitate maximă cu sarcina maximă a CPU. Acestea. Aceasta este o opțiune ideală, de exemplu, dacă difuzați fluxuri către doar 10 persoane distribuite geografic, fiecare dintre ele primește o rată de biți dinamică și fiecare dintre ele are nevoie de o latență 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 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 este mutată către camera în sine, deoarece Camera este acum forțată să codifice două sau mai multe fluxuri în loc de doar 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 ocupă 1 nucleu de server, atunci obținem următorul tabel de încărcare a procesorului:

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

Testarea RTSP ca WebRTC

A sosit momentul să efectuăm mai multe teste pentru a identifica imaginea reală a ceea ce se întâmplă. Să luăm o cameră IP reală și să efectuăm teste pentru a măsura latența de difuzare.

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

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

După conectarea la rețea, s-a aprins ledul verde de pe cameră și routerul a văzut un alt dispozitiv din rețeaua locală cu adresa IP 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

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

Ne-am asigurat că camera funcționează și transmite 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 preluați fluxul video. Apoi, distribuiți fluxul 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 unei setări

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, iar 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 adresa 192.168.1.37 pentru intrare. TCP/RTSP conexiuni astfel încât serverul să poată stabili o conexiune 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 către portul 554 și adresa IP la 37.

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 este: rtsp://ip-cam/live1.sdp
Aici ip-cam 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-o VLC, a configurat serverul și a testat RTSP flux prin server cu distribuție prin WebRTC, putem compara în sfârșit latențele.

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 folosind un 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ța ms	0	768	321

În acest test vedem o întârziere de 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ță poate fi cauzată de faptul că VLC funcționează prin TCP (mod intercalat) și include câteva buffer-uri suplimentare pentru o redare fluidă a videoclipurilor.

Am făcut mai multe poze pentru a înregistra valorile latenței.

Apare adesea întrebarea: Cum se conectează o cameră IP la un NVR dacă nu este pe lista de compatibilitate?

Există două opțiuni ONVIF și RTSP

Să începem cu protocolul ONVIF (Open Network Video Interface Forum)

ONVIF este un protocol general acceptat pentru operarea în comun a 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ă a oamenilor.

Asigurați-vă că dispozitivele conectate acceptă ONVIF pe unele dispozitive este posibil ca ONVIF să fie dezactivat în mod implicit.
Sau autorizarea prin 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 operare prin protocolul ONVIF

În unele cazuri, parola ONVIF poate diferi de parola de acces WEB.

Ce este disponibil atunci când este conectat prin ONVIF?

Descoperirea dispozitivului

Transmisie video

Recepția și transmiterea datelor audio

Controlul camerei PTZ

Analize video (cum ar fi detectarea mișcării)

Acești parametri depind de compatibilitatea versiunilor de protocol ONVIF. În unele cazuri, unii parametri nu sunt disponibili sau nu funcționează corect.

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 noile modele ONVIF portul a fost schimbat la 80 pentru seriile Alpha și Mira)
Camere OMNY Baza utilizare ONVIF portul 80, în registrator este indicat ca port HTTP

Nume

Parola conform parametrilor dispozitivului

Canal de la distanță implicit este 1. Dacă dispozitivul este multicanal, este indicat numărul canalului.

Buffer decodor— tamponarea fluxului video indicând valoarea timpului

Tip serveraici există o alegere de TCP, UDP Schedule

TCP- stabilește o conexiune între emițător și destinatar, se asigură că toate datele ajung la destinatar fără modificări și în ordinea necesară și, de asemenea, reglează viteza de transmisie.

Spre deosebire de TCP, UDP nu stabilește o conexiune preliminară, ci pur și simplu începe transmiterea datelor. UDP nu monitorizează că datele au fost 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ă o transmisie mai rapidă a fluxurilor datorită absenței retransmisiei pachetelor pierdute.

Programa— detectarea automată a tipului.

Așa arată dispozitivele conectate în Dahua

Starea verde înseamnă că reportofonul și camera sunt conectate cu succes

Starea roșie înseamnă că există probleme de conexiune. De exemplu, portul de conectare este incorect.

A doua metodă 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.

Folosind aceste comenzi, fluxul video este transmis de la sursă la destinatar

de exemplu de la o cameră IP la un DVR sau server.

Ce este disponibil la conectarea prin RTSP?

Transmisie video

Recepția și transmiterea datelor audio

AvantajAcest protocol de transfer este că nu necesită compatibilitate cu versiunea.

Astăzi, RTSP este acceptat de aproape toate camerele IP și NVR-urile

Defecte Protocolul este că în afară de transmiterea de date video și audio, nimic altceva nu este disponibil.

Să ne uităm la un exemplu de conectare a unei camere la și folosind RTSP

RTSP situat pe fila Dispozitiv la distanță, linia Producător, în recorderul SNR și Dahua este prezentat caGeneral

Selectați canalul la care va fi conectat dispozitivul

Adresă URL- aici introducem sirul de interogare pentru care trimite camera de bază Flux RTSP cu înalt rezoluţie.

URL suplimentar - Aici introduceți șirul de interogare pentru care trimite camera adiţional Flux RTSP cu rezolutie scazuta.

Exemplu de solicitare:

rtsp://172.16.31.61/1 flux principal

rtsp://172.16.31.61/2 flux suplimentar

De ce ai nevoie de un thread suplimentar?

Pe un monitor local conectat la reportofonul cu imagini multiple, reportofonul folosește un fir suplimentar pentru a economisi resurse. De exemplu, în pozele mici cu 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 indicând valoarea timpului

Tip 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ă!?

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 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 se va simți lipsa grosimii canalului și apoi resursele camerei în sine.

2. După cum am menționat mai sus, camera IP este un server. Dar ce protocoale poate folosi pentru a trimite videoclipuri către browserul desktop? Dispozitiv mobil? Cel mai probabil, acesta va fi fluxul HTTP, unde cadrele video sau imaginile JPEG sunt transmise prin HTTP. Streamingul HTTP, după cum știți, nu este pe deplin potrivit pentru streaming video în timp real, deși s-a dovedit bine în videoclipurile la cerere, unde interactivitatea și latența în flux nu sunt deosebit de importante. De fapt, dacă vizionați un film, o întârziere de câteva secunde nu va înrăutăți situația decât dacă vizionați filmul în același timp cu altcineva. "Oh nu! Jack a ucis-o! - Alice îi scrie lui Bob un spoiler în chat cu 10 secunde înainte de finalul 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 captura și reda videoclipuri, la fel ca playerul însuși. Dar avem nevoie de streaming real bazat pe browser, fără a instala cârje/plugin-uri suplimentare.

Mai întâi, să facem o fotografie a camerei IP pentru a afla ce anume trimite acest dispozitiv către browser. Subiectul de testare va fi camera D-Link DCS 7010L:

Puteți citi mai multe despre instalarea și configurarea camerei de mai jos, dar aici ne vom uita doar la ce folosește aceasta pentru streaming video. Când intram î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 se îngheață uniform, 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 cazul. Arata ca HTTP. Să lansăm 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 tip de streaming. Nu este ușor, ridică solicitările HTTP. Câte astfel de solicitări pe secundă poate gestiona camera? Există motive să credem că la 10 spectatori sau mai devreme, camera se va îndoi în siguranță sau va începe să se defecteze teribil și să producă diapozitive.

Dacă te uiți la pagina HTML a panoului de administrare al camerei, vei vedea acest 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;"; //alertă(o); DW(o); )

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

Aici putem aminti și Flash Player, care poate, printr-un server adecvat precum Wowza, să primească un stream RTMP convertit din RTSP, RTP, H.264. 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 sau 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 folosesc browsere care acceptă 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 primi fluxul video de la cameră.

Conectam camera la router folosind cablul 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ă mergi la setările routerului, vei vedea că dispozitivul DCS 7010L este conectat - asta e tot ). 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ă o parolă.

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

Configurarea camerei

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

Acolo verificăm și 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 configurat 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 orice alt player 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 reproduce în mod regulat fluxul video în player prin protocolul RTSP.

Apropo, fluxul este redat 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 pentru difuzare prin server. Folosind whatismyip.com determinăm adresa IP externă a camerei. În cazul nostru a fost 178.51.142.223. Tot ce rămâne este să-i spuneți routerului că atunci când accesați prin RTSP pe portul 554, cererile primite vor fi transmise către camera IP.

Introduceți 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-am asigurat 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 evita problemele de performanță, am ales o instanță m3.medium cu un singur VCPU:

Da, da, există și Linode și DigitalOcean, dar în acest caz am vrut să încerc 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:

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

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

Pentru instalare vom avea nevoie de acces SSH.

Sub spoiler este o descriere detaliată a comenzilor executate

1. Am descărcat 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. Extins:
$tar -xzf FlashphonerMediaServerWebRTC-3.0.868.tar.gz
3. Instalat:
$cd FlashphonerMediaServerWebRTC-3.0.868
$./install.sh
În timpul procesului de instalare, am introdus adresa IP externă a serverului: 54.186.112.111 și 172.31.20.65 intern (la fel ca 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

Să ne amintim că structura transmisiei noastre WebRTC este următoarea:

Am instalat deja elementele principale ale acestei diagrame, nu rămâne decât 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 punctul 9 de mai sus sub spoiler).

Interacțiunea dintre browser și server este configurată în fișierul de configurare XML flashphoner.xml. Acolo trebuie să introduceți adresa IP a serverului, 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:

Deschideți pagina clientului 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 în conformitate cu regulile 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 dvs. acceptă DDNS. Dacă nu, atunci camera IP în sine are un astfel de suport:

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

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 fluxul video. Întregul proces durează câteva secunde.

În acest moment, se stabilește o conexiune între browser și server prin intermediul websocket-urilor, apoi serverul solicită camera IP prin RTSP, primește fluxul H.264 prin RTP și îl transcodează în VP8 / SRTP - care în cele din urmă redă 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ă.

Ne asigurăm că acesta este cu adevărat WebRTC.

Dacă am fi înșelați, iar videoclipul de la camera IP este transmis 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, lansăm din nou Wireshark și consola de depanare în Chrome. În consola browserului Chrome putem vedea următoarele:

De data aceasta nimic nu clipește și nicio imagine nu este vizibilă transmisă prin HTTP. 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.

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-ul către serverul Amazon este de aproximativ 300 de milisecunde.

Acum să ne uităm la Wireshark, puteți vedea clar traficul UDP de la adresa IP a serverului. În imaginea de mai jos, pachetele au 1468 de octeți. Acesta este WebRTC. Mai exact, pachetele SRTP care transportă cadre video VP8, pe care le putem observa pe ecranul browserului. În plus, solicitările STUN trec (cel mai jos 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) pentru redarea video. WebRTC funcționează prin SRTP/UDP și, până la urmă, acesta este cel mai rapid mod de a livra pachete, spre deosebire de HTTP, RTMP și alte metode de streaming asemănătoare TCP. Acestea. Întârzierea vizibilă pentru ochi ar trebui să fie RTT + timpul de buffering, decodare și redare de către browser. Vizual, acesta este cazul în acest caz - ochiul aproape că nu vede întârzierea, este mai mică de 500 de milisecunde.

Următorul test este conectarea altor spectatori. Am reușit să deschid 10 ferestre Chrome și fiecare dintre ele arăta o poză. În același timp, Chrome însuși a început să devină puțin plictisitor. 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:

Imaginea arată un telefon HTC, browserul Firefox afișează videoclipuri de la cameră. Nu există diferențe de fluiditate a redării față de desktop.

Concluzie

Drept urmare, am reușit să lansăm o transmisie online WebRTC de la o cameră IP către mai multe browsere cu un efort minim. Nu a fost nevoie de dans cu o tamburină 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.

Pentru a rezuma, 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?

Principalul obstacol este poate lipsa codecurilor. Comunitatea WebRTC și vânzătorii ar trebui să facă un efort și să introducă 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...

Pe locul doi nu este suportul 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 în care nu va fi necesară transcodarea și conversia fluxurilor și majoritatea browserelor vor putea reda direct fluxuri de pe diverse dispozitive.

Vizualizarea confortabilă a transmisiunilor video sau poate fi configurată folosind playere multimedia software de pe computerul personal. Astăzi ne vom uita la modul de configurare a unui flux RTSP pentru echipamentele de rețea Dahua Technology într-unul dintre cele mai populare playere, VLC Media Player.

RTSP (Real Time Streaming Protocol) 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 – 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.

Explicația link-ului RTSP

Exemplu:

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

Unde :

: Nume de utilizator (autentificare).

: parola.

: adresa IP a camerei video de rețea.

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

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

: tipul fluxului. Sens Firul principal este 0, firul suplimentar 1 este 1, firul suplimentar 2 este 2. De exemplu, legătura pentru numărul suplimentar de fir 1 ar fi după cum urmează:

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 video (interfață web).

Dacă aveți probleme la configurarea unui flux RTSP, vă rugăm să consultați secțiunea corespunzătoare.

RTSP (Protocol de streaming în timp real)– 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 în conferințe 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 pentru protocolul RTSP, utilizatorii TrueConf Server nu se pot conecta doar la camerele 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

• Prin instalarea unei camere IP într-un birou sau atelier industrial și conectarea la aceasta în orice moment convenabil, veți putea controla procesul de producție al companiei dumneavoastră.
• Puteți monitoriza obiectele de la distanță non-stop. De exemplu, dacă plecați în vacanță și nu doriți să vă lăsați apartamentul nesupravegheat, instalați pur și simplu una sau mai multe camere IP acolo. 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 în timp real ce se întâmplă acolo.
• În aplicațiile client TrueConf pentru Windows, Linux și macOS, toți utilizatorii au acces la posibilitatea de a înregistra conferințe video, datorită cărora în timpul supravegherii video puteți înregistra orice evenimente și puteți primi dovezi documentare ale acestora.