DE112013002247T5

DE112013002247T5 - Kombinierte Broadcast- und Unicast-Übermittlung

Info

Publication number: DE112013002247T5
Application number: DE201311002247
Authority: DE
Inventors: Torbjorn Einarsson; J. Fritz Barnes
Original assignee: MobiTv Inc
Current assignee: Adeia Media Holdings LLC
Priority date: 2012-04-27
Filing date: 2013-04-26
Publication date: 2015-03-05
Also published as: US20130290555A1; WO2013163551A1; US9769236B2; US20150106439A1; US8949451B2; GB201416930D0; GB2515931B; GB2515931A

Abstract

Hierin werden Techniken zum Ermöglichen einer kombinierten Broadcast- und Unicast-Übermittlung von Inhalt beschrieben. Gemäß verschiedenen Ausführungsformen kann ein Medien-Stream von einem Inhaltsanbieter an einem Unicast-Server und einem Broadcast-Server empfangen werden. Der Medien-Stream kann mehrere Medien-Stream-Fragmente umfassen. Am Broadcast-Server kann eine relative Verzögerung in den Medien-Stream eingebracht werden, so dass Medien-Stream-Fragmente, die von dem Broadcast-Server gesendet werden, relativ zu Medien-Stream-Fragmenten, die von dem Unicast-Server gesendet werden, verzögert werden. Die Medien-Stream-Fragmente können an eine Benutzereinheit gesendet werden. Die Benutzereinheit kann so zu betreiben sein, dass sie zwischen dem Empfang der Medien-Stream-Fragmente von dem Unicast-Server und dem Broadcast-Server umschaltet.

Description

