Videocommunicatie is de belangrijkste manier van communicatie tussen docent en leerling op het Vimbox-platform. We hebben Skype al lang geleden opgegeven, hebben verschillende oplossingen van derden geprobeerd en uiteindelijk gekozen voor de combinatie WebRTC - Janus-gateway. Een tijdlang waren we met alles tevreden, maar er bleven toch enkele negatieve aspecten naar voren komen. Als gevolg hiervan ontstond een aparte videoregie.
Ik vroeg Kirill Rogovoy, het hoofd van de nieuwe richting, om te praten over de evolutie van videocommunicatie bij Skyeng, de ontdekte problemen, oplossingen en krukken die we uiteindelijk gebruikten. We hopen dat het artikel nuttig zal zijn voor bedrijven die ook zelf video maken via een webapplicatie.
Een beetje geschiedenis
In de zomer van 2017 sprak het hoofd van Skyeng-ontwikkeling, Sergey Safonov, op Backend Conf met een verhaal over hoe we “Skype achter ons lieten en WebRTC implementeerden.” Geïnteresseerden kunnen de opname van de toespraak bekijken op (~45 min), en hier zal ik kort de essentie ervan schetsen.
Voor Skyeng School is videocommunicatie altijd een prioriteit geweest in de communicatie tussen leraar en leerling. In eerste instantie werd Skype gebruikt, maar dit was om een aantal redenen categorisch niet bevredigend, voornamelijk vanwege het gebrek aan logbestanden en de onmogelijkheid van directe integratie in de webapplicatie. Daarom hebben we allerlei experimenten uitgevoerd.
Eigenlijk waren onze eisen voor videocommunicatie ongeveer de volgende:
- stabiliteit;
— lage prijs per les;
— lessen opnemen;
— bijhouden wie hoeveel spreekt (het is voor ons belangrijk dat leerlingen tijdens de lessen meer spreken dan de leraar);
— lineaire schaling;
- mogelijkheid om zowel UDP als TCP te gebruiken.
De eerste die dit probeerde was de implementatie van Tokbox in 2013. Alles was goed, maar het bleek erg duur - 113 roebel per les - en at de winst op.
In 2015 werd Voximplant geïntegreerd. Hier was de functie die we nodig hadden om bij te houden wie hoeveel sprak, en tegelijkertijd was de oplossing veel goedkoper: als er alleen audio werd opgenomen, kostte het 20 roebel per les. Het werkte echter alleen via UDP en kon niet overschakelen naar TCP. Ongeveer 40% van de studenten maakte er uiteindelijk gebruik van.
Een jaar later begonnen we zakelijke klanten te krijgen met hun eigen specifieke eisen. Zo zou alles via een browser moeten werken, het bedrijf opent alleen http en https; dat wil zeggen geen Skype of UDP. Zakelijke klanten = geld, dus keerden ze terug naar Tokbox, maar het prijsprobleem verdween niet.
Oplossing - WebRTC en Janus
Besloten om te gebruiken . Het is verantwoordelijk voor het tot stand brengen van een verbinding, het coderen en decoderen van streams, het synchroniseren van tracks en de kwaliteitscontrole bij het afhandelen van netwerkstoringen. Van onze kant moeten we ervoor zorgen dat de streams van de camera en de microfoon worden gelezen, video wordt getekend, de verbinding wordt beheerd, een WebRTC-verbinding tot stand wordt gebracht en er streams naartoe worden verzonden, evenals het verzenden van signaalberichten tussen clients om een verbinding tot stand te brengen (WebRTC zelf beschrijft alleen de gegevensformaat, maar niet het mechanisme voor overdracht). Als clients achter NAT staan, verbindt WebRTC STUN-servers; als dit niet helpt, TURN-servers.
Een reguliere p2p-verbinding is voor ons niet voldoende, omdat wij lessen willen opnemen voor verdere analyse bij klachten. Daarom sturen wij WebRTC-streams via een relay . Als gevolg hiervan kennen clients elkaars adressen niet en zien ze alleen het Janus-serveradres; het vervult ook de functies van een signaalserver. Janus heeft veel van de functies die we nodig hebben: schakelt automatisch over naar TCP als UDP op de client is geblokkeerd; kan zowel UDP- als TCP-streams opnemen; schaalbaar; Er is zelfs een ingebouwde plug-in voor echotests. Indien nodig worden STUN- en TURN-servers van Twilio automatisch met elkaar verbonden.
In de zomer van 2017 hadden we twee Janus-servers draaien, plus een extra server voor het verwerken van opgenomen onbewerkte audio- en videobestanden, om de processors van de belangrijkste niet te bezetten. Bij het verbinden werden Janus-servers geselecteerd op een oneven-even basis (verbindingsnummer). Op dat moment was dit naar onze mening voldoende, het gaf ongeveer een viervoudige veiligheidsmarge, het implementatiepercentage was ongeveer 80. Tegelijkertijd werd de prijs verlaagd tot ~2 roebel per les, plus ontwikkeling en ondersteuning.
Terugkomend op het onderwerp videocommunicatie
We monitoren voortdurend de feedback van studenten en docenten om problemen tijdig te kunnen identificeren en corrigeren. In de zomer van 2018 stond de gesprekskwaliteit duidelijk op de eerste plaats onder de klachten. Enerzijds betekende dit dat we andere tekortkomingen met succes hadden overwonnen. Aan de andere kant was het noodzakelijk om dringend iets te doen: als de les wordt verstoord, lopen we het risico de waarde ervan te verliezen, soms samen met de kosten voor de aanschaf van het volgende pakket, en als de introductieles wordt verstoord, lopen we het risico een potentiële klant te verliezen. allemaal samen.
Onze videocommunicatie stond toen nog in MVP-modus. Simpel gezegd, ze lanceerden het, het werkte, ze hebben het één keer geschaald, ze begrepen hoe ze het moesten doen - nou ja, geweldig. Als het werkt, repareer het dan niet. Niemand heeft bewust aandacht besteed aan de kwestie van de kwaliteit van de communicatie. In augustus werd duidelijk dat dit niet door kon gaan, en we lanceerden een aparte richting om erachter te komen wat er mis was met WebRTC en Janus.
Bij de input kreeg deze richting: een MVP-oplossing, geen statistieken, geen doelen, geen verbeteringsprocessen, terwijl 7% van de leraren klaagde over de kwaliteit van de communicatie (er waren ook geen gegevens over studenten).
Er is een nieuwe richting gaande
Het commando ziet er ongeveer zo uit:
- Het hoofd van de afdeling, die tevens de hoofdontwikkelaar is.
- QA helpt bij het testen van veranderingen, zoekt naar nieuwe manieren om onstabiele communicatieomstandigheden te creëren en rapporteert problemen vanaf de frontlinie.
- De analist zoekt voortdurend naar verschillende correlaties in technische gegevens, verbetert de analyse van gebruikersfeedback en controleert de resultaten van experimenten.
- De productmanager helpt bij de algemene leiding en toewijzing van middelen voor experimenten.
- Vaak helpt een tweede ontwikkelaar mee met programmeren en aanverwante taken.
Om te beginnen hebben we een relatief betrouwbare metriek opgezet die veranderingen in de beoordelingen van de communicatiekwaliteit bijhield (gemiddeld over dagen, weken, maanden). Destijds waren dit cijfers van docenten, later werden daar cijfers van studenten aan toegevoegd. Vervolgens begonnen ze hypothesen op te stellen over wat er niet goed werkte, dit te corrigeren en te kijken naar veranderingen in de dynamiek. We gingen voor het laaghangende fruit: we hebben bijvoorbeeld de vp8-codec vervangen door vp9, de prestaties verbeterden. We probeerden met de Janus-instellingen te spelen en andere experimenten uit te voeren - in de meeste gevallen leidden ze nergens toe.
In de tweede fase kwam een hypothese naar voren: WebRTC is een peer-to-peer-oplossing en we gebruiken een server in het midden. Misschien ligt het probleem hier? We zijn begonnen met graven en hebben de grootste verbetering tot nu toe gevonden.
Op dat moment werd een server uit de pool geselecteerd met behulp van een nogal dom algoritme: elk had zijn eigen "gewicht", afhankelijk van het kanaal en het vermogen, en we probeerden de gebruiker naar degene met het grootste "gewicht" te sturen, zonder aandacht besteden aan waar de gebruiker zich geografisch bevond. Als gevolg hiervan kon een leraar uit Sint-Petersburg via Moskou communiceren met een leerling uit Siberië, en niet via onze Janus-server in Sint-Petersburg.
Het algoritme is vernieuwd: wanneer een gebruiker ons platform nu opent, verzamelen we pings van hem naar alle servers die Ajax gebruiken. Bij het tot stand brengen van een verbinding selecteren we een paar pings (leraar-server en leerling-server) met het kleinste aantal. Minder ping betekent minder netwerkafstand tot de server; een kortere afstand betekent een lagere kans op het kwijtraken van pakketten; Pakketverlies is de grootste negatieve factor bij videocommunicatie. Het aandeel negativiteit is in drie maanden tijd met de helft gedaald (om eerlijk te zijn: er zijn in die tijd ook andere experimenten uitgevoerd, maar deze had vrijwel zeker de meeste impact).
We hebben onlangs nog een niet voor de hand liggend, maar blijkbaar belangrijk ding ontdekt: in plaats van één krachtige Janus-server op een dik kanaal, is het beter om twee eenvoudigere te hebben met een kleinere bandbreedte. Dit werd duidelijk nadat we krachtige machines kochten in de hoop er zoveel mogelijk kamers (communicatiesessies) tegelijk in te proppen. Servers hebben een bandbreedtelimiet, die we nauwkeurig kunnen vertalen naar het aantal kamers; we weten hoeveel kamers er bijvoorbeeld kunnen worden geopend bij 300 Mbit/s. Zodra er te veel kamers open zijn op een server, kiezen we deze niet meer voor nieuwe activiteiten totdat de belasting afneemt. Het idee was dat we, nadat we een krachtige machine hadden gekocht, het kanaal er maximaal op zouden laden, zodat het uiteindelijk zou worden beperkt door de processor en het geheugen, en niet door de bandbreedte. Maar het bleek dat na een bepaald aantal open kamers (420), ondanks het feit dat de belasting van de processor, het geheugen en de schijf nog steeds ver van de limieten ligt, negativiteit begint te komen bij technische ondersteuning. Blijkbaar wordt er iets erger binnen Janus, misschien zijn daar ook enkele beperkingen. We begonnen te experimenteren, verlaagden de bandbreedtelimiet van 300 naar 200 Mbit/s en de problemen verdwenen. Nu we in één keer drie nieuwe servers hebben gekocht met lage limieten en kenmerken, denken we dat dit zal leiden tot een stabiele verbetering van de kwaliteit van de communicatie. Natuurlijk hebben we niet geprobeerd erachter te komen wat daar aan de hand was; onze krukken zijn alles. Laten we ter verdediging zeggen dat het op dat moment nodig was om het dringende probleem zo snel mogelijk op te lossen, en niet om het mooi te doen; bovendien is Janus voor ons een zwarte doos geschreven in C, het is erg duur om eraan te sleutelen.
Welnu, tijdens het proces:
- alle afhankelijkheden bijgewerkt die konden worden bijgewerkt, zowel op de server als op de client (dit waren ook experimenten, we hebben de resultaten gemonitord);
- alle geïdentificeerde bugs opgelost die verband hielden met specifieke gevallen, bijvoorbeeld wanneer de verbinding werd verbroken en niet automatisch werd hersteld;
- We hebben veel ontmoetingen gehad met bedrijven die actief zijn op het gebied van videocommunicatie en bekend zijn met onze problemen: games streamen, webinars organiseren; we hebben alles geprobeerd wat ons nuttig leek;
- Een technisch onderzoek uitgevoerd naar de hardware- en communicatiekwaliteit van docenten, van wie de meeste klachten afkomstig waren.
Door de experimenten en daaropvolgende veranderingen is het mogelijk geworden om de ontevredenheid over de communicatie onder docenten terug te brengen van 7,1% in januari 2018 naar 2,5% in januari 2019.
What's Next
Het stabiliseren van ons Vimbox-platform is een van de belangrijkste projecten van het bedrijf voor 2019. We hebben goede hoop dat we het momentum kunnen vasthouden en videocommunicatie niet meer in de topklachten zien. We begrijpen dat een aanzienlijk deel van deze klachten verband houdt met vertragingen in de computers en het internet van gebruikers, maar we moeten dit deel vaststellen en de rest oplossen. Al het andere is een technisch probleem, het lijkt erop dat we er mee om moeten kunnen gaan.
Het grootste probleem is dat we niet weten in hoeverre het daadwerkelijk mogelijk is om de kwaliteit te verbeteren. Het vinden van dit plafond is de hoofdtaak. Daarom werden twee experimenten gepland:
- vergelijk video via Janus met reguliere p2p in gevechtsomstandigheden. Dit experiment is al uitgevoerd, er werd geen statistisch significant verschil gevonden tussen onze oplossing en p2p;
- Laten we (dure) diensten leveren van bedrijven die uitsluitend geld verdienen met videocommunicatieoplossingen, en de hoeveelheid negativiteit van hen vergelijken met de bestaande.
Deze twee experimenten zullen ons in staat stellen een haalbaar doel te identificeren en ons daarop te concentreren.
Daarnaast zijn er een aantal taken die routinematig kunnen worden opgelost:
- We creëren een technische maatstaf voor communicatiekwaliteit in plaats van subjectieve beoordelingen;
- We maken gedetailleerdere sessielogboeken om de fouten die optreden nauwkeuriger te analyseren, te begrijpen wanneer en waar ze precies plaatsvonden en welke ogenschijnlijk niet-gerelateerde gebeurtenissen op dat moment plaatsvonden;
- We bereiden vóór de les een automatische verbindingskwaliteitstest voor, en geven de klant ook de mogelijkheid om de verbinding handmatig te testen om de hoeveelheid negativiteit veroorzaakt door zijn hardware en kanaal te verminderen;
- we zullen meer belastingtests voor videocommunicatie ontwikkelen en uitvoeren in slechte omstandigheden, met variabel pakketverlies, enz.;
- we veranderen het gedrag van servers in geval van problemen om de fouttolerantie te vergroten;
- Wij zullen de gebruiker waarschuwen als er überhaupt iets mis is met zijn verbinding, zoals Skype dat doet, zodat hij begrijpt dat het probleem aan zijn kant ligt.
Sinds april is de richting videocommunicatie een volwaardig afzonderlijk project binnen Skyeng geworden, dat zich bezighoudt met een eigen product en niet alleen een onderdeel van Vimbox. Dit betekent dat wij op zoek gaan naar mensen . Nou ja, zoals altijd .
En uiteraard blijven we actief communiceren met mensen en bedrijven die met videocommunicatie werken. Als u ervaringen met ons wilt uitwisselen, vinden wij dat leuk! Reageer, neem contact op - wij zullen iedereen antwoorden.
Bron: www.habr.com