DE102015002119B4 - Live-Videostreaming mit geringer Verzögerungszeit - Google Patents

Live-Videostreaming mit geringer Verzögerungszeit Download PDF

Info

Publication number
DE102015002119B4
DE102015002119B4 DE102015002119.2A DE102015002119A DE102015002119B4 DE 102015002119 B4 DE102015002119 B4 DE 102015002119B4 DE 102015002119 A DE102015002119 A DE 102015002119A DE 102015002119 B4 DE102015002119 B4 DE 102015002119B4
Authority
DE
Germany
Prior art keywords
video segments
video
request
segments
segment
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE102015002119.2A
Other languages
English (en)
Other versions
DE102015002119A1 (de
Inventor
Viswanathan Swaminathan
Sheng Wei
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Adobe Inc
Original Assignee
Adobe Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Adobe Inc filed Critical Adobe Inc
Publication of DE102015002119A1 publication Critical patent/DE102015002119A1/de
Application granted granted Critical
Publication of DE102015002119B4 publication Critical patent/DE102015002119B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2187—Live feed
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234318—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into objects, e.g. MPEG-4 objects
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/654—Transmission by server directed to the client
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

Computerimplementiertes Verfahren, umfassend:Erzeugen einer Mehrzahl von Videosegmenten eines Videostreams, wobei jedes Segment einen Abschnitt eines Multimediainhaltes darstellt, wenn die jeweiligen Abschnitte des Multimediainhaltes von einer Live-Inhaltsquelle empfangen werden;Empfangen, von einer Clientrechenvorrichtung, nur einer HTTP-Anfrage nach wenigstens zweien der Videosegmente; undPushen, von einem Servercomputer an die Clientrechenvorrichtung, der wenigstens zwei Videosegmente entsprechend einer vordefinierten Push-Strategie ohne die Notwendigkeit von separaten HTTP-Anfragen von dem Client für ein jedes der Videosegmente, wobei die Push-Strategie eine k-Push-Strategie ist, bei der der Client eine Anfrage nach k Videosegmenten ausgibt und der Server auf die Anfrage durch Pushen von bis zu k Segmenten, wenn jedes Segment verfügbar wird, antwortet, undwobei das Verfahren ferner Variieren der Anzahl k von Videosegmenten der k-Push-Strategie im Anschluss an das Pushen der wenigstens zwei Videosegmente umfasst.

Description

  • Gebiet der Offenbarung
  • Die vorliegende Offenbarung betrifft allgemein das Gebiet der Digitalmedienverteilung und insbesondere Techniken zum Live-Videostreaming mit geringer Verzögerungszeit.
  • Hintergrund
  • Videostreaming ist eine Multimediaform, die einem Anwender während der Übermittlung durch einen Provider präsentiert wird, was im Gegensatz zu einem einfachen Dateitransfer steht, der das Empfangen des gesamten Videoinhaltes vor dessen Abspielen impliziert. Das Hypertexttransferprotokoll (HTTP) wurde bislang als anpassbares und effizientes Protokoll zum Streaming von Videoinhalt über das Internet eingesetzt. HTTP-Live-Streaming (HLS), HTTP Dynamic Streaming (HDS) und Dynamic Adaptive Streaming over HTTP (DASH) sind Beispiele für bestehende Techniken zum Multimediastreamen von HTTP-Webservern. Der Videoinhalt wird in eine Folge von Dateisegmenten unterteilt. Unter Verwendung dieser Protokolle wird jedes Segment einzeln übermittelt. Bei bestehenden HTTP-Streaming-Techniken weisen die Segmente beispielsweise feste Intervalle auf, wobei jedes Segment als separate Ressource für HTTP-Anfragen und Antworten betrachtet wird. Im Ergebnis kann der Videoinhalt erst dann übermittelt und abgespielt werden, wenn das gesamte zugehörige Videosegment mit festem Intervall vollständig erzeugt ist. Eine Verzögerungszeit (latency) beim Live-Videostreaming (beispielsweise bei einem Live-Sportereignis) ist allgemein die Zeitdifferenz zwischen dem Punkt, zu dem das Live-Ereignis stattfindet, und dem Punkt, zu dem dieses beim Anwender abgespielt wird. Daher ist die Verzögerungszeit wenigstens gleich der Dauer eines Videosegmentintervalls und unterliegt zusätzlichen Pufferungs- und Netzwerkverzögerungen. Oftmals ist jedes Segment wenigstens einige Sekunden lang, was zu einer Verzögerungszeit von einigen 10 Sekunden führt. Derartige Verzögerungen sind, insbesondere bei zeitkritischen Live-Streaming-Szenarien, unerwünscht.
  • Die Druckschrift US 2006/0236387 A1 beschreibt ein Verfahren zur Übertragung einer HTTP-Antwort in mehreren unterschiedlichen Teilen, bei dem ein HTTP-Antwortstrom für eine Kommunikation offengehalten wird, sodass Teile einer Gesamtantwort, die einer einzelnen Anforderung entsprechen, über den HTTP-Antwortstrom gesendet werden können. Wenn die verschiedenen Teile der Gesamtantwort an einem entsprechenden Dienstendpunkt verfügbar werden, kapselt ein Dienst die Nachrichten entsprechend und sendet sie an den anfordernden Endpunkt. Der Empfänger ist dann in der Lage, die verfügbaren Teile der Antwort zu lesen, die eingebetteten Teile entsprechend zu dekodieren und diese nach Bedarf zu verarbeiten.
  • Die Druckschrift US 2011/0 080 940 A1 beschreibt ein Streamingsystem mit niedriger Latenz mittels eines zustandslosen Protokolls zwischen Client und Server. Der Server bettet inkrementelle Informationen in Medienfragmente ein, wodurch die Verwendung eines typischen Steuerungskanals entfällt. Darüber hinaus stellt der Server einheitliche Medienfragmentantworten auf Medienfragmentanforderungen bereit, sodass die vorhandene Internetcacheinfrastruktur Streaming-Mediendaten zwischenspeichern kann. Jedes Fragment verfügt über eine eindeutige URL (Uniform Resource Locator), mit der das Fragment sowohl von Internetcacheservern als auch vom Browsercache des Clients identifiziert und zwischengespeichert werden kann.
  • Es ist eine Aufgabe der Erfindung, ein verbessertes Verfahren und ein entsprechendes System zum Live-Videostreaming mit verringerter Zeitverzögerung bereitzustellen.
  • Die Aufgabe wird durch ein computerimplementiertes Verfahren und ein entsprechendes System mit den in den unabhängigen Ansprüchen angegebenen Merkmalen gelöst. Bevorzugte Ausführungsformen sind Gegenstand der Unteransprüche.
  • Kurzbeschreibung der Zeichnung
  • Die begleitende Zeichnung ist nicht notwendigerweise maßstabsgetreu. In der Zeichnung ist jede identische oder nahezu identische Komponente, die in verschiedenen Figuren dargestellt ist, mit dem gleichen Bezugszeichen bezeichnet.
    • 1 zeigt ein exemplarisches Client-Server-System zum Live-Videostreaming mit geringer Verzögerungszeit entsprechend einer Ausführungsform der vorliegenden Erfindung.
    • 2 zeigt ein Flussdiagramm für eine exemplarische Anfrage-Antwort-Videostreaming-Push-Strategie entsprechend einer Ausführungsform der vorliegenden Erfindung.
    • 3 zeigt ein Flussdiagramm für eine weitere exemplarische Anfrage-Antwort-Videostreaming-Push-Strategie entsprechend einer Ausführungsform der vorliegenden Erfindung.
    • 4 zeigt ein Flussdiagramm für wieder eine andere exemplarische Anfrage-Antwort-Videostreaming-Push-Strategie entsprechend einer Ausführungsform der vorliegenden Erfindung.
    • 5 zeigt eine exemplarische serverseitige methodische Vorgehensweise zum Live-Videostreaming mit geringer Verzögerungszeit entsprechend einer Ausführungsform der vorliegenden Erfindung.
    • 6 zeigt ein Beispiel für eine clientseitige methodische Vorgehensweise beim Live-Videostreaming mit geringer Verzögerungszeit entsprechend einer Ausführungsform der vorliegenden Erfindung.
    • 7 ist ein Blockdiagramm zur Darstellung einer exemplarischen Rechenvorrichtung, die entsprechend einer Ausführungsform der vorliegenden Erfindung Verwendung finden kann.
  • Detailbeschreibung
  • Wie vorstehend ausgeführt worden ist, wird bislang das HTTP-Streaming als Schema zum Übermitteln eines Videoinhaltes über das Internet eingesetzt. Dies beruht teilweise auf der Allgegenwart und Anpassungsfähigkeit von HTTP-Servern oder Caches. HTTP ist ein zustandsloses (stateless) Kommunikationsprotokoll. Im Allgemeinen ist ein zustandsloses Protokoll ein Kommunikationsprotokoll, das jede Anfrage nach Information als unabhängige Transaktion behandelt, die mit einer vorhergehenden Anfrage nicht in Zusammenhang steht, sodass die Kommunikation aus unabhängigen Paaren von Anfragen und Antworten besteht. Es gibt verschiedene Arten von Videostreamingdiensten, darunter das Live-Videostreaming. Das Live-Videostreaming ist die Übermittlung eines Videos eines Live-Ereignisses, so beispielsweise von Sportwettkämpfen. Idealerweise erfolgt ein derartiges Live-Streaming in Echtzeit (wo nahezu keine Verzögerung auftritt) oder in Beinahe-Echtzeit (wo die Verzögerung nicht merklich ist), wenn der Inhalt erzeugt wird. Daher sollte beim Live-Videostreaming die Video-Streamingauflösung eine vergleichsweise geringe Verzögerungszeit aufweisen. Bestehende HTTP-VideostreamingTechniken sind jedoch nicht für Anwendungen mit geringer Verzögerungszeit, so beispielsweise das Live-Videostreaming, geeignet, da die Segmentierung von Videoinhalt wenigstens eine Segmentverzögerung zwischen dem Server und dem Client einführt, da jedes Segment einzeln verpackt, angefordert und ausgeführt wird. Eine Lösung zum Verringern der Verzögerungszeit besteht in der Verringerung der Länge eines jeden Segmentes. Die Folge der Verringerung der Segmentlänge ist jedoch diese, dass die Anzahl von Segmenten proportional zunimmt (beispielsweise verdoppelt das Halbieren der Segmentlänge die Gesamtzahl von Segmenten). Da jedes Segment als separatere Ressource behandelt wird, nimmt die Anzahl von HTTP-Anfragen, die vom Client ausgegeben werden, mit der Anzahl von Segmenten zu. So sind beispielsweise für ein Live-Ereignis von 60 s, wenn die Segmentdauer gleich 4 s ist, insgesamt 15 Anfrage-Antwort-Paare vorhanden. Wenn jedoch die Segmentdauer auf 1 s verringert wird, wächst die Anzahl der Anfrage-Antwort-Paare auf 60 an. Entsprechend können sehr kleine Segmentdauern zu einer Explosion der Anzahl der HTTP-Anfragen und Antworten führen. Da jede Anfrage und Antwort einen Verarbeitungsmehraufwand für den Client, den Server und die Netzwerkinfrastruktur mit sich bringt, kann diese einfache Lösung in ausreichendem Maße keine Verringerung der Verzögerungszeit bringen.
  • Zu diesem Zweck werden hier Techniken zum Videostreaming mit geringer Verzögerungszeit offenbart. Entsprechend einer Ausführungsform der vorliegenden Erfindung kann ein Client dafür ausgelegt sein, eine einzelne Anfrage zum Live-Videostreaming an einen Server zu senden. Der Server kann dafür ausgelegt sein, ein oder mehrere Videosegmente an den Client entsprechend einer vordefinierten Push-Strategie zu senden oder zu pushen. So sendet der Client beispielsweise unter Verwendung einer so genannten All-Push-Strategie nur eine Anfrage an den Server, wobei als Antwort der Server alle Videosegmente an den Client pusht, sobald jedes Segment vollständig ist. Andere Push-Strategien, so beispielsweise diejenigen, die nachstehend noch detailliert beschrieben werden, können ebenfalls verwendet werden. Die Videosegmente können unter Verwendung eines zustandslosen Kommunikationsprotokolls, so beispielsweise HTTP 2.0, gepusht werden. Diese Technik beseitigt das Problem der Explosion von Anfragen, wenn kleine Segmente verwendet werden. Des Weiteren kann die Anzahl von Segmenten, die bei jeder Anfrage gepusht werden, bei einigen Ausführungsformen variiert werden, um so für Clients einen Weg bereitzustellen, auf die geeigneten Bitratensegmente zu schalten, während der Mehraufwand gesteuert bzw. geregelt wird. Zahlreiche Ausgestaltungen und Abwandlungen ergeben sich im Lichte dieser Offenbarung.
  • Im Sinne des Vorliegenden beinhalten die Begriffe „Inhalt“ (content) und „Multimediainhalt“ (multimedia content) Audio-, Video-, Standfotografie-, Daten-, Grafik- oder beliebige andere Information, die in einem beliebigen Netzwerkinformationssystem, so beispielsweise dem World Wide Web, identifiziert, adressiert, referenziert oder verarbeitet werden kann, oder auch beliebige Information, die von einem Veröffentlicher (publisher) an einen Endanwender über ein physisches Medium, so beispielsweise ein tragbares USB-Laufwerk, CD, DVD oder eine Blue-Ray Disk, übermittelt werden kann. Im Allgemeinen beinhaltet ein Inhalt eine beliebige Form von Information in digitaler Form. Inhalt kann jedoch auch in nicht digitalen Formen (beispielsweise analog) oder in einer Kombination aus digitalen und nicht digitalen Formen verkörpert sein. Der Begriff „Video“ soll im Sinne des Vorliegenden alle Typen von Multimediainhalt einschließen.
  • HTTP 2.0 ist im Sinne des Vorliegenden eine Version des HTTP-Kommunikationsprotokolls, das beispielsweise vom World Wide Web verwendet wird. HTTP 2.0 wird von der Internet Engineering Task Force (IETF) unter Verwendung von SPDY™ von Google, Inc. als Ausgangspunkt standardisiert. Im Vergleich zu HTTP 1.1 ermöglicht HTTP 2.0 beispielsweise eine viel effizientere Nutzung von Netzwerkressourcen und eine verringerte Wahrnehmbarkeit der Verzögerungszeit unter Verwendung einer Headerfeld-Kompression und erlaubt mehrere gleichzeitige Nachrichten auf derselben Verbindung. HTTP 2.0 unterstützt zudem nicht angefordertes (unsolicited) Pushen (pushes) von Daten von Servern an Clients. HTTP 2.0 ist jedoch nicht für Videostreaming-Anwendungen konzipiert, und der Server-Push-Mechanismus kann nicht direkt zum Videostreaming eingesetzt werden. Zu diesem Zweck ermöglichen die hier offenbarten Techniken für HTTP 2.0 eine server-push-basierte Übermittlung von Live-Videostreaming-Anwendungen, darunter denjenigen, die beispielsweise HDS-, HLS- und DASH-basierte Clients, einsetzen.
  • Im Sinne des Vorliegenden bezeichnen die Begriffe „push bzw. pushartig bzw. pushartige Übertragung“ (push) und „Server-Push“ allgemein eine netzwerkbasierte Kommunikation, wo Live-Videosegmente aktiv von einem Webserver zu einem Client gepusht werden können, wenn Segmente verfügbar werden, ohne dass die Notwendigkeit von separaten HTTP-Anfragen von dem Client für jedes Segment notwendig wären. Bei einer hier vorgestellten besonderen exemplarischen Ausführungsform pusht eine Live-Server-Push-Strategie mehrere Videosegmente nach dem Empfangen einer einzelnen Anfrage. Auf diese Weise kann der Effekt eines Livestreaming mit geringer Verzögerungszeit durch Verringern der Segmentdauer erreicht werden, ohne dass dies mit einem stark vergrößerten Anfragesaufwand von mehreren Anfragen einherginge. Ein Push-Dienst steht im Gegensatz zu einem Pull-Dienst, wo die Übertragung eines jeden einzelnen Segmentes durch eine separate Anfrage vom Empfänger der Daten (beispielsweise einem Client des Servers) initiiert wird. Ein Beispiel für einen Push-Dienst, der beim Vorliegenden Verwendung finden kann, ist ein HTTP-2.0-Server-Push, der allgemein ein Senden von nicht angeforderten oder asynchronen Daten von einem Webserver an einen Webbrowser beinhaltet. Wie sich im Lichte der vorliegenden Offenbarung ergibt, muss ein Server, der einen Live-Videoinhalt-Push-Dienst bereitstellt, nicht notwendigerweise eine Verbindung mit einem Client beenden, nachdem ein erstes Segment der Live-Videodaten an den Client gepusht worden ist. Anstatt dessen kann der Webserver die Verbindung offen lassen, damit dann, wenn ein Ereignis eintritt (neuer Inhalt verfügbar wird), dieses unmittelbar unter Verwendung der bestehenden Verbindung ausgesendet werden kann.
  • Bestehende Versionen von HTTP-basierten Videostreamingtechniken, darunter HLS, HDS, Smooth Streaming und DASH, sind bislang nicht für die Verwendung mit dem Server-Push-Merkmal von HTTP 2.0 ausgelegt oder optimiert. Daher wird entsprechend einer Ausführungsform eine Technik zum Live-Videostreaming bereitgestellt, die eine Live-Server-Push-Strategie in einem zustandslosen Kommunikationsprotokoll, so beispielsweise HTTP 2.0, verwendet. Der Live-Videoinhalt wird in eine Folge von HTTP-basierten Dateisegmenten zerlegt. Jedes Segment enthält ein kurzes Abspielzeitintervall (beispielsweise in der Größenordnung von Sekunden) von Videoinhalt, dessen Dauer gegebenenfalls viele Minuten oder Stunden ist, so beispielsweise wie bei einer Live-Übertragung eines Sportereignisses. Der Push-Server empfängt eine Push-Marker-Anfrage von einem Videoclient (beispielsweise einem DASH-Client), um zu bestimmen, welche Segmente pushartig verschoben werden sollen. Der Push-Marker kann beispielsweise in einer Lightweight-GET-Anfrage beinhaltet sein, die die Anfangs- und Endsegmentnummern angibt, die der Videoclient anfordert. Der Videoclient kann die Push-Marker-Anfragen zu bestimmten Zeiten senden, die durch eine gegebene Push-Strategie mit geringer Verzögerungszeit, die dem zugeordnet ist, bestimmt sind. Sobald die gepushten Videosegmente vom HTTP-Stapel (stack) des Videoclients empfangen werden, können sie abgespielt oder zusätzlich und alternativ in einem Cache (beispielsweise Client) gespeichert werden. Wenn sodann der Videoclient bereit ist, den bereits gepushten Inhalt abzuspielen, kann er diesen Inhalt aus dem Cache beziehen, ohne dass er eine weitere Anfrage an den Push-Server aussenden müsste.
  • Entsprechend einer weiteren Ausführungsform der vorliegenden Erfindung wird eine methodische Vorgehensweise zum Videostreaming unter Verwendung eines Server-Push-Schemas bereitgestellt, das von HTTP 2.0 unterstützt wird. Insbesondere beinhaltet das Verfahren ein Verringern der Segmentgröße des Videostreams entsprechend einer gegebenen Push-Strategie, bis die gewünschte Verzögerungszeit erreicht ist, während Effekte des Aufwandes und der Unterstützung eines dynamischen Bitratenschaltens berücksichtigt werden. Die Push-Strategie kann eine No-Push-, eine All-Push- oder eine k-Push-Strategie beinhalten. Die No-Push-Strategie ist eine Strategie, bei der der Client eine HTTP-Anfrage nach einem jeden Videosegment sendet und der Server auf jede Anfrage durch Senden des entsprechenden Segmentes an den Client antwortet. Die All-Push-Strategie ist eine Strategie, bei der der Client nur eine Anfrage nach dem gesamten Live-Videostream ausgibt und der Server auf die Anfrage durch aktives Pushen eines jeden Videosegmentes, wenn dieses verfügbar wird, antwortet. Die k-Push-Strategie ist eine Strategie, bei der der Client eine Anfrage nach k Videosegmenten ausgibt und der Server auf die Anfrage durch Pushen von bis zu k Segmenten, wenn jedes Segment verfügbar wird, antwortet. Ein Variieren von k beim k-Push kann verwendet werden, um sicherzustellen, dass der Client die geeignete Fähigkeit zum Schalten zu einer anderen Bitrate/Auflösung, so diese gewünscht ist, hat. Das Schalten kann beim Client durch Senden der nächsten HTTP-Anfrage nach einer anderen Bitrate/Auflösung des Videosegmentes erfolgen. Durch Konfigurieren des Wertes von k können die Fähigkeit und der Aufwand (beispielsweise die Schaltverzögerung) des Clients gesteuert bzw. geregelt werden. Bei einigen Ausführungsformen können zwei oder mehr weitere Push-Strategien für einen gegebenen Live-Videostream kombiniert werden, und zwar beispielsweise unter Verwendung einer k-Push-Strategie für eine gewisse Zeitperiode, gefolgt von einer All-Push-Strategie oder einer No-Push-Strategie. Andere Push-Strategien und Kombinationen hieraus können ebenfalls eingesetzt werden und ergeben sich im Lichte der vorliegenden Offenbarung.
  • Bei einigen Ausführungsformen kann der Inhalt zur Übermittlung vom Push-Server an den Client bei einer Vielzahl von verschiedenen Bitraten und Auflösungen verfügbar gemacht werden, um so den dynamischen Bitratenschaltaspekt des HTTP-Streamings oder des adaptiven Bitratenstreamings zu emulieren. Bei einer derartigen Ausführungsform bestimmt, wenn der Inhalt durch einen Videoclient abgespielt wird, der Push-Server automatisch die geeignete Bitrate für das nächste Segment auf Grundlage von aktuellen Netzwerkbedingungen (beispielsweise Änderungen der verfügbaren oder nutzbaren Bandbreite). Der Push-Server kann beispielsweise die geringste Bitrate und damit das kleinstmögliche Segment auswählen, das jeweils zum Abspielen heruntergeladen werden kann, ohne Bildeinfrier- (stalls) oder Umpufferungsvorgänge zu verursachen, die das Abspielen unterbrechen oder auf andere Weise die Abspielverzögerungszeit vergrößern würden. Die Schaltentscheidung kann durch den Client dynamisch gefällt werden, wenn der Client seine Netzwerkbedingung überwacht. Sobald der Client bestimmt, dass auf eine andere Bitrate und Auflösung geschaltet wird, sendet er die nächste HTTP-Anfrage nach jener Bitrate/Auflösung des Videosegmentes. Der Server ist zustandslos und kann auf HTTP-Anfragen des Clients bezüglich bestimmter Segmente bei der angeforderten Bitrate/Auflösung antworten.
  • Exemplarisches System zum Videostreaming mit geringer Verzögerungszeit
  • 1 zeigt ein exemplarisches Client-Server-System 100 zum Videostreaming mit geringer Verzögerungszeit entsprechend einer Ausführungsform. Das System 100 beinhaltet einen Live-Videoverpacker (live video packager) 110 (beispielsweise einen HDS-, HLS- oder DASH-basierten Verpacker oder einen anderen geeigneten Verpacker), einen Webserver 120, der SPDY (beispielsweise Jetty) unterstützt, und eine Clientrechenvorrichtung 130. Die Clientrechenvorrichtung 130 beinhaltet eine Videoabspieleinrichtung 132 (beispielsweise eine DASH-Abspieleinrichtung oder eine andere geeignete Videoabspieleinrichtung) und einen Browser 134 (beispielsweise einen Web-Browser auf Basis von Google Chromium SPDY oder eine andere geeignete HTTP-kompatible Anwendung). Der Webserver 120 ist in Kommunikation mit dem Client 130 über ein Kommunikationsnetzwerk 140, so beispielsweise das Internet oder ein anderes geeignetes Bereichs- oder Ortsnetzwerk. Eine Live-Inhaltsquelle 110 liefert einen Videoinhalt 114 an den Verpacker 110. Die Live-Inhaltsquelle 112 kann bei einigen Ausführungsformen eine derartige Vorrichtung beinhalten oder mit dieser operativ verbunden sein, die ein Video und ein Audio (beispielsweise über eine Kamera beziehungsweise ein Mikrofon) eines Ereignisses, so beispielsweise eines Sportereignisses, einer Pressekonferenz oder einer Bühnenaufführung, aufnimmt. Bei einigen Ausführungsformen kann der Verpacker 110 innerhalb des Webservers 120 integriert sein. Bei anderen Ausführungsformen kann der Verpacker 110 auf einem Server oder einer anderen Rechenvorrichtung (nicht gezeigt) untergebracht sein, der/die in Kommunikation mit dem Webserver 120 entweder direkt oder über das Netzwerk 140 ist. Bei einigen Ausführungsformen kann ein Cache 150 mit der Clientrechenvorrichtung 130 zum Speichern von HTTP-Ressourcen 152, so beispielsweise einem Videoinhalt, der von dem Webserver 120 gepusht wird, verknüpft sein. Der Cache 150 kann beispielsweise zum temporären Speichern von Videosegmenten, wenn diese empfangen werden, verwendet werden. Der Videoabspieleinrichtung 132 kann sodann auf den Cache 150 zugreifen und die Videosegmente zum Abspielen abrufen.
  • Bei Verwendung stellt das System 100 eine Client-Server-Umgebung zum Videostreaming mit geringer Verzögerungszeit unter Verwendung einer Server-Push-Strategie bereit. Der Verpacker 110 ist operativ dafür ausgelegt, den Videoinhalt 114 auf eine zur Sendung an den Client 130 geeignete Weise (beispielsweise unter Verwendung eines dateisegmentebasierten Schemas wie DASH, HDS und dergleichen mehr) zu verpacken. Anstatt des Initiierens einer Anfrage nach einem jeden Videosegment, wie dies bei bestehenden Techniken erfolgt, kann bei einer exemplarischen Ausführungsform der Webserver 120 dafür ausgelegt sein, jedes Videosegment aktiv nach dem Empfangen der ersten Anfrage nach dem Videostreaming entsprechend einer vordefinierten Push-Strategie zu pushen. Auf diese Weise ist es für den Client möglich, die Anzahl von HTTP-Anfragen an den Server auf eine vernünftige kleine Anzahl zu verringern, so beispielsweise auf eine Anfrage nach dem gesamten Videostream oder eine Anfrage nach mehreren Videosegmenten. Des Weiteren beseitigt dadurch, dass dem Server ermöglicht wird, den verpackten Inhalt 152 an den Client über HTTP zu pushen, diese exemplarische methodische Vorgehensweise die umgekehrt proportionale Korrelation zwischen der Segmentdauer und der Anzahl von Anfragen bezüglich einer bestimmten Länge eines Videos, was, wie vorstehend erläutert worden ist, die Verringerung der Verzögerungszeit effektiv begrenzt. Daher kann diese exemplarische methodische Vorgehensweise die Verzögerungszeit des Live-Videostreamings durch Verringern der Segmentdauer und durch Verwenden einer kleinen Anzahl von Anfragen an den Server (beispielsweise eine Anfrage) verringern, um die Verringerung der Verzögerungszeit zu verbessern.
  • Der Webserver 120 kann mit einer verweiserbasierten (referrer-based) Push-Strategie ausgestaltet sein, wo der Server den gesamten Inhalt, der derselben Verweiser (referrer) im HTTP-Header aufweist, beim Empfangen der Anfrage des Verweisers URL pusht. Diese Push-Strategie arbeitet ausreichend gut bei regulärem Webinhalt (beispielsweise Inhalt, der kein Video-Live-Streaming ist, so beispielsweise bei einer Webpage), da ein Großteil des zugehörigen Webinhaltes, der gepusht werden muss, in der Hauptressource, auf die verwiesen wird, eingebettet ist. Gleichwohl wird die verweiserbasierte Push-Strategie wenigstens aus den nachfolgenden Gründen nicht beim Videostreaming eingesetzt. Erstens erfordern bestehende Videoabspieleinrichtungen aufeinanderfolgende unabhängige Videosegmente anstelle von eingebetteten Ressourcen, weshalb die gepushten Ressource nicht auf dem Verweiser zum Videostreaming beruhen kann. Zweitens wird beim Live-Videostreaming der Inhalt (beispielsweise die Videosegmente) in Echtzeit erzeugt, weshalb sie nicht gepusht werden können, bis sie erzeugt sind. Drittens bleibt bei dem bestehenden Server-Push-Schema die Anfrage nach der Hauptressource anhängig, bis der gesamte angeforderte Inhalt an den Client gepusht ist. Dies genügt nicht den Erfordernissen des Live-Videostreamings und insbesondere der Erfordernis einer geringen Verzögerungszeit.
  • Daher kann entsprechend einer Ausführungsform der Webserver 120 zum Videostreaming mit geringer Verzögerungszeit unter Verwendung einer Push-Strategie, die nicht auf Verweisern beruht, ausgestaltet sein. Es kann beispielsweise anstelle des Wartens auf eine Anfrage eines Verweisers URL der Webserver 120 eine spezielle Push-Marker-Anfrage von dem Client einsetzen, um die gepushten Ressourcen zu bestimmen. In einigen Fällen kann der Push-Marker eine Lightweight-HTTP-GET-Anfrage sein, die die Anfangs- und Endsegmentnummern angibt, deren Empfang über einen Push-Dienst von dem Webserver 120 der Client 130 erwartet. Des Weiteren kann in einigen Fällen der Client 130 den Push-Marker als Mitteilung in einer Richtung (one-way message) verwenden, ohne eine Antwort zu erwarten oder synchron auf diese zu warten. Auf diese Weise wird der gepushte Inhalt nicht durch eine anhängige Push-Marker-Anfrage blockiert, und entsprechend kann das Live-Videostreaming beginnen, sobald das erste Videosegment verfügbar wird. Des Weiteren kann in einigen Fällen der Zeitpunkt bzw. die Zeittaktung (timing) bei der Ausführung der Push-Strategie während des Streamings variiert werden, sodass der Server 120 die Live-Videosegmente einzeln pushen kann, sobald diese von dem Inhaltsverpacker 110 erzeugt werden.
  • Bei einer exemplarischen Ausführungsform kann die Videoabspieleinrichtung 132 dafür ausgelegt sein, die spezielle Push-Marker-Anfrage zu bestimmten Zeiten zu senden, die von dem verwendeten Schema mit geringer Verzögerungszeit bestimmt werden. Sobald der gepushte Inhalt 152 von dem Browser 134 empfangen wird, kann er in dem Cache 150 des Clients 130 gespeichert werden. Wenn sodann der Client 130 den bereits gepushten Inhalt 152 anfordert, kann er den Inhalt 152 aus seinem Cache beziehen, ohne dass er eine weitere Anfrage an den Webserver 120 senden müsste.
  • Exemplarische Push-Strategien
  • 2 zeigt einen Flussdiagramm 200 für eine exemplarische Anfrage-Antwort-Videostreaming-Push-Strategie entsprechend einer Ausführungsform der vorliegenden Erfindung. Bei diesem Beispiel wird eine All-Push-Strategie beschrieben. Bei einer All-Push-Strategie gibt der Client 130 nur eine Anfrage nach dem gesamten Live-Videostream aus. Beim Empfangen der Anfrage pusht der Server 120 aktiv alle Videosegmente, sobald diese bereit sind. Der Server 120 kann kontinuierlich Segmente an den Client 130 bei Abwesenheit von weiteren Anfragen nach dem Videostream pushen. Der Client 130 kann an den Server 120 beispielsweise eine Anfrage (202) bezüglich der Segmente 1 bis n des Videostreams senden, wobei n das letzte Segment des Videos darstellt. Für ein Live-Video kann n unbestimmt sein, bis das Live-Ereignis beendet ist. Des Weiteren kann n in Abhängigkeit von der Länge eines jeden Segmentes variieren. Als Antwort auf die Anfrage (202) kann der Server 120 das Segment 1 (204), das Segment 2 (206) und so weiter bis zu dem Segment n (208) pushen, wenn jedes Segment zum Pushen an den Client 130 erzeugt oder auf andere Weise verfügbar wird.
  • 3 zeigt ein Flussdiagramm 300 für eine exemplarische Anfrage-Antwort-Videostreaming-Push-Strategie entsprechend einer Ausführungsform der vorliegenden Erfindung. Bei diesem Beispiel wird die No-Push-Strategie beschrieben. Bei der No-Push-Strategie gibt der Client 130 eine Anfrage nach einem jeden Segment in dem Live-Videostream aus. Beim Empfangen der Anfrage pusht der Server 120 nur das angeforderte Videosegment. Der Server 120 pusht Segmente nicht kontinuierlich an den Client 130 bei Abwesenheit von weiteren Anfragen nach dem Videostream. Der Client 130 kann an den Server 120 beispielsweise eine Anfrage (302) bezüglich des Segmentes 1 des Videostreams senden. Als Antwort auf die Anfrage (302) kann der Server 120 das Segment 1 (304) pushen, wenn das Segment zum Pushen an den Client 130 erzeugt oder auf andere Weise verfügbar wird. Der Client 130 kann sodann an den Server 120 eine Anfrage (306) bezüglich des Segmentes 2 des Videostreams und weitere derartige Anfragen bezüglich zusätzlicher Segmente bis zum Segment n (310) senden, wobei n das letzte Segment des Videos darstellt. Der Server 120 antwortet auf jede Anfrage (302, 306, 310) durch Pushen des entsprechenden Segmentes an den Client 130 (304, 308, 312).
  • 4 zeigt ein Flussdiagramm 400 für eine exemplarische Anfrage-Antwort-Videostreaming-Push-Strategie entsprechend einer Ausführungsform der vorliegenden Erfindung. Bei diesem Beispiel wird die k-Push-Strategie beschrieben. Bei der k-Push-Strategie gibt der Client 130 eine Anfrage nach den nächsten verfügbaren k Segmenten des Live-Videostreams aus. Beim Empfangen der Anfrage pusht der Server 120 aktiv die nächsten k Videosegmente, sobald diese bereit sind. Der Server 120 kann kontinuierlich Segmente an den Client 130 bei Abwesenheit von weiteren Anfragen bezüglich des Videostreams bis zum k-ten Segment pushen. Der Client 130 kann an den Server 120 beispielsweise eine Anfrage (402) bezüglich der Segmente 1 bis k des Videostreams senden. Als Antwort auf die Anfrage (402) kann der Server 120 das Segment 1 (404), das Segment 2 (406) und so weiter bis zum Segment k (408) pushen, wenn jedes Segment zum Pushen an den Client 130 erzeugt oder auf andere Weise verfügbar wird. Zu jedem Zeitpunkt kann der Client 130 an den Server 120 eine Anfrage (410) bezüglich weiterer k Segmente des Videostreams (beispielsweise Segment n-k+1 bis Segment n) senden. Als Antwort auf die Anfrage (410) kann der Server 120 die nächsten k Segmente, wenn jedes Segment erzeugt oder zum Pushen verfügbar wird, bis einschließlich zu dem Segment n pushen.
  • Exemplarische serverseitige und clientseitige methodische Vorgehensweisen
  • 5 zeigt eine exemplarische serverseitige methodische Vorgehensweise 500 zum Videostreamen mit geringer Verzögerungszeit entsprechend einer Ausführungsform. Das Verfahren 500 kann beispielsweise auf dem Webserver 120 von 1 implementiert sein. Das Verfahren 500 beginnt mit dem Erzeugen (510) einer Mehrzahl von Videosegmenten, die jeweils einen Abschnitt eines Multimediainhaltes darstellen. Die Videosegmente können verschiedene aufeinanderfolgende Zeitperioden des Multimediainhaltes darstellen. Jedes Segment kann beispielsweise erzeugt werden, wenn die jeweiligen Abschnitte des Multimediainhaltes von einer Live-Inhaltsquelle, so beispielsweise der Videoquelle 112 von 1, empfangen werden, oder auch zu einem nachfolgenden Zeitpunkt. Weiter geht das Verfahren 500 mit einem von einer Clientrechenvorrichtung (beispielsweise dem Client 130 von 1) erfolgenden Empfangen einer Anfrage nach wenigstens einem der Videosegmente (520). Bei einigen Ausführungsformen wird nur eine HTTP-Anfrage nach wenigstens zweien der Videosegmente empfangen. Als Antwort auf die Anfrage geht das Verfahren 500 weiter mit einem Pushen (530) eines jeden der angeforderten Segmente an die Clientrechenvorrichtung entsprechend einer vordefinierten Push-Strategie (beispielsweise einer All-Push-, einer No-Push- oder einer k-Push-Strategie, wie vorstehend anhand 2, 3 und 4 beschrieben worden ist). Bei einigen Ausführungsformen werden die wenigstens zwei angeforderten Videosegmente ohne die Notwendigkeit von separaten HTTP-Anfragen von der Clientrechenvorrichtung für jedes der Videosegmente gepusht. Die Videosegmente können in einigen Fällen unter Verwendung eines zustandslosen Kommunikationsprotokolls, so beispielsweise von HTTP 2.0, gepusht werden. Dieser Prozess des Empfangens (520) und des Pushens (530) kann unendlich fortgesetzt werden (beispielsweise bis der gesamte Videostream gepusht worden ist). Bei einigen Ausführungsformen können die Videosegmente asynchron in Bezug auf das Empfangen der Anfrage (520) gepusht werden (530). Bei einigen Ausführungsformen können die Bitrate und Auflösung eines jeden Videosegmentes als Antwort auf eine Änderung einer Netzwerkbedingung (beispielsweise einer Änderung der Bandbreitenverfügbarkeit, des Netzwerkverkehrs, der CPU-Nutzung und dergleichen mehr) variieren. Bei einigen Ausführungsformen kann das Erzeugen von Videosegmenten (510) parallel mit dem Empfangen der Anfrage (520) und dem Pushen der angeforderten Segmente (530), die bereits erzeugt worden sind, erfolgen. Es sollte einsichtig sein, dass einige oder alle der verschiedentlich in diesem Absatz beschriebenen Funktionen in einer beliebigen Reihenfolge und zu einer beliebigen Zeit von einem oder mehreren verschiedenen Prozessoren durchgeführt werden können.
  • Bei einigen Ausführungsformen kann die Anfrage eine HTTP-GET-Anfrage beinhalten, die die Anfangs- und Endsegmente innerhalb der Mehrzahl von Videosegmenten, die an den Client gepusht werden sollen, beinhalten. Das Segment kann das letzte der Videosegmente (beispielsweise wie bei der All-Push-Strategie) oder ein beliebiges Segment, das nicht das erste oder letzte Videosegment (beispielsweise wie bei der k-Push-Strategie) ist, sein. Alternativ können die Anfangs- und Endsegmente der Anfrage dasselbe Segment (beispielsweise wie bei der No-Push-Strategie) sein. Codiert werden kann jedes der Videosegmente entsprechend einem dateifragmentebasierten Segmentierungsschema, so beispielsweise einem dynamischen adaptiven MPEG-Streaming über HTTP (DASH) und einem dynamischen HTTP-Streaming (HDS), oder einem streamfragmentebasierten Segmentierungsschema, so beispielsweise einem HTTP-Live-Streaming (HLS).
  • 6 zeigt eine exemplarische clientseitige methodische Vorgehensweise 600 zum Videostreaming mit geringer Verzögerungszeit entsprechend einer Ausführungsform. Das Verfahren 600 kann beispielsweise auf der Clientrechenvorrichtung 130 von 1 implementiert sein. Das Verfahren 600 beginnt mit einem an einen Server (beispielsweise den Webserver 120 von 1) erfolgenden Senden (610) einer Anfrage nach einem Videosegment. Bei einigen Ausführungsformen wird nur eine HTTP-Anfrage an den Server bezüglich wenigstens zweier der Videosegmente gesendet. Das Videosegment / die Videosegmente stellt/stellen einen Abschnitt eines Multimediainhaltes dar, der beispielsweise von der Live-Inhaltsquelle 112 von 1 bereitgestellt wird. Das Videosegment / die Videosegmente kann/können eine andere aufeinanderfolgende Zeitperiode in Bezug auf andere Videosegmente des Multimediainhaltes darstellen. Das Videosegment / die Videosegmente kann/können beispielsweise erzeugt werden, wenn die jeweiligen Abschnitte des Multimediainhaltes von einer Live-Inhaltsquelle, so beispielsweise der Videoquelle 112 von 1, empfangen werden, oder zu einem nachfolgenden Zeitpunkt. Weiter geht das Verfahren 600 mit dem Empfangen (620) des angeforderten Videosegmentes / der angeforderten Videosegmente von dem Server entsprechend einer vordefinierten Push-Strategie (beispielsweise einer All-Push-, einer No-Push oder einer k-Push-Strategie, wie vorstehend anhand 2, 3 und 4 beschrieben worden ist). Bei einigen Ausführungsformen werden die wenigstens zwei angeforderten Videosegmente ohne die Notwendigkeit von separaten HTTP-Anfragen von der Clientrechenvorrichtung bezüglich eines jeden der Videosegmente empfangen. Das Empfangen kann in einigen Fällen unter Verwendung eines zustandslosen Kommunikationsprotokolls, so beispielsweise von HTTP 2.0, durchgeführt werden. Weiter geht das Verfahren mit dem Abspielen (630) des Multimediainhaltes unter Verwendung des empfangenen Videosegmentes / der empfangenen Videosegmente. Dieser Prozess des Anforderns (610), des Empfangens (620) und des Abspielens (630) (beispielsweise für eine k-Push- oder No-Push-Strategie) oder des Empfangens (620) und des Abspielens (630) (beispielsweise für eine All-Push-Strategie) kann unendlich fortgesetzt werden (beispielsweise bis der gesamte Videostream empfangen und abgespielt worden ist). Bei einigen Ausführungsformen können die Videosegmente asynchron in Bezug auf das Senden der Anfrage (610) empfangen (620) werden. Bei einigen Ausführungsformen können die Bitrate und Auflösung eines jeden Videosegmentes als Antwort auf eine Änderung einer Netzwerkbedingung (Änderung bei der Bandbreitenverfügbarkeit, dem Netzwerkverkehr, der CPU-Nutzung und dergleichen mehr) variieren. Codiert werden kann jedes der Videosegmente entsprechend einem dateifragmentebasierten Segmentierungsschema, so beispielsweise einem dynamischen adaptiven MPEG-Streaming über HTTP (DASH), einem dynamischen HTTP-Streaming (HDS), oder einen streamfragmentebasierten Segmentierungsschema, so beispielsweise einem HTTP-Live-Streaming (HLS). Es sollte einsichtig sein, dass einige oder alle der verschiedentlich in diesem Absatz beschriebenen Funktionen in einer beliebigen Reihenfolge und zu einer beliebigen Zeit von einem oder mehreren verschiedenen Prozessoren durchgeführt werden können.
  • Exemplarische Rechenvorrichtung
  • 7 ist ein Blockdiagramm zur Darstellung einer exemplarischen Rechenvorrichtung 1000, die zum Durchführen einer beliebigen der hier verschiedentlich beschriebenen Techniken verwendet werden kann. Beispielsweise können der Verpacker 110, der Webserver 120, die Clientrechenvorrichtung 130 oder eine beliebige Kombination hieraus (gemäß Beschreibung in Bezug auf 1) in der Rechenvorrichtung 1000 implementiert sein. Die Rechenvorrichtung 1000 kann ein beliebiges Computersystem sein, so beispielsweise eine Workstation, ein Desktopcomputer, ein Server, ein Laptop, ein Handcomputer, ein Tabletcomputer (beispielsweise der Tabletcomputer iPad™), eine Mobilrechen- oder Kommunikationsvorrichtung (beispielsweise die Mobilkommunikationsvorrichtung iPhone™, die Mobilkommunikationsvorrichtung Android™ und dergleichen mehr), oder eine andere Form von Rechen- oder Telekommunikationsvorrichtung, die zu einer Kommunikation fähig ist und eine ausreichende Prozessorleistung und Speicherkapazität zur Durchführung der hier beschriebenen Operationen aufweist. Es kann auch ein verteiltes Rechensystem zum Einsatz kommen, das eine Mehrzahl von derartigen Rechenvorrichtungen umfasst.
  • Die Rechenvorrichtung 1000 beinhaltet ein oder mehrere Speichervorrichtungen 1010 und/oder nichttemporäre computerlesbare Medien 1020, auf denen eine oder mehrere computerausführbare Anweisungen oder Software zum Implementieren von Techniken, die hier verschiedentlich beschrieben sind, codiert sind. Beinhalten können die Speichervorrichtungen 1010 einen Computersystemspeicher oder einen Speicher mit wahlfreiem Zugriff, so beispielsweise eine dauerhaften Plattenspeicher (der eine beliebige optische oder magnetische dauerhafte Speichervorrichtung beinhalten kann, so beispielsweise RAM, ROM, Flash, USB-Laufwerk oder ein anderes halbleiterbasiertes Speichermedium), ein Festplattenlaufwerk, CD-ROM oder andere computerlesbare Medien zum Speichern von Daten und computerlesbaren Anweisungen und/oder Software zum Implementieren von verschiedenen Ausführungsformen gemäß vorliegender Lehre. Die Speichervorrichtung 1010 kann andere Typen von Speicher oder Kombinationen hieraus beinhalten. Die Speichervorrichtung 1010 kann auf der Rechenvorrichtung oder auch separat oder entfernt von der Rechenvorrichtung vorgesehen sein. Die nichttemporären computerlesbaren Medien 1012 können beispielsweise unter anderem einen oder mehrere Typen von Hardwarespeicher, nichttemporäre physische Medien (beispielsweise eine oder mehrere Magnetspeicherplatten, eine oder mehrere optische Platten, eine oder mehrere USB-Flash-Laufwerke) und dergleichen beinhalten. Die nichttemporären computerlesbaren Medien 1012, die in der Rechenvorrichtung 1000 beinhaltet sind, können computerlesbare und computerausführbare Anweisungen oder Software zum Implementieren von verschiedenen Ausführungen speichern. Die computerlesbaren Medien 1012 können auf der Rechenvorrichtung 1000 oder separat oder entfernt von der Rechenvorrichtung vorgesehen sein.
  • Die Rechenvorrichtung 1000 beinhaltet zudem wenigstens einen Prozessor 1020 zum Ausführen von computerlesbaren, computerausführbaren Anweisungen oder Software mit Speicherung in der Speichervorrichtung und/oder nichttemporäre computerlesbare Medien und andere Programme zum Steuern bzw. Regeln von Systemhardware. Es kann eine Virtualisierung in der Rechenvorrichtung 1000 eingesetzt werden, damit die Infrastruktur und Ressourcen in der Rechenvorrichtung gemeinsam dynamisch genutzt werden können. So kann eine virtuelle Maschine beispielsweise vorgesehen sein, um einen Prozess, der auf mehreren Prozessoren läuft, derart zu verwalten, dass der Prozess derart wirkt, dass er nur eine Rechenressource anstatt mehrerer Rechenressourcen verwendet. Mehrere virtuelle Maschinen können ebenfalls mit einem Prozessor verwendet werden.
  • Ein Anwender kann mit der Rechenvorrichtung 1000 über eine Ausgabevorrichtung 1030, so beispielsweise einen Bildschirm oder Monitor, interagieren, der ein oder mehrere Anwenderschnittstellen anzeigen kann, die entsprechend einigen Ausführungsformen bereitgestellt werden. Die Ausgabevorrichtung 1030 kann zudem andere Aspekte, Elemente und/oder Informationen oder Daten im Zusammenhang mit den Ausführungsformen anzeigen. Die Rechenvorrichtung 1000 kann weitere I/O-Vorrichtungen 1040 zum Empfangen einer Eingabe von einem Anwender beinhalten, so beispielsweise eine Tastatur, einen Joystick, eine Gamesteuerung bzw. Gameregelung, eine Zeigevorrichtung (beispielsweise eine Maus, einen Finger eines Anwenders, der direkt mit einer Anzeigevorrichtung in Schnittstellenwechselwirkung tritt, und dergleichen mehr) oder eine beliebige andere Anwenderschnittstelle. Die Rechenvorrichtung 1000 kann weitere geeignete herkömmliche I/O-Peripheriegeräte beinhalten. Die Rechenvorrichtung 1000 kann verschiedene geeignete Vorrichtungen zum Wahrnehmen einer oder mehrerer der Funktionen, die verschiedentlich hier beschrieben sind, beinhalten oder damit gekoppelt sein. Die Rechenvorrichtung 1000 kann eine Netzwerkschnittstelle 1014 zum Kommunizieren mit anderen Vorrichtungen über ein Netzwerk wie das Internet beinhalten.
  • Die Rechenvorrichtung 1000 kann auf einem beliebigen Betriebssystem laufen, so beispielsweise auf Versionen der Microsoft®-Windows®-Betriebssysteme, auf den verschiedenen Versionen der Betriebssysteme Unix und Linux, auf einer beliebigen Version von MacOs® für Macintosh-Computer, auf einem beliebigen eingebetteten Betriebssystem, einem beliebigen Echtzeitbetriebssystem, einem beliebigen Open-Source-Betriebssystem, einem beliebigen proprietären Betriebssystem, einem beliebigen Betriebssystem für Mobilrechenvorrichtungen oder einem beliebigen anderen Betriebssystem, das auf der Rechenvorrichtung laufen und die hier beschriebenen Operationen durchführen kann. Bei einer Ausführungsform kann das Betriebssystem auf einer oder mehreren Cloud-Maschinen-Instanzen laufen.
  • Bei anderen Ausführungsformen können die funktionellen Komponenten/Module mit Hardware implementiert sein, so beispielsweise einer Gate-Level-Logik (beispielsweise FPGA) oder einem zweckgebundenen Halbleiter (beispielsweise ASIC). Wieder andere Ausführungsformen können mit einer Mikrosteuerung implementiert sein, die eine Anzahl von Eingabe-/Ausgabeports zum Empfangen und Ausgeben von Daten sowie eine Anzahl von eingebetteten Routinen zum Ausführen der hier beschriebenen Funktionalität beinhaltet. In einem allgemeineren Sinne kann eine beliebige geeignete Kombination aus Hardware, Software und Firmware, wie ersichtlich ist, verwendet werden.
  • Wie sich im Lichte der vorliegenden Offenbarung ergibt, können die verschiedenen Module und Komponenten des in 1 gezeigten Systems, so beispielsweise der Verpacker 110, die Videoabspieleinrichtung 132 und der Webbrowser 134 in Software implementiert sein, so beispielsweise als Satz von Anweisungen (beispielsweise C, C++, objektorientiertes C, JavaScript, Java, BASIC und dergleichen mehr), die auf einem beliebigen computerlesbaren Medium oder Computerprogrammerzeugnis (beispielsweise Festplattenlaufwerk, Server, Diskette oder einem anderen geeigneten nichttemporären Satz von Speichern) codiert sind und die bei Ausführung durch einen oder mehrere Prozessoren bewirken, dass die hier bereitgestellten verschiedenen methodischen Vorgehensweisen ausgeführt werden. Man beachte, dass bei einigen Ausführungsformen verschiedene Funktionen, die von dem Anwenderrechensystem gemäß vorliegender Beschreibung wahrgenommen werden, von ähnlichen Prozessoren und/oder Datenbanken in verschiedenen Konfigurationen und Anordnungen durchgeführt werden können und dass die dargestellten Ausführungsformen nicht beschränkend sein sollen. Verschiedene Komponenten dieser exemplarischen Ausführungsform, darunter das Anwenderrechensystem, können beispielsweise in eine oder mehrere Desktop- oder Laptopcomputer, Workstations, Tablets, Smartphones, Spielekonsolen, Set-Top-Boxen oder andere derartige Rechenvorrichtungen integriert sein. Andere Komponenten und Module, die für ein Rechensystem typisch sind, so beispiellose Prozessoren (beispielsweise zentrale Verarbeitungseinheiten und Koprozessoren, Grafikprozessoren und dergleichen mehr), Eingabevorrichtungen (beispielsweise Tastatur, Maus, berührungsempfindliches Feld, berührungsempfindlicher Bildschirm und dergleichen mehr), sowie Betriebssysteme sind nicht gezeigt, erschließen sich jedoch ohne Weiteres.
  • Weitere Beispiele
  • Zahllose Ausführungsformen erschließen sie im Lichte der vorliegenden Offenbarung, und es können die hier beschriebenen Merkmale in einer beliebigen Anzahl von Konfigurationen kombiniert werden. Eine exemplarische Ausführungsform stellt ein System mit einem Speicher und einem Prozessor, der operativ mit dem Speicher gekoppelt ist, bereit. Der Prozessor ist dafür ausgelegt, in dem Speicher gespeicherte Anweisungen auszuführen, die bei Ausführung veranlassen, dass der Prozessor einen Prozess ausführt. Der Prozess beinhaltet ein Erzeugen einer Mehrzahl von Videosegmenten, wobei jedes Segment einen Abschnitt eines Multimediainhaltes darstellt, wenn die jeweiligen Abschnitte des Multimediainhaltes von einer Live-Inhaltsquelle erhalten werden, Empfangen, von einer Clientrechenvorrichtung, einer Anfrage nach wenigstens einem der Videosegmente; und Pushen, von einem Servercomputer an die Clientrechenvorrichtung, des angeforderten Videosegmentes oder der Segmente entsprechend einer vordefinierten Push-Strategie. Eine weitere Ausführungsform stellt ein nichttemporäres computerlesbares Medium oder ein Computerprogrammerzeugnis bereit, auf dem Anweisungen codiert sind, die bei Ausführung durch einen oder mehrere Prozessoren veranlassen, dass der Prozessor einen oder mehrere der in diesem Absatz beschriebenen Funktionen wahrnimmt. Wie vorstehend beschrieben worden ist, können in einigen Fällen einige oder alle der verschiedentlich in diesem Absatz beschriebenen Funktionen in einer beliebigen Reihenfolge und zu einer beliebigen Zeit von einem oder mehreren verschiedenen Prozessoren durchgeführt werden.
  • Die vorstehende Beschreibung und die Zeichnung verschiedener Ausführungsformen sind lediglich beispielhalber angeführt. Diese Beispiele sollen nicht erschöpfend sein oder die Erfindung auf die genau offenbarte Form begrenzen. Abwandlungen, Änderungen und Variationen erschließen sich im Lichte der vorliegenden Offenbarung und sollen innerhalb des Umfanges der Erfindung sein, die in den Ansprüchen niedergelegt ist.

Claims (16)

  1. Computerimplementiertes Verfahren, umfassend: Erzeugen einer Mehrzahl von Videosegmenten eines Videostreams, wobei jedes Segment einen Abschnitt eines Multimediainhaltes darstellt, wenn die jeweiligen Abschnitte des Multimediainhaltes von einer Live-Inhaltsquelle empfangen werden; Empfangen, von einer Clientrechenvorrichtung, nur einer HTTP-Anfrage nach wenigstens zweien der Videosegmente; und Pushen, von einem Servercomputer an die Clientrechenvorrichtung, der wenigstens zwei Videosegmente entsprechend einer vordefinierten Push-Strategie ohne die Notwendigkeit von separaten HTTP-Anfragen von dem Client für ein jedes der Videosegmente, wobei die Push-Strategie eine k-Push-Strategie ist, bei der der Client eine Anfrage nach k Videosegmenten ausgibt und der Server auf die Anfrage durch Pushen von bis zu k Segmenten, wenn jedes Segment verfügbar wird, antwortet, und wobei das Verfahren ferner Variieren der Anzahl k von Videosegmenten der k-Push-Strategie im Anschluss an das Pushen der wenigstens zwei Videosegmente umfasst.
  2. Verfahren nach Anspruch 1, wobei das Pushen der wenigstens zwei Videosegmente unter Verwendung eines zustandslosen Kommunikationsprotokolls durchgeführt wird.
  3. Verfahren nach Anspruch 1 oder 2, wobei die Anfrage eine HTTP-GET-Anfrage beinhaltet, die Anfangs- und Endsegmente innerhalb der Mehrzahl von Videosegmenten, die an die Clientrechenvorrichtung gepusht werden sollen, angibt.
  4. Verfahren nach einem der vorhergehenden Ansprüche, des Weiteren umfassend ein Codieren eines jeden der Videosegmente entsprechend wenigstens einem von einem dateifragmentebasierten Segmentierungsschema und einem streamfragmentebasierten Segmentierungsschema.
  5. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Videosegmente verschiedene aufeinanderfolgende Zeitperioden des Multimediainhaltes darstellen.
  6. Verfahren nach einem der vorhergehenden Ansprüche, des Weiteren umfassend ein Variieren von wenigstens einem von der Bitrate und Auflösung wenigstens eines Videosegmentes als Antwort auf eine Änderung einer Netzwerkbedingung.
  7. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Pushen der wenigstens zwei Videosegmente durch den Servercomputer asynchron in Bezug auf das Empfangen der Anfrage durchgeführt wird.
  8. Computerimplementiertes Verfahren, umfassend: Senden, durch eine Clientrechenvorrichtung an einen Servercomputer, nur einer HTTP-Anfrage nach wenigstens zwei Videosegmenten eines Videostreams, die einen Abschnitt eines Multimediainhaltes darstellen, wenn die jeweiligen Abschnitte des Multimediainhaltes von einer Live-Inhaltsquelle empfangen werden; Empfangen, durch die Clientrechenvorrichtung, der wenigstens zwei Videosegmente von dem Servercomputer entsprechend einer vordefinierten Push-Strategie ohne die Notwendigkeit von separaten HTTP-Anfragen von der Clientrechenvorrichtung für ein jedes der Videosegmente; und Abspielen, durch die Clientrechenvorrichtung, des Multimediainhaltes unter Verwendung der wenigstens zwei Videosegmente, wobei die Push-Strategie eine k-Push-Strategie ist, bei der der Client eine Anfrage nach k Videosegmenten ausgibt und der Server auf die Anfrage durch Pushen von bis zu k Segmenten, wenn jedes Segment verfügbar wird, antwortet, und wobei das Verfahren ferner Variieren der Anzahl k von Videosegmenten der k-Push-Strategie im Anschluss an das Abspielen der wenigstens zwei Videosegmente umfasst.
  9. Verfahren nach Anspruch 8, wobei das Empfangen der wenigstens zwei Videosegmente unter Verwendung eines zustandslosen Kommunikationsprotokolls durchgeführt wird.
  10. Verfahren nach Anspruch 8 oder 9, wobei die Anfrage eine HTTP-GET-Anfrage beinhaltet, die Anfangs- und Endsegmente innerhalb einer Mehrzahl von Videosegmenten, die von dem Servercomputer empfangen werden sollen, angibt.
  11. Verfahren nach Anspruch 3 oder 10, wobei das Endsegment ein beliebiges Segment ist, das nicht erste und letzte Segmente der Mehrzahl von Videosegmenten ist.
  12. Verfahren nach einem der Ansprüche 8 bis 11, des Weiteren umfassend ein Decodieren des angeforderten Videosegmentes entsprechend wenigstens einem von einem dateifragmentebasierten Segmentierungsschema und einem streamfragmentebasierten Segmentierungsschema.
  13. Verfahren nach Anspruch 4 oder 12, wobei das Segmentierungsschema wenigstens eines von einer HTTP-Live-Streaming-Technik (HLS), einer dynamischen HTTP-Dynamic-Streaming-Technik (HDS), einer Smooth-Streaming-Technik und einer MPEG-Dynamic-Adaptive-Streaming über HTTP (DASH)-Technik ist.
  14. Verfahren nach einem der Ansprüche 8 bis 13, wobei wenigstens eines von der Bitrate und Auflösung des angeforderten Videosegmentes in Bezug auf andere von der Clientrechenvorrichtung empfangene Videosegmente als Antwort auf eine Änderung einer Netzwerkbedingung variiert wird.
  15. Verfahren nach einem der Ansprüche 8 bis 14, wobei das Empfangen der wenigstens zwei Videosegmente durch die Clientrechenvorrichtung asynchron in Bezug auf das Senden der Anfrage durchgeführt wird.
  16. System, umfassend: einen Speicher; und einen Prozessor, der operativ mit dem Speicher gekoppelt und dafür ausgelegt ist, in dem Speicher gespeicherte Anweisungen auszuführen, die bei Ausführung den Prozessor veranlassen, einen Prozess durchzuführen, der umfasst: Erzeugen einer Mehrzahl von Videosegmenten eines Videostreams, wobei jedes Segment einen Abschnitt eines Multimediainhaltes darstellt, wenn die jeweiligen Abschnitte des Multimediainhaltes von einer Live-Inhaltsquelle empfangen werden; Empfangen, von einer Clientrechenvorrichtung, nur einer HTTP-Anfrage nach wenigstens zweien der Videosegmente; und Pushen, von dem System an die Clientrechenvorrichtung, der wenigstens zwei Videosegmente entsprechend einer vordefinierten Push-Strategie ohne die Notwendigkeit von separaten HTTP-Anfragen von der Clientrechenvorrichtung für ein jedes der Videosegmente, wobei die Push-Strategie eine k-Push-Strategie ist, bei der der Client eine Anfrage nach k Videosegmenten ausgibt und der Server auf die Anfrage durch Pushen von bis zu k Segmenten, wenn jedes Segment verfügbar wird, antwortet, und wobei das Verfahren ferner Variieren der Anzahl k von Videosegmenten der k-Push-Strategie Strategie im Anschluss an das Pushen der wenigstens zwei Videosegmente umfasst.
DE102015002119.2A 2014-03-14 2015-02-19 Live-Videostreaming mit geringer Verzögerungszeit Active DE102015002119B4 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/213,127 2014-03-14
US14/213,127 US9635077B2 (en) 2014-03-14 2014-03-14 Low latency live video streaming

Publications (2)

Publication Number Publication Date
DE102015002119A1 DE102015002119A1 (de) 2015-09-17
DE102015002119B4 true DE102015002119B4 (de) 2023-11-16

Family

ID=52998473

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102015002119.2A Active DE102015002119B4 (de) 2014-03-14 2015-02-19 Live-Videostreaming mit geringer Verzögerungszeit

Country Status (4)

Country Link
US (1) US9635077B2 (de)
CN (1) CN104918072B (de)
DE (1) DE102015002119B4 (de)
GB (1) GB2525485B (de)

Families Citing this family (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10200353B2 (en) 2013-07-25 2019-02-05 Convida Wireless, Llc End-to-end M2M service layer sessions
US11477262B2 (en) * 2014-02-13 2022-10-18 Koninklijke Kpn N.V. Requesting multiple chunks from a network node on the basis of a single request message
EP3120520B1 (de) * 2014-03-17 2023-05-24 bitmovin GmbH Medienstreaming
US11943289B2 (en) 2014-10-14 2024-03-26 Comcast Cable Communications, Llc Manipulation of content transmissions
US11917002B2 (en) 2014-10-14 2024-02-27 Comcast Cable Communications, Llc Manipulation and recording of content transmissions
US10050912B2 (en) * 2014-10-27 2018-08-14 At&T Intellectual Property I, L.P. Subscription-based media push service
US9723095B2 (en) * 2014-12-05 2017-08-01 At&T Intellectual Property I, L.P. Multi delivery method policy controlled client proxy
KR101897959B1 (ko) * 2015-02-27 2018-09-12 쏘닉 아이피, 아이엔씨. 라이브 비디오 인코딩 및 스트리밍에서의 프레임 복제 및 프레임 확장을 위한 시스템 및 방법
GB2540632B (en) * 2015-07-24 2018-05-16 Canon Kk Methods, devices and computer programs for pushing data in a network environment comprising cache servers
US20170078351A1 (en) * 2015-09-15 2017-03-16 Lyve Minds, Inc. Capture and sharing of video
US10152080B2 (en) 2015-09-23 2018-12-11 Adobe Systems Incorporated Power efficient multimedia content streaming based on media segment duration
WO2017063189A1 (en) * 2015-10-16 2017-04-20 Qualcomm Incorporated Deadline signaling for streaming of media data
CN105516319B (zh) * 2015-12-15 2019-02-19 华为技术有限公司 管理http报文的方法和装置
US10432678B2 (en) 2016-01-04 2019-10-01 Cisco Technology, Inc. Multiparty real-time communications support over information-centric networking
US10469885B2 (en) 2016-03-22 2019-11-05 Arris Enterprises Llc Playback synchronization among adaptive bitrate streaming clients
JP6741784B2 (ja) * 2016-04-08 2020-08-19 ヴィズビット インコーポレイテッド ビューを意識した３６０度ビデオストリーミング
CN105978933B (zh) * 2016-04-25 2019-09-17 青岛海信电器股份有限公司 一种网页请求及响应方法、终端、服务器和系统
WO2017196670A1 (en) 2016-05-13 2017-11-16 Vid Scale, Inc. Bit depth remapping based on viewing parameters
US10708667B1 (en) * 2016-06-28 2020-07-07 Amazon Technologies, Inc. Combining fragments with different encodings
US11503314B2 (en) 2016-07-08 2022-11-15 Interdigital Madison Patent Holdings, Sas Systems and methods for region-of-interest tone remapping
WO2018018497A1 (zh) * 2016-07-28 2018-02-01 王晓光 不同时延在视频广告接收中策略方法及系统
DE102016116555A1 (de) * 2016-09-05 2018-03-08 Nanocosmos Informationstechnologien Gmbh Verfahren zur Übertragung von echtzeitbasierten digitalen Videosignalen in Netzwerken
KR102454470B1 (ko) 2016-10-06 2022-10-14 삼성전자주식회사 스트리밍 서비스를 지원하는 방법 및 장치
CN107920108A (zh) * 2016-10-11 2018-04-17 华为技术有限公司 一种媒体资源的推送方法、客户端及服务器
CN107959667B (zh) * 2016-10-18 2020-10-09 华为技术有限公司 一种媒体分片的推送方法、服务器及客户端
CN109891772B (zh) 2016-11-03 2022-10-04 康维达无线有限责任公司 Nr中的帧结构
US10693928B2 (en) 2017-01-30 2020-06-23 Wipro Limited Method and device for adaptive streaming of multimedia data
CN110301136B (zh) 2017-02-17 2023-03-24 交互数字麦迪逊专利控股公司 在流传输视频中进行选择性感兴趣对象缩放的系统和方法
EP3593536A1 (de) 2017-03-07 2020-01-15 PCMS Holdings, Inc. Massgeschneidertes video-streaming für präsentationen mit mehreren vorrichtungen
KR102307447B1 (ko) * 2017-05-02 2021-09-30 삼성전자주식회사 네트워크 환경 모니터링에 기반하는 http 적응적 스트리밍 서버, 방법, 및 클라이언트 단말
US10461884B2 (en) 2017-10-05 2019-10-29 Comcast Cable Communications, Llc Server selected variable bitrate streaming
CN110166506B (zh) * 2018-02-12 2021-11-19 中国移动通信有限公司研究院 超文本传输协议Http的连接方法及节点设备
US11388464B2 (en) 2018-09-25 2022-07-12 Microsoft Technology Licensing, Llc Increasing video bit rates while maintaining video quality
KR20210066856A (ko) 2018-09-27 2021-06-07 콘비다 와이어리스, 엘엘씨 새로운 라디오의 비허가 스펙트럼들에서의 부대역 동작들
CN109474486A (zh) * 2018-09-30 2019-03-15 深圳市网心科技有限公司 流媒体数据传输欠速判定方法、系统及装置
EP4272452A2 (de) * 2021-01-04 2023-11-08 Nokia Technologies Oy Flexible aufwärts-/abwärtsunterstützung für netzwerkbasierte medienverarbeitungspipelines

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060236387A1 (en) 2005-01-07 2006-10-19 Microsoft Corporation Bulk transmission of messages using a single HTTP request
US20110080940A1 (en) 2009-10-06 2011-04-07 Microsoft Corporation Low latency cacheable media streaming

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7739350B2 (en) * 2003-12-10 2010-06-15 International Business Machines Corporation Voice enabled network communications
BRPI0923917B1 (pt) * 2008-12-31 2021-05-25 Apple Inc Método implementado por máquina, meio de armazenamento não transitório legível por máquina, aparelho, e sistema de processamento de dados para transmissão contínua em tempo real ou próximo ao tempo real
US20100180011A1 (en) * 2009-01-12 2010-07-15 Microsoft Corporation Url based retrieval of portions of media content
US20110096828A1 (en) * 2009-09-22 2011-04-28 Qualcomm Incorporated Enhanced block-request streaming using scalable encoding
US8954596B2 (en) * 2010-04-02 2015-02-10 Netflix, Inc. Dynamic virtual chunking of streaming media content
CN101917488B (zh) * 2010-08-20 2013-09-11 华为数字技术（成都）有限公司 一种bt下载方法、装置及系统
WO2012093202A1 (en) * 2011-01-07 2012-07-12 Nokia Corporation Method and apparatus for signaling presentation
US11025962B2 (en) 2011-02-28 2021-06-01 Adobe Inc. System and method for low-latency content streaming
CN102232298B (zh) * 2011-04-07 2013-10-09 华为技术有限公司 媒体内容的传输处理方法、装置与系统
MX336608B (es) * 2011-08-29 2016-01-25 Sling Media Pvt Ltd Sistemas y metodos para controlar la codificacion de una corriente de medio segmentada utilizando tiempos de transmision de segmento.

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060236387A1 (en) 2005-01-07 2006-10-19 Microsoft Corporation Bulk transmission of messages using a single HTTP request
US20110080940A1 (en) 2009-10-06 2011-04-07 Microsoft Corporation Low latency cacheable media streaming

Also Published As

Publication number Publication date
US9635077B2 (en) 2017-04-25
GB2525485B (en) 2017-06-07
CN104918072B (zh) 2019-09-06
DE102015002119A1 (de) 2015-09-17
GB2525485A (en) 2015-10-28
CN104918072A (zh) 2015-09-16
GB201503780D0 (en) 2015-04-22
US20150264096A1 (en) 2015-09-17

Similar Documents

Publication Publication Date Title
DE102015002119B4 (de) Live-Videostreaming mit geringer Verzögerungszeit
US10939148B2 (en) Playback synchronization among adaptive bitrate streaming clients
DE102013114633B4 (de) Netzwerk-adaptive Latenzzeit-Verringerung durch Framerate-Steuerung
DE112012001770T5 (de) Auf Echtzeitverarbeitungsfähigkeit basierende Qualitätsanpassung
DE69829361T2 (de) Automatische erkennung von protokollen in einem netzwerk
EP3357253B1 (de) Lückenloses video-looping
DE112012002159T5 (de) Kontextsensitive Client-Pufferschwellenwerte
EP4274244A1 (de) Planung von segmentdatenlieferung in einem adaptiven mediendatenstrom zur vermeidung von blockierungen
DE112013002247T5 (de) Kombinierte Broadcast- und Unicast-Übermittlung
KR102493871B1 (ko) 세그먼터 유동성을 위한 패키저
DE112013007509B4 (de) Verfahren, Einrichtung und System zum Auswählen von Audio-Video-Daten zum Streamen
DE112015002650B4 (de) Systeme und Verfahren zur prädiktiven Auslieferung von Inhalten mit hohen Bitraten zur Wiedergabe
DE112011101911T5 (de) Fragmentierte Dateistruktur für die Ausgabe von Live-Medien-Streams
DE112011101908T5 (de) Qualitätseinstellung unter Verwendung eines fragmentierten Medienstroms
US20190190971A1 (en) Reducing latency in multicast delivery of content
CN107864402A (zh) 直播视频播放方法及装置
DE112013000995T5 (de) Skalierbare Wasserzeicheneinfügung für fragmentierte Medienstrom-Bereitstellung
CN105721889A (zh) P2p数据下载的方法和装置
DE112016002055T5 (de) Vorabrufcodierung für anwendungs-streaming
DE112012004994T5 (de) Verbesserte Bildergruppen-(GOP)-Ausrichtung in Medienstromvarianten
WO2019193991A1 (ja) 配信装置、配信方法、およびプログラム
US20160088079A1 (en) Streaming playout of media content using interleaved media players
CN115336283B (zh) 客户机装置和向客户机装置流传送媒体内容的方法
EP1340352A2 (de) Verfahren und vorrichtung zum steuern der übertragung und wiedergabe von digitalen signalen
CN105847271A (zh) 基于http实时流的多媒体内容的提供方法及提供装置

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R081 Change of applicant/patentee

Owner name: ADOBE INC., SAN JOSE, US

Free format text: FORMER OWNER: ADOBE SYSTEMS INCORPORATED, SAN JOSE, CALIF., US

R082 Change of representative

Representative=s name: MUELLER-BORE & PARTNER PATENTANWAELTE PARTG MB, DE

R016 Response to examination communication
R018 Grant decision by examination section/examining division