DE10101075C2 - Verfahren und Mediendistributionssystem zur Speicherung und Übertragung von Videodateien - Google Patents

Description

Die Erfindung betrifft ein Verfahren zur Speicherung und Über­ tragung von als Videodateien ausgebildeten Contents nach dem Oberbegriff des Anspruchs 1 sowie ein entsprechend ausgebilde­ tes Mediendistributionssystem.

Im Zuge der sich schnell ausweitenden Nutzung des Internet als Infrastruktur zur Verteilung von Informationsinhalten (Con­ tents) werden seit einigen Jahren auch völlig neuartige Mög­ lichkeiten der Distribution verschiedenartiger Bewegtbildfolgen (Spielfilme, Videoclips, Veranstaltungsmitschnitte etc.) er­ probt und teilweise auch bereits kommerziell realisiert. Für den direkten Abruf von Videos durch private Nutzer hat sich be­ reits der Begriff "Video-on-Demand" eingebürgert.

Beim derzeitigen Stand der Technik gibt es für die digitale Me­ diendistribution, speziell die Bereitstellung von Videodateien in heterogenen Netzwerken, jedoch noch differenzierte Limitie­ rungen hinsichtlich der Bandbreiten und der Leistungsstabili­ tät. Nur eine Minderheit der privaten Nutzer verfügt über die technischen Voraussetzungen hinsichtlich Endgerät und Datenka­ nal, um Videos in hoher Qualität (mit ca. 1 bis 4 Mbit/s) in Echtzeit - d. h. ohne vorheriges Herunterladen auf einen inter­ nen Massenspeicher - abzurufen.

Eine große Gruppe von Nutzern ist bereits über DSL-Leitungen an das Internet angeschlossen, womit Datenraten von 384 bis 768 Kbit/s realisiert werden. Für diese Nutzergruppe müssen also entsprechende Videostreams existieren. Nutzer von ISDN- und Analoganlagen benötigen den Videostream mit Datenraten zwischen 33,6 Kbit und 128 Kbit.

Ein zusätzliches Problem bei der Realisierung von Video-on-De­ mand stellen die in Abhängigkeit von der Netzauslastung im tat­ sächlichen Betrieb stark variierenden erreichbaren Datenraten dar.

Diese Situation stellt die Anbieter der in Rede stehenden Con­ tents (Videodateien) vor das Problem, ihr Angebot für die ver­ schiedenen Nutzergruppen mit mehreren Datenraten bereitstellen zu müssen, um ein breites Spektrum an Zugriffsgeschwindigkeiten der Nutzer abzudecken. Derzeit halten die Anbieter daher höchst umfangreiche Datenbasen vor, in denen jeder Content in den gän­ gigen Videostream-Varianten bezüglich der benötigten Datenrate bzw. Bandbreite vorgehalten wird. Es gibt also für jeden Con­ tent eine Mehrzahl von verschiedenen Dateien und folglich auch entsprechend viele Datenbankeinträge.

Diese Situation ist offensichtlich in mehreren Aspekten höchst nachteilig: Zum einen benötigen die auf diese Weise aufgebauten Datenbasen sehr viel Speicherplatz, so daß ihre Erstellung mit hohen Hardwarekosten verbunden ist. Weiterhin sind sie schwer adressierbar, weshalb die Anbieter mit sogenannten "großen" Da­ tenbanken (etwa Oracel8i o. ä.) arbeiten - obgleich einfache Perl-, PHP- oder andere scriptbasierte Datenbanken grundsätz­ lich den gleichen Zweck erfüllen würden. Schließlich ist ein entsprechend aufgebautes Komplettsystem nur noch relativ schwer zu skalieren, d. h. um einzelne Komponenten zur Leistungsver­ besserung oder Erweiterung zu ergänzen.

Zusätzliche Probleme bestehen bei der gegenwärtigen Praxis auf Seiten der Nutzer: Die Nutzer müssen sich üblicherweise für ei­ nen Videostream mit einer bestimmten Datenrate entscheiden, verfügen aber oftmals nicht über das Wissen, um die verschiede­ nen lieferbaren Videostreams bezüglich ihrer Datenraten und Qualitäten hinreichend zu unterscheiden. In der Regel ist zudem für die Übertragung von Videodateien mit niedriger Datenrate ("Low-Bitrate Videos") zusätzlich die Installation von separa­ ter Software oder eines sogenannten Plugin nötig.

