Prema nekim izvještajima, danas ih ima stotine miliona IP kamere za video nadzor. Međutim, kašnjenje u reprodukciji videa nije kritično za sve njih. Video nadzor se obično odvija "statički" - tok se snima u skladištu i može se analizirati za kretanje. Postoji mnogo softverskih i hardverskih rješenja razvijenih za video nadzor koji dobro rade svoj posao.

U ovom članku ćemo pogledati malo drugačiju aplikaciju IP kamere, odnosno primjena u online emisijama gdje je to potrebno nisko kašnjenje komunikacije.

Prije svega, razjasnimo sve moguće nesporazume u terminologiji o web kamerama i IP kamerama.

Web kamera je uređaj za snimanje video zapisa koji nema vlastiti procesor i mrežno sučelje. Web kamera zahtijeva vezu s računalom, pametnim telefonom ili drugim uređajem koji ima mrežnu karticu i procesor.

IP kamera je samostalni uređaj koji ima vlastitu mrežnu karticu i procesor za komprimiranje snimljenog videa i njegovo slanje u mrežu. Dakle, IP kamera je autonomno mini-računalo koje se u potpunosti povezuje na mrežu i ne zahtijeva vezu s drugim uređajem, a može direktno emitovati na mrežu.

Niska latencija(niska latencija) je prilično rijedak zahtjev za IP kamere i online emitiranje. Potreba za radom s malim kašnjenjem javlja se, na primjer, ako izvor video toka aktivno komunicira sa gledaocima ovog toka.

Najčešće je mala latencija potrebna u slučajevima korištenja igara. Takvi primjeri uključuju: video aukciju u stvarnom vremenu, video kazino s dilerom uživo, interaktivnu internetsku TV emisiju s voditeljem, daljinsko upravljanje kvadrokopterom itd.

Diler online kazina uživo na poslu.

Obična RTSP IP kamera obično emituje video H.264 kodek i može raditi u dva načina prijenosa podataka: interleaved I non-interleaved.

Mode interleaved najpopularniji i najpovoljniji, jer U ovom načinu rada, video podaci se prenose putem TCP-a unutar mrežne veze do kamere. Da biste distribuirali sa IP kamere na interleaved, trebate samo otvoriti/proslijediti jedan RTSP port kamere (na primjer 554) prema van. Plejer se može povezati s kamerom samo preko TCP-a i preuzeti stream unutar ove veze.

Drugi način rada kamere je non-interleaved. U ovom slučaju, veza se uspostavlja pomoću protokola RTSP/TCP, a promet ide odvojeno, po protokolu RTP/UDP izvan kreiranog TCP kanala.

Mode non-interleaved povoljnije za emitovanje videa sa minimalnim kašnjenjem, jer koristi RTP/UDP, ali je u isto vrijeme problematičnije ako se igrač nalazi iza NAT.

Kada se povezuje na IP kameru plejera koji je iza NAT-a, plejer mora znati koje eksterne IP adrese i portove može koristiti za prijem audio i video saobraćaja. Ovi portovi su navedeni u tekstualnoj SDP konfiguraciji, koja se šalje kameri kada se uspostavi RTSP veza. Ako je NAT ispravno otvoren i određene ispravne IP adrese i portovi, onda će sve raditi.

Dakle, da biste pokupili video sa kamere sa minimalnim kašnjenjem, morate koristiti non-interleave način rada i primanje video prometa putem UDP-a.

Preglednici ne podržavaju RTSP/UDP protokolski stog direktno, ali podržavaju ugrađeni tehnološki stog protokola WebRTC.

Tehnologije pretraživača i kamere su posebno slične SRTPšifrovano je RTP. Ali za ispravnu distribuciju na pretraživače, IP kamera bi trebala delimičnu podršku za WebRTC stek.

Da bi se eliminisala ova nekompatibilnost, potreban je posredni relej server, koji će delovati kao most između protokola IP kamere i protokola pretraživača.

Server preuzima stream sa IP kamere putem RTP/UDP i šalje ga povezanim pretraživačima putem WebRTC-a.

WebRTC tehnologija radi prema protokolu UDP i na taj način obezbeđuje malo kašnjenje u pravcu Server > Pretraživač. IP kamera također radi koristeći protokol RTP/UDP i obezbeđuje malo kašnjenje u pravcu Kamera > Server.

Kamera može emitovati ograničen broj streamova zbog ograničenih resursa i propusnog opsega. Korištenje srednjeg servera omogućava vam da skalirate emitiranje s IP kamere na veliki broj gledatelja.

S druge strane, kada se koristi server, omogućene su dvije komunikacijske noge:
1) Između gledalaca i servera
2) Između servera i kamere
Ova topologija ima brojne „osobine“ ili „zamke“. Navodimo ih u nastavku.

Zamka #1 - Kodeci

Korišteni kodeci mogu biti prepreka performansama niske latencije i mogu degradirati ukupne performanse sistema.

Na primjer, ako kamera emituje 720p video stream u H.264, a Chrome pretraživač na Android pametnom telefonu koji podržava samo VP8 je povezan.

