Komunikimi me video është mënyra kryesore e komunikimit mes mësuesit dhe nxënësit në platformën Vimbox. Ne hoqëm dorë nga Skype shumë kohë më parë, provuam disa zgjidhje të palëve të treta dhe përfundimisht u vendosëm në kombinimin WebRTC - Janus-gateway. Për disa kohë ishim të kënaqur me gjithçka, por megjithatë disa aspekte negative vazhduan të shfaqeshin. Si rezultat, u krijua një drejtim i veçantë video.
I kërkova Kirill Rogovoy, kreut të drejtimit të ri, të fliste për evolucionin e komunikimit me video në Skyeng, problemet e zbuluara, zgjidhjet dhe patericat që përdorëm në fund. Shpresojmë që artikulli të jetë i dobishëm për kompanitë që krijojnë video vetë përmes një aplikacioni në internet.
Pak histori
Në verën e vitit 2017, kreu i zhvillimit të Skyeng, Sergey Safonov, foli në Backend Conf me një histori se si ne "braktisim Skype dhe implementuam WebRTC". Të interesuarit mund të shikojnë regjistrimin e fjalimit në (~45 min), dhe këtu do të përshkruaj shkurtimisht thelbin e saj.
Për Shkollën Skyeng, komunikimi me video ka qenë gjithmonë një mënyrë prioritare e komunikimit mësues-nxënës. Në fillim u përdor Skype, por kategorikisht nuk ishte i kënaqshëm për një sërë arsyesh, kryesisht për shkak të mungesës së regjistrave dhe pamundësisë së integrimit direkt në aplikacionin ueb. Prandaj, ne kryem të gjitha llojet e eksperimenteve.
Në fakt, kërkesat tona për komunikim me video ishin afërsisht si më poshtë:
- stabiliteti;
— çmim i ulët për mësim;
— regjistrimi i mësimeve;
— gjurmimi se kush sa flet (është e rëndësishme për ne që nxënësit të flasin më shumë se mësuesi gjatë mësimit);
— shkallëzim linear;
- aftësia për të përdorur si UDP ashtu edhe TCP.
E para që u përpoq ishte të zbatonte Tokbox në 2013. Gjithçka ishte e mirë, por doli të ishte shumë e shtrenjtë - 113 rubla për mësim - dhe hëngri fitimin.
Më pas në vitin 2015, Voximplant u integrua. Këtu ishte funksioni që na duhej për të gjurmuar se kush fliste sa, dhe në të njëjtën kohë zgjidhja ishte shumë më e lirë: nëse regjistrohej vetëm audio, kushtonte 20 rubla për mësim. Sidoqoftë, ai funksionoi vetëm përmes UDP dhe nuk mund të kalonte në TCP. Megjithatë, rreth 40% e studentëve përfunduan duke e përdorur atë.
Një vit më vonë, filluam të kishim klientë korporatash me kërkesat e tyre specifike. Për shembull, gjithçka duhet të funksionojë përmes një shfletuesi; kompania hap vetëm http dhe https; dmth pa Skype ose UDP. Klientët e korporatës = para, kështu që ata u kthyen në Tokbox, por problemi i çmimit nuk u largua.
Zgjidhja - WebRTC dhe Janus
Vendosi të përdorë . Ai është përgjegjës për vendosjen e një lidhjeje, kodimin dhe dekodimin e rrymave, sinkronizimin e gjurmëve dhe kontrollin e cilësisë me trajtimin e defekteve në rrjet. Nga ana jonë, ne duhet të sigurojmë leximin e transmetimeve nga kamera dhe mikrofoni, vizatimin e videos, menaxhimin e lidhjes, vendosjen e një lidhjeje WebRTC dhe transmetimin e transmetimeve në të, si dhe transmetimin e mesazheve sinjalizuese midis klientëve për të krijuar një lidhje (vetë WebRTC përshkruan vetëm formati i të dhënave, por jo transferimet e mekanizmit të tij). Nëse klientët janë prapa NAT-it, WebRTC lidh serverët STUN; nëse kjo nuk ju ndihmon, TURN serverët.
Një lidhje e rregullt p2p nuk na mjafton, sepse duam të regjistrojmë mësime për analiza të mëtejshme në rast ankesash. Prandaj ne dërgojmë transmetime WebRTC përmes një rele . Si rezultat, klientët nuk i dinë adresat e njëri-tjetrit, duke parë vetëm adresën e serverit Janus; ai gjithashtu kryen funksionet e një serveri sinjalesh. Janus ka shumë nga veçoritë që na duhen: kalon automatikisht në TCP nëse klienti ka UDP të bllokuar; mund të regjistrojë të dy rrymat UDP dhe TCP; i shkallëzuar; Ekziston edhe një shtojcë e integruar për testet e jehonës. Nëse është e nevojshme, serverët STUN dhe TURN nga Twilio lidhen automatikisht.
Në verën e vitit 2017, ne kishim dy serverë Janus në funksionim, plus një server shtesë për përpunimin e skedarëve audio dhe video të regjistruara të papërpunuara, në mënyrë që të mos zënë procesorët e atyre kryesore. Gjatë lidhjes, serverët Janus u zgjodhën në bazë tek-çift (numri i lidhjes). Në atë kohë, kjo ishte e mjaftueshme, sipas ndjenjave tona, ajo dha afërsisht një diferencë sigurie të katërfishtë, përqindja e zbatimit ishte rreth 80. Në të njëjtën kohë, çmimi u ul në ~ 2 rubla për mësim, plus zhvillim dhe mbështetje.
Kthimi në temën e komunikimit me video
Ne monitorojmë vazhdimisht reagimet nga nxënësit dhe mësuesit për të identifikuar dhe korrigjuar problemet në kohën e duhur. Deri në verën e vitit 2018, cilësia e thirrjeve ishte fort në vendin e parë midis ankesave. Nga njëra anë, kjo nënkuptonte se ne kishim kapërcyer me sukses të metat e tjera. Nga ana tjetër, ishte e nevojshme të bëhej diçka urgjentisht: nëse mësimi ndërpritet, rrezikojmë të humbasim vlerën e tij, ndonjëherë së bashku me koston e blerjes së paketës së radhës, dhe nëse mësimi hyrës ndërpritet, rrezikojmë të humbasim një klient të mundshëm. krejt.
Në atë kohë, komunikimi ynë me video ishte ende në modalitetin MVP. E thënë thjesht, ata e nisën atë, funksionoi, ata e shkallëzuan një herë, ata e kuptuan se si ta bënin - mirë, shkëlqyeshëm. Nëse funksionon, mos e rregulloni. Askush nuk e trajtoi qëllimisht çështjen e cilësisë së komunikimit. Deri në gusht, u bë e qartë se kjo nuk mund të vazhdonte dhe ne nisëm një drejtim të veçantë për të kuptuar se çfarë nuk shkonte me WebRTC dhe Janus.
Në hyrje, ky drejtim mori: një zgjidhje MVP, pa metrikë, pa qëllime, pa procese për përmirësim, ndërsa 7% e mësuesve ankohen për cilësinë e komunikimit (nuk kishte të dhëna as për studentët).
Një drejtim i ri është duke u zhvilluar
Komanda duket diçka si kjo:
- Shefi i departamentit, i cili është edhe zhvilluesi kryesor.
- QA ndihmon në testimin e ndryshimeve, kërkon mënyra të reja për të krijuar kushte të paqëndrueshme komunikimi dhe raporton problemet nga vija e parë.
- Analisti kërkon vazhdimisht korrelacione të ndryshme në të dhënat teknike, përmirëson analizën e reagimeve të përdoruesve dhe kontrollon rezultatet e eksperimenteve.
- Menaxheri i produktit ndihmon me drejtimin e përgjithshëm dhe shpërndarjen e burimeve për eksperimente.
- Një zhvillues i dytë shpesh ndihmon me programimin dhe detyrat e lidhura me to.
Për të filluar, ne vendosëm një metrikë relativisht të besueshme që gjurmonte ndryshimet në vlerësimet e cilësisë së komunikimit (mesatarisht në ditë, javë, muaj). Në atë kohë, këto ishin nota nga mësuesit, më vonë atyre iu shtuan notat nga studentët. Pastaj ata filluan të ndërtojnë hipoteza për atë që po funksiononte gabim, ta korrigjonin atë dhe të shikonin ndryshimet në dinamikë. Ne shkuam për fruta me varje të ulët: për shembull, ne zëvendësuam kodekun vp8 me vp9, performanca u përmirësua. Ne u përpoqëm të luanim me cilësimet e Janus dhe të kryenim eksperimente të tjera - në shumicën e rasteve ato nuk çuan në asgjë.
Në fazën e dytë, u shfaq një hipotezë: WebRTC është një zgjidhje peer-to-peer, dhe ne përdorim një server në mes. Ndoshta problemi qëndron këtu? Filluam të gërmojmë dhe gjetëm përmirësimin më të rëndësishëm deri tani.
Në atë moment, një server nga pishina u zgjodh duke përdorur një algoritëm mjaft budalla: secili kishte "peshën" e tij, në varësi të kanalit dhe fuqisë, dhe ne u përpoqëm ta dërgonim përdoruesin tek ai me "peshën" më të madhe, pa duke i kushtuar vëmendje vendndodhjes gjeografike të përdoruesit. Si rezultat, një mësues nga Shën Petersburgu mund të komunikonte me një student nga Siberia përmes Moskës, dhe jo përmes serverit tonë Janus në Shën Petersburg.
Algoritmi është ribërë: tani, kur një përdorues hap platformën tonë, ne mbledhim ping prej tij në të gjithë serverët që përdorin Ajax. Kur vendosim një lidhje, zgjedhim një palë ping (mësues-server dhe student-server) me sasinë më të vogël. Më pak ping do të thotë më pak distancë rrjeti nga serveri; distanca më e shkurtër do të thotë probabilitet më i ulët i humbjes së paketave; Humbja e paketave është faktori më i madh negativ në komunikimin me video. Pjesa e negativitetit ra përgjysmë në tre muaj (për të qenë të drejtë, eksperimente të tjera u kryen në këtë kohë, por ky pothuajse me siguri pati ndikimin më të madh).
Kohët e fundit kemi zbuluar një gjë tjetër jo të dukshme, por në dukje të rëndësishme: në vend të një serveri të fuqishëm Janus në një kanal të trashë, është më mirë të kemi dy më të thjeshtë me gjerësi bande më të hollë. Kjo u bë e qartë pasi blemë makineri të fuqishme me shpresën për të grumbulluar sa më shumë dhoma (sesione komunikimi) në to në të njëjtën kohë. Serverët kanë një kufi të gjerësisë së brezit, të cilin ne mund ta përkthejmë me saktësi në numrin e dhomave - ne e dimë se sa mund të hapen, për shembull, me 300 Mbit/s. Sapo ka shumë dhoma të hapura në një server, ne e ndalojmë zgjedhjen e tij për aktivitete të reja derisa ngarkesa të ulet. Ideja ishte që, pasi të kishim blerë një makinë të fuqishme, ta ngarkonim kanalin në maksimum, në mënyrë që në fund të kufizohej nga procesori dhe memoria, dhe jo nga gjerësia e brezit. Por doli që pas një numri të caktuar dhomash të hapura (420), përkundër faktit se ngarkesa në procesor, memorie dhe disk është ende shumë larg kufijve, negativiteti fillon të arrijë në mbështetje teknike. Me sa duket, diçka po përkeqësohet brenda Janusit, ndoshta edhe atje ka disa kufizime. Filluam të eksperimentonim, ulëm kufirin e gjerësisë së brezit nga 300 në 200 Mbit/s dhe problemet u larguan. Tani kemi blerë tre serverë të rinj njëherësh me limite dhe karakteristika të ulëta, mendojmë se kjo do të çojë në një përmirësim të qëndrueshëm të cilësisë së komunikimit. Sigurisht, ne nuk u përpoqëm të kuptonim se çfarë po ndodhte atje; paterica jonë është gjithçka. Në mbrojtjen tonë, le të themi se në atë moment ishte e nevojshme që problemi i ngutshëm të zgjidhej sa më shpejt që të ishte e mundur dhe jo ta bënim bukur; përveç kësaj, Janus për ne është një kuti e zezë e shkruar në C, është shumë e shtrenjtë të ngacmosh me të.
Epo, në proces ne:
- përditësoi të gjitha varësitë që mund të përditësoheshin, si në server ashtu edhe në klient (këto ishin gjithashtu eksperimente, ne monitoruam rezultatet);
- rregulloi të gjitha gabimet e identifikuara në lidhje me raste specifike, për shembull, kur lidhja ra dhe nuk u rivendos automatikisht;
- Kemi zhvilluar shumë takime me kompani që punojnë në fushën e komunikimit me video dhe janë njohur me problemet tona: transmetim lojërash, organizim webinarësh; ne provuam gjithçka që na dukej e dobishme;
- U krye një rishikim teknik i cilësisë së harduerit dhe komunikimit të mësuesve, nga të cilët vinin më shumë ankesa.
Eksperimentet dhe ndryshimet e mëvonshme bënë të mundur uljen e pakënaqësisë me komunikimin mes mësuesve nga 7,1% në janar 2018 në 2,5% në janar 2019.
Ç'pritet më tej
Stabilizimi i platformës sonë Vimbox është një nga projektet kryesore të kompanisë për vitin 2019. Ne kemi shumë shpresa se do të jemi në gjendje të ruajmë vrullin dhe të mos shohim më komunikim me video në ankesat kryesore. Ne e kuptojmë se një pjesë e konsiderueshme e këtyre ankesave kanë të bëjnë me vonesat në kompjuterët dhe internetin e përdoruesve, por ne duhet të përcaktojmë këtë pjesë dhe të zgjidhim pjesën tjetër. Çdo gjë tjetër është një problem teknik, duket se ne duhet të jemi në gjendje ta përballojmë atë.
Vështirësia kryesore është se ne nuk e dimë se deri në çfarë niveli është realisht e mundur të përmirësohet cilësia. Zbulimi i këtij tavani është detyra kryesore. Prandaj, janë planifikuar dy eksperimente:
- Krahasoni videon përmes Janus me p2p të rregullt në kushte luftarake. Ky eksperiment tashmë është kryer, nuk u gjet asnjë ndryshim statistikisht domethënës midis zgjidhjes sonë dhe p2p;
- Le të ofrojmë shërbime (të shtrenjta) nga kompani që fitojnë para ekskluzivisht në zgjidhjet e komunikimit me video dhe të krahasojmë sasinë e negativitetit prej tyre me atë ekzistues.
Këto dy eksperimente do të na lejojnë të identifikojmë një qëllim të arritshëm dhe të përqendrohemi në të.
Përveç kësaj, ka një numër detyrash që mund të zgjidhen në mënyrë rutinore:
- Ne krijojmë një metrikë teknike të cilësisë së komunikimit në vend të rishikimeve subjektive;
- Ne bëjmë regjistrat më të detajuar të sesioneve në mënyrë që të analizojmë më saktë dështimet që ndodhin, të kuptojmë se kur dhe ku kanë ndodhur saktësisht ato dhe cilat ngjarje në dukje të palidhura kanë ndodhur në atë moment;
- Ne përgatisim një test automatik të cilësisë së lidhjes përpara mësimit dhe gjithashtu i japim klientit mundësinë të testojë manualisht lidhjen në mënyrë që të zvogëlojë sasinë e negativitetit të shkaktuar nga hardueri dhe kanali i tij;
- ne do të zhvillojmë dhe kryejmë më shumë teste të ngarkesës së komunikimit me video në kushte të këqija, me humbje të ndryshueshme të paketave, etj.;
- ne ndryshojmë sjelljen e serverëve në rast të problemeve për të rritur tolerancën e gabimeve;
- Ne do ta paralajmërojmë përdoruesin nëse ka diçka që nuk shkon me lidhjen e tij fare, siç bën Skype, në mënyrë që ai të kuptojë se problemi është në anën e tij.
Që nga prilli, drejtimi i komunikimit me video është bërë një projekt i plotë i veçantë brenda Skyeng, që merret me produktin e tij, jo vetëm një pjesë të Vimbox. Kjo do të thotë që ne po fillojmë të kërkojmë njerëz . Epo, si gjithmonë .
Dhe, sigurisht, ne vazhdojmë të komunikojmë në mënyrë aktive me njerëzit dhe kompanitë që punojnë me komunikime video. Nëse dëshironi të shkëmbeni përvojë me ne, do të jemi të lumtur! Komentoni, kontaktoni - ne do t'i përgjigjemi të gjithëve.
Burimi: www.habr.com