DE10104961A1 - Verfahren zur bandbreiteneffizienten Übertragung von Datenströmen in einem IP-Netz - Google Patents

Verfahren zur bandbreiteneffizienten Übertragung von Datenströmen in einem IP-Netz

Info

Publication number
DE10104961A1
DE10104961A1 DE2001104961 DE10104961A DE10104961A1 DE 10104961 A1 DE10104961 A1 DE 10104961A1 DE 2001104961 DE2001104961 DE 2001104961 DE 10104961 A DE10104961 A DE 10104961A DE 10104961 A1 DE10104961 A1 DE 10104961A1
Authority
DE
Germany
Prior art keywords
content
multicast
group
server
client
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
DE2001104961
Other languages
English (en)
Inventor
Joerg Schwenk
Stephan Heuser
Wolfgang Ruppel
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.)
Deutsche Telekom AG
Original Assignee
Deutsche Telekom AG
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 Deutsche Telekom AG filed Critical Deutsche Telekom AG
Priority to DE2001104961 priority Critical patent/DE10104961A1/de
Publication of DE10104961A1 publication Critical patent/DE10104961A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1859—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast adapted to provide push services, e.g. data channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1881—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with schedule organisation, e.g. priority, sequence management
    • 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/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/2625—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for delaying content or additional data distribution, e.g. because of an extended sport event
    • 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/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47202—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand
    • 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/64—Addressing
    • H04N21/6405—Multicasting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17336—Handling of requests in head-ends

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Human Computer Interaction (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur bandbreiteneffizienten Übertragung von Datenströmen, bei dem als Content-on-Demand auf einem Server in einem IP-Netz bereitgestellte Datenströme (beispielsweise Video-on-Demand) über IP-Multicast-Verbindungen an eine Mehrzahl von Clients zeitdiskret übertragen werden. DOLLAR A Dies wird dadurch erreicht, das zueinander jeweils zeitdifferente Phasen des Contents vom Server mehreren IP-Multicast-Adressen zugeführt und die Datenströme über diese Adressen jeweils von einer Gruppe (IP-Multicast-Gruppe) der den Content anfordernden Clients bezogen werden. Dabei werden die IP-Multicast-Gruppen mittels einer auf dem Server ablaufenden Routine jeweils unter Zuweisung einer IP-Multicast-Adresse gebildet. Die Bildung der Gruppen erfolgt, indem die jeweilige IP-Multicast-Adresse jedem zur Gruppe gehörenden Client über eine von ihm zur Anforderung des Contents aufgebaute IP-Unicast-Verbindung mitgeteilt und die hierfür genutzte Verbindung, beispielsweise durch einen überbrückenden Dialog, für eine, bezogen auf den jeweiligen Client, variable Zeitspanne weiterhin aufrechterhalten wird, so dass die Übertrgung des Content quasi synchronisiert zeitgleich für die gesamte IP-Multicast-Gruppe beginnt.

Description

Die Erfindung betrifft ein Verfahren zur bandbreiteneffizienten Übertragung von Daten­ strömen, bei dem als Content-on-Demand auf einem Server in einem IP-Netz bereitgestellte Datenströme über IP-Multicast-Verbindungen an eine Mehrzahl gleichen Content zu unterschiedlichen und gegebenenfalls teilweise überlappenden Abrufzeiten anfordernde Clients zeitdiskret übertragen werden.
Neue breitbandige Anschlusstechniken (z. B. ADSL, Kabelmodem, Satellitenüber­ tragung, UMTS) machen es möglich, im zunehmenden Maße auch multimediale Inhalte über das Internet (IP-Netz) zu übertragen. Dieser sich heute bereits deutlich abzeichnende Trend wird durch die Entwicklung neuer leistungsfähiger Codecs (z. B. MPEG-4 als Videocodec) zusätzlich unterstützt. Leistungsfähige Videocodecs lassen es beispielsweise zu, Videoströme mit Datenraten im Bereich zwischen 500 Kbps bis 1 Mbps in VHS-Qualität an breitbandige IP-Anschlüsse zu übertragen. Multimedialer Content, beispielsweise in Form von Video-on-Demand oder Audio-on-Demand, kann auf diese Weise einer Vielzahl von Kunden zur Verfügung gestellt werden. Jedoch sind hierbei Randbedingungen und physikalische Grenzen der den Content bereitstellenden Quellen und der Übertragung im IP-Netz zu beachten. So vertilgen Videoserver jeweils über eine begrenzte Bandbreite und können daher nur eine begrenzte Anzahl von Datenströmen gleichzeitig ausspielen. Man behilft sich hier bislang teilweise mit einer Kaskadierung von Videoservern. Bei dieser Lösung wird der Ausgangsstrom eines Servers als Eingang eines anderen Servers verwendet und dort kurzzeitig zwischengespeichert. Die dabei benötigte Anzahl von großen Servern bringt jedoch beträchtliche Investitionskosten mit sich, welche jeweils von der maximalen Anzahl der gleichzeitig zu bedienenden Nutzer abhängen.
Beim Einsatz herkömmlicher IP-Unicast-, also Punkt-zu-Punkt-Verbindungen, muss zudem für jeden Nutzer im IP-Netz eine hohe Bandbreite reserviert werden. Dies bedeutet, dass beispielsweise über eine 100-Mbps-Leitung bei einer Datenrate von 500 Kbps deutlich weniger als 200 Kunden bedient werden können. Es treten somit insbesondere dann Probleme auf, wenn ein sehr gefragter Content, beispielsweise ein aktueller Kinofilm als Video-on-Demand, von einer großen Anzahl von Nutzern nahezu gleichzeitig aufgerufen wird. Innerhalb kurzer Zeit können dabei mehrere 10.000 oder 100.000 Zugriffe erfolgen.
Zu einer Verbesserung der Situation führt der Einsatz so genannter IP-Multicast-Techniken. Bei IP-Multicast handelt es sich um eine Erweiterung des für die Übertragung im Internet genutzten IP-Protokolls, mit der von einem Server bereitgestellte Inhalte (Content) gleichzeitig an eine Vielzahl von Clients versendet werden können. Dazu wird einer Client-Applikation eine IP-Multicast-Adresse aus einem reservierten Adressbereich des Internet mitgeteilt. Die Client-Applikation teilt sich dann sozusagen diese IP-Adresse mit anderen, auf anderen Hosts ablaufenden Client-Applikationen, wobei dazwischen liegende Router den IP-Datenstrom zur Versorgung aller Applikationen mit den Daten aufsplitten (Informationen zu IP-Multicast siehe u. a. www.ipmulticast.com). Eine Schwierigkeit besteht aber bei sehr hohen Zugriffszahlen weiterhin darin, dass die Vielzahl der Zugriffe zwar in kurzen Zeiträumen aber eben nicht genau zeitgleich erfolgt. Zur Bedienung all dieser zeitversetzten Zugriffe wären daher wiederum sehr hohe Bandbreiten für den Server und das Netz erforderlich.
Der Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren anzugeben, welches es ermöglicht, als Content-on-Demand auf einem Server im IP-Netz bereitgestellte Daten­ ströme bandbreiteneffizient an eine Mehrzahl gleichen Content zu unterschiedlichen, teilweise überlappenden Abrufzeiten anfordernde Clients zu überbertragen.
Die Aufgabe wird durch ein Verfahren mit Merkmalen entsprechend dem Hauptanspruch bzw. durch ein im Anspruch 6 charakterisiertes Verfahren gelöst. Vorteilhafte Weiter­ entwicklungen bzw. Ausgestaltungen des Verfahrens sind durch die jeweiligen Unteransprüche gegeben.
Nach dem erfindungsgemäßen Verfahren wird eine zeitdiskrete Übertragung des von einer großen Anzahl von Clients angeforderten Contents dadurch erreicht, dass zueinander jeweils zeitdifferente Phasen des Contents enthaltende Datenströme vom Server mehreren IP-Multicast-Adressen zugeführt werden. Über jede dieser IP-Multicast- Adressen werden die Datenströme dann von jeweils einer Gruppe (IP-Multicast-Gruppe) der den Content anfordernden Clients bezogen. Dabei werden die IP-Multicast-Gruppen mittels einer auf dem Server ablaufenden Routine jeweils unter Zuweisung der für sie gültigen IP-Multicast-Adresse entsprechend der zeitlichen Aufeinanderfolge der Anforderungen des Contents durch die Clients gebildet. Die Bildung der Gruppen erfolgt, indem die jeweilige IP-Multicast-Adresse jedem zur Gruppe gehörenden Client über eine von ihm zur Anforderung des Contents aufgebaute IP-Unicast-Verbindung mitgeteilt wird, und die hierfür genutzte Verbindung für eine variable, aber hinsichtlich ihrer maxi­ malen Dauer vom Betreiber des Servers vorgebbare Zeitspanne weiterhin aufrechterhalten wird. Dies geschieht durch einen überbrückenden Dialog zwischen dem Server und dem Client und/oder dadurch, dass vom Server an den Client zur Überbrückung der genannten Zeitdauer zusätzliche Daten gesendet werden, wobei die maximale Dauer der Zeitspanne, in der eine jeweilige IP-Unicast-Verbindung aufrechterhalten wird, mit dem Eintritt einer von der Serverroutine festgestellten Bedingung beginnt. Nach dem Ablauf der, bezogen auf den jeweiligen Client, variablen Zeitspanne steht dann der angeforderte Content auf der der Gruppe von Clients zugewiesenen IP-Multicast-Adresse bereit und die Downstream-Übertragung beginnt. Die Zeitspanne, für welche die IP-Unicast-Verbin­ dung zu einem Client gehalten wird, ist insoweit variabel als dessen Content-Anforderung zu einem Zeitpunkt erfolgen kann, zudem bereits ein Teil der maximalen Dauer dieser Zeitspanne aufgrund des zeitlich zuvor erfolgten Eintritts der Bedingung für den Beginn der Zeitdauer verstrichen ist. Auf die Art des den Beginn der maximalen Zeitdauer aus­ lösenden Ereignisses bzw. der damit verbundenen Bedingung soll später noch eingegangen werden.
Gemäß dem Verfahren wird also sozusagen durch den Server erst für eine bestimmte Zeit eine Anzahl von gleichen Content anfordernden Clients aufgesammelt. Alle solcher­ maßen "gesammelten" Clients bzw. Content-Anforderungen werden einer gemeinsamen IP-Multicast-Gruppe zugeordnet. Die Daten, welche zur Überbrückung der für das Zusammenstellen einer IP-Multicast-Gruppe zur Verfügung stehenden Zeit zwischen dem Server und dem Client ausgetauscht oder vom Server an den Client übermittelt werden, können unterschiedlichster Art sein. Im einfachsten Falle kann es sich beispielsweise um einen vom Server an den Client übertragenen Trailer variabler Länge handeln.
Entsprechend einer vorteilhaften Ausgestaltung des Verfahrens ist die maximale Dauer der Zeitspanne für das Aufrechterhalten der IP-Unicast-Verbindung zwischen dem Server und einem Client bzw. der von der Anforderung des Contents bis zum Beginn der IP-Multicast-Übertragung vergehenden Zeitspanne durch den Betreiber des Servers in Abhängigkeit der zur Übertragung des gesamten Contents benötigten Zeit variabel festlegbar. Dabei erfolgt die Bildung von IP-Multicast-Gruppen vorzugsweise in festgelegten Intervallen, so dass es sich bei der Bedingung mit deren Eintritt die maximale Dauer der Zeitspanne für das Aufrechterhalten einer IP-Unicast-Verbindung zwischen dem Server und einem einer IP-Multicast-Gruppe zugeordneten Client beginnt, um den Ablauf der Dauer für die Bildung der jeweils vorherigen IP-Multicast-Gruppe handelt. Diese Zeitdauer entspricht dann wiederum einem ganzzahligen Teil der zur Übertragung des gesamten Contents benötigten Zeit. Gemäß einer möglichen Ausge­ staltung des Verfahrens fällt der Beginn der Zeitdauer zur Zusammenstellung der ersten IP-Multicast-Gruppe mit der ersten Anforderung des entsprechenden Contents durch einen Client zusammen. Bei einer praxisgerechten Lösung beträgt die zwischen der Anforderung des Contents und dem Beginn der Downstream-Übertragung vergehende Zeitspanne zwischen 10 und 60 Sekunden, wobei sich diese Angabe selbstverständlich nur auf den zwischen dem Server und dem Client auf der Protokollebene erfolgenden Datenaustausch bezieht und etwaige Bedientätigkeiten eines das Angebot nutzenden Kunden, beispielsweise zum Nachweis seiner Zugangsberechtigung, nicht einbezieht.
Durch das Versenden von Datenströmen, welche zeitdifferente Phasen des Contents beinhalten, und die Verzögerung des Starts einer Downstream-Übertragung für eine zuvor festgelegte maximale Zeitdauer wird also der gesamte Content quasi in unterschiedliche Zeitscheiben aufgeteilt. So werden beispielsweise zu einem Zeitpunkt X an eine erste IP-Multicast-Gruppe Sequenzen übermittelt, welche, bezogen auf den zeitlichen Ablauf des Contents, der 5. Minute seiner Gesamtdauer entsprechen, während sich eine andere Gruppe im Hinblick auf den Fortschritt der Downstream-Übertragung zum gleichen Zeit­ punkt, beispielsweise in der 6. Minute oder 10. Minute der gesamten Content-Sequenz befindet. Je nach der Dauer des Gesamtcontents und der Differenz zwischen den zuein­ ander zeitdifferenten Phasen seiner Übertragung lässt sich dabei im Vorfeld die benötigte Bandbreite jeweils exakt bestimmen. Angenommen, ein multimedialer Datenstrom weist eine Gesamtübertragungsdauer von 60 Minuten auf, und die für die Zusammenstellung einer IP-Multicast-Gruppe festgelegte maximale Zeitdauer beträgt eine Minute, dann werden von dem Server gleichzeitig jeweils 60 verschiedene Phasen des Contents an 60 verschiedene IP-Multicast-Adressen übermittelt. Erfolgt die Übertragung des Daten­ stroms über jede dieser IP-Multicast-Adressen, entsprechend den eingangs getroffenen Annahmen, mit einer Datenrate von 1 Mbps (1 Megabit per second), so muss der Video­ server den Content mit einer Gesamtdatenrate 60 Mbps zu Verfügung stellen können.
Ein möglicher Verfahrensablauf zur Übertragung eines Videos gestaltet sich entsprechend einer Variante der Erfindung wie folgt:
  • a) Ein Kunde informiert sich unter Nutzung eines IP-Multicast-fähigen Endgerätes (PC oder Set-Top-Box) über Video-on-Demand-Angebote.
  • b) Unter Nutzung einer hierzu aufgebauten IP-Unicast-Verbindung und eines unter der entsprechenden IP-Adresse verfügbaren Links bestellt bzw. kauft er einen ange­ botenen Content.
  • c) Gleichzeitig wird auf dem Endgerät des Kunden eine zum Empfang und zur visuell/akustischen Umsetzung von Datenströmen geeignete Applikation gestartet.
  • d) Der Client des Kunden wird durch den Server einer IP-Multicast-Gruppe zum Bezug des ausgewählten Contents zugeordnet.
  • e) Dem Client werden die für die zuvor genannte Gruppe gültige IP-Multicast-Adresse sowie die Startzeit für die IP-Multicast-Übertragung des Contents über die bereits bzw. noch bestehende IP-Unicast-Verbindung mitgeteilt. Gegebenenfalls werden an den Client des Kunden weitere Parameter, wie Informationen über ein für die spätere IP-Multicast-Übertragung zu verwendendes Verschlüsselungsverfahren sowie die dabei zu verwendenden Schlüssel oder Parameter über die Qualität des Services (QoS - Quality-of-Service) übermittelt.
  • f) Sofern die für die Zusammenstellung von IP-Multicast-Gruppen festgelegte maximale Zeitdauer noch nicht verstrichen ist, wird an den Client des Kunden ein Datenstrom übertragen, welcher von der zur Umsetzung der Datenströme geeigneten, auf dem Client des Kunden ablaufenden Software als ein (Werbe-)Trailer variabler Länge umgesetzt wird.
  • g) Zum Startzeitpunkt des Videos wird die Multicast-Session eröffnet und der den ange­ forderten Content enthaltende Datenstrom wird an der der IP-Multicast-Gruppe zugewiesenen IP-Multicast-Adresse für die beginnende Downstream-Übertragung bereitgestellt.
Entsprechend einer besonders vorteilhaften Ausgestaltung der Erfindung soll der Down­ load bzw. die Wiedergabe der Datenströme durch den Benutzer mit Hilfe eines entsprechenden Endgerätes in einer mit der Bedienung eines Videorecorders vergleich­ baren Art und Weise beeinflussbar sein. Diese Weiterentwicklung sieht daher die Abbildung einer Stop- bzw. Pausentaste auf der graphischen Benutzeroberfläche der die Daten umsetzenden Client-Applikation vor. Im Falle einer Betätigung dieser Taste durch den Benutzer wird die zu seinem Client bestehende IP-Multicast-Verbindung zunächst aufrechterhalten und die weiter eingehenden Daten zwar nicht umgesetzt, aber in einem Puffer des Endgerätes zwischengespeichert. Nach dem Lösen der Stop- bzw. Pausentaste oder dem Betätigen einer weiterhin vorgesehenen Starttaste, also der Deaktivierung der Stop/Pause-Funktion, wird die Wiedergabe des Contents ab der Stop-Position durch Umsetzung der aus dem Zwischenspeicher abgerufenen Datenströme fortgesetzt. Gemäß der zuvor erläuterten Weiterbildung des erfindungsgemäßen Verfahrens ist zudem ein Regime für den Fall des Erreichens der Kapazitätsgrenze des Pufferspeichers im Endgerät festgelegt. In einem solchen Fall erfolgt zwischen dem Server und dem Client ein Dialog, in welchem dem Client eine neue IP-Multicast-Adresse mitgeteilt wird, über welche der Datenstrom zur Fortsetzung an der Unterbrechungsstelle erneut angefordert werden kann. Dabei ist für die praxisgerechte Umsetzung des Verfahrens anzustreben, dass das kürzest mögliche Stop-Start-Intervall unter 5 Sekunden liegt, damit die Bedienung mit einem Videorekorder vergleichbar erscheint. Je nach Dauer der Unterbrechung wird diese IP- Multicast-Adresse im Rahmen des Dialoges zwischen dem Server und dem Client entsprechend der für die Zusammenstellung von IP-Multicast-Gruppen festgelegten Zeit­ dauer mehrmals aktualisiert. Diesen Überlegungen folgend sieht eine weitere Verbesserung des Verfahrens am Client eine Funktion vor, mittels welcher sich ein Nutzer im Content, wiederum vergleichbar mit einem Videorekorder, schnell vorwärts (Forward) oder schnell rückwärts (Rewind) bewegen kann. Zu diesem Zweck werden an jeden zu einer IP-Multicast-Gruppe gehörendem Client neben der IP-Multicast-Adresse seiner (aktuellen) Gruppe auch die IP-Multicast-Adressen der nachfolgenden (bei der Wiedergabe des Contents zeitlich weiter zurückliegenden) und der vorauslaufenden (bei der Wiedergabe des Contents zeitlich weiter fortgeschrittenen) IP-Multicast-Gruppe übermittelt. In dem hierzu in drei Bereiche unterteilten Pufferspeicher des Clients werden unter Nutzung dieser Adressen Teile des der aktuellen Gruppe sowie des der nachfolgenden und der vorauslaufenden IP-Multicast-Gruppe übermittelten Contents zwischengespeichert. Beim Vorwärts- oder Rückwärtsbewegen im Content wird ein der Adressierung einzelner Speicherzellen der Pufferspeicher dienender Pointer bzw. Zeiger der zur visuell/akustischen Umsetzung der Datenströme auf dem Client laufenden Applikation in dem den Content der aktuellen Gruppe aufnehmenden Speicherbereich vorwärts oder rückwärts bewegt bzw. dieser Pointer hoch- oder heruntergezählt. Sofern dabei die Bereichsgrenzen für die aktuelle Gruppe nach oben oder unten überschritten werden, wird die vorauslaufende oder die nachfolgende IP-Multicast-Gruppe als aktuelle Gruppe definiert. Gleichzeitig wird die Adresse der jeweils weitest entfernten Gruppe ungültig gesetzt, die Gruppe also deaktiviert und eine neue benachbarte Gruppe unter Anforderung einer entsprechenden IP-Multicast-Adresse beim Server aktiviert. Das heißt, dass im Falle der Forward-Funktion die Adresse der nachfolgenden IP-Multicast-Gruppe und beim Rewind die Adresse der vorauslaufenden IP-Multicast-Gruppe ungültig gesetzt wird. Die Abforderung der IP-Multicast-Adresse für die neu zu aktivierende Gruppe erfolgt durch den Client unter Nutzung in den Streamingdaten des Contents enthaltener Zeitinformationen. Beim Forward wird infolge dessen die IP-Multicast-Adresse der übernächsten, beim Rewind die IP-Multicast-Adresse der vorvorhergehenden, also der bezogen auf die Wiedergabe des Contents gegenüber der nachfolgenden IP-Multicast- Gruppe, zeitlich noch weiter zurückliegenden Gruppe abgefordert. Im Ergebnis dieser Vorgänge werden schließlich im Pufferspeicher wiederum Streamingdaten abgelegt, welche Teile des Contents einer aktuellen Gruppe sowie einer vorhergehenden und einer nachfolgenden IP-Multicast-Gruppe entsprechen.
Vorzugsweise dient die Systemzeit des Servers als Zeitbasis für die Steuerung aller im Zusammenhang mit der Erläuterung des Verfahrens dargestellten zeitlichen Abläufe. Dies kann zum Beispiel im Hinblick auf die Realisierung der Forward/Rewind-Funktion geschehen, indem der Client den gerade aktuellen Zeitpunkt der Echtzeitübertragung (also die aktuelle zeitliche Phase des an ihn übertragenen Contents) aus einem Header des bei der Übertragung verwendeten Streaming-Protokolls (z. B. Real Time Protocol, MPEG-4 oder andere) übernimmt und an den Server sendet. Der Server kann diese relative Zeit (relativ innerhalb des Echtzeitstroms) mit seiner Systemzeit in Relation setzen und daraus die Adresse der IP-Multicast-Gruppe ermitteln, die er dem Client mitteilen muss.
Die Erfindung soll anschließend anhand eines Ausführungsbeispieles nochmals erläutert werden, wobei anhand der Fig. 1 die Forward-/Rewind-Funktion verdeutlicht werden soll.
Auf dem Server eines Anbieters wird ein Kinofilm als Video-on-Demand bereitstehender Datenströme angeboten. Samstags um 20.00 Uhr, also zu einer vom Fernsehen her bekanntermaßen beliebten Sendezeit, wird dieser Content aufgrund dessen, dass es sich um einen aktuellen Kinofilm handelt, im starken Maße von einer Vielzahl von Kunden angefordert. Innerhalb einer vergleichsweise kurzen Zeitspanne greifen demnach nahezu, aber nicht vollständig gleichzeitig, viele Kunden auf den entsprechenden Server zu. Hierzu baut jeder Kunde mittels eines Endgerätes (Client) eine IP-Unicast-Verbindung zu dem entsprechenden Videoserver auf. Vom Server wird der Client einer IP-Multicast- Gruppe zugeteilt und allen zu dieser Gruppe gehörenden Clients werden, über die zu ihnen jeweils bestehende IP-Unicast-Verbindung, die für die Gruppe gültige IP-Multicast- Adresse sowie die Startzeit der Downstream-Übertragung des angeforderten Contents mitgeteilt. Solange dieser Zeitpunkt nicht erreicht ist, werden zwischen den Clients der Kunden und dem Server gegebenenfalls weitere, die später aufzubauende Verbindung charakterisierende Parameter ausgetauscht. Es handelt sich hierbei beispielsweise um die Festlegung eines Verschlüsselungsmodus für die Übertragung der Daten sowie um den Austausch der für die Verschlüsselung notwendigen digitalen Schlüssel. Sofern nach diesem Austausch der Zeitpunkt für die Bereitstellung des Videodatenstroms an der den Clients der Gruppe übermittelnden IP-Multicast-Adresse immer noch nicht erreicht ist, werden vom Server an die Clients weitere Daten übermittelt, welche ausschließlich dazu dienen, die bis zum Start der Downstream-Übertragung noch verbleibende Zeit zu über­ brücken. Beispielsweise werden den Clients Datenströme zugeführt, welche von der zwischenzeitlich auf dem jeweiligen Endgerät gestarteten Software zur Umsetzung von Datenströmen in Form eines zu Werbezwecken dienenden Trailers visualisiert bzw. akus­ tisch wiedergegeben werden.
Mit dem Erreichen des für die IP-Multicast-Übertragung vorgesehenen Zeitpunktes steht an der IP-Multicast-Adresse, welche dem Client eines Kunden sowie anderen mit diesem Client zu einer Gruppe zusammengefassten Clients zugewiesen wurde, der Datenstrom mit dem angeforderten Content zur Downstream-Übertragung bereit. Quasi synchronisiert auf diesen Zeitpunkt beginnt die Übertragung des Datenstroms zeitgleich für die gesamte IP-Multicast-Gruppe. Jede weitere später durch den Server gebildete IP-Multicast-Gruppe erhält den gleichen Content über eine andere IP-Adresse in einer bezogen auf die Ablaufzeit des Contents zeitversetzten Phasenlage.
Entsprechend bereits dargestellter Weiterbildungen des Verfahrens soll der Nutzer die Wiedergabe des Contents durch den Client, ähnlich wie die Wiedergabe einer Video­ kassette auf einem Videorekorder, beeinflussen können. Hierzu sollen ihm eine Start/Pause-Funktion sowie eine Funktion für schnellen Vor- und Rücklauf (Forward/Rewind) zur Verfügung stehen. Die Forward-/Rewind-Funktion soll mit Hilfe der schematischen Darstellungen in den Fig. 1a) bis 1c) noch etwas näher erläutert werden. Dem grundsätzlichen Prinzip des Verfahrens folgend, wird der zur Abforderung sowie zur Umsetzung eines Contents dienende Client mit Forward/Rewind-Funktion einer IP-Multicast-Gruppe (aktuelle Gruppe) zugeteilt und ihm deren IP-Multicast-Adresse über die zur Anforderung des Contents aufgebaute IP-Unicast-Verbindung mitgeteilt. Zusätzlich werden ihm aber zur Realisierung der Forward/Rewind-Funktion die IP-Multicast-Adressen der, bezogen auf seine aktuelle Gruppe, vorauslaufenden und nachfolgenden Gruppe übermittelt. Der Client verfügt über einen Pufferspeicher, in welchem Teile des Contents zeitweilig zwischengespeichert werden können. Wie aus Fig. 1a) ersichtlich, ist dieser Pufferspeicher in drei Bereiche unterteilt. Ein Bereich nimmt Teile des Contents auf, der an diejenige Gruppe ausgestrahlt wird, welcher der Client zugeordnet ist. In den beiden anderen Speicherbereichen werden Teile des an die vorauslaufende bzw. an die nachfolgende Gruppe übermittelten Contents zwischen­ gespeichert. Bei der Umsetzung des Contents auf dem Client wird der Speicher von einer hierzu geeigneten Software mittels eines Pointers - eines Zeigers zur Adressierung einzelner Speicherzellen - verwaltet. Der Pointer zeigt dabei jeweils auf den aktuell auszulesenden und visuell umzusetzenden Bereich des Pufferspeichers. Wird nun die Forward-Funktion betätigt, so wird der Pointer innerhalb des Speicherbereichs für die aktuelle Gruppe vorwärts bewegt bzw. nach oben gezählt. Dies ist in der Fig. 1b) dadurch veranschaulicht, dass der Pfeil nach rechts verschoben wurde. Wenn die Forward-Funktion über eine längere Zeit betätigt wird, führt dies zwangsläufig dazu, dass der Pointer die obere Grenze des Speicherbereichs für die aktuelle Gruppe überschreitet. Gemäß dem vorgeschlagenen Verfahren wird dann, ohne dass dies vom Nutzer bemerkt wird, die vorauslaufende Gruppe als aktuelle Gruppe definiert und der Pointer zeigt auf den entsprechenden Speicherbereich. Die Fig. 1c) veranschaulicht dies. Gleichzeitig wird die am weitesten entfernt liegende Gruppe, also die ehemals nachfolgende Gruppe deak­ tiviert, d. h. die zugehörige IP-Multicast-Adresse ungültig gesetzt. Die ehemals aktuelle Gruppe wird nun, nachdem der Pointer einen Speicherbereich nach oben verschoben wurde, zur nachfolgenden Gruppe erklärt. Außerdem wird eine Verbindung zum Server aufgebaut, um eine neue, die künftig als vorauslaufend behandelte Gruppe adressierende IP-Multicast-Adresse anzufordern. Hierdurch ist sichergestellt, dass im Pufferspeicher wieder wie zuvor drei verschiedene Phasen des Contents zwischengespeichert werden.
Um einen reibungslosen Übergang zwischen den Phasen zu ermöglichen, werden in den drei Speicherbereichen in der Nähe der Bereichsgrenzen zeitlich überlappende Teile des Contents zwischengespeichert. Dies wird in Fig. 1a) bis 1c) dadurch verdeutlicht, dass sich die Symbole für die Speicherbereiche hinsichtlich ihrer horizontalen Anordnung und Erstreckung einander überdecken.