Zum Problemkreis der Bilddatenkodierung, speziell einschließ­ lich Kompression, und der Umkodierung auf andere Datenraten (Transcoding) gibt es umfangreichen Stand der Technik.

So beschreibt die WO 00/30359 ein Verfahren zum Transcoding von Videosignalen und einen entsprechenden Transcoder, bei denen durch Einfügen eines sogenannten "Downsampling Filter" eine Re­ duzierung der Auflösung erreicht werden kann. Das Verfahren schließt eine geeignete Bearbeitung der dekodierten Bewegungs­ vektoren ein und wird zur Anwendung speziell bei Mpeg-2-Trans­ codern empfohlen.

In der US 5,805,224 werden ein Verfahren und ein Gerät zum Transcoding von Videosignalen unter Einsatz einer Bitraten­ steuerung beschrieben, wobei die Aufteilung jedes Bildes in ei­ ne Mehrzahl von Teilbildern (Subpictures) und eine Quantisie­ rung der dekodierten Signale mit einer Schrittweite vorgesehen ist, welche auf eine Ausgangs-Bitrate abgestimmt ist.

In der EP-A-0 942 605 wird ein Transcoder speziell für den Mpeg-Standard beschrieben, mit dem unterschiedliche Bitraten realisierbar sind. Die in einem vorangehenden Kodierungsverfah­ ren relevanten Kodierungsparameter können an den Mpeg-Kodierer übertragen werden und dieser führt eine aktuelle Kodierung auf­ grund dieser Information zur Vorgeschichte aus. Mit diesem Ver­ fahren wird eine Verschlechterung der Bildqualität bei einer wiederholten Ausführung von Dekodierungs- und Kodierungsverfah­ ren weitgehend verhindert.

Aus der WO 00/51357 ist ein Transcoding zwischen unterschiedli­ chen Bildkompressionsstandard auf DCT-Basis bekannt. Das Ver­ fahren kommt ohne vollständige Dekodierung des ersten Bitstroms und ohne vollständige Kodierung gemäß dem zweiten Bildkompres­ sionsstandard aus, sondern wendet Schritte des ersten Kompres­ sionsstandards auf den Eingangs-Bitstrom an, um dequantisierte DCT-Koeffizientendaten zu gewinnen. Ein DCT-Datenwandler des Transcoding-Systems wandelt dann die dequantisierten DCT-Koef­ fizientendaten in der DCT-Domäne insoweit um, als dies zur An­ wendung von Schritten des zweiten Bildkompressionsstandards auf die konvertierten DCT-Koeffizientendaten zur Erzeugung des Aus­ gangs-Bitstroms erforderlich ist.

Der Erfindung liegt die Aufgabe zugrunde, ein verbessertes Ver­ fahren der gattungsgemäßen Art sowie ein entsprechendes Medien­ distributionssystem bereitzustellen, mit denen eine erhebliche Vereinfachung und Kosteneinsparung bei der Speicherung und Handhabung der Contents erreicht werden können.

Diese Aufgabe wird hinsichtlich ihres Verfahrensaspektes durch ein Verfahren mit den Merkmalen des Anspruchs 1 und hinsicht­ lich ihres Vorrichtungsaspektes durch ein Mediendistributions­ system mit den Merkmalen des Anspruchs 10 gelöst.

Die Erfindung schließt den grundlegenden Gedanken der Bereit­ stellung eines Verfahrens bzw. Mediendistributionssystems ein, welches präzise auf die Spezifikationen der Nutzer (nachfolgend auch als "User" oder "Clients" bezeichnet) Bezug nimmt, indem es Videostreams mit entsprechend optimierten Parametern bereit­ stellt. Die Videostreams werden erfindungsgemäß auf die spezi­ fische Umgebung des jeweiligen Client angepaßt, welche durch eine Vielzahl von Variablen - insbesondere Leitungsgeschwindig­ keit, Stabilität, Betriebssystemversion, Prozessorarchitektur und bereits implementierte Video-Software - gekennzeichnet ist.

