DE112012002159T5 - Kontextsensitive Client-Pufferschwellenwerte - Google Patents

Kontextsensitive Client-Pufferschwellenwerte Download PDF

Info

Publication number
DE112012002159T5
DE112012002159T5 DE112012002159.2T DE112012002159T DE112012002159T5 DE 112012002159 T5 DE112012002159 T5 DE 112012002159T5 DE 112012002159 T DE112012002159 T DE 112012002159T DE 112012002159 T5 DE112012002159 T5 DE 112012002159T5
Authority
DE
Germany
Prior art keywords
buffer
fragment
playback
media stream
threshold
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.)
Withdrawn
Application number
DE112012002159.2T
Other languages
English (en)
Inventor
Kent Karlsson
Tommy Isaksson
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.)
MobiTv Inc
Original Assignee
MobiTv 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 MobiTv Inc filed Critical MobiTv Inc
Publication of DE112012002159T5 publication Critical patent/DE112012002159T5/de
Withdrawn legal-status Critical Current

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/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • 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/75—Media network packet handling
    • H04L65/752—Media network packet handling adapting media to network capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/30—Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
    • 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
    • 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
    • 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
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • 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
    • 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/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2401—Monitoring of the client buffer
    • 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/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H04N21/440227—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display by decomposing into layers, e.g. base layer and one or more enhancement layers
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • 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/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • 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/6373—Control signals issued by the client directed to the server or network components for rate control, e.g. request to the server to modify its transmission rate
    • 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)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Transfer Systems (AREA)
  • Communication Control (AREA)

Abstract

Client-Pufferschwellenwerte werden dynamisch angepasst, um einen schnellen Start und eine reibungslose Wiedergabe unter verschiedenen Netzwerkbedingungen zu ermöglichen. Bei einigen Beispielen stehen mehrere Pufferkonfigurationen zur Verfügung. Eine anfängliche Pufferkonfiguration kann unter typischen Bedingungen verwendet werden und in den meisten Fällen gut funktioniere. Eine modifizierte Pufferkonfiguration kann verwendet werden, wenn begrenzte verfügbare Netzwerkressourcen eine reibungslose Wiedergabe verhindern. Bei einigen Ausführungsbeispielen wird die Client-Pufferkonfiguration kontinuierlich auf der Grundlage des Netzwerkdurchsatzes und der Datenübertragungsrate angepasst.

