Ամպային տեսահսկման համակարգի վրա աշխատելու առաջին իսկ օրերից մենք բախվեցինք մի խնդրի հետ, առանց որի լուծումը կարող էինք հրաժարվել Ivideon-ից. սա մեր Էվերեստն էր, բարձրանալը, որը շատ էներգիա խլեց, բայց հիմա մենք վերջապես ունենք. սառցե կացինը խրեց խաչաձև հարթակի գլուխկոտրուկի վերին մասում:
Ինտերնետում աուդիո և վիդեո փոխանցման համակարգը չպետք է կախված լինի սարքավորումներից, վեբ հաճախորդներից և նրանց կողմից աջակցվող ստանդարտներից, ինչպես նաև ճիշտ աշխատի ցանցային հասցեների թարգմանիչների և firewalls-ի առկայության դեպքում: Ամպային տեսահսկման օգտատերը ցանկանում է մուտք գործել ծառայություն, նույնիսկ եթե նա օգտագործում է անալոգային տեսախցիկներ, և նախընտրում է ուղիղ հեռարձակում դիտել ամենաարդիական սարքով:
Շատ կարևոր է, որ օգտատերը ցանկանում է դիտել տեսանյութեր նվազագույն ուշացումով։ Բրաուզերում ցածր ուշացումով տեսանյութ ցուցադրելու գրեթե միակ միջոցը WebRTC-ն է (վեբ իրական ժամանակի հաղորդակցություն): WebRTC-ը բրաուզերներում վիդեո և աուդիո հավասարակից փոխանցման տեխնոլոգիաների մի շարք է, որն ի սկզբանե նախատեսված է ցածր ուշացումով վիդեո հոսքերի փոխանցման և նվագարկման համար: Այդ նպատակով, ի թիվս այլ բաների, օգտագործվում է UDP արձանագրությունը:
Նախքան ձեզ կասենք, թե ինչ է տալիս նոր շարժիչը օգտագործողին, մենք ձեզ կհիշեցնենք, թե ինչու և ինչու ենք մենք աջակցում HLS տեխնոլոգիաներին, և ինչու որոշեցինք առաջ գնալ:
HLS շարժիչ՝ դրական և բացասական կողմեր
()
HLS (HTTP ուղիղ հեռարձակում) տեխնոլոգիան մշակվել է Apple-ի կողմից, ուստի զարմանալի չէ, որ այն սկզբում աջակցվել է Apple սարքերում: Այսօր HLS տեսանյութը աջակցվում է նաև գրեթե բոլոր թվային ընդունիչների և այդ օպերացիոն համակարգով աշխատող բազմաթիվ սարքերի կողմից: Android.
HLS շարժիչը օգտագործում է հայտնի H264 վիդեո կոդեկը AAC կամ MP3 աուդիո հոսքերի հետ համատեղ՝ վիդեո տվյալների հոսքի համար: Աուդիո և վիդեո տվյալների ամբողջ հոսքը փաթեթավորված է MPEG-TS տրանսպորտային կոնտեյների մեջ: HTTP արձանագրության միջոցով փոխանցման համար հոսքի մեջ պարունակվող տեղեկատվությունը բաժանվում է m3u8 երգացանկերում նկարագրված հատվածների: Եվ միայն դրանից հետո այս հատվածները, երգացանկերի հետ միասին, փոխանցվում են HTTP-ի միջոցով: Մանրացնելը ավտոմատ կերպով նշանակում է վայրկյաններով ուշացում: Սա MPEG-TS կոնտեյների առանձնահատկությունն է:
HLS շարժիչը նաև աջակցում է բազմաբիթային հոսքեր՝ Live/VOD:
HLS-ի հիմնական առավելությունները.
- ներկառուցված աջակցություն բոլոր հիմնական բրաուզերներում;
- իրականացման հեշտությունը (համեմատ WebRTC-ի հետ);
- Շատ հարմար և արդյունավետ է կազմակերպել բոլոր տեսակի հեռարձակումները մեծ լսարանի համար, քանի որ հատվածները կարող են մեկ անգամ վերբեռնվել CDN-ում:
Չնայած շարժիչի պարզությանը, ամեն ինչ այնքան հարթ չէ, որքան թվում է: Հիմնական խնդիրն այն է, որ երրորդ կողմի նվագարկիչների մշակողները հեռացել են Apple-ի առաջարկություններից, օրինակ՝ աջակցվող աուդիո ձևաչափերի առումով: Մասնավորապես, շատ ծրագրավորողներ սկսեցին ավելացնել հանրաճանաչ աուդիո հոսքերի հետ աշխատելու հնարավորությունը՝ mpeg2 վիդեո, mpeg2 աուդիո և այլն: Արդյունքում նրանք ստիպված էին տարբեր նվագարկիչների համար ստեղծել երգացանկի տարբեր ձևաչափեր:
Սակայն HLS շարժիչի ամենամեծ խնդիրներից մեկը տվյալների փոխանցման բարձր ուշացումն է:
«Արգելակների» ծագումը
HLS-ի բարձր հետաձգման հիմնական պատճառը կայանում է նրանում, որ ծրագրավորողները շարժիչը ստեղծել են ամենաբարձր որակի պատկերներ ստանալու համար: Հետևաբար, օգտագործվող կադրերի միջակայքի պարամետրերը և նվագարկման բուֆերի չափը պարզապես հարմար չեն ուղիղ վիդեո հեռարձակումների համար: Դրա պատճառով տեսագրությունների փոխանցման բավականին մեծ ուշացում կա, որը կարող է լինել 5-7 վայրկյան:
Սա մի կողմից շատ չէ, օրինակ նրանց համար, ովքեր ֆիլմ են դիտում վիդեոհոսթինգ սերվերից։ Բայց տեսահսկման համակարգերի համար տեսագրությունների փոխանցման հետաձգումը կարող է շատ կարևոր լինել:
Եթե դուք դիտում եք գրասենյակ, որտեղ աշխատակիցները ժամը մեկ անգամ նայում են մոնիտորներից, ապա 5 վայրկյան ուշացումն ընդհանրապես նշանակություն չունի: Բայց մարդիկ սկսեցին դժգոհել, որ, օրինակ, ֆուտբոլային հանդիպում հեռարձակելիս, արդեն չաթում գրել են ԳՈՈՈՈԼ, բայց սա դեռ տեսանյութում չկա :)։ Մենք արդեն ունենք մի շարք օգտատերերի դեպքեր, երբ Ivideon-ը գործնականում պետք է փոխարինի Skype-ին:
Հնարավո՞ր է արդյոք հաղթահարել ուշացումը HLS-ում: Այս հարցի պատասխանը հնչում է ինչպես փորձառու առնետների ոչնչացնողի ելույթը վնասատուների դեմ պայքարի սկսնակ մասնագետների համար դասախոսության ժամանակ. Նույնը HLS-ի հետաձգման դեպքում հնարավոր չի լինի այն զրոյացնել, սակայն շուկայում կան լուծումներ, որոնք կարող են զգալիորեն նվազեցնել ուշացումը:
Նուրբ կտրվածքներ
Շարժիչի մեկ այլ թերություն տվյալների փոխանցման համար փոքր ֆայլերի օգտագործումն է: Թվում է, թե ինչն է սխալ դրանում:
Ամեն ոք, ով փորձել է պատճենել մեծ թվով փոքր ֆայլեր մի միջավայրից մյուսը, հավանաբար նկատել է, որ նման հավաքածուի գրելու արագությունը շատ ավելի ցածր է, քան նույն չափի մեկ մեծ ֆայլը: Իսկ կոշտ սկավառակի մուտքի ինտենսիվությունը զգալիորեն մեծանում է, ինչը, ընդհանուր առմամբ, բացասաբար է անդրադառնում ամբողջ համակարգչի աշխատանքի վրա: Հետևաբար, վիդեո տվյալների փոխանցումը փոքր 10 վայրկյանանոց հատվածներով նույնպես նպաստում է շարժիչի հետաձգմանը:
Եկեք համառոտ ամփոփենք HLS տեխնոլոգիայի բոլոր դրական և բացասական կողմերը:
HLS-ի առավելությունները.
- Ցանկացած սարքի հետ աշխատելու ունակություն: Դուք կարող եք դիտել տեսանյութեր ցանկացած ժամանակակից սարքով, լինի դա սմարթֆոն, պլանշետ, նոութբուք կամ աշխատասեղան համակարգիչ: Հիմնական բանը այն է, որ վեբ բրաուզերը արդիական է և համատեղելի HTML5-ի և Media Source Extensions-ի հետ:
- Գերազանց պատկերի որակ: Օգտագործված տվյալների փոխանցման հարմարվողական գործառույթը թույլ է տալիս դինամիկ կերպով փոխել փոխանցվող տեսանյութի որակը՝ կախված ինտերնետ կապի թողունակությունից, մինչդեռ ալգորիթմը ձգտում է պահպանել առավելագույն որակը:
- Օգտագործողի սարքավորումների բարդ կոնֆիգուրացիայի կարիք չկա:
Թերությունները:
- Որոշ սարքերում շարժիչի հետ աշխատելու սահմանափակ աջակցություն:
- Պատկերի փոխանցման մեծ ուշացումներ:
- Օպտիմալացման ընդհանուր ծախսերի և բարդության զգալի աճ՝ փոքր ֆայլերի օգտագործման պատճառով: Կոնտեյների բնույթից ելնելով, մենք երբեք չենք կարողանա ստանալ հատվածի չափից ցածր ուշացում:
HLS-ի թերությունները մեզ համար գերազանցեցին նրա առավելությունները և ստիպեցին մեզ այլընտրանքային տարբերակներ փնտրել:
Ինչ է WebRTC-ն
()
WebRTC պլատֆորմը մշակվել է Google-ի կողմից 2011 թվականին՝ հոսքային վիդեո և աուդիո տվյալներ բրաուզերների և բջջային հավելվածների միջև փոխանցելու նվազագույն ուշացումով: Դրա համար օգտագործվում են ստանդարտ UDP արձանագրություն և հոսքի կառավարման հատուկ ալգորիթմներ: Այսօր այն բաց կոդով նախագիծ է, որը ակտիվորեն պահպանվում և մշակվում է Google-ի կողմից:
WebRTC-ն տեխնոլոգիաների մի շարք է հավասարակցին վիդեո և աուդիո փոխանցման համար: Այսինքն, օրինակ, WebRTC օգտագործող օգտատերերի բրաուզերները կարող են ուղղակիորեն տվյալներ փոխանցել միմյանց՝ առանց տվյալների պահպանման և մշակման համար հեռավոր սերվերների օգտագործման: Ամբողջ տեղեկատվությունը մշակվում է նաև վերջնական օգտագործողների բրաուզերների և բջջային հավելվածների կողմից:
Այս տեխնոլոգիայի հարմարավետությունն ու լայն հնարավորությունները գնահատվել են բոլոր հայտնի բրաուզերների մշակողների կողմից: WebRTC աջակցությունն այժմ հասանելի է Mozilla Firefox-ում, Opera-ում, Google Chrome-ում (և Chromium-ի վրա հիմնված բոլոր բրաուզերներում), ինչպես նաև բջջային հավելվածներում, որոնք աշխատում են... Android և iOS.
Չնայած իր բոլոր անկասկած առավելություններին, WebRTC-ն ունի մի քանի նշանակալի թերություններ:
Ընտրության դժվարություն
WebRTC տեխնոլոգիան շատ ավելի բարդ է ցանցային փոխազդեցությունների առումով՝ պայմանավորված այն հանգամանքով, որ խոսքը P2P-ի մասին է։ Դժվար է վրիպազերծել, փորձարկել և կարող է անկանխատեսելի վարվել: Միևնույն ժամանակ, մենք պետք է հաղթահարենք NAT-ը և firewall-ը, մենք պետք է ապահովենք աշխատանքը ցանցերում, որտեղ UDP-ն արգելափակված է։
Google-ի WebRTC ներդրումը շատ դժվար է օգտագործել: Կա նույնիսկ մի ամբողջ ընկերություն, որը տրամադրում է SDK հավաքման ծառայություններ: Բացի այդ, Google-ի ներդրումը շատ դժվար էր ինտեգրվել մեր համակարգին՝ առանց ամբողջ տեսանյութը նորից կոդավորելու:
Այնուամենայնիվ, մենք վաղուց ցանկանում էինք օգտատերերին հնարավորություն տալ աշխատել լիարժեք «կենդանի» տեսահոլովակով և նվազագույնի հասցնել էկրանի պատկերի և հենց իրադարձությունների միջև եղած ուշացումը: Բացի այդ, մենք ցանկություն ունեինք ավելի հարմարավետ դարձնել PTZ տեսախցիկների օգտագործումը, որտեղ ուշացումները կարևոր են:
Հաշվի առնելով, որ հակահետաձգման այլ ծրագրերը դեռևս ունեն սահմանափակ ֆունկցիոնալություն և նկատելիորեն ավելի վատ են աշխատում, մենք որոշեցինք օգտագործել WebRTC:
Ինչ ենք արել
WebRTC հարթակի ճիշտ ներդրումը հեշտ գործ չէ: Ցանկացած սխալ հաշվարկ կամ անճշտություն կարող է հանգեցնել տեսահաղորդման ուշացումների ոչ միայն այլ հարթակների համեմատությամբ չպակասելու, այլ նույնիսկ ավելանալու։
Որպեսզի WebRTC-ն ճիշտ աշխատի, առաջին հերթին անհրաժեշտ է կատարել վեբ տեսանյութերի հետ աշխատելու համար նախատեսված ստեկի տեխնոլոգիական արդիականացում։ Մենք այդպես էլ արեցինք։
Նախ, մենք ներդրեցինք WebRTC ազդանշանային արձանագրության սերվեր Websocket-ի միջոցով, ինչպես նաև տեղակայեցինք WebRTC սերվերը ամպում, որը հիմնված է webrtc.org SDK-ի վրա: Նրա խնդիրն է բաշխել վիդեո հոսքերը WebRTC հաճախորդներին H.264 + Opus/G.711 ձևաչափով՝ առանց վիդեո տրանսկոդավորման:
Մենք ընտրեցինք Websocket-ը որպես ազդանշանային արձանագրություն, քանի որ այն արդեն ունի բարձրորակ աջակցություն բոլոր հայտնի վեբ բրաուզերներում: Դրա շնորհիվ դուք կարող եք զգալիորեն կրճատել ոչ միայն զարգացման ծախսերը, այլև խուսափել ժամանակի և ռեսուրսների վատնումից կրկնվող TCP և TLS ձեռքսեղմումների վրա՝ համեմատած AJAX-ի հետ:
Փաստն այն է, որ լռելյայնորեն WebRTC-ն չի տրամադրում ազդանշանային արձանագրություն, որն անհրաժեշտ է աղբյուրի և հաճախորդի հավելվածների միջև իրական ժամանակում վիդեո հաղորդակցությունը ճիշտ կարգավորելու, պահպանելու և դադարեցնելու համար:
Իսկ ազդանշանային տեխնոլոգիան ինքնուրույն իրականացնելու համար մեզ անհրաժեշտ էր զարգացնել մեր սեփական ազդանշանային սերվերը՝ մի քանի վեբ արձանագրությունների աջակցությամբ (Websocet, WebRTC): Եվ իրական ժամանակում նիստերն ու ծանուցումները անվտանգ կառավարելու ունակությամբ, տեսանյութերի կառավարում և շատ ավելին:
Մենք հաղթահարեցինք P2P-ի սահմանափակումները՝ նվազեցնելով հետաձգումը ոչ թե P2P-ի, այլ UDP-ի և հոսքի վերահսկման միջոցով՝ նվազեցնելու ուշացումը: Սա նաև ներկառուցված է WebRTC-ում, քանի որ հիմնական օգտագործման դեպքը p2p խոսակցություններն են բրաուզերի միջոցով:
Բջջային հաճախորդում մենք ներդրել ենք նվագարկիչը՝ օգտագործելով webrtc.org SDK-ն, քանի որ միայն այն է ճիշտ իրականացնում հոսքի կառավարումը, ունի բոլոր հայտնի Forward Error Correction (FEC) սխեմաները և ճիշտ իրականացնում է բոլոր բրաուզերների համար փաթեթները վերաուղարկելու մեխանիզմը: Կարևոր է նաև, որ webrtc.org SDK-ն ակտիվորեն մշակվում է Google-ի կողմից:
Ո՞րն է WebRTC-ի ներդրման արդյունքը:
Տեսախցիկներից ուղիղ եթերով տեսանյութ դիտելու համար մենք ձեր անձնական հաշվում ավելացրել ենք նոր օպտիմիզացված նվագարկիչ՝ հիմնված WebRTC-ի վրա: Այն ապահովում է տեսանյութերի բեռնման արագ արագություններ և ամբողջությամբ վերացնում է հետաձգման կուտակման խնդիրը, քանի որ դիտման ժամանակը մեծանում է:
Ivideon ամպային ծառայության մեջ WebRTC-ի աջակցությունը ներդնելուց հետո մենք կարող ենք լիակատար վստահությամբ ասել, որ մեր հաճախորդներն այժմ կարող են դիտել լիարժեք ուղիղ տեսանյութ: Այժմ տեսահոլովակների հեռարձակման հետաձգումը չի գերազանցում մեկ վայրկյանը: Համեմատության համար նշենք, որ նախորդ HLS շարժիչն ապահովում էր վիդեո առաքում 5-7 վայրկյան ուշացումով։ Տեսանյութերի ցուցադրման արագության տարբերությունը շատ զգալի է, և օգտատերը դա կնկատի մեր վիդեո ծառայության հետ աշխատելուց անմիջապես հետո։
Ինչպես և մենք ակնկալում էինք, նոր նվագարկչի ներդրումը բարելավեց PTZ-ի արձագանքման և տեսախցիկի հետ ձայնային հաղորդակցությունը:
Կա միայն մեկ նուրբ կետ, որի վրա մենք ուզում ենք ուշադրություն հրավիրել. Նոր WebRTC նվագարկիչը ներկայումս աշխատում է թեստային ռեժիմում: Եվ դա է պատճառը, որ մենք այն լռելյայն չենք միացնում մեր բոլոր հաճախորդների համար: Բայց դուք կարող եք ակտիվացնել այն ինքներդ՝ միացնելով համապատասխան տարրը տեսախցիկի կարգավորումներում (դա անելու համար հարկավոր է գնալ ).
WebRTC-ի ներդրման առանձնահատկությունները Ivideon ծառայությունում
WebRTC-ն այս պահին դեռ փորձնական տեխնոլոգիա է: Դրա աջակցությունը դեռ ճիշտ չի ներդրվել բոլոր բրաուզերներում և օգտագործողների սարքերում, ինչպես նաև ոչ բոլոր տեսախցիկներում:
Հենց սա է պատճառը, որ մենք դեռ չենք դարձրել WebRTC նվագարկիչը լռելյայն բոլոր օգտատերերի համար:
Առայժմ խորհուրդ ենք տալիս օգտագործել WebRTC միայն Google Chrome բրաուզերներում: Firefox-ի և Safari-ի վերջին տարբերակները նույնպես աջակցում են այս տեխնոլոգիային, բայց, ցավոք, այն դեռ անկայուն է։
Մենք դեռ չենք իրականացրել WebRTC աջակցություն շարժական սարքերի բրաուզերների համար: Ներկայումս, եթե մուտք գործեք շարժական սարքից և ակտիվացնեք WebRTC-ն, այս ռեժիմը չի աշխատի: Այնուամենայնիվ, WebRTC-ն հասանելի է մեր բջջային հավելվածներում и .
Եվ եզրափակելով պատմությունը մեր ծառայության մեջ WebRTC ներդրման առանձնահատկությունների մասին, նշենք ևս երկու նուրբ կետ:
Նախ, տեխնոլոգիան ուղղված է իրական ժամանակում ուղիղ եթերով հեռարձակման վրա: Հետևաբար, եթե ձեր ալիքը չունի բավարար թողունակություն տեսանյութը փոխանցելու համար, դուք կնկատեք կադրերի անկումներ (HLS-ով դուք կնկատեք տեսանյութի խամրում և հետաձգման ավելացում, բայց կադրերի անկումներ չեն լինի), բայց տեսանյութը դեռ կհեռարձակվի իրականում։ ժամանակ.
Երկրորդ, քանի որ տեխնոլոգիան նախատեսված է իրական ժամանակում հատուկ կենդանի տեսանյութերի հետ աշխատելու համար, մենք այն չենք օգտագործում արխիվացված վիդեո տվյալների հետ աշխատելու համար:
Ծառայության այլ փոփոխություններ
Այս պահին Flash-ն այլևս ներգրավված չէ շարժիչի ընտրության ավտոմատ մեխանիզմում: Դուք դեռ կարող եք օգտագործել նման նվագարկիչ, բայց դա անելու համար անհրաժեշտ է ձեռքով ընտրել այն հաշվի կամ տեսախցիկի կարգավորումներում: Սա հարգանքի տուրք չէ նորաձևությանը, պարզապես, մեր ծառայության վիճակագրության համաձայն, Flash-ով աշխատող օգտատերեր գործնականում չեն մնացել: Եվ փորձելով որոշել, թե արդյոք օգտագործողի զննարկիչը աջակցում է դրան, մենք կորցնում ենք մոտ 2 վայրկյան թանկարժեք ժամանակ:
Ահա փոփոխությունների համառոտ ակնարկ, որոնք սպասում են ձեզ մեր ամպային տեսահսկման համակարգում և անձնական հաշվում: Մնացեք մեզ հետ և հետևեք նորություններին:
Source: www.habr.com