Weiterhin schließt die Erfindung den Gedanken ein, jeden Con­ tent in der Datenbasis (nachfolgend auch bezeichnet als "SAN = Storage-Area-Network" bezeichnet) nur noch in Form einer einzi­ gen Videodatei vorzuhalten. Diese Datei ist ein Video mit einem Informationsgehalt, der dem technisch realisierbaren Maximum entspricht. Diese eine optimale Videodatei wird dann erfin­ dungsgemäß - nach Erfassung der relevanten Parameter der Cli­ ent-Umgebung - exakt an diese Umgebung angepaßt, d. h. speziell durch eine "Herunterrechnung" (Downscaling) in eine Datei transformiert, die vom Client auf dem ihm verfügbaren Übertra­ gungskanal stabil empfangen werden kann. Wesentlich ist weiter­ hin, daß dieser Vorgang in Echtzeit oder schneller als Echtzeit abläuft, so daß letztlich die Videodatenübertragung an den Cli­ ent in Echtzeit erfolgen kann und kein vorhergehendes Herunter­ laden auf einen internen Speicher beim Endgerät des Nutzers er­ forderlich ist.

Die vorgeschlagene Lösung bietet eine ganze Reihe wesentlicher Vorteile: Zum einen ist jeder Informationsinhalt oder Content (oder auch "Stream") nur ein einziges Mal im Datenbanksystem (nachfolgend auch bezeichnet als SAN = Storage-Area-Network) vorhanden, wodurch der größte Teil der bisher erforderlichen Speicherkapazität eingespart werden kann. Weiterhin ergibt sich eine sehr leichte Skalierbarkeit, indem der Dateianpassungs­ rechner (Transcoder) in Abhängigkeit vom aktuellen Bedarf an Verarbeitungsleistung beliebig oft parallel eingesetzt werden kann.

Desweiteren bietet die Lösung besonders einfache Möglichkeiten der Bedienung über ein Netzwerk-Interface und damit der logi­ schen und physikalischen Separation von vorhandenen Serversys­ temen sowie der unabhängigen Erweiterung der einzelnen Kompo­ nenten (SAN, Server und Transcoder). Schließlich ermöglicht die Lösung universelle Schnittstellen und Bereitstellung der Datei­ en und den Einsatz herkömmlicher Umgebungen zur Bereitstellung von Schnittstellen für die Datenbasis-Anbindung. Die Schnitt­ stellen für die Datenbasis-Anbindung können insbesondere über ODBC-, JDBC-, SQL-, Perl- oder PHB-Umgebungen realisiert wer­ den, die dem Fachmann als solche bekannt sind und daher hier keiner weiteren Erläuterung bedürfen.

In der praktisch bei weitem relevantesten Ausführungsform des Systems erfolgen die Nutzerzugriffe über ein IP-Netz (speziell das Internet), und die Erfassung der Hard- und Softwarespezifi­ kation umfaßt das Auslesen von nutzerseitig bereitgestellten Informationen über eine Serverumgebung auf der Basis eines ent­ sprechenden Standardprotokolls, insbesondere über eine HTTP- Server-Umgebung. Die Hard- und Softwarespezifikationen umfassen in praxi speziell die maximale stabil erreichbare Datenrate bzw. Übertragungsbandbreite für die Übertragung zum jeweiligen Nutzer. Bedeutsam ist weiterhin die Erfassung der Art des Pro­ zessors bzw. Betriebssystems und/oder Browsers, der am Endgerät des Nutzers installiert ist, da die Bereitstellung eines nut­ zerbezogen optimierten Video-Bitstreams auch von diesen Fakto­ ren abhängt.

Bevorzugt ist weiterhin eine Ausführung des Systems, bei der in verschiedenen Speicherbereichen eines Programmspeichers des Da­ tenanpassungsrechners jeweils spezifizierte Anpassungsalgorith­ men für vorbestimmte Hard- und Softwarekonfigurationen gespei­ chert sind. Bei jedem Zugriff wird hierbei insbesondere eine für dessen Dauer gültige, die aktuelle Hard- und Softwarespezi­ fikation des Nutzers reflektierende Nutzer-ID vergeben, über die der Speicherbereich mit dem "passenden" Anpassungsalgorith­ mus adressiert wird.