Description

  • Daten verwandter Anmeldungen
  • Die vorliegende Anmeldung beansprucht die Priorität der US-Patentanmeldung Nr. 13/111,151 mit dem Titel CONTEXTUALLY AWARE CLIENT BUFFER THRESHOLDS, angemeldet am 19. Mai 2011 (Attorney Docket No. MOBIP065US), deren gesamte Offenbarung durch Bezugnahme für alle Zwecke Teil des Gegenstandes der vorliegenden Anmeldung ist.
  • Technisches Gebiet
  • Die vorliegende Offenbarung betrifft kontextsensitive Client-Pufferschwellenwerte.
  • Beschreibung des Standes der Technik
  • Clients empfangen üblicherweise Medien über Netzwerke, die unterschiedliche Übertragungsraten, Bandbreiten, Wartezeiten und Zuverlässigkeit aufweisen. Ein Medienwiedergabegerät eines Clients ist üblicherweise mit einem Puffer konfiguriert. Client-Puffer haben jedoch eine begrenzte Effizienz hinsichtlich der Bereitstellung einer problemlosen Wiedergabe unter verschiedenen Netzwerkbedingungen.
  • Herkömmliche Verfahren und Mechanismen für das Übertragen von Echtzeit-Medien sind begrenzt. Es ist daher erwünscht, verbesserte Verfahren und Mechanismen für das Abspielen von Medien auf der Client-Seite zu schaffen.
  • Kurzbeschreibung der Zeichnungen
  • Die Offenbarung ist am besten unter Bezugnahme auf die nachfolgende Beschreibung in Verbindung mit den zugehörigen Zeichnungen zu verstehen, welche besondere Ausführungsbeispiele darstellen.
  • 1 zeigt ein Beispiel für eine Pufferkonfiguration.
  • 2 zeigt ein Beispiel für eine Pufferkonfiguration mit mehreren Schwellenwerten.
  • 3 zeigt ein Beispiel für ein Fragmentierungssystem.
  • 4 zeigt ein anderes Beispiel für ein Fragmentierungssystem.
  • 5 zeigt Beispiele für von einem Fragmentschreiber gespeicherte Dateien.
  • 6 zeigt ein Beispiel für einen Austausch unter Verwendung eines Fragmentierungssystems.
  • 7 zeigt ein Verfahren für die Pufferkonfiguration.
  • 8 zeigt ein Beispiel für ein System.
  • Beschreibung exemplarischer Ausführungsbeispiele
  • Im Folgenden wird detailliert auf einige spezifische Beispiele für die Erfindung Bezug genommen, welche die von den Erfindern gegenwärtig als beste Arten der Durchführung der Erfindung angesehenen Ausführungsbeispiele beinhalten. Beispiele für diese spezifischen Ausführungsbeispiele sind in den beigefügten Zeichnungen dargestellt. Zwar wird die Erfindung in Zusammenhang mit diesen spezifischen Ausführungsbeispielen beschrieben, jedoch ist es ersichtlich, dass nicht beabsichtigt ist, die Erfindung auf die beschriebenen Ausführungsbeispiele zu beschränken. Im Gegenteil ist es beabsichtigt, Alternativen, Modifikationen und Äquivalente abzudecken, die dem Geist und dem Rahmen der Erfindung entsprechen, wie diese durch die beigefügten Ansprüche definiert sind.
  • Die Verfahren gemäß der vorliegenden Erfindung werden beispielsweise im Zusammenhang mit Medienwiedergabegerätepuffern beschrieben. Es sei jedoch darauf hingewiesen, dass die erfindungsgemäßen Verfahren auf eine Vielzahl von Pufferungsmechanismen anwendbar sind. In der folgenden Beschreibung werden zahlreiche spezifische Details angeführt, um ein umfassendes Verständnis der vorliegenden Erfindung zu vermitteln. Besondere exemplarische Ausführungsbeispiele der vorliegenden Erfindung können ohne einige oder sämtliche dieser spezifischen Details implementiert werden. In anderen Fällen werden hinreichend bekannte Verfahrensabläufe nicht im Detail beschrieben, um das Verständnis der vorliegenden Erfindung nicht unnötig zu erschweren.
  • Verschiedene Verfahren und Mechanismen der vorliegenden Erfindung werden manchmal aus Gründen der Klarheit in Singularform beschrieben. Es sei jedoch darauf hingewiesen, dass einige Ausführungsbeispiele mehrere Durchläufe eines Verfahrens oder mehrfache Instantiierungen eines Mechanismus beinhalten, sofern dies nicht anders angegeben ist. Zum Beispiel verwendet ein System einen Prozessor in verschiedenen Zusammenhängen. Es ist jedoch ersichtlich, dass ein System mehrere Prozessoren verwenden kann, ohne den Rahmen der vorliegenden Erfindung zu verlassen, sofern dies nicht anders angegeben ist. Ferner beschreiben die Verfahren und Mechanismen der vorliegenden Erfindung manchmal eine Verbindung zwischen zwei Einheiten. Es sei darauf hingewiesen, dass eine Verbindung zwischen zwei Einheiten nicht notwendigerweise eine direkte, uneingeschränkte Verbindung bezeichnet, da eine Vielzahl anderer Einheiten zwischen den beiden Einheiten vorhanden sein kann. Ein Prozessor kann beispielsweise mit einem Speicher verbunden sein, jedoch ist offensichtlich, dass eine Vielzahl von Brücken und Steuerungen zwischen dem Prozessor und dem Speicher vorgesehen sein kann. Dementsprechend bedeutet eine Verbindung nicht notwendigerweise eine direkte, uneingeschränkte Verbindung, sofern dies nicht anders angegeben ist.
  • Überblick
  • Client-Pufferschwellenwerte werden dynamisch eingestellt, um einen schnellen Start und ein problemloses Abspielen unter verschiedenen Netzwerkbedingungen zu ermöglichen. Eine anfängliche Pufferkonfiguration kann unter typischen Bedingungen verwendet werden und in den meisten Fällen ein gutes Verhalten zeigen. Eine modifizierte Pufferkonfiguration kann verwendet werden, wenn begrenzte verfügbare Netzwerkressourcen eine problemlose Wiedergabe verhindern. Bei einigen Ausführungsbeispielen wird die Client-Pufferkonfiguration kontinuierlich auf der Grundlage der Netzwerkdurchsatz- und Datentransferraten angepasst.
  • Exemplarische Ausführungsbeispiele
  • Eine Vielzahl verschiedener Mechanismen wird zur Ausgabe von Medienströmen an Geräte verwendet. In vielen Fällen liefern diese Mechanismen Daten nicht mit einer konstanten Datenrate. Die Netzwerkbandbreite, die Wartezeit, der Durchsatz und die Zuverlässigkeit können sämtlich in Abhängigkeit von den Netzwerkbedingungen variieren. Daher weisen Media-Player in Clientgeräten üblicherweise Puffer und Pufferschwellenwerte auf, die dazu dienen, zu bestimmen, wann eine Wiedergabe beginnt oder fortgesetzt wird. Ein großer Puffer mit einem hohen zugeordneten Pufferschwellenwert benötigt viel Zeit für den Aufbau, jedoch toleriert er ungünstige Netzwerkbedingungen. Ein kleiner Puffer mit einem niedrigen zugeordneten Pufferschwellenwert ermöglicht eine schnelle Anfangswiedergabe, ist jedoch unter vielen Netzwerkbedingungen schwer aufrechtzuerhalten.
  • Typische Client-Geräte weisen einen einzelnen Parametersatz auf. Sobald eine Wahl hinsichtlich der Puffergröße gefallen ist, verhält sich ein Client-Gerät üblicherweise unter Bedingungen einer bestimmten Gruppe gut, jedoch schlecht unter anderen Bedingungen. In einigen Fällen kann der Benutzer Puffergrößen und Pufferschwellenwerte manuell einstellen. Ein Benutzer, der eine problemlosere Wiedergabe wünscht, möchte unter Umständen einen relativ großen Puffer einstellen, während ein Benutzer, der eine schnelle Wiedergabe wünscht, einen relativ kleinen Puffer einstellen kann. Jedoch berücksichtigt auch die manuelle Einstellung der Puffergrößen und der Pufferschwellenwerte nicht stark unterschiedliche Netzwerkbedingungen, die während der Wiedergabe auftreten können.
  • Die Verfahren und Mechanismen der vorliegenden Erfindung sehen folglich multiple Pufferkonfigurationen vor. Bei einigen Beispielen ist anfangs ein kleiner Puffer vorgesehen, um den Fokus auf einen schnellen Start zu legen. Falls ausreichend Durchsatz vorhanden ist, wird der kleine Puffer aufgebaut und die Sitzung läuft reibungslos ab. Ströme mit unterschiedlichen Bitraten können von einem Inhaltsserver übertragen werden, während der Client die anfängliche Pufferkonfiguration verwendet. Wenn jedoch noch immer eine Puffererschöpfung auftritt, wird eine modifizierte Konfiguration eingeleitet. Die zweite Pufferkonfiguration verwendet einen größeren Puffer, hat jedoch eine bessere Chance, eine gute Wiedergabe zu liefern, wenn die Netzwerkbedingungen schlecht sind.
  • Gemäß verschiedenen Ausführungsbeispielen weist eine anfängliche Pufferkonfiguration mehrere Schwellenwerte auf. Die Medienwiedergabe beginnt erst wenn ein erster Puffer bis zu einem hohen Schwellenwert gefüllt ist. Baut sich der Puffer weiter auf, kann ein Medienabspielgerät beginnen, einen Strom höherer Qualität zu empfangen, sobald der Puffer einen noch höheren Schwellenwert erreicht. Wenn der Puffer beginnt, sich zu erschöpfen, kann das Medienabspielgerät beginnen, einen Strom geringerer Qualität zu empfange, sobald der Puffer sich auf einen niedrigeren Schwellenwert leert.
  • Bei bestimmten Ausführungsbeispielen kann eine neue Pufferkonfiguration vorgenommen werden, wenn sich der Puffer weiterhin erschöpft, trotzdem auf einen oder mehrere Ströme geringerer Qualität umgeschaltet wurde. Die neue Pufferkonfiguration kann einen viel größeren Puffer und höhere Schwellenwerte mit breiteren Bändern zwischen den Schwellenwerten aufweisen. Wenn ein Puffer sich weiter füllt, kann ein Strom höherer Qualität an den Client übertragen werden. Wenn der Puffer sich weiter erschöpft, wird dem Client ein Strom geringerer Qualität übermittelt.
  • Folglich werden viele Client-Geräte einen Medienstrom mit schnellen Startzeiten und reibungsloser Wiedergabe abspielen. Eine anfängliche Pufferkonfiguration ist effektiv. Dynamische Änderungen der Medienstromqualität können während der Übertragung auf der Grundlage der Pufferschwellenwerte in einer anfänglichen Pufferkonfiguration vorgenommen werden. Wenn sich ein Puffer dennoch erschöpft, wird eine neue Pufferkonfiguration erstellt. Die neue Pufferkonfiguration weist einen größeren Puffer und höhere Schwellenwertpegel auf, wodurch der neue Puffer schwerer zu erschöpfen ist. Der neue Puffer erhöht die Chancen für ein reibungsloses Wiedergabeerlebnis unter nachteiligen Netzwerkbedingungen. Gemäß verschiedenen Ausführungsbeispielen können auch bei der neuen Pufferkonfiguration unterschiedliche Schwellenwertpegel die Übertragung von Medienströmen höherer oder geringerer Qualität auslösen.
  • Es sei darauf hingewiesen, dass bei verschiedenen Ausführungsbeispielen zwei Pufferkonfigurationen vorgesehen sind. Eine Konfiguration sieht einen kleineren Puffer für den schnellen Start vor und die andere Konfiguration sieht einen großen Puffer für die reibungslose Widergabe vor. In anderen Fällen jedoch können zusätzliche Konfigurationen und zusätzliche Schwellenwerte vorgesehen sein. Die zusätzlichen Schwellenwerte können inkrementell, logarithmisch, exponentiell, empirisch etc. eingestellt werden.
  • In bestimmten Beispielen eröffnet ein Client eine Sitzung, beispielsweise eine Real-Time-Streaming-Protocol-Sitzung (RTSP). Ein Servercomputer empfängt eine Verbindung für einen Medienstrom, eröffnet eine Sitzung, und liefert einen Medienstrom an ein Clientgerät. Der Medienstrom enthält Pakete, die Frames, beispielsweise MPEG-4-Frames, kapseln. Die MPEG-4-Frames selbst können Schlüsselbilder oder Differenzbilder sein. Die von dem Server verwendete spezifische Datenkapselungsmethode hängt von der Art des Inhalts, dem Format dieses Inhalts, dem Format der Nutzdaten, und den für das Senden der Daten verwendeten Anwendungs- und Übertragungsprotokollen ab. Nachdem das Clientgerät den Medienstrom empfangen hat, entkapselt das Clientgerät die Pakete, um die MPEG-Frames zu erhalten, und dekodiert die MPEG-Frames, um die eigentlichen Mediendaten zu erhalten.
  • Herkömmliche MPEG-4-Dateien machen es erforderlich, dass ein Abspielgerät den gesamten Dateikopf parst, bevor irgendwelche Daten dekodiert werden können. Das Parsen des gesamten Dateikopfs kann erhebliche Zeit in Anspruch nehmen, insbesondere bei Geräten mit begrenzten Netzwerk- und Verarbeitungsressourcen. Infolgedessen wird durch die Verfahren und Mechanismen der vorliegenden Erfindung ein fragmentiertes MPEG-4-Framework geschaffen, das ein Abspielen während des Empfangs eines ersten MPEG-4-Dateifragments ermöglicht. Ein zweites MPEG-4-Dateifragment kann unter Verwendung von in dem ersten MPEG-4-Dateifragment enthaltenen Informationen angefordert werden. Gemäß verschiedenen Ausführungsbeispielen kann es sich bei dem angeforderten zweiten MPEG-4-Dateifragment um ein Fragment handeln, das einem Strom entspricht, der eine höhere oder geringere Bitrate aufweist, als der dem ersten Dateifragment zugeordnete Strom.
  • MPEG-4 ist ein erweiterbares Containerformat ohne eine festgelegte Struktur für die Beschreibung von Medientypen. Stattdessen weist MPEG-4 eine Objekthierarchie auf, welche das Definieren individueller Strukturen für jedes Format ermöglicht. Die Formatbeschreibung ist in dem Beispielbeschreibungsfeld (”stsd”) für jeden Strom gespeichert. Das Beispielbeschreibungsfeld kann Informationen enthalten, die nicht bekannt werden, bevor sämtliche Daten kodiert sind. Das Beispielbeschreibungsfeld kann beispielsweise eine durchschnittliche Bitrate enthalten, die vor der Kodierung nicht bekannt ist.
  • Gemäß verschiedenen Ausführungsbeispielen werden MPEG-4-Dateien fragmentiert, so dass ein Live-Stream nahezu live aufgezeichnet und wiedergegeben werden kann. MPEG-4-Dateien können erzeugt werden, ohne warten zu müssen, bis der gesamte Inhalt für das Vorbereiten der Film-Dateiköpfe geschrieben ist. Um eine MPEG-4-Fragmentierung ohne band-externe Signalgebung zu ermöglichen, ist eine Feldstruktur vorgesehen, welche Synchronisierungsinformationen, Dateiende-Informationen und Kapitelinformationen enthält. Gemäß verschiedenen Ausführungsbeispielen dienen Synchronisierungsinformationen der Audio- und Video-Synchronisierung, wenn die Wiedergabe einen Beginn mitten in einem Strom mit sich bringt. Die Dateiende-Informationen geben das Ende des gegenwärtigen Programms oder der Datei an. Diese können Informationen zum Fortsetzen der Stromübertragung des nächsten Programms oder der nächsten Datei enthalten. Die Kapitelinformationen können für Video-on-Demand-Inhalte verwendet werden, die in Kapitel, welche möglicherweise durch Werbeslots getrennt sind, unterteilt sind.
  • TCP findet häufiger Anwendung als UDP, und Netzwerktechnologien, die Schalt-, Load-Balancer- und Netzwerkkartentechnologien verwenden, werden häufiger für TCP als für UDP entwickelt. Infolgedessen werden Verfahren und Mechanismen zum Ausgeben von fragmentierten Live-Medien über TCP bereitgestellt. Sequenzinformationen werden ebenfalls beibehalten und/oder modifiziert, um einen übergangslosen Betrieb des Clientgeräts zu ermöglichen. Die Zeitsteuerungs- und Sequenzinformationen in einem Medienstrom bleiben erhalten.
  • Anforderungen werden als separate Dateien einem Client angezeigt, und Dateien sollten auf Abspielgeräten, die fragmentiertes MPEG-4 umsetzen können, wiedergebbar sein. Live-Inhalte oder nahezu live gesendete Inhalte, Video-on-Demand-(VOD) und Digital-Video-Record-Inhalte (DVR) sind sämtlich unter Verwendung von Fragmentierung verarbeitbar.
  • 1 zeigt eine Pufferkonfiguration in Verbindung mit einem Clientgerät. Gemäß verschiedenen Ausführungsbeispielen weist der Puffer 101 einen Wiedergabestartschwellenwert 103 auf. Bei bestimmten Ausführungsbeispielen werden Daten wie fragmentierte MPEG-4-Pakete empfangen und in dem Puffer abgelegt. Sobald der Puffer 101 bis zu dem Schwellenwert 103 gefüllt ist, beginnt die Wiedergabe. Gemäß verschiedenen Ausführungsbeispielen stellt die anfängliche Pufferkonfiguration den Wiedergabestartschwellenwert 103 auf einen relativ niedrigen Wert ein, der auf typischen Netzwerkbedingungen basiert. Der relativ niedrige Wert erlaubt es einem Puffer 101 den Wiedergabeschwellenwert 103 in einer relativ kurzen Zeit zu erreichen. Die Wiedergabe kann schnell beginnen. Daten werden dem Puffer 101 beim Empfang der Daten hinzugefügt und es werden Daten aus dem Puffer 101 entfernt, sobald sie zum Verarbeiten und zur Wiedergabe erfasst werden. Gemäß verschiedenen Ausführungsbeispielen kann eine neue Pufferkonfiguration geladen werden, wenn der Puffer 101 erschöpft ist. Eine durch den Puffer 131 dargestellte nachfolgende Pufferkonfiguration weist einen höheren Wiedergabestartschwellenwert 133 auf. Bei bestimmten Ausführungsbeispielen werden Daten wie fragmentierte MPEG-4-Pakete empfangen und in dem Puffer 131 abgelegt. Sobald der Puffer 131 bis zu dem Schwellenwert 133 gefüllt ist, beginnt die Wiedergabe. Gemäß verschiedenen Ausführungsbeispielen stellt die modifizierte anfängliche Pufferkonfiguration den Wiedergabestartschwellenwert 133 auf einen relativ hohen Wert ein, da nunmehr nachteilige Netzwerkbedingungen bekannt sind. Die Wiedergabe beginnt erst, wenn der Puffer den modifizierten Schwellenwert 133 erreicht hat. Es kann nun länger dauern, bis die Wiedergabe beginnt, jedoch ist es nunmehr schwieriger, den modifizierten Puffer zu erschöpfen. Daten werden dem Puffer 131 beim Empfang der Daten hinzugefügt und es werden Daten aus dem Puffer 131 entfernt, sobald sie zum Verarbeiten und zur Wiedergabe erfasst werden.
  • 2 zeigt Pufferkonfigurationen mit mehreren Schwellenwerten in Verbindung mit einem Client-Gerät. Der anfängliche Puffer 201 weist einen Wiedergabestartschwellenwert 203 auf. Bei bestimmten Ausführungsbeispielen werden Daten wie fragmentierte MPEG-4-Pakete empfangen und in dem Puffer abgelegt. Sobald der Puffer 201 bis zu dem Schwellenwert 203 gefüllt ist, beginnt die Wiedergabe. Gemäß verschiedenen Ausführungsbeispielen stellt die anfängliche Pufferkonfiguration den Wiedergabestartschwellenwert 203 auf einen relativ niedrigen Wert ein, der auf typischen Netzwerkbedingungen basiert. Wenn der Puffer sich zu erschöpfen beginnt und den Qualitätsschwellenwert 205 erreicht, kann der an das Gerät gesendete Medienstrom auf einen Medienstrom geringerer Qualität umgeschaltet werden. Bei einigen Beispielen hat der Medienstrom geringerer Qualität eine geringere Bitrate als der anfängliche Medienstrom. Das Wiedergabeerlebnis kann ohne Unterbrechung fortgesetzt werden, ohne die Notwendigkeit der Eröffnung einer neuen Sitzung. Gemäß verschiedenen Ausführungsbeispielen wird der Medienstrom hinsichtlich seiner Qualität von einem Inhaltsserver geändert, wenn dieser von dem Client ein Signal empfängt, dass das Erreichen eines Qualitätsschwellenwerts anzeigt. Der Inhaltsserver kann MPEG-4-Fragmente höherer Qualität durch MPEG-4-Fragmente geringerer Qualität ersetzen, während die Zeitsteuerungs- und Sequenznummerninformationen beibehalten werden.
  • In einigen Beispielen wird, wenn der Puffer einen Qualitätsschwellenwert 205 erreicht, der Strom auf einen Strom geringerer Qualität umgeschaltet, der die Wiedergabe von mehr Inhalt mit weniger übertragenen MPEG-4-Fragmenten ermöglicht. Alternativ wird, wenn der Puffer einen Qualitätsschwellenwert 207 erreicht, erkannt, dass ausreichende Netzwerk-Ressourcen verfügbar sind. Der Inhaltsserver kann mit der Übertragung eines Stroms höherer Qualität beginnen, während ein nahtloses Wiedergabeerlebnis für den Benutzer beibehalten wird. Ein Inhaltsserver kann die Qualität eines Stromes auf der Grundlage von Feedback-Informationen in Zusammenhang mit dem Clientgerät wechseln. Erschöpft sich der Puffer 201 dennoch weiter, kann eine andere Pufferkonfiguration erstellt werden.
  • Gemäß verschiedenen Ausführungsbeispielen weist eine als Puffer 231 dargestellte modifizierte Pufferkonfiguration einen höheren Wiedergabestartschwellenwert 233 auf. Bei bestimmten Ausführungsbeispielen werden Daten wie fragmentierte MPEG-4-Pakete empfangen und in dem Puffer abgelegt. Sobald der Puffer 231 bis zu dem Schwellenwert 233 gefüllt ist, beginnt die Wiedergabe. Gemäß verschiedenen Ausführungsbeispielen stellt die modifizierte anfängliche Pufferkonfiguration den Wiedergabestartschwellenwert 2033 auf einen relativ hohen Wert ein, da nunmehr nachteilige Netzwerkbedingungen bekannt sind. Die Wiedergabe beginnt erst, wenn der Puffer den modifizierten Schwellenwert 233 erreicht hat. Es kann nun länger dauern, bis die Wiedergabe beginnt, jedoch ist es nunmehr schwieriger, den modifizierten Puffer zu erschöpfen. Daten werden dem Puffer 231 beim Empfang der Daten hinzugefügt und es werden Daten aus dem Puffer 231 entfernt, sobald sie zum Verarbeiten und zur Wiedergabe erfasst werden. Gemäß verschiedenen Ausführungsbeispielen weist der Puffer 231 auch die Qualitätsschwellenwerte 235 und 237 auf. Erschöpft sich der Puffer 231 bis zu dem Schwellenwert 235, wird die Qualität des Stroms verringert, um ungünstige Netzwerkbedingungen auszugleichen. Der Inhaltsserver kann erneut auf einen Strom von noch geringerer Qualität wechseln, wenn der Qualitätsschwellenwert 237 erreicht wird.
  • 3 ist eine schematische Darstellung eines Beispiels für ein Fragmentierungssystem 301, das einem Inhaltsserver zugeordnet ist, der die erfindungsgemäßen Verfahren und Mechanismen verwenden kann. Kodierer 305 empfangen Mediendaten von Satelliten, Inhaltsbibliotheken und anderen Inhaltsquellen und senden RTP-Multicast-Daten an einen Fragmentschreiber 309. Die Kodierer 305 senden ferner Session-Announcement-Protocol-Bekanntgaben (SAP) an einen SAP-Empfänger 321. Gemäß verschiedenen Ausführungsbeispielen erzeugt der Fragmentschreiber 309 Fragmente für das Live-Streaming und schreibt Dateien zur Aufzeichnung auf eine Platte. Der Fragmentschreiber 309 empfängt RTP-Multicast-Ströme von den Kodierern 305 und parst die Ströme, um die Audio-/Video-Daten als Teil von fragmentierten MPEG-4-Dateien neu zu packen. Wenn ein neues Programm beginnt, erzeugt der Fragmentschreiber 309 eine neue MPEG-4-Datei im Fragmentspeicher und hängt Fragmente an. Bei bestimmten Ausführungsbeispielen unterstützt der Fragmentschreiber 309 Live- und/oder DVR-Konfigurationen.
  • Der Fragmentserver 311 versieht die Zwischenspeicherungsschicht mit Fragmenten für Clients. Die Designphilosophie hinter der Client/Server-API minimiert Leerläufe und verringert im Hinblick auf die Ausgabe der Mediendaten an den Client 315 die Komplexität so weit wie möglich. Der Fragmentserver 311 stellt Live-Streams und/oder DVR-Konfigurationen zur Verfügung.
  • Der Fragment-Controller 307 ist mit Anwendungsservern 303 verbunden und steuert die Fragmentierung von Live-Kanal-Strömen. Der Fragment-Controller 307 integriert optional Führungsdaten, um die Aufzeichnungen für eine Global-/Netzwerk-DVR zu steuern. In bestimmten Ausführungsbeispielen bettet der Fragment-Controller 307 die Aufzeichnung in eine Logik ein, um die Fragmentschreiberkomponente 309 zu vereinfachen. Gemäß verschiedenen Ausführungsbeispielen läuft der Fragment-Controller 307 auf dem selben Host wie der Fragmentschreiber 309. Bei bestimmten Ausführungsbeispielen instanziiert der Fragment-Controller 307 Instanzen des Fragmentschreibers 309 und sorgt für eine hohe Verfügbarkeit.
  • Gemäß verschiedenen Ausführungsbeispielen verwendet der Client 315 eine Medienkomponente, welche fragmentierte MPEG-4-Dateien anfordert, Trick-Play ermöglicht, und Bandbreitenanpassung vornimmt. Der Client kommuniziert mit den dem HTTP-Proxy 313 zugeordneten Anwendungsdienstleistungen, um Führer zu erhalten und dem Nutzer den verfügbaren aufgezeichneten Inhalt anzuzeigen.
  • 4 zeigt ein Beispiel für ein Fragmentierungssystem 401, das für Video-on-Demand-Inhalte verwendbar ist. Der Fragger 403 erfordert eine Quelle kodierter Videoclips. Jedoch erzeugt der kommerzielle Kodierer keine Ausgangsdatei mit minimalem objektorientiertem Framework-Dateikopf (MOOF) und bettet stattdessen sämtliche Inhalt-Dateiköpfe in die Movie-Datei (MOOV) ein. Der Fragger liest die Eingangsdatei und erzeugt einen alternativen Ausgang, der mit MOOF-Dateiköpfen fragmentiert und mit individuellen Dateiköpfen erweitert wurde, welche das Erlebnis optimieren und als Hinweise für Server dienen.
  • Der Fragmentserver 411 versieht die Zwischenspeicherungsschicht mit Fragmenten für Clients. Die Designphilosophie hinter der Client/Server-API minimiert Leerläufe und verringert im Hinblick auf die Ausgabe der Mediendaten an den Client 415 die Komplexität so weit wie möglich. Der Fragmentserver 411 liefert VoD-Inhalte.
  • Gemäß verschiedenen Ausführungsbeispielen verwendet der Client 415 eine Medienkomponente, welche fragmentierte MPEG-4-Dateien anfordert, Trick-Play ermöglicht, und Bandbreitenanpassung vornimmt. Der Client kommuniziert mit den dem HTTP-Proxy 413 zugeordneten Anwendungsservices, um Führer zu erhalten und dem Nutzer den verfügbaren aufgezeichneten Inhalt anzuzeigen.
  • 5 zeigt Beispiele für Dateien, welche von dem Fragmentschreiber gespeichert werden. Gemäß verschiedenen Ausführungsbeispielen handelt es sich bei dem Fragmentschreiber um eine Komponente in der Gesamtheit des Fragmentierers. Es handelt sich dabei um ein Binärprogramm, das Befehlszeilenargumente verwendet, um ein bestimmtes Programm basierend entweder auf der NTP-Zeit aus dem kodierten Strom oder auf der Uhrzeit aufzuzeichnen. Bei bestimmten Ausführungsbeispielen ist dies als Teil der Argumente konfigurierbar und ist von dem Eingangs-Strom abhängig. Sobald der Fragmentschreiber das Aufzeichnen eines Programms abgeschlossen hat, wird er geschlossen. Für Live-Ströme werden Programme künstlich als kurze Intervalle von beispielsweise 5–15 Minuten Länge erzeugt.
  • Gemäß verschiedenen Ausführungsbeispielen handelt es sich bei den Fragmentschreiber-Befehlszeilenargumenten um die SDP-Datei des aufzuzeichnenden Kanals, die Startzeit, die Endzeit, den Namen der gegenwärtigen und der nächsten Ausgangsdatei. Der Fragmentschreiber beobachtet den RTP-Verkehr von den Live-Video-Kodierern und schreibt die Mediendaten als fragmentierte MPEG-4 erneut auf die Platte. Gemäß verschiedenen Ausführungsbeispielen werden Mediendaten als fragmentierte MPEG-4 geschrieben, wie dies in MPEG-4 Teil 12 (ISO/IEC 14496-12) definiert ist. Jede übertragene Sendung wird als separate Datei, die durch eine Sendungs-ID (welche aus dem EPG abgeleitet ist) identifiziert ist, auf eine Platte geschrieben. Clients fügen die Sendungs-ID als Teil des Kanalnamens hinzu, wenn sie das Ansehen einer vorab aufgezeichneten Sendung anfordern. Der Fragmentschreiber nimmt jede der verschiedenen Kodierungen auf und speichert sie als verschiedene MPEG-4-Fragmente.
  • Bei bestimmten Ausführungsbeispielen schreibt der Fragmentschreiber die RTP-Daten für eine bestimmte Kodierung und das Sendungs-ID-Feld in eine einzelne Datei. In dieser Datei befinden sich Metadateninformationen, welche die gesamte Datei (MOOV-Blöcke) beschreiben. Atome werden als Gruppen von MOOF/MDAT-Paaren gespeichert, um das Speichern einer Sendung als einzelne Datei zu ermöglichen. Am Ende der Datei befinden sich Direktzugriffsinformationen, die verwendet werden können, um einem Client das Durchführen von Bandbreitenanpassungen und Trickplay-Funktionen zu ermöglichen.
  • Gemäß verschiedenen Ausführungsbeispielen enthält der Fragmentschreiber eine Option, welche Fragmente verschlüsselt, um die Stream-Sicherheit während des Aufzeichnungsvorgangs zu gewährleisten. Der Fragmentschreiber fordert einen Kodierschlüssel von dem Lizenzmanager an. Die verwendeten Schlüssel sind denen ähnlich, die für das DRM verwendet werden. Das Kodierformat ist bei der Kodierung von MOOF geringfügig anders. Die Verschlüsselung erfolgt ein Mal, so dass dadurch keine übermäßigen Kosten während der Ausgabe an die Clients entstehen.
  • Der Fragmentserver antwortet auf HTTP-Anforderungen von Inhalten. Gemäß verschiedenen Ausführungsbeispielen stellt er API bereit, die von Clients genutzt werden können, um erforderliche Dateiköpfe zu erhalten, die für das Dekodieren des Videos sowie das Suchen eines beliebigen gewünschten Zeitabschnitts in dem Fragment notwendig sind, und API für das Live-Ansehen von Kanälen. Tatsächlich werden Live-Kanäle mit den zuletzt geschriebenen Fragmenten einer Sendung auf diesem Kanal gespeist. Der Fragmentschreiber sendet den Mediendateikopf (der für das Initialisieren von Decodern erforderlich ist), bestimmte Fragmente und den Direktzugriffsblock an die Clients zurück. Gemäß verschiedenen Ausführungsbeispielen ermöglichen die unterstützen API eine Optimierung, wenn die Metadatendateikopfinformationen dem Client zusammen mit dem ersten Fragment zurück gesendet werden. Der Fragmentschreiber erzeugt eine Reihe von Fragmenten innerhalb der Datei. Fordert ein Client einen Stream an, fordert er jedes dieser Fragmente an und der Fragmentserver liest den Teil der Datei, welcher das Fragment betrifft, und sendet dieses an den Client zurück.
  • Gemäß verschiedenen Ausführungsbeispielen verwendet der Fragmentserver eine REST API, die zwischenspeicherfreundlich ist, so dass die meisten an den Fragmentserver gerichteten Anforderungen zwischengespeichert werden können. Der Fragmentserver verwendet Zwischenspeicher-Control-Dateiköpfe und ETag-Dateiköpfe, um dem Zwischenspeicher die richtigen Hinweise zu geben. Diese API verleiht ferner die Fähigkeit, zu verstehen, an welcher Stelle ein bestimmter Nutzer die Wiedergabe angehalten hat, und die Wiedergabe von diesem Punkt an zu starten (die Fähigkeit zur Pause bei einem Gerät und zur Fortsetzung bei einem anderen vorausgesetzt).
  • Bei bestimmten Ausführungsbeispielen folgen die Client-Anforderungen nach Fragmenten dem folgenden Format:
    http://{HOSTNAME}/frag/{CHANNEL}/{BITRATE}/[{ID}/]{COMMAND}[/{ARG}] z. B.
    http://frag.hosttv.com/frag/1/H8QVGAH264/1270059632.mp4/fragment/42.
  • Gemäß verschiedenen Ausführungsbeispielen ist der Kanalname der selbe wie der Backend-Kanalname, der als Kanalbereich der SDP-Datei verwendet wird. VOD verwendet den Kanalnamen ”vod”. Die BITRATE sollte dem BITRATE/AUFLÖSUNG-Identifikatorschema entsprechen, die für RTP-Streams verwendet wird. Die ID wird dynamisch zugewiesen. Bei Live-Streams kann es sich dabei um den UNIX-Zeitstempel handeln; bei DVR handelt es sich dabei um eine einzigartige ID für die Sendung; bei VOD handelt es sich dabei um die Posten-ID. Die ID ist optional und nicht in LIVE-Befehl-Anforderungen enthalten. Der Befehl und das Argument dienen der Angabe des genauen gewünschten Befehls und jedweder Argumente. Um beispielsweise den Teil 42 anzufordern, lautet dieser Bereich ”fragment/42”.
  • Das URL-Format macht die Anforderungen geeignet für Inhaltsausgabenetzwerke (CDN), da die Fragmente sich nach diesem Punkt nie mehr verändern, so dass zwei separate Clients, welche den gleichen Strom ansehen, unter Verwendung eines Zwischenspeichers bedient werden können. Insbesondere nutzt die Headend-Architektur dies, um das Eintreffen zu vieler dynamischer Anforderungen an dem Fragmentserver zu vermeiden, indem sie für das Zwischenspeichern von Anforderungen einen HTTP-Proxy am vorderen Ende verwendet.
  • Gemäß verschiedenen Ausführungsbeispielen handelt es sich bei dem Fragment-Controller um ein Daemon, das auf dem Fragmentierer abläuft und die Fragmentschreiberprozesse verwaltet. Es wird vorgeschlagen, hierin ein konfiguriertes Filter zu verwenden, das von dem Fragment-Controller ausgeführt wird, um die Liste der aufzuzeichnenden Übertragungen zu erzeugen. Dieses Filter fügt sich in externe Komponenten ein, wie beispielsweise einen Führerserver, um zu bestimmen, welche Sendungen aufzuzeichnen sind und welche Übertragungs-ID zu verwenden ist.
  • Gemäß verschiedenen Ausführungsbeispielen weist der Client eine Anwendungslogikkomponente und eine Medienwiedergabekomponente auf. Die Anwendungslogikkomponente liefert die UI für den Benutzer und teilt dem Frontend-Server ferner mit, dass er Sendungen beschaffen soll, die für den Benutzer verfügbar sind, und die Authentifizierung vornehmen soll. Als Teil dieses Vorgangs sendet der Server URLs zu Medieninhalten zurück, die an die Medienwiedergabekomponente weitergeleitet werden.
  • In besonderen Ausführungsbeispielen verlässt sich der Client auf die Tatsache, dass jedes Fragment in einer fragmentierten MP-4-Datei eine Sequenznummer hat. Unter Nutzung dieser Kenntnis und einer gut definierten URL-Struktur für die Kommunikation mit dem Server, fordert der Client Fragmente einzeln an, als ob er separate Dateien aus dem Server lesen würde, indem er einfach URLs für Dateien anfordert, die ansteigenden Sequenznummern zugeordnet sind. Bei einigen Ausführungsbeispielen kann der Client Dateien anfordern, die Ströme mit einer höheren oder einer geringeren Bitrate entsprechen, je nachdem, welche Geräte- und Netzwerkressourcen gegeben sind.
  • Da jede Datei die zum Erzeugen der URL für die nächste Datei erforderlichen Informationen enthält, sind keine speziellen Playlist-Dateien erforderlich, und alle Aktionen (Start, Kanalwechsel, Suche) können mittels einer einzigen HTTP-Anforderung durchgeführt werden. Nachdem jedes Fragment heruntergeladen wurde, beurteilt der Client unter anderem die Größe des Fragments und die für dessen Download erforderliche Zeit, um festzustellen, ob eine Verlangsamung erforderlich ist, oder ob ausreichend Bandbreite verfügbar ist, um eine höhere Bitrate anzufordern.
  • Da jede an den Server gerichtete Anforderung wie eine Anforderung nach einer separaten Datei erscheint, kann die Reaktion auf die Anforderungen in jedem HTTP-Proxy zwischengespeichert oder über jedes HTTP-basierte CDN verteilt werden.
  • 6 zeigt eine Interaktion für einen Client, der einen Live-Stream empfängt. Der Client startet die Wiedergabe, während ein Fragment aus dem Server abgespielt wird. Der Client verwendet die Fragmentnummer, so dass er das korrekte nachfolgende Dateifragment anfordern kann. Eine Anwendung, wie beispielsweise eine Abspielanwendung 607 sendet eine Anforderung an ein Mediakit 605. Die Anforderung kann eine Basisadresse und eine Bitrate umfassen. Das Mediakit 605 sendet eine HTTP-Get-Anforderung an die Zwischenspeicherungsschicht 603. Gemäß verschiedenen Ausführungsbeispielen befindet sich die Live-Antwort nicht im Zwischenspeicher und die Zwischenspeicherungsschicht 603 leitet die HTTP-Get-Anforderung an einen Fragmentserver 601 weiter. Der Fragmentserver 601 führt eine Verarbeitung durch und sendet das richtige Fragment an die Zwischenspeicherungsschicht 603, welche die Daten an das Mediakit 605 sendet.
  • Das Fragment kann für einen kurzen Zeitraum in der Zwischenspeicherungsschicht 603 zwischengespeichert werden. Das Mediakit 605 identifiziert die Fragmentnummer und stellt fest, ob die Ressourcen zum Abspielen des Fragments ausreichen. In einigen Beispielen sind die Ressourcen, wie beispielsweise die Verarbeitungs- oder Bandbreitenressourcen, unzureichend. Das Fragment wurde möglicherweise nicht schnell genug empfangen oder das Gerät hat Schwierigkeiten mit einer ausreichend schnellen Dekodierung des Fragments. Folglich kann das Mediakit 605 ein nächstes Fragment anfordern, das eine andere Datenrate hat. In einigen Fällen kann das Mediakit 605 ein nächstes Fragment mit einer höheren Datenrate anfordern. Gemäß verschiedenen Ausführungsbeispielen hält der Fragmentserver 601 Fragmente für verschiedene Service-Stromqualitäten mit Zeitsteuerungssynchronisierungsinformationen bereit, um eine Zeitsteuerung der genauen Wiedergabe zu ermöglichen.
  • Das Mediakit 605 fordert ein nächstes Fragment unter Verwendung von Informationen aus dem empfangenen Fragment an. Gemäß verschiedenen Ausführungsbeispielen kann das nächste Fragment für den Medienstrom auf einem anderen Server gespeichert sein, eine andere Bitrate aufweisen oder eine andere Autorisierung erfordern. Die Zwischenspeicherungsschicht 603 stellt fest, dass sich das nächste Fragment nicht in dem Zwischenspeicher befindet und sendet die Anforderung an den Fragmentserver 601. Der Fragmentserver 601 sendet das Fragment an die Zwischenspeicherungsschicht 603 und das Fragment wird für einen kurzen Zeitraum zwischengespeichert. Das Fragment wird sodann an das Mediakit 605 gesendet.
  • 7 zeigt ein Beispiel für ein Verfahren für das Pufferkonfigurations-Management. Bei 701 sendet ein Clientgerät eine Anforderung eines Medienstroms. Gemäß verschiedenen Ausführungsbeispielen liefert das Clientgerät Informationen über das Clientgerät an einen Inhaltsserver, beispielsweise einen Fragmentserver. Die Informationen können die Auflösung, die Puffergröße, die Verarbeitungsfähigkeiten, den Netzwerkdurchsatz, durchschnittliche Datenübertragungsraten, die Position etc. umfassen. Bei bestimmten Ausführungsbeispielen besitzt der Inhaltsserver bereits Informationen über das Clientgerät. Der Inhaltsserver wählt einen Strom mit einem geeigneten Qualitätslevel zur Ausgabe an das Clientgerät aus. Bei 703 beginnt das Clientgerät mit dem Empfang von Inhalt unter Verwendung einer anfänglichen Pufferkonfiguration. Wenn bei 705 ein Wiedergabeschwellenwert erreicht wird, beginnt die Wiedergabe. Gemäß verschiedenen Ausführungsbeispielen sendet das Clientgerät, wenn ein Schwellenwert für eine geringere Qualität erreicht wird, bei 709 eine Anforderung an den Inhaltsserver zur Übertragung eines Stroms von geringerer Qualität. Der Strom geringerer Qualität kann ein Strom mit geringerer Bitrate sein. Es können mehrere Schwellenwerte für eine geringere Qualität vorgesehen sein. Wenn beim Füllen des Puffers während der Wiedergabe ein Schwellenwert für eine höhere Qualität erreicht wird, kann in manchen Fällen ein Clientgerät eine Anforderung an den Inhaltsserver senden, um mit dem Empfang eines Stroms höherer Qualität zu beginnen. Die Änderung der Qualität kann auf der Grundlage der Pufferlevel vorgenommen werden.
  • Wenn ein Clientgerätepuffer sich erschöpft, wird bei 713 eine neue Pufferkonfiguration erstellt. Die modifizierte Pufferkonfiguration weist einen höheren Wiedergabestartschwellenwert auf. Der höhere Wiedergabestartschwellenwert kann den Beginn der Wiedergabe verzögern, verringert jedoch die Gefahr der Erschöpfung des Puffers. Beginnt der Puffer dennoch sich zu erschöpfen und erreicht er einen Schwellenwert für eine geringere Qualität, sendet das Clientgerät bei 715 an den Inhaltsserver eine Anforderung für den Empfang eines Stroms geringerer Qualität. Bei einigen Ausführungsbeispielen können zusätzliche modifizierte Pufferkonfigurationen erstellt werden, wenn der Puffer sich erneut erschöpft.
  • 8 zeigt ein Beispiel für einen Fragmentserver. Gemäß bestimmten Ausführungsbeispielen weist ein System 800, das zum Implementieren bestimmter Ausführungsbeispiele der vorliegenden Erfindung geeignet ist, einen Prozessor 801, einen Speicher 803, ein Interface 811 und einen Bus 815 (beispielsweise einen PCI-Bus oder eine andere Verbindungsstruktur) auf und arbeitet als Streaming-Server. Wenn er unter Steuerung durch geeignete Software oder Firmware arbeitet, ist der Prozessor 801 für das Modifizieren und Übertragen von Live-Mediendaten an einen Client verantwortlich. Verschiedene speziell konfigurierte Vorrichtungen können ebenfalls anstelle des Prozessors 801 oder zusätzlich zu dem Prozessor 801 verwendet werden. Das Interface 811 ist üblicherweise zum Senden und Empfangen von Datenpaketen oder Datensegmenten über ein Netzwerk konfiguriert.
  • Besondere Beispiele für unterstützte Interfaces umfassen Ethernet-Interfaces, Frame-Relay-Interfaces, Kabel-Interfaces, DSL-Interfaces, Token-Ring-Interfaces und dergleichen. Darüber hinaus können verschiedene sehr schnelle Interfaces vorgesehen sein, wie beispielsweise Fast-Ethernet-Interfaces, Gigabit-Ethernet-Interfaces, ATM-Interfaces, HSSI-Interfaces, POS-Interfaces, FDDI-Interfaces und dergleichen. Im Allgemeinen können diese Interfaces Ports aufweisen, welche für die Kommunikation mit geeigneten Medien geeignet sind. In einigen Fällen können sie auch einen unabhängigen Prozessor und in einigen Fällen einen flüchtigen RAM aufweisen. Die unabhängigen Prozessoren können solch kommunikationsintensive Aufgaben wie Paketwechsel, Mediensteuerung und -verwaltung wahrnehmen.
  • Gemäß verschiedenen Ausführungsbeispielen handelt es sich bei dem System 800 um einen Fragmentserver, der ferner einen Transceiver, Streaming-Puffer und eine Programmführerdatenbank aufweist. Der Fragmentserver kann ferner mit Fähigkeiten für die Abonnementverwaltung, die Logging- und Berichterstellung und die Überwachung versehen sein. In bestimmten Ausführungsbeispielen besteht die Möglichkeit des Betriebs mit mobilen Geräten, wie Mobiltelefonen, die in einem bestimmten Mobilfunknetz betrieben werden, und der Bereitstellung einer Abonnementverwaltung. Gemäß verschiedenen Ausführungsbeispielen prüft ein Authentisierungsmodul die Identität von Geräten, einschließlich Mobilgeräten. Ein Logging- und Berichterstellungsmodul verfolgt Anforderungen von Seiten von Mobilgeräten und die entsprechenden Antworten. Ein Überwachungssystem ermöglicht es einem Administrator, Nutzungsmuster und die Systemverfügbarkeit zu beobachten. Gemäß verschiedenen Ausführungsbeispielen handhabt der Fragmentserver Anforderungen und Antworten bezüglich Medieninhalte betreffenden Transaktionen, während ein separater Streaming-Server die eigentlichen Medien-Ströme liefert.
  • Zwar wurde ein bestimmter Fragmentserver beschrieben, jedoch sollte ersichtlich sein, dass eine Vielzahl alternativer Konfigurationen möglich ist. Beispielsweise sind einige Module wie das Logging- und Berichterstellungsmodul und ein Monitormodul möglicherweise nicht in jedem Server erforderlich. Alternativ können die Module in einer anderen Vorrichtung ausgebildet sein, welche mit dem Server verbunden ist. In einem anderen Beispiel weist der Server kein Interface zu einer Abstraktkaufmaschine aus und kann tatsächlich die Abstraktkaufmaschine selbst aufweisen. Eine Vielzahl von Konfigurationen ist möglich.
  • In der vorangehenden Beschreibung wurde die Erfindung unter Bezugnahme aus spezifische Ausführungsbeispiele beschrieben. Für den Fachmann auf diesem Gebiet ist jedoch ersichtlich, dass verschiedene Modifizierungen und Änderungen vorgenommen werden können, ohne den in den Ansprüchen nachfolgend ausgeführten Rahmen der Erfindung zu verlassen. Die Beschreibung und die Figuren sind daher eher als illustrativ, denn als einschränkend anzusehen, und sämtliche derartigen Modifizierungen gelten als in den Rahmen der Erfindung eingeschlossen.

