Տեսահաղորդակցությունը Vimbox հարթակում ուսուցչի և աշակերտի միջև շփման հիմնական միջոցն է։ Մենք վաղուց հրաժարվեցինք Skype-ից, փորձեցինք երրորդ կողմի մի քանի լուծումներ և ի վերջո տեղավորվեցինք WebRTC - Janus-gateway համակցության վրա: Որոշ ժամանակ մենք գոհ էինք ամեն ինչից, բայց այնուամենայնիվ որոշ բացասական կողմեր շարունակում էին ի հայտ գալ։ Արդյունքում ստեղծվել է առանձին տեսաուղղություն։
Ես խնդրեցի նոր ուղղության ղեկավար Կիրիլ Ռոգովոյին խոսել Skyeng-ում տեսահաղորդակցության էվոլյուցիայի, հայտնաբերված խնդիրների, լուծումների և հենակների մասին, որոնք մենք ի վերջո օգտագործեցինք: Հուսով ենք, որ հոդվածը օգտակար կլինի այն ընկերությունների համար, որոնք նաև ինքնուրույն տեսանյութ են ստեղծում վեբ հավելվածի միջոցով:
Մի քիչ պատմություն
2017 թվականի ամռանը Skyeng-ի զարգացման ղեկավար Սերգեյ Սաֆոնովը խոսեց Backend Conf-ում՝ պատմելով այն մասին, թե ինչպես մենք «լքեցինք Skype-ը և իրականացրեցինք WebRTC»-ն։ Ցանկացողները կարող են դիտել ելույթի ձայնագրությունը՝ ք (~45 րոպե), և այստեղ ես հակիրճ ուրվագծեմ դրա էությունը։
Skyeng դպրոցի համար տեսահաղորդակցությունը միշտ եղել է ուսուցիչ-աշակերտ շփման առաջնահերթ միջոց: Սկզբում օգտագործվեց Skype-ը, սակայն այն կտրականապես գոհացուցիչ չէր մի շարք պատճառներով, առաջին հերթին տեղեկամատյանների բացակայության և անմիջապես վեբ հավելվածում ինտեգրվելու անհնարինության պատճառով։ Ուստի մենք իրականացրել ենք բոլոր տեսակի փորձեր։
Իրականում տեսահաղորդակցության մեր պահանջները մոտավորապես հետևյալն էին.
- կայունություն;
- ցածր գին մեկ դասի համար;
— ձայնագրման դասեր;
— հետևել, թե ով ինչքան է խոսում (մեզ համար կարևոր է, որ դասերի ժամանակ ուսանողներն ավելի շատ խոսեն, քան ուսուցիչը);
- գծային մասշտաբավորում;
- ինչպես UDP, այնպես էլ TCP օգտագործելու ունակություն:
Առաջինը փորձել է Tokbox-ի ներդրումը 2013թ. Ամեն ինչ լավ էր, բայց պարզվեց, որ շատ թանկ արժեր՝ 113 ռուբլի մեկ դասի համար, և կերավ շահույթը։
Այնուհետև 2015 թվականին Voximplant-ը ինտեգրվեց: Ահա այն գործառույթը, որը մեզ անհրաժեշտ էր՝ հետևելու համար, թե ով ինչքան է խոսում, և միևնույն ժամանակ լուծումը շատ ավելի էժան էր՝ եթե ձայնագրվում էր միայն ձայնագրությունը, այն արժեր 20 ռուբլի մեկ դասի համար։ Այնուամենայնիվ, այն աշխատում էր միայն UDP-ի միջոցով և չէր կարող անցնել TCP-ին: Այնուամենայնիվ, ուսանողների մոտ 40%-ն ի վերջո սկսեց օգտագործել այն:
Մեկ տարի անց մենք սկսեցինք ունենալ կորպորատիվ հաճախորդներ՝ իրենց հատուկ պահանջներով: Օրինակ, ամեն ինչ պետք է աշխատի բրաուզերի միջոցով, ընկերությունը բացում է միայն http և https; այսինքն՝ չկա Skype կամ UDP: Կորպորատիվ հաճախորդներ = փող, ուստի նրանք վերադարձան Tokbox, բայց գնի խնդիրը չվերացավ:
Լուծում - WebRTC և Janus
Որոշել է օգտագործել . Այն պատասխանատու է կապի հաստատման, հոսքերի կոդավորման և վերծանման, հետագծերի համաժամացման և որակի վերահսկման համար՝ ցանցային խափանումների հետ: Մեր կողմից, մենք պետք է ապահովենք տեսախցիկից և խոսափողից հոսքերի ընթերցումը, տեսանյութերի նկարումը, կապի կառավարումը, WebRTC կապի հաստատումը և հոսքերի փոխանցումը, ինչպես նաև հաճախորդների միջև ազդանշանային հաղորդագրությունների փոխանցումը կապ հաստատելու համար (WebRTC-ն ինքն է նկարագրում միայն տվյալների ձևաչափը, բայց ոչ դրա մեխանիզմի փոխանցումները): Եթե հաճախորդները կանգնած են NAT-ի հետևում, WebRTC-ն միացնում է STUN սերվերները, եթե դա չի օգնում, շրջեք սերվերները:
Մեզ համար սովորական p2p կապը բավարար չէ, քանի որ մենք ցանկանում ենք դասեր ձայնագրել՝ բողոքների դեպքում հետագա վերլուծության համար։ Հետևաբար, մենք ուղարկում ենք WebRTC հոսքեր ռելեի միջոցով . Արդյունքում հաճախորդները չգիտեն միմյանց հասցեները՝ տեսնելով միայն Janus սերվերի հասցեն; այն նաև կատարում է ազդանշանային սերվերի գործառույթները: Janus-ն ունի մեզ անհրաժեշտ շատ գործառույթներ. ավտոմատ կերպով անցնում է TCP-ի, եթե հաճախորդը արգելափակել է UDP-ն; կարող է գրանցել ինչպես UDP, այնպես էլ TCP հոսքեր; մասշտաբային; Կա նույնիսկ ներկառուցված փլագին արձագանքների թեստերի համար: Անհրաժեշտության դեպքում, STUN և TURN սերվերները Twilio-ից ավտոմատ կերպով միացված են:
2017-ի ամռանը մենք ունեինք երկու Janus սերվեր, ինչպես նաև լրացուցիչ սերվեր՝ ձայնագրված չմշակված աուդիո և վիդեո ֆայլերի մշակման համար, որպեսզի չզբաղեցնենք հիմնականների պրոցեսորները։ Միանալիս Janus սերվերներն ընտրվել են կենտ-զույգ սկզբունքով (միացման համար): Այն ժամանակ սա բավական էր, ըստ մեր զգացմունքների, այն տալիս էր մոտավորապես չորս անգամ անվտանգության մարժան, կատարման տոկոսը մոտ 80 էր: Միևնույն ժամանակ, գինը նվազեցվեց մինչև ~ 2 ռուբլի մեկ դասի համար, գումարած զարգացում և աջակցություն:
Վերադառնալով տեսահաղորդակցության թեմային
Մենք մշտապես վերահսկում ենք ուսանողների և ուսուցիչների արձագանքները՝ խնդիրները ժամանակին բացահայտելու և ուղղելու համար: 2018 թվականի ամռանը զանգերի որակը հաստատապես առաջին տեղում էր բողոքների շարքում: Սա մի կողմից նշանակում էր, որ մենք հաջողությամբ հաղթահարել ենք այլ թերություններ։ Մյուս կողմից, անհրաժեշտ էր շտապ ինչ-որ բան անել. եթե դասը խանգարում է, մենք վտանգում ենք կորցնել դրա արժեքը, երբեմն՝ հաջորդ փաթեթը գնելու ծախսերի հետ մեկտեղ, իսկ եթե ներածական դասը խանգարում է, մենք ռիսկի ենք դիմում կորցնել պոտենցիալ հաճախորդին։ ընդհանրապես։
Այն ժամանակ մեր տեսահաղորդակցությունը դեռ MVP ռեժիմում էր։ Պարզ ասած՝ գործարկեցին, աշխատեց, մեկ անգամ չափեցին, հասկացան՝ ինչպես անել՝ լավ, հիանալի։ Եթե դա աշխատում է, մի ուղղեք այն: Ոչ ոք միտումնավոր չի անդրադարձել կապի որակի խնդրին: Օգոստոսին պարզ դարձավ, որ դա չի կարող շարունակվել, և մենք գործարկեցինք առանձին ուղղություն՝ պարզելու, թե ինչն է սխալ WebRTC-ի և Janus-ի հետ:
Մուտքագրման արդյունքում այս ուղղությունը ստացավ. MVP լուծում, չափումներ, նպատակներ, բարելավման գործընթացներ չկան, մինչդեռ ուսուցիչների 7%-ը դժգոհում է հաղորդակցության որակից (ուսանողների մասին նույնպես տվյալներ չկան):
Նոր ուղղություն է ընթանում
Հրամանն այսպիսի տեսք ունի.
- Բաժնի պետը, որը նաև հիմնական կառուցապատողն է։
- QA-ն օգնում է փորձարկել փոփոխությունները, որոնում է կապի անկայուն պայմաններ ստեղծելու նոր ուղիներ և հայտնում խնդիրների առաջնագծից:
- Վերլուծաբանը մշտապես փնտրում է տարբեր հարաբերակցություններ տեխնիկական տվյալների մեջ, բարելավում է օգտատերերի հետադարձ կապի վերլուծությունը և ստուգում է փորձերի արդյունքները։
- Արտադրանքի մենեջերն օգնում է փորձերի ընդհանուր ուղղորդմանը և ռեսուրսների բաշխմանը:
- Երկրորդ մշակողը հաճախ օգնում է ծրագրավորման և հարակից առաջադրանքների հարցում:
Սկզբից մենք ստեղծեցինք համեմատաբար հուսալի չափիչ, որը հետևում էր հաղորդակցության որակի գնահատման փոփոխություններին (միջին օրերի, շաբաթների, ամիսների ընթացքում): Այն ժամանակ սրանք ուսուցիչների գնահատականներ էին, ավելի ուշ դրանց ավելացան ուսանողների գնահատականները։ Հետո նրանք սկսեցին վարկածներ կառուցել այն մասին, թե ինչն է սխալ աշխատում, ուղղեցին այն և դիտարկեցին դինամիկայի փոփոխությունները: Մենք գնացինք ցածր կախված մրգերի. օրինակ, մենք փոխարինեցինք vp8 կոդեկը vp9-ով, կատարողականությունը բարելավվեց: Մենք փորձեցինք խաղալ Janus-ի կարգավորումների հետ և կատարել այլ փորձեր. շատ դեպքերում դրանք ոչնչի չեն հանգեցրել:
Երկրորդ փուլում ի հայտ եկավ վարկած. WebRTC-ն հավասարազոր լուծում է, իսկ մեջտեղում մենք օգտագործում ենք սերվեր: Միգուցե խնդիրը այստեղ է. Մենք սկսեցինք փորել և գտանք մինչ այժմ ամենաէական բարելավումը:
Այդ պահին լողավազանից մի սերվեր ընտրվեց բավականին հիմար ալգորիթմի միջոցով. յուրաքանչյուրն ուներ իր «քաշը»՝ կախված կապուղուց և հզորությունից, և մենք փորձեցինք օգտատերին ուղարկել ամենամեծ «քաշը» ունեցողին, առանց. ուշադրություն դարձնելով, թե որտեղ է գտնվել օգտատերը աշխարհագրական առումով: Արդյունքում Սանկտ Պետերբուրգի ուսուցիչը կարող էր Մոսկվայի միջոցով շփվել Սիբիրից եկած աշակերտի հետ, այլ ոչ թե Սանկտ Պետերբուրգի մեր Janus սերվերի միջոցով։
Ալգորիթմը վերամշակվել է. այժմ, երբ օգտատերը բացում է մեր հարթակը, մենք նրանից ping-ներ ենք հավաքում Ajax-ի օգտագործող բոլոր սերվերներին: Կապ հաստատելիս ընտրում ենք զույգ պինգ (ուսուցիչ-սերվեր և աշակերտ-սերվեր) ամենափոքր քանակով։ Ավելի քիչ ping նշանակում է ցանցի ավելի քիչ հեռավորություն դեպի սերվեր; ավելի կարճ հեռավորությունը նշանակում է փաթեթներ կորցնելու ավելի քիչ հավանականություն. Փաթեթների կորուստը տեսահաղորդակցության ամենամեծ բացասական գործոնն է: Բացասականի մասնաբաժինը երեք ամսվա ընթացքում կիսով չափ կրճատվեց (արդարության համար նշենք, որ այս պահին այլ փորձեր են իրականացվել, բայց այս մեկը գրեթե անկասկած ամենաշատ ազդեցությունն է ունեցել):
Վերջերս մենք հայտնաբերեցինք ևս մեկ ոչ ակնհայտ, բայց ակնհայտորեն կարևոր բան. հաստ ալիքով մեկ հզոր Janus սերվերի փոխարեն ավելի լավ է ունենալ երկու ավելի պարզ՝ ավելի բարակ թողունակությամբ: Սա պարզ դարձավ այն բանից հետո, երբ մենք գնեցինք հզոր մեքենաներ՝ հույս ունենալով, որ նույնքան սենյակներ (հաղորդակցման սեանսներ) խցկենք դրանց մեջ: Սերվերներն ունեն թողունակության սահմանափակում, որը մենք կարող ենք ճշգրիտ թարգմանել սենյակների քանակով. մենք գիտենք, թե քանիսը կարելի է բացել, օրինակ, 300 Մբիթ/վրկ արագությամբ: Հենց որ սերվերի վրա չափազանց շատ սենյակներ կան, մենք դադարում ենք ընտրել այն նոր գործողությունների համար, մինչև բեռնվածությունը նվազի: Գաղափարը կայանում էր նրանում, որ հզոր մեքենա գնելով, մենք ալիքը բեռնում ենք առավելագույնը դրա վրա, որպեսզի ի վերջո այն սահմանափակվի պրոցեսորով և հիշողությամբ, այլ ոչ թե թողունակությամբ։ Բայց պարզվեց, որ որոշակի թվով բաց սենյակներից հետո (420), չնայած այն հանգամանքին, որ պրոցեսորի, հիշողության և սկավառակի բեռը դեռ շատ հեռու է սահմաններից, բացասականությունը սկսում է հասնել տեխնիկական աջակցության: Երևում է, Յանուսի ներսում ինչ-որ բան վատանում է, միգուցե այնտեղ էլ կան որոշակի սահմանափակումներ։ Մենք սկսեցինք փորձարկել, թողունակության սահմանը 300-ից իջեցրինք 200 Մբիթ/վրկ, և խնդիրները վերացան: Այժմ մենք գնեցինք միանգամից երեք նոր սերվեր՝ ցածր սահմաններով և բնութագրերով, կարծում ենք, որ դա կհանգեցնի կապի որակի կայուն բարելավմանը։ Իհարկե, մենք չփորձեցինք պարզել, թե ինչի մասին է խոսքը, մեր հենակները ամեն ինչ էին: Ի պաշտպանություն մեզ, ասենք, որ այդ պահին անհրաժեշտ էր հնարավորինս արագ լուծել հրատապ խնդիրը, այլ ոչ թե դա անել գեղեցիկ. բացի այդ, Յանուսը մեզ համար C-ով գրված սև արկղ է, դրա հետ հարելը շատ թանկ արժե։
Դե, գործընթացում մենք.
- թարմացրել է բոլոր կախվածությունները, որոնք կարող էին թարմացվել ինչպես սերվերի, այնպես էլ հաճախորդի վրա (սրանք նույնպես փորձեր էին, մենք վերահսկում էինք արդյունքները);
- ուղղել է բոլոր հայտնաբերված սխալները՝ կապված կոնկրետ դեպքերի հետ, օրինակ, երբ կապն անջատվել է և ինքնաբերաբար չի վերականգնվել.
- Մենք բազմաթիվ հանդիպումներ ենք անցկացրել տեսահաղորդակցության ոլորտում աշխատող և մեր խնդիրներին ծանոթ ընկերությունների հետ. սթրիմինգ խաղեր, վեբինարների կազմակերպում; մենք փորձեցինք այն ամենը, ինչը մեզ օգտակար էր թվում.
- Իրականացրել է ուսուցիչների ապարատային և հաղորդակցման որակի տեխնիկական ստուգում, որոնցից ամենաշատ բողոքներն են եղել:
Փորձերը և հետագա փոփոխությունները հնարավորություն են տվել նվազեցնել ուսուցիչների միջև հաղորդակցությունից դժգոհությունը 7,1 թվականի հունվարի 2018%-ից մինչև 2,5 թվականի հունվարին 2019%:
Ինչ է հաջորդը
Մեր Vimbox պլատֆորմի կայունացումը ընկերության 2019 թվականի գլխավոր նախագծերից մեկն է։ Մենք մեծ հույսեր ունենք, որ մենք կկարողանանք պահպանել թափը և այլևս չենք տեսնի տեսահաղորդակցությունը հիմնական բողոքների մեջ: Մենք հասկանում ենք, որ այդ բողոքների մի զգալի մասը կապված է օգտատերերի համակարգիչների և ինտերնետի հետաձգման հետ, բայց մենք պետք է որոշենք այս մասը, իսկ մնացածը լուծենք։ Մնացած ամեն ինչ տեխնիկական խնդիր է, կարծես թե պետք է կարողանանք գլուխ հանել դրանից։
Հիմնական դժվարությունն այն է, որ մենք չգիտենք, թե իրականում ինչ մակարդակով է հնարավոր բարելավել որակը։ Այս առաստաղը պարզելը հիմնական խնդիրն է: Հետևաբար, երկու փորձ էր նախատեսվում.
- համեմատեք տեսանյութը Janus-ի միջոցով սովորական p2p-ի հետ մարտական պայմաններում: Այս փորձն արդեն իրականացվել է, մեր լուծույթի և p2p-ի միջև վիճակագրորեն նշանակալի տարբերություն չի հայտնաբերվել;
- Եկեք մատուցենք (թանկ) ծառայություններ այն ընկերություններից, որոնք գումար են վաստակում բացառապես տեսահաղորդակցության լուծումների վրա և համեմատենք դրանցից բացասականի չափը գոյություն ունեցողի հետ։
Այս երկու փորձերը մեզ թույլ կտան բացահայտել հասանելի նպատակը և կենտրոնանալ դրա վրա:
Բացի այդ, կան մի շարք խնդիրներ, որոնք կարող են լուծվել կանոնավոր կերպով.
- Մենք ստեղծում ենք հաղորդակցության որակի տեխնիկական չափանիշ՝ սուբյեկտիվ ակնարկների փոխարեն.
- Մենք կազմում ենք ավելի մանրամասն նիստերի մատյաններ, որպեսզի ավելի ճշգրիտ վերլուծենք տեղի ունեցած ձախողումները, հասկանանք, թե կոնկրետ երբ և որտեղ են դրանք տեղի ունեցել, և ինչ թվացյալ կապ չունեցող իրադարձություններ են տեղի ունեցել այդ պահին.
- Մենք դասից առաջ պատրաստում ենք կապի որակի ավտոմատ թեստ, ինչպես նաև հաճախորդին հնարավորություն ենք տալիս ձեռքով փորձարկել կապը, որպեսզի նվազեցնի իր ապարատով և ալիքով առաջացած բացասականությունը.
- մենք կմշակենք և կանցկացնենք ավելի շատ տեսահաղորդակցության բեռնվածության թեստեր վատ պայմաններում, փաթեթների փոփոխական կորստով և այլն;
- մենք փոխում ենք սերվերների վարքագիծը խնդիրների դեպքում՝ սխալների հանդուրժողականությունը բարձրացնելու համար.
- Մենք կզգուշացնենք օգտատիրոջը, եթե նրա կապի մեջ ընդհանրապես ինչ-որ բան այն չէ, ինչպես դա անում է Skype-ը, որպեսզի նա հասկանա, որ խնդիրն իր կողմն է։
Ապրիլից ի վեր վիդեո հաղորդակցության ուղղությունը դարձել է լիարժեք առանձին նախագիծ Skyeng-ի շրջանակներում, որը զբաղվում է սեփական արտադրանքով, ոչ միայն Vimbox-ի մի մասով: Սա նշանակում է, որ մենք սկսում ենք մարդկանց փնտրել . Դե, ինչպես միշտ .
Եվ, իհարկե, մենք շարունակում ենք ակտիվորեն շփվել տեսահաղորդակցության ոլորտում աշխատող մարդկանց և ընկերությունների հետ։ Եթե ցանկանում եք փորձի փոխանակում կատարել մեզ հետ, մենք ուրախ կլինենք: Մեկնաբանեք, կապ հաստատեք - մենք կպատասխանենք բոլորին։
Source: www.habr.com