Claims (11)

1. Verfahren zur bandbreiteneffizienten Übertragung von Datenströmen, bei dem als Content-on-Demand auf einem Server in einem IP-Netz bereitgestellte Datenströme über IP-Multicast-Verbindungen an eine Mehrzahl gleichen Content zu unterschied­ lichen und gegebenenfalls teilweise überlappenden Abrufzeiten anfordernde Clients zeitdiskret übertragen werden, indem zueinander jeweils zeitdifferente Phasen des Contents enthaltende Datenströme vom Server mehreren IP-Multicast-Adressen zugeführt und über jede dieser IP-Multicast-Adressen von jeweils einer Gruppe (IP-Multicast-Gruppe) der den Content anfordernden Clients bezogen werden, wobei die IP-Multicast-Gruppen mittels einer auf dem Server ablaufenden Routine, jeweils unter Zuweisung der für sie gültigen IP-Multicast-Adresse, entsprechend der zeitlichen Aufeinanderfolge der Anforderung des Contents durch die Clients gebildet werden, indem die IP-Multicast-Adresse jedem zur Gruppe gehörenden Client über eine von ihm zur Anforderung des Contents aufgebaute IP-Unicast-Verbindung mitgeteilt wird und diese IP-Unicast-Verbindung, überbrückt durch einen Dialog zwischen dem Server und dem Client und/oder durch weitere vom Server zum Client übermittelte Daten, für eine variable Zeitspanne weiterhin aufrechterhalten wird, deren maximale, vom Betreiber des Servers vorgebbare Dauer mit dem durch die auf dem Server laufende Routine festgestellten Eintritt einer Bedingung beginnt und nach deren Ablauf die Downstream-Übertragung des angeforderten Contents über die der betreffenden IP-Multicast-Gruppe zugewiesene IP-Multicast-Adresse beginnt.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die maximale Dauer der Zeitspanne für das Aufrechterhalten der IP-Unicast-Verbindung zwischen dem Server und einem einer IP-Multicast-Gruppe zugeordneten Client durch den Betreiber des Servers in Abhängigkeit der zur Übertragung des gesamten Contents benötigten Zeit variabel festlegbar ist.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Bildung von IP-Multicast-Gruppen in festgelegten Intervallen erfolgt, so dass es sich bei der Bedingung, mit deren Eintritt die maximale Dauer der Zeitspanne für das Aufrechterhalten einer IP-Unicast-Verbindung zwischen dem Server und einem einer IP-Multicast-Gruppe zugeordneten Client beginnt, um den Ablauf der Dauer für die Bildung der jeweils vorherigen IP-Multicast-Gruppe handelt, wobei diese Zeitdauer einem ganzzahligen Teil der zur Übertragung des gesamten Contents benötigten Zeit entspricht.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Zeitdauer zur Bildung der ersten, einen bestimmten Content anfordernden IP-Multicast-Gruppe mit dem Eingang der ersten Anforderung dieses Contents durch einen Client beim Server beginnt.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die Zeitspanne, für welche die IP-Unicast-Verbindung zwischen dem Server und einem Content anfordernden Client bis zur Bereitstellung des Contents auf der dem Client und seiner IP-Multicast-Gruppe zugewiesenen IP-Multicast-Adresse aufrechterhalten wird, 10 Sekunden bis 1 Minute beträgt.
6. Verfahren zur bandbreiteneffizienten Übertragung von Datenströmen, bei dem als Content-on-Demand auf einem Server in einem IP-Netz bereitgestellte Datenströme über IP-Multicast-Verbindungen an die Clients (Endgeräte mit einer gegebenenfalls zugehörigen Software-Umgebung) einer Mehrzahl gleichen Content zu unterschied­ lichen und gegebenenfalls teilweise überlappenden Abrufzeiten anfordernder Kunden zeitdiskret übertragen werden, indem
  • a) sich der jeweilige Kunde unter Nutzung einer von seinem IP-Multicast-fähigen Endgerät (PC oder Set-Top-Box) zu einer IP-Adresse aufgebauten IP-Unicast- Verbindung über das Content-on-Demand-Angebot informiert,
  • b) der Kunde, unter Nutzung der bestehenden IP-Unicast-Verbindung und eines unter der entsprechenden IP-Adresse verfügbaren Links, angebotenen Content bestellt oder kauft,
  • c) auf dem Endgerät des Kunden eine zum Empfang und zur visuell/akustischen Umsetzung von Datenströmen geeignete Applikation gestartet wird,
  • d) der den Content anfordernde Client des Kunden vom Server des den Content zur Verfügung stellenden Betreibers einer Gruppe (IP-Multicast-Gruppe) gleichen Content anfordernder Clients zugeordnet wird,
  • e) über die weiterhin bestehende IP-Unicast-Verbindung vom Server die für die IP-Multicast-Gruppe gültige IP-Multicast-Adresse sowie die Startzeit für die IP-Multicast-Übertragung des Contents über diese Adresse an den Client über­ mittelt wird, wobei gegebenenfalls zwischen dem Server und dem Client zu der vorgesehenen IP-Multicast-Übertragung weitere Parameter, wie Angaben zur Art eines einzusetzenden Verschlüsselungsverfahrens mit zugehörigen Schlüsseln oder Quality-of-Service-Parameter, ausgetauscht werden,
  • f) sofern die Startzeit für die IP-Multicast-Übertragung noch nicht erreicht ist, weitere Daten vom Server an den Client in Form eines (Werbe-)Trailers variabler Länge gesendet werden,
  • g) bei Erreichen der Startzeit für die IP-Multicast-Übertragung die Multi­ cast-Session eröffnet und der Content des übertragenen Datenstroms auf den zu der betreffenden IP-Multicast-Gruppe gehörenden Clients dargestellt wird.
