Mõnede teadete kohaselt on täna neid sadu miljoneid IP kaamerad videovalveks. Video taasesituse viivitus pole aga nende kõigi jaoks kriitiline. Videovalve toimub tavaliselt "staatiliselt" - voog salvestatakse salvestusruumi ja selle liikumist saab analüüsida. Videovalve jaoks on välja töötatud palju tarkvara- ja riistvaralahendusi, mis teevad oma tööd hästi.

Selles artiklis vaatleme veidi teistsugust rakendust IP kaamerad, nimelt rakendamine võrgusaadetes, kus seda nõutakse madal side latentsus.

Kõigepealt teeme selgeks kõik võimalikud arusaamatused veebikaamerate ja IP-kaamerate terminoloogias.

Veebikaamera on videohõiveseade, millel pole oma protsessorit ja võrguliidest. Veebikaamera jaoks on vaja ühendust arvuti, nutitelefoni või muu seadmega, millel on võrgukaart ja protsessor.

IP kaamera on eraldiseisev seade, millel on oma võrgukaart ja protsessor jäädvustatud video tihendamiseks ja võrku saatmiseks. Seega on IP-kaamera autonoomne miniarvuti, mis ühendub täielikult võrguga ja ei vaja ühendust teise seadmega ning suudab otse võrku edastada.

Madal latentsusaeg(madal latentsus) on IP-kaamerate ja võrguülekannete puhul üsna haruldane nõue. Vajadus töötada väikese latentsusega tekib näiteks siis, kui videovoo allikas suhtleb aktiivselt selle voo vaatajatega.

Kõige sagedamini on mängude puhul vaja madalat latentsust. Selliste näidete hulka kuuluvad: reaalajas videooksjon, videokasiino reaalajas diileriga, interaktiivne võrgusaade koos saatejuhiga, kvadrokopteri kaugjuhtimispult jne.

Live online kasiino diiler tööl.

Tavaline RTSP IP-kaamera edastab tavaliselt videot H.264 koodek ja võib töötada kahes andmeedastusrežiimis: vaheleheidetud Ja põimimata.

Režiim vaheleheidetud kõige populaarsem ja mugavam, sest Selles režiimis edastatakse videoandmeid TCP kaudu kaamera võrguühenduse piires. IP-kaamerast interleavedile levitamiseks tuleb lihtsalt avada/edasida kaamera üks RTSP-port (näiteks 554) väljapoole. Mängija saab kaameraga ühenduse luua ainult TCP kaudu ja selle ühenduse kaudu voogu vastu võtta.

Teine kaamera töörežiim on põimimata. Sel juhul luuakse ühendus protokolli kasutades RTSP/TCP, ja liiklus käib protokolli järgi eraldi RTP/UDP väljaspool loodud TCP kanalit.

Režiim põimimata soodsam video edastamiseks minimaalse latentsusega, kuna see kasutab RTP/UDP, kuid on samal ajal problemaatilisem, kui mängija asub taga NAT.

NAT-i taga oleva mängija IP-kaameraga ühendamisel peab mängija teadma, milliseid väliseid IP-aadresse ja porte saab heli- ja videoliikluse vastuvõtmiseks kasutada. Need pordid on täpsustatud tekstis SDP config, mis saadetakse kaamerasse RTSP-ühenduse loomisel. Kui NAT avati õigesti ja määrati õiged IP-aadressid ja pordid, siis kõik töötab.

Seega, et videot kaamerast minimaalse viivitusega üles võtta, peate kasutama mittevahetama režiimis ja saada videoliiklust UDP kaudu.

Brauserid ei toeta otseselt RTSP/UDP protokollivirnu, kuid toetavad sisseehitatud tehnoloogiaprotokolli pinu WebRTC.

Eriti sarnased on brauseri- ja kaameratehnoloogiad SRTP see on krüpteeritud RTP. Kuid õigeks brauseritesse levitamiseks vajaks IP-kaamera WebRTC-pinu osalist tuge.

Selle kokkusobimatuse kõrvaldamiseks on vaja vahereleeserverit, mis toimib sillana IP-kaamera protokollide ja brauseri protokollide vahel.

Server võtab IP-kaamera voo üle RTP/UDP ja saadab selle WebRTC kaudu ühendatud brauseritele.

WebRTC tehnoloogia töötab vastavalt protokollile UDP ja tagab seega väikese viivituse suunal Server > Brauser. Protokolli kasutades töötab ka IP-kaamera RTP/UDP ja annab väikese suuna viivituse Kaamera > Server.

Kaamera suudab piiratud ressursside ja ribalaiuse tõttu väljastada piiratud arvu vooge. Vaheserveri kasutamine võimaldab skaleerida ülekannet IP-kaamerast suure hulga vaatajateni.

Teisest küljest on serveri kasutamisel lubatud kaks sidejalat:
1) Vaatajate ja serveri vahel
2) Serveri ja kaamera vahel
Sellel topoloogial on mitmeid "funktsioone" või "lõkse". Loetleme need allpool.

Lõks nr 1 – koodekid

Kasutatavad koodekid võivad takistada madalat latentsust ja halvendada süsteemi üldist jõudlust.

