-
Die Erfindung betrifft die Übertragung von digitalen Video- und Audiosignalen von einer Videosignalquelle über einen Server zu einer Wiedergabeeinrichtung, auf der die von der Videosignalquelle zur Verfügung gestellten Daten dargestellt werden.
-
Stand der Technik
-
Die Übertragung von Echtzeit Videodaten, auch Live-Streaming genannt, erfolgt in Netzwerken in der Regel über mehrere Zwischenstationen, angefangen von der Kamera über eine Aufbereitung oder Kodierungseinheit bei der Kamera bis zu einem Server, der die Weiterleitung an den Empfänger bzw. die Wiedergabeeinrichtung vornimmt. Die Wegstrecken in den Netzwerken können zu Verzögerungen in der Übertragung führen. Zusätzliche Verzögerungen ergeben sich durch medientechnisch erforderliche Eingriffe in den Datenstrom, die auf Basis aktueller Standards und Technologien erforderlich sind. Alle Verzögerungen im Netzwerk addieren sich zu einer Gesamtverzögerung.
-
Die Übertragung von Videodaten in höchstmöglicher Qualität ist eine hohe technische Herausforderung, bei der sich verschiedene Probleme ergeben, die zu einer eingeschränkten Bildqualität sowie zu verzögerten Darstellungen führen, die häufig im Bereich von mehreren Sekunden liegen.
-
Die Qualität der Übertragung ergibt sich einerseits aus der Bildqualität selbst, aber auch aus der Flüssigkeit der Wiedergabe. Die Bildqualität hängt mit der verfügbaren Bandbreite im Netzwerk zusammen, die Flüssigkeit mit der Bildrate, die in Bildern pro Sekunde oder Hz gemessen wird. Es ist mit bisherigen Verfahren nicht möglich, Videodaten in überall verfügbaren Netzwerken ohne Qualitätsverlust zu übertragen. Die Videodaten müssen komprimiert (encodiert) werden, um die verfügbare Bandbreite im Netzwerk nicht zu überschreiten. Um die Datenmenge des erzeugten Videosignals an die verfügbare Bandbreite anzupassen, sind verlustbehaftete Kompressionsverfahren erforderlich, die möglichst wenig sichtbare Fehler zulassen.
-
Die Verarbeitung und Kompression von Video- und Audiodaten geschieht in der Regel unabhängig voneinander in separaten Modulen.
-
Bei der Kompression von Videodaten werden hybride Verfahren verwendet, die eine stark schwankende Datenmenge pro Bild erzeugen durch die Verwendung unterschiedlicher Bildtypen (Keyframes = I-Frames, Differenzbilder = P/B-Frames). Die Zusammenfassung von Bildgruppen im Abstand der Keyframes bezeichnet man als „Group of pictures“ (GOP). Die GOP-Länge liegt häufig im Bereich von 1–10 Sekunden oder mehr. Je länger die GOP-Länge, desto besser ist die erzielte durchschnittliche Videoqualität, desto länger werden aber auch notwendige Bildpuffer.
-
Um Schwankungen der Datenrate des Encoders sowie der verfügbaren Netzwerkbandbreite ausgleichen zu können, werden Pufferspeicher eingesetzt, die die Schwankungen über bestimmte Zeitperioden ausgleichen sollen. Zusätzlich werden bei der Kompression lange Abstände von „Key-Frames“ (I-Frames) gewählt, die ebenfalls im Bereich von 2–10 Sekunden liegen. Durch Mehrfach-Pufferungen in allen beteiligten Komponenten (Sender, Server, Empfänger) entstehen häufig Pufferzeiten bzw. Latenzen von mehr als 30 Sekunden.
-
Für die Videokommunikation zwischen verschiedenen Teilnehmern ist eine wesentlich niedrigere Latenz erforderlich, insbesondere, wenn es sich um Signale handelt, die „Echtzeit“ nahe kommen sollen (z.B. Videokonferenz, Live-Events).
-
Paketierung / Multiplex
-
Das von der Videosignalquelle in einem Stream ausgegebene Signal wird in Pakete geteilt, Ein Paket kann Videodaten, Audiodaten oder beides enthalten (Multiplex).
-
Der Begriff Paket bezieht sich in diesem Zusammenhang auf das Zusammenfassen, Multiplexen von Video- und gegebenenfalls Audiodaten im Ausgabeformat, nicht auf die Größe von Paketen beim Netzwerktransport, die nachfolgend auf einer unteren Systemebene erfolgt. Die Betrachtung der Netzwerkschicht ist nicht Gegenstand dieser Einrichtung.
-
Streaming unterscheidet sich im Begriff üblicherweise im Anwendungsfall von Videokommunikation durch die Anzahl der Zuschauer. Streaming soll unabhängig von der Anzahl der Zuschauer möglich sein.
-
Bei dem Video-on-demand-Streaming, bei dem bestimmte vorgehaltene Videodaten abgerufen werden, spielt das Problem der oben genannten Latenzen keine Rolle, im Gegensatz zu dem Echtzeit-live-Streaming, mit dem sich die Erfindung befasst.
-
Beim Echtzeit-Live-Streaming wird das Material nicht vorproduziert, sondern in Echtzeit in der Gegenwart hergestellt. Quellen sind in der Regel Live-Kameras, entweder als separates Gerät oder eingebaut in einem Gerät (Mobilgerät, Laptop, Überwachungskamera, Action-Cam, stationär oder an mobilen Geräten montiert, usw.). Als Quelle kann aber auch ein künstlich erzeugtes Signal dienen, das nicht von einer Kamera kommen muss, z.B. für Präsentationen oder Spiele.
-
Für das Streaming gibt es bereits Protokolle und Standards.
-
RTMP (Realtime Messaging Protocol): Das Verfahren wurde von der Firma Adobe als Teil der „Flash“-Technologie erfunden und ist nicht offiziell standardisiert und mittlerweile veraltet. Es basiert auf einem kontinuierlichen Datenstrom, der von einem Server zu einem Client (Player) geschickt werden kann. Aktuelle Wiedergabegeräte sind nur mit Hilfe eines zusätzlichen Softwaremoduls („Flash-Plugin“) in der Lage, RTMP abzuspielen. Das „Flash-Plugin“ war viele Jahre Bestandteil von Browser-Anwendungen auf dem Schreibtisch („Desktop“) und wird ab voraussichtlich 2017 von keinem Browser mehr unterstützt. Auf mobilen Geräten und den meisten TVs und embedded devices wie IoT wird diese Technik nicht unterstützt.
-
http-Live-Streaming (HLS und DASH)
-
HLS wurde von Apple erfunden und basiert auf einer gepufferten Übertragung von Teilstücken des Livestreams. DASH ist ein ISO-Standard und basierte auf dem gleichen Prinzip. Die Teilstücke des Livestreams müssen eine bestimmte Mindestgröße haben, damit eine fehlerfreie Übertragung gewährleistet ist.
-
Streaming/Playback mit HTML5
-
HLS und DASH sind Teil des Standards „HTML5“, der von den meisten Browserherstellern unterstützt wird.
-
Mit HTML5 ist es möglich, Videodaten direkt auf einer Webseite einzubetten und so in multimedialen Umgebungen zu präsentieren. HTML erlaubt für die Einbettung von Videodaten nur bestimmte Videoformate und Protokolle. Stand der Technik bei HTML5 sind die Videokompressions-Verfahren ISO-MPEG4, ITU-H264 mit dem Dateiformat MP4 sowie das proprietäre, weniger verbreitete VP8 oder VP9 mit dem Dateiformat WebM. Die dateibasierten Formate wie mp4 sind prinzipiell nicht für die Echtzeitwiedergabe konzipiert. Für die Übertragung und das Abspielen über Echtzeit-Signalen („Live“) über Netzwerke existieren ergänzend die Protokolle HLS (proprietär Apple für iPhone und MacOS auf Basis des Formates MPEG-TS) sowie MPEG DASH. Allerdings bedeutet in diesen Fällen „Live“ nicht „Echtzeit“, sondern Verzögerungen von häufig 30 Sekunden und mehr. Diese können durch Feineinstellung aller Komponenten auf Stand der Technik in den minimalen Bereich 6–10 Sekunden reduziert werden.
-
Die Übertragung von Videosignalen mit kurzen Latenzen erfordern bisher andere Verfahren als die o.g. HTML/HTTP-Protokolle. Stand der Technik dafür sind die Protokolle UDP und RTP, die z.B. in den Anwendungen Skype oder der Webtechnologie WebRTC zum Einsatz kommen.
-
Echtzeitkommunikation ist im Gegensatz zu „Streaming“ nicht in Form von internationalen Standards vereinheitlicht und auf wenigen Geräten verfügbar, so dass Endgeräte wie TV und Mobilgeräte dafür keine einheitliche Schnittstelle aufweisen.
-
Die Übertragung mit kurzen Latenzzeiten mit diesen Protokollen führt häufig zu einer nicht unterbrechungsfreien Übertragung, was die Anwendungserfahrung einschränkt. Video-Kommunikationsanwendungen sind konzipiert für die Übertragung von Punkt-zu-Punkt Verbindungen ähnlich der Telefonie (one-to-one).
-
Die Protokolle zur Videokommunikation und Chat (Skype, WebRTC) sind nicht kompatibel zu Standards des Streaming (HTML5, HLS, DASH).
-
Hauptmangel der bisherigen HTML/http-Lösungen ist die lange Verzögerung der Bildübertragung über mehrere Sekunden. Das hat den großen Nachteil, dass diese Verfahren nicht für Kommunikationsanwendungen geeignet sind, die eine kurze Latenzzeit zwischen Sender und Empfänger erfordern. (z.B. zur Audio/Videotelefonie oder interaktiven Einbindung der Zuschauer mit einem Rückkanal.) Anwendungsgebiete wie Videokonferenzen oder Auktionen sind somit nicht möglich.
-
Im Stand der Technik ist ein HTML 5-Video-Element in der Lage, entweder eine komplette Datei oder ein Video Fragment oder Segment abzuspielen, das in Form einer Datei oder als Teil eines Datenstroms bereitgestellt werden kann. Für die Formate DASH und HLS werden Segmente verwendet, die wiederum in Fragmente unterteilt sind. Stand der Technik ist das ISO-MP4-File-Format in der Variante fMP4. Dabei entspricht eine Segmentlänge mindestens einer GOP-Länge, also 1 bis 10 Sekunden pro Segment. Die zusätzlich eingefügte Latenz beträgt eine Länge eines Segments. Nach dem Stand der Technik kann ein Segment ein oder mehrere vollständige GOPs enthalten. Die minimale Latenz entspricht damit der GOP Länge. Durch Mehrfachpufferung wird in existierenden Einrichtungen eine dreifache Latenz erzeugt.
-
Die Fragmentierung kann z.B. auf Basis des ISO-Standards „fMP4“ erfolgen.
-
Für das fMP4 Format ist Paket gleichbedeutend mit MP4 Fragment. Die zeitliche Größe eines Fragments entspricht im Stand der Technik mehrerer Videobilder. Nach Stand der Technik enthält ein Fragment mindestens die Anzahl der Videobilder einer GOP-Länge.
-
Die Fragmente bestehe aus unterschiedlichen Typenbezeichnungen („Atome“). Die Paketfragmente sind aufgeteilt auf Kopfdaten (Header) und Nutzdaten (Payload). Zwischen den einzelnen Nutzdaten der Paketfragmente gibt es also einen Zwischenraum, der nur aus den Header Infos für die „Atome“ moof und mdat besteht, die zur Synchronisation verwendet werden können.
-
Die Übertragung erfolgt üblicherweise über das IP-Protokoll TCP, sodass eine Störung auf der Übertragungsstrecke auf dieser Protokollebene ausgeschlossen ist. Bei einer Unterbrechung der Verbindung ist es notwendig und möglich, auf den Live-Stream wieder aufzusetzen, um eine Echtzeitübertragung fortzusetzen.
-
Sowohl bei der Kodierung als auch beim Server und bei der Wiedergabeeinrichtung gibt es Pufferspeicher.
-
Es kann vorgesehen sein, dass jedes Paket mit einem Zeitstempel versehen wird. Zeitstempel, sind ein übliches Mittel für die Synchronisation von A/V-Paketen. Für jeden Zeitpunkt der Aufnahme mit einer Live-Quelle gibt es einen Zeitstempel, der zum Beispiel mit der Echtzeit synchronisiert werden kann. Auf der Wiedergabeseite kann dann festgestellt werden, wie spät oder früh sich das Paket im Vergleich zu Echtzeit sowie zu anderen Paketen verhält.
-
Ein Datenstream entsprechend dem fMP4-Format besteht aus einer einleitenden Datenstruktur „ftyp“ und „moov“ gefolgt von in einem Beispiel 5 Paketfragmenten.
-
Jedes Paketfragment besteht aus 2 Teilen, nämlich einem Teil „moof“ der Informationen enthält über die Anzahl der Video- und Audioframes in dem Paket, über die zeitliche Position oder Dauer der Video- und Audioframes, über die Bytegröße der Video- und Audioframes sowie über die Byteposition der Video und Audioframes. An dieses Atom „moof“ schließt sich dann jeweils ein Atom „mdat“ an, in dem die eigentlichen Video- und Audiodaten enthalten sind. Die einzelnen Teile dieses als Beispiel dargestellten Streams schließen sich unmittelbar aneinander an.
-
Für die Segmentierung und Fragmentierung kann auch das HLS-Format anstatt fMP4 verwendet werden. Das HLS-Format besteht aus 2 Teilen: mehreren Segmenten im Format TS (ISO-MPEG-Transportstrom), die jeweils mindestens eine GOP-Länge umfassen und unabhängig von einander abspielbar sind, sowie den index-Daten (Playlist) im Format m3u8, die jeweils auf die Segmente zeigen. Üblicherweise werden 3 Segmente pro Index verwendet, die sich zeitlich verschieben während der Übertragung. Beispielhaft ergeben sich bei 10 Sekunden pro Segment eine Mindestlatenz von 3 × 10 = 30 Sekunden.
-
Die Wiedergabeeinrichtung enthält im Stand der Technik einen eigenen Puffer, der eine zusätzliche Latenz erzeugt. Der Puffer wird in der Wiedergabeeinrichtung automatisch eingestellt. Die automatische Einstellung erfolgt in der Regel auf Basis der eingestellten Spieldauer des Datenstroms, die mindestens der Segmentlänge entspricht.
-
Die von einer Signalquelle erzeugten Daten werden in der Praxis durch Zeitschwankungen der Systeme und andere Systemeinflüsse nicht immer kontinuierlich erzeugt. Beispiel: theoretisch hat eine Kamera eine Bildrate von 25 Bildern pro Sekunde. Ein Bild entspricht einer Zeitdauer von 40 ms. Die durch die Signalquelle erzeugten Bilder können in der Praxis in unterschiedlichen Zeitabständen abfolgen. Im Beispiel könnte eine Lücke von 3 Bildern entstehen, die 3 × 40 = 120ms Zeitdauer entspricht. Im Beispiel 5 Bilder je Sekunde ergeben sich bei 200ms pro Bild und für 3 Bilder 600ms. Diese Lücken führen im Stand der Technik zu Latenzen auf der Wiedergabeseite.
-
Beschreibung der Erfindung
-
Der Erfindung liegt die Aufgabe zu Grunde, ein Verfahren zur Übertragung von echtzeitbasierten digitalen Videosignalen in Netzwerken zu schaffen, das auch dort Anwendung finden kann, wo es auf eine schnelle Reaktion auf Seiten des Empfängers ankommt, beispielsweise also bei Videokonferenzen, Auktionen oder interaktiven Einbinden der Zuschauer.
-
Zur Lösung dieser Aufgabe schlägt die Erfindung ein Verfahren mit den im Anspruch 1 genannten Merkmalen vor. Weiterbildungen der Erfindung sind Gegenstand von Unteransprüchen.
-
Das von der Videosignalquelle in einem Stream ausgegebene Signal wird also in Pakete fragmentiert, wobei ein Paketfragment mindestens einem Videobild mit zugehöriger Audioinformationen entspricht. Die Verwendung genau eines einzigen Videobilds ermöglicht eine Wiedergabe mit der geringsten möglichen Verzögerung zwischen der Videoaufnahme und der Wiedergabe. Bei der Verwendung mehrerer Videobilder in einem Paketfragment ist die Verzögerung immer noch deutlich geringer als im Stand der Technik, sofern man mit der Zahl der in dem Paketfragment enthaltenen Videobilder unter der im Stand der Technik bekannten Zahl in einer GOP (Group of Pictures,) bleibt.
-
Die zeitliche Größe eines Fragments entspricht der Länge eines oder mehrerer Videobilder, die kleiner als ein GOP ist. Die Datengröße entspricht der eines oder mehrerer Videobilder und gegebenenfalls der zeitlich korrespondierenden Audiodaten plus Multiplexdaten.
-
Bei der Verarbeitungseinheit und der Wiedergabeeinrichtung kann es Pufferspeicher geben, wobei allerdings erfindungsgemäß die Paketierung Einheit den Puffer so klein wie möglich hält, da das Füllen eines Puffers üblicherweise mit Latenzen verbunden ist, die die Erfindung möglichst klein halten möchte.
-
In Weiterbildung der Erfindung kann vorgesehen sein, dass die Paketierung in Fragmente im Bereich der Videoquelle vorgenommen wird.
-
Als besonders sinnvoll hat es sich aber herausgestellt, wenn die Paketierung in Fragmente mithilfe eines von der Videoquelle getrennten Servers vorgenommen wird.
-
Es ist aber in Einzelfällen ebenfalls möglich und liegt im Rahmen der Erfindung, dass die Paketfragmentierung in der Wiedergabeeinrichtung erfolgt, beispielsweise im Browser. Hierbei kann ein Eingriff auf Skriptebene erfolgen, d.h. mithilfe eines vom Browser unterstützten Programmmoduls. Üblich ist dabei Java Skript. Diese Art der Programmsteuerung mit Java Skript ist für eine Vielzahl von Anwendungen üblich und Stand der Technik. Diese Programmsteuerung findet unter vom Browser kontrollierten Umgebungen statt und erlaubt keinen direkten Hardwarezugriff.
-
In Weiterbildung der Erfindung kann vorgesehen sein, dass die Paketfragmente in dem fragmentierten MP4 Format (fMP4) vorliegen. Nach diesem Format ist ein Initialisierungssegment vorgesehen, an das sich eine sich wiederholende Gruppe aus einem Fragment-Header (moof) und einem Fragment-Datensegment (mdat) anschließen.
-
Weitere Merkmale, Einzelheiten und Vorzüge ergeben sich aus der folgenden Beschreibung eines bevorzugten Ausführungsbeispiels sowie anhand der Zeichnung. Hierbei zeigen:
-
1 eine schematische Übersicht der verschiedenen Stufen der Erfindung;
-
2 eine schematische Darstellung eines aus 5 Fragmenten bestehenden Streams;
-
3 ein Ablaufdiagramm eine Verarbeitungseinheit zum Verarbeiten des ankommenden Streams;
-
4 ein Ablaufdiagramm der Verarbeitung in der in 1 erwähnten Paketierungseinheit;
-
5 ein übergeordnetes Diagramm.
-
Die 1 zeigt in stark vereinfachter schematischer Form den Aufbau eines Übertragungssystems, auf dem das von der Erfindung vorgeschlagene Verfahren abläuft. Das Videosignal wird von einer Videosignalquelle 1, beispielsweise einer Videokamera, erzeugt. Die Videosignalquelle 1 ist über eine Übertragungsstrecke 2 mit einer Paketierungseinrichtung 3 verbunden. Bei dieser Paketierungseinrichtung 3 kann es sich beispielsweise um einen Server handeln. Über die Übertragungsstrecke 2 wird das Signal der Videoquelle 1 zu der Paketierungseinrichtung übertragen. In der Paketierungseinrichtung 3 wird das Videosignal in Pakete fragmentiert, was im Folgenden noch näher erläutert wird. Die Paketierungseinrichtung 3 ist über eine weitere Übertragungsstrecke bzw. einen Kanal 4 mit einer Wiedergabeeinrichtung 5 verbunden, auf der ein Benutzer das sehen kann, was die Quelle sendet.
-
Bei dem Kanal 4 kann es sich um einen kontinuierlichen Kanal mit Hin- und Rücksendedaten handeln. Es kann sich aber auch um einen statischen Kanal handeln, der nur in der Richtung vom Server 3 zu der Wiedergabeeinrichtung 5 arbeitet, ohne dass es einen Rückkanal gibt.
-
In der Paketierungseinrichtung 3 werden Anpassungen des ankommenden Datenstroms durchgeführt, nämlich zum einen eine Paketierung und Segmentierung des Einkommen Datenstroms und zum anderen eine Anpassung des Datenstroms an ein für die Wiedergabeeinrichtung 5 passendes Format.
-
In 2 ist beispielhaft der Datenstrom anhand des fMP4-Formates dargestellt (Stand der Technik)
-
In 3 ist nun vereinfacht die Vorgehensweise bzw. der Ablauf des Verfahrens innerhalb einer Verarbeitungseinheit dargestellt, in der der Eingangsstrom verarbeitet wird. Das Verfahren beginnt im Block 11, in dem der Stream ankommt. Auf den Block 11 folgt der Verarbeitungsblock 12, der auch als Demultiplexblock bezeichnet werden kann. In diesem Block wird der ankommende Stream in Video-, Audio- und Metadaten-Pakete aufgesplittet.
-
In dem sich daran anschließenden Block 13 werden die Daten in die interne Paketstruktur der Mediadaten umgewandelt. Zu diesen Mediadaten gehören der Pakettyp, nämlich Video, Audio oder Metadaten, Zeitinformationen, ein Synchronisierungpunkt, Video und Audio Konfigurationsdaten, Datenpuffer und Datengröße.
-
In dem sich dann anschließenden Block 14 erfolgt die Ausgabe zu der die Paketierung entsprechend der Erfindung vornehmenden Einrichtung, die in 4 näher erläutert wird.
-
Aus dem Block 14 gelangen dann die Daten in den Abfrageblock 21 aus 4. Dort wird von den ankommenden Daten abgefragt, ob es sich um Konfigurationsdaten handelt. Wenn es sich tatsächlich um Konfigurationsdaten handelt, werden diese in Block 22 gespeichert.
-
Falls es sich nicht um Konfigurationsdaten handelt, geht der Ablauf zum Block 23, wo abgefragt wird, ob es sich um Metadaten handelt. Falls ja, werden diese im Block 24 abgespeichert. Falls nein, geht der Ablauf zum Block 25 weiter, wo abgefragt wird, ob die abgespeicherten Konfigurationsdaten verfügbar sind. Falls Sie Konfigurationsdaten als Ergebnis der Abfrage in Block 25 nicht gespeichert wurden, wird im Block 26 das Datenpaket verworfen.
-
In dem sich bei positiver Abfrage anschließenden Block 27 wird überprüft, ob in diesem Paket ein Keyframe enthalten ist oder bereits ein Keyframe empfangen wurde. Falls nein, wird im Block 28 das Datenpaket verworfen.
-
In dem sich bei positiver Abfrage anschließenden Block 29 erfolgt eine Abfrage, ob es sich um ein Audiopaket handelt. Falls ja, wird das Audiopaket im Block 30 abgespeichert.
-
In dem sich anschließenden Block 31 erfolgt eine Abfrage, ob es sich um ein Videopaket handelt. Wenn ja, wird im anschließenden Block 33 abgefragt, ob es sich um den Start eines Videoframes handelt. Falls dies nicht der Fall ist, wird in dem Block 34 das Videopaket gespeichert.
-
In dem bei positiver Abfrage sich anschließenden Abfrageblock 35 wird überprüft, ob die Zahl der Videoframes in dem Fragment gepuffert ist. Falls nein, wird im Block 36 das Videopaket abgespeichert.
-
Wenn es sich um das erste zu sendende Fragment handelt, was im Abfrageblock 37 festgestellt wird, wird im Block 38 die Initialisierung eines Headers ftyp und moov vorbereitet und durchgeführt, siehe die Angaben zu 2.
-
Anschließend wird, auch dann, wenn die Frage im Abfrageblock 37 negativ beantwortet wird, in Block 39 der Header eines Fragments moof vorbereitet und erstellt. Daran anschließend wird im Block 40 der Datenteil des Fragments erstellt, nämlich das Element mdat, das in 2 erläutert wurde.
-
In Block 40b wird das aktuelle Videopaket abgespeichert.
-
Wenn es sich um das erste zu sendende Fragment handelt, was im Abfrageblock 41 festgestellt wird, wird in Block 42 der Initialisierungs-Header, der Fragmentheader und die Fragmentdaten ausgegeben.
-
Falls es sich nicht um das erste zu sendende Fragment handelt, der Abfrageblock 41 also eine negative Antwort liefert, wird der Fragment Header und die Fragmentdaten im Block 43 ausgegeben. Mit der Ausgabe in Block 44 ist die Tätigkeit der Paketierungseinheit beendet.
-
Die 5 zeigt nun nochmals in einer übergeordneten Darstellung die Struktur des Verfahrens, wie es von der Erfindung vorgeschlagen wird. Die Steuerung des Streams geschieht so, dass am Beginn „Quelle“ steht, der den Datenstrom bereitstellt. Die in dem Stream enthaltenen Video-, Audio- und Metadaten werden entpackt und über die Verbindung 52 an die Paketierung bzw. Multiplexer-Komponente 53 weitergeleitet. Die Multiplexer Komponente 53 macht das, was in 4 im Einzelnen erläutert wurde. In dieser Multiplexer Komponente 53 wird in ein HTML5 fähiges Filestream-Format erzeugt. Dabei kann es sich beispielsweise um fMP4 für Chrome, Firefox oder IE 11 handeln. Für Safari US X und iOS wird das Format m3u8/ts(HLS) bevorzugt. Anschließend erfolgt die Weiterleitung über die Verbindung 54 zu der Outputgruppe 55. Von dort erfolgt die Weiterleitung an die Outputs, die im Einzelnen nicht mehr dargestellt sind.
-
Die gesamte End-to-End Latenz ist die Summe aus der Netzwerktransport-Latenz, der formatbedingten Latenzen und der Latenz durch Buffern im Wiedergabegerät.
-
Die Netzwerktransportlatenzen setzen sich zusammen aus der Übermittlung des Encoders an den Server, die Weitergabe von dem Server an die Paketierungseinheit Player/Transmux Server (53 in 5) und die Weitergabe von dort an die Wiedergabeeinrichtung.
-
Durch Gruppierungen bedingte zeitliche Abhängigkeiten bei der Auslieferung eines Streams führen zu einer zusätzlichen Latenz. Der Beginn eines Segments oder Fragments kann nicht ausgeliefert werden, bevor alle enthaltenen Samples empfangen wurden. Die zusätzliche Latenz beträgt bei der fMP4 Formatierung der Länge eines fMP4 Fragments. Bei den bisher verwendeten Methoden enthält ein Fragment ein oder mehrere vollständige GOPs (Group of pictures, Bildgruppe). Die minimale Latenz bei den bekannten Verfahren entspricht damit der GOP Länge.
-
Durch das von der Erfindung vorgeschlagene Verfahren einer Fragmentierung pro Frame verkürzt sich die formatbedingte Latenz auf die Framelänge.
-
Für die Segmentierung und Fragmentierung kann auch das HLS-Format anstatt fMP4 verwendet werden. Bei der Verwendung des HLS-Formats beträgt im Stand der Technik die formatbedingte zusätzliche Latenz Länge mal Anzahl der HLS Segmente, zum Beispiel 3·3 Sekunden = 9 Sekunden. Durch die Maßnahmen nach der Erfindung enthält die HLS Playlist nur ein Segment mit einer kurzen nominellen Spieldauer (m3u8 Tags).
-
Der Puffer in der Wiedergabeeinrichtung entspricht nach Stand der Technik mindestens einer Segmentlänge, was auch zu einer Latenz führen kann.
-
In Weiterbildung der Erfindung kann vorgesehen sein, die nominelle Spieldauer der Segmente auf geringe Werte zu setzen. Dies wird durch Anpassung durch die Einrichtung im fMP4 Header und/oder in der HLS-Playlist kontrolliert.
-
Die Einrichtung überwacht und steuert weiterhin den Puffer der Wiedergabeeinheit.
-
Im Stand der Technik wird ein einem GOP entsprechendes Segment bzw. Fragment auf Anforderung an den Player übermittelt, der dieses als für sich alleine abspielbares Segment ansieht. Nach dem Abspielen des Segments fordert der Player ein neues Segment an. Dieses Verfahren hat technische Grenzen in der Mindestlänge der GOP und den Zugriffs- und Anforderungszeiten zwischen den Einheiten.
-
Erfindungsgemäß wird die GOP-Grenze aufgehoben. Viele kleine Frames werden als Datenstrom übermittelt und empfangen.
-
In Weiterbildung der Erfindung kann vorgesehen sein, dass Zeitinformationen (Zeitstempel, Zeitdauer, Spielzeiten) geändert werden.
-
In Weiterbildung der Erfindung kann vorgesehen sein, dass Audio-Pakete gemeinsam oder getrennt von Videopaketen übertragen werden.
-
In Weiterbildung der Erfindung kann vorgesehen sein, dass Pakete ausgelassen oder hinzugefügt werden.
