es ist sehr praktisch und effizient, verschiedene \u00dcbertragungen f\u00fcr ein gro\u00dfes Publikum zu organisieren, da Segmente einmal auf das CDN hochgeladen werden k\u00f6nnen.<\/li>\n<\/ul>\n\nObwohl der Engine recht einfach ist, gibt es einige Herausforderungen, die nicht so glatt verlaufen, wie es scheint. Das Hauptproblem besteht darin, dass die Entwickler von Drittanbietermedienplayern von den Empfehlungen von Apple abgewichen sind, insbesondere bez\u00fcglich der unterst\u00fctzten Audioformate. Viele Entwickler haben begonnen, die M\u00f6glichkeit zu integrieren, mit g\u00e4ngigen Audiostreams zu arbeiten: mpeg2 Video, mpeg2 Audio usw. Daher mussten verschiedene Playlist-Formate f\u00fcr unterschiedliche Player geschaffen werden.<\/p>\n
Eine der gr\u00f6\u00dften Herausforderungen des HLS-Engines ist jedoch die hohe Latenz bei der Daten\u00fcbertragung.<\/p>\n
Urspr\u00fcnge der 'Verz\u00f6gerung'<\/h2>\n \nDie Hauptursache f\u00fcr die hohe Latenz bei HLS liegt darin, dass Programmierer die Engine so entwickelt haben, dass sie die h\u00f6chstm\u00f6gliche Bildqualit\u00e4t erh\u00e4lt. Daher sind die Parameter des verwendeten Frame-Intervalls und das Volumen des Wiedergabepuffers einfach nicht f\u00fcr Live-\u00dcbertragungen geeignet. Dies f\u00fchrt zu einer erheblichen Verz\u00f6gerung bei der \u00dcbertragung des Videostreams, die 5 bis 7 Sekunden betragen kann.<\/p>\n
Auf der einen Seite ist dies nicht viel, z.B. f\u00fcr diejenigen, die einen Film von einem Video-Hosting-Server ansehen. F\u00fcr \u00dcberwachungssysteme kann jedoch die Verz\u00f6gerung bei der \u00dcbertragung des Videostreams von gro\u00dfer Bedeutung sein.<\/p>\n
Wenn Sie ein B\u00fcro beobachten, in dem Mitarbeiter jede Stunde eine Pause von ihren Bildschirmen einlegen, spielt eine Verz\u00f6gerung von 5 Sekunden keine Rolle. Doch die Leute fangen an zu klagen, dass beispielsweise beim \u00dcbertragen eines Fu\u00dfballspiels im Chat bereits GOOOOOL geschrieben wurde, das Video jedoch noch nicht zeigt, was passiert ist. Wir haben bereits mehrere Anwendungsf\u00e4lle, in denen Ivideon praktisch Skype ersetzen muss.<\/p>\n
Kann man die Verz\u00f6gerung bei HLS besiegen? Die Antwort auf diese Frage klingt wie die Ansprache eines erfahrenen Kammerj\u00e4gers vor einer Gruppe von angehenden Rattenf\u00e4ngern: \u201eRatten kann man nicht vollst\u00e4ndig ausrotten, aber ihre Population auf ein vern\u00fcnftiges Minimum reduzieren.\u201c So ist es auch mit der Verz\u00f6gerung im HLS; sie auf null zu reduzieren, ist unm\u00f6glich, aber es gibt L\u00f6sungen auf dem Markt, die die Verz\u00f6gerung erheblich verringern k\u00f6nnen.<\/p>\n
Feines Timing<\/h2>\n \nEin weiterer Nachteil der Engine ist die Verwendung von kleinen Dateien zur Daten\u00fcbertragung. Was k\u00f6nnte daran schlecht sein?<\/p>\n
Jeder, der schon einmal versucht hat, eine gro\u00dfe Anzahl kleiner Dateien von einem Speichermedium auf ein anderes zu kopieren, hat sicherlich bemerkt, dass die Schreibgeschwindigkeit f\u00fcr solch eine Gruppe deutlich niedriger ist als die eines einzelnen gro\u00dfen Datei mit demselben Volumen. Zudem steigt die Intensit\u00e4t der Zugriffe auf die Festplatte erheblich, was sich insgesamt negativ auf die Leistung des gesamten Computers auswirkt. Daher tr\u00e4gt die \u00dcbertragung von Videodaten in Form kleiner, 10-sek\u00fcndiger Fragmente ebenfalls zur erh\u00f6hten Verz\u00f6gerung des Systems bei.<\/p>\n
Lassen Sie uns die Vor- und Nachteile der HLS-Technologie kurz zusammenfassen.<\/p>\n
Vorteile von HLS:<\/b><\/p>\n\nKompatibilit\u00e4t mit s\u00e4mtlichen 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 aktuelle Version hat und mit HTML5 sowie den Media Source Extensions kompatibel ist.<\/li>\n Hervorragende Bildqualit\u00e4t. Die verwendete Funktion der adaptiven Daten\u00fcbertragung erm\u00f6glicht es, die Qualit\u00e4t des \u00fcbertragenen Videostreams dynamisch je nach Bandbreite der Internetverbindung anzupassen. Dabei strebt der Algorithmus an, die Qualit\u00e4t maximal zu halten.<\/li>\n Es ist keine komplexe Benutzerhardware-Konfiguration erforderlich.<\/li>\n<\/ol>\n\nNachteile:<\/b><\/p>\n\nEingeschr\u00e4nkte Unterst\u00fctzung f\u00fcr den Betrieb mit bestimmten Ger\u00e4ten.<\/li>\n Hohe Latenzen bei der Bild\u00fcbertragung.<\/li>\n Signifikante Erh\u00f6hung des Overheads und schwierige Optimierung aufgrund der Verwendung kleiner Dateien. Wegen der Container-Eigenschaften k\u00f6nnen wir niemals eine Latenz unterhalb der Segmentgr\u00f6\u00dfe erreichen.<\/li>\n<\/ol>\n\nDie Nachteile von HLS haben f\u00fcr uns die Vorteile \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 mit minimaler Latenz zwischen Browsern und mobilen Anwendungen zu \u00fcbertragen. Daf\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 eine Technologie-Suite f\u00fcr die Peer-to-Peer-\u00dcbertragung von Audio und Video. Das bedeutet, Benutzerbrowser k\u00f6nnen mithilfe von WebRTC Daten direkt untereinander austauschen, ohne auf entfernte Server zur Speicherung und Verarbeitung zur\u00fcckgreifen zu m\u00fcssen. Alle Informationen werden zudem von den Browsern und mobilen Anwendungen der Endbenutzer verarbeitet.<\/p>\n
Die Benutzerfreundlichkeit und die umfangreichen M\u00f6glichkeiten dieser Technologie wurden von Entwicklern aller g\u00e4ngigen Browser gesch\u00e4tzt. Heute wird WebRTC in Mozilla Firefox, Opera, Google Chrome (und allen Chromium-basierten Browsern) sowie in mobilen Anwendungen f\u00fcr Android und iOS unterst\u00fctzt.<\/p>\n
Trotz ihrer unbestreitbaren Vorteile hat WebRTC auch einige wesentliche Nachteile. <\/p>\n
Herausforderungen bei der Auswahl<\/h2>\n \nDie WebRTC-Technologie ist viel komplexer in Bezug auf Netzwerkinteraktionen, da sie auf P2P basiert. Sie ist schwer zu debuggen und zu testen und kann unvorhersehbar agieren. Dabei m\u00fcssen wir NAT und Firewalls \u00fcberwinden und sicherstellen, dass sie in Netzwerken funktioniert, in denen UDP blockiert ist.<\/p>\n
Die Implementierung von WebRTC von Google ist sehr komplex. Es gibt sogar ein ganzes Unternehmen, das Dienstleistungen zur Erstellung von SDKs anbietet. Zudem war es sehr schwierig, die Google-Implementierung mit unserem System zu integrieren, ohne dabei das gesamte Video neu zu kodieren.<\/p>\n
Wir haben schon lange dar\u00fcber nachgedacht, unseren Nutzern die M\u00f6glichkeit zu geben, mit echtem \"Live\"-Videomaterial zu arbeiten und die Verz\u00f6gerung des Bildes auf dem Bildschirm im Vergleich zu den Ereignissen selbst zu minimieren. Dar\u00fcber hinaus wollten wir die Nutzung von PTZ-Kameras komfortabler gestalten, da Verz\u00f6gerungen hier von entscheidender Bedeutung sind.<\/p>\n
Angesichts der Tatsache, dass andere Ans\u00e4tze zur Bek\u00e4mpfung von Lags derzeit nur eingeschr\u00e4nkte Funktionalit\u00e4ten bieten und deutlich schlechter arbeiten, haben wir uns entschieden, WebRTC zu nutzen. <\/p>\n
Was wir getan haben<\/h2>\n \n
F\u00fcr das korrekte Funktionieren von WebRTC ist es in erster Linie erforderlich, den Technologie-Stack f\u00fcr die Arbeit mit Web-Videos zu modernisieren, was wir auch getan haben.<\/p>\n
Zun\u00e4chst haben wir einen WebRTC-Signalisierungsserver \u00fcber Websocket implementiert und einen WebRTC-Peer-Server in der Cloud auf Basis des SDK webrtc.org bereitgestellt. Dieser dient der Verteilung von Video-Streams an die Client-WebRTC-Peer im Format H.264 + Opus\/G.711, ohne dass das Video neu codiert werden muss.<\/p>\n
Wir haben Websocket als Signalisierungsprotokoll gew\u00e4hlt, da es bereits eine umfassende Unterst\u00fctzung in allen g\u00e4ngigen Webbrowsern bietet. Dadurch k\u00f6nnen die Entwicklungskosten erheblich gesenkt werden, und es ist nicht notwendig, Zeit und Ressourcen f\u00fcr wiederholte TCP- und TLS-Handshake-Vorg\u00e4nge im Vergleich zu AJAX aufzuwenden.<\/p>\n
Der Grund daf\u00fcr ist, dass WebRTC standardm\u00e4\u00dfig kein Signalisierungsprotokoll bereitstellt, das f\u00fcr die korrekte Einrichtung, Unterst\u00fctzung und Beendigung von Echtzeit-Videokommunikation zwischen den Quell- und Client-Anwendungen erforderlich ist.<\/p>\n
Um die Signalisierungstechnologie selbst zu implementieren, mussten wir unseren eigenen Signalisierungsserver mit Unterst\u00fctzung f\u00fcr mehrere Webprotokolle (Websocket, WebRTC) entwickeln. Au\u00dferdem sollte er in der Lage sein, Sitzungen sicher zu verwalten, Echtzeitbenachrichtigungen zu bearbeiten, Video zu steuern und viele andere Parameter zu verwalten.<\/p>\n
Wir haben die P2P-Einschr\u00e4nkungen \u00fcberwunden, indem wir die Latenz nicht durch P2P, sondern durch UDP und latenzreduzierendes Traffic-Management verringert haben. Dies ist auch in WebRTC integriert, da das Hauptanwendungsfeld p2p-Gespr\u00e4che \u00fcber den Browser ist.<\/p>\n
In der mobilen App haben wir einen Player mit dem SDK von webrtc.org implementiert, da nur dieses das Traffic-Management korrekt umsetzt, alle bekannten Forward Error Correction (FEC)-Methoden verwendet und den Mechanismus zur Wiederholung von Paketen f\u00fcr alle Browser richtig implementiert. Zudem ist es wichtig, dass das SDK von webrtc.org aktiv von Google weiterentwickelt wird.<\/p>\n
Was sind die Ergebnisse der Implementierung von WebRTC?<\/h2>\n \n
![\"WebRTC](\"\/wp-content\/uploads\/2019\/04\/d185b546f5fc4c15021481c0cc2fedbd.jpeg\")