Web Streaming

Es gibt verschiedene Kanäle eines Video-Streams. Voraussetzung ist nun, dass der Videostream zum Zeitpunkt des Drehbeginns der Station (Punkt 1) fortlaufend auf die Bühne gesendet wird. Dies wirft bereits die erste Fragestellung auf: Wie soll der Strom gepackt und übermittelt werden? An der Plattformseite (Punkt 2) stellt sich die erste Frage: Wie soll der Strom empfangen werden?

Soll der Datenstrom zu einem beliebigen Termin zur VerfÃ?gung stehen, muss geklärt werden, wie der Datenstrom als abrufbares Videofile abgespeichert werden kann. Als nächstes (Punkt 3) soll der Strom auf die Receiver verteilt werden. Wie soll der Strom gepackt und übermittelt werden?

Wie erreichen Sie die Adressaten? Nicht zuletzt muss der Videostream am Receiver wiedergegeben werden (Punkt 4). An dieser Stelle muss die Antwort auf die Fragen gegeben werden, wie ein solcher Strom auf allen gängigen Receivern (Smartphones, Tabletts, Heimcomputern etc.) dargestellt werden kann. Der Transfer und die Aufbereitung des Stroms braucht Zeit. Der Grundgedanke für das Versenden des Videostreams ist, dass, nachdem der Strom geströmt ist, der Strom in Paketen an die Platform geschickt wird - im Diagramm durch die gruenen Pakete wiedergegeben.

Das heißt ganz praktisch, dass der Transmitter alle 2 Sek. ein Paket an die Bühne schickt, das z.B. 2 Sek. Filmaufnahmen enthält. Solche Spezialpakete werden als "Video-Brocken" bezeichnet. Sie werden über HTTP an die Platform geschickt und dort über eine REST-Schnittstelle empfangen. Zusätzliche Metainformationen können natürlich in den Chunk übernommen werden.

Bei einem Smartphone als Transmitter können z.B. noch Breiten- und Längengrade übertragen werden, so dass die Receiver auf einer Landkarte dargestellt werden können, auf der jemand gerade Live-Streaming betreibt. Man konnte es auch sehen, wenn sich der Wimpel bewegte. Natürlich können die Stücke auch auf andere Weise empfangen werden. Die Stücke können auf der Bühne direkt auf die Receiver aufgeteilt oder abgespeichert werden.

Der Speicher bringt den Vorzug, dass der Datenstrom auch später als "on demand" Videomaterial geliefert werden kann. Auf diese Weise können die Betrachter das Videomaterial zu einem beliebigen Termin ansehen. Im Idealfall würden Sie in diesem Falle die Videoblöcke nach Abschluss des Stroms zu einer einzigen Datei mischen. Natürlich kann vor jeder Lieferung des aktuellen Films ein Werbesong verschickt werden.

Die Blöcke werden dann über WebSocket-Kanäle von der Bühne zu den Empfängern gesendet. Hier wird der Datenstrom dann im Web-Browser des Receivers zum HTML5-Videoelement geroutet und dort angezeigt. Dabei wird eine REST-Schnittstelle verwendet, um die Videoblöcke und ggf. die Metainformationen zu empfangen. Der Absender bucht die Blöcke in unserem Falle über HTTP an die Resource (siehe Abb.3).

WebSocket werden für die Distribution von Brocken eingesetzt. Bei WebSocket kann eine permanente Verbindung zwischen der Bühne und dem entsprechenden Receiver hergestellt werden. Bei der bidirektionalen Übertragung können beide Seiten genutzt werden. So erhalten Sie eine indirekte Chat-Funktionalität, denn der Adressat kann auch etwas in Fahrtrichtung der Bühne senden, die dann diese Botschaft an alle weiterleitet.

So kann die Handelsplattform ein Stück sofort nach dem Eintreffen des neuen Stücks versenden. Die WebSocket-Verbindung wird über HTTP hergestellt und beibehalten. Das Ergebnis ist eine auf HTTP basierende Kommunikations-Kette vom Absender zum Empfänger. 2. Das DASH steht für Dynamic Adaptive Streaming über HTTP und bietet die Antwort auf die Frage, wie die Blöcke gepackt und dargestellt werden können.