Claims (10)

  1. Verfahren, umfassend: das Senden einer ersten Anforderung eines Medienstroms an einen Inhaltsserver; das Erstellen eines anfänglichen Wiedergabepuffers; das Empfangen eines Medienstroms eines ersten Qualitätslevels in dem anfänglichen Wiedergabepuffer; das Beginnen der Wiedergabe des Medienstroms des ersten Qualitätslevels nach dem Erreichen des anfänglichen Wiedergabeschwellenwerts in dem anfänglichen Wiedergabepuffer; das Senden einer zweiten Anforderung eines Medienstroms eines zweiten Qualitätslevels an den Inhaltsserver nach dem Erreichen des anfänglichen Wiedergabeschwellenwerts in dem anfänglichen Wiedergabepuffer; wobei ein modifizierter Wiedergabepuffer erstellt wird, wenn sich der anfängliche Wiedergabepuffer erschöpft, wobei der modifizierte Wiedergabepuffer einen modifizierten Wiedergabeschwellenwert aufweist, der höher als der anfängliche Wiedergabeschwellenwert ist.
  2. Verfahren nach Anspruch 1, bei welchem der Medienstrom des zweiten Qualitätslevels den gleichen Inhalt liefert wie der Medienstrom des ersten Qualitätslevels, jedoch mit einer geringeren Bitrate.
  3. Verfahren nach Anspruch 1, bei welchem der der Medienstrom des zweiten Qualitätslevels den gleichen Inhalt liefert wie der Medienstrom des ersten Qualitätslevels, jedoch mit einer höheren Bitrate.
  4. Verfahren nach Anspruch 1, bei welchem an den Inhaltsserver eine dritte Anforderung eines Medienstroms eines dritten Qualitätslevels gesendet wird, nachdem ein modifizierter Qualitätsschwellenwert in dem modifizierten Wiedergabepuffer erreicht wurde.
  5. Verfahren nach Anspruch 1, bei welchem der Medienstrom des ersten Qualitätslevels ein erstes Fragment, das mit einer ersten Bitrate kodiert ist, aufweist.
  6. Verfahren nach Anspruch 5, bei welchem das erste Fragment eine erste Fragmentnummer und eine Feldstruktur aufweist, welche Synchronisierungsinformationen, Dateiende-Informationen und Kapitelinformationen unterstützt.
  7. Verfahren nach Anspruch 6, bei welchem die Synchronisierungsinformationen der Audio- und Video-Synchronisierung dienen, wenn die Wiedergabe einen Beginn mitten in einem Strom mit sich bringt.
  8. Verfahren nach Anspruch 6, bei welchem der Medienstrom des zweiten Qualitätslevels ein zweites Fragment, das mit einer zweiten Bitrate kodiert ist, aufweist.
  9. Verfahren nach Anspruch 8, bei welchem das zweite Fragment eine zweite Fragmentnummer und eine Feldstruktur aufweist, welche Synchronisierungsinformationen, Dateiende-Informationen und Kapitelinformationen unterstützt, wobei die zweite Fragmentnummer aus der ersten Fragmentnummer abgeleitet ist.
  10. Verfahren nach Anspruch 5, bei welchem die erste Fragmentnummer einem Zeitindex für ein nahezu live gesendetes Medienprogramm entspricht.
