Videokommunikation är det huvudsakliga sättet för kommunikation mellan lärare och elev på Vimbox-plattformen. Vi gav upp Skype för länge sedan, försökte flera tredjepartslösningar och slog så småningom fast på kombinationen WebRTC - Janus-gateway. Under en tid var vi nöjda med allt, men ändå fortsatte några negativa aspekter att dyka upp. Som ett resultat skapades en separat videoriktning.
Jag bad Kirill Rogovoy, chefen för den nya riktningen, att prata om utvecklingen av videokommunikation på Skyeng, problemen som upptäckts, lösningar och kryckor som vi till slut använde. Vi hoppas att artikeln kommer att vara användbar för företag som också skapar video på egen hand genom en webbapplikation.
Lite historia
Sommaren 2017 talade chefen för Skyengs utveckling, Sergey Safonov, på Backend Conf med en berättelse om hur vi "övergav Skype och implementerade WebRTC." Intresserade kan se inspelningen av talet kl (~45 min), och här kommer jag kortfattat att beskriva dess väsen.
För Skyeng School har videokommunikation alltid varit ett prioriterat sätt för lärare-elevkommunikation. Till en början användes Skype, men det var kategoriskt inte tillfredsställande av flera skäl, främst på grund av bristen på loggar och omöjligheten att integrera direkt i webbapplikationen. Därför genomförde vi alla möjliga experiment.
Egentligen var våra krav för videokommunikation ungefär följande:
— stabilitet;
— Lågt pris per lektion.
— spela in lektioner.
— spåra vem som talar hur mycket (det är viktigt för oss att eleverna talar mer än läraren under lektionerna);
— linjär skalning;
- förmåga att använda både UDP och TCP.
Den första som testade var att implementera Tokbox 2013. Allt var bra, men det visade sig vara väldigt dyrt - 113 rubel per lektion - och åt upp vinsten.
Sedan 2015 integrerades Voximplant. Här var funktionen vi behövde för att spåra vem som talade hur mycket, och samtidigt var lösningen mycket billigare: om bara ljud spelades in kostade det 20 rubel per lektion. Det fungerade dock bara via UDP och kunde inte byta till TCP. Det slutade dock med att cirka 40 % av eleverna använde det.
Ett år senare började vi få företagskunder med sina egna specifika krav. Allt ska till exempel fungera via en webbläsare, företaget öppnar bara http och https; dvs inget Skype eller UDP. Företagskunder = pengar, så de återvände till Tokbox, men problemet med priset försvann inte.
Lösning - WebRTC och Janus
Beslutade att använda . Den ansvarar för att upprätta en anslutning, koda och avkoda strömmar, synkronisera spår och kvalitetskontroll med hantering av nätverksfel. För vår del måste vi se till att läsa strömmar från kameran och mikrofonen, rita video, hantera anslutningen, upprätta en WebRTC-anslutning och överföra strömmar till den, samt sända signalmeddelanden mellan klienter för att upprätta en anslutning (WebRTC själv beskriver endast dataformat, men inte dess mekanismöverföringar). Om klienter ligger bakom NAT ansluter WebRTC STUN-servrar, om detta inte hjälper, TURN-servrar.
En vanlig p2p-anslutning räcker inte för oss, eftersom vi vill spela in lektioner för vidare analys vid klagomål. Därför skickar vi WebRTC-strömmar genom ett relä . Som ett resultat känner klienterna inte till varandras adresser, de ser bara Janus-serveradressen; den utför också funktionerna hos en signalserver. Janus har många av funktionerna vi behöver: byter automatiskt till TCP om klienten har blockerat UDP; kan spela in både UDP- och TCP-strömmar; skalbar; Det finns till och med en inbyggd plugin för ekotester. Vid behov ansluts STUN- och TURN-servrar från Twilio automatiskt.
Sommaren 2017 hade vi två Janus-servrar igång, plus en extra server för att bearbeta inspelade råa ljud- och videofiler, för att inte uppta processorerna på de viktigaste. Vid anslutning valdes Janus-servrar på en udda-jämn basis (anslutningsnummer). På den tiden räckte detta, enligt våra känslor gav det ungefär en fyrfaldig säkerhetsmarginal, implementeringsprocenten var cirka 80. Samtidigt sänktes priset till ~2 rubel per lektion, plus utveckling och support.
Återgår till ämnet videokommunikation
Vi övervakar ständigt feedback från elever och lärare för att identifiera och korrigera problem i tid. Sommaren 2018 låg samtalskvaliteten klart på första plats bland klagomålen. Å ena sidan innebar detta att vi framgångsrikt hade övervunnit andra brister. Å andra sidan var det nödvändigt att göra något brådskande: om lektionen störs riskerar vi att förlora dess värde, ibland tillsammans med kostnaden för att köpa nästa paket, och om den inledande lektionen störs riskerar vi att förlora en potentiell kund sammanlagt.
Vid den tiden var vår videokommunikation fortfarande i MVP-läge. Enkelt uttryckt, de lanserade det, det fungerade, de skalade det en gång, de förstod hur man gör det - ja, bra. Om det fungerar, fixa det inte. Ingen tog medvetet upp frågan om kommunikationskvalitet. I augusti stod det klart att detta inte kunde fortsätta, och vi lanserade en separat riktning för att ta reda på vad som var fel med WebRTC och Janus.
Vid ingången fick denna riktning: en MVP-lösning, inga mätetal, inga mål, inga förbättringsprocesser, medan 7 % av lärarna klagar på kvaliteten på kommunikationen (det fanns inga uppgifter om eleverna heller).
En ny riktning är på väg
Kommandot ser ut ungefär så här:
- Avdelningschefen som också är huvudutvecklare.
- QA hjälper till att testa förändringar, letar efter nya sätt att skapa instabila kommunikationsförhållanden och rapporterar problem från frontlinjen.
- Analytikern letar ständigt efter olika samband i teknisk data, förbättrar analysen av användarfeedback och kontrollerar resultaten av experiment.
- Produktchefen hjälper till med den övergripande inriktningen och allokeringen av resurser för experiment.
- En andra utvecklare hjälper ofta till med programmering och relaterade uppgifter.
Till att börja med satte vi upp ett relativt tillförlitligt mått som spårade förändringar i kommunikationskvalitetsbedömningar (genomsnitt över dagar, veckor, månader). På den tiden var det betyg från lärare, senare kom betyg från elever till dem. Sedan började de bygga hypoteser om vad som fungerade fel, rätta till det och titta på förändringar i dynamiken. Vi valde den lågt hängande frukten: till exempel ersatte vi vp8 codec med vp9, prestandan förbättrades. Vi försökte leka med Janus-inställningarna och genomföra andra experiment – i de flesta fall ledde de inte till någonting.
I det andra steget dök en hypotes upp: WebRTC är en peer-to-peer-lösning, och vi använder en server i mitten. Kanske ligger problemet här? Vi började gräva och hittade den viktigaste förbättringen hittills.
I det ögonblicket valdes en server från poolen med en ganska dum algoritm: var och en hade sin egen "vikt", beroende på kanalen och kraften, och vi försökte skicka användaren till den med den största "vikten", utan uppmärksamma var användaren var geografiskt belägen. Som ett resultat kunde en lärare från St. Petersburg kommunicera med en elev från Sibirien genom Moskva, och inte via vår Janus-server i St. Petersburg.
Algoritmen har gjorts om: nu, när en användare öppnar vår plattform, samlar vi in pingar från honom till alla servrar som använder Ajax. När vi upprättar en anslutning väljer vi ett par pingar (lärare-server och elev-server) med det minsta beloppet. Mindre ping betyder mindre nätverksavstånd till servern; kortare avstånd betyder lägre sannolikhet att förlora paket; Paketförlust är den största negativa faktorn i videokommunikation. Andelen negativitet minskade med hälften på tre månader (för att vara rättvis utfördes andra experiment vid denna tidpunkt, men detta hade nästan säkert störst effekt).
Vi upptäckte nyligen en annan icke-uppenbar, men tydligen viktig sak: istället för en kraftfull Janus-server på en tjock kanal, är det bättre att ha två enklare med tunnare bandbredd. Detta blev tydligt efter att vi köpt kraftfulla maskiner i hopp om att stoppa in så många rum (kommunikationssessioner) i dem samtidigt. Servrar har en bandbreddsgräns, som vi exakt kan översätta till antalet rum - vi vet hur många som kan öppnas, till exempel med 300 Mbit/s. Så fort det är för många rum öppna på en server slutar vi välja den för nya aktiviteter tills belastningen minskar. Tanken var att efter att ha köpt en kraftfull maskin skulle vi ladda kanalen till den maximalt, så att den i slutändan skulle begränsas av processorn och minnet, och inte av bandbredden. Men det visade sig att efter ett visst antal öppna rum (420), trots att belastningen på processorn, minnet och disken fortfarande är väldigt långt från gränserna, börjar negativiteten komma till teknisk support. Tydligen blir det något värre inom Janus, kanske finns det några restriktioner även där. Vi började experimentera, sänkte bandbreddsgränsen från 300 till 200 Mbit/s och problemen försvann. Nu köpte vi tre nya servrar på en gång med låga gränser och egenskaper, vi tror att detta kommer leda till en stabil förbättring av kvaliteten på kommunikationen. Naturligtvis försökte vi inte ta reda på vad som pågick där; våra kryckor är allt. Till vårt försvar, låt oss säga att det i det ögonblicket var nödvändigt att lösa det akuta problemet så snabbt som möjligt, och inte göra det vackert; dessutom är Janus för oss en svart låda skriven i C, det är väldigt dyrt att mixtra med den.
Tja, i processen:
- uppdaterade alla beroenden som kunde uppdateras, både på servern och på klienten (detta var också experiment, vi övervakade resultaten);
- fixade alla identifierade buggar relaterade till specifika fall, till exempel när anslutningen avbröts och inte återställdes automatiskt;
- Vi höll många möten med företag som arbetar inom videokommunikationsområdet och var bekanta med våra problem: strömmande spel, organisera webbseminarier; vi försökte allt som verkade användbart för oss;
- Gjorde en teknisk granskning av hårdvaran och kommunikationskvaliteten hos lärare, från vilka de flesta klagomålen kom.
Experimenten och efterföljande förändringar gjorde det möjligt att minska missnöjet med kommunikationen bland lärare från 7,1 % i januari 2018 till 2,5 % i januari 2019.
Vad är nästa
Att stabilisera vår Vimbox-plattform är ett av företagets huvudprojekt för 2019. Vi har stora förhoppningar om att vi ska kunna behålla farten och inte längre se videokommunikation i de främsta klagomålen. Vi förstår att en betydande del av dessa klagomål är relaterade till fördröjningar i användarnas datorer och internet, men vi måste fastställa denna del och lösa resten. Allt annat är ett tekniskt problem, det verkar som att vi borde kunna hantera det.
Den största svårigheten är att vi inte vet till vilken nivå det faktiskt är möjligt att förbättra kvaliteten. Att ta reda på detta tak är huvuduppgiften. Därför planerades två experiment:
- jämför video via Janus med vanlig p2p i stridsförhållanden. Detta experiment har redan utförts, ingen statistiskt signifikant skillnad hittades mellan vår lösning och p2p;
- Låt oss tillhandahålla (dyra) tjänster från företag som tjänar pengar uteslutande på videokommunikationslösningar och jämför mängden negativitet från dem med den befintliga.
Dessa två experiment kommer att tillåta oss att identifiera ett uppnåeligt mål och fokusera på det.
Dessutom finns det ett antal uppgifter som kan lösas rutinmässigt:
- Vi skapar ett tekniskt mått på kommunikationskvalitet istället för subjektiva recensioner;
- Vi gör mer detaljerade sessionsloggar för att mer exakt analysera de fel som inträffar, förstå när och exakt var de inträffade och vilka till synes orelaterade händelser som ägde rum i det ögonblicket;
- Vi förbereder ett automatiskt test av anslutningskvalitet innan lektionen, och ger även klienten möjlighet att manuellt testa anslutningen för att minska mängden negativitet som orsakas av hans hårdvara och kanal;
- vi kommer att utveckla och genomföra fler belastningstester för videokommunikation under dåliga förhållanden, med varierande paketförluster, etc.;
- vi ändrar servrarnas beteende vid problem för att öka feltoleransen;
- Vi kommer att varna användaren om det är något fel med hans anslutning överhuvudtaget, som Skype gör, så att han förstår att problemet är på hans sida.
Sedan april har videokommunikationsinriktningen blivit ett fullfjädrat separat projekt inom Skyeng, som handlar om sin egen produkt, inte bara en del av Vimbox. Det gör att vi börjar leta efter folk på . Tja, som alltid .
Och naturligtvis fortsätter vi att aktivt kommunicera med människor och företag som arbetar med videokommunikation. Om du vill utbyta erfarenheter med oss blir vi glada! Kommentera, hör av dig - vi svarar alla.
Källa: will.com