Es ist sehr praktisch und effizient, verschiedene \u00dcbertragungen f\u00fcr ein gro\u00dfes Publikum zu organisieren, da Segmente einmal auf einem CDN geladen werden k\u00f6nnen.<\/li>\n<\/ul>\n\nTrotz der Einfachheit des Engines l\u00e4uft nicht alles so glatt, wie es scheint. Das Hauptproblem ist, dass Entwickler von Drittanbieter-Playern von den Empfehlungen von Apple abgewichen sind, insbesondere in Bezug auf unterst\u00fctzte Audioformate. Insbesondere haben viele Entwickler begonnen, die M\u00f6glichkeit zu integrieren, mit g\u00e4ngigen Audio-Streams zu arbeiten: mpeg2 Video, mpeg2 Audio usw. Infolgedessen mussten verschiedene Playlist-Formate f\u00fcr verschiedene Player erstellt werden.<\/p>\n
Aber eines der gr\u00f6\u00dften Probleme des HLS-Engines ist die hohe Latenz bei der Daten\u00fcbertragung.<\/p>\n
Urspr\u00fcnge der Verz\u00f6gerungen<\/h2>\n \nDer Hauptgrund f\u00fcr die hohe Latenz bei HLS liegt darin, dass Programmierer die Engine f\u00fcr die Erzielung maximaler Bildqualit\u00e4t entwickelt haben. Daher sind die Parameter des verwendeten Intervallrahmens und das Volumen des Wiedergabepuffers einfach nicht geeignet f\u00fcr Live-Video\u00fcbertragungen. Dies f\u00fchrt zu einer relativ hohen Verz\u00f6gerung bei der \u00dcbertragung des Videostreams, die 5-7 Sekunden betragen kann.<\/p>\n
Einerseits ist das wenig, beispielsweise f\u00fcr diejenigen, die einen Film von einem Video-Hosting-Server anschauen. Aber f\u00fcr \u00dcberwachungssysteme kann die Verz\u00f6gerung bei der \u00dcbertragung des Videostreams von gro\u00dfer Bedeutung sein.<\/p>\n
Wenn Sie ein B\u00fcro \u00fcberwachen, in dem Mitarbeiter sich einmal pro Stunde von den Monitoren abwenden, z\u00e4hlt die Verz\u00f6gerung von 5 Sekunden nicht. Aber die Menschen begannen sich zu beschweren, dass zum Beispiel beim \u00dcbertragen eines Fu\u00dfballspiels im Chat bereits GOOOOOL geschrieben wurde, das Video dies aber noch nicht zeigt :). Wir haben bereits eine Reihe von Benutzerf\u00e4llen, in denen Ivideon Skype praktisch ersetzen muss.<\/p>\n
Kann man die Latenz bei HLS \u00fcberwinden? Die Antwort auf diese Frage klingt wie die Rede eines erfahrenen Rattenf\u00e4ngers bei einer Vorlesung vor angehenden Sch\u00e4dlingsbek\u00e4mpfern: \u201eRatten kann man nicht ausrotten, aber ihre Anzahl kann auf ein vern\u00fcnftiges Minimum reduziert werden.\u201c So ist es auch mit der Latenz bei HLS, sie auf null zu bringen, ist nicht m\u00f6glich, aber es gibt L\u00f6sungen auf dem Markt, die die Latenz erheblich reduzieren k\u00f6nnen.<\/p>\n
Kleine Segmentierung<\/h2>\n \nEin weiteres Problem der Engine ist die Verwendung von kleinen Dateien zur Daten\u00fcbertragung. Es scheint, als w\u00e4re daran nichts Schlechtes?<\/p>\n
Jeder, der versucht hat, eine gro\u00dfe Anzahl kleiner Dateien von einem Datentr\u00e4ger auf einen anderen zu kopieren, hat sicherlich bemerkt, dass die Schreibgeschwindigkeit eines solchen Sets deutlich niedriger ist als die eines gro\u00dfen Files mit demselben Volumen. Zudem erh\u00f6ht sich die Intensit\u00e4t der Zugriffe auf die Festplatte erheblich, was sich insgesamt negativ auf die Leistung des Computers auswirkt. Daher tr\u00e4gt die \u00dcbertragung von Videodaten in Form kleiner 10-Sekunden-Fragmente ebenfalls zur erh\u00f6hten Verz\u00f6gerung des Engines bei.<\/p>\n
Fassen wir die Vor- und Nachteile der HLS-Technologie kurz zusammen.<\/p>\n
Vorteile von HLS:<\/b><\/p>\n\nKompatibilit\u00e4t mit allen Ger\u00e4ten. Sie k\u00f6nnen Videos auf jedem modernen Ger\u00e4t ansehen, sei es ein Smartphone, Tablet, Laptop oder Desktop-PC. Wichtig ist, dass der Webbrowser eine moderne Version ist und mit HTML5 und Media Source Extensions kompatibel ist.<\/li>\n Hervorragende Bildqualit\u00e4t. Die verwendete Funktion zur adaptiven Daten\u00fcbertragung erm\u00f6glicht es, die Qualit\u00e4t des \u00fcbertragenen Videoinhalts dynamisch in Abh\u00e4ngigkeit von der Bandbreite der Internetverbindung zu \u00e4ndern, wobei der Algorithmus bestrebt ist, die Qualit\u00e4t maximal zu erhalten.<\/li>\n Keine Notwendigkeit f\u00fcr komplizierte Benutzereinstellungen.<\/li>\n<\/ol>\n\nNachteile:<\/b><\/p>\n\nEingeschr\u00e4nkte Unterst\u00fctzung der Engine auf einigen Ger\u00e4ten.<\/li>\n Hohe Verz\u00f6gerungen bei der Bild\u00fcbertragung.<\/li>\n Stark erh\u00f6hte Overheadkosten und schwierige Optimierung aufgrund der Verwendung kleiner Dateien. Aufgrund der Eigenschaften des Containers werden wir niemals eine Verz\u00f6gerung von weniger als der Segmentgr\u00f6\u00dfe erreichen k\u00f6nnen.<\/li>\n<\/ol>\n\nDie Nachteile von HLS haben f\u00fcr uns \u00fcberwogen und uns dazu gebracht, nach alternativen Optionen zu suchen.<\/p>\n
Was ist WebRTC<\/h2>\n \nc<\/noindex>)<\/p>\nDie WebRTC-Plattform wurde 2011 von Google entwickelt, um Video- und Audiodaten zwischen Browsern und mobilen Anwendungen mit minimaler Verz\u00f6gerung zu \u00fcbertragen. Hierf\u00fcr wird das Standardprotokoll UDP und spezielle Flusskontrollalgorithmen verwendet. Heute handelt es sich um ein Open-Source-Projekt, das aktiv von Google unterst\u00fctzt und weiterentwickelt wird.<\/p>\n
WebRTC ist ein Technologiesatz f\u00fcr die Peer-to-Peer-\u00dcbertragung von Video und Audio. Das bedeutet, dass beispielsweise Benutzersbrowser mit Hilfe von WebRTC Daten direkt untereinander austauschen k\u00f6nnen, ohne entfernte Server zur Speicherung und Verarbeitung der Daten zu verwenden. Alle Informationen werden ebenfalls von den Browsern und mobilen Anwendungen der Endbenutzer verarbeitet.<\/p>\n
Die Benutzerfreundlichkeit und die umfangreichen M\u00f6glichkeiten dieser Technologie haben die Entwickler aller g\u00e4ngigen Browser \u00fcberzeugt. Heute wird WebRTC in Mozilla Firefox, Opera, Google Chrome (und in allen auf Chromium basierenden Browsern) sowie in mobilen Anwendungen f\u00fcr Android und iOS unterst\u00fctzt.<\/p>\n
Trotz ihrer unbestreitbaren Vorteile hat WebRTC einige wesentliche Nachteile. <\/p>\n
Schwierigkeiten bei der Auswahl<\/h2>\n \nDie WebRTC-Technologie ist aufgrund ihrer P2P-Natur viel komplexer im Hinblick auf Netzinteraktionen. Sie ist schwer zu debuggen und zu testen und kann sich unvorhersehbar verhalten. Gleichzeitig m\u00fcssen wir NAT und Firewalls \u00fcberwinden und sicherstellen, dass sie in Netzwerken funktioniert, in denen UDP blockiert ist.<\/p>\n
Es ist sehr schwierig, die WebRTC-Implementierung von Google zu verwenden. Es gibt sogar ein ganzes Unternehmen, das Dienstleistungen zur Zusammenstellung von SDKs anbietet. Au\u00dferdem war es sehr schwierig, die Implementierung von Google in unser System zu integrieren, ohne dabei das gesamte Video neu zu kodieren.<\/p>\n
Wir wollten unseren Benutzern schon lange die M\u00f6glichkeit geben, mit echtem \"Live\"-Videomaterial zu arbeiten und die Verz\u00f6gerung des Bildes auf dem Bildschirm im Verh\u00e4ltnis zu den Ereignissen zu minimieren. Au\u00dferdem wollten wir die Nutzung von PTZ-Kameras komfortabler gestalten, wo Verz\u00f6gerungen von entscheidender Bedeutung sind.<\/p>\n
Angesichts der Tatsache, dass andere Implementierungen zur Bek\u00e4mpfung von Lags derzeit eingeschr\u00e4nkte Funktionen haben und erheblich schlechter funktionieren, haben wir uns entschieden, WebRTC zu nutzen. <\/p>\n
Was wir getan haben<\/h2>\n \n
F\u00fcr das ordnungsgem\u00e4\u00dfe Funktionieren von WebRTC ist es in erster Linie erforderlich, den technologischen Stack f\u00fcr die Verarbeitung von Webvideos zu modernisieren. Das haben wir auch getan.<\/p>\n
Zun\u00e4chst haben wir einen WebRTC-Signalprotokollserver \u00fcber Websocket implementiert und einen WebRTC-Peer-Server in der Cloud basierend auf dem SDK webrtc.org eingerichtet. Seine Aufgabe ist es, Videostreams an die Client-WebRTC-Peers im H.264 + Opus\/G.711-Format ohne Video-Rekodierung auszugeben.<\/p>\n
Wir haben Websocket als Signalprotokoll gew\u00e4hlt, weil es bereits qualitativ hochwertige Unterst\u00fctzung in allen g\u00e4ngigen Webbrowsern bietet. Dadurch k\u00f6nnen sowohl die Entwicklungskosten erheblich gesenkt als auch Zeit und Ressourcen f\u00fcr wiederholte TCP- und TLS-Handshake im Vergleich zu AJAX eingespart werden.<\/p>\n
Das Problem ist, dass WebRTC standardm\u00e4\u00dfig kein Signalprotokoll bereitstellt, das f\u00fcr die korrekte Einrichtung, Unterst\u00fctzung und Beendigung von Echtzeit-Videokommunikation zwischen Quell- und Client-Anwendungen erforderlich ist.<\/p>\n
Um die Signaltechnologie selbst zu implementieren, mussten wir unseren eigenen Signalsserver mit Unterst\u00fctzung f\u00fcr mehrere Webprotokolle (Websocket, WebRTC) entwickeln. Au\u00dferdem sollte er die sichere Verwaltung von Sitzungen und Benachrichtigungen in Echtzeit, die Verwaltung von Videos und viele andere Parameter erm\u00f6glichen.<\/p>\n
Wir haben die P2P-Einschr\u00e4nkungen \u00fcberwunden, indem wir die Latenz nicht durch P2P, sondern durch UDP und ein auf die Verringerung der Latenz ausgelegtes Flussmanagement verringert haben. Dies ist ebenfalls in WebRTC enthalten, da der Hauptanwendungsfall P2P-Gespr\u00e4che \u00fcber den Browser sind.<\/p>\n
In der mobilen App haben wir einen Player mit dem SDK webrtc.org implementiert, da dort das Stream-Management korrekt umgesetzt ist, alle g\u00e4ngigen Forward Error Correction (FEC)-Schemata verf\u00fcgbar sind und der Mechanismus f\u00fcr die erneute Paket\u00fcbertragung f\u00fcr alle Browser richtig implementiert ist. Ein weiterer wichtiger Punkt ist, dass das SDK webrtc.org aktiv von Google weiterentwickelt wird.<\/p>\n
Was ist das Ergebnis der Einf\u00fchrung von WebRTC?<\/h2>\n \n
![\"WebRTC](\"\/wp-content\/uploads\/2019\/04\/d185b546f5fc4c15021481c0cc2fedbd.jpeg\")