Kada je transkodiranje omogućeno, sesija transkodiranja mora biti kreirana za svaku od povezanih IP kamera koja dekodira H.264 i kodira u VP8. U ovom slučaju, 16-jezgarni dual-procesor server će moći da servisira samo 10-15 IP kamera, po približnoj stopi od 1 kamere po fizičkom jezgru.

Stoga, ako kapacitet servera ne dozvoljava transkodiranje planiranog broja kamera, transkodiranje treba izbjegavati. Na primjer, služite samo pretraživačima koji podržavaju H.264, a drugima ponudite korištenje matične mobilne aplikacije za iOS ili Android koja podržava H.264 kodek.

Kao opciju za zaobilaženje transkodiranja u mobilnom pretraživaču možete koristiti H.L.S.. Ali HTTP streaming uopće nema malo kašnjenje i trenutno se ne može koristiti za interaktivno emitiranje.

Zamka #2 - brzina prijenosa i gubitak kamere

UDP protokol pomaže u rješavanju kašnjenja, ali dozvoljava gubitak video paketa. Stoga, uprkos malom kašnjenju, ako postoje veliki gubici u mreži između kamere i servera, slika može biti oštećena.

Da biste eliminisali gubitke, morate osigurati da video stream koji generiše kamera ima bitrate koji se uklapa u namjenski propusni opseg između kamere i servera.

Zamka #3 - brzina prijenosa gledatelja i gubici

Svaki gledalac emitovanja povezan sa serverom takođe ima određenu propusnost za preuzimanje.

Ako IP kamera šalje stream koji premašuje mogućnosti kanala gledatelja (na primjer, kamera šalje 1 Mbps, a gledalac može samo prihvatiti 500 Kbps), tada će doći do velikih gubitaka na ovom kanalu i, kao rezultat, zamrzavanja videa ili jakih artefakata.

U ovom slučaju postoje tri opcije:

1. Transkodirajte video stream pojedinačno za svakog gledaoca uz potreban bitrate.
2. Transkodirajte streamove ne za svaku povezanu osobu, već za grupu gledatelja.
3. Pripremite streamove kamere unaprijed u nekoliko rezolucija i brzina prijenosa.

Prva opcija sa transkodiranjem nije pogodan za svakog gledatelja, jer će trošiti CPU resurse čak i sa 10-15 povezanih gledatelja. Iako treba napomenuti da ova opcija pruža maksimalnu fleksibilnost uz maksimalno opterećenje CPU-a. One. Ovo je idealna opcija, na primjer, ako emitujete streamove na samo 10 geografski raspoređenih ljudi, svaki od njih prima dinamički bitrate i svakom od njih treba minimalno kašnjenje.

Druga opcija je smanjenje opterećenja na serverskom CPU-u korištenjem grupa za transkodiranje. Server kreira nekoliko grupa po bitrate-u, ​​na primjer dvije:

• 200 Kbps
• 1 Mbps

Ako gledalac nema dovoljno propusnog opsega, prelazi u grupu u kojoj može udobno primati video stream. Dakle, broj sesija transkodiranja nije jednak broju gledatelja kao u prvom slučaju, već je fiksni broj, na primjer 2, ako transkodiraju grupe dva.

Treća opcija podrazumijeva potpuno odbacivanje transkodiranja na strani servera i korištenje već pripremljenih video streamova u različitim rezolucijama i bitrate-ima. U ovom slučaju, kamera je konfigurisana da emituje dva ili tri toka sa različitim rezolucijama i brzinama bitova, a gledaoci se prebacuju između ovih tokova u zavisnosti od njihove propusnosti.

U ovom slučaju opterećenje transkodiranja na serveru nestaje i prebacuje se na samu kameru, jer Kamera je sada primorana da kodira dva ili više tokova umjesto samo jednog.

Kao rezultat toga, razmotrili smo tri opcije za prilagođavanje propusnosti gledalaca. Ako pretpostavimo da jedna sesija transkodiranja zauzima 1 jezgro servera, onda ćemo dobiti sljedeću tablicu opterećenja CPU-a:

Tabela pokazuje da možemo prebaciti opterećenje transkodiranja na kameru ili prebaciti transkodiranje na server. Čini se da su opcije 2 i 3 najoptimalnije.

Testiranje RTSP-a kao WebRTC-a

Došlo je vrijeme da se provede nekoliko testova kako bi se utvrdila prava slika onoga što se dešava. Uzmimo pravu IP kameru i izvršimo testiranje kako bismo izmjerili kašnjenje emitiranja.

Za testiranje, uzmimo drevnu IP kameru D-link DCS-2103 uz podršku RTSP i kodeci H.264 i G.711.

Pošto je kamera dugo ležala u ormaru sa ostalim korisnim uređajima i žicama, morala sam je poslati Resetovati pritiskom i držanjem dugmeta na zadnjoj strani kamere 10 sekundi.

Nakon povezivanja na mrežu, upalilo se zeleno svjetlo na kameri i ruter je vidio drugi uređaj na lokalnoj mreži s IP adresom 192.168.1.37.

Idemo na web sučelje kamere i postavljamo kodeke i rezoluciju za testiranje:

Zatim idite na mrežne postavke i saznajte RTSP adresu kamere. U ovom slučaju, RTSP adresa live1.sdp, tj. Kamera je dostupna na rtsp://192.168.1.37/live1.sdp

Dostupnost kamere može se lako provjeriti pomoću VLC player. Mediji - Otvorite mrežni tok.

Uvjerili smo se da kamera radi i emituje video preko RTSP-a.

Koristićemo Web Call Server 5 kao server za testiranje. Ovo je streaming server s podrškom RTSP i WebRTC protokoli. Povezat će se na IP kameru putem RTSP i podignite video stream. Zatim distribuirajte stream WebRTC.

Nakon instalacije potrebno je prebaciti server u RTSP mod non-interleaved o kojoj smo gore govorili. Ovo se može uraditi dodavanjem postavke

Rtsp_interleaved_mode=false
Ova postavka se dodaje u flashphoner.properties konfiguraciju i zahtijeva ponovno pokretanje servera:

Ponovno pokretanje servisa webcallserver
Dakle, imamo server koji radi po ne-interleaved šemi, prima pakete od IP kamere putem UDP-a, a zatim ih distribuira preko WebRTC-a (UDP).

Test server se nalazi na VPS serveru koji se nalazi u frankfurtskom data centru, ima 2 jezgra i 2 gigabajta RAM-a.

Kamera se nalazi na lokalnoj mreži na adresi 192.168.1.37.

Stoga, prva stvar koju moramo učiniti je proslijediti port 554 na adresu 192.168.1.37 za dolazni TCP/RTSP veze tako da server može uspostaviti vezu sa našom IP kamerom. Da biste to učinili, dodajte samo jedno pravilo u postavkama rutera:

Pravilo govori ruteru da sav dolazni promet preusmjeri na port 554, a IP adresu na 37.

Ako imate prijateljski NAT i znate eksternu IP adresu, onda možete započeti testiranje sa serverom.

Standardni demo plejer u pregledniku Google Chrome izgleda ovako:

Da biste započeli reprodukciju RTSP streama, samo trebate unijeti njegovu adresu u polje Potok.
U ovom slučaju, adresa toka je: rtsp://ip-cam/live1.sdp
Evo ip-cam ovo je vanjska IP adresa vaše kamere. Server će pokušati uspostaviti vezu sa ovom adresom.

Testiranje kašnjenja VLC vs WebRTC

Nakon što smo konfigurisali IP kameru i testirali je VLC, konfigurisao server i testirao RTSP protok kroz server sa distribucijom po WebRTC, konačno možemo uporediti latencije.

Da bismo to učinili, koristit ćemo tajmer koji će prikazati djeliće sekunde na ekranu monitora. Uključite tajmer i istovremeno uključite video stream VLC lokalno i na Firefox pretraživaču preko udaljenog servera.

Ping na server 100 ms.
Ping lokalno 1 ms.

Prvi test pomoću tajmera izgleda ovako:
Na crnoj pozadini je originalni tajmer, koji pokazuje nultu kašnjenje. lijevo VLC, desno Firefox, primanje WebRTC stream sa udaljenog servera.

	Zero	VLC	Firefox, WCS
Vrijeme	50.559	49.791	50.238
Latencija ms	0	768	321

U ovom testu vidimo kašnjenje od VLC duplo duže od kašnjenja Firefox + Web Call Server, uprkos činjenici da se video u VLC-u reprodukuje na lokalnoj mreži, a video koji se prikazuje u Firefox-u prolazi kroz server u data centru u Nemačkoj i vraća se nazad. Ovo neslaganje može biti uzrokovano činjenicom da VLC radi preko TCP-a (interleaved mode) i uključuje neke dodatne bafere za glatku reprodukciju video zapisa.

Napravili smo nekoliko slika da zabilježimo vrijednosti kašnjenja.

Često se postavlja pitanje: Kako spojiti IP kameru na NVR ako nije na listi kompatibilnosti?

Postoje dvije opcije ONVIF i RTSP

Počnimo s ONVIF protokolom (Open Network Video Interface Forum)

ONVIF je opšteprihvaćen protokol za zajednički rad IP kamera, NVR-a, softvera, u slučaju da su svi uređaji različitih proizvođača. ONVIF se može porediti sa engleskim jezikom za međunarodnu komunikaciju ljudi.

Uvjerite se da povezani uređaji podržavaju ONVIF; na nekim uređajima ONVIF može biti onemogućen prema zadanim postavkama.
Ili ONVIF autorizacija može biti onemogućena, što znači da će prijava/lozinka uvijek biti po defaultu
bez obzira na login/lozinku za WEB

Također je vrijedno napomenuti da neki uređaji koristeposeban port za rad preko ONVIF protokola

U nekim slučajevima, ONVIF lozinka se može razlikovati od lozinke za WEB pristup.

Šta je dostupno kada se povežete preko ONVIF-a?

Otkrivanje uređaja

Video prijenos

Prijem i prijenos audio podataka

Kontrola PTZ kamera

Video analitika (kao što je detekcija pokreta)