Die Übertragung des konkreten Video-Bitstreams erfolgt bevor­ zugt über eine von mehreren, jeweils an eine bestimmte Hard- und Softwarespezifikation angepaßten Schnittstellen, welche an­ hand des Erfassungsergebnisses (insbesondere durch Adressierung einer Auswahlrichtung mit der oben erwähnten Nutzer-ID) ausge­ wählt wird.

Aus derzeitiger Sicht wird die Umrechnung der einen in der Da­ tenbasis gespeicherten Primär-Videodatei in die jeweils zu übertragende Sekundär-Videodatei im wesentlichen hardwareba­ siert auszuführen sein - softwarebasierte Lösungen sind aus Gründen der Verarbeitungsgeschwindigkeit eher zur manuellen Um­ setzung einzelner Videostreams oder zum sogenannten Batch- Transcoding von Bedeutung.

Die Systemstruktur kann in einer ersten Ausführungsform so aus­ sehen, daß der Dateianpassungsrechner (Transcoder/Downscaler) mit dem Server für den eigentlichen Netzbetrieb des Distributi­ onssystems (Webserver) integriert ausgeführt ist, während in einer alternativen Ausführungsform beide Komponenten als lo­ gisch und physikalisch getrennte Rechnereinheiten ausgebildet sind. Weiterhin kann eine Mehrzahl von Dateianpassungsrechnern in einem Distributionssystem vorgesehen sein, welche insbeson­ dere in sogenannten Cluster-Lösungen zusammenwirken. Schließ­ lich kann der (oder jeder) Dateianpassungsrechner selbst in ei­ ne Mehrzahl von einzelnen Rechnerkomponenten aufgeteilt sein, um eine optimale Anpassung an die Anforderungen bezüglich der Verarbeitungskapazität zu realisieren.

Vorteile und Zweckmäßigkeiten der Erfindung ergeben sich im üb­ rigen aus den Unteransprüchen sowie der nachfolgenden Beschrei­ bung bevorzugter Ausführungsprinzipien anhand der Figuren. Von diesen zeigen:

Fig. 1 eine schematische Darstellung eines Mediendistributi­ onssystems gemäß dem Stand der Technik,

Fig. 2 eine schematische Darstellung eines Mediendistributi­ onssystems gemäß einer ersten Ausführungsform der Er­ findung,

Fig. 3 eine schematische Darstellung eines Mediendistributi­ onssystems gemäß einer zweiten Ausführungsform der Erfindung,

Fig. 4 eine schematische Darstellung eines Mediendistributi­ onssystems gemäß einer dritten Ausführungsform der Erfindung,

Fig. 5 eine schematische Darstellung eines Mediendistributi­ onssystems gemäß einer vierten Ausführungsform der Erfindung,

Fig. 6 eine schematische Darstellung eines Mediendistributi­ onssystems gemäß einer fünften Ausführungsform der Erfindung,

Fig. 7 eine schematische Darstellung eines Mediendistributi­ onssystems gemäß einer sechsten Ausführungsform der Erfindung und

Fig. 8 eine schematische Darstellung zur Erläuterung eines speziellen Aspekts einer Ausführungsform des erfin­ dungsgemäßen Verfahrens.

Fig. 1 zeigt in einer Prinzipdarstellung ein herkömmliches Me­ diendistributionssystem, bei dem in einem SAN eine Mehrzahl von Videodateien gespeichert ist, die gemäß dem Mpeg1-Standard zur Übertragung in verschiedenen Datenraten zugeschnitten sind. Das SAN ist über ein TCP-IP-Netz mittels eines Webservers mit ver­ schiedenen Nutzern verbunden, für die in der Figur stellvertre­ tend die Nutzer Client 2 Mbit, Client DSL und Client ISDN symbo­ lisch dargestellt sind. Kernstück des Systems ist also eine Da­ tenbank, die, um gleichzeitig verschiedene Datenratenanforde­ rungen erfüllen zu können, ein und denselben Content in einer Mehrzahl von Videodateien speichert und über den Webserver die­ se vorgehaltenen Dateien als Videostreams in den verschiedenen Datenraten ausgibt.