Näiteks kui kaamera väljastab 720p videovoogu H.264-vormingus ja ainult VP8 toega Android-nutitelefoni Chrome'i brauser on ühendatud.

Kui ümberkodeerimine on lubatud, tuleb iga ühendatud IP-kaamera jaoks, mis dekodeerib, luua ümberkodeerimise seanss H.264 ja kodeerib sisse VP8. Sel juhul suudab 16-tuumaline kahe protsessoriga server teenindada ainult 10–15 IP-kaamerat, ligikaudu 1 kaamera füüsilise tuuma kohta.

Seega, kui serveri maht ei võimalda kavandatud arvu kaamerate ümberkodeerimist, tuleks ümberkodeerimist vältida. Näiteks teenindage ainult brausereid, mis toetavad H.264, ja pakkuge teistele iOS-i või Androidi jaoks mõeldud mobiilirakenduse kasutamist, mis toetab H.264 kodekit.

Mobiilibrauseris ümberkodeerimisest möödahiilimise võimalusena saate kasutada H.L.S.. Kuid HTTP voogesitusel pole üldse väikest latentsust ja seda ei saa praegu kasutada interaktiivsete saadete jaoks.

Lõks nr 2 – kaamera bitikiirus ja kadu

UDP-protokoll aitab toime tulla latentsusega, kuid võimaldab videopakettide kadumist. Seega, hoolimata madalast latentsusest, võib kaamera ja serveri vahelises võrgus suurte kadude korral pilt kahjustada saada.

Kadude kõrvaldamiseks peate veenduma, et kaamera genereeritud videovoo bitikiirus sobib kaamera ja serveri vahelise ribalaiusega.

Lõks nr 3 – vaataja bitikiirus ja kaod

Igal serveriga ühendatud saatevaaturil on allalaadimisel ka teatud ribalaius.

Kui IP-kaamera saadab voogu, mis ületab vaataja kanali võimalusi (näiteks kaamera saadab 1 Mbps ja vaataja saab ainult nõustuda 500 Kbps), tekivad sellel kanalil suured kaotused ja selle tulemusena video hangub või tugevad artefaktid.

Sel juhul on kolm võimalust:

1. Transkodeerige videovoog iga vaataja jaoks eraldi vajaliku bitikiirusega.
2. Voogude ümberkodeerimine mitte iga ühendatud inimese, vaid vaatajate rühma jaoks.
3. Valmistage ette kaamera voogusid mitme eraldusvõime ja bitikiirusega.

Esimene variantümberkodeerimisega ei sobi igale vaatajale, kuna see kulutab protsessori ressursse isegi 10-15 ühendatud vaatajaga. Kuigi tuleb märkida, et see valik pakub maksimaalset paindlikkust maksimaalse CPU koormuse korral. Need. See on ideaalne valik, näiteks kui edastate vooge ainult 10 geograafiliselt jaotunud inimesele, igaüks neist saab dünaamilise bitikiiruse ja igaüks neist vajab minimaalset latentsust.

Teine variant eesmärk on vähendada serveri CPU koormust ümberkodeerimisrühmade abil. Server loob bitikiiruse järgi mitu rühma, näiteks kaks:

• 200 Kbps
• 1 Mbps

Kui vaatajal pole piisavalt ribalaiust, lülitub ta gruppi, kus saab mugavalt videovoogu vastu võtta. Seega ei võrdu ümberkodeerimise seansside arv vaatajate arvuga nagu esimesel juhul, vaid on fikseeritud arv, näiteks 2, kui transkodeerivad grupid kaks.

Kolmas variant hõlmab serveripoolse ümberkodeerimise täielikku keeldumist ja juba ettevalmistatud videovoogude kasutamist erinevates eraldusvõimetes ja bitikiirustes. Sel juhul on kaamera konfigureeritud väljastama kahte või kolme erineva eraldusvõime ja bitikiirusega voogu ning vaatajad lülituvad nende voogude vahel olenevalt ribalaiusest.

Sel juhul kaob serveri ümberkodeerimise koormus ja see nihkub kaamerale endale, kuna Kaamera on nüüd sunnitud kodeerima kaks või enam voogu ühe asemel.

Selle tulemusena kaalusime vaatajate ribalaiusega kohanemiseks kolme võimalust. Kui eeldame, et üks ümberkodeerimise seanss võtab enda alla 1 serverituuma, saame järgmise CPU koormustabeli:

Tabel näitab, et saame nihutada ümberkodeerimise koormuse kaamerale või edastada ümberkodeerimise serverisse. 2. ja 3. variandid tunduvad kõige optimaalsemad.

RTSP testimine WebRTC-na

On saabunud aeg läbi viia mitmeid katseid, et teha kindlaks tegelik pilt toimuvast. Võtame tõelise IP-kaamera ja viige läbi testid, et mõõta edastuse latentsust.

Testimiseks võtame iidse IP-kaamera D-link DCS-2103 toetusega RTSP ja kodekid H.264 ja G.711.

Kuna kaamera lebas pikka aega kapis koos muude kasulike seadmete ja juhtmetega, pidin selle saatma Lähtesta vajutades ja hoides 10 sekundit all kaamera tagaküljel olevat nuppu.