Ovi parametri zavise od kompatibilnosti verzija ONVIF protokola. U nekim slučajevima, neki parametri nisu dostupni ili ne rade ispravno.

K and koristeći ONVIF

U SNR i Dahua snimačima, ONVIF protokol se nalazi na kartici Remote Device, linija proizvođača

Odaberite kanal na koji će se uređaj povezati

Na kartici Proizvođač odaberite ONVIF

Odrediti ip adresa uređaja

RTSP port ostaje zadani

Koriste kamere ONVIF port 8080
(od 2017. na novim ONVIF modelima port je promijenjen na 80 za Alpha i Mira seriju)
OMNY kamere Baza koristiti ONVIF port 80, u registratoru je označen kao HTTP port

Ime

Lozinka prema parametrima uređaja

Udaljeni kanal podrazumevano je 1. Ako je uređaj višekanalni, prikazuje se broj kanala.

Dekoderski bafer— baferovanje video toka koji pokazuje vrijednost vremena

Tip serveraovdje postoji izbor TCP,UDP rasporeda

TCP- uspostavlja vezu između pošiljaoca i primaoca, osigurava da svi podaci stignu do primaoca bez promjena i u traženom redoslijedu, a također reguliše brzinu prijenosa.

Za razliku od TCP-a, UDP ne uspostavlja preliminarnu vezu, već jednostavno započinje prijenos podataka. UDP ne prati da li su podaci primljeni i ne duplira ih u slučaju gubitka ili greške.

UDP je manje pouzdan od TCP-a. Ali s druge strane, omogućava brži prijenos tokova zbog izostanka ponovnog prijenosa izgubljenih paketa

Raspored— automatska detekcija tipa.

Ovako izgledaju povezani uređaji u Dahui

Zeleni status znači da su diktafon i kamera uspješno povezani

Crveni status znači da postoje problemi sa vezom. Na primjer, priključak za vezu nije ispravan.

Drugi način povezivanja je RTSP(Protokol za prijenos u realnom vremenu)

RTSPprotokol za striming u realnom vremenu koji opisuje komande za kontrolu video toka.

Koristeći ove komande, video stream se emituje od izvora do primaoca

na primjer sa IP kamere na DVR ili server.

Šta je dostupno pri povezivanju putem RTSP-a?

Video prijenos

Prijem i prijenos audio podataka

PrednostOvaj protokol prijenosa je da ne zahtijeva kompatibilnost verzija.

Danas RTSP podržavaju gotovo sve IP kamere i NVR-ovi

Nedostaci Protokol je da osim prijenosa video i audio podataka ništa drugo nije dostupno.

Pogledajmo primjer povezivanja kamere do i koristeći RTSP

RTSP koji se nalazi na kartici Remote Device, linija Manufacturer, u SNR i Dahua snimaču je predstavljen kaoGenerale

Odaberite kanal na koji će se uređaj povezati

URL adresa- ovdje unosimo string upita za koji kamera šalje osnovni RTSP stream sa visoko rezoluciju.

Dodatni URL - Evo unesite string upita za koji kamera šalje dodatno RTSP stream sa niske rezolucije.

Primjer zahtjeva:

rtsp://172.16.31.61/1 glavni tok

rtsp://172.16.31.61/2 dodatni stream

Zašto vam je potreban dodatni konac?

Na lokalnom monitoru povezanom sa snimačem sa više slika, snimač koristi dodatnu nit za uštedu resursa. Na primjer, na malim slikama sa 16 prozora uopće nije potrebno dekodirati Full HD rezoluciju, dovoljan je D1. Pa, ako ste otvorili 1/4/8 prozora, u ovom slučaju glavni stream se dekodira u visokoj rezoluciji.

Imeprema parametrima uređaja

Lozinka prema parametrima uređaja

Dekoder Bufferbaferovanje video toka koji pokazuje vremensku vrijednost

Tip servera- TCP, UDP, raspored (slično ONVIF protokolu)

Ovaj članak daje odgovore na najčešća pitanja, kao što su:

Da li je IP kamera kompatibilna sa NVR-om?

I ako je kompatibilan, kako spojiti!?

Rešavanje problema onlajn emitovanja sa IP kamere, generalno govoreći, ne zahteva upotrebu WebRTC-a. Sama kamera je server, ima IP adresu i može se povezati direktno na ruter za distribuciju video sadržaja. Zašto onda koristiti WebRTC tehnologiju?

Za to postoje najmanje dva razloga:

1. Kako se broj gledalaca Ethernet emitiranja povećava, prvo će se osjetiti nedostatak debljine kanala, a zatim i resursa same kamere.

2. Kao što je gore navedeno, IP kamera je server. Ali koje protokole može koristiti za slanje videa na desktop pretraživač? Mobilni uređaj? Najvjerovatnije će to biti HTTP streaming, gdje se video okviri ili JPEG slike prenose putem HTTP-a. HTTP streaming, kao što znate, nije u potpunosti prikladan za video streaming u realnom vremenu, iako se dobro pokazao u videu na zahtjev, gdje interaktivnost streama i latencija nisu posebno važni. U stvari, ako gledate film, kašnjenje od nekoliko sekundi neće pogoršati situaciju osim ako ne gledate film u isto vrijeme kada i neko drugi. "O ne! Jack ju je ubio! - Alice piše spoiler u ćaskanju Bobu 10 sekundi prije tragičnog kraja.”

