-
Diese
Erfindung betrifft das Gebiet von Computersystemen. Genauer gesagt
wird in einem Medienflußsystem,
in dem ein Medientrack verknüpfte Metadaten
hat, die Zeit-, Offset- und andere Information bereitstellen, eine
Vorrichtung und ein Verfahren bereitgestellt für das Streaming bzw. Strömen eines Medientracks
zu mehreren Clients mit nur einer Kopie der Metadaten des Tracks.
-
Medienstromsysteme
sind dafür
ausgelegt, Medienprogramme und Ereignisse, die vorher aufgezeichnet
sein können
oder live sein können,
zu Clientgeräten
(z. B. Computer, Medienplayer) zu übertragen. Ein Client kann
einen Medienstrom abspielen, wenn er ihn empfängt (d.h. bevor der Strom bzw. die Übertragung
vollständig
ist), wodurch ein schneller oder sogar Echtzeit-Genuß des Medienprogramms oder
Ereignisses ermöglicht
wird.
-
Medien
können
im Unicast- oder Multicastmodus übertragen
werden. Im Unicastmodus hält
der Strömungsserver
eine reservierte Verbindung zu jedem empfangenden Clientgerät, was dem
Nutzer eine weitgehende Steuerung über seinen oder ihren Strom
gewährt.
Er oder sie kann beispielsweise in der Lage sein, einen Strom anzuhalten
oder durch das strömende
Medium zurückzuspulen
oder vorzuspulen oder andere Steuerfunktionen durchzuführen. Dies
kann jedoch zu einer nichteffizienten Verwendung der Bandbreite
bei einer großen
Anzahl von Nutzern führen.
Im Multicastmodus überträgt der Medienstromserver
ein Programm gleichzeitig zu mehreren Benutzern, wodurch weniger
Bandbreite verwendet wird. Dieser Typ der Datenströmung ist
somit vergleichbar des traditionellen Sendens und Nutzer haben wenig
Kontrolle über
ihre individuellen Ströme.
Liveereignisse können
normalerweise im Multicastmodus übertragen
werden, da es effizienter für das
Bedienen großer
Benutzerzahlen ist. Und das es ein Liveereignis ist, das in Echtzeit
genossen wird, gibt es wenig Notwendigkeit, die strömenden Medien zu
manipulieren.
-
Das
IBM Technical Disclosure Bulletin V40/10, Oktober 97, Seiten 123-127
beschreibt die Verwendung von strukturierten Metadaten für anwendungsspezifische
Betrachter für übertragenes
Internetvideo/-audio. Die Navigation und Auswahl für Video
und Audio wird verwirklicht unter Verwendung der Web-Browser-Technologie.
Metadaten werden von einem Anwendungsserver zu einem Client über einen
http-Server zurückgegeben
und veranlassen, daß ein
Video/Audioviewer beim Client gestartet wird. Informationen in den
Metadaten beinhalten die Adresse des Anwendungsservers und den Typ
der Kodierung des Videos/Audios.
-
Geströmte Medien
sind häufig
aus mehreren Tracks bzw. Stücken
oder Dateien zusammengesetzt. Beispielsweise beinhaltet ein audiovisuelles Programm
im Allgemeinen zumindest einen Audiotrack und zumindest einen Videotrack.
Jeder Track beinhaltet Medien des geeigneten Typs (z. B. Audio, Video)
und kann ebenso Metadaten beinhalten, die verwendet werden, um die
Medien korrekt zu übertragen.
Die Metadaten eines Tracks können
Informationen beinhalten für
das Identifizieren eines Mediensegmentes oder eines Mediensample
(oder einer anderen Medieneinheit), die in einem gegebenen Zeitindex
innerhalb des Programms abgespielt werden sollten, für das Bestimmen,
wo das Segment oder das Sample in der Datei lokalisiert ist, usw.
Die Metadaten eines Medientracks können somit von einem Medienströmungsserver
verwendet werden, um den Medientrack in der korrekten Reihenfolge
mit der geeigneten Taktung usw. zu übertragen.
-
Wenn
ein Medientrack oder ein Programm zu mehreren Clients übertragen
wird, speichern existierende Systeme üblicherweise separate Kopien
von den Metadaten jedes Tracks für
jeden Client. Genauer gesagt extrahieren diese Systeme wiederholt
aus einem Medienfile, der das zu übertragende Medium enthält, die
Mediendaten und zwar jedes mal, wenn ein neuer Client die Medien
anfordert, und speichert sie. Wenn eine große Anzahl von Clients bedient wird,
kann dies eine signifikante Menge der Serverressourcen (z. B. Speicher,
Prozessor, Plattenverwendung) erfordern und kann die Anzahl der
Clients, die der Server unterstützen
kann, begrenzen.
-
Einige
bestehende Systeme weisen typischerweise ebenso nur einen Dateideskriptor
zu, der von allen Clients, die einen bestimmten Medienstrom empfangen,
gemeinsam genutzt wird, für
das Zugreifen auf die Mediendatei, die die übertragenen Medien enthält. Dies
kann zu einer erheblichen Konkurrenz zwischen den Clientströmen führen, denn
jeder versucht ein unterschiedliches Mediensegment oder Sample zu
suchen (d.h. zu finden) und zu extrahieren.
-
Weiterhin,
wenn ein Mehrfachtrack-Medienprogramm zu einem Client übertragen
wird, versuchen existierende Medienströmsysteme die Synchronisation
zwischen den Tracks beizubehalten, so daß der geeignete korrespondierende
Medientrack übertragen
oder abgespielt wird für
jede Zeiteinheit des Programms, sie können jedoch nicht in der Lage sein,
die Synchronisierung wiederzuerlangen, wenn sie verloren geht. Wenn
beispielsweise die Medien für
einen Track empfangen werden (z. B. von einer Speichervorrichtung)
mit einer langsameren Geschwindigkeit als die Medien für einen
anderen Track, kann ein existierendes Medienstromsystem einfach
mit Fortfahren, die Medien zu übertragen, selbst
wenn die Tracks mehr und mehr aus der Synchronisation geraten. Andere
Systeme können
einen Medienstrom einfach anhalten, wenn die Synchronisation verloren
geht, ohne zu versuchen, die Situation zu korrigieren.
-
ZUSAMMENFASSUNG
-
Eine
Vorrichtung, ein Verfahren und ein computerlesbares Speichermedium
werden in Übereinstimmung
mit der vorliegenden Erfindung und wie in den Ansprüchen festgelegt
bereitgestellt für
das gemeinsame Verwenden einer Kopie der Metadaten eines Medientracks
für das Übertragen
des Medientracks zu mehreren Clients.
-
In
einer Ausführungsform
wird ein Dateitrack erzeugt, um die Metadaten eines einzelnen Medientracks
zu speichern. Für
ein Medienprogramm, das mehrere Tracks aufweist, wird ein getrennter
Dateitrack für
jeden Track erzeugt. Für
jeden Clientmedienstrom werden getrennte Dateitrackhandhaber errichtet.
Jeder Dateitrackhandhaber fungiert als eine Schnittstelle zwischen
seinem Clientstrom – unterschiedliche
Clientströme
können
bei unterschiedlichen Zeitindizes innerhalb des Mediums sein – und der
einzigen Instanz der Medienmetadaten.
-
BESCHREIBUNG
DER FIGUREN
-
1 ist
ein Blockdiagramm, das einen Server darstellt, der konfiguriert
ist, um Medien in Übereinstimmung
mit einer Ausführungsform
der vorliegenden Erfindung zu übertragen.
-
2 ist
ein Blockdiagramm, das die Verwendung einer einzigen Kopie der Medientrackmetadaten
darstellt, um die Medien zu mehreren Clients zu übertragen und zwar in Übereinstimmung
mit einer Ausführungsform
der Erfindung.
-
3 stellt
eine Konfiguration von Programmobjekten dar, die kooperieren, um
einen Medientrack zu mehreren Clients zu übertragen mit einer einzigen
Kopie der Metadaten des Tracks in Übereinstimmung mit einer Ausführungsform
der vorliegenden Erfindung.
-
4a-4b weisen
ein Flußdiagramm
auf, das ein Verfahren zum Übertragen
eines Medientracks zu mehreren Clients mit einer einzelnen Kopie der
Metadaten des Tracks darstellt in Übereinstimmung mit einer Ausführungsform
der vorliegenden Erfindung.
-
5 stellt
eine Konfiguration von Programmobjekten für das Resynchronisieren von
Medien innerhalb eines Medienstroms dar, in Übereinstimmung mit einer Ausführungsform
der vorliegenden Erfindung.
-
6 ist
ein Flußdiagramm,
das in Übereinstimmung
mit einer Ausführungsform
der vorliegenden Erfindung ein Verfahren zum Redsynchronisieren
von Medien innerhalb eines Medienstroms darstellt.
-
DETAILLIERTE
BESCHREIBUNG
-
Die
Programmumgebung, in der eine vorliegende Ausführungsform der Erfindung ausgeführt wird,
beinhaltet anschaulich einen Allzweckcomputer oder eine spezielle
Vorrichtung, wie z. B. einen Computerserver, der konfiguriert ist,
um Daten- oder Medienströmdienste
Computer- oder Kommunikationseinrichtungen vom praktisch jeder Konfiguration (z.
B. verdrahtet, drahtlos, tragbar, Tischgerät) bereitzustellen. Details
solcher Computer und anderer Geräte
(z. B. Prozessor, Speicher, Datenspeicher, Anzeige) sind bekannt
und können
aus Gründen
der Klarheit weggelassen werden. Weiterhin werden Ausführungsformen
der Erfindung beschrieben sowie sie in einer objektorientierten
Programmierumgebung implementiert sein können. Geeignete Variationen
von Ausführungsformen
können
implementiert werden unter Verwendung von anderen Programmiermodellen
oder Frameworks, die für
den Fachmann selbstverständlich
ist.
-
Es
versteht sich ebenso, daß die
Techniken der vorliegenden Erfindung implementiert sein könnten unter
Verwendung einer Vielzahl von Technologien. Beispielsweise können die
hier beschriebenen Verfahren mittels Software implementiert sein,
die auf einem Computersystem ausgeführt wird, oder sie könnten in
Hardware implementiert sein, die entweder eine Kombination aus Mikroprozessoren
oder anderen speziell konstruierten anwendungsspezifischen Schaltkreisen,
programmierbaren logischen Vorrichtungen oder verschiedenen Kombinationen hiervon,
verwenden. Insbesondere können
die hier beschriebenen Verfahren durch eine Reihe von computerausführbaren
Befehlen, die auf einem Speichermedium abgelegt sind, wie z. B.
eine Trägerwelle,
ein Plattenlaufwerk oder ein computerlesbares Medium, implementiert
sein. Beispielhafte Formen von Trägerwellen können die Formen von elektrischen,
elektromagnetischen oder optischen Signalen einnehmen, die digitale
Datenströme
entlang eines lokalen Netzwerks oder eines öffentlich zugänglichen
Netzwerks wie z. B. das Internet, weiterleiten.
-
In
einer Ausführungsform
der Erfindung wird ein Medien- oder Datenstromserver konfiguriert,
um Medien oder Daten zu mehreren Clients zu übertragen. Ein Medienprogramm
oder – ereignis,
das zu mehreren Clients übertragen
wird, beinhaltet ein oder mehrere Tracks (z. B. Audio, Video), wobei
jeder in ein oder mehreren Mediendateien gespeichert sein kann.
Wenn eine erste Anforderung für
das Medienprogramm empfangen wird, werden die Metadaten des Tracks
abgerufen und in einem Dateitrack abgelegt. Die Metadaten können Informationen
beinhalten betreffend: Taktung (z. B. um die Medien des Tracks mit
anderen Programmtracks zu synchronisieren), Positionen von Mediensegmenten
oder Samples (oder anderen Medieneinheiten) innerhalb einer Mediendatei,
Hierarchien von Medieneinheiten (z. B. Stücke, Samples, die ein Stück aufweisen),
Editiertabellen, usw.
-
Für jeden
Client, zu dem der Medientrack übertragen
wird, werden getrennte Dateitrackhandhaber errichtet, um auf Metadaten
innerhalb des Dateitracks zu referenzieren bzw. zu verweisen. Statt des
Speichern getrennter Kopien der Trackmetadaten für jeden Clientstrom referenziert
somit (z. B. mit Zeigern) jeder Dateitrackhandhaber des Clients
auf den einzelnen Dateitrack, um die Taktstelle abzurufen, Mediensegmente
in einem Medienfile zu lokalisieren, usw. Weiterhin wird jeder Dateitrackhandhaber
einem Dateideskriptor zugewiesen in den Mediendateien des Tracks
für das
Suchen und Abrufen von Medien.
-
Spezielle
Ausführungsformen
der Erfindung werden unten beschrieben sowie sie für das Übertragen
von QuickTime-Medien von einem UNIX-basierten Computersystem, wie
z. B. ein System, das das Solaristm Betriebssystem
vom Sun Microsystems, Inc. ausführt,
implementiert sein Können.
Solche Ausführungsformen
können
für die
Verwendung mit anderen Medientypen und anderen Computersystemen
modifiziert werden, wie sich aus der folgenden Beschreibung ergibt.
-
ANSCHAULICHER
MEDIENSTROMSERVER
-
Ein
Medienstrom erlaubt einem Benutzer Medieninhalte zu empfangen und
zu genießen
ohne warten zu müssen,
bis das gesamte Programm oder die gesamte Präsentation auf sein oder ihr
Clientgerät
runtergeladen ist. Beispielsweise kann ein Benutzer ein vorher aufgezeichnetes
Programm genießen oder
ein Liveereignis in Echtzeit erfahren ohne zu warten, bis das gesamte
Programm empfangen ist.
-
Ein
Medienstromserver nach einer vorliegenden Ausführungsform der Erfindung kann
in einem "Reflektions-Betriebsmodus" arbeiten, indem
der Server einen Medienstrom von einem anderen Stromsystem oder
-server (üblicherweise
im Multicastmodus) empfängt
und die Medien zu einem oder mehreren Benutzern (im Unicast- oder
Multicastmodus) weiterleitet.
-
Das
Strömen
von Echtzeitmedien setzt Schranken für den ausgebenden Server, da
die Lieferung von jedem Einzelbild oder anderer Einheit der Medien
in einer spezifischen Reihenfolge und innerhalb einer bestimmten
Zeitperiode durchgeführt
werden muß.
Somit muß ungeachtet
der Anzahl von Clients, die bedient werden, ein Medienstromserver sich
bemühen,
die Anforderungen für
das Strömen von
Echtzeitmedien zu erfüllen,
so daß die
Dienstqualität
der Benutzer nicht auf ein inakzeptables Niveau fällt. Beispielsweise
wird, ungeachtet des Programmtyps (z. B. live oder vorher aufgezeichnet)
und des Strömungsmodus
(z. B. Unicast oder Multicast) zu übertragende Medien im Allgemeinen
komprimiert, um die Bandbreite zu verringern, die sie beim Transit
verbrauchen, wodurch geholfen wird, die rechtzeitige Lieferung der
Medien zu einem Client sicherzustellen.
-
Ein
Medienstromserver nach einer Ausführungsform der Erfindung ist
konfiguriert, um QuickTime-Medien und/oder andere Medienformen in
einem Unicast- oder Mullticast-Modus über ein proprietäres oder öffentlich
zugängliches
Netzwerk, wie z. B. das Internet zu übertragen. Medienströme werden
formatiert entsprechend einem Satz von Protokollen, der mit dem Übertragungsmedium
kompatibel ist, insbesondere, wenn QuickTime-Medien übertragen
werden, kann der Server konfiguriert sein für RTSP (Real-Time Streaming
Protocol), um die Steuerung des Medienstroms durch einen Client
zu erleichtern, für RTP
(Real-Time Transport Protocol) konfiguriert sein, um den Strom zu
dem Client zu liefern und/oder Medien von einer anderen Quelle zu
empfangen, für RTCP
(Real-Time Transport Control Protocol) konfiguriert sein, um Informationen
betreffend die Stromqualität
zu empfangen oder auszutauschen, für SDP (Session Description
Protocol) konfiguriert sein, um die Medien dem Client zu beschreiben,
usw. Andere Ausführungsformen
können
für andere
Medienprotokolle konfiguriert sein.
-
1 stellt
einen Medienstromserver 102 dar, der konfiguriert ist,
um QuickTime-Medien zu übertragen,
gemäß einer
Ausführungsform
der Erfindung. In 1 bedient der Medienstromserver 102 die
Clients 110, 112. Das Medium, das zu den Clients übertragen
wird, kann ein vorher aufgezeichnetes Programm aufweisen, das von
der Speichervorrichtung 104 abgerufen wird, oder kann ein
Echtzeitprogramm sein, das von dem Server 130 empfangen wird
(z. B. als Teil einer Multicastsendung 130a). Der Medienstromserver 102 kann
somit Liveereignisse (z. B. Konzerte, Nachrichtensendungen, Sportereignisse),
Filme, Dokumentationen, Trainingvideos, Lehrprogramme, usw. übertragen.
-
Die
Medienübertragung
kann mehrere Verbindungen zwischen dem Medienstromserver 102 und
einem Client erfordern. In der in 1 dargestellten
Ausführungsform
ist eine erste Verbindung für
RTSP (z. B. die Verbindung 110a, die Verbindung 112a)
vorgesehen, um es einem Client zu ermöglichen, einen Medienstrom
zu steuern. Insbesondere verwendet ein Client eine RTSP-Verbindung,
um Befehle zu dem Medienstromserver zu senden. Die Medienstrombefehle,
die ein Client zu dem Server in dieser Ausführungsform übermitteln kann, beinhalten Befehle,
wie z. B. Options, um eine Liste von unterstützten Befehlen zu erhalten,
Describe, um dem Server das Medienprogramm zu beschreiben, Setup, um
die gewünschten
Tracks zu identifizieren, die empfangen werden sollen (wobei jeder
Track eine unterschiedliche Medienform haben kann, wie z. B. Video,
Audio, usw.), Play, um einen Medientrack oder Programm abzuspielen,
Pause, um zeitweilig die Übertragung
zu stoppen, Teardown, um einen Strom zu beenden, usw. Somit kann
der Client 110 beispielsweise eine RTSP-Verbindung 110a mit
dem Server 102 errichten und den Describe-Befehl ausgeben,
um eine Beschreibung des Inhalts und der für die Übertragung verfügbaren Tracks
zu empfangen. Der Client 110 kann dann eine Setup-Anforderung für ein oder
mehrere Tracks übertragen.
-
Wenn
ein Client einen Setup-Befehl zu dem Server ausgibt, errichtet der
Server eine RTP-Verbindung
(z. B. Verbindung 110b, Verbindung 112b) und eine
RTCP-Verbindung (z. B. Verbindung 110c, Verbindung 112c)
für den
(die) ausgewählten
Track(s). Wenn der Play-Befehl empfangen wird, startet der Server
mit der Übertragung
der Medienpakete zu dem Client über
die RTP-Verbindung. Und der Server und der Client kann RTCP-Pakete über die RTCP-Verbindung austauschen,
die die Qualität
des Stroms beschreiben. Wenn ein Teardown-Befehl ausgegeben wird,
schließt
der Server die betroffenen Strömungsverbindungen
mit dem ausgebenden Client.
-
Die
verschiedenen Verbindungen, die von dem Mediumstromserver eingesetzt
werden, können TCP
(Transport Control Protocol) Sockets für ein kompatibles Kommunikationsmedium
verwenden, über
das der Server und ein Client kommunizieren (z. B. das Internet).
In anderen Ausführungsformen
der Erfindung können
die Sockets nach einem anderen Protokoll (z. B. http-HyperText Transport
Protocol, FTP-File Transfer Protocol) konfiguriert sein.
-
Wie
bereits beschrieben kann der Medienstromserver 102 von 1 Echtzeit-
oder Livemedien zu Clients übertragen
und kann ebenso voraufgezeichnete Medien übertragen. Weiterhin kann der Medienstromserver
im Reflexionsbetriebsmodus Medien, die er von einer anderen Entität, wie z.
B. ein Liveereignis, eine Videokamera, eine Sendung von einem anderen
Server (z. B. Server 130), usw. empfängt, zu den Clients weiterleiten.
In dieser Situation fungiert der Medienstromserver 102 als
ein Client und empfängt
Medienpakete über
eine RTP-Verbindung, die mit der Entität errichtet ist.
-
Die
Clients 110, 112 sind mit geeigneten Medienplayern
für das
Abspielen der Medien, die von dem Medienstromserver 102 übertragen
wurden, ausgestattet. Für
das QuickTime-Medienströmen können die
Clients einen QuickTime-Player, wie er z. B. von Apple Computer,
Inc. erhältlich
ist, betreiben. Die Client-Rechenvorrichtungen können auf nahezu jedem Betriebssystem
arbeiten, für
das ein geeigneter Medienplayer verfügbar ist (z. B. Solaris, Mac
OS, Windows, Linux). Da Clientvorrichtungen ein relativ niederbandbreitige
Kommunikationsvermögen
haben (z. B. 56 K Modem), können
Medienströme
mit relativ niedrigen Bitraten gesendet werden. Höhere Bitraten
können
natürlich
für stabilere
Clients implementiert werden. Clients können Medien, die zu ihnen übertragen
werden, identifizieren durch Vorlegen einer URL (Uniform Ressource
Locator), eines Dateinamen, eines Programmnamen (z. B. Filmname, Songtitel),
usw.
-
Die
US-Patentanmeldung mit der Nr 20010029548, eingereicht am 06.04.2001
mit dem Titel "Method
and Apparatus for Handling Events Received at a Server Socket" beschreibt eine
Konfiguration des Medienstromservers 102 für das Übertragen von
Medien zu mehreren Clients über
eine begrenzte Anzahl von Kommunikationssockets.
-
STRÖMEN VON
MEDIEN ZU MEHREREN CLIENTS MIT EINEM EINZELNEN DATEITRACK
-
In
einer Ausführungsform
der Erfindung übermittelt
ein Medienstromserver Medien, die von Metadaten begleitet sind,
um den Strömungsprozeß zu erleichtern.
Beispielsweise können
Metadaten für einen
QuickTime Medientrack anzeigen, welche Einheit und welches Stück des Medium
(z. B. Audiosample, Filmsegment) zu einem gegebenen Zeitindex innerhalb
des Programms des Mediums korrespondiert und wo es innerhalb einer
Mediendatei zu finden ist. In dieser Ausführungsform können die
Metadaten einmal zusammengesetzt werden (z. B. aus einem oder mehreren
Mediendateien für
einen gegebenen Medientrack extrahiert), können jedoch verwendet werden,
um das Übertragen
dieses Tracks zu vielen Clients zu erleichtern. Dieses Schema ist
somit effizienter als existierende Übertragungssysteme, in denen
getrennte Kopien der Metadaten für
jeden individuellen Clientstrom zusammengesetzt werden.
-
Die
Mediendaten, sobald sie mit Hilfe der Metadaten extrahiert wurden,
werden in RTP-Pakete plaziert und zu den Clients übertragen.
Die Mediendaten können
für das Übertragen
in nahezu jedem Format, das von einem Client gehandhabt werden kann,
präpariert
sein. Insbesondere können
die Medien in Paketen plaziert sein ohne ihre Kodierung, ihre Komprimierung
oder andere Attribute zu ändern.
-
Anschaulich
gesprochen kann ein Client einen Medienstrom anfordern, der mehrere
Tracks aufweist oder kann individuell spezifische Tracks anfordern.
Jeder Track hat seine eigenen Metadaten und kann als getrennter
Strom zu einem Client gesendet werden (d. h. mehrere Tracks können in
einem einzelnen Strom kombiniert sein, müssen aber nicht). Wie oben
beschrieben wird in einer Ausführungsform der
Erfindung die Medien in RTP-Pakete gesendet, wobei in diesem Fall
die Übertragung
von einem Client über
RTSP-Befehle kontrolliert werden können und die Strömungsqualität kann über RTCP
berichtet werden. In anderen Ausführungsformen der Erfindung
werden andere geeignete Protokolle eingesetzt.
-
Wenn
der Medienstromserver in einem Reflexionsmodus arbeitet, in dem
es Medien (als RTP-Pakete)
von einer Quelle empfängt
und diese zu Clients überträgt, können Metadaten
für die
Medien mit oder vor den Medien empfangen werden.
-
2 stellt
die Verwendung eines einelementigen Dateitracks und mehreren Dateitrackhandhabern
dar, um einen Medientrack zu mehreren Clients zu übertragen
ohne getrennt zu extrahieren oder getrennte Kopien der Metadaten
des Tracks zu erstellen, entsprechend einer Ausführungsform der Erfindung.
-
In
der dargestellten Ausführungsform
beinhaltet das Medienprogramm 200 einen Audiotrack 202 und
einen Viedeotrack 204. Jeder Track beinhaltet seinen angezeigten
Medientyp für
das Programm (z. B. Audio, Video) und Metadaten, die u. a. identifizieren,
welche Medieneinheit (z. B. Audiosample, Videoeinzelbild) zu einem
gegebenen Zeitindex in dem Medienprogramm korrespondiert, identifizieren,
welchem Stück
(z. B. eine Sammlung von Medieneinheiten) eine gegebene Einheit
gehört
oder darin beinhaltet ist, listet die Medieneinheiten innerhalb
eines gegebenen Stückes
auf, identifiziert, wo ein gegebenes Stück oder Medieneinheit innerhalb
der Medienprogrammdatei 200 gespeichert wird, beinhaltet
Editiertabellen, die es Content Tools erlauben, Teile des Tracks
einzufügen
oder zu löschen
ohne den gesamten Track zu kopieren oder zu kompaktieren (z. B.
erlauben sie einen Track zu fragmentieren), usw. Anschaulich werden
der Audiotrack 202 und der Videotrack 204 als
getrennte Dateien (oder Sätze
von Dateien) gespeichert. Alternativ dazu können jedoch unterschiedliche
Typen von Tracks oder Abschnitte von unterschiedlichen Tracktypen
in einer einzelnen Datei abgelegt werden.
-
Die
Metadaten eines Medientracks können innerhalb
der Datei(en), die die Medien des Tracks enthalten, zusammenhängend gespeichert
sein, können über die
Mediendatei(en) des Tracks verteilt sein oder können sogar als ein getrennter
Track abgespeichert sein.
-
In Übereinstimmung
mit dieser Ausführungsform
der Erfindung werden die Metadaten jedes Tracks extrahiert und in
getrennten Dateitracks gespeichert. Die Metadaten für den Audiotrack 202 werden
somit als Dateitrack 212 zusammengesetzt, während die
Metadaten für
den Videotrack 204 in dem Dateitrack 214 gespeichert
werden. Die unterschiedlichen Metadatentypen innerhalb eines Tracks können als
getrennte Tabellen, Listen oder andere Datenstrukturen gespeichert
sein.
-
Für jeden
Client, zu dem ein Track des Medienprogramms übertragen wird, werden getrennte Dateitrackhandhaber
etabliert. Somit wird für
den Client 230a der Dateitrackhandhaber 222a, 224a errichtet
für das
Zugreifen auf die Metadaten des Dateitracks 212 bzw. 214.
In gleicher Weise werden für den
Client 230b auf die Metadaten, die in dem Dateitrack 212 für den Audiotrack 202 gespeichert
sind, durch den Dateitrackhandhaber 222b zugegriffen, während auf
die Metadaten des Dateitracks 214 für den Videotrack 204 über den
Dateitrackhandhaber 224b zugegriffen wird. Anschaulich
beinhaltet jeder Dateitrackhandhaber ein oder mehrere Zeiger oder andere
Referenzen in den verknüpften
Dateitrack, mit dem auf die verschiedenen Informationstypen zugegriffen
wird.
-
Zusätzlich kann
jeder Dateitrackhandhaber oder jeder Satz von Dateitrackhandhabern
für einen gegebenen
Clientstrom einem getrennten Dateideskriptor zugewiesen werden für das Zugreifen
auf die Mediendatei(en), die die Medien des Tracks speichert. Somit
werden in der Ausführungsform
von 2, in der der Audiotrack 202 und der
Videotrack 204 in getrennten Dateien gespeichert werden,
jeder Dateitrackhandhaber 222a, 222b, 224a, 224b seinem
eigenen Dateideskriptor für
das Lokalisieren und Extrahieren von Medien für die Übertragung zugewiesen. Alternativ
dazu kann ein einzelner Dateideskriptor von allen Dateitrackhandhabern,
die mit einem einzelnen Medientrack verknüpft sind, für den Zugriff auf die Datei,
die die Medien des Tracks speichert, gemeinsam genutzt werden.
-
Während die
Medien zu einem Client (z. B. nachdem der Client einen abzuspielenden
Track oder Programm anfordert) übertragen
werden, greifen die Dateitrackhandhaber für den Strom des Clients auf
die Dateitracks zu, um die richtige Abfolge der Medien zu bestimmen
(d.h. die Medieneinheit(en), die für jeden Zeitindex der Medien
zu übertragen
sind). Mit dieser Information extrahieren die Dateitrackhandhaber
die Medien von der (den) Mediendatei(en), so daß sie in RTP-Paketen (oder
Paketen, die gemäß eines
anderen geeigneten Protokolls konfiguriert sind) plaziert werden
können
und zu dem Client über
eine RTP-Verbindung übertragen werden
können.
Wenn ein Client seinen Strom beendet, werden die Dateitrackhandhaber
gelöscht.
-
In
einer Ausführungsform
der Erfindung wird ein Dateitrack konfiguriert, um die Anzahl von
Dateitrackhandhabern, die auf ihn referenzierten, zu überwachen.
In dieser Ausführungsform,
wenn alle Einströme
des betroffenen Medientracks beendet wurden, kann sich der Dateitrack
selbst entfernen und dadurch zusätzliche
Ressourcen für
andere Prozesse oder Medientracks freigeben.
-
3 stellt
verschiedene Programmobjekte dar, die in einer Ausführungsform
der Erfindung eingesetzt werden. Geeignete entsprechende Programmodule,
die konfiguriert sind, um in ähn licher
Weise wie die dargestellten Programmobjekten zu arbeiten, können für Computersystem
mit nichtobjektorientierten Programmierverfahren erzeugt werden.
-
In
dieser Ausführungsform
stellt der Track 302 eine Klasse aus Objekten dar, die
konfiguriert ist, um Metadaten für
einen Medientrack zusammenzustellen und es mehreren Dateitrackhandhabern
zu erlauben, die Metadaten für
verschiedene Clientströme
zu verwenden. Mehrere Typen von Trackobjekten können aus dem Track 302 erzeugt
werden, wie z. B. der Livetrack 320 für das Zusammensetzen von Metadaten
für das Übertragen
von Live- oder Echtzeitereignismedien, und den Dateitrack 322 für das Zusammensetzen
von Metadaten für
gespeicherte oder vorher aufgezeichnete Medien. In einer alternativen Ausführungsform
der Erfindung kann ein Trackobjekttyp (z. B. der Filetrack 322)
konfiguriert sein, um die Übertragung
von sowohl vorher aufgezeichneten als auch Livemedien zu erleichtern.
In noch einer anderen alternativen Konfiguration müssen die
Livemedien nicht in Form von Tracks vorliegen und können somit
Clients in irgendeiner anderen Art und Weise als hier beschrieben
zur Verfügung
gestellt werden.
-
Der
QuickTime-Filetrack 322a und der MPEG-Flietrack 322b stellen
Filetrackobjekte dar, die konfiguriert sind, um Metadaten für zwei spezifische
Medienformen (z. B. QuickTime und MPEG) tu handhaben. Objekte, die
aus dem Track 302 erzeugt wurden, können Attribute und Verfahren übernehmen,
die für
die Handhabung von Livemedien, vorher aufgezeichneten Medien und/oder
anderen Medien nützlich
sind. Unter den übernommenen
Attributen kann beispielsweise eins sein, das einem Zähler von Trackhandhabern
hält, die
auf einen gegebenen Track verweisen.
-
Der
Trackhandhaber 304 stellt eine Objektklasse dar, die konfiguriert
ist, um das Übertragen von
Trackmedien zu einem Client unter Verwendung einer gemeinsam verwendeten
Kollektion von Trackmetadaten erleichtert. Anschaulich gesprochen
stellt der Livetrackhandle 340 (Livetrackhandhaber) eine Klasse
von Trackhandleobjekten dar, die konfiguriert sind für das Übertragen
von Livemedien, während der
Filetrackhandle 342 eine Klasse aus Trackhandleobjekten
darstellt, die konfiguriert ist für vorher aufgezeichnete oder
andere gespeicherte Medien. In einer alternativen Ausführungsform
der Erfindung kann ein Typ des Trackhandhabobjekts (z. B. der Filetrackhandle 342)
konfiguriert sein für
die Übertragung
von sowohl vorher aufgezeichneten als auch Livemedien. Nach einer
anderen alternativen Livekonfiguration müssen die Livemedien nicht die
Form eines Tracks annehmen und können
somit in irgendeiner anderen Art und Weise als hier beschrieben
zu den Clients geliefert werden.
-
Von
dem Filetrackhandle 342 können unterschiedliche Typen
von Filetrackhandleobjekten für spezifische
Medienformen realisiert werden, wie z. B. ein QuickTime Filetrackhandle 342a für QucikTime-Medien
und ein MPEG-Dateitrackhandle 342b für MPEG-Medien.
-
In
dieser Ausführungsform
der Erfindung beinhaltet jedes Trackhandleobjekt, das von dem Trackhandle 304 abgeleitet
ist, geeignete Verfahren für
das sich fortbewegen zu einem bestimmten Zeitindex in einem Medienprogramm
oder Track, das Lesen von Mediendaten in einem Puffer (für das Übertragen
zu einem Client), usw. Somit halten die Trackhandleobjekte die Zustandsinformation
betreffend der gegenwärtigen
Abspielposition eines Clients in einem Medientrack und können einen
oder mehrere Puffer für das
Senden von Medienpaketen zu Clients und einem oder mehrerer Zeiger
oder Referenzen zu ihren entsprechenden Trackobjekten für das Zugreifen
auf die Metadaten beinhalten.
-
Sobald
ein Filetrackobjekt für
einen gegebenen Medientrack errichtet ist, verwenden nachfolgende
Clientanforderungen für
diesen Track den errichteten Filetrack statt die Metadaten des Tracks
erneut zusammenzustellen. Somit können Filetrackobjekte konfiguriert
sein, um neue Filetrackhandleobjekte für neue Clientströme zu realisieren.
-
4 stellt
ein Verfahren zu Bereitstellen von Medienströmen von einem Track zu mehreren Clients
dar, während
nur eine Kopie der Metadaten der Medien beibehalten wird und zwar
entsprechend einer Ausführungsform
der Erfindung. In diesem Verfahren können die selben Medien zu jedem
Client übertragen
werden, jedoch mit einer anderen Taktung. Das heißt, unterschiedliche
Clientströme
können
zu irgendeiner gegebenen Zeit Medien von unterschiedlichen Zeitindizes
innerhalb des Medientracks übertragen.
-
Im
Zustand 402 des dargestellten Verfahrens wird eine Anforderung,
um vorher aufgezeichnete Medien zu übertragen, die nicht bereits übertragen werden,
empfangen. Die Anforderung kann beispielsweise als ein RTSP-Befehl
empfangen werden, um einen bestimmten Medientrack einzustellen und abzuspielen.
Andere Formen von anfordernden Medien können für andere Protokolle oder Medienformen
verwendet werden.
-
Im
Zustand 404 erzeugt der Medienstromserver ein Trackobjekt,
um den gemeinsam genutzten Zugriff auf die angeforderten Metadaten
zu verwalten. Das dargestellte Verfahren zeigt die Erzeugung eines
Filetrackobjekts, das, wie oben beschrieben, für voraufgezeichnete Medienprogramme
und Tracks konfiguriert sein kann.
-
Im
Zustand 406 extrahiert das Filetrackobjekt die Metadaten
von dem Medientrack und speichert sie. Das Filetrackobjekt kann
ein oder mehrere Dateien, die den Medientrack enthalten, zu analysieren
haben, um die Metadaten zusammenzusetzen.
-
Im
Zustand 408 wird ein Filetrackhandle für den neuen Clientstrom erzeugt,
um eine Abbildung oder eine Schnittstelle zwischen dem stromspezifischen
Clientkontext und den trackspezifischen Metadaten, die von dem Filetrackobjekt
gehalten werden, zur Verfügung
zu stellen. Das Filetrackhandleobjekt kann mit einer oder mehreren
Referenzen auf die zusammengesetzten Metadaten (z. B. unterschiedliche Referenzen
für unterschiedliche
Tabellen oder unterschiedliche Metadatentypen) bereitgestellt werden. Zusätzlich wird
dem Filetrackhandle ein Dateideskriptor oder eine ähnliche
Ressource zugewiesen, um seinen Zugriff auf die Datei(en), die die
Medien enthalten (z. B. um zu übertragende
Medien zu finden und zu extrahieren), zu erleichtern.
-
Im
Zustand 410 werden die angeforderten Medien zu dem neuen
Client übertragen.
Der Client kann Befehle ausgeben, um den Strom zu steuern – z. B.
zum schnellen Rücklauf
oder schnellen Vorlauf, um einen bestimmten Teil der Medien zu lokalisieren, um
die Übertragung
anzuhalten, usw.
-
Im
Zustand 412 wird, während
die Medien zu einem oder mehreren Clients übertragen werden, der Medienströmungsserver
bei jeder neuen Anforderung für
die selben Medien alarmiert. Wenn eine neue Anforderung empfangen
wird, kehrt das dargestellte Verfahren zu dem Zustand 408 zurück, um ein neues
Filetrackhandleobjekt und einen neuen Strom einzustellen. Ansonsten
setzt das Verfahren mit Zustand 414 fort.
-
Im
Zustand 414 bestimmt der Medienstromserver, ob alle Clientströme des Medium
beendet wurden. Der Server kann diese Entscheidung fällen, beispielsweise
wenn immer ein Clientstrom beendet wird. Anschaulich, wenn ein Clientstrom
beendet wird, wird sein verknüpftes
Filetrackhandleobjekt gelöscht.
Wenn irgendwelche Ströme
immer noch in Benutzung sind oder errichtet sind, oder wenn neue Ströme gerade
aufgebaut werden, kehrt die Prozedur zurück zu Zustand 410.
Ansonsten setzt die Prozedur mit Zustand 416 fort.
-
Im
Zustand 416 wird, nachdem alle Clientströme beendet
wurden, das Filetrackobjekt gelöscht und
die Metadaten werden aus dem Speicher entfernt.
-
RESYNCHRONISIERUNG DER
MEDIEN WÄHREND
DER ÜBERTRAGUNG
-
Ein
Medienstrom wird als asynchron angesehen, wenn Medien für ein oder
mehrere Tracks in dem Programm oder dem Ereignis, das übertragen wird,
nicht schnell genug übertragen
werden, um mit dem Zeitindex des Stroms Schritt zu halten. Mit anderen
Worten ist ein gegenwärtiger
Zeitindex des übertragenen
Medienprogramms der Zeitindex für
den alle Tracks entsprechende Medien senden sollten. Wenn die Medien
für einen
bestimmten Track hinter dem gegenwärtigen Zeitindex herhinken
oder überhaupt
gar keine Medien für
den Track übertragen werden,
dann kann der Strom als asynchron angesehen werden. Der Verlust
der Synchronisation kann beispielsweise auftreten, wenn eine Quelle
der Medien des Tracks (z. B. eine Speichereinrichtung, eine Livemedienzuführung) die
Medien nicht in einer ausreichend hohen Geschwindigkeit zuführen können.
-
Wenn
die Synchronisation verloren geht, kann ein Medienstromserver versuchen,
den Medienstrom zu resynchronisieren durch Auswählen eines neuen, späteren Medienzeitindex,
zudem die Übertragung
wieder aufgenommen wird. Der Server fordert dann Medien entsprechend
dem neuen Zeitindex an oder wartet auf sie und, bis der neue Zeitindex erreicht
wird, kann der Server die Übertragung
einstellen oder kann mit der Überstragung
von Medien fortsetzen, die gerade übertragen werden (z. B. für einen
Track der immer noch synchronisiert ist).
-
Wenn
der neue Zeitindex erreicht wird, beginnt, wenn die notwendigen
Medien empfangen werden, der Medienstromserver mit der Überstragung
der entsprechenden Medien. Wenn jedoch die Medien, die zu dem neuen
Zeitindex korrespondieren, nicht verfügbar sind, wenn der neue Zeitindex
erreicht wird, unternimmt der Server einen anderen Versuch, um zu
einem anderen späteren
neuen Zeitindex zu resynchonisieren und kann mehr Zeit für das Abrufen
der entsprechenden Medien zulassen. Versuche, einen Medienstrom
zu resynchronisieren, können
mit einer konfigurierbaren Anzahl durchgeführt werden, und der Server
kann den Strom beenden, wenn alle Versuche fehlgeschlagen sind.
-
5 stellt
verschiedene Programmobjekte dar, die zusammenarbeiten können, um
die Resynchronisation eines Medienstroms zu erleichtern. Geeignete
entsprechende Programmodule, die konfiguriert sind, um in ähnlicher
Weise wie die dargestellten Programmobjekte zu arbeiten, können für Computersysteme
errichtet werden unter Verwendung von nichtobjektorientierten Programmierverfahren.
-
In 5 stellt
der TrackStream 502 eine Objektklasse dar, die konfiguriert
ist, um Daten eines Medientracks für das Übertragen zu einem Client zu verarbeiten.
Der LiveTrackStream 520 stellt eine TrackStream-Objektklasse
dar, die konfiguriert ist für das Übertragen
von Livemedien, während
FiletrackStream 522 eine TrackStream-Objektklasse darstellt, die
für voraufge zeichnete
oder andere Medien konfiguriert ist. Ein TrackStream-Objekt kann
Schnittstellen beinhalten für
das Abrufen spezifischer Trackmedien (z. B. für einen spezifizierten Zeitindex).
Im FiletrackStream 522 können verschiedene Typen von
FiletrackStream-Objekten realisiert oder aufgerufen werden für spezifische
Medienformen, wie z. B. der QuickTime-FiletrackStream 522a für QuickTime-Medien
und der MPEG-FiletrackStream 522b für MPEG-Medien.
-
Die
Programmobjekte, die in 5 dargestellt sind, können mit
Objekten zusammenarbeiten, wie z. B. die in Verbindung mit 3 dargestellten und
beschriebenen. Insbesondere kann ein FiletrackStream-Objekt ein
Filetrackhandleobjekt beinhalten oder auf dieses verweisen für das Suchen
spezifischer Orte in einer Mediendatei, das Lesen von Daten von
der Datei, usw.
-
Der
Strom 504 ist eine Abstraktion eines Medienstroms zu einem
Client. Verschiedene Typen von Medienströmen können dargestellt werden, durch beispielsweise
den Livestream 540 für
einen Strom von Livemedien und den Filestream 542 für einen Strom
von vorher aufgezeichneten Medien. Für verschiedene Medienprotokolle
oder Formen, können verschiedene
Typen von Stromobjekten erzeugt werden, um die Übertragung zu handhaben. So
ist in 5 FileRTPStream 542a konfiguriert, um
Medien zu Clients über
RTP zu übertragen,
während
FileHTTPStream 542b konfiguriert ist, um Medien über http
zu übertragen.
-
In
dem dargestellten System beinhaltet jedes Streamobjekt Verfahren,
um einen Medienstrom (z. B. in Antwort auf Befehle eines Clients)
zu starten, zu stoppen, zu unterbrechen und zur anderweitigen Steuerung.
Ein Streamobjekt hat einen oder mehrere Sockets, über die
es mit einem Client kommuniziert, und wechselwirkt mit oder kann
sogar beinhalten ein Trackstreamobjekt, um Mediendaten für die Übertragung
abzurufen. Anschaulich und da ein Medienstrom mehrere Tracks aufweisen
kann, kann jedes Streamobjekt mit mehreren Trackstreamobjekten verknüpft sein
oder diese beinhalten. Falls beispielsweise FileRTPStream 542a erzeugt
wird, um ein grundlegendes audiovisuelles Medienprogramm, das aus
einem Audiotrack und einem Videotrack besteht, zu einem Client zu übertragen,
kann FileRTPStream 542a mit getrennten FiletrackStream-Objekten
für jeden
Track wechselwirken oder diese beinhalten. Wie unten beschrieben,
wenn ein Track mit einem Medienstrom aus der Synchronisation gerät, kann
das Streamobjekt, das die Übertragung
steuert, eine Resynchronisationsprozedur starten.
-
Ein
Client verbindet sich mit einem Medienstromserver, um ein voraufgezeichnetes
Medienprogramm abzurufen und ein Streamobjekt des geeigneten Typs
oder Konfiguration, wie z. B. FileRTPStream 542a wird erzeugt,
um die Übertragung
der Medien zu steuern. FileRTPStream 542a initiiert oder
ruft ein oder mehrere Trackstreamobjekte des geeigneten Typs auf,
wie z. B. den QuickTime-Filetrackstream 542a. Das (die)
Filetrackstreamobjekt(e) erzeugt oder ruft auf einen Track oder
Trackhandleobjekte des geeigneten Typs oder Konfiguration (z. B.
wie in 3 dargestellt), um Medien von dem (den) Track(s)
des Programms abzurufen. Das Streamobjekt steuert die Übertragung
(z. B. starten, stoppen, unterbrechen) und resynchronisiert den
Strom, falls notwendig. Das (die) Trackstreamobjekt(e) steuert (steuern)
das Abrufen der Trackmedien durch Initiieren geeigneter Tasks und/oder
Aufrufen von Schnittstellen, die von dem Track oder den Trackhandleobjekten
bereitgestellt werden (z. B. um Mediendaten zu lokalisieren, Daten
von einem Medienfile zu lesen).
-
6 stellt
die Resynchronisation eines Medienstroms dar. Die in der dargestellten
Prozedur zu übertragenden
Medien sind vorher aufgezeichnet worden und werden daher von ein
oder mehreren Speichervorrichtungen abgerufen, die Prozedur kann jedoch
leicht modifiziert werden von einem Liveereignis oder einem anderen
Server empfangene Livemedien. In Zustand 602 wird ein vorher
aufgezeichnetes Medienprogramm, das mehrere Tracks aufweist, zu einem
Client durch ein zugewiesenes Streamobjekt (z. B. FileRTPStream 542a von 5) übertragen.
-
Im
Zustand 604 wird eine Anforderung gemacht oder terminiert
(z. B. durch den QuickTime-Filetrackstream 522a von 5),
um Mediendaten für einen
der Tracks des Programms von einer Mediendatei zu lesen. Anschaulich
entsprechen die angeforderten Mediendaten einem anstehenden Medienzeitindex
(z. B. Filmzeit). Während
auf die angeforderten Daten gewartet wird, kann das Streamobjekt
Mediendaten übertragen,
die bereits verfügbar
sind (z. B. da sie früher
empfangen wurden), für
den gleichen oder einen anderen Track oder es kann warten bis die
angeforderten Daten verfügbar
sein sollten.
-
Im
Zustand 606 bestimmt das Streamobjekt, ob die angeforderten
Daten verfügbar
sind, oder es kann automatisch geweckt werden oder auf andere Weise
alarmiert werden, wenn die Daten empfangen werden. Wenn die angeforderten
Daten empfangen wurden, kehrt das Verfahren zu Zustand 602 zurück, um die
Mediendaten mit dem geeigneten Medienzeitindex zu übertragen.
Insbesondere, wenn Mediendaten für
die Tracks des Programms in einer zeitlichen Art und Weise empfangen
werden, kann das Streamobjekt die Daten mit dem entsprechenden Medienzeitindex übertragen,
wodurch das Medienprogramm synchron gehalten wird. Wenn das Streamobjekt
im Zustand 606 bestimmt, daß die angeforderten Daten nicht
verfügbar
sind (z. B. eine Speichereinrichtung ist überlastet), was somit einen
Synchronisationsverlust anzeigt, setzt die Prozedur mit Zustand 608 fort.
-
Im
Zustand 608 setzt das Streamobjekt den gegenwärtigen Medienzeitindex
auf einen zukünftigen
Zeitindex hoch und fragt in Zustand 610 Mediendaten, die
zu dem zukünftigen
Index korre spondieren, ab. Somit entscheidet sich in dieser Ausführungsform
der Erfindung der Medienstromserver für das Fallenlassen oder Ignorieren
von Daten, die zu der Medienzeit zwischen dem gegenwärtigen und dem
zukünftigen
Zeitindex korrespondieren. Anschaulich können alle solche Daten (z.
B für einen Track
der Synchronisation nicht verloren hat) verworfen werden. Das Streamobjekt
geht dann in den Ruhezustand oder wartet eine geeignete Zeitdauer
bis die angeforderten Medien empfangen werden. In Zustand 612 bestimmt
das Streamobjekt, ob die Mediendaten, die dem neuen Medienzeitindex
entsprechen, empfangen wurden und für die Übertragung verfügbar sind.
Falls dies der Fall ist, kehrt das Streamobjekt zu dem Zustand 602 zurück, um die
Medien zu übertragen
und den nächsten
Abschnitt der Medien abzurufen.
-
Wenn
jedoch die Mediendaten nicht empfangen werden und für die Übertragung
an dem neuen Zeitindex nicht verfügbar sind, bestimmt im Zustand 614 das
Streamobjekt, ob die Resynchronisierung mehr als eine Grenzzahl
von Versuchen (z. B. 3) fehlgeschlagen hat. Falls nicht, kehrt die
dargestellte Prozedur zu Zustand 608 zurück um den
Medienzeitindex einmal mehr vorzusetzen. Jedes mal, wenn der Zeitindex
vorgesetzt wird, kann er ohne größeren Abschnitt
fortgesetzt werden. Wenn beispielsweise der Zeitindex das erste
Mal um eine Periode T vorgesetzt wird, kann er das nächste mal
um eine Periode 2*T, dann 4*T, 8*T, usw. vorgerückt werden. Wenn die Resynchronisierung
wiederholt mit einer vorbestimmten Anzahl fehlschlägt, hält das Streamobjekt
den Strom an und die Prozedur endet.
-
Der
Fachmann versteht, daß die
in 6 dargestellte Prozedur nur ein Verfahren zum
Resynchronisieren eines Medienstroms durch Fallenlassen von alten
Medien zugunsten der Wiedererlangung der Resynchronisation zu einem
späteren
Zeitindex ist.
-
Die
Mediendatenmenge, die jedes mal angefordert oder abgerufen wird,
kann bestimmt werden teilweise durch die Größe oder die Anzahl von verfügbaren Datenpuffern,
die Frequenz, mit der Datenanforderungen ausgegeben werden, die
Bitrate, mit der die Medien zu einem Client übertragen werden, usw.