DE112012002159.2T 2011-05-19 2012-05-04 Kontextsensitive Client-Pufferschwellenwerte Withdrawn DE112012002159T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US13/111,151 US8769144B2 (en) 2011-05-19 2011-05-19 Contextually aware client buffer thresholds
USUS-13/111,151 2011-05-19
PCT/US2012/036451 WO2012158365A1 (en) 2011-05-19 2012-05-04 Contextually aware client buffer thresholds

Publications (1)

Publication Number Publication Date
DE112012002159T5 true DE112012002159T5 (de) 2014-02-20

Family

ID=47175810

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112012002159.2T Withdrawn DE112012002159T5 (de) 2011-05-19 2012-05-04 Kontextsensitive Client-Pufferschwellenwerte

Country Status (4)

Country Link
US (3) US8769144B2 (de)
DE (1) DE112012002159T5 (de)
GB (1) GB2506047B (de)
WO (1) WO2012158365A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9635080B2 (en) 2011-05-19 2017-04-25 Mobitv, Inc. Contextually aware client buffer thresholds

Families Citing this family (33)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8965545B2 (en) * 2010-09-30 2015-02-24 Google Inc. Progressive encoding of audio
DE102012201534B4 (de) * 2011-12-09 2018-08-30 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Vorrichtung zur Zwischenspeicherung einer skalierbaren Original-Datei
WO2013106390A1 (en) 2012-01-09 2013-07-18 Activevideo Networks, Inc. Rendering of an interactive lean-backward user interface on a television
US9800945B2 (en) 2012-04-03 2017-10-24 Activevideo Networks, Inc. Class-based intelligent multiplexing over unmanaged networks
US10171887B2 (en) * 2013-03-13 2019-01-01 Comcast Cable Communications, Llc Methods and systems for intelligent playback
US9565139B2 (en) * 2013-03-15 2017-02-07 Comcast Cable Communications, Llc Remote latency adjustment
WO2014145921A1 (en) 2013-03-15 2014-09-18 Activevideo Networks, Inc. A multiple-mode system and method for providing user selectable video content
US9503491B2 (en) * 2013-03-15 2016-11-22 Echostar Technologies L.L.C. Playback stall avoidance in adaptive media streaming
US9788029B2 (en) 2014-04-25 2017-10-10 Activevideo Networks, Inc. Intelligent multiplexing using class-based, multi-dimensioned decision logic for managed networks
US20160119154A1 (en) * 2014-10-23 2016-04-28 LiveQoS Inc. Usage and performance based billing
US20160164788A1 (en) * 2014-12-05 2016-06-09 Qualcomm Incorporated Egress Rate Shaping To Reduce Burstiness In Application Data Delivery
US10523985B2 (en) 2014-12-24 2019-12-31 Activevideo Networks, Inc. Managing deep and shallow buffers in a thin-client device of a digital media distribution network
US10264293B2 (en) 2014-12-24 2019-04-16 Activevideo Networks, Inc. Systems and methods for interleaving video streams on a client device
US9756112B2 (en) 2015-02-11 2017-09-05 At&T Intellectual Property I, L.P. Method and system for managing service quality according to network status predictions
US10735489B1 (en) * 2016-03-21 2020-08-04 Amazon Technologies, Inc. Mid-stream content delivery network switching
US10878028B1 (en) 2017-11-22 2020-12-29 Amazon Technologies, Inc. Replicating and indexing fragments of time-associated data streams
US11025691B1 (en) * 2017-11-22 2021-06-01 Amazon Technologies, Inc. Consuming fragments of time-associated data streams
US10944804B1 (en) 2017-11-22 2021-03-09 Amazon Technologies, Inc. Fragmentation of time-associated data streams
US10764347B1 (en) 2017-11-22 2020-09-01 Amazon Technologies, Inc. Framework for time-associated data stream storage, processing, and replication
US10298995B1 (en) * 2017-12-29 2019-05-21 Dish Network L.L.C. Predictive pre-buffering
US10587670B2 (en) 2017-12-29 2020-03-10 Dish Network L.L.C. Coverage optimized content buffering
US10693575B2 (en) 2018-08-31 2020-06-23 At&T Intellectual Property I, L.P. System and method for throughput prediction for cellular networks
CN109327716B (zh) * 2018-10-31 2020-09-11 北京达佳互联信息技术有限公司 延迟控制方法、延迟控制装置和计算机可读存储介质
US10868726B2 (en) 2018-12-07 2020-12-15 At&T Intellectual Property I, L.P. Apparatus and method for selecting a bandwidth prediction source
CN109769140A (zh) * 2018-12-20 2019-05-17 南京杰迈视讯科技有限公司 一种基于流媒体技术的网络视频流畅播放控制方法
US11490149B2 (en) 2019-03-15 2022-11-01 At&T Intellectual Property I, L.P. Cap-based client-network interaction for improved streaming experience
CN112040302B (zh) 2019-06-03 2023-01-03 优视科技有限公司 视频缓冲方法、装置、电子设备及计算机可读存储介质
US11818187B2 (en) * 2019-08-31 2023-11-14 Sonos, Inc. Mixed-mode synchronous playback
US20210256057A1 (en) * 2020-02-13 2021-08-19 Beijing Dajia Internet Information Technology Co., Ltd. Method for playing audio, device, terminal, server and storage medium
US11902900B2 (en) * 2020-05-29 2024-02-13 Qualcomm Incorporated User equipment (UE)-based discontinuous control channel monitoring
US11178198B1 (en) 2020-11-04 2021-11-16 Disney Enterprises, Inc. Buffering data on high bandwidth networks
US11350160B1 (en) * 2021-04-14 2022-05-31 Synamedia Limited Management of a client device buffer
US20240196049A1 (en) * 2022-12-08 2024-06-13 Synamedia Limited Client Device Switching to Low Latency Content

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6665751B1 (en) * 1999-04-17 2003-12-16 International Business Machines Corporation Streaming media player varying a play speed from an original to a maximum allowable slowdown proportionally in accordance with a buffer state
US6760303B1 (en) * 2000-03-29 2004-07-06 Telefonaktiebolaget Lm Ericsson (Publ) Channel-type switching based on cell load
WO2004039034A1 (en) * 2002-10-24 2004-05-06 Telefonaktiebolaget Lm Ericsson (Publ) System and method for reducing initial buffering time for a streaming application
CA2411506C (en) * 2002-11-07 2010-02-16 Research In Motion Limited Pseudo-interactive input processing in wireless environments
US9344476B2 (en) * 2005-04-11 2016-05-17 Telefonaktiebolaget Lm Ericsson (Publ) Technique for controlling data packet transmission of variable bit rate data
US8804515B2 (en) * 2005-04-11 2014-08-12 Telefonaktiebolaget Lm Ericsson (Publ) Technique for dynamically controlling data packet transmissions
US20080244042A1 (en) 2007-03-26 2008-10-02 Sugih Jamin Method and system for communicating media over a computer network
US8335262B2 (en) * 2008-01-16 2012-12-18 Verivue, Inc. Dynamic rate adjustment to splice compressed video streams
US8223641B2 (en) * 2008-07-28 2012-07-17 Cellco Partnership Dynamic setting of optimal buffer sizes in IP networks
US8291451B2 (en) 2008-12-24 2012-10-16 Verizon Patent And Licensing Inc. Providing dynamic information regarding a video program
US9438861B2 (en) 2009-10-06 2016-09-06 Microsoft Technology Licensing, Llc Integrating continuous and sparse streaming data
US9313512B2 (en) * 2009-11-25 2016-04-12 Vudu, Inc. Multiple bit rate encoding by segments
EP2451151B1 (de) * 2010-11-08 2014-08-13 Deluxe Media Inc. Verfahren und Vorrichtung zur Steuerung der Wiedergabe von Inhalten in Bezug auf aufgezeichneten Inhalt
US8769144B2 (en) 2011-05-19 2014-07-01 Mobitv, Inc. Contextually aware client buffer thresholds
US8542561B1 (en) * 2011-10-12 2013-09-24 Marvell International Ltd. Method and apparatus for reading a storage medium
US9674100B2 (en) * 2013-11-11 2017-06-06 Hulu, LLC Dynamic adjustment to multiple bitrate algorithm based on buffer length

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9635080B2 (en) 2011-05-19 2017-04-25 Mobitv, Inc. Contextually aware client buffer thresholds
US10250659B2 (en) 2011-05-19 2019-04-02 Mobitv, Inc. Contextually aware client buffer thresholds