Pärast võrguga ühenduse loomist süttis kaameral roheline tuli ja ruuter nägi kohalikus võrgus teist seadet IP-aadressiga 192.168.1.37.

Läheme kaamera veebiliidesele ja määrame testimiseks koodekid ja eraldusvõime:

Järgmisena minge võrguseadetesse ja leidke kaamera RTSP-aadress. Sel juhul RTSP aadress live1.sdp, st. Kaamera on saadaval aadressil rtsp://192.168.1.37/live1.sdp

Kaamera saadavust saab hõlpsasti kontrollida kasutades VLC mängija. Meedia – avatud võrguvoog.

Veendusime, et kaamera töötab ja edastab videot RTSP kaudu.

Testimiseks kasutame serverina Web Call Server 5. See on toega voogedastusserver RTSP ja WebRTC protokollid. See ühendub IP-kaameraga läbi RTSP ja vali videovoog. Järgmisena levitage voogu WebRTC.

Pärast installimist peate lülitama serveri RTSP-režiimi põimimata mida me eespool arutasime. Seda saab teha seadistuse lisamisega

Rtsp_interleaved_mode=false
See säte lisatakse konfiguratsioonile flashphoner.properties ja see nõuab serveri taaskäivitamist:

Teeninduse veebikõneserveri taaskäivitamine
Seega on meil server, mis töötab mitte-põimitud skeemi järgi, võtab IP-kaamerast pakette vastu UDP kaudu ja seejärel levitab neid WebRTC (UDP) kaudu.

Testserver asub Frankfurdi andmekeskuses asuvas VPS-serveris, sellel on 2 tuuma ja 2 gigabaiti muutmälu.

Kaamera asub kohalikus võrgus aadressil 192.168.1.37.

Seetõttu peame esimese asjana edastama pordi 554 aadressile 192.168.1.37. TCP/RTSPühendused, et server saaks luua ühenduse meie IP-kaameraga. Selleks lisage ruuteri seadetesse ainult üks reegel:

Reegel käsib ruuteril suunata kogu sissetulev liiklus ümber porti 554 ja IP-aadress 37-le.

Kui teil on sõbralik NAT ja teate välist IP-aadressi, võite alustada testimist serveriga.

Tavaline demopleier Google Chrome'i brauseris näeb välja selline:

RTSP-voo esitamise alustamiseks peate lihtsalt sisestama selle aadressi väljale Voog.
Sel juhul on voo aadress: rtsp://ip-cam/live1.sdp
Siin ip-kaamera see on teie kaamera väline IP-aadress. Server proovib selle aadressiga ühendust luua.

Latentsustestimine VLC vs WebRTC

Pärast IP-kaamera konfigureerimist ja selle testimist VLC, konfigureeris serveri ja testis RTSP voog läbi serveri jaotusega WebRTC, saame lõpuks võrrelda latentsusaega.

Selleks kasutame taimerit, mis kuvab monitori ekraanil sekundi murdosa. Lülitage taimer sisse ja esitage samaaegselt videovoogu VLC kohapeal ja Firefoxi brauseris kaugserveri kaudu.

Ping serverisse 100 ms.
Ping kohapeal 1 ms.

Esimene katse taimeriga näeb välja selline:
Mustal taustal on algne taimer, mis näitab nulli viivitust. Vasakule VLC, paremal Firefox, saamine WebRTC voogesitus kaugserverist.

	Null	VLC	Firefox, WCS
Aeg	50.559	49.791	50.238
Latentsus ms	0	768	321

Selles testis näeme viivitust VLC kaks korda pikem kui viivitus Firefox + veebikõnede server, hoolimata asjaolust, et VLC-s olevat videot esitatakse kohalikus võrgus ja Firefoxis kuvatav video läbib Saksamaal asuva andmekeskuse serveri ja naaseb tagasi. Selle lahknevuse põhjuseks võib olla asjaolu, et VLC töötab üle TCP (interleaved mode) ja sisaldab mõningaid lisapuhvreid video sujuvaks taasesitamiseks.

Tegime latentsusväärtuste salvestamiseks mitu pilti.

Sageli tekib küsimus: kuidas ühendada IP-kaamera NVR-iga, kui seda pole ühilduvusloendis?

On kaks võimalust ONVIF ja RTSP

Alustame ONVIF-protokollist (avatud võrgu videoliidese foorum)

ONVIF on üldtunnustatud protokoll IP-kaamerate, NVR-ide, tarkvara ühiseks kasutamiseks, juhul kui kõik seadmed on erinevatelt tootjatelt. ONVIF-i võib inimeste rahvusvahelise suhtluse jaoks võrrelda inglise keelega.

Veenduge, et ühendatud seadmed toetaksid mõnes seadmes ONVIF-i.
Või ONVIF-i autoriseerimine võib olla keelatud, mis tähendab, et sisselogimine/parool on alati vaikimisi
sõltumata WEBi sisselogimisest/paroolist

Samuti väärib märkimist, et mõned seadmed kasutavaderaldi port ONVIF-protokolli kaudu töötamiseks

Mõnel juhul võib ONVIF-i parool erineda veebipääsu paroolist.

Mis on saadaval ONVIF-i kaudu ühendamisel?

Seadme avastamine

Video edastamine

Heliandmete vastuvõtmine ja edastamine