Dem gegenüber gibt es bei dem in Fig. 2 gezeigten erfindungsge­ mäßen System im SAN für jeden Content nur eine einzige Datei, nämlich eine auf die maximale anforderbare Datenrate von 4 Mbit zugeschnittene Mpeg1-Datei. Bei einer Anforderung eines Con­ tents wird die entsprechende Datei aufgerufen und in einem Webserver mit integriertem Downscaler und Transcoder entspre­ chend der Spezifikation des jeweiligen Nutzers umkodiert und dabei auf die Datenratenanforderung des Nutzers herabskaliert. (Falls der Nutzer die im SAN gespeicherte "Maximaldatei" direkt verarbeiten kann und der Webserver dies bei der Erfassung der Hard- und Softwarespezifikation des Nutzers erfaßt hat, erfolgt natürlich eine Übermittlung der gespeicherten Videodatei ohne Transcoding/Downscaling.)

In Fig. 3 ist eine gegenüber Fig. 2 insofern modifizierte Sys­ temkonfiguration dargestellt, als hier die Funktionsbereiche Downscaler/Transcoder einerseits und Webserver andererseits re­ lativ unabhängig voneinander realisiert sind. Dies verbessert - wie weiter oben bereits angemerkt - die Skalierbarkeit des Sys­ tems.

Fig. 4 zeigt eine weiter modifizierte Ausführung, bei der der eigentliche Dateianpassungsrechner (Downscaler und Transcoder) eine vom Webserver logisch und physikalisch völlig getrennte Einheit ist, was die Ausbaumöglichkeiten des Systems weiter verbessert.

In Fig. 5 ist als weiteres Ausführungsbeispiel eine sogenannte Cluster-Lösung dargestellt, bei der - ähnlich dem an sich be­ kannten Distributed-Supercomputing - mehrere Dateianpassungs­ rechner zusammenwirken. Hinsichtlich der logisch und physika­ lisch getrennten Ausführung von Dateianpassungsrechner und Webserver ist diese Variante an die vorbeschriebene Ausführung nach Fig. 4 angelehnt. Mit der Cluster-Lösung läßt sich beson­ ders leicht eine Lastverteilung für den Fall des Ausfalls einer oder mehrerer Transcoder/Downscaler realisieren.

In Fig. 6 ist eine weitere Ausführung dargestellt, bei der die zentrale Verarbeitungseinheit des Mediendistributionssystems neben einem separaten Webserver drei weitere separate Einheiten umfaßt, nämlich einen Demultiplexer, einen Scaler und Trans­ coder und einen Multiplexer. Dieser Aufbau ergibt eine noch hö­ here Skalierbarkeit und präzisere Aufteilung der Verarbeitungs­ leistung auf die verschiedenen Verarbeitungsprozesse bzw. -schritte. Für den Gesamtprozeß lassen sich dadurch sehr hohe symmetrische Prozeßauslastungen erzielen, und die einzelnen Re­ cheneinheiten lassen sich im laufenden Betrieb relativ einfach austauschen, wenn jeweils mehrere parallele Einheiten gleiche Funktion bzw. gleichen Typs vorhanden sind.

Die in Fig. 6 dargestellte Komponenten-Untergliederung ist le­ diglich beispielhaft zu verstehen und stellt einzelne Komponen­ ten einer auch als "Downscaling-Engine" zu bezeichnenden Verar­ beitungseinheit dar, die im wesentlichen die folgenden Verfah­ rensschritte ausführt:

• 1. Erfassen der Client-Daten (System, Browser, Übertragungsge­ schwindigkeit, usw.),
• 2. Selektion (durch Datenbank) des vorliegenden Stream-Systems (Video- und Audio-Daten) im Netzwerk,
• 3. Einlesen des Streams in einen Zwischenspeicher (Buffer),
• 4. Demultiplexung der einzelnen Komponenten (Video- und Audio­ teil, Subtitles usw.) und Extraktion einiger Daten des Sys­ temstreams (Motion Vectors, Color Scales, Timestamps),
• 5. Umrechnung der extrahierten Daten auf die neue Anforderung (Parameter wurden bei der Erfassung der Client-Eigenschaf­ ten ermittelt),
• 6. Herabskalieren der Video- und Audiodaten mit Wiederverwen­ dung einiger Komponenten des ursprünglichen Sytem-Streams,
• 7. Erneutes Multiplexing der System-Stream-Komponenten mit Er­ stellung neuer Timestamps und Ausschreiben in Zwischenspei­ cher,
• 8. Serverseitiges Auslesen und Versenden der Stream-Datenpake­ te.