7. Verfahren nach Anspruch 1 oder 6, dadurch gekennzeichnet, dass dem Benutzer eines Content anfordernden Clients eine Stop/Pause-Funktion zur Verfügung gestellt wird, wobei im Falle einer Aktivierung dieser Funktion die IP-Multicast-Verbindung aufrechterhalten und der weitere in Form von Datenströmen eingehende Content in einem Pufferspeicher des Clients zwischengespeichert wird, aus dem er zeitverzögert von einer zur visuell/akustischen Umsetzung von Datenströmen geeignete Appli­ kation wieder ausgelesen werden kann.
8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass bei Erreichen der maxi­ malen Kapazität des bei aktivierter Stop/Pause-Funktion zur Zwischenspeicherung genutzten Pufferspeichers zwischen dem Server und dem betreffenden Client ein Dialog beginnt, in welchem der Client einer neuen IP-Multicast-Gruppe zugeordnet und ihm die für diese Gruppe gültige IP-Multicast-Adresse übermittelt wird, wobei der Content über diese Adresse zeitversetzt, also in einer gegenüber der zuvor gültigen IP-Multicast-Adresse zeitlich früheren Phase seines Ablaufs zu beziehen ist und sich dieser Verfahrensablauf bis zur Deaktivierung der Stop/Pause-Funktion oder dem Abbruch der auf dem Client zur Umsetzung der Datenströme laufenden Applika­ tion wiederholt.
9. Verfahren nach einem der Ansprüche 1 oder 6 bis 8, dadurch gekennzeichnet, dass an jeden zu einer IP-Multicast-Gruppe gehörenden Client neben der IP-Multicast- Adresse seiner Gruppe (aktuelle Gruppe) auch die IP-Multicast-Adressen der nachfolgenden (bei der Wiedergabe des Contents zeitlich weiter zurückliegenden) und der vorauslaufenden (bei der Wiedergabe des Contents zeitlich weiter fortgeschrittenen) IP-Multicast-Gruppe übermittelt und in einem in drei Bereiche unterteilten Pufferspeicher des Clients Teile des der aktuellen Gruppe sowie des der nachfolgenden und der vorauslaufenden IP-Multicast-Gruppe übermittelten Contents zwischengespeichert werden und dass dem Benutzer des Clients eine Funktion zur Verfügung steht, mittels welcher er sich vergleichbar einem Videorekorder in dem Content schnell vorwärts (Forward) oder schnell rückwärts (Rewind) bewegen kann, indem ein zur Adressierung einzelner Speicherzellen des Pufferspeichers dienender Pointer (Zeiger) einer zur visuell/akustischen Umsetzung von Datenströmen auf dem Client laufenden Applikation in dem den Content der aktuellen Gruppe aufnehmenden Speicherbereich vorwärts oder rückwärts bewegt beziehungsweise hoch- oder heruntergezählt und beim Überschreiten der Speicherbereichsgrenzen für diese Gruppe die vorauslaufende oder die nachfolgende IP-Multicast-Gruppe als aktuelle Gruppe definiert wird sowie im Falle der Forward-Funktion die Adresse der nachfolgenden IP-Multicast-Gruppe, andernfalls die Adresse der vorauslaufenden IP-Multicast-Gruppe ungültig gesetzt und vom Client unter Nutzung in den Streamingdaten des Contents enthaltener Zeitinformationen im Falle des Forward die IP-Multicast-Adresse der übernächsten, also noch weiter vorauslaufenden Gruppe, andernfalls die IP-Multicast-Adresse der, bezogen auf die Wiedergabe des Contents gegenüber der nachfolgenden IP-Multicast-Gruppe, zeitlich noch weiter zurückliegenden Gruppe vom Server abgefordert wird, so dass wiederum der Pufferspeicher mit Streamingdaten, welche Teile des Contents einer aktuellen Gruppe sowie einer vorauslaufenden und einer nachfolgenden IP-Multicast-Gruppe repräsentieren, belegt wird.
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass die Systemzeit des Servers als Zeitbasis zur Steuerung der zeitlichen Abläufe dient.
11. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass es sich bei dem Content um Video-on-Demand handelt.
DE2001104961 2001-02-03 2001-02-03 Verfahren zur bandbreiteneffizienten Übertragung von Datenströmen in einem IP-Netz Withdrawn DE10104961A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE2001104961 DE10104961A1 (de) 2001-02-03 2001-02-03 Verfahren zur bandbreiteneffizienten Übertragung von Datenströmen in einem IP-Netz

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE2001104961 DE10104961A1 (de) 2001-02-03 2001-02-03 Verfahren zur bandbreiteneffizienten Übertragung von Datenströmen in einem IP-Netz