Die Ausgabe ist ein HTTP-Server, von dem eine Bilddatei an einen bestimmten Adressaten gesendet werden soll. Das File Low. MP3 stellt das Videomaterial in einer nicht so hohen Auflösung dar, das File Media. MP3 in einer höheren Auflösung und das File am besten. MP3 in einer sehr hohen Auflösung. Mit zunehmender Güte wird die Datenmenge erhöht und es müssen mehr Informationen an den Adressaten übermittelt werden.

Dieser Film wird nun über das Netz zum Adressaten gesendet. Mittlerweile verändert sich die Bandweite immer wieder, d.h. manchmal können schnellere, manchmal langsamere Übertragungen durchgeführt werden. MPEG DASH erlaubt dem Receiver nun, das Bild abhängig von der Bandweite zu sehen. Die Zielsetzung ist, dass der Receiver auch bei wechselnder Bandweite ein kontinuierliches Bild ohne Unterbrechungen wiedergeben kann.

Exakt dieser Grundsatz wird "Dynamic adaptives Streaming" genannt. Dabei sind es exakt diese Abschnitte, die an die hier präsentierte Bühne geschickt werden. Das Betrachten eines MPEG-DASH-Videostroms ist besonders leicht, da das HTML5-Videoelement ihn unmittelbar abspielt. So können Medienströme unmittelbar im Videoelement wiedergegeben werden. Der Zweck dieses Beitrags ist der Aufbau einer Live Video Streaming Platform, so dass die Implementierung der Platform und die Darstellung der Ströme im Anschluss diskutiert werden.

Für einen Schnelltest kann auch ein normaler Videoclip verwendet werden, der dann aber MPEG-DASH-kompatibel gemacht werden muss, d.h. der korrekte Videocontainer, das Segmentieren, Splitten usw. muss gemacht werden. Anschließend sollte das Videomaterial in Einzeldateien aufgeteilt werden, die dann nacheinander an die REST-Schnittstelle geschickt werden können.

Auflistung 1 gibt an, wie eine solche Oberfläche aufgebaut werden kann, um Videoblöcke und Metainformationen zu empfangen. Es wird der URI /video gesetzt, an den dann der POST-Request gesendet wird. ý privates Event ChunkEvent; Im Beispiel wird ein CDI-Ereignis angegeben, das ausgelöst wird, wenn ein Videochunk eintrifft. Das mit @Post kommentierte Verfahren ist für den Empfang von Blöcken verantwortlich.

copy (chunk, Paths. get(PATH_STORE_VIDEOS+Dateiname) ); Um den Chunk für den späteren Einsatz zu speichern, wird dies hier gemacht. clunkEvent. fire(buf); Schließlich wird das Ereignis ausgelöst, um zu melden, dass ein neues Stück da ist. Im Listing 2 wird die Implementation des WebSocket Endpoints dargestellt, der die Brocken an die Receiver weiterleitet und die Chatnachrichten der Absender empfängt und auch weiterleitet. ý Privates statisches Finale Set Sessions = Collect.

synchronizedSet (new HashSet()); sitzungen. add(session); session.getBasicRemote(). sendBinary(buffer); ex. printStackTrace(); s.getBasicRemote(). sendObject(message); ex. printStackTrace(); Die WebSocks werden verwendet, um Klumpen zu verbreiten und um Chat-Nachrichten zu übertragen. Damit wird der WebSocket-Endpunkt festgelegt, mit dem sich ein Receiver anschließen kann. NachrichtEncoder und NachrichtDecoder werden lediglich verwendet, um Chat-Nachrichten in JSON-Objekte umzuwandeln. Privates statisches Finale Set Sitzungen = Sammlungen. synchroneSet (neues HashSet()); In diesem Satz werden alle Sitzungen der Receiver statt.

D. h. sobald sich ein anderer Receiver mit dem WebSockel verbunden hat, wird die Sitzung des Receivers notiert, um ihn später unmittelbar erreichen zu können. session.getBasicRemote(). sendBinary(buffer); ex. printStackTrace(); Dies ist tatsächlich der interessanteste Ort. Gelangt ein Stück auf die Bühne, wird das CDI-Ereignis ausgelöst. Dieses Verfahren erfasst das Ereignis und liefert den Klumpen.

