Videokommunikation ist die wichtigste Art der Kommunikation zwischen Lehrer und Schüler auf der Vimbox-Plattform. Wir haben Skype vor langer Zeit aufgegeben, verschiedene Lösungen von Drittanbietern ausprobiert und uns schließlich für die WebRTC-Janus-Gateway-Kombination entschieden. Eine Zeit lang waren wir mit allem zufrieden, aber dennoch kamen immer wieder einige negative Aspekte zum Vorschein. Infolgedessen wurde eine eigene Videoregie erstellt.
Ich habe Kirill Rogovoy, den Leiter der neuen Leitung, gebeten, über die Entwicklung der Videokommunikation bei Skyeng, die entdeckten Probleme, Lösungen und Krücken zu sprechen, die wir letztendlich verwendet haben. Wir hoffen, dass der Artikel für Unternehmen nützlich ist, die auch selbst Videos über eine Webanwendung erstellen.
Ein wenig Geschichte
Im Sommer 2017 sprach der Leiter der Skyeng-Entwicklung, Sergey Safonov, auf der Backend Conf mit einer Geschichte darüber, wie wir „Skype aufgegeben und WebRTC implementiert haben“. Interessierte können sich die Aufzeichnung der Rede hier ansehen (~45 Minuten), und hier werde ich kurz das Wesentliche skizzieren.
Für die Skyeng School war Videokommunikation schon immer ein vorrangiges Mittel der Lehrer-Schüler-Kommunikation. Zunächst wurde Skype verwendet, das jedoch aus mehreren Gründen grundsätzlich nicht zufriedenstellend war, vor allem aufgrund fehlender Protokolle und der Unmöglichkeit einer direkten Integration in die Webanwendung. Deshalb haben wir alle möglichen Experimente durchgeführt.
Eigentlich waren unsere Anforderungen an die Videokommunikation ungefähr die folgenden:
- Stabilität;
— niedriger Preis pro Unterrichtsstunde;
— Unterrichtsstunden aufzeichnen;
— Nachverfolgung, wer wie viel spricht (für uns ist es wichtig, dass die Schüler während des Unterrichts mehr sprechen als der Lehrer);
— lineare Skalierung;
- Möglichkeit, sowohl UDP als auch TCP zu verwenden.
Der erste Versuch war die Implementierung von Tokbox im Jahr 2013. Alles war gut, aber es erwies sich als sehr teuer – 113 Rubel pro Unterrichtsstunde – und verschlang den Gewinn.
Im Jahr 2015 wurde dann Voximplant integriert. Hier war die Funktion, die wir brauchten, um zu verfolgen, wer wie viel gesprochen hat, und gleichzeitig war die Lösung viel günstiger: Wenn nur Audio aufgezeichnet wurde, kostete es 20 Rubel pro Unterrichtsstunde. Es funktionierte jedoch nur über UDP und konnte nicht auf TCP umstellen. Am Ende nutzten es jedoch etwa 40 % der Studierenden.
Ein Jahr später begannen wir, Firmenkunden mit ihren eigenen spezifischen Anforderungen zu betreuen. Beispielsweise sollte alles über einen Browser funktionieren; das Unternehmen öffnet nur http und https; d.h. kein Skype oder UDP. Firmenkunden = Geld, also kehrten sie zu Tokbox zurück, aber das Preisproblem verschwand nicht.
Lösung – WebRTC und Janus
Beschlossen zu verwenden . Es ist für den Verbindungsaufbau, die Codierung und Decodierung von Streams, die Synchronisierung von Tracks und die Qualitätskontrolle bei der Bewältigung von Netzwerkstörungen verantwortlich. Wir müssen unsererseits sicherstellen, dass Streams von der Kamera und dem Mikrofon gelesen, Videos gezeichnet, die Verbindung verwaltet, eine WebRTC-Verbindung hergestellt und Streams dorthin übertragen werden sowie Signalisierungsnachrichten zwischen Clients übertragen werden, um eine Verbindung herzustellen (WebRTC selbst beschreibt nur die Datenformat, nicht jedoch dessen Übertragungsmechanismus). Wenn sich Clients hinter NAT befinden, verbindet WebRTC STUN-Server; wenn dies nicht hilft, TURN-Server.
Eine reguläre P2P-Verbindung reicht uns nicht aus, da wir Lektionen für die weitere Analyse im Falle von Beschwerden aufzeichnen möchten. Deshalb senden wir WebRTC-Streams über ein Relay . Dadurch kennen Clients die Adressen der anderen Clients nicht und sehen nur die Janus-Serveradresse. es übernimmt auch die Funktionen eines Signalservers. Janus verfügt über viele der Funktionen, die wir benötigen: schaltet automatisch auf TCP um, wenn der Client UDP blockiert hat; kann sowohl UDP- als auch TCP-Streams aufzeichnen; skalierbar; Es gibt sogar ein integriertes Plugin für Echotests. Bei Bedarf werden automatisch STUN- und TURN-Server von Twilio angebunden.
Im Sommer 2017 hatten wir zwei Janus-Server in Betrieb, plus einen zusätzlichen Server zur Verarbeitung der aufgenommenen Roh-Audio- und Videodateien, um die Prozessoren der Hauptserver nicht zu belasten. Beim Herstellen der Verbindung wurden Janus-Server auf einer ungeraden-geraden Basis (Verbindungsnummer) ausgewählt. Dies war damals ausreichend, nach unserem Empfinden gab es ungefähr eine vierfache Sicherheitsmarge, der Umsetzungsprozentsatz lag bei etwa 80. Gleichzeitig wurde der Preis auf ~2 Rubel pro Unterrichtsstunde gesenkt, zuzüglich Entwicklung und Support.
Zurück zum Thema Videokommunikation
Wir überwachen ständig das Feedback von Schülern und Lehrern, um Probleme rechtzeitig zu erkennen und zu beheben. Im Sommer 2018 stand die Anrufqualität bei den Beschwerden fest an erster Stelle. Einerseits bedeutete dies, dass wir andere Defizite erfolgreich überwunden hatten. Andererseits musste dringend etwas unternommen werden: Wenn die Unterrichtsstunde unterbrochen wird, riskieren wir, ihren Wert zu verlieren, manchmal zusammen mit den Kosten für den Kauf des nächsten Pakets, und wenn die Einführungsstunde unterbrochen wird, riskieren wir, einen potenziellen Kunden zu verlieren insgesamt.
Zu diesem Zeitpunkt befand sich unsere Videokommunikation noch im MVP-Modus. Einfach ausgedrückt: Sie haben es gestartet, es hat funktioniert, sie haben es einmal skaliert, sie haben verstanden, wie es geht – nun ja, großartig. Wenn es funktioniert, reparieren Sie es nicht. Niemand hat sich bewusst mit der Frage der Kommunikationsqualität befasst. Im August wurde klar, dass dies nicht so weitergehen konnte, und wir starteten eine separate Richtung, um herauszufinden, was mit WebRTC und Janus nicht stimmte.
Bei der Eingabe erhielt diese Richtung: eine MVP-Lösung, keine Metriken, keine Ziele, keine Prozesse zur Verbesserung, während 7 % der Lehrer sich über die Qualität der Kommunikation beschweren (es gab auch keine Daten zu den Schülern).
Eine neue Richtung ist im Gange
Der Befehl sieht etwa so aus:
- Der Abteilungsleiter, der auch der Hauptentwickler ist.
- Die Qualitätssicherung hilft beim Testen von Änderungen, sucht nach neuen Wegen, um instabile Kommunikationsbedingungen zu schaffen, und meldet Probleme an vorderster Front.
- Der Analyst sucht ständig nach verschiedenen Zusammenhängen in technischen Daten, verbessert die Analyse des Benutzerfeedbacks und überprüft die Ergebnisse von Experimenten.
- Der Produktmanager hilft bei der Gesamtleitung und Zuweisung von Ressourcen für Experimente.
- Ein zweiter Entwickler hilft oft bei der Programmierung und den damit verbundenen Aufgaben.
Zunächst haben wir eine relativ zuverlässige Metrik erstellt, die Änderungen in der Bewertung der Kommunikationsqualität (Durchschnitt über Tage, Wochen, Monate) verfolgt. Damals handelte es sich dabei um Noten von Lehrern, später kamen noch Noten von Schülern hinzu. Dann begannen sie, Hypothesen darüber aufzustellen, was falsch funktionierte, diese zu korrigieren und Veränderungen in der Dynamik zu untersuchen. Wir haben uns für die niedrig hängende Frucht entschieden: Wir haben zum Beispiel den vp8-Codec durch vp9 ersetzt, die Leistung hat sich verbessert. Wir haben versucht, mit den Janus-Einstellungen zu spielen und andere Experimente durchzuführen – in den meisten Fällen führten sie zu nichts.
Im zweiten Schritt entstand eine Hypothese: WebRTC ist eine Peer-to-Peer-Lösung und wir verwenden einen Server in der Mitte. Vielleicht liegt hier das Problem? Wir begannen zu graben und fanden die bislang bedeutendste Verbesserung.
In diesem Moment wurde ein Server aus dem Pool mithilfe eines ziemlich dummen Algorithmus ausgewählt: Jeder hatte sein eigenes „Gewicht“, abhängig vom Kanal und der Leistung, und wir versuchten, den Benutzer zu dem Server mit dem größten „Gewicht“ ohne zu schicken Achten Sie darauf, wo sich der Benutzer geografisch befindet. Dadurch konnte ein Lehrer aus St. Petersburg mit einem Schüler aus Sibirien über Moskau kommunizieren und nicht über unseren Janus-Server in St. Petersburg.
Der Algorithmus wurde überarbeitet: Wenn ein Benutzer jetzt unsere Plattform öffnet, sammeln wir Pings von ihm an alle Server, die Ajax verwenden. Beim Verbindungsaufbau wählen wir das Ping-Paar (Lehrer-Server und Schüler-Server) mit der geringsten Menge aus. Weniger Ping bedeutet weniger Netzwerkentfernung zum Server; Eine kürzere Entfernung bedeutet eine geringere Wahrscheinlichkeit, dass Pakete verloren gehen. Paketverlust ist der größte negative Faktor bei der Videokommunikation. Der Anteil der Negativität sank innerhalb von drei Monaten um die Hälfte (um fair zu sein, zu dieser Zeit wurden auch andere Experimente durchgeführt, aber dieses hatte mit ziemlicher Sicherheit die größte Wirkung).
Wir haben kürzlich noch eine weitere nicht offensichtliche, aber scheinbar wichtige Sache entdeckt: Anstelle eines leistungsstarken Janus-Servers auf einem dicken Kanal ist es besser, zwei einfachere Server mit geringerer Bandbreite zu haben. Dies wurde deutlich, nachdem wir leistungsstarke Maschinen gekauft hatten, in der Hoffnung, möglichst viele Räume (Kommunikationssitzungen) gleichzeitig unterzubringen. Server haben eine Bandbreitenbegrenzung, die wir genau in die Anzahl der Räume umrechnen können – wir wissen, wie viele beispielsweise bei 300 Mbit/s geöffnet werden können. Sobald auf einem Server zu viele Räume geöffnet sind, wählen wir ihn nicht mehr für neue Aktivitäten aus, bis die Auslastung nachlässt. Die Idee war, dass wir nach dem Kauf einer leistungsstarken Maschine den Kanal maximal auslasten würden, sodass er am Ende durch den Prozessor und den Speicher und nicht durch die Bandbreite begrenzt wäre. Es stellte sich jedoch heraus, dass nach einer bestimmten Anzahl offener Räume (420) trotz der Tatsache, dass die Belastung des Prozessors, des Speichers und der Festplatte immer noch weit von den Grenzen entfernt ist, Negativität beim technischen Support Einzug hält. Anscheinend wird bei Janus etwas schlimmer, vielleicht gibt es auch dort Einschränkungen. Wir begannen zu experimentieren, senkten die Bandbreitenbegrenzung von 300 auf 200 Mbit/s und die Probleme verschwanden. Jetzt haben wir gleich drei neue Server mit niedrigen Limits und Eigenschaften gekauft und gehen davon aus, dass dies zu einer stabilen Verbesserung der Kommunikationsqualität führen wird. Natürlich haben wir nicht versucht herauszufinden, was dort vor sich ging; unsere Krücken sind alles. Nehmen wir zu unserer Verteidigung an, dass es in diesem Moment darum ging, das drängende Problem so schnell wie möglich zu lösen und nicht, es schön zu machen; Außerdem ist Janus für uns eine in C geschriebene Blackbox, es ist sehr teuer, daran herumzubasteln.
Nun, dabei haben wir:
- alle Abhängigkeiten aktualisiert, die aktualisiert werden konnten, sowohl auf dem Server als auch auf dem Client (dies waren ebenfalls Experimente, wir haben die Ergebnisse überwacht);
- alle identifizierten Fehler im Zusammenhang mit bestimmten Fällen behoben, z. B. wenn die Verbindung unterbrochen und nicht automatisch wiederhergestellt wurde;
- Wir haben viele Treffen mit Unternehmen abgehalten, die im Bereich der Videokommunikation tätig sind und mit unseren Problemen vertraut sind: Spiele streamen, Webinare organisieren; wir haben alles versucht, was uns nützlich erschien;
- Durchführung einer technischen Überprüfung der Hardware und Kommunikationsqualität der Lehrer, von denen die meisten Beschwerden eingingen.
Durch die Experimente und anschließenden Änderungen konnte die Unzufriedenheit mit der Kommunikation unter Lehrern von 7,1 % im Januar 2018 auf 2,5 % im Januar 2019 gesenkt werden.
Was weiter
Die Stabilisierung unserer Vimbox-Plattform ist eines der Hauptprojekte des Unternehmens für 2019. Wir haben große Hoffnungen, dass wir den Schwung beibehalten und Videokommunikation nicht mehr in den Top-Beschwerden sehen können. Wir verstehen, dass ein erheblicher Teil dieser Beschwerden mit Verzögerungen bei den Computern und dem Internet der Benutzer zusammenhängt, aber wir müssen diesen Teil ermitteln und den Rest lösen. Alles andere ist ein technisches Problem, wir sollten damit wohl zurechtkommen.
Die Hauptschwierigkeit besteht darin, dass wir nicht wissen, bis zu welchem Grad es tatsächlich möglich ist, die Qualität zu verbessern. Die Ermittlung dieser Obergrenze ist die Hauptaufgabe. Daher waren zwei Experimente geplant:
- Vergleichen Sie Videos über Janus mit normalem P2P unter Kampfbedingungen. Dieses Experiment wurde bereits durchgeführt, es wurde kein statistisch signifikanter Unterschied zwischen unserer Lösung und p2p festgestellt;
- Lassen Sie uns (teure) Dienstleistungen von Unternehmen anbieten, die ausschließlich mit Videokommunikationslösungen Geld verdienen, und das Ausmaß der Negativität von ihnen mit der bestehenden vergleichen.
Diese beiden Experimente werden es uns ermöglichen, ein erreichbares Ziel zu identifizieren und uns darauf zu konzentrieren.
Darüber hinaus gibt es eine Reihe von Aufgaben, die routinemäßig gelöst werden können:
- Wir erstellen eine technische Messgröße für die Kommunikationsqualität anstelle subjektiver Bewertungen.
- Wir erstellen detailliertere Sitzungsprotokolle, um die auftretenden Fehler genauer zu analysieren, zu verstehen, wann und wo genau sie aufgetreten sind und welche scheinbar unabhängigen Ereignisse zu diesem Zeitpunkt stattgefunden haben;
- Wir bereiten vor dem Unterricht einen automatischen Verbindungsqualitätstest vor und geben dem Kunden auch die Möglichkeit, die Verbindung manuell zu testen, um die durch seine Hardware und seinen Kanal verursachte Negativität zu reduzieren;
- Wir werden weitere Lasttests für die Videokommunikation unter schlechten Bedingungen, mit variablem Paketverlust usw. entwickeln und durchführen;
- Wir ändern das Verhalten von Servern bei Problemen, um die Fehlertoleranz zu erhöhen.
- Wir warnen den Benutzer, wenn mit seiner Verbindung überhaupt etwas nicht stimmt, wie es bei Skype der Fall ist, damit er versteht, dass das Problem auf seiner Seite liegt.
Seit April ist die Videokommunikationsleitung zu einem vollwertigen separaten Projekt innerhalb von Skyeng geworden, das sich um ein eigenes Produkt kümmert und nicht nur um einen Teil von Vimbox. Das bedeutet, dass wir anfangen, nach Leuten zu suchen . Na ja, wie immer .
Und natürlich kommunizieren wir weiterhin aktiv mit Menschen und Unternehmen, die mit Videokommunikation arbeiten. Wenn Sie mit uns Erfahrungen austauschen möchten, freuen wir uns! Kommentieren Sie, nehmen Sie Kontakt auf – wir werden jedem antworten.
Source: habr.com