Hierbei ist zu beachten, daß dieses Verfahren mit einem her­ kömmlichen Dekodierungs-Neukodierungs(Decode-Reencode)-Verfah­ ren nichts gemein hat. In den oben genannten Schritten 4, 5 und 6 wird der Videostream nämlich nicht im eigentlichen Sinne neu kodiert, sondern es findet eine Umrechnung aus dem ursprüngli­ chen Videostream statt. Der hohe Zeitaufwand einer A-priori-Ko­ dierung, bei der die Abhängigkeiten der einzelnen Bilder von­ einander berücksichtigt werden müssen, wird damit vermieden. Es werden hier insbesondere keine Sprungvorhersagen getroffen, um ein folgendes Bild zu einem vorhergehenden Bild in eine mathe­ matisch Abhängigkeit zu bringen. Statt dessen werden gewisse extrahierte Daten aus dem ursprünglichen Videostream weiterver­ wendet, wodurch der Verarbeitungs-Zeitaufwand erheblich redu­ ziert und eine Echtzeitverarbeitung von Videostreams auch mit hohen Datenraten ermöglicht wird.

Dieses Prinzip ist in Fig. 7 schematisch skizziert. Diese Figur ist aufgrund der Beschriftung selbsterklärend, so daß sich wei­ tere Ausführungen dazu hier erübrigen.

In der praktischen Ausführung ist aus derzeitiger Sicht eine Realisierung des Dateianpassungsrechners bzw. der Downscaling- Engine auf einer oder mehreren Einsteckkarte(n), insbesondere für IBM-kompatible Rechner, bevorzugt. Die Einsteckkarte ent­ hält programmierbare Logikbausteine, in denen die Verarbei­ tungsalgorithmen hardwaremäßig implementiert sind. Weiterhin enthält sie - abhängig von der gewünschten Skalierbarkeit und Verfügbarkeit - RISC-Prozessoren mit einer Rechenleistung, die eine Abarbeitung der Algorithmen in höherer Geschwindigkeit als eine Standard-CPU ermöglichen.

In einem einzigen Host-System lassen sich mehrere derartige Downscaling-Engines einbauen und betreiben, und über Cluster- Lösungen wiederum lassen sich mehrere Host-Systeme als eigen­ ständige Transcoder/Downscaler benutzen. Im letzteren Fall ist eine Management-Einheit zur Steuerung der Arbeitsverteilung auf die einzelnen Einheiten vorzusehen. Aus derzeitiger Sicht bie­ tet sich insbesondere eine Realisierung über ein UNIX-System bzw. freie Derivate (Linux o. ä.) an.

Wie in Fig. 8 skizziert, können die einzelnen Stufen der Down­ scaling-Engine auch auf separaten Einsteckkarten realisiert sein. Dargestellt ist eine Ausführung, bei der ein Demultiple­ xer auf einer separaten Karte untergebracht ist und dieser eine Audio-Transcoder-Karte und mehrere verschiedene Video-Transco­ der-Karten versorgt, die auf unterschiedlichen Standards - in der Figur den Standards Mpeg-1, Mpeg-2 und Mpeg-4 - basieren. Die in der Audio-Transcoder-Karte und den Video-Transcoder-Kar­ ten umgewandelten Audio- bzw. Videodaten werden einer wiederum separat ausgeführten Multiplexer-Karte zugeführt, wo sie zum Videostream des jeweiligen Standards zusammengesetzt werden.

Auch hierbei erfolgt eine Umsetzung und Wiederverwendung von gewissen aus der Ursprungs-Videodatei extrahierten Teilen.

Die Ausführung der Erfindung ist nicht auf die oben beschriebe­ nen Beispiele beschränkt, sondern im Rahmen der anhängenden An­ sprüche in einer Vielzahl von Abwandlungen möglich, die im Rah­ men fachgemäßen Handelns liegen.

