Videocommunicatie is de belangrijkste manier van communicatie tussen docent en student op het Vimbox-platform. We zijn al geruime tijd gestopt met Skype, hebben verschillende externe oplossingen geprobeerd en zijn uiteindelijk aangekomen bij de combinatie van WebRTC en Janus-gateway. Een tijdlang voldeed dit ons, maar toch bleven er enkele negatieve aspecten naar voren komen. Uiteindelijk is er een aparte tak voor video opgericht.
Ik heb Kirill Rogov, de leider van deze nieuwe tak, gevraagd om de evolutie van videocommunicatie bij Skyeng, de ontdekte problemen, oplossingen en bijkomstigheden die we uiteindelijk hebben toegepast, toe te lichten. We hopen dat het artikel nuttig zal zijn voor bedrijven die ook zelf video via webapplicaties implementeren.
Een beetje geschiedenis
In de zomer van 2017 gaf Sergey Safonov, hoofd ontwikkeling bij Skyeng, een presentatie op de Backend Conf over hoe we 'van Skype zijn afgestapt en WebRTC hebben geïmplementeerd'. Belangstellenden kunnen de opname van de presentatie bekijken via (~45 min), en hier zal ik de essentie kort samenvatten.
Voor de school Skyeng was videocommunicatie altijd de prioritaire manier van communiceren tussen leraar en leerling. In het begin gebruikten we 'Skype', maar dat voldeed absoluut niet om verschillende redenen, vooral vanwege het gebrek aan logs en de onmogelijkheid tot integratie in de webapplicatie. Daarom hebben we allerlei experimenten uitgevoerd.
Eigenlijk waren onze eisen aan videocommunicatie ongeveer als volgt:
— stabiliteit;
— lage kosten per les;
— opname van lessen;
— bijhouden wie hoeveel spreekt (het is belangrijk voor ons dat leerlingen meer spreken dan de docent tijdens lessen);
— lineaire schaalbaarheid;
— mogelijkheid om zowel UDP als TCP te gebruiken.
Als eerste probeerden we in 2013 Tokbox te implementeren. Alles was goed, maar het was erg duur – 113 roebel per les – en dat verbruikte onze winst.
Daarna hebben we in 2015 Voximplant geïntegreerd. Deze oplossing had de benodigde functie om bij te houden wie hoeveel spreekt, en was bovendien aanzienlijk goedkoper: bij opname van alleen geluid kostte het 20 roebel per les. Het werkte echter alleen via UDP en kon niet overschakelen naar TCP. Desondanks gebruikte ongeveer 40% van de leerlingen het.
Na een jaar begonnen we zakelijke klanten te krijgen met hun specifieke eisen. Bijvoorbeeld, alles moet via de browser werken, in het bedrijf zijn alleen http en https open; dat wil zeggen, geen 'Skype' en UDP. Zakelijke klanten = geld, dus we keerden terug naar Tokbox, maar het prijsprobleem bleef bestaan.
Oplossing — WebRTC en Janus
We hebben besloten om . Het is verantwoordelijk voor het opzetten van de verbinding, het coderen en decoderen van streams, het synchroniseren van tracks en het kwaliteitsbeheer met het verwerken van netwerkproblemen. Van onze kant moeten we zorgen voor het lezen van streams van de camera en microfoon, het weergeven van video, het beheren van de verbinding, het opzetten van de WebRTC-verbinding en het doorgeven van streams aan hem, evenals het doorgeven van signaalberichten tussen klanten voor het opzetten van de verbinding (WebRTC beschrijft alleen het gegevensformaat, maar niet het mechanisme voor hun overdracht). In het geval dat klanten zich achter NAT bevinden, verbindt WebRTC STUN-servers, en als dat niet helpt, TURN-servers.
Een gewone p2p-verbinding is niet genoeg voor ons, aangezien we lessen willen opnemen voor verdere analyse in geval van klachten. Daarom sturen we de WebRTC-streams via een relais . Hierdoor weten klanten elkaars adressen niet, ze zien alleen het adres van de Janus-server; deze fungeert ook als signaalserver. Janus heeft veel nuttige functies voor ons: schakelt automatisch over naar TCP als de UDP van de klant is geblokkeerd; kan zowel UDP- als TCP-streams opnemen; is schaalbaar; er is zelfs een ingebouwde plug-in voor echo-tests. Indien nodig worden automatisch STUN- en TURN-servers van Twilio verbonden.
In de zomer van 2017 hadden we twee Janus-servers in werking plus een extra server voor de verwerking van opgenomen ruwe audio- en videobestanden, zodat de hoofdprocessoren niet belast werden. Bij het aansluiten werden de Janus-servers gekozen op basis van even-oneven (verbindingnummer). Op dat moment was dit voldoende, we hadden het gevoel dat dit ongeveer vier keer de benodigde capaciteit bood, het implementatiepercentage was ongeveer 80. Tegelijkertijd werd de prijs verlaagd tot ~2 roebel per les, plus ontwikkeling en ondersteuning.
Terug naar het onderwerp videocommunicatie
We constantly monitor feedback from students and teachers to identify and address issues promptly. By the summer of 2018, the quality of the connection firmly took the top spot among complaints. On one hand, this meant we had successfully addressed other shortcomings. On the other hand, we needed to act quickly: if a lesson is disrupted, we risk losing its value, sometimes along with the cost of purchasing the next package, and if the introductory session is disrupted, we might even lose a potential client.
At that time, our video connection was still in MVP mode. Simply put, we launched it, it worked, scaled once, understood how to do it – and good. If it works, don’t fix it. No one was specifically addressing the issue of connection quality. By August, it became clear that this could not continue, and we launched a separate initiative to figure out what was wrong with WebRTC and Janus.
This initiative began with: an MVP solution, no metrics, no goals, no processes for improvement, and meanwhile, 7% of teachers complained about connection quality (there was no data on students either).
The new initiative gets to work
The team looks something like this:
- Head of the initiative, who is also the main developer.
- QA helps test changes, looks for new ways to create unstable connection conditions, and reports issues from the frontline.
- An analyst constantly looks for different correlations in technical data, improves user feedback analysis, and checks the results of experiments.
- The product manager assists with overall direction and resource allocation for experiments.
- The second developer often helps with the actual programming and related tasks.
Initially, we set up a relatively reliable metric that tracked changes in connection quality ratings (averaged over days, weeks, months). At that time, these were ratings from teachers, and later ratings from students were added. Then we started building hypotheses about what wasn't working, making corrections, and watching for changes in dynamics. We went for low-hanging fruits: for example, we replaced the vp8 codec with vp9, and the indicators improved. We tried adjusting Janus settings and conducting other experiments, most of which led to nothing.
In de tweede fase ontstond de hypothese: WebRTC is een peer-to-peer oplossing, en wij gebruiken een server ertussen. Zou het probleem hier verborgen kunnen zijn? We begonnen te graven en vonden hier tot nu toe de meest significante verbetering.
Op dat moment werd de server uit de pool gekozen volgens een vrij dom algoritme: iedereen had zijn eigen 'gewicht', afhankelijk van de verbinding en de kracht, en we probeerden de gebruiker te sturen naar de server met het hoogste 'gewicht', zonder acht te slaan op waar de gebruiker geografisch zich bevond. Als gevolg hiervan kon een leraar uit St. Petersburg communiceren met een student uit Siberië via Moskou, in plaats van via onze Janus-server in St. Petersburg.
Het algoritme is opnieuw ontworpen: nu, wanneer een gebruiker ons platform opent, verzamelen we via Ajax de pings van hen naar alle servers. Bij het tot stand brengen van de verbinding kiezen we een paar pings (leraar-server en student-server) met de laagste som. Minder ping betekent een kleinere netwerklatentie naar de server; minder afstand betekent een kleinere kans op pakketverlies; pakketverlies is de grootste negatieve factor in videocall. Het percentage van negatieve ervaringen is in drie maanden tijd gehalveerd (ter rechtvaardiging, in deze periode werden ook andere experimenten uitgevoerd, maar deze heeft waarschijnlijk het meeste effect gehad).
Onlangs hebben we nog iets ontdekt dat niet voor de hand ligt, maar blijkbaar belangrijk is: in plaats van één krachtige Janus-server op een dikke lijn, zijn twee eenvoudigere servers met een lagere bandbreedte beter. Dit werd duidelijk nadat we juist krachtige machines hadden aangeschaft in de hoop daar zoveel mogelijk kamers (communicatiesessies) tegelijkertijd op te zetten. Servers hebben een bandbreedte-limiet, die we exact kunnen omrekenen naar het aantal kamers — we weten hoeveel we bijvoorbeeld kunnen openen op 300 Mbit/s. Zodra er te veel kamers op de server zijn geopend, stoppen we met het kiezen van deze voor nieuwe sessies totdat de belasting vermindert. Het idee was dat we met de aankoop van een krachtige machine de lijn maximaal zouden belasten, zodat we uiteindelijk tegen de CPU- en geheugengrenzen aanlopen in plaats van tegen de bandbreedte. Maar het bleek dat na een bepaald aantal geopende kamers (420), hoewel de belasting van CPU, RAM en schijf nog ver van de limieten is, er negatieve reacties bij de support binnenkomen. Blijkbaar wordt er iets slechter binnen Janus, misschien zijn daar ook beperkingen. We zijn gaan experimenteren, hebben de bandbreedte-limiet verlaagd van 300 naar 200 Mbit/s, en de problemen verdwenen. Nu hebben we drie nieuwe servers aangeschaft met lagere limieten en specificaties, in de hoop dat dit zal leiden tot een stabiele verbetering van de kwaliteit van de verbinding. We hebben er natuurlijk niet verder naar gekeken, tijdelijke oplossingen zijn ons alles. Ter verdediging zeggen we dat we op dat moment snel een dringend probleem moesten oplossen en niet esthetisch; bovendien is Janus voor ons een zwart gat, geschreven in C, en het is erg kostbaar om daar in te graven.
En in het proces hebben we:
- alle afhankelijkheden geüpdatet die we konden updaten, zowel op de server als op de client (dit waren ook experimenten, we hielden de resultaten in de gaten);
- alle gevonden bugs opgelost die specifieke gevallen betroffen, bijvoorbeeld wanneer de verbinding viel en niet automatisch herstelde;
- een groot aantal vergaderingen gehouden met bedrijven die actief zijn in videocommunicatie en bekend zijn met onze problemen: game streaming, webinars organiseren; we hebben alles geprobeerd wat nuttig leek;
- een technische beoordeling van de hardware en de verbindingskwaliteit bij de docenten uitgevoerd, van wie de meeste klachten afkomstig waren.
De uitgevoerde experimenten en de daaropvolgende wijzigingen hebben het aantal klachten over de verbinding onder docenten weten te verlagen van 7,1% in januari 2018 naar 2,5% in januari 2019.
Hier was eigenlijk een praktische sectie gepland met demonstratie van drie projecten op STM32 en STM8, speciaal voor dit artikel gemaakt met behulp van datasheets, met lampen, SPI, timers, PWM en interrupts:
De stabilisatie van ons Vimbox-platform is een van de belangrijkste projecten van het bedrijf voor 2019. We hebben hoge verwachtingen dat we de dynamiek kunnen behouden en geen videoconferentie meer in de top van klachten zien. We begrijpen dat een aanzienlijk deel van deze klachten te maken heeft met de lag van computers en internetverbindingen van gebruikers, maar we moeten dit deel identificeren en de rest oplossen. De rest is een technisch probleem, waar we in staat moeten zijn mee om te gaan.
De belangrijkste uitdaging is dat we niet weten tot welk niveau we de kwaliteit kunnen verhogen. Het vaststellen van deze grens is de belangrijkste taak. Daarom zijn er twee experimenten gepland:
- vergelijking van video via Janus met gewone p2p onder realistische omstandigheden. Dit experiment is al uitgevoerd, en er is geen statistisch significante verschil tussen onze oplossing en p2p ontdekt;
- we plaatsen (dure) diensten van bedrijven die uitsluitend verdienen aan videoconferentieoplossingen en vergelijken de hoeveelheid negativiteit die daaruit voortkomt met de huidige situatie.
Deze twee experimenten stellen ons in staat om het haalbare doel vast te stellen en ons daarop te concentreren.
Daarnaast zijn er verschillende taken die we in de dagelijkse gang van zaken aanpakken:
- we creëren een technische kwaliteitsmeter voor de verbinding in plaats van subjectieve beoordelingen;
- we maken gedetailleerdere sessielogs zodat we storingen nauwkeuriger kunnen analyseren, begrijpen wanneer en waar ze precies zijn voorgekomen, en welke ogenschijnlijk niet met elkaar verbonden gebeurtenissen zich op dat moment hebben voorgedaan;
- we bereiden een automatische kwaliteitsmeting van de verbinding voor vóór de les en bieden ook de mogelijkheid voor de klant om handmatig de verbinding te testen, om het aantal klachten dat door zijn hardware en verbinding wordt veroorzaakt te verminderen;
- we zullen meer stresstests van videoconferenties in slechte omstandigheden uitvoeren, met variabele pakketverlies, enz.;
- we veranderen het gedrag van servers in het geval van problemen om de beschikbaarheid te verhogen;
- we zullen de gebruiker waarschuwen als er iets mis is met zijn verbinding, zoals Skype doet, zodat hij begrijpt dat het probleem aan zijn kant ligt.
Vanaf april wordt videocommunicatie een volwaardig zelfstandig project binnen Skyeng, gericht op ons eigen product, niet slechts een onderdeel van Vimbox. Dit betekent dat we beginnen met het zoeken naar mensen voor . En zoals altijd .
. Natuurlijk blijven we ook actief in contact met mensen en bedrijven die zich bezighouden met videocommunicatie. Als je ervaring met ons wilt delen, zijn we blij dat je contact met ons opneemt! Laat een reactie achter, neem contact op — we antwoorden iedereen.
Bron: habr.com
