Ang komunikasyong video ay ang pangunahing paraan ng komunikasyon sa pagitan ng guro at mag-aaral sa Vimbox platform. Ibinigay namin ang Skype nang matagal na ang nakalipas, sinubukan ang ilang mga solusyon sa third-party at kalaunan ay nanirahan sa kumbinasyon ng WebRTC - Janus-gateway. Sa loob ng ilang panahon ay masaya kami sa lahat, ngunit patuloy pa rin ang ilang mga negatibong aspeto. Bilang resulta, nilikha ang isang hiwalay na direksyon ng video.
Tinanong ko si Kirill Rogovoy, ang pinuno ng bagong direksyon, na pag-usapan ang tungkol sa ebolusyon ng komunikasyong video sa Skyeng, ang mga problemang natuklasan, mga solusyon at saklay na huli naming ginamit. Umaasa kami na ang artikulo ay magiging kapaki-pakinabang para sa mga kumpanyang gumagawa din ng video sa kanilang sarili sa pamamagitan ng isang web application.
Ang isang maliit na kasaysayan
Noong tag-araw ng 2017, ang pinuno ng Skyeng development, si Sergey Safonov, ay nagsalita sa Backend Conf na may isang kuwento tungkol sa kung paano namin "tinalikuran ang Skype at ipinatupad ang WebRTC." Maaaring panoorin ng mga interesado ang pag-record ng talumpati sa (~45 min), at dito ko ibabalangkas sa madaling sabi ang kakanyahan nito.
Para sa Skyeng School, ang komunikasyong video ay palaging isang priyoridad na paraan ng komunikasyon ng guro-mag-aaral. Sa una, ang Skype ay ginamit, ngunit ito ay tiyak na hindi kasiya-siya para sa isang bilang ng mga kadahilanan, lalo na dahil sa kakulangan ng mga log at ang imposibilidad ng pagsasama nang direkta sa web application. Samakatuwid, nagsagawa kami ng lahat ng uri ng mga eksperimento.
Sa totoo lang, ang aming mga kinakailangan para sa komunikasyong video ay humigit-kumulang sa mga sumusunod:
β katatagan;
β mababang presyo bawat aralin;
- pag-record ng mga aralin;
β pagsubaybay kung sino ang nagsasalita (mahalaga para sa amin na ang mga mag-aaral ay nagsasalita ng higit kaysa sa guro sa panahon ng mga aralin);
- linear scaling;
- kakayahang gamitin ang parehong UDP at TCP.
Ang unang sumubok ay ang pagpapatupad ng Tokbox noong 2013. Ang lahat ay mabuti, ngunit ito ay naging napakamahal - 113 rubles bawat aralin - at kinain ang kita.
Pagkatapos noong 2015, isinama ang Voximplant. Narito ang function na kailangan namin upang subaybayan kung sino ang nagsalita kung magkano, at sa parehong oras ang solusyon ay mas mura: kung naitala lamang ang audio, nagkakahalaga ito ng 20 rubles bawat aralin. Gayunpaman, ito ay gumana lamang sa pamamagitan ng UDP at hindi maaaring lumipat sa TCP. Gayunpaman, humigit-kumulang 40% ng mga mag-aaral ang natapos na gumamit nito.
Pagkalipas ng isang taon, nagsimula kaming magkaroon ng mga kliyenteng pangkorporasyon na may sarili nilang mga partikular na pangangailangan. Halimbawa, ang lahat ay dapat gumana sa pamamagitan ng isang browser, ang kumpanya ay nagbubukas lamang ng http at https; ibig sabihin, walang Skype o UDP. Corporate clients = pera, kaya bumalik sila sa Tokbox, ngunit ang problema sa presyo ay hindi nawala.
Solusyon - WebRTC at Janus
Nagpasya na gamitin . Ito ay responsable para sa pagtatatag ng isang koneksyon, pag-encode at pag-decode ng mga stream, pag-synchronize ng mga track at kontrol sa kalidad sa paghawak ng mga glitches sa network. Para sa aming bahagi, dapat naming tiyakin ang pagbabasa ng mga stream mula sa camera at mikropono, pagguhit ng video, pamamahala sa koneksyon, pagtatatag ng isang koneksyon sa WebRTC at pagpapadala ng mga stream dito, pati na rin ang pagpapadala ng mga mensahe ng senyas sa pagitan ng mga kliyente upang magtatag ng isang koneksyon (Ang WebRTC mismo ay naglalarawan lamang ng format ng data, ngunit hindi ang mekanismo ng paglilipat nito). Kung ang mga kliyente ay nasa likod ng NAT, kinokonekta ng WebRTC ang mga STUN server; kung hindi ito makakatulong, TURN server.
Ang isang regular na koneksyon sa p2p ay hindi sapat para sa amin, dahil gusto naming magtala ng mga aralin para sa karagdagang pagsusuri kung sakaling may mga reklamo. Samakatuwid nagpapadala kami ng mga stream ng WebRTC sa pamamagitan ng isang relay . Bilang resulta, hindi alam ng mga kliyente ang mga address ng isa't isa, nakikita lamang ang address ng server ng Janus; ito rin ay gumaganap ng mga function ng isang signal server. Si Janus ay may marami sa mga tampok na kailangan namin: awtomatikong lilipat sa TCP kung ang kliyente ay may naka-block na UDP; maaaring mag-record ng parehong UDP at TCP stream; nasusukat; Mayroong kahit isang built-in na plugin para sa echo test. Kung kinakailangan, awtomatikong konektado ang mga STUN at TURN server mula sa Twilio.
Noong tag-araw ng 2017, mayroon kaming dalawang Janus server na tumatakbo, kasama ang isang karagdagang server para sa pagproseso ng mga naitala na raw na audio at mga video file, upang hindi sakupin ang mga processor ng mga pangunahing. Kapag kumokonekta, pinili ang mga server ng Janus sa isang odd-even na batayan (numero ng koneksyon). Sa oras na iyon, sapat na ito, ayon sa aming mga damdamin, nagbigay ito ng humigit-kumulang apat na beses na margin ng kaligtasan, ang porsyento ng pagpapatupad ay halos 80. Kasabay nito, ang presyo ay nabawasan sa ~2 rubles bawat aralin, kasama ang pag-unlad at suporta.
Pagbabalik sa paksa ng komunikasyong video
Patuloy naming sinusubaybayan ang feedback mula sa mga mag-aaral at guro upang matukoy at maitama ang mga problema sa isang napapanahong paraan. Sa tag-araw ng 2018, ang kalidad ng tawag ay nasa unang lugar sa mga reklamo. Sa isang banda, nangangahulugan ito na matagumpay nating nalampasan ang iba pang mga pagkukulang. Sa kabilang banda, kailangang gumawa ng isang bagay nang madalian: kung ang aralin ay nagambala, nanganganib na mawala ang halaga nito, kung minsan kasama ang halaga ng pagbili ng susunod na pakete, at kung ang panimulang aralin ay nagambala, nanganganib tayong mawalan ng potensyal na kliyente. sama-sama.
Nung time na yun, MVP mode pa yung video communication namin. Sa madaling salita, inilunsad nila ito, nagtrabaho ito, na-scale nila ito nang isang beses, naunawaan nila kung paano ito gagawin - mabuti, mahusay. Kung ito ay gumagana, huwag ayusin ito. Walang sinuman ang sadyang tumugon sa isyu ng kalidad ng komunikasyon. Noong Agosto, naging malinaw na hindi ito matutuloy, at naglunsad kami ng hiwalay na direksyon para malaman kung ano ang mali sa WebRTC at Janus.
Sa input, nakatanggap ang direksyong ito: isang MVP solution, walang sukatan, walang layunin, walang proseso para sa pagpapabuti, habang 7% ng mga guro ang nagreklamo tungkol sa kalidad ng komunikasyon (wala ring data sa mga mag-aaral).
Isang bagong direksyon ang isinasagawa
Ang utos ay mukhang ganito:
- Ang pinuno ng departamento, na siya ring pangunahing developer.
- Tumutulong ang QA sa pagsubok ng mga pagbabago, naghahanap ng mga bagong paraan upang lumikha ng hindi matatag na kundisyon ng komunikasyon, at nag-uulat ng mga problema mula sa front line.
- Ang analyst ay patuloy na naghahanap ng iba't ibang mga ugnayan sa teknikal na data, pinapabuti ang pagsusuri ng feedback ng user, at sinusuri ang mga resulta ng mga eksperimento.
- Tumutulong ang tagapamahala ng produkto sa pangkalahatang direksyon at paglalaan ng mga mapagkukunan para sa mga eksperimento.
- Ang pangalawang developer ay madalas na tumutulong sa programming at mga kaugnay na gawain.
Upang magsimula, nag-set up kami ng medyo maaasahang sukatan na sumusubaybay sa mga pagbabago sa mga pagtatasa ng kalidad ng komunikasyon (average sa mga araw, linggo, buwan). Noong panahong iyon, ang mga ito ay mga marka mula sa mga guro; ang mga susunod na grado mula sa mga mag-aaral ay idinagdag sa kanila. Pagkatapos ay nagsimula silang bumuo ng mga hypotheses tungkol sa kung ano ang gumaganang mali, itama ito, at tingnan ang mga pagbabago sa dynamics. Pinuntahan namin ang low-hanging fruit: halimbawa, pinalitan namin ang vp8 codec ng vp9, bumuti ang performance. Sinubukan naming maglaro sa mga setting ng Janus at magsagawa ng iba pang mga eksperimento - sa karamihan ng mga kaso ay hindi sila humantong sa anumang bagay.
Sa ikalawang yugto, lumitaw ang isang hypothesis: Ang WebRTC ay isang peer-to-peer na solusyon, at gumagamit kami ng server sa gitna. Marahil ang problema ay namamalagi dito? Nagsimula kaming maghukay at natagpuan ang pinakamahalagang pagpapabuti sa ngayon.
Sa sandaling iyon, napili ang isang server mula sa pool gamit ang isang medyo hangal na algorithm: ang bawat isa ay may sariling "timbang", depende sa channel at kapangyarihan, at sinubukan naming ipadala ang user sa isa na may pinakamalaking "timbang", nang walang binibigyang pansin kung saan matatagpuan ang gumagamit sa heograpiya. Bilang resulta, ang isang guro mula sa St. Petersburg ay maaaring makipag-ugnayan sa isang mag-aaral mula sa Siberia sa pamamagitan ng Moscow, at hindi sa pamamagitan ng aming Janus server sa St. Petersburg.
Ang algorithm ay muling ginawa: ngayon, kapag binuksan ng isang user ang aming platform, kinokolekta namin ang mga ping mula sa kanya sa lahat ng mga server gamit ang Ajax. Kapag nagtatatag ng isang koneksyon, pumili kami ng isang pares ng mga ping (teacher-server at student-server) na may pinakamaliit na halaga. Ang mas kaunting ping ay nangangahulugan ng mas kaunting distansya ng network sa server; ang mas maikling distansya ay nangangahulugan ng mas mababang posibilidad ng pagkawala ng mga packet; Ang pagkawala ng packet ay ang pinakamalaking negatibong salik sa komunikasyong video. Ang bahagi ng negatibiti ay bumaba ng kalahati sa loob ng tatlong buwan (para maging patas, ang iba pang mga eksperimento ay isinagawa sa oras na ito, ngunit ang isang ito ay halos tiyak na may pinakamalaking epekto).
Natuklasan namin kamakailan ang isa pang hindi halata, ngunit tila mahalagang bagay: sa halip na isang malakas na server ng Janus sa isang makapal na channel, mas mabuting magkaroon ng dalawang mas simple na may mas manipis na bandwidth. Naging malinaw ito pagkatapos naming bumili ng makapangyarihang mga makina sa pag-asang makapag-cramming ng maraming kuwarto (mga sesyon ng komunikasyon) sa mga ito nang sabay-sabay. Ang mga server ay may limitasyon sa bandwidth, na maaari naming tumpak na isalin sa bilang ng mga silid - alam namin kung ilan ang maaaring mabuksan, halimbawa, sa 300 Mbit/s. Sa sandaling masyadong maraming kuwartong nakabukas sa isang server, hihinto kami sa pagpili nito para sa mga bagong aktibidad hanggang sa bumaba ang load. Ang ideya ay, sa pagbili ng isang malakas na makina, i-load namin ang channel dito sa maximum, upang sa huli ay limitado ito ng processor at memorya, at hindi ng bandwidth. Ngunit ito ay lumabas na pagkatapos ng isang tiyak na bilang ng mga bukas na silid (420), sa kabila ng katotohanan na ang pag-load sa processor, memorya at disk ay napakalayo pa rin sa mga limitasyon, ang negatibiti ay nagsisimulang dumating sa teknikal na suporta. Tila, may lumalala sa loob ni Janus, marahil ay may ilang mga paghihigpit din doon. Nagsimula kaming mag-eksperimento, ibinaba ang limitasyon ng bandwidth mula 300 hanggang 200 Mbit/s, at nawala ang mga problema. Ngayon bumili kami ng tatlong bagong server nang sabay-sabay na may mababang limitasyon at katangian, sa palagay namin ay hahantong ito sa isang matatag na pagpapabuti sa kalidad ng komunikasyon. Siyempre, hindi namin sinubukang alamin kung ano ang nangyayari doon; ang aming mga saklay ang lahat. Sa aming pagtatanggol, sabihin natin na sa sandaling iyon ay kinakailangan upang malutas ang pagpindot sa problema sa lalong madaling panahon, at hindi gawin ito nang maganda; besides, para sa amin si Janus ay isang black box na nakasulat sa C, napakamahal ng pagkukulitan nito.
Well, sa proseso namin:
- na-update ang lahat ng mga dependency na maaaring ma-update, kapwa sa server at sa kliyente (mga eksperimento din ito, sinusubaybayan namin ang mga resulta);
- naayos ang lahat ng natukoy na mga bug na nauugnay sa mga partikular na kaso, halimbawa, kapag bumaba ang koneksyon at hindi awtomatikong naibalik;
- Nagdaos kami ng maraming pagpupulong sa mga kumpanyang nagtatrabaho sa larangan ng mga komunikasyong video at pamilyar sa aming mga problema: streaming na mga laro, pag-aayos ng mga webinar; sinubukan namin ang lahat na tila kapaki-pakinabang sa amin;
- Nagsagawa ng teknikal na pagsusuri sa kalidad ng hardware at komunikasyon ng mga guro, kung saan nagmula ang pinakamaraming reklamo.
Ang mga eksperimento at mga kasunod na pagbabago ay naging posible upang mabawasan ang kawalang-kasiyahan sa komunikasyon sa mga guro mula 7,1% noong Enero 2018 hanggang 2,5% noong Enero 2019.
kung ano ang susunod
Ang pagpapatatag ng aming Vimbox platform ay isa sa mga pangunahing proyekto ng kumpanya para sa 2019. Malaki ang aming pag-asa na mapanatili namin ang momentum at hindi na namin makikita ang video communication sa mga nangungunang reklamo. Nauunawaan namin na ang isang mahalagang bahagi ng mga reklamong ito ay nauugnay sa mga pagkahuli sa mga computer at Internet ng mga user, ngunit dapat naming tukuyin ang bahaging ito at lutasin ang iba. Lahat ng iba ay isang teknikal na problema, tila dapat nating makayanan ito.
Ang pangunahing kahirapan ay hindi natin alam kung hanggang saang antas ang aktwal na posibleng pagbutihin ang kalidad. Ang paghahanap ng kisame na ito ay ang pangunahing gawain. Samakatuwid, dalawang eksperimento ang binalak:
- ihambing ang video sa pamamagitan ng Janus na may regular na p2p sa mga kondisyon ng labanan. Naisagawa na ang eksperimentong ito, walang nakitang makabuluhang pagkakaiba sa istatistika sa pagitan ng aming solusyon at p2p;
- Mag-supply tayo ng (mahal) na mga serbisyo mula sa mga kumpanyang eksklusibong kumikita ng pera sa mga solusyon sa komunikasyong video, at ihambing ang halaga ng negatibiti mula sa mga ito sa umiiral na.
Ang dalawang eksperimentong ito ay magbibigay-daan sa amin na matukoy ang isang maaabot na layunin at tumuon dito.
Bilang karagdagan, mayroong isang bilang ng mga gawain na maaaring malutas nang regular:
- Lumilikha kami ng teknikal na sukatan ng kalidad ng komunikasyon sa halip na mga pansariling pagsusuri;
- Gumagawa kami ng mas detalyadong mga log ng session upang mas tumpak na masuri ang mga pagkabigo na nangyari, maunawaan kung kailan at saan eksaktong nangyari ang mga ito, at kung ano ang mga tila hindi nauugnay na mga kaganapan na naganap sa sandaling iyon;
- Naghahanda kami ng isang awtomatikong pagsubok sa kalidad ng koneksyon bago ang aralin, at binibigyan din ang kliyente ng pagkakataon na manu-manong subukan ang koneksyon upang mabawasan ang dami ng negatibong dulot ng kanyang hardware at channel;
- bubuo at magsasagawa kami ng higit pang mga pagsubok sa pagkarga ng komunikasyon sa video sa mahihirap na kondisyon, na may variable na pagkawala ng packet, atbp.;
- binabago namin ang pag-uugali ng mga server sa kaso ng mga problema upang madagdagan ang pagpapahintulot sa kasalanan;
- Babalaan namin ang gumagamit kung may mali sa kanyang koneksyon, tulad ng ginagawa ng Skype, upang maunawaan niya na ang problema ay nasa kanyang panig.
Mula noong Abril, ang direksyon ng komunikasyon sa video ay naging isang ganap na hiwalay na proyekto sa loob ng Skyeng, na nakikitungo sa sarili nitong produkto, hindi lamang isang bahagi ng Vimbox. Nangangahulugan ito na nagsisimula kaming maghanap ng mga tao . Well, gaya ng dati .
At, siyempre, patuloy kaming aktibong nakikipag-ugnayan sa mga tao at kumpanyang nagtatrabaho sa mga komunikasyong video. Kung gusto mong makipagpalitan ng karanasan sa amin, matutuwa kami! Magkomento, makipag-ugnayan - sasagutin namin ang lahat.
Pinagmulan: www.habr.com