Claims (19)

1. Verfahren zur Speicherung und Übertragung von als Videoda­ teien ausgebildeten Contents im Rahmen eines digitalen Me­ diendistributionssystems mit einer Datenbasis, auf die ei­ ne Mehrzahl von Nutzern über Datenkanäle und mit Endgerä­ ten mit unterschiedlichen Hard- und Softwarespezifikatio­ nen zugreifen kann, dadurch gekennzeichnet, daß
jeder Content in der Datenbasis genau einmal in Form einer Primär-Videodatei mit maximalem Informationsin­ halt gespeichert wird,
bei jedem Zugriff eines Nutzers die Hard- und Software­ spezifikation von dessen Endgerät und des Datenkanals zu diesem erfaßt und das Erfassungsergebnis einem Steu­ ereingang eines Dateianpassungsrechners zugeführt,
im Dateianpassungsrechner in Echtzeit oder schneller als Echtzeit die Primär-Videodatei in eine an die Hard- und Softwarespezifikation angepaßte Sekundär-Videodatei umgerechnet und
die Sekundär-Videodatei ohne Endspeicherung in der Da­ tenbasis im wesentlichen in Echtzeit an das Endgerät übermittelt wird.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die Nutzerzugriffe über ein IP-Netz erfolgen und die Er­ fassung der Hard- und Softwarespezifikation das Auslesen von nutzerseitig bereitgestellten Informationen über eine Serverumgebung auf der Basis eines Standardprotokolls, insbesondere über eine HTTP-Server-Umgebung, erfolgt.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß als Hard- und Softwarespezifikationen die maximale stabil erreichbare Datenrate bzw. Übertragungsbandbreite für die Übertragung zum Nutzer erfaßt wird.

4. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß als Hard- und Softwarespezifikation die Art des Prozessors und/oder Betriebssystems und/oder Browsers des Endgerätes des Nutzers erfaßt wird.

5. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß bei jedem Zugriff eine für dessen Dauer gültige, die Hard- und Softwarespezifikation reflektierende Nutzer-ID verge­ ben wird, über die ein Speicherbereich eines Programmspei­ chers des Datenanpassungsrechners zum Auslesen eines ge­ speicherten Anpassungsalgorithmus adressiert wird.

6. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß die Übertragung über eine von mehreren, jeweils an eine Hard- und Softwarespezifikation angepaßten Schnittstellen erfolgt, welche anhand des Erfassungsergebnisses, insbe­ sondere durch Adressierung einer Auswahleinrichtung mit der Nutzer-ID, ausgewählt wird.

7. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß Schnittstellen für die Datenbasisanbindung über ODBC-, JDBC-, SQL-, Perl- und PHB-Umgebungen realisiert werden.

8. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß die Umrechnung der Primär-Videodatei in die Sekundär-Vi­ deodatei im wesentlichen hardwarebasiert ausgeführt wird.

9. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, daß
die Primär-Videodatei vor der Umrechnung in einen ers­ ten Pufferspeicher eingelesen wird,
ein Demultiplexen der Komponenten der Primär-Videodatei in Video- und Audiodaten, Untertitel und dergleichen ausgeführt wird,
aus der Pufferspeicher-Kopie ausgewählte Daten des Sys­ temstreams, insbesondere Bewegungsvektoren, Farbskalen­ werte und/oder Zeitmarken extrahiert werden,
die extrahierten Daten auf die erfaßte Hard- und Soft­ warespezifikation umgerechnet werden,
die Video- und Audiodaten, insbesondere unter Wieder­ verwendung ausgewählter Komponenten der Primär-Videoda­ tei, skaliert werden,
ein Multiplexen der skalierten und gegebenenfalls wie­ derverwendeten Komponenten, insbesondere unter Erstel­ lung neuer Zeitmarken, zur Sekundär-Videodatei ausge­ führt und diese in einen zweiten Pufferspeicher einge­ lesen wird und
die Kopie der Primär-Videodatei im ersten Pufferspei­ cher gelöscht wird.