PTZ kaamera juhtimine

Videoanalüütika (nt liikumistuvastus)

Need parameetrid sõltuvad ONVIF-protokolli versioonide ühilduvusest. Mõnel juhul pole mõned parameetrid saadaval või ei tööta korralikult.

K ja kasutades ONVIF-i

SNR- ja Dahua-salvestites asub ONVIF-protokoll vahekaardil Kaugseade, real Tootja

Valige kanal, millega seade ühendatakse

Valige vahekaardilt Tootja ONVIF

Täpsustage IP-aadress seadmeid

RTSP port jääb vaikeseadeks

Kaamerad kasutamine ONVIF port 8080
(alates 2017. aastast on uutel ONVIF-mudelitel Alpha ja Mira seeriate jaoks port muudetud 80-le)
OMNY kaamerad Alus kasutada ONVIF port 80, registripidajas on see märgitud HTTP-pordina

Nimi

Parool vastavalt seadme parameetritele

Kaugkanal vaikimisi on 1. Kui seade on mitme kanaliga, kuvatakse kanali number.

Dekoodri puhver— videovoo puhverdamine, mis näitab ajaväärtust

Serveri tüüpSiin saab valida TCP, UDP ajakava

TCP- loob ühenduse saatja ja saaja vahel, tagab, et kõik andmed jõuavad saajani muutusteta ja vajalikus järjekorras ning reguleerib ka edastuskiirust.

Erinevalt TCP-st, UDP ei loo eelühendust, vaid alustab lihtsalt andmete edastamist. UDP ei jälgi andmete vastuvõtmist ega dubleeri neid kaotsimineku või vea korral.

UDP on vähem usaldusväärne kui TCP. Kuid teisest küljest tagab see voogude kiirema edastamise kaotatud pakettide uuesti edastamise puudumise tõttu

Ajakava— automaatne tüübituvastus.

Sellised näevad ühendatud seadmed Dahuas välja

Roheline olek tähendab, et salvesti ja kaamera on edukalt ühendatud

Punane olek tähendab, et ühendusega on probleeme. Näiteks ühendusport on vale.

Teine ühendusviis on RTSP(Reaalajas voogesituse protokoll)

RTSPreaalajas voogedastusprotokoll, mis kirjeldab käske videovoo juhtimiseks.

Neid käske kasutades edastatakse videovoog allikast adressaadile

näiteks IP-kaamerast DVR-i või serverisse.

Mis on RTSP kaudu ühenduse loomisel saadaval?

Video edastamine

Heliandmete vastuvõtmine ja edastamine

EelisSee edastusprotokoll seisneb selles, et see ei nõua versioonide ühilduvust.

Tänapäeval toetavad RTSP-d peaaegu kõik IP-kaamerad ja NVR-id

Puudused Protokoll on see, et peale video- ja heliandmete edastamise pole midagi muud saadaval.

Vaatame kaamera ühendamise näidet juurde ja kasutades RTSP-d

RTSP asub vahekaardil Kaugseade, tootja real, SNR-i ja Dahua salvestis on see esitatud kuiKindral

Valige kanal, millega seade ühendatakse

URL-i aadress- siia sisestame päringustringi, mille jaoks kaamera saadab põhilised RTSP voog koos kõrge resolutsioon.

Täiendav URL - Siin sisestage päringustring, mille jaoks kaamera saadab lisaks RTSP voog koos madal eraldusvõime.

Taotluse näidis:

rtsp://172.16.31.61/1 põhivoog

rtsp://172.16.31.61/2 täiendav voog

Miks vajate täiendavat lõime?

Mitme pildisalvestiga ühendatud kohalikul monitoril kasutab salvesti ressursside säästmiseks täiendavat lõime. Näiteks väikestel 16 aknaga piltidel pole Full HD resolutsiooni dekodeerimine üldse vajalik, piisab D1-st. Noh, kui olete avanud 1/4/8 aknad, siis sel juhul dekodeeritakse põhivoog kõrge eraldusvõimega.

Nimivastavalt seadme parameetritele

Parool vastavalt seadme parameetritele

Dekoodri puhvervideovoo puhverdamine, mis näitab ajaväärtust

Serveri tüüp- TCP, UDP, ajakava (sarnaselt ONVIF-protokolliga)

See artikkel annab vastused kõige levinumatele küsimustele, näiteks:

Kas IP-kaamera ühildub NVR-iga?

Ja kui see ühildub, kuidas ühendada!?

IP-kaamerast Interneti-edastuse probleemi lahendamine üldiselt ei nõua WebRTC kasutamist. Kaamera ise on server, sellel on IP-aadress ja selle saab videosisu levitamiseks otse ruuteriga ühendada. Miks siis kasutada WebRTC tehnoloogiat?

Sellel on vähemalt kaks põhjust:

1. Etherneti ülekande vaatajate arvu kasvades annab esmalt tunda kanali paksuse puudumist ja seejärel kaamera enda ressursse.