VERWEIS AUF VERWANDTE PATENTANMELDUNGEN
Die vorliegende Patentanmeldung beansprucht die Priorität der US-Patentanmeldung 13/535,870 der Bezeichnung „COMBINED BROADCAST AND UNICAST DELIVERY”, eingereicht am 28. Juni 2012 (Anwalts-Aktenzeichen MOBIP095US), welche die Priorität der vorläufigen US-Patentanmeldung 61/639,566 der Bezeichnung „COMBINED BROADCAST AND UNICAST DELIVERY” von Einarsson und Barnes, eingereicht am 27. April 2012 (Anwalts-Aktenzeichen MOBIP095P), beansprucht, welche in ihrer Gesamtheit und für alle Zwecken durch Verweis hierin einbezogen wird.
TECHNISCHES GEBIET
Die vorliegende Erfindung betrifft die Broadcast- und Unicast-Übermittlung.
BESCHREIBUNG DES STANDES DER TECHNIK
Es ist eine Vielfalt von Broadcast-Medienübermittlungsmechanismen verfügbar. In einigen Fällen kann Medieninhalt unter Verwendung von RTP-basiertem Streaming durch Broadcast an Einheiten gesendet werden. Es ist auch eine Vielfalt von Unicast-Medienübermittlungsmechanismen verfügbar. HTTP-Streaming sowie RTSP/RTP-basiertes Streaming können verwendet werden, um einzelne Medien-Streams an Client-Einheiten zu übermitteln. Broadcast und Unicast weisen beide eine Vielfalt von Vorteilen und Nachteilen auf und werden demzufolge beide in verschiedenen Umgebungen angewendet.
Mechanismen zum Ermöglichen eines effektiven Umschaltens zwischen Broadcast- und Unicast-Übermittlungsmechanismen sind jedoch beschränkt. Deswegen ermöglichen die Techniken und Mechanismen der vorliegenden Erfindung ein verbessertes Umschalten zwischen Broadcast- und Unicast-Übermittlungsmechanismen.
KURZBESCHREIBUNG DER ZEICHNUNGEN
Die Offenbarung ist am besten durch die folgende Beschreibung in Verbindung mit den begleitenden Zeichnungen zu verstehen, welche spezielle Ausführungsformen veranschaulichen.
1 veranschaulicht beispielhafte Systeme, welche mit verschiedenen Techniken und Mechanismen der vorliegenden Erfindung verwendet werden können.
2 veranschaulicht eine Technik zum Unterstützen des Medien-Streaming-Sitzungs-Transporttyp-Umschaltens.
3 veranschaulicht eine Technik zum Unterstützen des Umschaltens des Transporttyps einer Medien-Streaming-Sitzung.
4 veranschaulicht ein Beispiel eines Systems, welches mit verschiedenen Techniken und Mechanismen der vorliegenden Erfindung verwendet werden kann.
BESCHREIBUNG BEISPIELHAFTER AUSFÜHRUNGSFORMEN
Es wird nun detailliert auf einige spezielle Beispiele der Erfindung Bezug genommen, umfassend die von den Erfindern vorgesehenen besten Formen zum Ausführen der Erfindung. Beispiele dieser speziellen Ausführungsformen sind in den begleitenden Zeichnungen veranschaulicht. Obwohl die Erfindung in Verbindung mit diesen speziellen Ausführungsformen beschrieben wird, versteht es sich, dass die Erfindung nicht auf die beschriebenen Ausführungsformen beschränkt sein soll. Es sollen stattdessen Alternativen, Modifikationen und Äquivalente abgedeckt sein, welche unter die Idee und den Umfang der Erfindung fallen, wie sie durch die anhängenden Patentansprüche definiert sind.
Zum Beispiel werden die Techniken der vorliegenden Erfindung im Kontext von Fragmenten, speziellen Servern und Codiermechanismen beschrieben. Es sollte jedoch bedacht werden, dass die Techniken der vorliegenden Erfindung auf eine breite Vielfalt von verschiedenen Fragmenten, Segmenten, Servern und Codiermechanismen angewendet werden können. In der folgenden Beschreibung werden zahlreiche spezielle Einzelheiten ausgeführt, um für ein gründliches Verständnis der vorliegenden Erfindung zu sorgen. Spezielle beispielhafte Ausführungsformen der vorliegenden Erfindung können ohne einige dieser oder all diese speziellen Einzelheiten verwirklicht werden. In anderen Fällen wohlbekannte Verfahrensoperationen nicht detailliert beschrieben worden, um die vorliegende Erfindung nicht unnötig zu verschleiern.
Verschiedene Techniken und Mechanismen der vorliegenden Erfindung werden manchmal aus Gründen der Klarheit in Singularform beschrieben. Man sollte jedoch beachten, dass einige Ausführungsformen mehrere Wiederholungen einer Technik oder mehrere Instanzierungen eines Mechanismus umfassen, sofern nicht anders angegeben. Zum Beispiel wird in einem System ein Prozessor in einer Vielfalt von Kontexten benutzt. Es versteht sich jedoch, dass ein System mehrere Prozessoren verwenden kann und dabei immer noch innerhalb des Umfangs der Erfindung bleibt, sofern nicht anders angegeben. Ferner beschreiben die Techniken und Mechanismen der vorliegenden Erfindung manchmal eine Verbindung zwischen zwei Einheiten. Man sollte jedoch beachten, dass eine Verbindung zwischen zwei Einheiten nicht notwendigerweise eine direkte, ungehinderte Verbindung bedeutet, da zwischen den zwei Einheiten eine Vielfalt von anderen Einheiten angeordnet sein kann. Zum Beispiel kann ein Prozessor mit einem Speicher verbunden sein, es versteht sich jedoch, dass eine Vielfalt von Brücken und Steuerungen zwischen dem Prozessor und dem Speicher angeordnet sein können. Demzufolge bedeutet eine Verbindung zwischen zwei Einheiten nicht notwendigerweise eine direkte, ungehinderte Verbindung, sofern nicht anders angegeben.
Überblick
Es wird ein System zum Ermöglichen nahtloser oder nahezu nahtloser Übergänge zwischen im Broadcast-Verfahren verteilten Medien und im Unicast-Verfahren übermittelten Medien bereitgestellt. Alle Medienverteilungsmechanismen könnten modifiziert werden, um nahtlose oder nahezu nahtlose Übergänge zu ermöglichen. In einigen Beispielen werden die Medien in Fragmente oder Segmente unterteilt und an Broadcast-Server und Unicast-Server gesendet. Zwischen den Broadcast-Servern und den Unicast-Servern wird eine relative Verzögerung eingebracht, so dass sich Broadcast-Sendefragmente um ein oder mehrere Fragmente hinter Unicast-Fragmenten befinden, um einer Client-Einheit Zeit zu geben, um Unicast-Fragmente anzufordern und abzurufen, wenn die entsprechenden Broadcast-Fragmente nicht verfügbar sind.
Beispielhafte Ausführungsformen
Gemäß verschiedenen Ausführungsformen kann ein Medieninhalt über verschiedene Transporttechniken wie z. B. Broadcast, Unicast und Multicast gesendet werden. Broadcast-Technologien können beliebige Technologien umfassen, die dafür konfiguriert sind, Informationen in fortlaufender Weise zu senden, auch ohne Kommunikationen oder spezielle Anforderungen der Informationen von der empfangenden Einheit oder den empfangenden Einheiten. Zu jeder speziellen Zeit können Informationen, die durch Broadcast-Technologien gesendet werden, von einer einzelnen Einheit, von mehr als einer Einheit oder von überhaupt keiner Einheit empfangen werden, was von Faktoren wie dem Typ der verwendeten Broadcast-Technologie, den Netzwerkbedingungen des Netzwerks, über welches die Informationen rundgesendet werden, oder den Bedingungen der Client-Einheit oder Client-Einheiten abhängt. Unicast-Technologien können beliebige Technologien umfassen, die dafür konfiguriert sind, Meldungen in Punkt-zu-Punkt-Form über ein Netzwerk zu senden. Das heißt, ein Server oder eine andere Maschine kann eine Meldung an eine bestimmte Einheit senden, die über ein Netzwerk in Kommunikation mit dem Server steht.
Gemäß verschiedenen Ausführungsformen können Multicast-Technologien beliebige Technologien zum Senden von Daten für eine Gruppe von Zielen umfassen. Viele hierin beschriebene Techniken werden allgemein in Bezug auf Unicast- und Broadcast-Technologien oder in Bezug auf spezielle Unicast- und Broadcast-Technologien beschrieben. Die Techniken sind jedoch allgemein auf eine breite Vielfalt von Transporttypen anwendbar. Zum Beispiel können Techniken auf eine IP-Multicast-Einrichtung anwendbar sein, bei welcher ein Empfänger auswählt, Pakete zu empfangen. Als ein anderes Beispiel können Techniken auf eine Sendeeinrichtung anwendbar sein, bei welcher ein Empfänger in eine bestimmte Frequenz oder eine andere Inhaltsquelle einschalten kann, um Daten zu empfangen. Entsprechend können Transporttypen wie Multicast Alternativen zu Broadcast oder Unicast sein oder können in dem Umfang von Broadcast oder Unicast enthalten sein, was von den speziellen Technologien oder dem speziellen Netzwerk abhängt, die verwendet werden.
Hypertext-Transfer-Protokoll(HTTP)-Unicast-Streaming ist ein komfortabler Mechanismus ZUM Verteilen sowohl von Medieninhalt als auch von Near-Live-Streaming-Video- und Videoclip-Inhalt. Einzelne Streams werden ausgewählt und zu jedem Benutzer transportiert. Im Gegensatz zu einem progressiven Herunterladen wird der Medieninhalt in Fragmente oder Segmente partitioniert, die als separate Dateien oder Byte-Bereiche einer größeren Datei übermittelt werden. Eine Vielfalt von Fragment-Streams kann in verschiedenen Qualitätsstufen codiert werden, um eine Auswahl unter den Varianten nahezu in Echtzeit zu ermöglichen. Die Uniform Resource Locators (URLs) der Segmente werden typischerweise in einer Manifestierungsdatei bereitgestellt, welche entweder eine URL-Vorlagenstruktur oder eine explizite Liste von Segment-URLs enthält. Fragmentbasiertes Streaming kann existierende HTTP-Server und Inhaltsübermittlungsnetzwerk(Content Delivery Network, CDN)-Netzwerke verbessern und im Vergleich zum RTP-Streaming bedeutend weniger Probleme mit Firewalls bewirken. Es besteht daher ein Trend dazu, sich vom Echtzeit-Streaming-Protokoll/Echtzeit-Transportprotokoll(Real-Time-Streaming-Protocol/Real-Time-Transport-Protocol, RTSP/RTP)-basierten Streaming weg und zum HTTP-Streaming hin zu bewegen. Starke Entwicklungen in diese Richtung umfassen HTTP-Live-Streaming (HLS) und DASH (Dynamic Adaptive Streaming over HTTP, Dynamisches Adaptives Streaming über HTTP) von 3GPP und MPEG.
RTP-basiertes Multicast-Streaming über Broadcast-Netzwerke bleibt in bestimmten Umgebungen vorherrschend. Der 3GPP-Standard Multimedia Broadcast Multicast Services (MBMS) beruhte auf einem RTP-basierten Streaming für die Video-Verteilung. Außerdem gibt es in MBMS einen Modus zum Herunterladen/Dateiverteilen unter Verwendung des File-Delivery-over-Unidirectional-Transport(Dateiübermittlung über unidirektionalen Transport, FLUTE)-Protokolls, immer noch unter Verwendung von IP-Multicast. Beispielhafte Anwendungsfälle hierfür umfassen die Verteilung von elektronischen Programmführungsdaten und Datendateien, wie z. B. Sportstatistiken.
Mit der Einführung von MBMS in LTE-Netzwerken der 4. Generation steigt das Interesse an MBMS, insbesondere in einer Version, die als „eMBMS” bezeichnet wird. Der Live-Video-Verteilungsmechanismus unter Verwendung des RTP ist immer noch Standard, aber eMBMS ermöglicht MBMS, Video und andere kontinuierlichen Medien unter Verwendung von DASH-kompatiblen Medien und Metadaten-Paketbildung zu verteilen. Es gibt somit ein Mittel zur Broadcast-Verteilung von DASH zusätzlich zu der HTTP-basierten Unicast-Standardverteilung von DASH.
Die Mechanismen zum Umschalten zwischen Broadcast- und Unicast-Verteilungen wie z. B. Broadcast- und Unicast-Verteilungen von DASH sind jedoch begrenzt oder nicht verfügbar. Insbesondere da möglicherweise nicht das vollständige Netzwerk Broadcast-fähig ist, ist es wichtig, dass eine Sitzung fortgesetzt werden kann, auch wenn zwischen Broadcast- und Unicast-Verteilungen umgeschaltet wird.
MBMS weist eine Unterstützung für Punkt-zu-Punkt-Wiederherstellung über Unicast auf. Es weist auch eine Umschaltung zwischen Punkt-zu-Punkt- und Broadcast-Sendung in Abhängigkeit von der Anzahl an Benutzern in einer Zelle auf. Dies macht es jedoch keinen Übergang zwischen einem Netzwerk, welches nicht MBMS-fähig ist, z. B. einem weniger hochentwickelten zellulären oder WLAN-Netzwerk, und einem MBMS-Netzwerk möglich.
Gemäß verschiedenen Ausführungsformen ermöglichen die hierin beschriebenen Techniken und Mechanismen nahtlose oder nahezu nahtlose Übergänge zwischen im Broadcast-Verfahren verteilten segmentierten Medien und einem entsprechenden Transport derselben Medien im Unicast-Verfahren (z. B. unter Verwendung von HTTP). In einigen Fällen kann ein Transport derselben Medien im Unicast-Verfahren eine adaptive Auswahl der richtigen Bitratenvariante in Abhängigkeit von Netzwerkbedingungen ermöglichen. Gemäß verschiedenen Ausführungsformen können existierende dateibasierte Medienverteilungsmechanismen gemäß hierin beschriebenen Techniken modifiziert werden, um ein nahtloses Umschalten zu ermöglichen. Mediendaten, die in Kurzintervallsegmente aufgeteilt sind, können über Broadcast (BC) oder Unicast (UC) gesendet werden. Dies umfasst das Verteilen von DASH-Mediensegmenten und möglicherweise der Manifestierung über ein Broadcast-Netzwerk und das Kombinieren desselben mit DASH-Sitzungen auf HTTP-Basis über ein Unicast-Netzwerk in nahtloser Form.
Gemäß verschiedenen Ausführungsformen kann dieselbe URL oder Gruppe von URLs verwendet werden, um die Segmente auf beiden Verteilungskanälen zu lokalisieren. Die Broadcast-Sendung von einem oder mehreren Segmenten kann jedoch verzögert werden, um nahtlose Übergänge zu erleichtern.
Im Broadcast-Modus kann der Client als ein passiver Empfänger von Segmenten fungieren, die über eine Broadcast-Verbindung übermittelt werden, die mit einem Dateiverteilungsprotokoll wie FLUTE eingerichtet ist. Wenn die Kombination aus Empfangsqualität und Weiterleitungsfehlerkorrektur (FEC) ausreichend ist, werden an einen Empfangspufferspeicher am Client großenteils oder vollständig fehlerfreie Segmente übermittelt. Anschließend kann der Medien-Player Segmente aus dem Pufferspeicher auslesen, diese decodieren und abspielen.
1 veranschaulicht ein Beispiel eines Systems, welches mit verschiedenen Techniken und Mechanismen der vorliegenden Erfindung verwendet werden kann. Gemäß verschiedenen Ausführungsformen kann das in 1 dargestellte System verwendet werden, um die Verteilung von Medien-Stream-Segmenten über Broadcast und Unicast zu erleichtern. Medien-Stream-Segmente können in der Live-Quelle 102 erzeugt und/oder von dieser gesendet werden und an den Unicast-Server 104 sowie einen Broadcast-Verteilungs-Server 106 verteilt werden. Eine Benutzereinheit kann Inhalt von dem Broadcast-Server, wie in der Konfiguration 108a dargestellt, sowie von dem Unicast-Server empfangen, wie in der Konfiguration 108b dargestellt. In verschiedenen Zeitperioden oder an verschiedenen Stellen kann möglicherweise auf einen Server besser zugegriffen werden als auf einen anderen Server oder ein Server kann wünschenswerter sein als ein anderer Server, was von Faktoren wie der Zugreifbarkeit auf die verschiedenen Server, den Kosten des Empfangs von Daten von den verschiedenen Servern und/oder der Latenzzeit abhängt, die mit dem Kommunizieren mit den verschiedenen Servern verbunden ist. Die Benutzereinheit umfasst einen Pufferspeicher 110, einen Unicast-Agenten 112, einen Broadcast-Empfänger 114, ein Display 116 und einen Decoder 118.
Unter 102 ist eine Live-Inhalts-Quelle 102 dargestellt. Gemäß verschiedenen Ausführungsformen kann die Live-Inhalts-Quelle 102 so zu betreiben sein, dass sie Daten bereitstellt, welche ein Medienelement zur Darstellung an einer Client-Maschine repräsentieren, welche hierin auch als eine Benutzereinheit bezeichnet wird. Die Daten, welche das Medienelement repräsentieren. Können der Client-Maschine als ein Medien-Stream bereitgestellt werden. Die Client-Maschine kann so zu betreiben sein, dass die Client-Maschine in Echtzeit zum Konsumieren durch einen Benutzer dargestellt wird. Die Live-Inhalts-Quelle 102 kann ein Inhaltsanbieter, ein Inhaltsverteiler oder eine beliebige andere Inhaltsquelle sein.
Gemäß verschiedenen Ausführungsformen kann der Medien-Stream in mehrere Medien-Stream-Fragmente getrennt werden, wie hierin beschrieben. Die Medien-Stream-Fragmente können in sequentieller Reihenfolge oder in beliebiger anderer Reihenfolge erzeugt werden.
Gemäß verschiedenen Ausführungsformen kann ein Medien-Stream verschiedene Informationstypen umfassen. Zum Beispiel kann ein Medien-Stream ein oder mehrere Audio-Tracks, Video-Tracks, Einblendungsinformationen, Video-Untertitel, Bilder, Bilderalben umfassen. Als ein anderes Beispiel kann ein Medien-Stream eine oder mehrere URLs oder andere Mechanismen für Lokalisierer oder zum Zugreifen auf Inhalt umfassen.
Unter 104 ist ein Unicast-Server dargestellt. Gemäß verschiedenen Ausführungsformen kann der Unicast-Server über einen oder mehrere Unicast-Transporttypen mit Client-Einheiten kommunizieren. Zum Beispiel kann der Unicast-Server über HTTP mit Client-Einheiten kommunizieren. Gemäß verschiedenen Ausführungsformen können hierin beschriebene Techniken in Verbindung mit verschiedenen Typen der Unicast-Sendetechnologie wie z. B. HSPA, CDMA 2000, LTE, LTE Advanced und Varianten von IEEE 802.11 angewendet werden.
Gemäß verschiedenen Ausführungsformen kann der Unicast-Server die Medien-Stream-Segmente von der Inhaltsquelle 102 empfangen. Die Medien-Stream-Segmente können an dem Unicast-Server gespeichert werden.
Anschließend können die Medien-Stream-Segmente auf Anforderung an die Client-Einheit gesendet werden.
Unter 106 ist ein Broadcast-Server dargestellt. Gemäß verschiedenen Ausführungsformen können hierin beschriebene Techniken in Verbindung mit verschiedenen Typen der Broadcast-Technologie angewendet werden, wobei Streams oder Dateien zum Senden verwendet werden, z. B. DVB-H, ATSC-M/H, MediaFlo. Der Broadcast-Server kann zum Beispiel ein Broadcast-Multicast-Service-Center (BMSC) in einem 3GPP-Netzwerk sein. Als ein anderes Beispiel kann der Broadcast-Server dafür konfiguriert sein, Informationen über Meldungen gemäß der Multimedia-Broadcast-Multicast-Services(MBMS)-Spezifikation zu senden.
Unter 108a ist eine Benutzereinheit in einer Konfiguration dargestellt, in welcher die Einheit Inhalt über den Broadcast-Knoten 106 empfängt. Unter 108b ist die Benutzereinheit in einer Konfiguration dargestellt, in welcher die Einheit Inhalt über den Unicast-Knoten 104 empfängt. In beiden Fällen kann der Benutzer die empfangenen Fragmente in dem Medien-Stream-Fragment-Pufferspeicher 110 speichern. Diese Fragmente können dann durch den Decoder 118 decodiert und über das Display 116 angezeigt werden.
Gemäß verschiedenen Ausführungsformen kann der Medien-Stream-Fragment-Pufferspeicher 110 Medien-Fragmente speichern, welche von dem Unicast-Server 104 und/oder dem Broadcast-Server 106 empfangen werden. Die in dem Pufferspeicher 110 gespeicherten Fragmente können jene Fragmente umfassen, die noch nicht zum Decodieren und Darstellen über das Display 116 gesendet worden sind. Alternativ können die Fragmente weiter in dem Pufferspeicher 110 gespeichert werden, nachdem sie für die Darstellung decodiert worden sind.
Unter 112 ist ein Unicast-Kommunikationsmodul dargestellt. Gemäß verschiedenen Ausführungsformen kann das Unicast-Kommunikationsmodul eine beliebige Kombination aus Computer-Software und/oder Hardware sein, die dafür konfiguriert ist, Kommunikationen mit dem Unicast-Server 104 zu senden, zu empfangen und zu verarbeiten. Zum Beispiel kann das Unicast-Kommunikationsmodul ein HTTP-Agent sein, der für eine Kommunikation über das HTTP-Protokoll konfiguriert ist.
Unter 114 ist ein Broadcast-Kommunikationsmodul dargestellt. Gemäß verschiedenen Ausführungsformen kann das Broadcast-Kommunikationsmodul eine beliebige Kombination aus Computer-Software und/oder Hardware sein, die dafür konfiguriert ist, Sendungen von dem Broadcast-Server 106 zu empfangen und zu verarbeiten. Zum Beispiel kann das Broadcast-Kommunikationsmodul dafür konfiguriert sein, Broadcast-Sendungen zu empfangen, die über das FLUTE-Protokoll von einem BMSC-Knoten gesendet werden.
Unter 116 ist ein Display 116 dargestellt. Gemäß verschiedenen Ausführungsformen kann das Display 116 verwendet werden, um den Inhalt darzustellen, der von der Live-Inhalts-Quelle 102 empfangen wird. Das Display 116 kann eines oder mehreres aus einem Bildschirm, einem Lautsprecher und einer beliebigen anderen Einheit zum Darstellen von Inhalt für einen Benutzer umfassen.
Gemäß verschiedenen Ausführungsformen kann das Display 116 Inhalt mittels eines Decoders 118 empfangen. Wie hierin beschrieben, kann Inhalt während des Sendens an die Client-Maschine codiert werden. Entsprechend kann der Decoder 118 das Verfahren umkehren, den Inhalt für die Darstellung über das Display 116 decodieren.
Gemäß verschiedenen Ausführungsformen wird absichtlich eine Verzögerung in den Broadcast-Server 106 eingebracht. In einigen Beispielen wird das drittaktuellste Segment rundgesendet. Es können jedoch auch Verzögerungen anderer Längen angewendet werden, wie hierin beschrieben. Die spezielle verwendete Verzögerung kann strategisch auf der Grundlage von Faktoren wie der Medien-Stream-Fragmentgröße, der Datenrate, die beim Kommunizieren mit der Client-Einheit verwendet wird, und den Fähigkeiten des Netzwerks bestimmt werden.
Durch eine Vergrößerung der Verzögerung kann ein größerer Spielraum bereitgestellt werden, welcher für eine größere Sicherheit gegenüber Dienstunterbrechungen oder Transporttypumschaltungen sorgen kann. Eine Vergrößerung der Verzögerung kann jedoch auch erforderlich machen, dass der Medien-Stream-Pufferspeicher 110 zusätzliche Medien-Stream-Segmente speichert, da der Pufferspeicher mindestens die Medien-Stream-Segmente speichert, die die Verzögerung ausmachen, um ein nahtloses Umschalten von Unicast auf Broadcast zu ermöglichen.
Gemäß verschiedenen Ausführungsformen können, wenn eine Verzögerung eingebracht ist, Segmente nicht sofort rundgesendet werden, wenn sie verfügbar sind, sondern können stattdessen derart in dem Knoten gepuffert werden, dass sie relativ zu dem Unicast-Fragment-Server verzögert werden. Alternativ oder zusätzlich können die Segmente verzögert werden, wenn sie von der Inhaltsquelle 102 an den Broadcast-Server 106 gesendet werden. In einigen Fällen kann eine Pufferverzögerung an der Inhaltsquelle eingebracht werden und außerdem eine zusätzliche relative Verzögerung an dem Broadcast-Server eingebracht werden, so dass der Unicast-Fragment-Server eine geringere Verzögerung als der Broadcast-Server aufweist. Auf diese Weise kann der Segmentempfang durch eine Client-Einheit über einen Unicast-Agenten in gewissem Maße vor dem Broadcast-Empfang erfolgen.
Da der Unicast-Empfang von Medien-Stream-Segmenten in gewissem Maße vor der Broadcast-Sitzung erfolgt, ist es einfach, von Unicast- auf Broadcast-Empfang umzuschalten, ohne Medien-Stream-Segmente im Empfangspufferspeicher zu verpassen. Wenn sich zum Beispiel der Client in dem Zustand befindet, der in der Client-Einheits-Konfiguration 108b dargestellt ist, weist er bereits das aktuell rundgesendete Segment n – 1 im Pufferspeicher auf, so dass es nichts ausmacht, dass er das Paket n – 1 nicht empfangen kann, wenn es rundgesendet wird. Das nächste Segment, das rundgesendet wird, das Segment n, wird vollständig empfangen und im Pufferspeicher liegt eine ununterbrochene Sequenz von Segmenten vor.
Ein Übergang von Broadcast auf Unicast kann abrupt erfolgen, wenn zum Beispiel die Client-Einheit einen Broadcast-fähigen Bereich belässt. Wenn sich die Client-Einheit zum Beispiel in dem Zustand befindet, der in der Konfiguration 108a dargestellt ist, empfängt sie nicht das vollständige Segment n – 1 über Broadcast.
Das Segment n – 1 ist jedoch auf dem Unicast-Server verfügbar, so dass der Client es von dort abrufen kann. Somit kann ein Umschalten von Broadcast auf Unicast ohne Unterbrechung gehandhabt werden, vorausgesetzt, dass die Netzwerkbedingungen ausreichend sind. Um eine Unterbrechung zu vermeiden, wenn später auf einen Broadcast-Modus zurückgewechselt wird, kann der Client zusätzliche Segmente über Unicast abrufen, um wieder einen Vorsprung vor der Broadcast-Sendung zu erhalten.
In speziellen Ausführungsformen wird bei der Client-Entwicklung das Design des anwendungsspezifischen Codes von der Inhaltsdarstellungsschicht (z. B. dem Audio- und/oder Video-Player) getrennt. Übliche Inhaltsdarstellungsschichten stellen Steuerungen für Abspielen, Pause, Suchlauf und/oder andere Operationen bereit. Die Plattformen können auch die Weiterleitung von Fehlerinformationen und einiger Typen von Qualitätsrückmeldungen ermöglichen.
Gemäß verschiedenen Ausführungsformen können Systeme dafür konfiguriert sein, die Wechselwirkung des Medien-Players mit zusammengeführten Anwendungen zu unterstützen. Einige Ausführungsformen können Rückmeldungen an die Anwendung und/oder die Fähigkeit der Inhaltserwerbsanwendung ermöglichen, das Abspielen des Players zu steuern. Diese Operationen können in einigen Ausführungsformen durch die Verwendung der folgenden Rückmeldungs-APIs ausgeführt werden: der Empfangsstärken für ein Broadcast- und/oder Unicast-Netzwerk; einer Kennung, welche dem Segment entspricht, das von dem Inhaltserwerbssystem zuletzt empfangen wurde; einer Kennung, welche dem Segment entspricht, das von dem Medien-Player zuletzt abgespielt wurde; eines Werts, welcher aktivem Transport und/oder Ereignissen entspricht, wenn der Transport wechselt; eines Werts, welcher einer aktiven Vorlage und/oder Ereignissen entspricht, wenn die Vorlage wechselt; eines Werts, welcher der verfügbaren Bandbreite entspricht; Metadateninformationen (z. B. Dateien, welche bei FLUTE zusammen mit Segmenten übertragen werden, welche Programminformationen bereitstellen, die mit dem abgespielten Video synchronisiert werden können).
In speziellen Ausführungsformen kann, um die richtige Synchronisierung der Verteilungen des BC- und UC-Transporttyps zu ermöglichen, der Client-Takt mit dem Segment-Generator-Takt synchronisiert werden. Dann kann das Herunterladen von Segmenten durch die aktuellste Manifestierungsdatei gesteuert werden, welche genug Informationen bereitstellt, um programmatisch Segment-URLs zu erzeugen, und einen oder mehrere Werte, die in der Manifestierungsdatei spezifiziert sind, z. B. die Verfügbarkeits-Startzeit. In diesem Fall kann das aktuellste Live-Segment durch Addieren der Dauer der einzelnen Segmente berechnet werden. Jedoch können auch, wenn die Takte nicht gut synchronisiert sind, die Unicast-Medien-Segment-Abrufe einen Vorsprung gegenüber der Broadcast-Sendung erhalten, indem versucht wird, Segmente so früh wie möglich abzurufen, bis keine aktuelleren Segmente verfügbar sind.
In speziellen Ausführungsformen, zum Beispiel bei MBMS, gibt das Netzwerk durch eine MBMS-Benutzerdienstbeschreibung (User Service Description, USD) bekannt, dass Dateien durch MBMS-Herunterladen verfügbar sind. Die USD kann eine Manifestierung umfassen, welche eine Mediendarstellungsbeschreibung (Media Presentation Description, MPD) sein kann, zum Beispiel über den Verweis mediaPresentationDescription. Die Manifestierung kann anzeigen, dass eine MPD über den MBMS-Download-Dienst übermittelt werden kann. Dieselbe MPD kann auch über HTTP verfügbar gemacht werden. Andere Netzwerktypen können ähnliche Konfigurationen ermöglichen.
Eine beispielhafte URL, welche einem Medien-Stream-Segment entsprechen kann, ist: http://cdn1.example.com/SomeMovie_1400kbps_00001.ts. Diese URL kann einem ersten Medien-Stream-Segment des Inhalts „SomeMovie” mit einer Datenrate von 14.000 kbps entsprechen.
Wenn zum Beispiel die Verfügbarkeits-Startzeit 2011-05-10T06:16:42 ist und die Uhrzeit 07:20:01 ist, dann ist die Zeit 01:03:19 (entsprechend 3799 s) vergangen, seit das erste Segment verfügbar war, und bei einer Segmentdauer von 4 s sollte das Segment 700 das letzte verfügbare sein. Dieses ist das eine, welches der http-Client abrufen sollte, während die MBMS-Übermittlung verzögert ist, so dass ein älteres Segment übermittelt wird, z. B. das Segment 698.
Ein Beispiel für eine vorlagenbasierte MPD für Live-Inhalt unter Verwendung des MPEG-2-Transport-Stream(TS)-Protokolls ist in Abschnitt G.3 in Teil 1 der MPEG-Spezifikation für DASH (IOS/IEC IS 23009-1) verfügbar. Ein Beispiel für eine Beschreibung eines solchen Inhalts ist das folgende.
2 veranschaulicht ein Verfahren 200 zum Unterstützen des Medien-Streaming-Sitzungs-Transporttyp-Umschaltens. Gemäß verschiedenen Ausführungsformen kann das Verfahren 200 in einem ähnlichen System wie jenem durchgeführt werden, das in Bezug auf 1 und 4 beschrieben ist. Das heißt, eine Client-Maschine kann einen Medien-Stream von einem Inhaltsanbieter empfangen. Der Medien-Stream kann über mindestens zwei verschiedene Transporttypen bereitgestellt werden. Inhalt, der über diese zwei Transporttypen gesendet wird, kann über denselben physischen Server bereitgestellt werden oder kann über verschiedene physische Server bereitgestellt werden. In 2 sind die beiden Transporttypen als Unicast und Broadcast beschrieben. Jedoch kann gemäß verschiedenen Ausführungsformen, wie hierin beschrieben, eine Vielfalt von Transporttypen angewendet werden.
Bei 202 wird eine Anforderung zum Streaming eines Medieninhaltselements empfangen. Gemäß verschiedenen Ausführungsformen kann die Anforderung an einem Server empfangen werden, z. B. einem Server, der von einem Inhaltsanbieter gesteuert wird. Bei dem Medieninhalt kann es sich um einen Audioinhalt, einen Videoinhalt, Untertitel oder einen anderen Inhalt handeln, der an einer Benutzereinheit dargestellt werden kann. Bei dem Medieninhalt kann es sich um ein oder mehrere durchgängige Inhaltsstücke handeln, z. B. um einen Film, ein Lied oder ein Album mit Liedern. Alternativ kann es sich bei dem Medieninhalt um ein oder mehrere diskrete Inhaltsstücke handeln, z. B. um ein Bild oder ein Album mit Bildern. In jedem Fall kann auf den Medieninhalt einzeln oder als Teil eines andauernden Inhalts-Streams zugegriffen werden, z. B. bei einer Fernseh- oder Radiostation.
Bei 204 wird das Medieninhaltselement in mehrere Medien-Stream-Fragmente geteilt. Durch Teilen des Inhalts in Fragmente kann der Inhalt stückweise an den Benutzer gesendet werden, statt als eine einzige große Datei. Dieses Verfahren kann das Senden von Live-Inhalt an die Client-Maschine ermöglichen, da der Inhalt gesendet und dargestellt werden kann, wenn er erzeugt wird. Alternativ oder zusätzlich kann das Verfahren der Client-Maschine ermöglichen, eine Anpassung durchzuführen, wann immer ein neues Fragment heruntergeladen wird.
Gemäß verschiedenen Ausführungsformen kann die Benutzereinheit mit dem darstellen des Inhalts beginnen, sobald das erste Fragment empfangen wird, anstatt darauf zu warten, dass alle Daten empfangen werden, die zu dem Inhalt gehören. Auch muss die Benutzereinheit nur eine begrenzte Datenmenge speichern, statt aller Daten, die zu dem Inhalt gehören. In einigen Fällen kann durch das Teilen des Inhalts in Fragmente der Empfang eines Medien-Streams an mehr begrenzten Einheiten (z. B. mobilen Einheiten) ermöglicht werden, als es praktisch wäre, wenn der Inhalt als ein vereinigtes Ganzes gesendet würde. In speziellen Ausführungsformen kann das Streaming-Verfahren eine einfachere Verwaltung digitaler Rechte und einen einfacheren Inhaltsschutz ermöglichen als beim Senden einer gesamten Datei.
Gemäß verschiedenen Ausführungsformen können die Medien durch eine Computereinheit wie z. B. ein Fragmentiersystem in Fragmente geteilt werden. Ein Beispiel für ein Fragmentiersystem wird unter Bezugnahme auf 2 beschrieben. Das Fragmentiersystem kann durch den Inhaltsanbieter, den Operator der Broadcast- und/oder Unicast-Server oder eine irgendeine andere Partei gesteuert werden.
Bei 206 wird eine Beschreibung der mehreren Fragmente an die Benutzereinheit gesendet. Gemäß verschiedenen Ausführungsformen können durch die Beschreibung der mehreren Fragmente eine oder mehrere URLs oder andere Kennungen zum Abrufen der Medien-Stream-Fragmente identifiziert werden. Die Kennungen können in einer Liste gesendet werden oder können als eine Vorlage gesendet werden. Die Beschreibung der mehreren Fragmente kann durch den Inhaltsanbieter, durch den Unicast-Server, durch den Broadcast-Server oder durch eine andere Einheit in dem Netzwerk gesendet werden.
Gemäß verschiedenen Ausführungsformen kann die Beschreibung der mehreren Fragmente verschiedene Kennungen oder Kennungsvorlagewerte umfassen, um der Client-Einheit zu ermöglichen, Fragmente mit verschiedenen Datenraten, Auflösungen, Fragmentgrößen oder anderen Parameterwerten abzurufen. Zum Beispiel kann die Beschreibung Informationen zum Abrufen von Medien-Stream-Fragmenten mit 720 Kilobyte je Sekunde (kbps), 1.130 kbps, 1.400 kbps, 2.100 kbps, 2.700 kbps oder 3.400 kbps umfassen.
Bei 208 wird eine Transporttyp-Streaming-Verzögerung zum Streaming der Fragmente bestimmt. Gemäß verschiedenen Ausführungsformen kann die Transporttyp-Streaming-Verzögerung einem Transporttyp relativ zu einem anderen Transporttyp auferlegt werden. Zum Beispiel können Medien-Stream-Fragmente, die über Broadcast gesendet werden, relativ zu Medien-Stream-Fragmenten verzögert sein, die über Unicast gesendet werden. Auf diese Weise eine Benutzereinheit, die in der Mitte der Sitzung von Unicast auf Broadcast umschaltet, sicher sein, über den Broadcast-Server das nächste Medien-Stream-Fragment zu empfangen, das von der Benutzereinheit noch nicht empfangen worden ist. Das heißt, wenn die Benutzereinheit plötzlich den Zugriff auf den Unicast-Server verliert, zum Beispiel auf halber Strecke beim Empfangen eines Medien-Stream-Fragments, kann die Benutzereinheit auf den Broadcast-Server umschalten und den Medien-Stream eine kurze Zeit später wieder aufnehmen.
Gemäß verschiedenen Ausführungsformen kann die Transporttyp-Streaming-Verzögerung als eine bestimmte Anzahl von Fragmenten, eine bestimmte Zeitperiode, eine bestimmte Datengröße oder irgendeine andere Größe zum Spezifizieren einer Sendedifferenz zwischen den beiden Transporttypen spezifiziert werden. In speziellen Ausführungsformen kann die Transporttyp-Streaming-Verzögerung eine bestimmte Anzahl an Fragmenten zwischen eins und zehn sein. Zum Beispiel kann eine Transporttyp-Streaming-Verzögerung zwei Fragmente betragen.
Bei 210 werden die mehreren Fragmente an einen Unicast-Server zum Streaming zu der Benutzereinheit gesendet. Ein Unicast-Server wurde in Bezug auf den Block 116 beschrieben, der in 1 dargestellt ist. Wie in Bezug auf 1 beschrieben, kann der Unicast-Server Medien-Stream-Fragmente auf Anforderung an eine Benutzereinheit senden.
Bei 212 werden die mehreren Fragmente an einen Broadcast-Server zum Streaming zu der Benutzereinheit gesendet. Wenn sie von dem Broadcast-Server gesendet werden, werden die Medien-Stream-Fragmente gemäß der Transporttyp-Streaming-Verzögerung relativ zu jenen verzögert, die von dem Unicast-Server gesendet werden.
Gemäß verschiedenen Ausführungsformen kann die Transporttyp-Streaming-Verzögerung an verschiedenen Stellen in dem System eingebracht werden. Zum Beispiel kann der Inhaltsanbieter die Medien-Stream-Fragmente nach einer Verzögerung relativ zu dem Senden der Medien-Stream-Fragmente an den Unicast-Server an den Broadcast-Server senden. Als ein anderes Beispiel kann der Inhaltsanbieter die Medien-Stream-Fragmente mit ungefähr derselben Rate und zu ungefähr derselben Zeit an die zwei Server senden, während der Broadcast-Server die Fragmente puffert und die Verzögerung einbringt.
Gemäß verschiedenen Ausführungsformen kann die Transporttyp-Streaming-Verzögerung auf verschiedene Weisen eingebracht werden. Zum Beispiel kann der Broadcast-Server eine Anzeige von dem Unicast-Server empfangen, dass der Unicast-Server eine Anforderung für ein bestimmtes Medien-Stream-Fragment empfangen hat. Dann kann der Broadcast-Server das Senden des bestimmten Medien-Stream-Fragments gemäß der Transporttyp-Streaming-Verzögerung verzögern. Als ein anderes Beispiel kann der Broadcast-Server das Senden nicht beginnen, bis er eine Anzeige empfängt, dass die Benutzereinheit angefordert hat, Inhalt über den Broadcast-Server zu empfangen. Dann kann der Broadcast-Server ein bestimmtes Medienfragment senden, das von dem Unicast-Server identifiziert wird, verzögert durch die Streaming-Verzögerung.
Gemäß verschiedenen Ausführungsformen können die Medien-Stream-Fragmente inkrementierend an den Unicast- und/oder Broadcast-Server gesendet werden. Das heißt, die Medien-Stream-Fragmente können nacheinander so gesendet werden, dass einer oder beide der Server mit dem Streaming zu der Client-Einheit beginnen, bevor alle der Medien-Stream-Fragmente empfangen sind. Das Senden aller Medienfragmente auf einmal kann in einigen Systemkonfigurationen wünschenswert sein, z. B. wenn sich einige oder alle der Server nicht in enger physischer Nähe befinden oder durch ein Netzwerk wie das Internet getrennt sind.
Gemäß verschiedenen Ausführungsformen können alle der Medien-Stream-Fragmente an einen oder beide der Server gesendet werden, bevor die Server mit dem Senden an die Client-Einheit beginnen. Zum Beispiel können die Medien-Stream-Fragmente für vorher aufgezeichneten Inhalt auf diese Weise gesendet werden. Das Senden aller Medienfragmente auf einmal kann in einigen Systemkonfigurationen wünschenswert sein, z. B. wenn sich einige oder alle der Server in enger physischer Nähe oder in derselben physischen Maschine befinden.
Gemäß verschiedenen Ausführungsformen können als Teil des Unterstützens des Transporttypumschaltens innerhalb einer Medien-Streaming-Sitzung Operationen durchgeführt werden, die in 2 nicht dargestellt sind. Alternativ oder außerdem müssen nicht in jedem Fall alle der Operationen, die in 2 dargestellt sind. Zum Beispiel kann das Medieninhaltselement bereits in mehrere Fragmente geteilt sein, lange bevor eine Anforderung zum Streaming des Inhalts empfangen wird.
3 veranschaulicht ein Verfahren 300 zum Unterstützen des Umschaltens des Transporttyps einer Meiden-Streaming-Sitzung. Gemäß verschiedenen Ausführungsformen kann das Verfahren 300 an einer Client-Einheit durchgeführt werden, z. B. an einer Client-Einheit in den Konfigurationen 108a und 108b, die in 1 dargestellt sind. Die Client-Einheit kann mit einem Broadcast- und/oder Unicast-Server wie die Server 104 und 106, die in 1 dargestellt sind, in Kommunikation stehen. Das Verfahren 300 kann hauptsächlich oder vollständig in einer Verarbeitungsschicht durchgeführt werden, welche auf der Client-Einheit residiert, z. B. in einer Verarbeitungsschicht, welche das Unicast-Kommunikationsmodul 112, ein Broadcast-Kommunikationsmodul 114, einen Mediensegment-Pufferspeicher 110 und/oder beliebige andere Hardware und/oder Software zum Durchführen des Verfahrens umfasst.
Bei 302 wird eine Anforderung eines Medieninhaltselements an einen Server gesendet. Wie hierin beschrieben, kann es sich bei dem Medieninhaltselement um ein oder mehrere diskrete Inhaltsstücke oder einen durchgängigen Inhalts-Stream wie z. B. bei einer Fernseh- oder Radiostation handeln. Gemäß verschiedenen Ausführungsformen kann die Anforderung eines Medieninhalts von der Client-Einheit gesendet werden. Alternativ oder außerdem kann die Anforderung eines Medieninhalts von einer anderen Maschine in Kommunikation mit der Client-Einheit gesendet werden, z. B. von einer Maschine, die dafür konfiguriert ist, einen Inhalt zum Anzeigen auf der Client-Einheit auszuwählen.
Gemäß verschiedenen Ausführungsformen kann die Anforderung eines Medieninhalts an eine Inhaltsquelle gesendet werden, z. B. die Inhaltsquelle 102, die in 1 dargestellt ist. Alternativ oder außerdem kann die Anforderung eines Medieninhalts an einen Unicast-Server, einen Broadcast-Server oder ein beliebiges anderes vernetztes Ziel gesendet werden, welches dafür konfiguriert ist, das Bereitstellen von Inhalt für die Client-Einheit auszulösen.
Bei 304 werden Download-Informationen für Segmente des Medieninhaltselements empfangen. Wie in Bezug auf 1 beschrieben, können die Download-Informationen eine beliebige Beschreibung von Kennungen oder Lokalisierern für die Mediensegmente umfassen. Zum Beispiel können die Download-Informationen eine MBMS-Benutzerdienstbeschreibung (USD) umfassen, welche eine Mediendarstellungsbeschreibung (MPD) umfassen kann. Die Download-Informationen können einzelne URLs oder URL-Vorlagen umfassen, welche den Medien-Stream-Segmenten entsprechen. Die Download-Informationen können von dem Inhaltsanbieter, dem Unicast-Server, dem Broadcast-Server oder einer beliebigen anderen Maschine empfangen werden, die über ein Netzwerk mit der Client-Einheit in Kommunikation steht.
Bei 306 wird ein Transportprotokoll zum Empfangen der Medien-Stream-Segmente identifiziert. Gemäß verschiedenen Ausführungsformen kann das Transportprotokoll ein beliebiges Protokoll sein, welches von dem Netzwerk unterstützt wird, über das der Benutzer kommuniziert. Zum Beispiel kann sich die Benutzereinheit in einem Bereich befinden, welcher eine Unicast-Kommunikation über HTTP unterstützt, aber keine Broadcast-Kommunikation unterstützt. Als ein anderes Beispiel kann sich die Benutzereinheit in einem Bereich befinden, welcher eine Broadcast-Kommunikation unterstützt, aber keine Unicast-Kommunikation unterstützt.
Gemäß verschiedenen Ausführungsformen kann, wenn mehr als ein Transportprotokoll verfügbar ist, das identifizierte Protokoll dann auf verschiedene Weisen ausgewählt werden. Zum Beispiel kann ein Server auf der Grundlage der niedrigen Latenzzeit, der Stabilität, der Datenrate oder anderer Faktoren ausgewählt werden. Als ein anderes Beispiel kann ein Protokoll (z. B. Broadcast) gegenüber einem anderen Protokoll (z. B. Unicast) bevorzugt werden, wenn beide verfügbar sind.
Bei 308 wird über das identifizierte Transportprotokoll der nächste Medien-Stream empfangen. Gemäß verschiedenen Ausführungsformen kann das Medien-Stream-Segment von einem Kommunikationsmodul, z. B. einem Broadcast- oder Unicast-Kommunikationsmodul, empfangen werden, das sich in der Client-Einheit befindet und dafür konfiguriert ist, über das identifizierte Transportprotokoll zu kommunizieren.
Gemäß verschiedenen Ausführungsformen können die Medien-Stream-Segmente in sequentieller oder nahezu sequentieller Reihenfolge empfangen werden. Das heißt, die Medien-Stream-Segmente können beim Broadcast-Modus von dem Broadcast-Server sequentiell rundgesendet werden. In ähnlicher Weise können beim Unicast-Modus die Medien-Stream-Segmente von dem Unicast-Server sequentiell angefordert und empfangen werden. Die Medien-Stream-Segmente können jedoch in einigen Fällen in einer Reihenfolge empfangen werden, die nicht vollständig sequentiell ist, zum Beispiel wenn das Netzwerk überlastet ist.
Bei 310 wird das Medien-Stream-Segment in einem Pufferspeicher gespeichert. Durch das Speichern des Medien-Stream-Segment in einem Pufferspeicher vor dem Abspielen desselben kann dazu beigetragen werden, dass ein nahtloses Abspielen des Medien-Streams sichergestellt wird. Wenn zum Beispiel das Transportprotokoll umgeschaltet wird oder der Netzwerkdienst vorübergehend unterbrochen ist, kann das nächste Medien-Stream-Segment nicht zur vorgesehenen Zeit empfangen werden. Wenn die Medien-Stream-Segmente gepuffert werden, dann kann das nächste nicht abgespielte Medien-Stream-Segment zum Abspielen aus dem Pufferspeicher abgerufen werden, auch wenn ein Problem dabei entsteht, das nächste ungepufferte Medien-Stream-Segment über das Netzwerk abzurufen.
Bei 312 wird ein gepuffertes Medien-Stream-Segment zur Darstellung gesendet. In speziellen Ausführungsformen, wie in Bezug auf 1 beschrieben, kann ein Fragment in dem Medien-Stream-Pufferspeicher zuerst von einem Decoder decodiert werden und dann auf dem Display angezeigt werden. Gemäß verschiedenen Ausführungsformen kann ein Medien-Player an der Client-Einheit einen Pufferspeicher, einen Decoder und eine Anzeigeeinheit umfassen.
Obwohl 3 ein Medien-Stream-Segment zeigt, welches gesendet wird, nachdem ein anderes Medien-Stream-Segment empfangen und im Pufferspeicher gespeichert wird, ist diese Reihenfolge nur zu Erläuterungszwecken verwendet worden und eine tatsächliche Client-Einheit kann diese Schritte in einer anderen Reihenfolge ausführen. Das heißt, das nächste nicht abgespielte Medien-Stream-Segment wird unmittelbar abgespielt, nachdem das aktuell abgespielte Medien-Stream-Segment beendet ist, wenn das Abspielen ununterbrochen fortgesetzt werden soll. Ferner kann, obwohl Medien-Stream-Segmente in einer Geschwindigkeit empfangen werden, die mindestens gleich der Abspielgeschwindigkeit ist, wenn das Abspielen ununterbrochen fortgesetzt werden soll, in einigen Fällen der Empfang von Medien-Stream-Segmenten in gewisser Weise sprunghaft sein, zum Beispiel wenn das Netzwerk überlastet ist. Somit kann die Client-Einheit in einigen Fällen verschiedene Medien-Stream-Segmente empfangen und Puffern, während ein einzelnes Segment abgespielt wird. In anderen Fällen kann die Client-Einheit verschiedene Segmente abspielen, ohne ein neues Medien-Stream-Segment zu empfangen und zu puffern, zum Beispiel wenn die Transportprotokolle umgeschaltet werden.
Gemäß verschiedenen Ausführungsformen sind die Geschwindigkeiten des Empfangens und Abspielens von Medien-Stream-Segmenten im Mittelwert ähnlich, wenn die Netzwerkbedingungen für ein ununterbrochenes Streaming-Abspielen ausreichend sind. Die Geschwindigkeiten können zum Beispiel ähnlich sein, wenn an der Client-Einheit eine Live-Medien-Einspeisung dargestellt wird. In bestimmten Ausführungsformen können die Geschwindigkeiten unterschiedlich sein. Wenn zum Beispiel ein Video-on-Demand-Inhalt empfangen wird, könnte ein Benutzer oder eine Einheit wählen, den vollständigen Inhalt noch schneller als in Echtzeit herunterzuladen.
Bei 314 wird eine Bestimmung vorgenommen, ob weitere Medien-Stream-Segmente zu empfangen sind. Gemäß verschiedenen Ausführungsformen können weiter Mediensegmente empfangen werden, während die Netzwerkbedingungen ausreichend sind und während weitere Mediensegmente verfügbar sind. Zum Beispiel können die Download-Informationen, die bei der Operation 304 empfangen werden, eine endliche Anzahl an Medien-Stream-Segmenten identifizieren. Entsprechend können die Medien-Stream-Segmente empfangen werden, bis keine weiteren Segmente verbleiben. Als ein anderes Beispiel kann eine Bestimmung vorgenommen werden, dass die Netzwerkbedingungen ein Streaming des Medieninhalts nicht mehr unterstützen. Zum Beispiel kann die Drahtlos-Signalstärke niedrig sein oder es ist möglicherweise kein drahtloses Netzwerk vorhanden. Als noch ein weiteres Beispiel kann die Client-Einheit eine Benutzereingabe (z. B. das Drücken einer Pause- oder Stopptaste) empfangen, welche anzeigt, dass das Abspielen angehalten werden sollte.
Bei 316 wird eine Bestimmung vorgenommen, ob das Transportprotokoll gewechselt werden sollte. Gemäß verschiedenen Ausführungsformen können verschiedene Erwägungen diese Bestimmung beeinflussen. Zum Beispiel können die Faktoren, die in Bezug auf die Operation 306 erörtert wurden, neu bewertet werden, um wechselnde Bedingungen zu berücksichtigen. Als ein anderes Beispiel kann das Transportprotokoll, das verwendet wurde, um das aktuellste Medienfragment zu empfangen, nicht verfügbar sein. Ein Szenario, bei welchem das Transportprotokoll gewechselt werden kann, kann sein, wenn sich eine Client-Einheit in einen anderen Bereich bewegt, der von einem drahtlosen Netzwerk abgedeckt ist, in welchem das zuvor verwendete Protokoll nicht unterstützt wird.
4 veranschaulicht ein Beispiel für einen Server. Gemäß speziellen Ausführungsformen umfasst ein System 400, welches zum Verwirklichen spezieller Ausführungsformen der vorliegenden Erfindung geeignet ist, einen Prozessor 401, einen Speicher 403, eine Schnittstelle 411 und einen Bus 415 (z. B. einen PCI-Bus oder eine andere Verbindungskonfiguration) und arbeitet als ein Streaming-Server. Wenn er unter der Steuerung durch geeignete Software oder Firmware arbeitet, ist der Prozessor 401 für das Modifizieren und Senden von Live-Medien-Daten an einen Client verantwortlich. Statt eines Prozessors 401 oder zusätzlich zu einem Prozessor 401 können auch verschiedene speziell konfigurierte Einheiten verwendet werden. Die Schnittstelle 411 ist typischerweise dafür konfiguriert, Datenpakete oder Datensegmente über ein Netzwerk zu senden oder zu empfangen.
Spezielle Beispiele für unterstützte Schnittstellen umfassen Ethernet-Schnittstellen, Rahmenrelais-Schnittstellen, Kabelschnittstellen, DSL-Schnittstellen, Token-Ring-Schnittstellen und Ähnliches. Außerdem können verschiedene Schnittstellen sehr hoher Geschwindigkeit bereitgestellt werden, z. B. Fast-Ethernet-Schnittstellen, Gigabit-Ethernet-Schnittstellen, ATM-Schnittstellen, HSSI-Schnittstellen, POS-Schnittstellen, FDDI-Schnittstellen und Ähnliches. Im Allgemeinen können diese Schnittstellen Anschlüsse umfassen, die für eine Kommunikation mit den 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 umfassen. Die unabhängigen Prozessoren können kommunikationsintensive Aufgaben, wie z. B. Paketumschaltung, Mediensteuerung und -verwaltung, steuern.
Gemäß verschiedenen Ausführungsformen ist das System 400 ein Server, der auch einen Sender/Empfänger, Streaming-Pufferspeicher und eine Programmführungs-Datenbank umfasst. Der Server kann auch mit Teilnehmerverwaltungs-, Log- und Berichtserzeugungs- und Überwachungsfähigkeiten verbunden sein. In speziellen Ausführungsformen kann der Server mit einer Funktionalität zum Ermöglichen einer Operation mit mobilen Einheiten wie Mobiltelefonen verbunden sein, die in einem speziellen Netzwerk operieren und Teilnehmerverwaltungsfähigkeiten bereitstellen. Gemäß verschiedenen Ausführungsformen verifiziert ein Authentifizierungsmodul die Identität von Einheiten, z. B. mobilen Einheiten. Ein Log- und Berichtserzeugungsmodul verfolgt Anforderungen von mobilen Einheiten und zugehörige Reaktionen. Ein Überwachungssystem ermöglicht einem Administrator, Benutzungsmuster und die Systemverfügbarkeit zu betrachten. Gemäß verschiedenen Ausführungsformen behandelt der Server Anforderungen und Reaktionen für Transaktionen, die sich auf einen Medieninhalt beziehen, während ein separater Streaming-Server die tatsächlichen Medien-Streams bereitstellt.
Obwohl ein spezieller Server beschrieben wird, sollte erkannt werden, dass eine Vielfalt von alternativen Konfigurationen möglich ist. Zum Beispiel sind möglicherweise einige Module wie z. B. ein Berichts- und Logmodul und eine Überwachungseinheit nicht in jedem Server erforderlich. Alternativ können die Module in einer anderen Einheit realisiert werden, die mit dem Server verbunden ist. In einem anderen Beispiel umfasst der Server möglicherweise keine Schnittstelle zu einer abstrakten Einkaufsmaschine und kann tatsächlich die abstrakte Einkaufsmaschine selbst umfassen. Es ist eine Vielfalt von Konfigurationen möglich.
In der vorstehenden Beschreibung ist die Erfindung unter Bezugnahme auf spezielle Ausführungsformen beschrieben worden. Der Fachmann erkennt jedoch, dass verschiedene Modifikationen und Veränderungen vorgenommen werden können, ohne von dem Umfang der Erfindung abzuweichen, wie er in den folgenden Patentansprüchen ausgeführt ist. Entsprechend sind die Beschreibung und die Figuren in einem beispielhaften statt in einem beschränkenden Sinn zu betrachten und all solche Modifikationen sollen vom Umfang der Erfindung umfasst sein.