10. Digitales Mediendistributionssystem, insbesondere zur Durchführung des Verfahrens nach einem der vorangehenden Ansprüche, mit einer Datenbasis zur Speicherung von als Videodateien ausgebildeten Contents und einem Server zur Verwaltung der Datenbasis zur Realisierung von Zugriffen durch eine Mehrzahl von Nutzern, dadurch gekennzeichnet, daß
die Datenbasis genau eine Primär-Videodatei jedes Contents enthält und
eine Erfassungseinrichtung zur Erfassung der jeweiligen Hard- und Softwarespezifikation des Endgerätes eines auf die Datenbasis zugreifenden Nutzers und des Datenkanals zu diesem sowie
ein über einen Steuereingang mit dem Ausgang der Erfas­ sungseinrichtung verbundener Dateianpassungsrechner zur Umrechnung einer Primär-Videodatei, auf die ein Nutzer ei­ nen Zugriff wünscht, in eine an die Hard- und Softwarespe­ zifikation seines Endgerätes und Datenkanals angepaßte Se­ kundär-Videodatei im Ansprechen auf das Erfassungsergebnis der Erfassungseinrichtung vorgesehen ist.

11. Mediendistributionssystem nach Anspruch 10, dadurch gekennzeichnet, daß die Erfassungseinrichtung in einer HTTP-Server-Umgebung realisiert ist.

12. Mediendistributionssystem nach Anspruch 10 oder 11, dadurch gekennzeichnet, daß zwischen die Erfassungseinrichtung und den Dateianpas­ sungsrechner eine ID-Zuweisungseinrichtung zur Vergabe ei­ ner die Hard- und Softwarespezifikation reflektierenden, für die Dauer des Zugriffs gültigen Nutzer-ID bei jedem Zugriff geschaltet ist, deren Ausgang mit einem Programm­ speicher des Dateianpassungsrechners verbunden ist derart, daß mit der Nutzer-ID ein Speicherbereich desselben zum Auslesen eines gespeicherten konkreten Anpassungsalgorith­ mus adressierbar ist.

13. Mediendistributionssystem nach einem der Ansprüche 10 bis 12, gekennzeichnet durch eine Mehrzahl von jeweils an eine Hard- und Softwarespezi­ fikation angepaßter Schnittstellen und eine mit der Erfas­ sungseinrichtung verbundene Auswahleinrichtung zur Auswahl einer der Schnittstellen im Ansprechen auf das Erfassungs­ ergebnis.

14. Mediendistributionssystem nach einem der Ansprüche 10 bis 13, gekennzeichnet durch ODBC-, JDB-, SQL-, Perl- und PHB-Umgebungen realisierte Schnittstellen für die Datenbasisanbindung.

15. Mediendistributionssystem nach einem der Ansprüche 10 bis 14, dadurch gekennzeichnet, daß der Dateianpassungsrechner mit dem Server integriert aus­ geführt ist.

16. Mediendistributionssystem nach einem der Ansprüche 10 bis 14, dadurch gekennzeichnet, daß der Dateianpassungsrechner und der Server als logisch und physikalisch getrennte Rechnereinheiten ausgeführt sind.

17. Mediendistributionssystem nach einem der Ansprüche 10 bis 16, gekennzeichnet durch das Vorsehen einer Mehrzahl von Dateianpassungsrechnern, die insbesondere in Cluster-Lösungen zusammenwirken.

18. Mediendistributionssystem nach einem der Ansprüche 10 bis 17, dadurch gekennzeichnet, daß der oder jeder Dateianpassungsrechner in eine Mehrzahl von einzelnen Rechnereinheiten aufgeteilt ist.

19. Mediendistributionssystem nach einem der Ansprüche 10 bis 18, dadurch gekennzeichnet, daß der oder jeder Dateianpassungsrechner zwei Pufferspeicher zur Zwischenspeicherung von Primär-Videodateien bzw. Se­ kundär-Videodateien sowie einen Demultiplexer zum Separie­ ren von Audio-, Video- und weiteren Komponenten von Pri­ mär-Videodateien sowie einen Multiplexer zum Zusammenfüh­ ren von umgerechneten Video-, Audio- und weiteren Kompo­ nenten zu einer Sekundär-Videodatei im Zusammenhang mit der Umrechnung von Primär-Videodateien in Sekundär-Video­ dateien aufweist.