Bideo komunikazioa irakasle eta ikasleen arteko komunikazio bide nagusia da Vimbox plataforman. Aspaldi utzi genuen Skyperi utzi, hirugarrenen hainbat irtenbide probatu eta azkenean WebRTC - Janus-gateway konbinazioa ezarri genuen. Denbora batez denarekin pozik egon ginen, baina hala ere alderdi negatibo batzuk azaleratzen jarraitu zuten. Ondorioz, bideo-norabide bereizia sortu zen.
Kirill Rogovoyi, zuzendaritza berriko buruari, Skyeng-en bideo-komunikazioaren bilakaeraz, aurkitutako arazoez, konponbideez eta azken finean erabili ditugun makuluez hitz egiteko eskatu nion. Artikulua web aplikazio baten bidez bideoak euren kabuz ere sortzen dituzten enpresentzat erabilgarria izatea espero dugu.
Historia apur bat
2017ko udan, Skyeng garapeneko buruak, Sergey Safonov-ek, Backend Conf-en hitz egin zuen "Skype utzi eta WebRTC inplementatu genuen" buruzko istorio batekin. Interesa dutenek hitzaldiaren grabaketa helbidean ikus dezakete (~45 min), eta hemen labur-labur azalduko dut haren funtsa.
Skyeng Eskolarentzat, bideo-komunikazioa beti izan da irakasle-ikasle komunikaziorako lehentasunezko modua. Hasieran, Skype erabiltzen zen, baina kategorikoki ez zen asegarria hainbat arrazoirengatik, batez ere erregistro faltagatik eta web aplikazioan zuzenean integratzeko ezintasunagatik. Horregatik, era guztietako esperimentuak egin genituen.
Egia esan, bideo-komunikaziorako gure eskakizunak gutxi gorabehera honako hauek ziren:
β egonkortasuna;
β prezio baxua ikasgai bakoitzeko;
β ikasgaiak grabatzea;
β zenbat hitz egiten duen kontrolatzea (garrantzitsua da guretzat ikasleek irakasleak baino gehiago hitz egitea ikasgaietan);
β eskalatze lineala;
- UDP eta TCP erabiltzeko gaitasuna.
Saiatu zen lehena 2013an Tokbox inplementatzea izan zen. Dena ona zen, baina oso garestia izan zen - 113 errublo ikasgai bakoitzeko - eta irabaziak jan zituen.
Ondoren, 2015ean, Voximplant integratu zen. Hona hemen nork zenbat hitz egiten zuen jarraitzeko behar genuen funtzioa, eta, aldi berean, irtenbidea askoz merkeagoa zen: audioa bakarrik grabatzen bazen, 20 errublo balio zuen ikasgai bakoitzeko. Hala ere, UDP bidez bakarrik funtzionatu zuen eta ezin zen TCPra aldatu. Hala ere, ikasleen % 40 inguruk erabili zuten azkenean.
Urtebete geroago, bezero korporatiboak izaten hasi ginen, beren eskakizun zehatzak zituztenak. Adibidez, dena nabigatzaile baten bidez funtzionatu beharko luke;konpainiak http eta https soilik irekitzen ditu; hau da, Skype edo UDPrik ez. Bezero korporatiboak = dirua, beraz, Tokboxera itzuli ziren, baina prezioaren arazoa ez zen desagertu.
Irtenbidea - WebRTC eta Janus
Erabiltzea erabaki zuen . Konexio bat ezartzeaz, korronteak kodetzeaz eta deskodetzeaz, ibilbideak sinkronizatzeaz eta kalitate-kontrolaz arduratzen da sareko akatsak kudeatzeaz. Gure aldetik, kameratik eta mikrofonotik korronteak irakurtzea, bideoa marraztea, konexioa kudeatzea, WebRTC konexioa ezarri eta hari korronteak transmititzea ziurtatu behar dugu, baita bezeroen arteko seinaleztapen-mezuak transmititzea ere konexioa ezartzeko (WebRTC-k berak bakarrik deskribatzen du datu-formatua, baina ez bere mekanismo-transferentziak). Bezeroak NAT atzean badaude, WebRTC-k STUN zerbitzariak konektatzen ditu; honek laguntzen ez badu, TURN zerbitzariak.
Ohiko p2p konexioa ez da nahikoa guretzat, ikasgaiak grabatu nahi ditugulako kexak izanez gero azterketa gehiago egiteko. Hori dela eta, WebRTC korronteak bidaltzen ditugu errele baten bidez . Ondorioz, bezeroek ez dituzte elkarren helbideak ezagutzen, Janus zerbitzariaren helbidea soilik ikusten dute; seinale-zerbitzari baten funtzioak ere betetzen ditu. Janus-ek behar ditugun ezaugarri asko ditu: automatikoki TCPra aldatzen da bezeroak UDP blokeatuta badu; UDP zein TCP korronteak graba ditzake; eskalagarria; Oihartzun probak egiteko plugin integratua ere badago. Beharrezkoa bada, Twilioko STUN eta TURN zerbitzariak automatikoki konektatzen dira.
2017ko udan, bi Janus zerbitzari izan genituen martxan, gehi zerbitzari gehigarri bat grabatutako audio eta bideo fitxategi gordinak prozesatzeko, nagusien prozesadoreak ez okupatzeko. Konektatzeko orduan, Janus zerbitzariak bakoiti-bikoitietan hautatu ziren (konexio-zenbakia). Garai hartan, nahikoa zen, gure sentimenduen arabera, gutxi gorabehera, segurtasun-marjina laukoitza ematen zuen, ezarpen-ehunekoa 80 ingurukoa zen. Aldi berean, prezioa ~ 2 errublora murriztu zen ikasgai bakoitzeko, gehi garapena eta laguntza.
Bideo komunikazioaren gaira itzuliz
Ikasle eta irakasleen iritzia etengabe kontrolatzen dugu, arazoak garaiz identifikatu eta zuzentzeko. 2018ko udan, deien kalitatea irmo zegoen kexen artean lehen postuan. Alde batetik, horrek esan nahi zuen arrakastaz gainditu genituela beste gabezi batzuk. Bestalde, premiazko zerbait egin behar zen: ikasgaia eten egiten bada, balioa galtzeko arriskua dugu, batzuetan hurrengo paketea erosteko kostuarekin batera, eta hastapeneko ikasgaia eteten bada, balizko bezero bat galtzeko arriskua dugu. guztiz.
Garai hartan, gure bideo-komunikazioa MVP moduan zegoen oraindik. Besterik gabe, martxan jarri zuten, funtzionatu zuen, behin eskalatu zuten, nola egin ulertu zuten - tira, bikaina. Funtzionatzen badu, ez konpondu. Inork ez zuen nahita jorratu komunikazioaren kalitatearen gaia. Abuztuan, argi geratu zen honek ezin zuela jarraitu, eta WebRTC eta Janusekin zer gertatzen zen jakiteko norabide bereizia jarri genuen martxan.
Sarreran, norabide honek jaso zuen: MVP irtenbide bat, ez metrikarik, ez helbururik, ez hobetzeko prozesurik, eta irakasleen %7 komunikazioaren kalitateaz kexatzen da (ikasleei buruzko daturik ere ez zegoen).
Norabide berri bat abian da
Komandoak honelako itxura du:
- Saileko burua, garatzaile nagusia ere bada.
- QA-k aldaketak probatzen laguntzen du, komunikazio-baldintza ezegonkorrak sortzeko modu berriak bilatzen eta arazoen berri ematen du lehen lerrotik.
- Analistak datu teknikoetan hainbat korrelazio bilatzen ditu etengabe, erabiltzaileen iritzien azterketa hobetzen du eta esperimentuen emaitzak egiaztatzen ditu.
- Produktu-kudeatzaileak esperimentuetarako baliabideen norabide orokorrarekin eta esleipenarekin laguntzen du.
- Bigarren garatzaile batek askotan laguntzen du programazioan eta erlazionatutako zereginetan.
Hasteko, komunikazioaren kalitatearen ebaluazioen aldaketen jarraipena egiten duen metrika nahiko fidagarria ezarri dugu (egunetan, asteetan, hilabeteetan batez beste). Garai hartan, irakasleen kalifikazioak ziren; geroago ikasleen kalifikazioak gehitu zitzaizkien. Orduan, gaizki funtzionatzen zuenari buruzko hipotesiak egiten hasi ziren, zuzentzen eta dinamikaren aldaketak aztertzen. Fruta baxuaren bila joan ginen: adibidez, vp8 codec-a vp9-rekin ordezkatu genuen, errendimendua hobetu zen. Janus ezarpenekin jolasten eta beste esperimentu batzuk egiten saiatu ginen; kasu gehienetan, ez zuten ezer ekarri.
Bigarren fasean, hipotesi bat sortu zen: WebRTC peer-to-peer irtenbide bat da, eta zerbitzari bat erabiltzen dugu erdian. Arazoa hemen dago agian? Zulatzen hasi ginen eta orain arteko hobekuntzarik nabarmenena aurkitu genuen.
Momentu horretan, igerilekuko zerbitzari bat aukeratu zen algoritmo ergel samarra erabiliz: bakoitzak bere "pisua" zuen, kanalaren eta potentziaren arabera, eta erabiltzailea "pisu handiena" zuenera bidaltzen saiatu ginen, gabe. erabiltzailea geografikoki non zegoen erreparatuz . Ondorioz, San Petersburgoko irakasle bat Siberiako ikasle batekin komunika zitekeen Moskutik barrena, eta ez San Petersburgoko gure Janus zerbitzariaren bidez.
Algoritmoa berritu da: orain, erabiltzaile batek gure plataforma irekitzen duenean, harengandik ping-ak biltzen ditugu Ajax erabiliz zerbitzari guztietara. Konexio bat ezartzerakoan, ping pare bat hautatzen dugu (irakasle-zerbitzaria eta ikasle-zerbitzaria) kopuru txikienarekin. Ping gutxiago zerbitzariarekiko sareko distantzia txikiagoa da; distantzia laburragoak paketeak galtzeko probabilitate txikiagoa esan nahi du; Pakete-galera da bideo-komunikazioko faktore negatiborik handiena. Ezezkotasunaren zatia erdira jaitsi zen hiru hilabetetan (bidezkoa izateko, garai honetan beste esperimentu batzuk egin ziren, baina honek izan zuen eragin handiena).
Duela gutxi agerikoa ez den, baina itxuraz garrantzitsua den beste gauza bat aurkitu dugu: kanal lodi batean Janus zerbitzari indartsu baten ordez, hobe da banda zabalera meheagoa duten bi sinpleago izatea. Hori argi geratu zen makina indartsuak erosi genituenean aldi berean gela (komunikazio-saio) adina pilatzeko asmoz. Zerbitzariek banda zabalera muga bat dute, eta gela kopurura zehaztasunez itzul dezakegu -badakigu zenbat ireki daitezkeen, adibidez, 300 Mbit/s-an. Zerbitzari batean gela gehiegi ireki bezain laster, jarduera berrietarako aukeratzeari uzten diogu karga gutxitu arte. Ideia zen, makina indartsu bat erosita, kanala gehienez kargatuko genuela, azkenean prozesadoreak eta memoriak mugatu zezan, eta ez banda zabalerak. Baina gela ireki kopuru jakin baten ondoren (420), prozesadorearen, memoriaren eta diskoaren karga mugetatik oso urrun dagoen arren, negatiboa laguntza teknikora iristen hasten da. Antza denez, zerbait okerrera doa Janusen barruan, agian hor ere murrizketa batzuk daude. Esperimentatzen hasi ginen, banda-zabalera muga 300-tik 200 Mbit/s-ra jaitsi eta arazoak desagertu egin ziren. Orain hiru zerbitzari berri aldi berean erosi ditugu muga eta ezaugarri baxuekin, horrek komunikazioaren kalitatearen hobekuntza egonkorra ekarriko duela uste dugu. Noski, ez ginen saiatu han zer gertatzen zen asmatzen; gure makuluak dena dira. Gure defentsan, esan momentu horretan premiazko arazoa ahalik eta azkarren konpontzea beharrezkoa zela, eta ez ederki egitea; gainera, guretzat Janus C-z idatzitako kutxa beltz bat da, oso garestia da hura txikitzea.
Beno, prozesuan:
- eguneratu litezkeen mendekotasun guztiak eguneratu ditu, zerbitzarian zein bezeroan (hauek ere esperimentuak ziren, emaitzak kontrolatu genituen);
- kasu zehatzekin erlazionatutako identifikatutako akats guztiak konpondu ditu, adibidez, konexioa erori eta automatikoki leheneratu ez zenean;
- Bideo-komunikazioen arloan lan egiten duten eta gure arazoak ezagutzen dituzten enpresekin bilera ugari egin ditugu: streaming bidezko jokoak, webinar-ak antolatzea; baliagarria iruditu zitzaigun guztia probatu genuen;
- Irakasleen hardwarearen eta komunikazioaren kalitatearen berrikuspen teknikoa egin du, eta haietatik etorri dira kexa gehien.
Esperimentuek eta ondorengo aldaketek irakasleen arteko komunikazioarekiko atsekabea 7,1ko urtarrilean %2018etik 2,5ko urtarrilean %2019era murriztea ahalbidetu zuten.
Zer da hurrengoa
Gure Vimbox plataforma egonkortzea da konpainiaren proiektu nagusietako bat 2019rako. Itxaropen handia dugu bultzadari eusteko gai izango garela eta bideo-komunikazioa jadanik ez ikusteko kexa nagusietan. Ulertzen dugu kexa horien zati garrantzitsu bat erabiltzaileen ordenagailuen eta Interneten atzerapenekin lotuta dagoela, baina zati hori zehaztu eta gainerakoa konpondu behar dugu. Gainontzeko guztia arazo tekniko bat da, badirudi horri aurre egin beharko geniokeela.
Zailtasun nagusia zera da: ez dakigula benetan zein mailaraino den posible kalitatea hobetzea. Sabai hori jakitea da zeregin nagusia. Hori dela eta, bi esperimentu aurreikusi ziren:
- konparatu Janus bidezko bideoa ohiko p2p-ekin borroka-baldintzetan. Esperimentu hau dagoeneko egin da, ez da estatistikoki esanguratsurik aurkitu gure soluzioaren eta p2p-en artean;
- Horni ditzagun bideo-komunikazioko soluzioekin soilik dirua irabazten duten enpresen zerbitzuak (garestiak) eta konparatu ditzagun haien negatibotasun kopurua lehendik dagoenarekin.
Bi esperimentu hauei esker, lor daitekeen helburu bat identifikatu eta horretan zentratuko gara.
Horrez gain, ohikotasunez konpondu daitezkeen hainbat zeregin daude:
- Berrikuspen subjektiboen ordez komunikazioaren kalitatearen metrika tekniko bat sortzen dugu;
- Saio-erregistro zehatzagoak egiten ditugu gertatzen diren hutsegiteak zehatzago aztertzeko, noiz eta non gertatu diren zehatz-mehatz ulertzeko, eta itxuraz zerikusirik ez duten gertakariak une horretan gertatu diren;
- Konexioaren kalitatearen proba automatikoa prestatzen dugu ikasgaiaren aurretik, eta bezeroari konexioa eskuz probatzeko aukera ere ematen diogu, bere hardwareak eta kanalak eragindako negatibotasuna murrizteko;
- bideo-komunikazioen karga-proba gehiago garatu eta egingo ditugu baldintza txarretan, pakete-galera aldakorrarekin, etab.;
- zerbitzarien portaera aldatzen dugu arazoak izanez gero akatsen tolerantzia handitzeko;
- Erabiltzaileari ohartaraziko diogu bere konexioan zerbait gaizki badago, Skypek egiten duen bezala, arazoa bere alde dagoela uler dezan.
Apiriletik, bideo-komunikazioen zuzendaritza Skyeng-en barneko proiektu bereizi oso bat bihurtu da, bere produktua jorratzen duena, ez Vimbox-en zati bat soilik. Horrek esan nahi du jendearen bila hasi garela . Tira, beti bezala .
Eta, noski, bideo-komunikazioekin lan egiten duten pertsonekin eta enpresekin aktiboki komunikatzen jarraitzen dugu. Gurekin esperientzia trukatu nahi baduzu, pozik egongo gara! Iruzkin, jarri harremanetan - guztiei erantzungo diegu.
Iturria: www.habr.com