Videokommunikasie is die belangrikste manier van kommunikasie tussen onderwyser en student op die Vimbox-platform. Ons het lank gelede Skype opgegee, verskeie derdeparty-oplossings probeer en uiteindelik op die WebRTC - Janus-gateway-kombinasie besluit. Vir 'n geruime tyd was ons tevrede met alles, maar steeds het 'n paar negatiewe aspekte na vore gekom. As gevolg hiervan is 'n aparte videorigting geskep.
Ek het Kirill Rogovoy, die hoof van die nuwe rigting, gevra om te praat oor die evolusie van videokommunikasie by Skyeng, die probleme wat ontdek is, oplossings en krukke wat ons uiteindelik gebruik het. Ons hoop dat die artikel nuttig sal wees vir maatskappye wat ook video op hul eie deur 'n webtoepassing skep.
'N bietjie geskiedenis
In die somer van 2017 het die hoof van Skyeng-ontwikkeling, Sergey Safonov, by Backend Conf gepraat met 'n storie oor hoe ons "Skype laat vaar het en WebRTC geïmplementeer het." Belangstellendes kan na die opname van die toespraak kyk by (~45 min), en hier sal ek die essensie daarvan kortliks uiteensit.
Vir Skyeng Skool was videokommunikasie nog altyd 'n prioriteitsmanier van onderwyser-leerling kommunikasie. Aanvanklik is Skype gebruik, maar dit was om 'n aantal redes kategories nie bevredigend nie, hoofsaaklik as gevolg van die gebrek aan logs en die onmoontlikheid om direk in die webtoepassing in te skakel. Daarom het ons allerhande eksperimente uitgevoer.
Eintlik was ons vereistes vir videokommunikasie ongeveer die volgende:
- stabiliteit;
- lae prys per les;
— opneem van lesse;
— dop wie praat hoeveel (dit is vir ons belangrik dat studente meer praat as die onderwyser tydens lesse);
- lineêre skalering;
- vermoë om beide UDP en TCP te gebruik.
Die eerste wat probeer het, was om Tokbox in 2013 te implementeer. Alles was goed, maar dit blyk baie duur te wees - 113 roebels per les - en het die wins opgeëet.
Toe in 2015 is Voximplant geïntegreer. Hier was die funksie wat ons nodig gehad het om op te spoor wie hoeveel gepraat het, en terselfdertyd was die oplossing baie goedkoper: as net klank opgeneem is, het dit 20 roebels per les gekos. Dit het egter net via UDP gewerk en kon nie na TCP oorskakel nie. Ongeveer 40% van studente het dit egter uiteindelik gebruik.
'n Jaar later het ons korporatiewe kliënte begin hê met hul eie spesifieke vereistes. Byvoorbeeld, alles moet deur 'n blaaier werk; die maatskappy maak slegs http en https oop; d.w.s. geen Skype of UDP nie. Korporatiewe kliënte = geld, so hulle het teruggekeer na Tokbox, maar die probleem van prys het nie verdwyn nie.
Oplossing - WebRTC en Janus
Besluit om te gebruik . Dit is verantwoordelik vir die vestiging van 'n verbinding, enkodering en dekodering van strome, sinchronisering van snitte en gehaltebeheer met die hantering van netwerkfoute. Van ons kant moet ons verseker dat ons strome vanaf die kamera en mikrofoon lees, video teken, die verbinding bestuur, 'n WebRTC-verbinding vestig en strome daarheen stuur, asook om seinboodskappe tussen kliënte uit te stuur om 'n verbinding te bewerkstellig (WebRTC self beskryf slegs die dataformaat, maar nie sy meganisme-oordragte nie). As kliënte agter NAT is, verbind WebRTC STUN-bedieners; as dit nie help nie, TURN bedieners.
'n Gereelde p2p-verbinding is nie vir ons genoeg nie, want ons wil lesse opneem vir verdere ontleding in geval van klagtes. Daarom stuur ons WebRTC-strome deur 'n aflos . Gevolglik ken kliënte nie mekaar se adresse nie, aangesien hulle slegs die Janus-bedieneradres sien; dit voer ook die funksies van 'n seinbediener uit. Janus het baie van die kenmerke wat ons nodig het: skakel outomaties oor na TCP as die kliënt UDP geblokkeer het; kan beide UDP- en TCP-strome opneem; skaalbaar; Daar is selfs 'n ingeboude inprop vir eggo-toetse. Indien nodig, word STUN- en TURN-bedieners van Twilio outomaties gekoppel.
In die somer van 2017 het ons twee Janus-bedieners aan die gang gehad, plus 'n bykomende bediener vir die verwerking van aangetekende rou oudio- en videolêers, om nie die verwerkers van die belangrikstes te beset nie. By koppeling is Janus-bedieners op 'n onewe-gelyk basis (verbindingsnommer) gekies. Op daardie tydstip was dit genoeg, volgens ons gevoelens het dit ongeveer 'n viervoudige veiligheidsmarge gegee, die implementeringspersentasie was ongeveer 80. Terselfdertyd is die prys verminder tot ~2 roebels per les, plus ontwikkeling en ondersteuning.
Keer terug na die onderwerp van videokommunikasie
Ons monitor voortdurend terugvoer van studente en onderwysers om probleme betyds te identifiseer en reg te stel. Teen die somer van 2018 was oproepkwaliteit stewig in die eerste plek onder klagtes. Aan die een kant het dit beteken dat ons ander tekortkominge suksesvol oorkom het. Aan die ander kant was dit nodig om iets dringend te doen: as die les ontwrig word, loop ons die risiko om sy waarde te verloor, soms saam met die koste van die aankoop van die volgende pakket, en as die inleidende les ontwrig word, loop ons die risiko om 'n potensiële kliënt te verloor geheel en al.
Op daardie tydstip was ons videokommunikasie nog in MVP-modus. Eenvoudig gestel, hulle het dit bekendgestel, dit het gewerk, hulle het dit een keer afgeskaal, hulle het verstaan hoe om dit te doen - wel, wonderlik. As dit werk, moenie dit regmaak nie. Niemand het doelbewus die kwessie van kommunikasiekwaliteit aangespreek nie. Teen Augustus het dit duidelik geword dat dit nie kon voortgaan nie, en ons het 'n aparte rigting geloods om uit te vind wat fout is met WebRTC en Janus.
By die insette het hierdie rigting ontvang: 'n MVP-oplossing, geen maatstawwe, geen doelwitte, geen prosesse vir verbetering nie, terwyl 7% van onderwysers kla oor die kwaliteit van kommunikasie (daar was ook geen data oor studente nie).
’n Nuwe rigting is aan die gang
Die opdrag lyk so iets:
- Die hoof van die departement, wat ook die hoofontwikkelaar is.
- QA help om veranderinge te toets, soek na nuwe maniere om onstabiele kommunikasietoestande te skep, en rapporteer probleme vanaf die voorste linie.
- Die ontleder soek voortdurend na verskeie korrelasies in tegniese data, verbeter die ontleding van gebruikersterugvoer en kontroleer die resultate van eksperimente.
- Die produkbestuurder help met die algehele rigting en toewysing van hulpbronne vir eksperimente.
- ’n Tweede ontwikkelaar help dikwels met programmering en verwante take.
Om mee te begin, het ons 'n relatief betroubare maatstaf opgestel wat veranderinge in kommunikasiekwaliteitbeoordelings (gemiddeld oor dae, weke, maande) nagespoor het. Op daardie tydstip was dit grade van onderwysers; later grade van studente is daarby gevoeg. Toe het hulle begin om hipoteses te bou oor wat verkeerd werk, dit reg te stel en na veranderinge in dinamika te kyk. Ons het gegaan vir die laaghangende vrugte: ons het byvoorbeeld die vp8-kodek met vp9 vervang, die werkverrigting het verbeter. Ons het probeer om met die Janus-instellings te speel en ander eksperimente uit te voer – in die meeste gevalle het dit tot niks gelei nie.
In die tweede stadium het 'n hipotese na vore gekom: WebRTC is 'n eweknie-oplossing, en ons gebruik 'n bediener in die middel. Miskien lê die probleem hier? Ons het begin grawe en die belangrikste verbetering tot dusver gevind.
Op daardie oomblik is 'n bediener uit die swembad gekies met 'n nogal dom algoritme: elkeen het sy eie "gewig", afhangende van die kanaal en krag, en ons het probeer om die gebruiker na die een met die grootste "gewig" te stuur sonder aandag te gee aan waar die gebruiker geografies geleë was. Gevolglik kon 'n onderwyser van St. Petersburg met 'n student van Siberië deur Moskou kommunikeer, en nie deur ons Janus-bediener in St. Petersburg nie.
Die algoritme is oorgedoen: nou, wanneer 'n gebruiker ons platform oopmaak, versamel ons pings van hom na alle bedieners wat Ajax gebruik. Wanneer 'n verbinding tot stand kom, kies ons 'n paar pings (onderwyser-bediener en student-bediener) met die kleinste hoeveelheid. Minder ping beteken minder netwerkafstand na die bediener; korter afstand beteken laer waarskynlikheid om pakkies te verloor; Pakkieverlies is die grootste negatiewe faktor in videokommunikasie. Die aandeel van negatiwiteit het binne drie maande met die helfte gedaal (om eerlik te wees, ander eksperimente is in hierdie tyd uitgevoer, maar hierdie een het byna seker die meeste impak gehad).
Ons het onlangs nog 'n nie-vanselfsprekende, maar blykbaar belangrike ding ontdek: in plaas van een kragtige Janus-bediener op 'n dik kanaal, is dit beter om twee eenvoudigers met dunner bandwydte te hê. Dit het duidelik geword nadat ons kragtige masjiene gekoop het in die hoop om soveel kamers (kommunikasiesessies) gelyktydig daarin te prop. Bedieners het 'n bandwydtelimiet, wat ons akkuraat kan vertaal in die aantal kamers - ons weet hoeveel kan oopgemaak word, byvoorbeeld teen 300 Mbit/s. Sodra daar te veel kamers op 'n bediener oop is, hou ons op om dit vir nuwe aktiwiteite te kies totdat die vrag afneem. Die idee was dat, nadat ons 'n kragtige masjien gekoop het, ons die kanaal tot die maksimum sou laai, sodat dit uiteindelik deur die verwerker en geheue beperk sou word, en nie deur bandwydte nie. Maar dit het geblyk dat na 'n sekere aantal oop kamers (420), ondanks die feit dat die las op die verwerker, geheue en skyf nog baie ver van die perke is, negatiwiteit by tegniese ondersteuning begin uitkom. Blykbaar word iets erger binne Janus, miskien is daar ook 'n paar beperkings. Ons het begin eksperimenteer, die bandwydtelimiet van 300 tot 200 Mbit/s verlaag, en die probleme het verdwyn. Nou het ons drie nuwe bedieners gelyktydig gekoop met lae limiete en eienskappe, ons dink dit sal lei tot 'n stabiele verbetering in die kwaliteit van kommunikasie. Natuurlik het ons nie probeer uitvind wat daar aangaan nie; ons krukke is alles. In ons verdediging, kom ons sê dat dit op daardie oomblik nodig was om die knellende probleem so vinnig moontlik op te los, en nie om dit mooi te doen nie; buitendien is Janus vir ons 'n swart boks wat in C geskryf is, dit is baie duur om daarmee te peuter.
Wel, in die proses het ons:
- het alle afhanklikhede opgedateer wat opgedateer kan word, beide op die bediener en op die kliënt (dit was ook eksperimente, ons het die resultate gemonitor);
- het alle geïdentifiseerde foute wat verband hou met spesifieke gevalle reggestel, byvoorbeeld wanneer die verbinding verval het en nie outomaties herstel is nie;
- Ons het baie vergaderings gehou met maatskappye wat op die gebied van videokommunikasie werk en vertroud is met ons probleme: stroom speletjies, organisering van webinars; ons het alles probeer wat vir ons nuttig gelyk het;
- Het 'n tegniese hersiening gedoen van die hardeware en kommunikasiekwaliteit van onderwysers, van wie die meeste klagtes gekom het.
Die eksperimente en daaropvolgende veranderinge het dit moontlik gemaak om ontevredenheid met kommunikasie onder onderwysers van 7,1% in Januarie 2018 tot 2,5% in Januarie 2019 te verminder.
Wat is volgende?
Die stabilisering van ons Vimbox-platform is een van die maatskappy se hoofprojekte vir 2019. Ons het groot hoop dat ons die momentum sal kan behou en nie meer videokommunikasie in die topklagtes sal sien nie. Ons verstaan dat 'n beduidende deel van hierdie klagtes verband hou met vertragings in gebruikers se rekenaars en internet, maar ons moet hierdie deel bepaal en die res oplos. Alles anders is 'n tegniese probleem, dit blyk dat ons dit moet kan hanteer.
Die grootste probleem is dat ons nie weet tot watter vlak dit werklik moontlik is om kwaliteit te verbeter nie. Om hierdie plafon uit te vind is die hooftaak. Daarom is twee eksperimente beplan:
- vergelyk video via Janus met gewone p2p in gevegstoestande. Hierdie eksperiment is reeds uitgevoer, geen statisties betekenisvolle verskil is gevind tussen ons oplossing en p2p nie;
- Kom ons verskaf (duur) dienste van maatskappye wat uitsluitlik geld maak op videokommunikasie-oplossings, en vergelyk die hoeveelheid negatiwiteit van hulle met die bestaande een.
Hierdie twee eksperimente sal ons in staat stel om 'n haalbare doelwit te identifiseer en daarop te fokus.
Daarbenewens is daar 'n aantal take wat gereeld opgelos kan word:
- Ons skep 'n tegniese maatstaf van kommunikasiekwaliteit in plaas van subjektiewe resensies;
- Ons maak meer gedetailleerde sessielogboeke om die mislukkings wat voorkom meer akkuraat te ontleed, te verstaan wanneer en waar presies dit plaasgevind het, en watter oënskynlik onverwante gebeure op daardie oomblik plaasgevind het;
- Ons berei 'n outomatiese verbindingsgehaltetoets voor die les voor, en gee ook die kliënt die geleentheid om die verbinding met die hand te toets om die hoeveelheid negatiwiteit wat deur sy hardeware en kanaal veroorsaak word, te verminder;
- ons sal meer videokommunikasieladingstoetse ontwikkel en uitvoer in swak toestande, met veranderlike pakkieverlies, ens.;
- ons verander die gedrag van bedieners in geval van probleme om fouttoleransie te verhoog;
- Ons sal die gebruiker waarsku as daar hoegenaamd fout is met sy verbinding, soos Skype doen, sodat hy verstaan dat die probleem aan sy kant is.
Sedert April het die videokommunikasierigting 'n volwaardige afsonderlike projek binne Skyeng geword, wat handel oor sy eie produk, nie net 'n deel van Vimbox nie. Dit beteken dat ons begin soek na mense op . Wel, soos altyd .
En natuurlik gaan ons voort om aktief te kommunikeer met mense en maatskappye wat met videokommunikasie werk. As jy ervaring met ons wil uitruil, sal ons bly wees! Lewer kommentaar, kontak ons - ons sal almal antwoord.
Bron: will.com