Also Published As

Publication number Publication date
US20120297081A1 (en) 2012-11-22
GB2506047A (en) 2014-03-19
US8769144B2 (en) 2014-07-01
US9635080B2 (en) 2017-04-25
WO2012158365A1 (en) 2012-11-22
GB201322070D0 (en) 2014-01-29
US10250659B2 (en) 2019-04-02
US20170302717A1 (en) 2017-10-19
GB2506047B (en) 2018-05-23
US20140250212A1 (en) 2014-09-04

Similar Documents

Publication Publication Date Title
DE112012002159T5 (de) Kontextsensitive Client-Pufferschwellenwerte
DE112012001770T5 (de) Auf Echtzeitverarbeitungsfähigkeit basierende Qualitätsanpassung
DE112011101911T5 (de) Fragmentierte Dateistruktur für die Ausgabe von Live-Medien-Streams
DE112011103333T5 (de) Medienkonvergenzplattform
DE112011102878T5 (de) Nutzer- und Vorrichtungsauthentifizierung für Mediendienstleistungen
US9787747B2 (en) Optimizing video clarity
DE112011101908T5 (de) Qualitätseinstellung unter Verwendung eines fragmentierten Medienstroms
US9351020B2 (en) On the fly transcoding of video on demand content for adaptive streaming
DE112011102879T5 (de) Medienrechteverwaltung auf mehreren Geräten
DE112012002526B4 (de) Medieninhalt-Übertragungsverfahren und Übertragungsvorrichtung unter Verwendung desselben
DE112013001136T5 (de) Effiziente Abgrenzung und Verteilung von Media-Segmenten
DE112013002247T5 (de) Kombinierte Broadcast- und Unicast-Übermittlung
DE112006002677T5 (de) Verfahren und Vorrichtung für RTP-Ausgabe-Streaming unter Verwendung von komplementären Richtungsdateien
DE112011101004T5 (de) Medienkonvergenzplattform
KR102137858B1 (ko) 송신 장치, 송신 방법, 수신 장치, 수신 방법 및 프로그램
DE112012004994T5 (de) Verbesserte Bildergruppen-(GOP)-Ausrichtung in Medienstromvarianten
DE112014000242T5 (de) Skalierbare digitale Videoaufzeichnungen auf Netzwerkbasis über eine Architektur auf Shard-Basis
US20130135525A1 (en) Fragment boundary independent closed captioning
EP3507987A1 (de) Verfahren zur übertragung von echtzeitbasierten digitalen videosignalen in netzwerken
Eberhard et al. Nextsharepc: an open-source bittorrent-based p2p client supporting svc
DE102018108784B4 (de) Verfahren zum Senden eines digitalen Videosignals an ein Empfangsgerät, Recheneinheit und Computerprogrammprodukt
Bouzakaria Advanced contributions in HTTP adaptive streaming
DE112018002893T5 (de) Verfahren zum Senden und Empfangen eines Rundsendungssignals und eine Vorrichtung hierfür
WO2009080111A1 (en) Method and apparatus for distributing media over a communications network

Legal Events

Date Code Title Description
R005 Application deemed withdrawn due to failure to request examination