Claims

Verfahren, umfassend: Empfangen eines Medien-Streams von einem Inhaltsanbieter an einem Unicast-Server und an einem Broadcast-Server, wobei der Medien-Stream mehrere Medien-Stream-Fragmente umfasst; Einbringen einer relativen Verzögerung in den Medien-Stream an dem Broadcast-Server, wobei Medien-Stream-Fragmente, die von dem Broadcast-Server gesendet werden, relativ zu Medien-Stream-Fragmenten, die von dem Unicast-Server gesendet werden, verzögert sind; und Senden der Medien-Stream-Fragmente an eine Benutzereinheit, wobei die Benutzereinheit betreibbar ist, um zwischen dem Empfang der Medien-Stream-Fragmente von dem Unicast-Server und dem Broadcast-Server umzuschalten.
Verfahren nach Anspruch 1, wobei das Umschalten zwischen dem Empfang der Medien-Stream-Fragmente von dem Unicast-Server und dem Broadcast-Server Folgendes umfasst: Bestimmen an der Benutzereinheit, dass der Broadcast-Server nicht länger verfügbar ist; und Empfangen einer Anforderung von der Benutzereinheit, eines oder mehrere der Medien-Stream-Fragmente zu empfangen, an dem Unicast-Server.
Verfahren nach Anspruch 1, wobei der Medien-Stream auf der Benutzereinheit darstellbar ist und wobei das Umschalten zwischen dem Empfang der Medien-Stream-Fragmente von dem Unicast-Server und dem Broadcast-Server ohne Unterbrechen der Darstellung des Medien-Streams auf der Benutzereinheit durchführbar ist.
Verfahren nach Anspruch 1, wobei das Umschalten zwischen dem Empfang der Medien-Stream-Fragmente von dem Unicast-Server und dem Broadcast-Server Folgendes umfasst: Bestimmen an der Benutzereinheit, dass der Broadcast-Server verfügbar ist; und Empfangen eines oder mehrerer der Medien-Stream-Fragmente, die von dem Broadcast-Server rundgesendet werden, an der Benutzereinheit.
Verfahren nach Anspruch 1, wobei die Benutzereinheit betreibbar ist, um einen Medienfragment-Pufferspeicher zu unterhalten, der betreibbar ist, um eine bestimmte Anzahl der Medien-Stream-Fragmente zu speichern, und wobei die Benutzereinheit betreibbar ist, um Medienfragmente darzustellen, die in dem Medienfragment-Pufferspeicher gespeichert sind, während zwischen dem Empfang der Medien-Stream-Fragmente von dem Unicast-Server und dem Broadcast-Server umgeschaltet wird.
Verfahren nach Anspruch 1, wobei der Unicast-Server betreibbar ist, um die Medien-Stream-Fragmente zu speichern, die er von dem Inhaltsanbieter empfängt, und wobei der Unicast-Server ferner betreibbar ist, um die gespeicherten Medien-Stream-Fragmente auf Anforderung der Benutzereinheit bereitzustellen.
Verfahren nach Anspruch 1, wobei die Transporttyp-Streaming-Verzögerung einer bestimmten Anzahl der Medien-Stream-Fragmente entspricht.
Verfahren nach Anspruch 1, wobei die Transporttyp-Streaming-Verzögerung einer bestimmten Zeitperiode entspricht.
Verfahren nach Anspruch 1, wobei der Medien-Stream dafür verfügbar ist, mit mehreren Datenraten von der Benutzereinheit empfangen zu werden, wobei das Verfahren ferner Folgendes umfasst: Empfangen einer Meldung, welche eine Datenrate bezeichnet, mit welcher der Medien-Stream zu empfangen ist, von der Client-Maschine.
Verfahren nach Anspruch 1, wobei der Medien-Stream Audio- oder Videoinhalt umfasst, ausgewählt aus der Gruppe, bestehend aus: Video-Untertiteln, Einblendungen, mehreren alternativen Audio-Tracks und mehreren alternativen Video-Tracks.
System, umfassend: einen Unicast-Server, welcher einen Speicher, eine Netzwerk-Schnittstelle, einen oder mehrere Prozessoren umfasst, wobei der Unicast-Server für Folgendes konfiguriert ist: Empfangen eines Medien-Streams von einem Inhaltsanbieter, wobei der Medien-Stream mehrere Medien-Stream-Fragmente umfasst, und Senden der Medien-Stream-Fragmente an eine Benutzereinheit; und einen Broadcast-Server, welcher einen Speicher, eine Netzwerk-Schnittstelle und einen oder mehrere Prozessoren umfasst, wobei der Broadcast-Server für Folgendes konfiguriert ist: Empfangen eines Medien-Streams von einem Inhaltsanbieter, Einbringen einer relativen Verzögerung in den Medien-Stream, wobei Medien-Stream-Fragmente, die von dem Broadcast-Server gesendet werden, relativ zu Medien-Stream-Fragmenten, die von dem Unicast-Server gesendet werden, verzögert werden, und Senden der Medien-Stream-Fragmente an eine Benutzereinheit, wobei die Benutzereinheit betreibbar ist, um zwischen dem Empfang der Medien-Stream-Fragmente von dem Unicast-Server und dem Broadcast-Server umzuschalten.
System nach Anspruch 11, wobei das Umschalten zwischen dem Empfang der Medien-Stream-Fragmente von dem Unicast-Server und dem Broadcast-Server Folgendes umfasst: Bestimmen an der Benutzereinheit, dass der Broadcast-Server nicht länger verfügbar ist; und Empfangen einer Anforderung von der Benutzereinheit, eines oder mehrere der Medien-Stream-Fragmente zu empfangen, an dem Unicast-Server.
System nach Anspruch 11, wobei der Medien-Stream auf der Benutzereinheit darstellbar ist und wobei das Umschalten zwischen dem Empfang der Medien-Stream-Fragmente von dem Unicast-Server und dem Broadcast-Server ohne Unterbrechen der Darstellung des Medien-Streams auf der Benutzereinheit durchführbar ist.
System nach Anspruch 11, wobei das Umschalten zwischen dem Empfang der Medien-Stream-Fragmente von dem Unicast-Server und dem Broadcast-Server Folgendes umfasst: Bestimmen an der Benutzereinheit, dass der Broadcast-Server verfügbar ist; und Empfangen eines oder mehrerer der Medien-Stream-Fragmente, die von dem Broadcast-Server rundgesendet werden, an der Benutzereinheit.
System nach Anspruch 11, wobei die Benutzereinheit betreibbar ist, um einen Medienfragment-Pufferspeicher zu unterhalten, der betreibbar ist, um eine bestimmte Anzahl der Medien-Stream-Fragmente zu speichern, und wobei die Benutzereinheit betreibbar ist, um Medienfragmente darzustellen, die in dem Medienfragment-Pufferspeicher gespeichert sind, während zwischen dem Empfang der Medien-Stream-Fragmente von dem Unicast-Server und dem Broadcast-Server umgeschaltet wird.
System nach Anspruch 11, wobei der Unicast-Server betreibbar ist, um die Medien-Stream-Fragmente zu speichern, die er von dem Inhaltsanbieter empfängt, und wobei der Unicast-Server ferner betreibbar ist, um die gespeicherten Medien-Stream-Fragmente auf Anforderung der Benutzereinheit bereitzustellen.
System nach Anspruch 11, wobei die Transporttyp-Streaming-Verzögerung einer bestimmten Anzahl der Medien-Stream-Fragmente entspricht.
Ein oder mehrere computerlesbare Medien, welche darauf gespeicherte Befehle zum Durchführen eines Verfahrens aufweisen, wobei das Verfahren Folgendes umfasst: Empfangen eines Medien-Streams von einem Inhaltsanbieter an einem Unicast-Server und an einem Broadcast-Server, wobei der Medien-Stream mehrere Medien-Stream-Fragmente umfasst; Einbringen einer relativen Verzögerung in den Medien-Stream an dem Broadcast-Server, wobei Medien-Stream-Fragmente, die von dem Broadcast-Server gesendet werden, relativ zu Medien-Stream-Fragmenten, die von dem Unicast-Server gesendet werden, verzögert sind; und Senden der Medien-Stream-Fragmente an eine Benutzereinheit, wobei die Benutzereinheit betreibbar ist, um zwischen dem Empfang der Medien-Stream-Fragmente von dem Unicast-Server und dem Broadcast-Server umzuschalten.
Ein oder mehrere computerlesbare Speichermedien nach Anspruch 18, wobei das Umschalten zwischen dem Empfang der Medien-Stream-Fragmente von dem Unicast-Server und dem Broadcast-Server Folgendes umfasst: Bestimmen an der Benutzereinheit, dass der Broadcast-Server nicht länger verfügbar ist; und Empfangen einer Anforderung von der Benutzereinheit, eines oder mehrere der Medien-Stream-Fragmente zu empfangen, an dem Unicast-Server.
Ein oder mehrere computerlesbare Speichermedien nach Anspruch 18, wobei der Medien-Stream auf der Benutzereinheit darstellbar ist und wobei das Umschalten zwischen dem Empfang der Medien-Stream-Fragmente von dem Unicast-Server und dem Broadcast-Server ohne Unterbrechen der Darstellung des Medien-Streams auf der Benutzereinheit durchführbar ist.