Publications (1)

Publication Number Publication Date
DE10104961A1 true DE10104961A1 (de) 2002-08-08

Family

ID=7672782

Family Applications (1)

Application Number Title Priority Date Filing Date
DE2001104961 Withdrawn DE10104961A1 (de) 2001-02-03 2001-02-03 Verfahren zur bandbreiteneffizienten Übertragung von Datenströmen in einem IP-Netz

Country Status (1)

Country Link
DE (1) DE10104961A1 (de)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2906954A1 (fr) * 2006-10-10 2008-04-11 Tdf Sa Procede de retardement temporel de flux de contenus numeriques,dispositif,et produit programme d'ordinateur correspondants.
US20170366590A1 (en) * 2014-09-15 2017-12-21 Verizon Digital Media Services Inc. Multi-Tenant Over-The-Top Multicast
CN114938361A (zh) * 2022-05-30 2022-08-23 阿里云计算有限公司 媒体服务提供方法、***、设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19807076A1 (de) * 1998-02-20 1999-08-26 Cit Alcatel Datenbereitstellungsystem
US6085221A (en) * 1996-01-08 2000-07-04 International Business Machines Corporation File server for multimedia file distribution
WO2000048364A1 (fr) * 1999-02-09 2000-08-17 Sony Corporation Systeme de distribution de l'information, dispositif terminal, dispositif serveur, procede de reception de donnees, et procede de transmission de donnees

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6085221A (en) * 1996-01-08 2000-07-04 International Business Machines Corporation File server for multimedia file distribution
DE19807076A1 (de) * 1998-02-20 1999-08-26 Cit Alcatel Datenbereitstellungsystem
WO2000048364A1 (fr) * 1999-02-09 2000-08-17 Sony Corporation Systeme de distribution de l'information, dispositif terminal, dispositif serveur, procede de reception de donnees, et procede de transmission de donnees

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
KATZ,Randy H.: High-Performance Network and Channel Based Storage. In: Proceedings Of The IEEE, Vol.80, No.8, Aug. 1992, S.1238-1260 *

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2906954A1 (fr) * 2006-10-10 2008-04-11 Tdf Sa Procede de retardement temporel de flux de contenus numeriques,dispositif,et produit programme d'ordinateur correspondants.
WO2008043738A1 (fr) * 2006-10-10 2008-04-17 Tdf Procédé de retardement temporel de flux de contenus numériques, dispositif, et produit programme d'ordinateur correspondants
US20170366590A1 (en) * 2014-09-15 2017-12-21 Verizon Digital Media Services Inc. Multi-Tenant Over-The-Top Multicast
US10791157B2 (en) * 2014-09-15 2020-09-29 Verizon Digital Media Services Inc. Multi-tenant over-the-top multicast
CN114938361A (zh) * 2022-05-30 2022-08-23 阿里云计算有限公司 媒体服务提供方法、***、设备及存储介质

