Ըստ որոշ տեղեկությունների՝ այսօր կան հարյուրավոր միլիոններ IP տեսախցիկներ տեսահսկման համար. Այնուամենայնիվ, վիդեո նվագարկման հետաձգումը նրանց բոլորի համար կարևոր չէ: Տեսահսկումը սովորաբար տեղի է ունենում «ստատիկ» - հոսքը գրանցվում է պահեստում և կարող է վերլուծվել շարժման համար: Տեսահսկման համար մշակված բազմաթիվ ծրագրային և ապարատային լուծումներ կան, որոնք լավ են կատարում իրենց աշխատանքը:
Այս հոդվածում մենք կանդրադառնանք մի փոքր այլ հավելվածի IP տեսախցիկներ, մասնավորապես՝ առցանց հեռարձակումների կիրառում, որտեղ դա պահանջվում է կապի ցածր ուշացում:
Նախ, եկեք պարզենք վեբ-տեսախցիկների և IP տեսախցիկների վերաբերյալ տերմինաբանության մեջ առկա ցանկացած հնարավոր թյուրիմացություն:
Վեբ - տեսախցիկտեսանկարահանող սարք է, որը չունի սեփական պրոցեսոր և ցանցային ինտերֆեյս։ Վեբ-տեսախցիկը պահանջում է միացում համակարգչի, սմարթֆոնի կամ այլ սարքի, որն ունի ցանցային քարտ և պրոցեսոր:
IP տեսախցիկինքնուրույն սարք է, որն ունի իր սեփական ցանցային քարտը և պրոցեսորը՝ նկարահանված տեսանյութը սեղմելու և այն ցանց ուղարկելու համար: Այսպիսով, IP տեսախցիկը ինքնուրույն մինի-համակարգիչ է, որը լիովին միանում է ցանցին և չի պահանջում միացում այլ սարքի հետ և կարող է ուղղակիորեն հեռարձակվել դեպի ցանց:
Ցածր ուշացում(ցածր ուշացում) բավականին հազվադեպ պահանջ է IP տեսախցիկների և առցանց հեռարձակումների համար: Ցածր հետաձգման հետ աշխատելու անհրաժեշտություն է առաջանում, օրինակ, եթե տեսահոսքի աղբյուրը ակտիվորեն շփվում է այս հոսքի դիտողների հետ:
Ամենից հաճախ խաղերի օգտագործման դեպքերում անհրաժեշտ է ցածր ուշացում: Նման օրինակները ներառում են՝ իրական ժամանակում վիդեո աճուրդ, վիդեո կազինո ուղիղ դիլերի հետ, ինտերակտիվ առցանց հեռուստաշոու հաղորդավարի հետ, քառակուսի մեքենայով հեռակառավարում և այլն:
Կենդանի առցանց կազինո դիլեր աշխատավայրում.
Սովորական RTSP IP տեսախցիկը սովորաբար տեսանյութ է հեռարձակում հ.264կոդեկ և կարող է գործել տվյալների փոխանցման երկու ռեժիմով՝ խճճվածԵվ չխճճված.
Ռեժիմ խճճվածամենահայտնին և հարմարը, քանի որ Այս ռեժիմում վիդեո տվյալները փոխանցվում են TCP-ի միջոցով տեսախցիկին ցանցային միացման շրջանակներում: IP տեսախցիկից միախառնվածին բաշխելու համար պարզապես անհրաժեշտ է բացել/փոխանցել տեսախցիկի մեկ RTSP պորտը (օրինակ 554) դեպի դրս: Նվագարկիչը կարող է միանալ տեսախցիկին միայն TCP-ի միջոցով և վերցնել հոսքը այս կապի շրջանակներում:
Երկրորդ տեսախցիկի գործառնական ռեժիմն է չխճճված. Այս դեպքում կապը հաստատվում է արձանագրության միջոցով RTSP/TCP, իսկ երթեւեկությունն ընթանում է առանձին՝ ըստ արձանագրության RTP / UDPստեղծված TCP ալիքից դուրս:
Ռեժիմ չխճճվածավելի բարենպաստ է նվազագույն ուշացումով տեսանյութեր հեռարձակելու համար, քանի որ այն օգտագործում է RTP / UDP, բայց միևնույն ժամանակ ավելի խնդրահարույց է, եթե խաղացողը գտնվում է հետևում ՆԱՏ.
NAT-ի հետևում գտնվող նվագարկչի IP տեսախցիկին միանալիս նվագարկիչը պետք է իմանա, թե որ արտաքին IP հասցեներն ու նավահանգիստները կարող է օգտագործել աուդիո և վիդեո տրաֆիկ ստանալու համար: Այս նավահանգիստները նշված են տեքստային SDP կազմաձևում, որն ուղարկվում է տեսախցիկին, երբ հաստատվում է RTSP կապ: Եթե NAT-ը ճիշտ է բացվել, և ճիշտ IP հասցեներն ու պորտերը որոշել են, ապա ամեն ինչ կաշխատի:
Այսպիսով, տեսախցիկից նվազագույն ուշացումով տեսանյութ վերցնելու համար անհրաժեշտ է օգտագործել չմիջամտելռեժիմ և ստացիր վիդեո տրաֆիկ UDP-ի միջոցով:
Զննարկիչները ուղղակիորեն չեն աջակցում RTSP/UDP արձանագրությունների փաթեթին, բայց աջակցում են բնիկ տեխնոլոգիական արձանագրությունների փաթեթին: WebRTC.
Բրաուզերի և տեսախցիկի տեխնոլոգիաները շատ նման են, մասնավորապես SRTPայն կոդավորված է RTP. Բայց բրաուզերներին ճիշտ բաշխման համար IP տեսախցիկը մասնակի աջակցության կարիք կունենա WebRTC փաթեթի համար:
Այս անհամատեղելիությունը վերացնելու համար անհրաժեշտ է միջանկյալ ռելե սերվեր, որը կամուրջ կգործի IP տեսախցիկի արձանագրությունների և բրաուզերի արձանագրությունների միջև:
Սերվերը վերցնում է հոսքը IP տեսախցիկի միջոցով RTP / UDPև այն ուղարկում է միացված բրաուզերներին WebRTC-ի միջոցով:
WebRTC տեխնոլոգիան աշխատում է ըստ արձանագրության UDPև այդպիսով ապահովում է ուղղության ցածր ուշացում Սերվեր > Զննարկիչ. IP տեսախցիկը նույնպես աշխատում է արձանագրության միջոցով RTP / UDPև ապահովում է ուղղության ցածր ուշացում Տեսախցիկ > Սերվեր.
Տեսախցիկը կարող է թողարկել սահմանափակ քանակությամբ հոսքեր՝ սահմանափակ ռեսուրսների և թողունակության պատճառով: Միջանկյալ սերվերի օգտագործումը թույլ է տալիս չափել հեռարձակումը IP տեսախցիկից մինչև մեծ թվով դիտողներ:
Մյուս կողմից, սերվեր օգտագործելիս միացված են հաղորդակցման երկու ոտք.
1) հեռուստադիտողների և սերվերի միջև
2) սերվերի և տեսախցիկի միջև
Այս տոպոլոգիան ունի մի շարք «առանձնահատկություններ» կամ «որոգայթներ»: Մենք դրանք թվարկում ենք ստորև։
Թակարդ #1 - Կոդեկներ
Օգտագործված կոդեկները կարող են խոչընդոտ հանդիսանալ ցածր հետաձգման աշխատանքի համար և կարող են վատթարացնել համակարգի ընդհանուր աշխատանքը:Օրինակ, եթե տեսախցիկը թողարկում է 720p վիդեո հոսք H.264-ում, և միացված է Chrome դիտարկիչը Android սմարթֆոնի վրա, որն ունի միայն VP8 աջակցություն:
Երբ տրանսկոդավորումը միացված է, տրանսկոդավորման նիստ պետք է ստեղծվի միացված IP տեսախցիկներից յուրաքանչյուրի համար, որը վերծանում է հ.264և կոդավորում է VP8. Այս դեպքում 16 միջուկանոց երկպրոցեսորային սերվերը կկարողանա սպասարկել միայն 10-15 IP տեսախցիկ՝ յուրաքանչյուր ֆիզիկական միջուկի համար 1 տեսախցիկի մոտավոր արագությամբ:
Հետևաբար, եթե սերվերի հզորությունը թույլ չի տալիս վերծանել տեսախցիկների պլանավորված քանակությունը, ապա պետք է խուսափել տրանսկոդավորումից: Օրինակ՝ սպասարկեք միայն այն բրաուզերները, որոնք աջակցում են H.264-ին, իսկ մյուսներին առաջարկեք օգտագործել տեղական բջջային հավելված iOS-ի կամ Android-ի համար, որն աջակցում է H.264 կոդեկին:
Որպես բջջային բրաուզերում տրանսկոդավորումը շրջանցելու տարբերակ, կարող եք օգտագործել Հ.Լ.Ս.. Բայց HTTP հոսքը բացարձակապես ցածր ուշացում չունի և ներկայումս չի կարող օգտագործվել ինտերակտիվ հեռարձակումների համար:
Թակարդ # 2 - Տեսախցիկի բիթային արագություն և կորուստ
UDP արձանագրությունն օգնում է հաղթահարել հետաձգումը, բայց թույլ է տալիս կորցնել վիդեո փաթեթները: Հետևաբար, չնայած ցածր հետաձգմանը, եթե տեսախցիկի և սերվերի միջև ցանցում մեծ կորուստներ կան, նկարը կարող է վնասվել:
Կորուստները վերացնելու համար դուք պետք է համոզվեք, որ տեսախցիկի ստեղծած տեսահոսքը ունի բիթային արագություն, որը տեղավորվում է տեսախցիկի և սերվերի միջև հատկացված թողունակության մեջ:
Թակարդ #3 - Դիտողի բիթային արագություն և կորուստներ
Սերվերին միացված յուրաքանչյուր հեռարձակման դիտող ունի նաև որոշակի թողունակություն Ներբեռնման վրա:Եթե IP տեսախցիկը ուղարկում է հոսք, որը գերազանցում է հեռուստադիտողի ալիքի հնարավորությունները (օրինակ՝ տեսախցիկը ուղարկում է. 1 Մբիթ/վրկ, իսկ հեռուստադիտողը կարող է միայն ընդունել 500 Կբիթ/վրկ), ապա այս ալիքում մեծ կորուստներ կլինեն, և արդյունքում՝ տեսանյութերի սառեցում կամ ուժեղ արտեֆակտներ։
Այս դեպքում կա երեք տարբերակ.
- Տրանսկոդավորեք տեսանյութի հոսքը յուրաքանչյուր դիտողի համար՝ պահանջվող բիթ արագությամբ:
- Transcode հոսքերը ոչ թե յուրաքանչյուր կապակցված անձի, այլ դիտողների խմբի համար:
- Նախապես պատրաստեք հեռարձակումները տեսախցիկից մի քանի լուծումներով և բիթային արագությամբ:
Երկրորդ տարբերակայն է նվազեցնել բեռը սերվերի պրոցեսորի վրա՝ օգտագործելով տրանսկոդավորման խմբերը: Սերվերը ստեղծում է մի քանի խմբեր ըստ բիթերի արագության, օրինակ՝ երկու.
- 200 Կբիթ/վրկ
- 1 Մբիթ/վրկ
Երրորդ տարբերակենթադրում է սերվերի կողմից տրանսկոդավորման ամբողջական մերժում և արդեն պատրաստված վիդեո հոսքերի օգտագործում տարբեր լուծումներով և բիթերի արագությամբ: Այս դեպքում տեսախցիկը կազմաձևված է այնպես, որ թողարկի երկու կամ երեք հոսք տարբեր լուծաչափերով և բիթային արագությամբ, և դիտողները փոխում են այս հոսքերի միջև՝ կախված դրանց թողունակությունից:
Այս դեպքում սերվերի տրանսկոդավորման բեռը հեռանում է և տեղափոխվում է հենց տեսախցիկ, քանի որ Այժմ տեսախցիկը ստիպված է միայն մեկի փոխարեն կոդավորել երկու կամ ավելի հոսքեր:
Արդյունքում մենք դիտարկեցինք հեռուստադիտողների թողունակությանը հարմարվելու երեք տարբերակ: Եթե ենթադրենք, որ մեկ տրանսկոդավորման նիստը վերցնում է 1 սերվերի միջուկ, ապա մենք ստանում ենք CPU-ի բեռնվածության հետևյալ աղյուսակը.
Աղյուսակը ցույց է տալիս, որ մենք կարող ենք տրանսկոդավորման բեռը տեղափոխել տեսախցիկ կամ փոխանցել տրանսկոդավորումը սերվերին: 2-րդ և 3-րդ տարբերակները, թվում է, ամենաօպտիմալն են:
RTSP-ի փորձարկում որպես WebRTC
Եկել է ժամանակը մի քանի թեստեր անցկացնելու՝ պարզելու տեղի ունեցողի իրական պատկերը։ Եկեք իրական IP տեսախցիկ վերցնենք և փորձարկում անցկացնենք հեռարձակման հետաձգումը չափելու համար:Փորձարկման համար վերցնենք հնագույն IP տեսախցիկ D-link DCS-2103աջակցությամբ RTSPև կոդեկներ հ.264 եւ Գ.711.
Քանի որ տեսախցիկը երկար ժամանակ պառկած էր պահարանում այլ օգտակար սարքերով և լարերով, ես ստիպված էի ուղարկել այն Վերականգնելսեղմելով և պահելով տեսախցիկի հետևի կոճակը 10 վայրկյան:
Ցանցին միանալուց հետո տեսախցիկի կանաչ լույսը վառվեց, և երթուղիչը տեսավ մեկ այլ սարք լոկալ ցանցում՝ 192.168.1.37 IP հասցեով:
Մենք գնում ենք տեսախցիկի վեբ ինտերֆեյս և սահմանում ենք կոդեկները և լուծումը փորձարկման համար.
Հաջորդը, անցեք ցանցի կարգավորումներ և պարզեք տեսախցիկի RTSP հասցեն: Այս դեպքում RTSP հասցեն live1.sdp, այսինքն. Տեսախցիկը հասանելի է rtsp://192.168.1.37/live1.sdp
Տեսախցիկի առկայությունը կարելի է հեշտությամբ ստուգել՝ օգտագործելով VLC նվագարկիչ. Մեդիա - Բաց ցանցային հոսք:
Մենք համոզվեցինք, որ տեսախցիկը աշխատում է և տեսանյութ է փոխանցում RTSP-ի միջոցով:
Մենք կօգտագործենք Web Call Server 5-ը որպես սերվեր՝ փորձարկման համար: Սա աջակցությամբ հոսքային սերվեր է RTSP և WebRTCարձանագրությունները։ Այն կմիանա IP տեսախցիկին միջոցով RTSPև վերցրեք տեսանյութի հոսքը: Հաջորդը, տարածեք հոսքը WebRTC.
Տեղադրվելուց հետո անհրաժեշտ է սերվերը միացնել RTSP ռեժիմին չխճճվածորը մենք քննարկեցինք վերևում: Դա կարելի է անել՝ ավելացնելով պարամետր
Rtsp_interleaved_mode=false
Այս պարամետրը ավելացվել է flashphoner.properties կազմաձևին և պահանջում է սերվերի վերաբեռնում.
Ծառայության վեբ զանգերի սերվերի վերագործարկում
Այսպիսով, մենք ունենք սերվեր, որը գործում է ըստ չխճճված սխեմայի, ընդունում է փաթեթներ IP տեսախցիկից UDP-ի միջոցով, այնուհետև դրանք բաշխում WebRTC-ի (UDP) միջոցով:
Փորձարկման սերվերը գտնվում է Ֆրանկֆուրտի տվյալների կենտրոնում տեղակայված VPS սերվերի վրա, ունի 2 միջուկ և 2 գիգաբայթ օպերատիվ հիշողություն:
Տեսախցիկը գտնվում է լոկալ ցանցում՝ 192.168.1.37։
Հետևաբար, առաջին բանը, որ մենք պետք է անենք, 554 պորտը փոխանցելն է 192.168.1.37 հասցեին՝ մուտքի համար TCP/RTSPմիացումներ, որպեսզի սերվերը կարողանա կապ հաստատել մեր IP տեսախցիկի հետ: Դա անելու համար երթուղիչի կարգավորումներում ավելացրեք ընդամենը մեկ կանոն.
Կանոնն ասում է երթուղիչին վերահղել ամբողջ մուտքային տրաֆիկը դեպի 554 նավահանգիստ, իսկ IP հասցեն՝ 37:
Եթե դուք ունեք բարեկամական NAT և գիտեք արտաքին IP հասցեն, ապա կարող եք սկսել փորձարկումը սերվերի հետ:
Google Chrome բրաուզերի ստանդարտ ցուցադրական նվագարկիչն ունի հետևյալ տեսքը.
RTSP հոսքի նվագարկումը սկսելու համար պարզապես անհրաժեշտ է դաշտում մուտքագրել դրա հասցեն Հոսք.
Այս դեպքում հոսքի հասցեն է. rtsp://ip-cam/live1.sdp
Այստեղ ip-camսա ձեր տեսախցիկի արտաքին IP հասցեն է: Սերվերը կփորձի կապ հաստատել այս հասցեի հետ:
Հետաձգման փորձարկում VLC ընդդեմ WebRTC
Այն բանից հետո, երբ մենք կազմաձևեցինք IP տեսախցիկը և փորձարկեցինք այն VLC, կազմաձևեց սերվերը և փորձարկվեց RTSPհոսում է սերվերի միջոցով՝ բաշխմամբ WebRTC, վերջապես կարող ենք համեմատել ուշացումները։Դա անելու համար մենք կօգտագործենք ժմչփ, որը մոնիտորի էկրանին ցույց կտա վայրկյանի կոտորակները: Միացրեք ժմչփը և միաժամանակ միացրեք տեսանյութի հոսքը VLC տեղականև Firefox բրաուզերի վրա՝ հեռավոր սերվերի միջոցով:
Ping դեպի սերվեր 100 ms.
Ping տեղական 1 ms.
Ժամաչափի օգտագործմամբ առաջին թեստն այսպիսի տեսք ունի.
Սև ֆոնի վրա բնօրինակ ժմչփն է, որը ցույց է տալիս զրոյական ուշացում: Ձախ VLC, աջ կողմում Firefox, ստանալով WebRTCհեռարձակում հեռավոր սերվերից:
| Զրո | VLC | Firefox, WCS | |
| Ժամանակը | 50.559 | 49.791 | 50.238 |
| Լատենտություն ms | 0 | 768 | 321 |
Մենք մի քանի նկար ենք վերցրել՝ ուշացման արժեքները գրանցելու համար:
Հաճախ հարց է առաջանում՝ ինչպե՞ս միացնել IP տեսախցիկը NVR-ին, եթե այն չկա համատեղելիության ցանկում:
Երկու տարբերակ կա ONVIF և RTSP
Սկսենք ONVIF արձանագրությունից (Open Network Video Interface Forum)
ONVIF-ը ընդհանուր ընդունված արձանագրություն է IP տեսախցիկների, NVR-ների, ծրագրային ապահովման համատեղ աշխատանքի համար, եթե բոլոր սարքերը տարբեր արտադրողներից են: ONVIF-ը կարելի է համեմատել անգլերենի հետ մարդկանց միջազգային հաղորդակցության համար:
Համոզվեք, որ միացված սարքերը աջակցում են ONVIF-ին որոշ սարքերում ONVIF-ը կարող է անջատված լինել լռելյայնորեն:
Կամ ONVIF-ի միջոցով թույլտվությունը կարող է անջատվել, ինչը նշանակում է, որ մուտքի/գաղտնաբառը միշտ կլինի լռելյայն
անկախ WEB-ի մուտքի/գաղտնաբառից 
Հարկ է նաև նշել, որ որոշ սարքեր օգտագործում ենONVIF արձանագրության միջոցով շահագործման առանձին նավահանգիստ
Որոշ դեպքերում ONVIF գաղտնաբառը կարող է տարբերվել WEB մուտքի գաղտնաբառից:
Ի՞նչ է հասանելի, երբ միացված է ONVIF-ի միջոցով:
Սարքի հայտնաբերում
Տեսանյութի փոխանցում
Ձայնային տվյալների ընդունում և փոխանցում
PTZ տեսախցիկի կառավարում
Տեսանյութերի վերլուծություն (օրինակ՝ շարժման հայտնաբերում)
Այս պարամետրերը կախված են ONVIF արձանագրության տարբերակների համատեղելիությունից: Որոշ դեպքերում որոշ պարամետրեր անհասանելի են կամ ճիշտ չեն աշխատում:
Կ և օգտագործելով ONVIF
SNR և Dahua ձայնագրիչներում ONVIF արձանագրությունը գտնվում է Remote Device ներդիրում, Արտադրող տողում:
Ընտրեք այն ալիքը, որին միացված կլինի սարքը
Արտադրող ներդիրից ընտրեք ONVIF
Նշեք ip հասցեսարքեր
RTSPնավահանգիստը մնում է լռելյայն
Տեսախցիկների օգտագործումը ONVIF նավահանգիստ 8080
(2017 թվականից ONVIF նոր մոդելներում նավահանգիստը փոխվել է 80-ի Alpha և Mira սերիաների համար)
OMNY տեսախցիկներ Հիմքօգտագործել ONVIF նավահանգիստ 80, գրանցամատյանում այն նշված է որպես HTTP պորտ
Անուն
Գաղտնաբառըստ սարքի պարամետրերի
Հեռավոր ալիքլռելյայն 1 է: Եթե սարքը բազմալիք է, նշվում է ալիքի համարը:
Ապակոդավորող բուֆեր— վիդեո հոսքի բուֆերացում, որը ցույց է տալիս ժամանակի արժեքը
Սերվերի տեսակըայստեղ կա TCP, UDP ժամանակացույցի ընտրություն
TCP- կապ է հաստատում ուղարկողի և ստացողի միջև, ապահովում է, որ բոլոր տվյալները հասնում են ստացողին առանց փոփոխությունների և պահանջվող հաջորդականությամբ, ինչպես նաև կարգավորում է փոխանցման արագությունը:
Ի տարբերություն TCP-ի, UDPչի հաստատում նախնական կապը, փոխարենը պարզապես սկսում է տվյալների փոխանցումը: UDP-ն չի վերահսկում ստացված տվյալները և չի կրկնօրինակում դրանք կորստի կամ սխալի դեպքում:
UDP-ն ավելի քիչ հուսալի է, քան TCP-ն: Բայց մյուս կողմից, այն ապահովում է հոսքերի ավելի արագ փոխանցում՝ կորցրած փաթեթների վերահաղորդման բացակայության պատճառով
Ժամանակացույց- ավտոմատ տիպի հայտնաբերում:
Ահա թե ինչ տեսք ունեն միացված սարքերը Dahua-ում
Կանաչ կարգավիճակը նշանակում է, որ ձայնագրիչը և տեսախցիկը հաջողությամբ միացված են
Կարմիր կարգավիճակը նշանակում է, որ կապի հետ կապված խնդիրներ կան: Օրինակ, միացման նավահանգիստը սխալ է:
Միացման երկրորդ եղանակն է RTSP(Իրական ժամանակի հոսքային արձանագրություն) 
RTSPիրական ժամանակի հոսքային արձանագրություն, որը նկարագրում է վիդեո հոսքը կառավարելու հրամանները:
Օգտագործելով այս հրամանները, տեսանյութի հոսքը հեռարձակվում է աղբյուրից մինչև ստացող
օրինակ՝ IP տեսախցիկից մինչև DVR կամ սերվեր:
Ի՞նչ է հասանելի RTSP-ի միջոցով միանալիս:
Տեսանյութի փոխանցում
Ձայնային տվյալների ընդունում և փոխանցում
ԱռավելությունԱյս փոխանցման արձանագրությունն այն է, որ այն չի պահանջում տարբերակի համատեղելիություն:
Այսօր RTSP-ին աջակցում են գրեթե բոլոր IP տեսախցիկները և NVR-ները
ԹերություններԱրձանագրությունն այն է, որ բացի վիդեո և աուդիո տվյալների փոխանցումից, ուրիշ ոչինչ հասանելի չէ։
Եկեք նայենք տեսախցիկի միացման օրինակինդեպի և օգտագործելով RTSP
.jpg)
RTSPգտնվում է Remote Device ներդիրում, Manufacturer տողում, SNR և Dahua ձայնագրիչում այն ներկայացված է որպեսԳեներալ
Ընտրեք այն ալիքը, որին միացված կլինի սարքը
URL հասցե- այստեղ մենք մուտքագրում ենք հարցման տողը, որի համար ուղարկում է տեսախցիկը հիմնական RTSP հոսքի հետ բարձր բանաձեւը։
Լրացուցիչ URL - Այստեղ մուտքագրեք հարցման տողը, որի համար ուղարկում է տեսախցիկը լրացուցիչ RTSP հոսքի հետ ցածր լուծում:
Հարցման օրինակ.
rtsp://172.16.31.61/1 հիմնական հոսք
rtsp://172.16.31.61/2 լրացուցիչ հոսք
Ինչու՞ է ձեզ անհրաժեշտ լրացուցիչ թեմա:
Բազմապատկերային ձայնագրիչին միացված տեղական մոնիտորի վրա ձայնագրիչն օգտագործում է լրացուցիչ թել՝ ռեսուրսները խնայելու համար: Օրինակ՝ 16 պատուհանով փոքր նկարներում բոլորովին էլ պետք չէ վերծանել Full HD լուծաչափը, բավական է D1-ը։ Դե, եթե բացել եք 1/4/8 պատուհաններ, ապա այս դեպքում հիմնական հոսքը վերծանվում է բարձր լուծաչափով։
Անունըստ սարքի պարամետրերի
Գաղտնաբառըստ սարքի պարամետրերի
Ապակոդավորող բուֆերվիդեո հոսքի բուֆերացում, որը ցույց է տալիս ժամանակի արժեքը
Սերվերի տեսակը- TCP, UDP, ժամանակացույց (նման է ONVIF արձանագրությանը)
Այս հոդվածը պատասխանում է ամենատարածված հարցերին, ինչպիսիք են.
Արդյո՞ք IP տեսախցիկը համատեղելի է NVR-ի հետ:
Իսկ եթե համատեղելի է, ինչպե՞ս միացնել։
IP տեսախցիկից առցանց հեռարձակման խնդրի լուծումը, ընդհանուր առմամբ, չի պահանջում WebRTC-ի օգտագործումը: Տեսախցիկը ինքնին սերվեր է, ունի IP հասցե և կարող է ուղղակիորեն միացվել երթուղիչին՝ տեսաբովանդակություն տարածելու համար: Այսպիսով, ինչու՞ օգտագործել WebRTC տեխնոլոգիան:
Դրա համար կա առնվազն երկու պատճառ.
1. Քանի որ Ethernet հեռարձակման դիտողների թիվը մեծանում է, սկզբում կզգացվի ալիքի հաստության բացակայությունը, իսկ հետո հենց տեսախցիկի ռեսուրսները:
2. Ինչպես նշվեց վերևում, IP տեսախցիկը սերվեր է: Բայց ի՞նչ արձանագրություններ կարող է այն օգտագործել վիդեո աշխատասեղանի դիտարկիչ ուղարկելու համար: Շարժական սարքը? Ամենայն հավանականությամբ սա կլինի HTTP հոսք, որտեղ վիդեո շրջանակները կամ JPEG պատկերները փոխանցվում են HTTP-ի միջոցով: HTTP հոսքը, ինչպես գիտեք, լիովին հարմար չէ իրական ժամանակի վիդեո հոսքի համար, թեև այն լավ է ապացուցել պահանջարկի տեսանյութում, որտեղ հոսքի ինտերակտիվությունն ու հետաձգումը առանձնապես կարևոր չեն: Իրականում, եթե դուք ֆիլմ եք դիտում, մի քանի վայրկյան ուշացումը չի վատթարացնի այն, քանի դեռ չեք դիտում ֆիլմը մեկ ուրիշի հետ միաժամանակ: "Օ ոչ! Ջեքը սպանեց նրան։ - Ալիսը ողբերգական ավարտից 10 վայրկյան առաջ չաթում սփոյլեր է գրում Բոբին։
Կամ դա կլինի RTSP/RTP և H.264, որի դեպքում բրաուզերում պետք է տեղադրվի վիդեո նվագարկչի պլագին, ինչպիսին է VLC կամ QuickTime: Նման փլագինը կնկարահանի և կցուցադրի տեսանյութ, ինչպես ինքը՝ նվագարկիչը: Բայց մեզ անհրաժեշտ է իրական բրաուզերի վրա հիմնված հոսք՝ առանց լրացուցիչ հենակներ/պլագիններ տեղադրելու:
Նախ, եկեք լուսանկարենք IP տեսախցիկը, պարզելու համար, թե կոնկրետ ինչ է ուղարկում այս սարքը դեպի դիտարկիչ: Փորձարկման առարկան կլինի D-Link DCS 7010L տեսախցիկը.
Դուք կարող եք ավելին կարդալ ստորև տեսախցիկի տեղադրման և կազմաձևման մասին, բայց այստեղ մենք պարզապես կանդրադառնանք, թե ինչ է այն օգտագործում տեսահոսքի համար: Վեբ ինտերֆեյսի միջոցով տեսախցիկի ադմինիստրատորի վահանակ մտնելիս մենք տեսնում ենք նման բան (ներողություն լանդշաֆտի համար).
Նկարը բացվում է բոլոր բրաուզերներում և հավասարաչափ սառչում, մոտավորապես վայրկյանը մեկ: Հաշվի առնելով, որ և՛ տեսախցիկը, և՛ նոութբուքը, որի վրա մենք դիտում ենք հոսքը, միացված են նույն երթուղղիչին, ամեն ինչ պետք է լինի հարթ և գեղեցիկ, բայց դա այդպես չէ։ Կարծես HTTP. Եկեք գործարկենք Wireshark-ը՝ մեր ենթադրությունները հաստատելու համար.
Այստեղ մենք տեսնում ենք 1514 բայթ երկարությամբ TCP բեկորների հաջորդականություն
Եվ վերջնական HTTP 200 OK ստացված JPEG-ի երկարությամբ.
Մեզ նման հոսքի կարիք չկա: Ոչ հարթ, ցնցում է HTTP հարցումները: Քանի՞ նման խնդրանք կարող է կատարել տեսախցիկը վայրկյանում: Հիմքեր կան ենթադրելու, որ 10 կամ ավելի վաղ հանդիսատեսի դեպքում տեսախցիկը ապահով կծկվի կամ կսկսի ահավոր շեղվել և սլայդներ առաջացնել:
Եթե նայեք տեսախցիկի ադմինիստրատորի վահանակի HTML էջին, կտեսնեք այս հետաքրքիր կոդը.
If(browser_IE) DW(""); այլապես ( if(mpMode == 1) var RTSPName = g_RTSPName1; այլապես, եթե (mpMode == 2) var RTSPName = g_RTSPName2; այլապես, եթե (mpMode == 3) var RTSPName = g_RTSPName3; var o=""; եթե (g_isIPv6) //քանի որ ipv6-ը չի աջակցում rtsp var host = g_netip;"; //զգուշացում(o); DW(o);)
RTSP/RTP-ն հենց այն է, ինչ ձեզ անհրաժեշտ է վիդեո պատշաճ նվագարկման համար: Բայց սա կաշխատի բրաուզերում: -Ոչ: Բայց եթե տեղադրեք QuickTime plugin-ը, ամեն ինչ կաշխատի: Բայց մենք կատարում ենք զուտ բրաուզերի վրա հիմնված հոսք:
Այստեղ կարող ենք նշել նաև Flash Player-ը, որը կարող է Wowza-ի նման համապատասխան սերվերի միջոցով ստանալ RTMP հոսք՝ փոխարկված RTSP, RTP, H.264-ից։ Բայց Flash Player-ը, ինչպես գիտեք, նույնպես բրաուզերի պլագին է, թեև անհամեմատ ավելի հայտնի է, քան VLC-ն կամ QuickTime-ը։
Այս դեպքում մենք կփորձարկենք նույն RTSP/RTP-ի վերահոսքը, սակայն WebRTC-ի հետ համատեղելի զննարկիչը կօգտագործվի որպես նվագարկիչ՝ առանց զննարկիչի հավելյալ հավելումների կամ այլ հենակների: Մենք կստեղծենք ռելե սերվեր, որը կվերցնի հոսքը IP տեսախցիկից և այն կուղարկի ինտերնետ կամայական թվով օգտվողների՝ օգտագործելով WebRTC-ն աջակցող բրաուզերներ:
IP տեսախցիկի միացում
Ինչպես նշվեց վերևում, փորձարկման համար ընտրվել է պարզ D-Link DCS-7010L IP տեսախցիկ: Այստեղ հիմնական ընտրության չափանիշը սարքի աջակցությունն էր RTSP արձանագրությանը, քանի որ դրա միջոցով է, որ մեր սերվերը կստանա տեսախցիկից տեսահոսքը:Մենք տեսախցիկը միացնում ենք երթուղիչին, օգտագործելով ներառված կարկատանի լարը: Հոսանքը միացնելուց և երթուղիչին միանալուց հետո տեսախցիկը DHCP-ի միջոցով վերցրեց IP հասցե, մեր դեպքում դա 192.168.1.34 էր (եթե անցնեք երթուղիչի կարգավորումները, կտեսնեք, որ DCS 7010L սարքը միացված է. վերջ. ). Ժամանակն է փորձարկել տեսախցիկը:
Բացեք նշված IP հասցեն 192.168.1.34 բրաուզերում՝ տեսախցիկի ադմինիստրատորի վեբ ինտերֆեյսին հասնելու համար: Լռելյայն գաղտնաբառ չկա:
Ինչպես տեսնում եք, տեսախցիկի տեսանյութը ճիշտ է հեռարձակվում ադմինիստրատորի վահանակում: Միաժամանակ նկատելի է պարբերական ցնցումներ։ Սա այն է, ինչ մենք կուղղենք WebRTC-ի միջոցով:
Տեսախցիկի կարգավորում
Նախ, մենք անջատում ենք նույնականացումը տեսախցիկի կարգավորումներում. որպես փորձարկման մաս, մենք հոսքը կտրամադրենք բոլորին, ովքեր հարցնում են: Դա անելու համար գնացեք տեսախցիկի վեբ ինտերֆեյսի կարգավորումները Կարգավորում - Ցանցև սահմանեք օպցիոնի արժեքը Նույնականացում՝ անջատելու համար.Այնտեղ մենք նաև ստուգում ենք RTSP արձանագրության պորտի արժեքը, ըստ նախնականի, այն 554 է: Փոխանցվող տեսանյութի ձևաչափը որոշվում է օգտագործված պրոֆիլով: Տեսախցիկում կարող եք տեղադրել դրանցից մինչև երեքը, մենք կօգտագործենք առաջինը, live1.sdp - ըստ կանխադրման այն կազմաձևված է օգտագործել H.264-ը վիդեո և G.711-ը ձայնի համար: Անհրաժեշտության դեպքում կարող եք փոխել կարգավորումները բաժնում Կարգավորում - աուդիո և վիդեո.
Այժմ դուք կարող եք ստուգել տեսախցիկի աշխատանքը RTSP-ի միջոցով: Բացեք VLC Player-ը (կարող եք օգտագործել ցանկացած այլ նվագարկիչ, որն աջակցում է RTSP - QuickTime, Windows Media Player, RealPlayer և այլն) և Open URL երկխոսության մեջ սահմանեք տեսախցիկի RTSP հասցեն՝ rtsp://192.168.1.34/live1.sdp:
Դե, ամեն ինչ աշխատում է այնպես, ինչպես պետք է: Տեսախցիկը պարբերաբար վերարտադրում է վիդեո հոսքը նվագարկիչում RTSP արձանագրության միջոցով:
Ի դեպ, հոսքը նվագարկվում է բավականին սահուն և առանց արտեֆակտների։ Նույնը ակնկալում ենք WebRTC-ից։
Սերվերի տեղադրում
Այսպիսով, տեսախցիկը տեղադրված է, փորձարկվել է սեղանադիր նվագարկիչների հետ և պատրաստ է սերվերի միջոցով հեռարձակման: Whatismyip.com-ի միջոցով մենք որոշում ենք տեսախցիկի արտաքին IP հասցեն: Մեր դեպքում եղել է 178.51.142.223։ Մնում է միայն ասել երթուղիչին, որ 554 նավահանգստի RTSP-ի միջոցով մուտք գործելիս մուտքային հարցումները կփոխանցվեն IP տեսախցիկին:Մուտքագրեք համապատասխան կարգավորումները երթուղիչում...
...և ստուգեք արտաքին IP հասցեն և RTSP պորտը՝ օգտագործելով telnet:
Տելնետ 178.51.142.223 554
Համոզվելով, որ այս նավահանգստում պատասխան կա, մենք անցնում ենք WebRTC սերվերի տեղադրմանը:
Amazon EC2-ում Centos 64 բիթանոց վիրտուալ սերվերը պատասխանատու կլինի հոսթինգի համար:
Աշխատանքային խնդիրներից խուսափելու համար մենք ընտրեցինք m3.medium օրինակ մեկ VCPU-ով.
Այո, այո, կա նաև Linode և DigitalOcean, բայց այս դեպքում ես ուզում էի փորձել Amazon-ը։
Առաջ նայելով, ես կգրեմ, որ Amazon EC2 կառավարման վահանակում դուք պետք է ավելացնեք մի քանի կանոններ (առաջադեմ նավահանգիստներ), առանց որոնց օրինակը չի աշխատի: Սրանք պորտեր են WebRTC (SRTP, RTCP, ICE) տրաֆիկի և պորտեր RTSP/RTP տրաֆիկի համար: Եթե փորձեք, Amazon-ի կանոնները պետք է ունենան նման բան մուտքային տրաֆիկի համար.
Ի դեպ, DigitalOcean-ի հետ ամեն ինչ ավելի պարզ կլինի, պարզապես բացեք այս պորտերը firewall-ի վրա կամ անջատեք վերջինս։ Համաձայն DO-ի օրինակների շահագործման վերջին փորձի, նրանք դեռ թողարկում են ստատիկ IP հասցե և չեն անհանգստանում NAT-ների հետ, ինչը նշանակում է, որ նավահանգիստների վերահասցեավորումը, ինչպես Amazon-ի դեպքում, անհրաժեշտ չէ:
Մենք կօգտագործենք WebRTC Media & Broadcasting Server-ը Flashphoner-ից որպես սերվերային ծրագիր, որը փոխանցում է RTSP/RTP հոսքը WebRTC-ին: Հոսքային սերվերը շատ նման է Wowza-ին, որը կարող է RTSP/RTP հոսք փոխանցել Flash: Միակ տարբերությունն այն է, որ այս հոսքը կուղարկվի WebRTC, այլ ոչ թե Flash: Նրանք. ազնիվ DTLS-ը կանցնի բրաուզերի և սերվերի միջև, կստեղծվի SRTP նիստ, և VP8-ում կոդավորված հոսքը կգնա դիտողին:
Տեղադրման համար մեզ անհրաժեշտ կլինի SSH մուտք:
Սփոյլերի տակ ներկայացված է կատարված հրամանների մանրամասն նկարագրությունը
1. Ներբեռնել է սերվերի տեղադրման արխիվը՝
$wget flashphoner.com/downloads/builds/WCS/3.0/x8664/wcs3_video_vp8/FlashphonerMediaServerWebRTC-3.0/FlashphonerMediaServerWebRTC-3.0.868.tar.gz
2. Ընդլայնված:
$tar -xzf FlashphonerMediaServerWebRTC-3.0.868.tar.gz
3. Տեղադրված:
$cd FlashphonerMediaServerWebRTC-3.0.868
$./install.sh
Տեղադրման գործընթացում մենք մուտքագրել ենք սերվերի արտաքին IP հասցեն՝ 54.186.112.111 և ներքին 172.31.20.65 (նույնը՝ Private IP):
4. Գործարկել է սերվերը.
$service webcallserver-ի մեկնարկը
5. Ստուգել են տեղեկամատյանները.
$tail - f /usr/local/FlashphonerWebCallServer/logs/server_logs/flashphoner.log
6. Համոզվեք, որ սերվերը գործարկվել է և պատրաստ է աշխատել.
$ps aux | grep Flashphoner
7. Տեղադրվել և գործարկվել է apache:
$yum տեղադրել httpd
$service httpd սկիզբ
8. Ներբեռնեց վեբ ֆայլերը և տեղադրեց դրանք ստանդարտ 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. Մուտքագրեք սերվերի IP հասցեն flashphoner.xml կազմաձևում՝
10. Դադարեցրեց firewall-ը:
$service iptables-ը կանգ է առնում
Տեսականորեն, 10-րդ կետի փոխարեն, ճիշտ կլիներ սահմանել բոլոր անհրաժեշտ պորտերը և firewall-ի կանոնները, բայց թեստավորման նպատակով մենք որոշեցինք պարզապես անջատել firewall-ը։
Սերվերի թյունինգ
Հիշեցնենք, որ մեր WebRTC հեռարձակման կառուցվածքը հետևյալն է.
Մենք արդեն տեղադրել ենք այս գծապատկերի հիմնական տարրերը, մնում է միայն փոխազդեցության «սլաքները»:
Բրաուզերի և WebRTC սերվերի միջև կապը տրամադրվում է վեբ հաճախորդի կողմից, որը հասանելի է Github: JS, CSS և HTML ֆայլերի մի շարք պարզապես նետվում է մեջ /var/www/htmlտեղադրման փուլում (տե՛ս 9-րդ կետը վերևում` սփոյլերի տակ):
Բրաուզերի և սերվերի միջև փոխազդեցությունը կազմաձևված է XML կազմաձևման ֆայլում flashphoner.xml: Այնտեղ դուք պետք է մուտքագրեք սերվերի IP հասցեն, որպեսզի վեբ հաճախորդը կարողանա միանալ WebRTC սերվերին HTML5 Websockets-ի միջոցով (9-րդ կետ վերևում):
Սերվերի կարգավորումն ավարտվում է այստեղ, կարող եք ստուգել դրա աշխատանքը.
Բացեք վեբ հաճախորդի էջը index.html բրաուզերում (դրա համար Apache-ն տեղադրվել է նույն Amazon սերվերի վրա հրամանով yum -y տեղադրել httpd):
54.186.112.111/wcs_media_client/?id=rtsp://webrtc-ipcam.ddns.net/live1.sdp
Այստեղ webrtc-ipcam.ddns.netանվճար տիրույթ է, որը ստացվում է դինամիկ DNS սերվերի միջոցով noip.com, որը կապում է մեր արտաքին IP հասցեին: Մենք երթուղիչին ասացինք վերահղել RTSP հարցումները դեպի 192.168.1.34՝ համաձայն NAT ցանցի հասցեների թարգմանության կանոնների (տես նաև վերևում):
Պարամետր id=rtsp://webrtc-ipcam.ddns.net/live1.sdpնշում է նվագարկվող հոսքի URL-ը: WebRTC սերվերը տեսախցիկից հոսքեր կպահանջի, կմշակի դրանք և կուղարկի զննարկիչ՝ WebRTC-ի միջոցով նվագարկելու համար: Հնարավոր է, որ ձեր երթուղիչը աջակցում է DDNS: Եթե ոչ, ապա IP տեսախցիկը ինքնին ունի այսպիսի աջակցություն.
Եվ ահա թե ինչ տեսք ունի DDNS աջակցությունը հենց երթուղիչում.
Այժմ դուք կարող եք սկսել թեստավորում և գնահատել արդյունքները:
Փորձարկում
Բրաուզերում հղումը բացելուց հետո կապ է հաստատվում WebRTC սերվերի հետ, որը հարցում է ուղարկում IP տեսախցիկին՝ տեսահոսքը ստանալու համար։ Ամբողջ գործընթացը տևում է մի քանի վայրկյան:
Այս պահին բրաուզերի և սերվերի միջև կապ է հաստատվում վեբսոկետների միջոցով, այնուհետև սերվերը պահանջում է IP տեսախցիկ RTSP-ի միջոցով, ստանում է H.264 հոսքը RTP-ի միջոցով և փոխակերպում այն VP8/SRTP-ի, որն ի վերջո նվագարկում է WebRTC բրաուզերը:
Տեսանյութի ներքևում ցուցադրվում է վիդեո հոսքի URL-ը, որը կարելի է պատճենել և բացել՝ այլ դիտարկիչից կամ ներդիրից դիտելու համար:
Մենք համոզված ենք, որ սա իսկապես WebRTC է:
Իսկ եթե մեզ խաբեն, և IP տեսախցիկի տեսանյութը կրկին փոխանցվի HTTP-ով: Եկեք պարապ չնայենք նկարին, այլ ստուգենք, թե իրականում ինչպիսի տրաֆիկ ենք ստանում։ Իհարկե, մենք նորից գործարկում ենք Wireshark-ը և վրիպազերծման վահանակը Chrome-ում: Chrome բրաուզերի վահանակում մենք կարող ենք տեսնել հետևյալը.
Այս անգամ ոչինչ չի թարթում և պատկերներ չեն երևում, որոնք փոխանցվում են HTTP-ի միջոցով: Այն ամենը, ինչ մենք տեսնում ենք այս անգամ, Websocket շրջանակներն են, և դրանցից շատերը պինգ/պոնգի տեսակներ են՝ Websocket նիստը պահպանելու համար: Հետաքրքիր շրջանակներ՝ միացեք, պատրաստեքRtspSession և onReadyToPlay - սա սերվերի հետ կապի հաստատման հերթականությունն է՝ նախ Websocket կապ, այնուհետև նվագարկման հոսքի հարցում:
Ահա թե ինչ է դա ցույց տալիս chrome://webrtc-internals
Ըստ գրաֆիկների՝ IP տեսախցիկից ունենք բիթային արագություն 1 Մբ/վրկ։ Կա նաև ելքային տրաֆիկ, ամենայն հավանականությամբ դրանք RTCP և ICE փաթեթներ են: Amazon սերվերի RTT-ը մոտ 300 միլիվայրկյան է:
Այժմ եկեք նայենք Wireshark-ին, դուք կարող եք հստակ տեսնել UDP տրաֆիկը սերվերի IP հասցեից. Ստորև բերված նկարում փաթեթները 1468 բայթ են: Սա WebRTC-ն է: Ավելի ճիշտ՝ VP8 վիդեո շրջանակներ կրող SRTP փաթեթներ, որոնք մենք կարող ենք դիտարկել բրաուզերի էկրանին։ Բացի այդ, STUN հարցումներն անցնում են (նկարում ամենացածր փաթեթը) – սա WebRTC ICE-ն է, որը ուշադիր ստուգում է կապը:
Հարկ է նաև նշել, որ համեմատաբար ցածր հետաձգումը (պինգը տվյալների կենտրոնին մոտ 250 մվ էր) տեսանյութերի նվագարկման համար: WebRTC-ն աշխատում է SRTP/UDP-ով, և սա, ի վերջո, փաթեթներ առաքելու ամենաարագ ճանապարհն է, ի տարբերություն HTTP-ի, RTMP-ի և TCP-ի նման հոսքային այլ մեթոդների: Նրանք. Աչքի համար տեսանելի ուշացումը պետք է լինի RTT + բրաուզերի կողմից բուֆերացման, վերծանման և նվագարկման ժամանակը: Տեսողականորեն այս դեպքում այդպես է՝ աչքը գրեթե չի տեսնում ուշացումը, այն 500 միլիվայրկյանից պակաս է։
Հաջորդ փորձությունը կապում է այլ հեռուստադիտողների հետ: Ես կարողացա բացել 10 Chrome պատուհան, որոնցից յուրաքանչյուրը ցույց էր տալիս մի նկար։ Միևնույն ժամանակ, Chrome-ն ինքը սկսեց մի փոքր ձանձրալի դառնալ: Մեկ այլ համակարգչի վրա 11-րդ պատուհանը բացելիս նվագարկումը մնաց հարթ:
WebRTC-ի մասին շարժական սարքերում
Ինչպես գիտեք, WebRTC-ն աջակցվում է Chrome և Firefox բրաուզերների կողմից Android հարթակի վրա:Եկեք ստուգենք, թե արդյոք մեր հեռարձակումը կցուցադրվի այնտեղ.
Նկարում պատկերված է HTC-ի հեռախոսը, որը ցուցադրում է տեսախցիկի տեսախցիկը: Սեղանից նվագարկման հարթության մեջ տարբերություններ չկան:
Եզրակացություն
Արդյունքում, մենք նվազագույն ջանքերով կարողացանք գործարկել WebRTC առցանց հեռարձակում IP տեսախցիկից մինչև մի քանի բրաուզերներ: Դափի հետ պարել կամ հրթիռային գիտություն չի պահանջվում՝ միայն Linux-ի և SSH կոնսոլի տարրական գիտելիքներ:Հեռարձակման որակը եղել է ընդունելի մակարդակի վրա, իսկ նվագարկման ուշացումը՝ աչքի համար անտեսանելի։
Ամփոփելու համար կարելի է ասել, որ բրաուզերի վրա հիմնված WebRTC հեռարձակումները գոյություն ունենալու իրավունք ունեն, քանի որ մեր դեպքում, WebRTC-ն այլևս հենակ կամ պլագին չէ, այլ բրաուզերում տեսանյութ նվագարկելու իրական հարթակ:
Ինչու՞ մենք չենք տեսնում WebRTC-ի համատարած ընդունումը:
Հիմնական խոչընդոտը, թերեւս, կոդեկների բացակայությունն է։ WebRTC համայնքը և վաճառողները պետք է ջանքեր գործադրեն և ներդնեն H.264 կոդեկը WebRTC-ում: VP8-ի դեմ ասելու ոչինչ չկա, բայց ինչո՞ւ հրաժարվել միլիոնավոր համատեղելի սարքերից և ծրագրերից, որոնք աշխատում են H.264-ի հետ: Պատենտներ, նման արտոնագրեր...Երկրորդ տեղում բրաուզերների ամբողջական աջակցությունը չէ: Օրինակ՝ IE-ի և Safari-ի դեպքում հարցը մնում է բաց, և այնտեղ դուք ստիպված կլինեք անցնել հոսքի այլ տեսակի կամ օգտագործել webrtc4all-ի նման փլագին։
Այսպիսով, ապագայում մենք հուսով ենք տեսնել ավելի հետաքրքիր լուծումներ, որոնցում հոսքերի տրանսկոդավորումն ու փոխակերպումն անհրաժեշտ չի լինի, և բրաուզերների մեծ մասը կկարողանա ուղղակիորեն տարբեր սարքերից հոսքեր նվագարկել:
Տեսահեռարձակումների հարմարավետ դիտում կամ կարող է կազմաձևվել՝ օգտագործելով ծրագրային ապահովման մուլտիմեդիա նվագարկիչներ ձեր անձնական համակարգչի վրա: Այսօր մենք կնայենք, թե ինչպես կարելի է կարգավորել RTSP հոսքը Dahua Technology ցանցային սարքավորումների համար ամենահայտնի խաղացողներից մեկում՝ VLC Media Player-ում:
RTSP (Real Time Streaming Protocol) արձանագրություն է, որը թույլ է տալիս օգտվողին հեռակա կերպով նվագարկել մուլտիմեդիա տվյալների հոսքը (աուդիո և վիդեո)՝ օգտագործելով հիպերհղումը և մուլտիմեդիա նվագարկիչը (մեր դեպքում՝ VLC Media Player):
Եթե Ձեզ անհրաժեշտ է կարգավորել վիդեո հոսքը, օգտագործեք հետևյալ քայլերը.
- Առաջին հերթին անհրաժեշտ է ներբեռնել և տեղադրել VLC Media Player-ը, որն անվճար հասանելի է պաշտոնական կայքում:
- Կտտացրեք ընտրացանկի տարրը Մեդիա – Բացեք ցանցային հոսքը (Բաց URL):
- Մուտքագրեք RTSP ցանցի հասցեն հուշման տողում:
- Սեղմեք նվագարկման կոճակը, երբ տեսահոլովակի պատկերը հայտնվի էկրանին:
Հղման բացատրություն RTSP
Օրինակ:
rtsp:// :@:/cam/realmonitor?channel= &ենթատեսակ=
Որտեղ:
rtsp://admin: [էլփոստը պաշտպանված է]:554/cam/realmonitor?channel=1&subtype=1
Dahua Technology IP տեսախցիկները աջակցում են TCP և UDP տվյալների փոխանցման արձանագրություններին: Եթե 554 պորտը փոխվել է, փոխեք այն տեսախցիկի կարգավորումների համապատասխան դաշտում (վեբ ինտերֆեյս):
Եթե որևէ խնդիր ունեք RTSP հոսքի ստեղծման հարցում, խնդրում ենք դիմել համապատասխան բաժին:
RTSP (իրական ժամանակի հոսքային արձանագրություն)– իրական ժամանակի հոսքային արձանագրություն, որը պարունակում է վիդեո հոսքի վերահսկման հիմնական հրամանների մի շարք:
RTSP աղբյուրների և IP տեսախցիկների միացում վիդեո կոնֆերանսներում
RTSP արձանագրությունը թույլ է տալիս TrueConf-ի ցանկացած օգտվողին միանալ IP տեսախցիկներին և մեդիա բովանդակության այլ աղբյուրներին, որոնք հեռարձակվում են այս արձանագրության միջոցով՝ հեռավոր օբյեկտները վերահսկելու համար: Օգտատերը կարող է նաև միանալ նման տեսախցիկներին՝ տեսահամաժողովի ընթացքում պատկերներ հեռարձակելու համար։
RTSP արձանագրության աջակցության շնորհիվ TrueConf սերվերի օգտվողները կարող են ոչ միայն միանալ IP տեսախցիկներին, այլև հեռարձակել վիդեո կոնֆերանսներ RTSP նվագարկիչների և մեդիա սերվերների համար: Կարդալ ավելին RTSP հեռարձակումների մասին:
TrueConf ծրագրային լուծումներով IP տեսախցիկների օգտագործման առավելությունները
- Տեղադրելով IP տեսախցիկ գրասենյակում կամ արդյունաբերական արտադրամասում և ցանկացած հարմար պահի միանալով դրան՝ դուք կկարողանաք վերահսկել ձեր ընկերության արտադրական գործընթացը։
- Դուք կարող եք վերահսկել հեռավոր օբյեկտները շուրջօրյա: Օրինակ, եթե արձակուրդ եք գնում և չեք ցանկանում առանց հսկողության թողնել ձեր բնակարանը, պարզապես այնտեղ տեղադրեք մեկ կամ մի քանի IP տեսախցիկ: Զանգահարելով ձեր համակարգչից այս տեսախցիկներից մեկին՝ տեղադրված TrueConf հաճախորդի հավելվածով, դուք կարող եք ցանկացած պահի միանալ ձեր բնակարանին և իրական ժամանակում տեսնել, թե ինչ է կատարվում այնտեղ:
- Windows-ի, Linux-ի և macOS-ի TrueConf հաճախորդի հավելվածներում բոլոր օգտատերերին հասանելի է վիդեո կոնֆերանսներ ձայնագրելու հնարավորությունը, որի շնորհիվ տեսահսկման ընթացքում կարող եք ձայնագրել ցանկացած իրադարձություն և ստանալ դրանց մասին փաստաթղթային ապացույցներ:
