DE102012212139A1

DE102012212139A1 - Verfahren zum Betreiben eines Servers für das HLS-Streaming eines Video-Films mit mindestens einem konfigurierbaren Objekt

Info

Publication number: DE102012212139A1
Application number: DE201210212139
Authority: DE
Inventors: Auf Nichtnennung Antrag
Original assignee: Mackevision Medien Design GmbH
Current assignee: Mackevision Medien Design GmbH
Priority date: 2012-07-11
Filing date: 2012-07-11
Publication date: 2014-01-16

Abstract

Es wird ein auf dem HTTP Live-Stream der Apple Inc. basierendes Verfahren aufgebaut, das es ermöglicht, Videofilme auf Endgeräten darzustellen, wobei während des Ablaufens des Videofilms die Konfiguration eines in dem Videofilm dargestellten Objekts geändert werden kann.

Description

In den Internetpräsenzen von Herstellern hochwertiger Güter wird dem potenziellen Kunden, der über ein Endgerät auf die Internetpräsenz des Herstellers zugreift, häufig die Möglichkeit geboten, bestimmte Produkte seinen Wünschen entsprechend zu konfigurieren. Ein typisches Beispiel für ein konfigurierbares Produkt ist ein PKW. Bei PKWs gibt es verschiedene Ausstattungsmerkmale, wie z.B. die Farbe der Karosserie, die Art und Form der Räder sowie Karosserievarianten (Limousine, Kombi oder Coupé). Diese Varianten können miteinander kombiniert werden, sodass sich eine Vielzahl von möglichen Konfigurationen des Produkts ergibt. Solche Konfiguratoren sind seit einigen Jahren bereits üblich und erlauben es dem potentiellen Kunden einen PKW in der von ihm gewünschten Konfiguration am Pc anzusehen.
Ein nächster Schritt besteht nun darin, dem potenziellen Kunden einen visuellen Eindruck des von dem Kunden konfigurierten Produkts in einem Videofilm unter möglichst realistischen Bedingungen zu vermitteln. Dies kann z.B. dadurch erfolgen, dass ein PKW in der vom Kunden erstellten Konfiguration in einem Videofilm auf einer Landstraße fahrend dargestellt wird und der potentielle Kunde sich diesen Videofilm an seinem Endgerät, wie zum Beispiel einem iphone oder einem ipad der Apple Inc., anschauen kann. Dadurch werden z.B. die Farbe der Karosserie im Zusammenspiel mit der Umgebung und den Lichtreflexen sehr gut veranschaulicht.
Die Endgeräte der Apple Inc. Verfügen über einen Mediaplayer, der das sogenannte HTTP Live-Streaming (HLS) durchführen kann. Das HLS ist ein dem einschlägigen Fachmann bekanntes Protokoll zur Übertragung von multimedia-Daten. Näheres dazu findet sich beispielsweise auf der internet-Präsenz der IETF.
Vorteile der Erfindung
Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren bereitzustellen, mit dessen Hilfe Endgeräte, die das sogenannte HLS-Streaming durchführen können, mit Videofilmen zu versorgen, die mindestens ein konfigurierbares Objekt enthalten, wobei die Konfiguration während dem Abspielen des Videofilms auf dem Endgerät durch den Nutzer des Endgeräts gewechselt werden kann.
Diese Aufgabe wird erfindungsgemäß bei einem Verfahren zum Betreiben eines Playlist Service Servers für das HTTP-Live-Streaming (HLS) eines Videofilms mit mindestens einem konfigurierbaren Objekt, wobei zu jeder möglichen Konfiguration ein Videofilm vorhanden ist, wobei jeder Videofilm eine begrenzte Zahl von Videosegmenten umfasst, wobei in dem Playlist Service die Namen und Speicherorte der Videosegmente hinterlegt sind, und wobei der Playlist Service eine mit dem HLS-Protokoll kompatible Schnittstelle und eine zusätzliche Steuerungsschnittstelle zur Kommunikation mit mindestens einem Endgerät aufweist, durch folgende Verfahrensschritte gelöst:
Bereitstellen einer Live-Stream Schnittstelle gemäß dem HLS-Standard sowie einer erfindungsgemäßen Steuerungsschnittstelle.
Empfangen einer Initialisierungsanfrage von einem Endgerät, wodurch eine individuelle Sitzungskennung generiert und an das anfragende Endgerät zurückgeliefert wird.
Empfangen kontinuierlich wiederkehrender Abfragen nach Aktualisierung einer Playlist, bezogen auf die zuvor ausgetauschte Sitzungskennung von dem Endgerät.
Auswählen des passenden Videosegments aus einem Pool vorproduzierter Videosegmente, das zeitlich auf das zuletzt an das Endgerät mit der Sitzungskennung SK übermittelte Videosegment folgt, wobei die Auswahl unter Berücksichtigung einer aktuellen Konfiguration eines konfigurierbaren Objekts in dem Videofilm erfolgt, und
Übertragen einer, der Sitzungskennung zugeordneten Playlist an das anfragende Endgerät, wobei die Playlist nur die URL des ausgewählten Videosegments enthält.
Die erfindungsgemäße Initialisierungsanfrage von einem Endgerät führt dazu, dass eine individuelle Sitzungskennung generiert wird, so dass – anders als bei dem standardmäßigen HLS-Verfahren – für jedes Endgerät das passende Videosegment ausgewählt und die zugehörige URL an das Endgerät in der Playliste übermittelt werden kann.
Auf diese Weise können verschiedene Endgeräte, die zur gleichen Zeit mit dem Playlist Service kommunizieren, unabhängig voneinander mit dem Abspielen des Videofilms beginnen und auch unabhängig voneinander die gewünschte Konfiguration des in dem Videofilm dargestellten konfigurierbaren Objekts ändern.
Ergänzend ist noch zu erwähnen, dass die Playliste auch noch andere Informationen gemäß dem HLS-Standard enthalten kann. Für das erfindungsgemäße Verfahren ist jedoch wichtig, dass in der Playliste nur die URL eines Videosegments enthalten ist. Maximal sind die URLs einer Anzahl von Videosegmenten enthalten, welche in ihrer zeitlichen Gesamtdauer die gewünschte Konfigurationsumschaltzeit nicht übersteigen.
Durch die Limitierung der Zahl der in der Playliste enthaltenen URLs wird ein schnelleres Umschalten auf eine andere vom Nutzer gewünschte Konfiguration beim Abspielen des Videofilms auf dem Endgerät ermöglicht, weil dadurch Anzahl der Segmente bzw. die Zeit, die der Client puffert, so kurz wie möglich gehalten wird. Standardmäßig versuchen HLS-Videowiedergabekomponenten alle verfügbaren Videosegmente zu puffern.
Wenn mehr als eine URL in der Playliste enthalten ist, lässt sich das erfindungsgemäße Verfahren auch noch durchführen. Allerdings nimmt der Nutzer wegen der verzögerten Umschaltung von der aktuellen Konfiguration auf die von ihm ausgewählte Konfiguration dieses Verfahren als verschlechtertes und weniger nutzerfreundliches Verfahren wahr.
Das erfindungsgemäße Verfahren hat den großen Vorteil, dass an den Videowiedergabekomponenten der Endgeräte keinerlei softwaremäßige Änderungen vorzunehmen sind. Alle HLS-fähigen Endgeräte können mit dem erfindungsgemäßen Playlist Service über das HLS-Protokoll kommunizieren und die bereitgestellte Medien (Videofilme) wiedergeben.
Die zusätzliche Funktionalität für den Nutzer des Endgeräts wird durch das Bereitstellen einer Steuerungsschnittstelle, die erfindungsgemäße Auswahl eines Videosegments und die Erstellung einer gegenüber dem HLS-Standard reduzierten Playliste erreicht. Somit steht das erfindungsgemäße Verfahren allen Nutzern HLS-fähiger Endgeräte zur Verfügung.
Für die Steuerung der Konfiguration von Objekten im Videostream wird eine Steuerungskomponente auf dem Endgerät benötigt. Diese Steuerungskomponente ist abhängig von der Plattform des Endgerätes zu realisieren und kann und beispielsweise innerhalb von Interseiten mit Javascript oder in für die Plattform typischen Programmiersprachen implementiert sein. (Auf iOS beispielsweise in Objective-C, auf Android beispielsweise in Java.)
In weiterer vorteilhafter Ausgestaltung der Erfindung liefert der Playlist Service vor Erhalt einer ersten Anfrage nach einer Playlistenaktualisierung von einem Endgerät, welche optional eine Startkonfiguration enthält, eine neue Sitzungskennung an das Endgerät aus und wechselt in einen Startmodus SM. In dem Startmodus SM liefert der Playlist Service für kontinuierlich wiederkehrende Anfragen nach einer Playlistenaktualisierung wiederholt die URL des ersten Videosegments in der Startkonfiguration in einer Playliste aus. Enthält die erste Anfrage eines Endgerätes keine Startkonfiguration nutzt der Playlist Service eine voreingestellte Standardkonfiguration als Startkonfiguration.
Dies bedeutet, dass der Nutzer zum Starten des HLS-Streamings keine Konfiguration vorgeben muss, so dass der Nutzer sehr rasch und einfach die Wiedergabe des gewünschten Videofilms beginnen kann. Das erfindungsgemäße Verfahren bleibt so lange im Startmodus SM, bis das Endgerät mit der entsprechenden Sitzungskennung eine Nachricht "Wechsle vom Start-Modus in den Wiedergabe-Modus" an den Playlist Service übermittelt.
Dann beginnt für den Nutzer des Endgeräts das Abspielen des Videofilms zunächst in der Startkonfiguration.
Wenn von einem Endgerät eine weitere Nachricht mit dem Inhalt "Änderung der Konfiguration: Gewünschte Konfiguration K = K_p" (zusammen mit der Sitzungskennung SK) an den Playlist Service übermittelt wird, dann wird in dem Playlist Service die aktuelle Konfiguration K in die gewünschte Konfiguration K_P geändert.
Infolgedessen nimmt der Nutzer schon zeitnah nach dem Absenden seiner Nachricht, das heißt mit einer zeitlichen Verzögerung von einer Segmentlänge, die geänderte Konfiguration des konfigurierbaren Objekts auf dem Bildschirm wahr.
Erfindungsgemäß können die Videosegmente der Videofilme auf dem Playlist Service abgespeichert oder auf einem separaten Server, bevorzugt in einem CDN abgespeichert sein.
Anders als beim regulären HLS-Verfahren ist die Segmentierung der in dem Server 1 hinterlegten Videofilme bei dem erfindungsgemäßen Verfahren möglichst kurz. Es hat sich als vorteilhaft erwiesen, wenn die Videosegmente eine Länge von weniger als 5 s, bevorzugt von 2 s und besonders bevorzugt von 1 s haben.
Weitere Vorteile und vorteilhafte Ausgestaltung der Erfindung sind der nachfolgenden Zeichnung, deren Beschreibung und den Patentansprüchen entnehmbar. Alle in der Zeichnung, deren Beschreibung und den Patentansprüchen offenbarten Merkmale können sowohl einzeln als auch in beliebiger Kombination miteinander erfindungswesentlich sein.
Zeichnung Es zeigen:
1: ein vereinfachtes Sequenzdiagramm des standardisierten HLS-Verfahrens,
2: ein Sequenzdiagramm des erfindungsgemäßen Verfahrens im Start-Modus und im Abspiel-Modus,
3: ein Sequenzdiagramm des erfindungsgemäßen Verfahrens mit einer Änderung einer Konfiguration durch den Nutzer und
4 die für das erfindungsgemäße Verfahren wichtigsten Komponenten und Schnittstellen.
Beschreiben der Ausführungsbeispiele
In den Sequenzdiagrammen der 1 bis 3 bedeuten:
Pfeil mit Block: Steht für eine synchrone Anfrage/Nachricht; der Sender wartet auf eine Antwort vom Empfänger.
Pfeil ohne Block: Steht für eine asynchrone Anfrage/Nachricht ohne Antwort vom Empfänger.
Uniform Resource Locator (URL): ein Bezeichnungsstandard für Netzwerkressourcen.
In der 1 wird ein Sequenzdiagramm eines vereinfachten HTTP-Live-Streaming-Verfahrens nach dem HLS-Standard dargestellt. An dem Verfahren sind ein Server 1 und ein Endgerät 3 beteiligt.
Ein Live-Stream ist ein Film, der regelmäßig durch das Anhängen weiterer Video-Segmente ergänzt und damit auch verlängert wird. Ein Live-Stream unterscheidet sich von einem herkömmlichen Film dadurch, dass er kein Ende hat, weil regelmäßig weitere Video-Segmente erzeugt und beispielsweise auf dem Server 1 abgespeichert werden.
Wenn ein Nutzer einen solchen Live-Stream auf seinem Endgerät 3 abspielt, dann läuft eine Schleife 12 umfassend die Verfahrensschritte 5, 7, 9 und 11 ab, bis der Nutzer durch eine entsprechende Eingabe das HLS-Streaming beendet oder der Server keine weiteren Segmente in die Playliste einfügt oder durch ein entsprechendes „End“-tag ein Ende kennzeichnet.
In dem Schritt 5 ruft das Endgerät eine sogenannte Playlist von dem Server 1 ab. Eine Playlist ist eine Liste der URLs aller zu dem Live-Stream gehörenden Video-Segmente.
Ein Live-Stream ist in den meisten Fällen eine Live-Übertragung von einem Ereignis, welche von vielen Nutzern gleichzeitig empfangen und betrachtet wird. Für einen Live-Stream existiert auf dem Server 1 eine Playliste, welche alle URLs der aktuell verfügbaren Videosegmente enthält und von allen Endgeräten abgerufen wird. Als Antwort auf die Abfrage 5 übermittelt der Server 1 diese Playliste, welche unter anderem die URLs aller verfügbaren Videosegmente des angefragten Live-Streams enthält, an das oder die Endgeräte 3.
Nachdem das Endgerät 3 die Playliste mit den URLs aller verfügbaren Videosegmente vom Server 1 erhalten hat, startet das Endgerät 3 eine Abfrage an den Server 1, um die benötigten Videosegmente von dem Server 1 herunter zu laden. Diese Abfrage der Videosegmente ist in der 1 mit dem Bezugszeichen 9 bezeichnet.
Anschließend werden die abgefragten Videosegmente vom Server 1 an das Endgerät 3 übertragen. Dieser Vorgang hat in der 1 das Bezugszeichen 11.
Diese Abfolge der Abfragen und der Kommunikation zwischen Server 1 und Endgerät 3 mit den Bezugszeichen 5, 7, 9 und 11 wiederholt sich regelmäßig in einer Schleife 12 bis der Nutzer des Endgeräts 3 oder der Server 1 den Live-Streaming-Prozess beendet.
Dies bedeutet, dass beispielsweise, wenn ein Live-Stream nach 30 Sekunden aktualisiert wird, indem ein neues Videosegment in dem Server 1 abgespeichert wird und die URL dieses neuen Videosegments in die Playliste des aktuellen Livesreams eingefügt wird. Ab diesem Zeitpunkt erfahren alle Endgeräte 3 durch erneutes Laden der aktualisierten Playliste von dem neuen Videosegment bzw. dessen URL und laden dieses herunter.
In der 2 ist ein Ausführungsbeispiel des erfindungsgemäßen Verfahrens ebenfalls als Sequenzdiagramm dargestellt. Zusätzlich zu dem Server 1 und dem Endgerät 3 ist noch ein erfindungsgemäßer Server vorgesehen, der als Playlist Service 13 bezeichnet wird, vorhanden.
Der Server 1 und der Playlist Service 13 sind als getrennte Blöcke dargestellt. Die Aufteilung in den Server 1 und den Playlist Service 13 ist in vielen Fällen aus Gründen der Wirtschaftlichkeit und der Effizienz vorteilhaft. Hardwaremäßig ist es jedoch auch möglich, den Server 1 und den Playlist Service 13 in einem Server zu integrieren.
Der Playlist Service 13 ist ein erfindungsgemäß konfigurierter Server, der mit der Videowiedergabekomponente des Endgeräts 3 wie ein regulärer HLS-Server 1 kommuniziert. Dies bedeutet, dass die Videowiedergabekomponente des Endgeräts 3 ohne hardware- oder softwareseitige Änderungen sowohl mit dem Server 1 gemäß der 1 als auch mit dem Playlist Service 13 gemäß der 2 und 3 kommuniziert.
Im Unterschied zu einem normalen Live-Stream gemäß dem HLS-Verfahren, wird mit dem erfindungsgemäßen Verfahren jedem Nutzer ein individueller, konfigurierbarer Live-Stream bereitgestellt. Dies wird dadurch erreicht, dass für jeden Nutzer bzw. für jedes Endgerät 3 eine Sitzungskennung generiert wird und entsprechend sitzungsbezogene Playlisten bereitgestellt werden. Dieser Vorgang ist in der 2 mit den Bezugszeichen 14 und 16 gekennzeichnet.
Außerdem werden die Playlisten nicht in festgelegten Intervallen um URLs zu neuen Videosegmenten erweitert, sondern durch gesonderte und erfindungsgemäße Anfragen des Endgeräts 3 gesteuert. Die Videosegmente werden, entgegen dem standardmäßigem HLS-Verfahren, nicht in Echtzeit erzeugt, sondern die URLs in den Playlisten verweisen ausschließlich auf vorproduzierte Videosegmente.
Der Live-Stream nach dem erfindungsgemäßen Verfahren enthält einen Video-Film mit einer bestimmten Länge, der aus einer festgelegten Zahl von vorproduzierten Videosegmenten besteht. Jedes Video-Segment ist in einer Datei mit einer eigenen URL abgespeichert. Zum Beispiel besteht ein Video-Film mit einer Dauer von 60 Sekunden und einer Segmentlänge von 1 Sekunde somit aus 60 Video-Segmenten, die jeweils in separaten Dateien abgespeichert sind.
Wenn in dem Video-Film vier Konfigurationen eines konfigurierbaren Objekts darstellbar sein sollen, bedeutet dies, dass insgesamt 4 × 60 (= 240) vorgefertigte Video-Segmente benötigt werden, die jeweils in separaten Dateien abgespeichert sind. Ein Beispiel für vier Konfigurationen sind die Wagenfarben „rot“, „weiß“, „silber“ und „schwarz“.
Wenn nun diese vier segmentierten Video-Filme in drei verschiedenen Auflösungen und Datenraten verfügbar sein sollen, um auf die unterschiedlichen Bandbreiten bei der Datenübertragung vom Server auf das Endgerät 3 reagieren zu können, werden somit 3 × 240 (= 720) Dateien mit Video-Segmenten auf dem Server 1 abgespeichert.
Die Segmentierung, d. h. die Aufteilung des Video-Films in mehrere Segmente ist bei allen 4 × 3 (= 12) Video-Filmen gleich. Das heißt beispielsweise bei einer Segmentdauer von 1 s, dass das fünfte Segment das Zeitintervall von t > 4 s bis t = 5 s abdeckt, unabhängig von der Konfiguration und der Datenrate des Videofilms.
Es ist für das erfindungsgemäße Verfahren unbeachtlich, ob die Dateien der segmentierten Video-Filme in einem separaten Server 1 oder auf dem gleichen Server wie der Playlist Service 13 abgespeichert sind.
Im Start-Modus SM (siehe die Schleife 22) wird immer die im Playlist Service 13 hinterlegte oder eine vom Endgerät 3 vorgegebenen Startkonfiguration eines konfigurierbaren Objekts berücksichtigt.
Wenn also beispielsweise der Videofilm Fahraufnahmen eines Kraftfahrzeugs zeigt und die Wagenfarbe „rot“ als Startkonfiguration gesetzt ist, dann wird bei dem in 2 beschriebenen erfindungsgemäßen Verfahren sowohl in dem ersten Videosegment als auch in den Folgesegmenten das Fahrzeug rot dargestellt.
Der Wechsel einer Konfiguration, beispielsweise der Wagenfarbe von „rot“ auf „weiß“, ist in der 2 nicht dargestellt.
Dieser Wechsel wird nachfolgend im Zusammenhang mit der 3 erläutert.
In der 2 werden zwei Betriebs-Modi, nämlich der Start-Modus (Schleife 22) und der Abspiel-Modus (Schleife 32), dargestellt. Weil das erfindungsgemäße Verfahren auf dem HLS-Verfahren basiert, gibt es gewisse Übereinstimmungen zwischen den 1 und 2.
Das erfindungsgemäße Verfahren beginnt mit der Abfrage einer Playlisten-Aktualisierung 15. Im Gegensatz zur Abfrage 5 beinhaltet Abfrage 15 die Sitzungskennung SK. Die Abfrage 15 richtet sich nicht an den Server 1, sondern an den Playlist Service 13.
Als Antwort auf diese Abfrage 15 übermittelt der Playlist Service 13 eine zu der Sitzungskennung SK gehörende Playliste an das anfragende Endgerät 3. Diese erfindungsgemäß verkürzte Playliste enthält nur ein erstes Videosegment eines Videofilms mit der Startkonfiguration des konfigurierbaren Objekts.
Dies bedeutet, dass in dem Schritt 17, wenn der Playlist Service 13 zum ersten Mal eine Playliste mit Sitzungskennung an das Endgerät 3 übermittelt, diese Playliste die URL zu genau einem Videosegment VS enthält. Es handelt sich dabei um das erste Videosegment des Videofilms, der abgespielt werden soll, wobei das oder die konfigurierbaren Objekte dieses Videofilms die Startkonfiguration aufweisen, die im Playlist Service 13 gesetzt ist.
Zur Verdeutlichung haben die Video-Segmente VS Indices, wobei der erste Index die fortlaufende Nummer der Segmente darstellt und mit dem zweiten Index die Konfiguration bezeichnet. Das Video-Segment VS_1,1 enthält somit den Beginn eines Video-Film in der das konfigurierbare Objekt in der Konfiguration “1“ dargestellt ist.
Nach dem das Endgerät 3 diese erfindungsgemäße Playliste mit nur einer Referenz auf ein Videosegment VS erhalten hat, ruft es dieses Videosegment VS in einem Schritt 19 von dem Server 1 ab.
Als Antwort auf diese Abfrage übermittelt der Server 1 dieses erste Videosegment VS, mit einer möglichst kurzen Dauer von beispielsweise 1 s, an das Endgerät 3. Dieser Vorgang wiederholt sich in der Schleife 22, so dass das erste Videosegment immer wieder in der Playliste referenziert wird.
Diese Schleife 22 wird erst unterbrochen, wenn von dem Endgerät 3 eine Mitteilung 23 mit dem Inhalt "Abspielen" oder "Play" an den Playlist Service 13 übermittelt wird.
Wie sich durch die blocklose Darstellung des Pfeils 23 ergibt, löst diese Mitteilung vom Endgerät 3 an den Playlist Service 13 keine direkte Antwort aus. Es ist vielmehr so, dass nun der Playlist Server die Schleife 22 bzw. den Startmodus SM umfassend die Schritte 15 bis 21 verlässt und in einen Abspielmodus AM (Schleife 32) wechselt. Im Abspielmodus AM (Schleife 32) wird bei der nächsten Abfrage einer Playlisten-Aktualisierung nicht mehr das erste Videosegment, sondern ein Folgesegment an das Endgerät übermittelt. Diese Vorgänge sind mit den Bezugszeichen 25 und 27 angedeutet.
Als Reaktion auf den Erhalt der Playliste 27 fragt das Endgerät 3 nun dieses Folgevideosegment vom Server 1 ab. Diese Abfrage ist mit dem Bezugszeichen 29 versehen. Als Reaktion auf diese Abfrage 29 übermittelt der Server 1 das Folgevideosegment an das Endgerät 3, wo es abgespielt bzw. auf dem Bildschirm dargestellt wird.
Im Start-Modus SM werden die Schritte 15, 17, 19 und 21 in der Schleife 22 wiederholt abgearbeitet.
Die erfindungsgemäße Schleife 22 ist notwendig, da ein normaler HLS Live-Stream für den Nutzer keinen klaren Anfang hat. Im Normalfall schaltet sich ein Nutzer sozusagen in einen laufenden Live-Stream. Aus diesem Grund versucht die Videowiedergabekomponente auf HLS-fähigen Endgeräten schon Videosegmente vorzuladen, bevor der Nutzer einen "Play"-Button betätigt hat. Dadurch kann die Videowiedergabekomponente gewährleisten, dass das aktuelle Videosegment des Live-Streams angezeigt werden kann, unmittelbar nachdem der Nutzer einen "Play"-Button betätigt.
Im Fall eines individuell konfigurierbaren Live-Streams würde dieses Standardvorgehen jedoch das Nutzungserlebnis beeinträchtigen, da der Nutzer den Video-Film nur von Beginn an sehen könnte, wenn er unmittelbar nach dem Erscheinen der Benutzeroberfläche auf einem Endgerät einen "Play"-Button betätigen würde. Wenn der Nutzer also beispielsweise 30 Sekunden wartet bis er den "Play"-Button betätigt, dann würde der Video-Film bei t = 30 Sekunden wiedergegeben werden.
Anders als bei dem HLS-Verfahren übermittelt der Playlist Service 13 im Start-Modus SM immer wieder den Dateinamen des gleichen Video-Segments an das Endgerät 3.Diese kurze Film-Sequenz wird solange wiederholt, bis der Nutzer des Endgeräts 3 eine Nachricht „Status = Play“ (siehe das Bezugszeichen 23) an den Playlist Service 13 übermittelt.
Sobald der Nutzer des Endgerätes 3 eine Nachricht „status=play“ (siehe das Bezugszeichen 23) an den Playlist Service 13 übermittelt, wechselt der Playlist Service 13 in den Abspiel-Modus AM und die Videowiedergabekomponente von Endgerät 13 beginnt mit der Wiedergabe der Videosegmente.
Im Abspiel-Modus AM werden die Schritte 25, 27, 29 und 31 in der Schleife 32 wiederholt abgearbeitet.
Anders als bei dem HLS-Verfahren übermittelt der Playlist Service 13 im Abspiel-Modus AM mit jeder Playliste nur die URL des nächsten Video-Segments. Wenn also das letzte vom Playlist Service 13 an das Endgerät 3 übermittelte Video-Segment VS die fortlaufende Nummer „n“ hatte, dann wird beim nächsten Ablauf der Schleife 32 der Dateiname des Video-Segments VS mit der Nummer „n + 1“ an das Endgerät übermittelt.
Zur Beendigung des erfindungsgemäßen Verfahrens bestehen zwei Möglichkeiten:
Wahlweise ist es durch eine Serverkonfiguration möglich, nach Übertragung des letzten Video-Segments, die Wiedergabe des Films zu wiederholen. Alternativ kann der Live-Stream durch den Playlist Service 13 beendet werden, indem der Playlist Service 13 in die Playliste hinter das letzte Video-Segment ein "End"-Tag einfügt. Dieses HLS-gemäße Vorgehen signalisiert der Videowiedergabekomponente auf dem Endgerät 3, dass es keine weiteren Video-Segmente gibt und der Live-Stream beendet wurde.
Für den Nutzer des Endgeräts 3 läuft im Abspiel-Modus AM somit der gewünschte Video-Film kontinuierlich ab, wobei das konfigurierbare Objekt in der Standardkonfiguration dargestellt wird.
Der Wechsel der Konfiguration wird nachfolgend anhand der 3 erläutert.
Die 3 geht davon aus, dass sich das erfindungsgemäße Verfahren in der Schleife 32 befindet, welche die Schritte 25, 27, 29 und 31 umfasst. In der 3 ist daher die Schleife 32 nochmals dargestellt.
Wenn der Nutzer des Endgeräts 3 die Konfiguration des konfigurierbaren Objekts ändern will, dann schickt er eine entsprechende Mitteilung 33 an die Steuerungsschnittstelle des Playlist Service 13. Diese Mitteilung enthält die Bezeichnung der gewünschten Konfiguration K_P sowie die Sitzungskennung SK.
Die Mitteilung 33 kann zwischen den Schritten 27 und 29 und/oder nach dem Schritt 31 und damit vor dem Schritt 25 erfolgen. Deshalb ist die Übermittlung dieser Mitteilung mit dem Bezugszeichen 33 zweimal in der 3 dargestellt. Durch diese Darstellung soll auch angedeutet werden, dass diese Übermittlung der Mitteilung 33 vom Endgerät 3 an den Playlist Service 13 unabhängig von dem Ablauf der Schleife 32 erfolgt.
Sobald eine solche (Änderungs-)Mitteilung 33 beim Playlist Service 13 angekommen ist, sendet der Playlist Service 13 in der nächsten Playlisten-Übermittlung 27 die URL des nächsten Video-Segments „n + 1“, welches das konfigurierbare Objekt in der vom Nutzer des Endgeräts 3 gewünschten Konfiguration zeigt, an das Endgerät 3.
Wenn Beispielsweise bis zum Abspielen des Videosegments „n“ das konfigurierbare Objekt in der Konfiguration K₁ dargestellt wird, und der Nutzer nun die Konfiguration K₃ zu sehen wünscht, dann übermittelt der Playlist Service 13 als nächstes nicht das Video-Segment VS_n+1,₁, sondern das Video-Segment VS_n+1,₃ anhand der Playliste an das Endgerät 3. Dadurch wird im Abspiel-Modus die auf dem Endgerät 3 dargestellte Konfiguration des konfigurierbaren Objekts entsprechend dem Wunsch des Nutzers geändert.
Wenn die Mitteilung 33 zwischen den Schritten 27 und 29 erfolgt, dann wird diese gewünschte Änderung der Konfiguration K noch nicht in dem unmittelbar darauf folgenden Schritt 29 berücksichtigt, weil in der zuletzt übermittelten Playliste 27 noch die Startkonfiguration unterstellt wird (siehe den Schritt 17 in 2). Infolgedessen würde in der Abfrage 29 noch das zur vorhergehenden Konfiguration gehörende Videosegment VS_n+1,₁ abgefragt und nach Erhalt (Schritt 31) am Endgerät 3 angezeigt.
In der darauf folgenden Abfrage der Playlistenaktualisierung 25 ist in dem Playlist Service 13 nun die vom Nutzer gewünschte Konfiguration K₃ aktiv, so dass der Playlist Service 13 nun die URL des Folgesegments VS_n+2,₃ an das Endgerät 3 überträgt.
Anschließend wird in den Schritten 29 und 31 das Folgesegment in der vom Nutzer gewünschten Konfiguration K₃ vom Server 1 abgefragt, an das Endgerät 3 übermittelt und dort abgespielt.
Dies bedeutet, dass immer wenn die Mitteilung 33 betreffend die gewünschte Konfiguration K zwischen den Schritten 27 und 29 erfolgt, die Änderung der Konfiguration erst mit einer gewissen Verzögerung auf dem Bildschirm sichtbar wird.
Die Länge dieser Verzögerung entspricht der Dauer eines Video-Segments VS. Daher ist man bei dem erfindungsgemäßen Verfahren bestrebt, die Länge der Segmente möglichst gering, beispielsweise mit einer Dauer von 1 s, zu halten. Dann wird ein rascheres Umschalten der Konfiguration ermöglicht.
Wenn die Mitteilungsänderung 33 nach dem Schritt 31 beim Playlist Service 13 eingeht, wird unmittelbar darauf bei der nächsten Abfrage der Playlisten-Aktualisierung (Schritt 25) schon die vom Nutzer gewünschte Konfiguration vom Playlist Service 13 berücksichtigt und es wird in der Playliste die URL des Folgesegments einer Videodatei übermittelt, welches das konfigurierbare Objekt in der gewünschten Konfiguration zeigt. In diesem Fall erfolgt der Wechsel der Konfiguration mit nur kurzer Verzögerung.
In der 4 sind die wesentlichsten Komponenten und Schnittstellen nochmals dargestellt.
Beginnend beim Server 1 sind „n“ Vielzahl von Videosegmenten VS_1,VS₂ .... bis VS_n dargestellt. Auf diese Videosegmente VS referenziert die Playliste.
Der Playlist Service 13 umfasst eine HLS-Schnittstelle 35 und eine Steuerungsschnittstelle 37.
Eine HLS-Videowiedergabekomponente 39 kommuniziert mit einer HLS-Schnittstelle 35 des Playlist Service 13. Die HLS-Videowiedergabekomponente 39 des Endgeräts 3 lädt auch die benötigten Videosegmente VS_i von dem Server 1.
Eine Steuerungskomponente 41 des Endgeräts 3 kommuniziert mit der Steuerungsschnittstelle 37 des Playlist Service 13. Dadurch wird die Erstellung der Playlisten gesteuert.

Claims

Verfahren zum Betreiben eines Playlist Service (13) für das HTTP Live Streaming (HLS) zum Bereitstellen eines Live-Streams eines Video-Films mit mindestens einem konfigurierbaren Objekt, wobei zu jeder möglichen Konfiguration (K_p, p = 1...r; mit „r“ = Zahl der möglichen Konfigurationen) ein Videofilm vorhanden ist, wobei jeder Videofilm eine begrenzte Zahl (m) von Video-Segmenten (VS_i, i = 1...m) umfasst, wobei in dem Playlist Service (13) die Namen und/oder Speicherorte der r × m Video-Segmente (VS_i,p) hinterlegt sind, wobei der Playlist Service Server (13) eine mit dem HLS-Protokoll kompatible Schnittstelle (35) sowie eine Steuerungsschnittstelle (39) zur Kommunikation mit mindestens einem Endgerät (3) aufweist, umfassend folgende Verfahrensschritte: Übermittlung einer Nachricht (16) mit einer Sitzungskennung (SK) von dem Playlist Service (13) an das Endgerät (3). Empfangen einer Nachricht (15) von einem Endgerät (3), wobei die Nachricht eine Sitzungskennung (SK) und die Abfrage nach Aktualisierung einer Playliste (gemäß dem HLS-Standard) umfasst, Auswählen eines Videosegments (VS_n+1,p), das zeitlich auf das zuletzt an das der Sitzungskennung (SK) zugeordnete Endgerät (3) übermittelte Videosegment (VS_n) folgt, wobei die Auswahl unter Berücksichtigung einer aktuellen Konfiguration (K_p) erfolgt, und Senden einer Playliste an das der Sitzungskennung (SK) zugeordnete Endgerät (3), wobei die Playliste nur die Referenz des ausgewählten Videosegments (VS_n+1,p) enthält.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Playlist Service Server (13) nach Erhalt einer ersten Anfrage von einem Endgerät (3) mit einer neuen Sitzungskennung (SK) einen Start-Modus (SM) einnimmt, und in dem Start-Modus (SM) nach dem Empfang einer Nachricht von dem Endgerät (3) mit der entsprechenden Sitzungskennung (SK) betreffend die Abfrage nach einer Aktualisierung der Playliste immer das erste Videosegment (VS_1,1) in einer voreingestellten Startkonfiguration (K1) auswählt.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass der Playlist Service (13) nach dem Empfang einer Nachricht (23) „Status = play“ von dem Endgerät (3) mit der entsprechenden Sitzungskennung (SK) in das Verfahren gemäß Anspruch 1 wechselt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Playlist Service (13) nach dem Empfang einer Nachricht (33) „Änderung der Konfiguration (K = K_p, p = 1...r) von einem Endgerät (3), wobei die Nachricht eine Sitzungskennung (SK) umfasst, die aktuelle Konfiguration von der Startkonfiguration (K₁) in die Konfiguration K_p ändert.
Verfahren nach einem der vorhergehenden Patentansprüche, dadurch gekennzeichnet, dass die Video-Segmente auf dem Playlist Service Server (13) abgespeichert sind.
Verfahren nach einem der vorhergehenden Patentansprüche, dadurch gekennzeichnet, dass die Video-Segmente auf einem Server (1), bevorzugt einem Content Delivery Network, abgespeichert sind.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass vorab für jede Konfiguration (K_p) des konfigurierbaren Objekts ein Video-Film mit m Video-Segmenten (VS_m) erstellt wird.
Computerprogramm für einen Server (13), dadurch gekennzeichnet, dass es ein Verfahren nach einem der vorhergehenden Ansprüche ausführt, wenn es auf einem Server, insbesondere einen Internet-Server (13), abläuft.
Speichermedium, dadurch gekennzeichnet, dass es ein Computerprogramm nach Anspruch 8 umfasst.
Computer, der als Internet-Server (13) eingesetzt wird, dadurch gekennzeichnet, dass er ein Verfahren nach einem der vorhergehenden Ansprüche ausführt.