Ili će to biti RTSP/RTP i H.264, u kom slučaju dodatak za video plejer kao što je VLC ili QuickTime mora biti instaliran u pretraživač. Takav dodatak će snimati i reproducirati video, baš kao i sam plejer. Ali trebamo pravi streaming baziran na pretraživaču bez instaliranja dodatnih štaka/dodataka.

Prvo, napravimo snimak IP kamere da saznamo šta tačno ovaj uređaj šalje prema pretraživaču. Ispitanik će biti D-Link DCS 7010L kamera:

Više o instalaciji i konfiguraciji kamere možete pročitati u nastavku, ali ovdje ćemo samo pogledati šta ona koristi za video streaming. Prilikom ulaska u admin panel kamere preko web sučelja vidimo nešto ovako (izvinite zbog pejzaža):

Slika se otvara u svim pretraživačima i ravnomjerno se zamrzava, otprilike jednom u sekundi. S obzirom da su i kamera i laptop na kojem gledamo stream povezani na isti ruter, sve bi trebalo biti glatko i lijepo, ali to nije slučaj. Izgleda kao HTTP. Pokrenimo Wireshark da potvrdimo naša nagađanja:

Ovdje vidimo niz TCP fragmenata dužine 1514 bajtova

I konačni HTTP 200 OK sa dužinom primljenog JPEG-a:

Ne treba nam ovakav streaming. Nije glatko, trza HTTP zahtjeve. Koliko takvih zahtjeva u sekundi kamera može podnijeti? Postoji razlog za vjerovanje da će se pri 10 gledatelja ili ranije kamera sigurno saviti ili početi strašno kvariti i proizvoditi slajdove.

Ako pogledate HTML stranicu administrativnog panela kamere, vidjet ćete ovaj zanimljiv kod:

If(browser_IE) DW(""); else ( if(mpMode == 1) var RTSPName = g_RTSPName1; else if(mpMode == 2) var RTSPName = g_RTSPName2; else if(mpMode == 3) var RTSPName = g_RTSPName3; var o=""; ako (g_isIPv6) //jer ipv6 ne podržava rtsp. var host = g_netip; inače var host = g_host; o+=""; //upozorenje(o); DW(o); )

RTSP/RTP je upravo ono što vam je potrebno za pravilnu reprodukciju videa. Ali hoće li ovo raditi u pretraživaču? - Ne. Ali ako instalirate QuickTime dodatak, sve će raditi. Ali mi radimo isključivo strimovanje zasnovano na pretraživaču.

Ovdje možemo spomenuti i Flash Player, koji preko odgovarajućeg servera kao što je Wowza može primiti RTMP stream konvertiran iz RTSP, RTP, H.264. Ali Flash Player je, kao što znate, takođe dodatak za pretraživač, iako je neuporedivo popularniji od VLC-a ili QuickTime-a.

U ovom slučaju, mi ćemo testirati isti RTSP/RTP re-streaming, ali WebRTC-kompatibilni pretraživač će se koristiti kao uređaj za igranje bez ikakvih dodatnih dodataka za pretraživač ili drugih štaka. Postavićemo relejni server koji će preuzimati stream sa IP kamere i slati ga na Internet proizvoljnom broju korisnika koji koriste pretraživače koji podržavaju WebRTC.

Povezivanje IP kamere

Kao što je već spomenuto, za testiranje je odabrana jednostavna D-Link DCS-7010L IP kamera. Ključni kriterij odabira ovdje je bila podrška uređaja za RTSP protokol, jer će preko njega naš server primati video stream sa kamere.

Kameru povezujemo sa ruterom pomoću priloženog patch kabla. Nakon uključivanja napajanja i povezivanja na ruter, kamera je uzela IP adresu preko DHCP-a, u našem slučaju je to bila 192.168.1.34 (Ako odete u postavke rutera, vidjet ćete da je DCS 7010L uređaj povezan - to je to ). Vrijeme je za testiranje kamere.

Otvorite navedenu IP adresu u pretraživaču 192.168.1.34 da biste došli do web interfejsa administratora kamere. Podrazumevano ne postoji lozinka.

Kao što vidite, video sa kamere se ispravno emituje u admin panelu. Istovremeno je primjetno periodično podrhtavanje. To je ono što ćemo popraviti pomoću WebRTC-a.

Podešavanje kamere

Prvo, deaktiviramo autentifikaciju u postavkama kamere - u sklopu testiranja dat ćemo stream svima koji budu tražili. Da biste to učinili, idite na postavke u web interfejsu kamere Podešavanje - Mreža i postavite vrijednost opcije Isključivanje autentifikacije.

Tu također provjeravamo vrijednost porta RTSP protokola, po defaultu je 554. Format prenijetog videa je određen profilom koji se koristi. Možete podesiti do tri od njih u kameri, mi ćemo koristiti prvi, live1.sdp - po defaultu je konfigurisan da koristi H.264 za video i G.711 za audio. Po potrebi možete promijeniti postavke u odjeljku Podešavanje – audio i video.

Sada možete provjeriti rad kamere putem RTSP-a. Otvorite VLC Player (možete koristiti bilo koji drugi plejer koji podržava RTSP - QuickTime, Windows Media Player, RealPlayer, itd.) i u dijalogu Open URL postavite RTSP adresu kamere: rtsp://192.168.1.34/live1.sdp

Pa, sve radi kako treba. Kamera redovno reprodukuje video stream u plejeru preko RTSP protokola.

Usput, stream se reproducira prilično glatko i bez artefakata. Isto očekujemo i od WebRTC-a.

Instalacija servera

Dakle, kamera je instalirana, testirana sa desktop plejerima i spremna za emitovanje preko servera. Koristeći whatismyip.com određujemo eksternu IP adresu kamere. U našem slučaju to je bio 178.51.142.223. Ostaje samo reći ruteru da će se prilikom pristupa putem RTSP-a na portu 554, dolazni zahtjevi prenijeti na IP kameru.

Unesite odgovarajuća podešavanja u ruter...

...i provjerite eksternu IP adresu i RTSP port koristeći telnet:

Telnet 178.51.142.223 554

Nakon što smo se uvjerili da postoji odgovor na ovom portu, nastavljamo s instaliranjem WebRTC servera.

Virtuelni server na Centos 64 bit na Amazon EC2 će biti odgovoran za hosting.
Da bismo izbjegli probleme s performansama, odabrali smo m3.medium instancu s jednim VCPU-om:

Da, da, tu su i Linode i DigitalOcean, ali u ovom slučaju sam htio isprobati Amazon.
Gledajući unaprijed, napisat ću da u kontrolnu ploču Amazon EC2 morate dodati nekoliko pravila (proslijedi portovi), bez kojih primjer neće raditi. To su portovi za WebRTC (SRTP, RTCP, ICE) saobraćaj i portovi za RTSP/RTP saobraćaj. Ako pokušate, Amazonova pravila bi trebala imati nešto slično za dolazni promet:

Usput, s DigitalOceanom sve će biti jednostavnije, samo otvorite ove portove na firewall-u ili isključite ovaj drugi. Prema najnovijim iskustvima u radu DO instanci, oni i dalje izdaju statičku IP adresu i ne opterećuju se NAT-ovima, što znači da prosljeđivanje portova, kao u slučaju Amazona, nije potrebno.

Koristićemo WebRTC Media & Broadcasting Server iz Flashphonera kao serverski softver koji prenosi RTSP/RTP tok na WebRTC. Streaming server je vrlo sličan Wowza, koji može streamati RTSP/RTP stream na Flash. Jedina razlika je u tome što će se ovaj stream poslati na WebRTC, a ne na Flash. One. pošteni DTLS će proći između pretraživača i servera, SRTP sesija će biti uspostavljena i tok kodiran u VP8 će ići do gledatelja.

Za instalaciju će nam trebati SSH pristup.

Ispod spojlera je detaljan opis izvršenih komandi

1. Preuzeta arhiva instalacije servera:
$wget flashphoner.com/downloads/builds/WCS/3.0/x8664/wcs3_video_vp8/FlashphonerMediaServerWebRTC-3.0/FlashphonerMediaServerWebRTC-3.0.868.tar.gz
2. Prošireno:
$tar -xzf FlashphonerMediaServerWebRTC-3.0.868.tar.gz
3. Instalirano:
$cd FlashphonerMediaServerWebRTC-3.0.868
$./install.sh
Tokom procesa instalacije uneli smo eksternu IP adresu servera: 54.186.112.111 i internu 172.31.20.65 (isto kao Privatna IP).
4. Pokrenuo server:
$service webcallserver start
5. Provjerio logove:
$tail - f /usr/local/FlashphonerWebCallServer/logs/server_logs/flashphoner.log
6. Provjerite je li server pokrenut i spreman za rad:
$ps aux | grep Flashphoner
7. Instalirao i pokrenuo apache:
$yum instalirajte httpd
$service httpd start
8. Preuzeo web datoteke i stavio ih u standardni Apache folder /var/www/html
cd /var/www/html
$wget github.com/flashphoner/flashphoner_client/archive/wcs_media_client.zip
$unzip webrtc_media_client.zip
9. Unesite IP adresu servera u flashphoner.xml konfiguraciju:
10. Zaustavljen firewall.
$service iptables stop

U teoriji, umjesto tačke 10, bilo bi ispravno postaviti sve potrebne portove i pravila zaštitnog zida, ali u svrhu testiranja odlučili smo jednostavno onemogućiti firewall.

Podešavanje servera

Podsjetimo, struktura našeg WebRTC emitiranja je sljedeća:

Već smo instalirali glavne elemente ovog dijagrama, preostaje samo da uspostavimo „strelice“ interakcija.

Vezu između pretraživača i WebRTC servera obezbeđuje veb klijent, koji je dostupan na Github:. Skup JS, CSS i HTML datoteka se jednostavno ubacuje /var/www/html u fazi instalacije (vidi tačku 9 iznad ispod spojlera).

Interakcija između pretraživača i servera je konfigurisana u XML konfiguracionoj datoteci flashphoner.xml. Tamo trebate unijeti IP adresu servera kako bi se web klijent mogao povezati na WebRTC server preko HTML5 Websockets (točka 9 iznad).

Postavljanje servera se završava ovdje; možete provjeriti njegov rad:

Otvorite stranicu web klijenta index.html u pretraživaču (za to je Apache instaliran na istom Amazon serveru sa komandom yum -y instalirati httpd):

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

Evo webrtc-ipcam.ddns.net je besplatna domena dobijena preko dinamičkog DNS servera noip.com, koji se odnosi na našu eksternu IP adresu. Rekli smo ruteru da preusmeri RTSP zahteve na 192.168.1.34 u skladu sa pravilima prevođenja NAT mrežnih adresa (takođe pogledajte gore).
Parametar id=rtsp://webrtc-ipcam.ddns.net/live1.sdp specificira URL toka za reprodukciju. WebRTC server će tražiti streamove od kamere, obraditi ih i poslati u pretraživač za reprodukciju putem WebRTC-a. Možda vaš ruter podržava DDNS. Ako ne, onda sama IP kamera ima takvu podršku:

A ovako izgleda DDNS podrška u samom ruteru:

Sada možete započeti testiranje i procijeniti rezultate.

Testiranje

Nakon otvaranja linka u pretraživaču, uspostavlja se veza sa WebRTC serverom, koji šalje zahtjev IP kameri da primi video stream. Cijeli proces traje nekoliko sekundi.

U ovom trenutku uspostavlja se veza između pretraživača i servera preko websocketa, zatim server traži IP kameru preko RTSP-a, prima H.264 stream preko RTP-a i transkodira ga u VP8 / SRTP - koji na kraju reproducira WebRTC pretraživač.

Na dnu videa prikazuje se URL video toka, koji se može kopirati i otvoriti za gledanje iz drugog pretraživača ili kartice.

Uvjeravamo se da je ovo zaista WebRTC.

Šta ako smo prevareni, a video sa IP kamere ponovo se prenosi preko HTTP-a? Nemojmo dokono gledati sliku, nego provjerimo kakav promet zapravo primamo. Naravno, ponovo pokrećemo Wireshark i konzolu za otklanjanje grešaka u Chromeu. U konzoli Chrome pretraživača možemo vidjeti sljedeće:

Ovaj put ništa ne treperi i nijedna slika nije vidljiva koja se prenosi putem HTTP-a. Sve što vidimo ovog puta su Websocket okviri i većina njih su tipovi ping/pong za održavanje Websocket sesije. Zanimljivi okviri: connect, readyRtspSession i onReadyToPlay - ovo je redoslijed kojim se uspostavlja konekcija sa serverom: prvo Websocket veza, a zatim zahtjev za stream za reprodukciju.

Evo šta pokazuje chrome://webrtc-internals

Prema grafikonima, imamo bitrate sa IP kamere od 1Mbps. Postoji i odlazni saobraćaj, najverovatnije su to RTCP i ICE paketi. RTT do Amazon servera je oko 300 milisekundi.

Pogledajmo sada Wireshark, možete jasno vidjeti UDP promet sa IP adrese servera. Na slici ispod, paketi su 1468 bajtova. Ovo je WebRTC. Tačnije, SRTP paketi koji nose VP8 video okvire, koje možemo posmatrati na ekranu pretraživača. Osim toga, STUN zahtjevi se provlače (najniži paket na slici) - ovo je WebRTC ICE koji pažljivo provjerava vezu.

Vrijedi napomenuti i relativno nisku latenciju (ping do centra podataka je bio oko 250 ms) za video reprodukciju. WebRTC radi preko SRTP/UDP, a ovo je, na kraju krajeva, najbrži način za isporuku paketa, za razliku od HTTP, RTMP i drugih metoda strimovanja sličnih TCP-u. One. Kašnjenje vidljivo oku treba biti RTT + vrijeme baferovanja, dekodiranja i reprodukcije od strane pretraživača. Vizuelno je to slučaj u ovom slučaju - oko gotovo ne vidi kašnjenje, manje je od 500 milisekundi.

Sljedeći test je povezivanje drugih gledatelja. Uspio sam otvoriti 10 Chrome prozora i svaki od njih je pokazao sliku. Istovremeno, sam Chrome je počeo da postaje pomalo dosadan. Prilikom otvaranja 11. prozora na drugom računaru, reprodukcija je ostala glatka.

O WebRTC-u na mobilnim uređajima

Kao što znate, WebRTC podržavaju Chrome i Firefox pretraživači na Android platformi.
Provjerimo da li će se tamo prikazati naša emisija:

Slika prikazuje HTC telefon, Firefox pretraživač prikazuje video sa kamere. Nema razlike u glatkoći reprodukcije u odnosu na desktop.

Zaključak

Kao rezultat toga, uspjeli smo pokrenuti WebRTC onlajn emitovanje sa IP kamere na nekoliko pretraživača uz minimalan napor. Nije bilo potrebno plesanje s tamburom ili raketna nauka - samo osnovno poznavanje Linuxa i SSH konzole.

Kvalitet emitovanja je bio na prihvatljivom nivou, a kašnjenje pri reprodukciji je bilo nevidljivo oku.

Da rezimiramo, možemo reći da WebRTC emitovanja zasnovana na pretraživaču imaju pravo na postojanje, jer u našem slučaju, WebRTC više nije štaka ili dodatak, već prava platforma za reprodukciju videa u pretraživaču.

Zašto ne vidimo široko usvajanje WebRTC-a?

Glavna prepreka je možda nedostatak kodeka. WebRTC zajednica i dobavljači bi se trebali potruditi i uvesti H.264 kodek u WebRTC. Nema šta da se kaže protiv VP8, ali zašto se odreći miliona kompatibilnih uređaja i softvera koji rade sa H.264? Patenti, takvi patenti...

Na drugom mjestu nije puna podrška u pretraživačima. Kod IE i Safarija, na primjer, pitanje ostaje otvoreno i tu ćete se morati prebaciti na drugu vrstu streaminga ili koristiti dodatak kao što je webrtc4all.

Stoga se nadamo da ćemo u budućnosti vidjeti još zanimljivija rješenja u kojima neće biti potrebno transkodiranje i konverzija streamova, a većina pretraživača će moći direktno reproducirati streamove s različitih uređaja.

Udobno gledanje video prenosa ili se može konfigurisati pomoću softverskih multimedijalnih plejera na vašem ličnom računaru. Danas ćemo pogledati kako konfigurirati RTSP stream za Dahua Technology mrežnu opremu u jednom od najpopularnijih playera, VLC Media Playeru.

RTSP (Real Time Streaming Protocol) je protokol koji omogućava korisniku da daljinski reprodukuje tok multimedijalnih podataka (audio i video) koristeći hipervezu i multimedijalni plejer (u našem slučaju VLC Media Player).

Ako trebate konfigurirati video stream, koristite sljedeće korake:

1. Prije svega, morate preuzeti i instalirati VLC Media Player, koji je besplatno dostupan na službenoj web stranici.
2. Kliknite na stavku menija Mediji – Otvori mrežni tok (Otvori URL).
3. Unesite RTSP mrežnu adresu u liniju upita.
4. Pritisnite dugme za reprodukciju kada se video slika pojavi na ekranu.

Objašnjenje veze RTSP

primjer:

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

gdje:

: Korisničko ime (prijava).

: lozinka.

: IP adresa mrežne video kamere.

: Podrazumevani port je 554. Ova vrijednost se može zanemariti.

: broj kanala. Numeracija počinje od 1.

: vrsta toka. Značenje glavna nit je 0, dodatna nit 1 je 1, dodatna nit 2 je 2. Na primjer, veza za dodatnu nit broj 1 bi bila kako slijedi:

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

IP video kamere Dahua Technology podržavaju TCP i UDP protokole za prijenos podataka. Ako je port 554 promijenjen, promijenite ga u odgovarajućem polju postavki video kamere (web interfejs).

Ako imate bilo kakvih problema s postavljanjem RTSP toka, pogledajte odgovarajući odjeljak.

RTSP (Real Time Streaming Protocol)– protokol za striming u realnom vremenu koji sadrži jednostavan skup osnovnih komandi za kontrolu video toka.

Povezivanje RTSP izvora i IP kamera na video konferencijama

RTSP protokol omogućava svakom korisniku TrueConf-a da se poveže na IP video kamere i druge izvore medijskog sadržaja koji emituju koristeći ovaj protokol za praćenje udaljenih objekata. Korisnik se takođe može povezati sa takvim kamerama da emituje slike tokom video konferencije.

Zahvaljujući podršci za RTSP protokol, korisnici TrueConf Servera mogu ne samo da se povežu na IP kamere, već i da emituju video konferencije na RTSP plejere i medijske servere. Pročitajte više o RTSP emisijama.

Prednosti korištenja IP kamera sa softverskim rješenjima TrueConf

• Instaliranjem IP kamere u kancelariji ili industrijskoj radionici i povezivanjem na nju u bilo koje vreme, moći ćete da kontrolišete proizvodni proces vaše kompanije.
• Možete pratiti udaljene objekte 24 sata dnevno. Na primjer, ako idete na odmor i ne želite da ostavite svoj stan bez nadzora, jednostavno tamo postavite jednu ili više IP kamera. Pozivanjem jedne od ovih kamera sa svog računara sa instaliranom TrueConf klijentskom aplikacijom, možete se u svakom trenutku povezati sa svojim stanom i videti u realnom vremenu šta se tamo dešava.
• U TrueConf klijentskim aplikacijama za Windows, Linux i macOS, svim korisnicima je dostupna mogućnost snimanja video konferencija, zahvaljujući kojima tokom video nadzora možete snimiti sve događaje i dobiti dokumentarne dokaze o njima.