Es werden alle WebSocket-Sitzungen ausgeführt, der Verweis auf den WebSocket-Endpunkt des Anwenders abgerufen und die Chunk- oder Binärdaten an den Anwender geschickt. Dieser BytePuffer kann ganz normal an die sendBinary-Methode s.: s.getBasicRemote(). sendObject(message); ex. printStackTrace(); Die mit @onMessage kommentierte Funktion wird ausgeführt, wenn ein Client eine Message erhält und diese Message an alle Adressaten ausgibt.

Listing 3 enthält den JavaScript-Teil, der zur Weiterleitung des Stroms an das Videoelement benötigt wird. ýVar video = Dokument. querySelector('video'); Var queue= [ ]; var Puffer; var mediaSource = new MediaSource(); Video. play(); Puffer = mediaSource.addSourceBuffer('video/mp4;codecs="avc1.64001f,mp4a.40 puffer.appendBuffer(queue. shift()) ; }) ; }) ; videoclip. src = window.URL. createObjectURL (mediaSource); Auf das HTML-Element mit der ID des Videos kann über den Skriptcode zugegriffen werden. ýVAR-Video = Dokument. querySelector('video'); Dies liefert einen Verweis auf das Video-Tag. ýVAR-Queue[]; var-Puffer; Die Blöcke werden in der Warteschlange abgelegt, die nach und nach rollen.

Wenn das Ereignis quelloffen, das erste Stück, eintrifft, wird das Videotag in den Wiedergabemodus umgeschaltet.

Das Videoformat und der Codec enthalten auch den Quellpuffer, d.h. den Speicher des MediaSource-Objekts, das die Mediadaten bereitstellt. Geblieben ist der Empfang der Stücke und das Füllen der Warteschlange mit ihnen. Auflistung 4 gibt an, welcher Client-seitige WebSocket-Endpunkt empfangen werden soll. var webSocket = new WebSocket('ws://localhost:: 8080/streamup/stream'); webSocket. binärType ='arraybuffer'; console. log('video chunk arrived'); queue.push(event. auf Anfrage).

binärType gibt den Datentyp der von der Leitung übertragenen Binary-Daten an. Hierbei werden ArrayBuffer-Objekte benutzt, d.h. solche, die von der Platform geschickt werden. queue.push(event. data); buffer.appendBuffer(event. data); console. log(e); writeResponse(event. data); }}; Wenn der Puffer aktualisiert wird oder sich noch ein Chunk in der Queue befindet, werden neue Brocken in die Queue eingefügt.

Bei leerer Druckerwarteschlange und rezeptivem Puffer wird der Klumpen unmittelbar in den Puffer übernommen. Die Quellpuffer warten auf ein Update-Ereignis und sobald es getriggert wird, erhält das Video-Element den nächstfolgenden Teil aus der Warteschleife. Damit sind die für die Produktion einer solchen Platform notwendigen Codepassagen bereits erledigt.

Das Bild gibt einen Schnappschuss des Prototyps mit zwei sich im Chatten austauschenden Receivern und einem Videostream wieder, der inzwischen von einem Transmitter gesendet wird. Für die Darstellung des Stroms wurde eine Video-Datei im MPEG-DASH-Stil benutzt, die Stück für Stück gesendet wird. MPEG-DASH, HTML5 mpeg-dash, html5 und WebSockel Eine REST-Schnittstelle wurde für den Empfang des Datenstroms benutzt, aber dies ist fakultativ.

Im Produktionsumfeld wäre nur die Übermittlung von Metainformationen an die REST-Schnittstelle und die der Blöcke auf andere Weise vorstellbar. Zum Beispiel, was muss geschehen, wenn ein Luftschlange im Fahrzeug ist und das Handy die Funkzelle austauscht? Sonst kommen die Stücke nicht in der korrekten Ordnung an? Dies und viele weitere Fragestellungen müssen für den fachgerechten Einsatz einer solchen Handelsplattform geklärt werden.