Similar Documents

Publication Publication Date Title
DE60103005T2 (de) Datenstrom in einer peer-to-peer Architektur
DE69832247T2 (de) Auf einem verteilten Internet- Protokollen basierte Echtzeit- Multimedia- Datenströmungs- Architektur
DE60308013T2 (de) Verfahren zur Verteilung von Echtzeitdatenströmen über ein Multimedianetz sowie Vermittlungvorrichtung und Multimedianetz
DE112012002526B4 (de) Medieninhalt-Übertragungsverfahren und Übertragungsvorrichtung unter Verwendung desselben
DE112006002677T5 (de) Verfahren und Vorrichtung für RTP-Ausgabe-Streaming unter Verwendung von komplementären Richtungsdateien
DE112012001770T5 (de) Auf Echtzeitverarbeitungsfähigkeit basierende Qualitätsanpassung
DE69517795T2 (de) System für Information auf Anfrage
DE69931513T2 (de) Datentransport
DE60026006T2 (de) System zum Empfang von Mehrfachdaten
DE60220802T2 (de) Verfahren zur verbreitung von inhalt ein erfassungsserver und empfänger
DE10004829B4 (de) Verfahren und Vorrichtung zum Übertragen von Dateneinheiten eines Datenstroms
DE69722162T2 (de) Verfahren zur Steuerung eines Nachrichtenflusses in einem interaktiven Netzwerk
DE10104961A1 (de) Verfahren zur bandbreiteneffizienten Übertragung von Datenströmen in einem IP-Netz
DE60205393T2 (de) Verfahren und vorrichtung zum empfang von rundsendedaten
EP2030474B1 (de) Verfahren und anordnung zum aufbau von kommunikationsbeziehungen
DE60214854T2 (de) Verfahren zur verbreitung von inhalt ein erfassungsserver und empfänger
EP2454863A1 (de) Steuerung der datenrate eines medien-downloads anhand von client-wiedergabestatusinformation
EP2206311B1 (de) Verfahren und system zur bandbreite-optimierten übertragung von hdtv-datenströmen über ein ip-basiertes verteilernetz
DE10353793B4 (de) Verfahren zur Verbesserung der Wiedergabequalität bei paketorientierter Übertragung von Audio-/Video-Daten
DE4446093C2 (de) Verfahren zur Steuerung eines Verbindungsaufbaus für interaktive Dienste
WO2021008943A1 (de) Verfahren zur übertragung von videoinformation an ein telekommunikationsgerät, wobei die videoinformation eine mehrzahl an videoinformationsströmen umfasst, system, telekommunikationsgerät, inhaltebezogene hintergrund-servereinrichtung, computerprogramm und computerlesbares medium
DE102008060346B4 (de) Verfahren und Multicast-Replikationspunkt zum Bereitstellen von Programmen einer Multicast-Gruppe
WO2009018791A1 (de) Verfahren und system zum reduzieren der umschaltlücke bei einem programmwechsel in einer digitalen videoumgebung
EP3585059B1 (de) Übertragung von echtzeitdatenpaketen von sendungen aus dem internet
DE102005046382A1 (de) Verfahren, Kommunikationsanordnung und dezentrale Kommunikationseinrichtung zum Übermitteln von Multimedia-Datenströmen

Legal Events

Date Code Title Description
OM8 Search report available as to paragraph 43 lit. 1 sentence 1 patent law
8141 Disposal/no request for examination