2. Nagu eespool mainitud, on IP-kaamera server. Kuid milliseid protokolle saab see kasutada video saatmiseks töölauabrauserisse? Mobiilseade? Tõenäoliselt on see HTTP voogesitus, kus videokaadreid või JPEG-pilte edastatakse HTTP kaudu. HTTP voogesitus, nagu teate, ei sobi täielikult reaalajas video voogedastuseks, kuigi see on end hästi tõestanud tellitavas videos, kus voo interaktiivsus ja latentsus ei ole eriti olulised. Tegelikult, kui vaatate filmi, ei muuda mõnesekundiline viivitus seda hullemaks, välja arvatud juhul, kui te vaatate filmi kellegi teisega samal ajal. „Oh ei! Jack tappis ta! - Alice kirjutab 10 sekundit enne traagilist lõppu Bobile vestlusesse spoileri.

Või on see RTSP/RTP ja H.264, sel juhul tuleb brauserisse installida videopleieri pistikprogramm, näiteks VLC või QuickTime. Selline pistikprogramm jäädvustab ja esitab videot, nagu pleier ise. Kuid me vajame tõelist brauseripõhist voogesitust ilma täiendavaid karkusid/pluginaid installimata.

Esmalt teeme IP-kaamerast pildi, et teada saada, mida see seade brauserile täpselt saadab. Katseobjektiks on D-Link DCS 7010L kaamera:

Lisateavet kaamera installimise ja konfigureerimise kohta saate lugeda allpool, kuid siin vaatame lihtsalt, mida see video voogesituse jaoks kasutab. Veebiliidese kaudu kaamera administraatori paneeli sisenedes näeme midagi sellist (vabandan maastiku pärast):

Pilt avaneb kõigis brauserites ja hangub ühtlaselt, umbes kord sekundis. Arvestades, et nii kaamera kui sülearvuti, millelt vooge vaatame, on ühendatud sama ruuteriga, peaks kõik olema sujuv ja ilus, kuid see pole nii. Näeb välja nagu HTTP. Käivitagem Wireshark, et oma oletusi kinnitada:

Siin näeme 1514 baiti pikkust TCP fragmentide jada

Ja viimane HTTP 200 OK vastuvõetud JPEG pikkusega:

Me ei vaja sellist voogesitust. Mitte sujuv, häirib HTTP-päringuid. Kui palju selliseid taotlusi sekundis suudab kaamera käsitleda? On põhjust arvata, et 10 pealtvaataja juures või varem kõverdub kaamera turvaliselt või hakkab kohutavalt tõmblema ja tekitab slaide.

Kui vaatate kaamera administraatori paneeli HTML-lehte, näete seda huvitavat koodi:

If(brauser_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=""; if (g_isIPv6) //sest ipv6 ei toeta rtsp-d. var host = g_netip;"; //alert(o); DW(o); )

RTSP/RTP on täpselt see, mida vajate korralikuks video taasesituseks. Kuid kas see töötab brauseris? - Ei. Aga kui installite QuickTime'i pistikprogrammi, siis kõik töötab. Kuid me teeme puhtalt brauseripõhist voogesitust.

Siinkohal võib mainida ka Flash Playerit, mis suudab läbi sobiva serveri nagu Wowza vastu võtta RTSP-st, RTP-st, H.264-st konverteeritud RTMP-voogu. Kuid Flash Player, nagu teate, on ka brauseri pistikprogramm, kuigi see on võrreldamatult populaarsem kui VLC või QuickTime.

Sel juhul testime sama RTSP/RTP re-streamingut, kuid mänguseadmena kasutatakse WebRTC-ga ühilduvat brauserit ilma täiendavate brauseri pluginate või muude karkudeta. Seadistame edastusserveri, mis võtab voo IP-kaamerast ja saadab selle Internetti suvalisele arvule kasutajatele, kes kasutavad WebRTC-d toetavaid brausereid.

IP-kaamera ühendamine

Nagu eelpool mainitud, valiti testimiseks lihtne D-Link DCS-7010L IP kaamera. Peamine valikukriteerium oli siin seadme tugi RTSP-protokollile, kuna selle kaudu saab meie server kaamerast videovoogu.

Kaamera ühendame ruuteriga kaasasoleva patch juhtme abil. Pärast toite sisselülitamist ja ruuteriga ühenduse loomist võttis kaamera DHCP kaudu IP-aadressi, meie puhul oli see 192.168.1.34 (kui lähete ruuteri sätetesse, näete, et seade DCS 7010L on ühendatud - see on kõik ). On aeg kaamerat testida.

Kaamera administraatori veebiliidese juurde pääsemiseks avage brauseris määratud IP-aadress 192.168.1.34. Vaikimisi parooli pole.

Nagu näete, edastatakse kaamera videot administraatoripaneelil õigesti. Samal ajal on märgatav perioodiline raputamine. Selle parandame WebRTC abil.

Kaamera seadistamine

Esiteks keelame kaamera seadetes autentimise – testimise raames anname voo kõigile, kes küsivad. Selleks avage kaamera veebiliidese seaded Seadistamine – võrk ja määrake valiku väärtus Autentimine keelamiseks.

Seal kontrollime ka RTSP-protokolli pordi väärtust vaikimisi 554. Edastatava video vormingu määrab kasutatav profiil. Kaameras saab neid seadistada kuni kolm, me kasutame esimest, live1.sdp - vaikimisi on see seadistatud video jaoks H.264 ja heli jaoks G.711. Vajadusel saate seadeid jaotises muuta Seadistamine – heli ja video.

Nüüd saate RTSP kaudu kontrollida kaamera tööd. Avage VLC Player (saate kasutada mis tahes muud mängijat, mis toetab RTSP-d – QuickTime, Windows Media Player, RealPlayer jne) ja määrake dialoogiaknas Ava URL kaamera RTSP-aadress: rtsp://192.168.1.34/live1.sdp

Noh, kõik töötab nii nagu peab. Kaamera taasesitab RTSP-protokolli kaudu regulaarselt pleieris olevat videovoogu.

Muide, striimi taasesitatakse üsna sujuvalt ja ilma artefaktideta. Sama ootame ka WebRTC-lt.

Serveri installimine

Seega on kaamera installitud, lauaarvuti mängijatega testitud ja serveri kaudu edastamiseks valmis. Kasutades whatismyip.com määrame kaamera välise IP-aadressi. Meie puhul oli see 178.51.142.223. Jääb üle vaid ruuterile öelda, et RTSP kaudu pordi 554 kaudu pääsemisel edastatakse sissetulevad päringud IP-kaamerasse.

Sisestage ruuterisse sobivad sätted...

...ja kontrollige telneti abil välist IP-aadressi ja RTSP-porti:

Telnet 178.51.142.223 554

Olles veendunud, et sellel pordil on vastus, jätkame WebRTC-serveri installimisega.

Virtuaalserver Centos 64 bitis Amazon EC2-s vastutab hostimise eest.
Jõudlusprobleemide vältimiseks valisime ühe VCPU-ga eksemplari m3.medium:

Jah, jah, on ka Linode ja DigitalOcean, aga antud juhul tahtsin Amazoni proovida.
Tulevikku vaadates kirjutan, et Amazon EC2 juhtpaneelil peate lisama mitu reeglit (edasipordid), ilma milleta näide ei tööta. Need on pordid WebRTC (SRTP, RTCP, ICE) liikluse jaoks ja pordid RTSP/RTP liikluse jaoks. Kui proovite, peaks Amazoni reeglites olema sissetuleva liikluse jaoks midagi sarnast:

Muide, DigitalOceaniga on kõik lihtsam, lihtsalt avage need pordid tulemüüril või lülitage viimane välja. Viimaste kogemuste kohaselt väljastavad nad endiselt staatilise IP-aadressi ega vaeva NAT-idega, mis tähendab, et pordi edastamine, nagu Amazoni puhul, pole vajalik.

Kasutame Flashphoneri WebRTC Media & Broadcasting Serverit serveritarkvarana, mis edastab RTSP/RTP voo WebRTC-le. Voogedastusserver on väga sarnane Wowzaga, mis suudab RTSP/RTP vooge Flashi voogesitada. Ainus erinevus on see, et see voog saadetakse WebRTC-le, mitte Flashile. Need. aus DTLS liigub brauseri ja serveri vahel, luuakse SRTP-seanss ja VP8-sse kodeeritud voog jõuab vaatajani.

Installimiseks vajame juurdepääsu SSH-le.

Spoileri all on käivitatud käskude üksikasjalik kirjeldus

1. Laaditi alla serveri installiarhiiv:
$wget flashphoner.com/downloads/builds/WCS/3.0/x8664/wcs3_video_vp8/FlashphonerMediaServerWebRTC-3.0/FlashphonerMediaServerWebRTC-3.0.868.tar.gz
2. Laiendatud:
$tar -xzf FlashphonerMediaServerWebRTC-3.0.868.tar.gz
3. Installitud:
$cd FlashphonerMediaServerWebRTC-3.0.868
$./install.sh
Installimise käigus sisestasime serveri välise IP-aadressi: 54.186.112.111 ja sisemise 172.31.20.65 (sama mis privaatne IP).
4. Käivitas server:
$service veebikõneserveri käivitamine
5. Kontrollisin logisid:
$tail – f /usr/local/FlashphonerWebCallServer/logs/server_logs/flashphoner.log
6. Veendusime, et server on käivitunud ja töövalmis:
$ps aux | grep Flashphoner
7. Installitud ja käivitatud apache:
$yum installi httpd
$teenus httpd algus
8. Laadige veebifailid alla ja asetage need standardsesse Apache kausta /var/www/html
cd /var/www/html
$wget github.com/flashphoner/flashphoner_client/archive/wcs_media_client.zip
$unzip webrtc_media_client.zip
9. Sisestasite faili flashphoner.xml konfiguratsiooni serveri IP-aadressi:
10. Peatas tulemüüri.
$service iptables peatub

Teoreetiliselt oleks punkti 10 asemel õige seada kõik vajalikud pordid ja tulemüürireeglid, kuid testimise eesmärgil otsustasime tulemüüri lihtsalt keelata.

Serveri häälestamine

Tuletagem meelde, et meie WebRTC saate struktuur on järgmine:

Oleme selle diagrammi põhielemendid juba installinud, jääb üle vaid interaktsioonide "nooled" kindlaks teha.

Ühenduse brauseri ja WebRTC serveri vahel pakub veebiklient, mis on saadaval Githubis:. JS-, CSS- ja HTML-failide komplekt visatakse lihtsalt sisse /var/www/html paigaldamise etapis (vt ülaltoodud punkti 9 spoileri all).

Brauseri ja serveri vaheline suhtlus on konfigureeritud XML-i konfiguratsioonifailis flashphoner.xml. Seal peate sisestama serveri IP-aadressi, et veebiklient saaks WebRTC serveriga ühenduse luua HTML5 Websocketsi kaudu (punkt 9 ülal).

Serveri seadistamine lõpeb siin, saate kontrollida selle toimimist:

Ava brauseris veebikliendi leht index.html (selleks installiti Apache samasse Amazoni serverisse käsuga yum -y installige httpd):

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

Siin webrtc-ipcam.ddns.net on tasuta domeen, mis on saadud dünaamilise DNS-serveri noip.com kaudu, mis viitab meie välisele IP-aadressile. Käskisime ruuteril suunata RTSP-päringud ümber aadressile 192.168.1.34 vastavalt NAT-i võrguaadressi tõlkimise reeglitele (vt ka ülalt).
Parameeter id=rtsp://webrtc-ipcam.ddns.net/live1.sdp määrab esitatava voo URL-i. WebRTC-server küsib kaameralt vooge, töötleb neid ja saadab need brauserisse taasesitamiseks WebRTC kaudu. Võib-olla toetab teie ruuter DDNS-i. Kui ei, siis on IP-kaameral endal selline tugi:

Ja ruuteris endas näeb DDNS-i tugi välja selline:

Nüüd saate alustada testimist ja tulemusi hinnata.

Testimine

Pärast lingi avamist brauseris luuakse ühendus WebRTC serveriga, mis saadab IP-kaamerale päringu videovoo vastuvõtmiseks. Kogu protsess võtab paar sekundit.

Sel ajal luuakse veebisockettide kaudu ühendus brauseri ja serveri vahel, seejärel küsib server RTSP kaudu IP-kaamerat, võtab RTP kaudu vastu H.264 voo ja kodeerib selle ümber VP8 / SRTP-ks – mis lõpuks mängib WebRTC brauserit.

Video allosas kuvatakse videovoo URL, mida saab kopeerida ja avada vaatamiseks teisest brauserist või vahekaardilt.

Me veendume, et see on tõesti WebRTC.

Mis siis, kui meid peteti ja IP-kaamera video edastatakse uuesti HTTP kaudu? Ärgem vaadakem pilti tühikäigul, vaid kontrolligem, millist liiklust me tegelikult saame. Loomulikult käivitame Chrome'is uuesti Wiresharki ja silumiskonsooli. Chrome'i brauseri konsoolis näeme järgmist.

Seekord midagi ei vilgu ja HTTP kaudu edastatud pilte pole näha. Seekord näeme ainult Websocketi raame ja enamik neist on pingi/pongi tüüpi, et säilitada Websocketi seanssi. Huvitavad kaadrid: ühendage, valmistaRtspSession ja onReadyToPlay – see on serveriga ühenduse loomise järjekord: esmalt Websocketi ühendus ja seejärel taasesituse vootaotlus.

Siin on see, mida see näitab chrome://webrtc-internals

Graafikute järgi on meil IP-kaamera bitikiirus 1Mbps. Samuti on väljaminev liiklus, tõenäoliselt on need RTCP ja ICE paketid. RTT Amazoni serverisse on umbes 300 millisekundit.

Vaatame nüüd Wiresharki, näete selgelt serveri IP-aadressi UDP-liiklust. Alloleval pildil on paketid 1468 baiti. See on WebRTC. Täpsemalt VP8 videokaadreid kandvad SRTP paketid, mida saame jälgida brauseri ekraanil. Lisaks lipsavad läbi STUN-päringud (madalaim pakett pildil) - see on WebRTC ICE, mis kontrollib hoolikalt ühendust.

Märkimist väärib ka video taasesituse suhteliselt madal latentsusaeg (ping andmekeskusesse oli umbes 250 ms). WebRTC töötab SRTP/UDP kaudu ja lõppude lõpuks on see kiireim viis pakettide edastamiseks, erinevalt HTTP-st, RTMP-st ja muudest TCP-laadsetest voogedastusmeetoditest. Need. Silmaga nähtav viivitus peaks olema RTT + brauseri puhverdamise, dekodeerimise ja taasesituse aeg. Visuaalselt on see antud juhul nii - silm peaaegu ei näe viivitust, see on alla 500 millisekundi.

Järgmine test on teiste vaatajate ühendamine. Mul õnnestus avada 10 Chrome'i akent ja igaüks neist näitas pilti. Samal ajal hakkas Chrome ise veidi nüriks jääma. Teises arvutis 11. akent avades jäi taasesitus sujuvaks.

Teave WebRTC kohta mobiilseadmetes

Nagu teate, toetavad WebRTC-d Androidi platvormil Chrome'i ja Firefoxi brauserid.
Vaatame, kas meie saadet seal kuvatakse:

Pildil on HTC telefon, Firefoxi brauser kuvab kaamerast pärit videot. Taasesituse sujuvuses töölaualt erinevusi ei ole.

Järeldus

Selle tulemusena saime minimaalse pingutusega käivitada WebRTC võrguülekande IP-kaamerast mitmesse brauserisse. Mingit parmupilliga tantsimist ega raketiteadust polnud vaja – vaid algteadmised Linuxist ja SSH-konsoolist.

Ülekande kvaliteet oli vastuvõetaval tasemel ja taasesituse viivitus oli silmale nähtamatu.

Kokkuvõtteks võib öelda, et brauseripõhistel WebRTC saadetel on õigus eksisteerida, sest meie puhul pole WebRTC enam kark ega pistikprogramm, vaid tõeline platvorm video brauseris esitamiseks.

Miks me ei näe WebRTC laialdast kasutuselevõttu?

Peamine takistus on võib-olla koodekite puudumine. WebRTC kogukond ja müüjad peaksid pingutama ja tutvustama WebRTC-s H.264 kodekit. VP8 vastu pole midagi öelda, aga miks loobuda miljonitest ühilduvatest seadmetest ja tarkvarast, mis H.264-ga töötavad? Patendid, sellised patendid...

Teisel kohal ei ole brauserite täielik tugi. Näiteks IE ja Safari puhul jääb küsimus lahtiseks ja seal tuleb lülituda teist tüüpi voogedastusse või kasutada pistikprogrammi nagu webrtc4all.

Seega loodame tulevikus näha huvitavamaid lahendusi, mille puhul ei ole vaja voogude ümberkodeerimist ja teisendamist ning enamik brausereid saab otse erinevatelt seadmetelt vooge esitada.

Mugav videoülekannete vaatamine või seda saab konfigureerida personaalarvuti tarkvaraliste multimeediumipleierite abil. Täna vaatame, kuidas konfigureerida RTSP-voogu Dahua Technology võrguseadmete jaoks ühes populaarseimas pleieris VLC Media Player.

RTSP (Real Time Streaming Protocol) on protokoll, mis võimaldab kasutajal hüperlingi ja multimeediumipleieri (meie puhul VLC Media Player) abil kaugesitada multimeediumiandmete voogu (heli ja video).

Kui teil on vaja videovoogu konfigureerida, toimige järgmiselt.

1. Kõigepealt peate alla laadima ja installima VLC Media Playeri, mis on ametlikul veebisaidil vabalt saadaval.
2. Klõpsake menüükäsku Media – Open Network Stream (Ava URL).
3. Sisestage viipareale RTSP võrguaadress.
4. Kui videopilt ekraanile ilmub, vajutage esitusnuppu.

Lingi selgitus RTSP

Näide:

rtsp:// :@:/cam/realmonitor?channel= &alatüüp=

Kus:

: Kasutajanimi (sisselogimine).

: parool.

: võrguvideokaamera IP-aadress.

: Vaikimisi port on 554. Seda väärtust saab ignoreerida.

: kanali number. Nummerdamine algab 1-st.

: voo tüüp. Tähendus põhilõime on 0, lisalõime 1 on 1, lisalõime 2 on 2. Näiteks lisalõime number 1 link oleks järgmine:

rtsp://admin: [e-postiga kaitstud]:554/cam/realmonitor?channel=1&subtype=1

Dahua Technology IP-videokaamerad toetavad TCP ja UDP andmeedastusprotokolle. Kui port 554 on muudetud, muutke seda videokaamera sätete (veebiliides) vastaval väljal.

Kui teil on RTSP-voo seadistamisel probleeme, vaadake vastavat jaotist.

RTSP (Real Time Streaming Protocol)– reaalajas voogedastusprotokoll, mis sisaldab lihtsat põhikäskude komplekti videovoo juhtimiseks.

RTSP-allikate ja IP-kaamerate ühendamine videokonverentsidel

RTSP-protokoll võimaldab igal TrueConfi kasutajal luua kaugobjektide jälgimiseks ühenduse IP-videokaamerate ja muude meediumisisu allikatega, mis edastavad seda protokolli kasutades. Samuti saab kasutaja selliste kaameratega ühenduse luua, et videokonverentsi ajal pilte edastada.

Tänu RTSP-protokolli toele saavad TrueConf Serveri kasutajad mitte ainult ühenduda IP-kaameratega, vaid ka edastada videokonverentse RTSP-mängijatele ja meediumiserveritele. Loe lähemalt RTSP saadete kohta.

IP-kaamerate kasutamise eelised TrueConfi tarkvaralahendustega

• Paigaldades IP-kaamera kontorisse või tööstuslikku töökotta ja ühendades sellega igal sobival ajal, saate juhtida oma ettevõtte tootmisprotsessi.
• Saate jälgida kaugobjekte ööpäevaringselt. Näiteks kui lähete puhkusele ja ei soovi oma korterit järelevalveta jätta, paigaldage sinna lihtsalt üks või mitu IP-kaamerat. Helistades arvutist ühele neist kaameratest, kuhu on installitud TrueConfi klientrakendus, saate igal ajal oma korteriga ühenduse luua ja vaadata reaalajas, mis seal toimub.
• Windowsi, Linuxi ja macOS-i TrueConfi klientrakendustes on kõigil kasutajatel juurdepääs videokonverentside salvestamise võimalusele, tänu millele saate videovalve ajal salvestada mis tahes sündmusi ja saada nende kohta dokumentaalseid tõendeid.