DE60121930T2 - Methode zum streamen einer einzelnen medienspur zu mehreren clients - Google Patents

Methode zum streamen einer einzelnen medienspur zu mehreren clients Download PDF

Info

Publication number
DE60121930T2
DE60121930T2 DE60121930T DE60121930T DE60121930T2 DE 60121930 T2 DE60121930 T2 DE 60121930T2 DE 60121930 T DE60121930 T DE 60121930T DE 60121930 T DE60121930 T DE 60121930T DE 60121930 T2 DE60121930 T2 DE 60121930T2
Authority
DE
Germany
Prior art keywords
media
track
metadata
file
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.)
Expired - Lifetime
Application number
DE60121930T
Other languages
English (en)
Other versions
DE60121930D1 (de
Inventor
Geetha Palo Alto SRIKANTAN
Aravind New York NARASIMHAN
Seth Concord PROCTOR
Jan San Francisco BRITTENSON
Matthew San Jose SHAFER
Jonathan Fremont SERGENT
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.)
Sun Microsystems Inc
Original Assignee
Sun Microsystems Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sun Microsystems Inc filed Critical Sun Microsystems Inc
Publication of DE60121930D1 publication Critical patent/DE60121930D1/de
Application granted granted Critical
Publication of DE60121930T2 publication Critical patent/DE60121930T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • 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/1066—Session management
    • H04L65/1101—Session protocols
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/564—Enhancement of application control based on intercepted application data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Description

  • 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.

Claims (16)

  1. Verfahren für das Streaming bzw. den Fluß von Medien zu mehreren Clients (110, 112), das aufweist: Empfangen einer Anforderung, um Medien von einem Medientrack zu einem ersten Client zu liefern, Extrahieren eines Satzes von Metadaten von dem Medientrack, wobei die Metadaten die Identifikation und das Abrufen der Medien von dem Medientrack erleichtern, Speichern des extrahierten Satzes von Metadaten in einem Speicher, Streaming bzw. Fließen der Medien zu einem ersten Client in einem ersten Strom unter Verwendung eines ersten Dateitrackhandhabers (222a), um auf die gespeicherten Metadaten zuzugreifen, und Strömen der Medien zu einem zweiten Client in einem zweiten Strom unter Verwendung eines zweiten Dateitrack- bzw. Dateistückhandhabers (222b), um auf die gespeicherten Metadaten zuzugreifen.
  2. Verfahren nach Anspruch 1, das weiterhin aufweist: Beibehalten eines ersten Dateideskriptors, der dem ersten Dateitrackhandhaber zugewiesen ist, für das Abrufen der Medien von dem Medientrack für den ersten Strom, und Beibehalten eines zweiten Dateideskriptors, der dem zweiten Dateitrackhandhaber zugewiesen ist, für das Abrufen der Medien von dem Medientrack für den zweiten Strom.
  3. Verfahren nach Anspruch 1 oder 2, das weiterhin aufweist: Erzeugen eines Dateitracks (212), um eine Kopie der gespeicherten Metadaten im Speicher abzulegen, und Empfangen einer zweiten Anforderung, um die Medien zu dem zweiten Client fließen zu lassen, bevor der Fluß der Medien zu dem ersten Client beendet wird, wobei das Fließen der Medien zu dem zweiten Client durchgeführt wird in Antwort auf die zweite Anforderung.
  4. Verfahren nach Anspruch 3, wobei das Fließen bzw. Strömen der Medien zu dem ersten Client aufweist: Errichten bzw. Erstellen eines ersten Referenzsatzes auf die Metadaten, Verwenden des ersten Satzes von Referenzen, um einen ersten Abschnitt der Medien zu identifizieren, die zu dem ersten Client fließen sollen, für einen ersten Zeitindex, und Verwenden des ersten Satzes von Referenzen, um den ersten Medienabschnitt in dem Medientrack zu lokalisieren.
  5. Verfahren nach Anspruch 4, bei dem das Fließen der Medien zu dem zweiten Client aufweist: Errichten eines zweiten Satzes von Referenzen zu den Metadaten, Verwenden des zweiten Satzes von Referenzen, um einen zweiten Medienabschnitt zu identifizieren, der zu dem zweiten Client fließen soll, für einen zweiten Zeitindex, und Verwenden des zweiten Satzes von Referenzen, um den zweiten Medienabschnitt in dem Medientrack zu lokalisieren.
  6. Verfahren nach Anspruch 5, bei dem der erste Satz von Referenzen und der zweite Satz von Referenzen verwendet werden, um gleichzeitig auf die Metadaten zuzugreifen.
  7. Verfahren nach einem der vorherigen Ansprüche, das weiterhin aufweist: Entfernen der Metadaten aus dem Speicher, nachdem der erste Strom und der zweite Strom beendet wurden.
  8. Verfahren nach einem der vorherigen Ansprüche, wobei der Medientrack ein Track eines Live-Ereignisses ist.
  9. Verfahren nach einem der Ansprüche 1 bis 7, bei dem der Medientrack ein Track eines vorher aufgezeichneten Medienprogramms ist.
  10. Computerlesbares Speichermedium, das ein Programm speichert, das, wenn es von einem Computer ausgeführt wird, den Computer dazu veranlaßt, ein Verfahren zum Fließen von Medien zu mehreren Clients durchzuführen, wie es in einem der vorherigen Ansprüche beansprucht ist.
  11. Vorrichtung für das Strömen bzw. Streaming von Medien zu Clients (110, 112), die aufweist: einen ersten Track eines Medienprogramms, das auf einer ersten Speichervorrichtung gespeichert ist, wobei der erste Medientrack aufweist: Medien und Metadaten, die konfiguriert sind, um den Zugriff auf die Medien zu erleichtern, einen ersten Speicher, einen Dateitrack (212), der konfiguriert ist, um die Metadaten in dem ersten Speicher für den gemeinsamen Zugriff zu speichern, einen Satz von Dateitrackhandhabern (222a, b), wobei jeder der Dateitrackhandhaber konfiguriert ist, um unter Verwendung des Dateitracks auf die gespeicherten Metadaten zuzugreifen, um das Fließen der Medien zu einem anderen Client zu erleichtern, und wobei die Dateitrackhandhaber auf die gespeicherten Metadaten zugreifen, um Abschnitte der Medien zu identifizieren und die Abschnitte auf der ersten Speichervorrichtung zu lokalisieren.
  12. Vorrichtung nach Anspruch 11, wobei jeder der Dateitrackhandhaber einem getrennten Dateideskriptor zugewiesen ist, für das Abrufen der Medien von der ersten Speichervorrichtung.
  13. Vorrichtung nach Anspruch 11, bei der jeder der Dateitrackhandhaber in der Lage ist, gleichzeitig auf die gespeicherten Metadaten in dem ersten Speicher zuzugreifen.
  14. Vorrichtung nach Anspruch 13, wobei der gleichzeitige Zugriff auf die gespeicherten Metadaten konfiguriert ist, um unterschiedliche Abschnitte der Medien zu identifizieren.
  15. Vorrichtung nach Anspruch 11, wobei die Medienabschnitte mit Zeitindizes innerhalb des ersten Medientracks verknüpft sind und die gespeicherten Metadaten konfiguriert sind, um für einen gegebenen Zeitindex den verknüpften Medienabschnitt zu identifizieren.
  16. Vorrichtung nach Anspruch 15, bei der die gespeicherten Metadaten weiterhin konfiguriert sind, um für einen gegebenen Medienabschnitt einen Ort auf der ersten Speichervorrichtung zu identifizieren, an dem der gegebene Medienabschnitt gespeichert ist.
DE60121930T 2000-04-08 2001-04-06 Methode zum streamen einer einzelnen medienspur zu mehreren clients Expired - Lifetime DE60121930T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US19575500P 2000-04-08 2000-04-08
US195755P 2000-04-08
PCT/US2001/011137 WO2001077870A2 (en) 2000-04-08 2001-04-06 Method of streaming a single media track to multiple clients

Publications (2)

Publication Number Publication Date
DE60121930D1 DE60121930D1 (de) 2006-09-14
DE60121930T2 true DE60121930T2 (de) 2007-07-26

Family

ID=22722659

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60121930T Expired - Lifetime DE60121930T2 (de) 2000-04-08 2001-04-06 Methode zum streamen einer einzelnen medienspur zu mehreren clients

Country Status (6)

Country Link
US (1) US7073191B2 (de)
EP (1) EP1273152B1 (de)
JP (1) JP4640723B2 (de)
AU (1) AU2001251353A1 (de)
DE (1) DE60121930T2 (de)
WO (1) WO2001077870A2 (de)

Families Citing this family (121)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7301944B1 (en) * 1997-10-24 2007-11-27 Tranz-Send Broadcasting Network, Inc. Media file distribution with adaptive transmission protocols
US7068729B2 (en) 2001-12-21 2006-06-27 Digital Fountain, Inc. Multi-stage code generator and decoder for communication systems
US6307487B1 (en) 1998-09-23 2001-10-23 Digital Fountain, Inc. Information additive code generator and decoder for communication systems
FI112307B (fi) * 2000-08-02 2003-11-14 Nokia Corp Viestintäpalvelu
CA2489324A1 (en) * 2000-09-11 2003-12-24 Agami Systems, Inc. Storage system having partitioned migratable metadata
US7478164B1 (en) 2001-06-12 2009-01-13 Netapp, Inc. Methods and apparatus for pacing delivery of streaming media data
US7155531B1 (en) 2001-06-12 2006-12-26 Network Appliance Inc. Storage methods and apparatus for streaming media data
US6813690B1 (en) * 2001-06-12 2004-11-02 Network Appliance, Inc. Caching media data using content-sensitive identifiers
US7149750B2 (en) * 2001-12-19 2006-12-12 International Business Machines Corporation Method, system and program product for extracting essence from a multimedia file received in a first format, creating a metadata file in a second file format and using a unique identifier assigned to the essence to access the essence and metadata file
US7386627B1 (en) 2002-01-29 2008-06-10 Network Appliance, Inc. Methods and apparatus for precomputing checksums for streaming media
KR100900968B1 (ko) * 2002-03-23 2009-06-04 삼성전자주식회사 사용자 선택 광고를 제공하는 스트리밍 서비스 제공 방법 및 멀티미디어 서버
KR20020057837A (ko) * 2002-03-29 2002-07-12 문의선 스트리밍 서비스 방법 및 장치
JP2005526452A (ja) * 2002-05-17 2005-09-02 コーニンクレッカ　フィリップス　エレクトロニクス　エヌ　ヴィ 品質駆動するストリーミング方法及び装置
US9240810B2 (en) 2002-06-11 2016-01-19 Digital Fountain, Inc. Systems and processes for decoding chain reaction codes through inactivation
US8117328B2 (en) * 2002-06-25 2012-02-14 Microsoft Corporation System and method for automatically recovering from failed network connections in streaming media scenarios
US7043559B2 (en) * 2002-06-27 2006-05-09 Seiko Epson Corporation System for distributing objects to multiple clients
MXPA05001292A (es) * 2002-08-01 2005-04-28 Gen Instrument Corp Metodo y aparato para integrar trafico sin protocolo de internet y de protocolo de internet en una red domestica.
US7120751B1 (en) 2002-08-09 2006-10-10 Networks Appliance, Inc. Dynamic streaming buffer cache algorithm selection
KR101143282B1 (ko) 2002-10-05 2012-05-08 디지털 파운튼, 인크. 연쇄 반응 코드의 체계적 인코딩 및 디코딩
GB2394611A (en) * 2002-10-21 2004-04-28 Sony Uk Ltd Metadata generation providing a quasi-unique reference value
KR100494432B1 (ko) * 2002-12-26 2005-06-10 (주)씨앤에스 테크놀로지 비디오서버와 클라이언트간 패킷데이터 처리방법
US7991905B1 (en) 2003-02-12 2011-08-02 Netapp, Inc. Adaptively selecting timeouts for streaming media
US8977763B1 (en) * 2003-04-25 2015-03-10 Aol Inc. Systems and methods for distributing streams and stream metadata
CN101834610B (zh) * 2003-10-06 2013-01-30 数字方敦股份有限公司 通过通信信道接收从源发射的数据的方法和装置
US20050102371A1 (en) * 2003-11-07 2005-05-12 Emre Aksu Streaming from a server to a client
US7519274B2 (en) 2003-12-08 2009-04-14 Divx, Inc. File format for multiple track digital data
US8472792B2 (en) 2003-12-08 2013-06-25 Divx, Llc Multimedia distribution system
US8412763B2 (en) * 2006-06-21 2013-04-02 Apple Inc. Podcast organization and usage at a computing device
US8516035B2 (en) 2006-06-21 2013-08-20 Apple Inc. Browsing and searching of podcasts
US7720983B2 (en) * 2004-05-03 2010-05-18 Microsoft Corporation Fast startup for streaming media
KR101205758B1 (ko) 2004-05-07 2012-12-03 디지털 파운튼, 인크. 파일 다운로드 및 스트리밍 시스템
WO2006020826A2 (en) * 2004-08-11 2006-02-23 Digital Fountain, Inc. Method and apparatus for fast encoding of data symbols according to half-weight codes
US7752325B1 (en) 2004-10-26 2010-07-06 Netapp, Inc. Method and apparatus to efficiently transmit streaming media
US7787974B2 (en) 2005-01-05 2010-08-31 Verint Americas Inc. Independent source recording
US8935313B2 (en) * 2005-02-23 2015-01-13 Cisco Technology, Inc. Quick session setup for video on demand with information caching
CN100403688C (zh) * 2005-04-04 2008-07-16 华为技术有限公司 一种业务数据包跟踪实现方法
US7496678B2 (en) * 2005-05-11 2009-02-24 Netapp, Inc. Method and system for unified caching of media content
US7917612B2 (en) * 2005-05-25 2011-03-29 Oracle International Corporation Techniques for analyzing commands during streaming media to confirm delivery
US7783635B2 (en) 2005-05-25 2010-08-24 Oracle International Corporation Personalization and recommendations of aggregated data not owned by the aggregator
US8365306B2 (en) * 2005-05-25 2013-01-29 Oracle International Corporation Platform and service for management and multi-channel delivery of multi-types of contents
US8068515B2 (en) * 2005-06-22 2011-11-29 Cisco Technology, Inc. Faster multimedia synchronization of broadcast streams using router caching of RTCP packets
US20070044090A1 (en) * 2005-08-22 2007-02-22 Bea Systems, Inc. Packaging of EPCIS software
US20070044089A1 (en) * 2005-08-22 2007-02-22 Bea Systems, Inc. Packaging of RFID software at edge server
US20070044091A1 (en) * 2005-08-22 2007-02-22 Bea Systems, Inc. RFID edge server with in process JAVA connector to connect to legacy systems
US20070043834A1 (en) * 2005-08-22 2007-02-22 Bea Systems, Inc. Store and forward messaging from RFID edge server
US7805499B2 (en) * 2005-08-22 2010-09-28 Bea Systems, Inc. RFID edge server with security WSRM
US7495568B2 (en) * 2005-08-22 2009-02-24 Bea Systems, Inc. JMX administration of RFID edge server
US7660890B2 (en) * 2005-08-22 2010-02-09 Bea Systems, Inc. RFID edge server with socket multiplexing
US7835954B2 (en) * 2005-08-22 2010-11-16 Bea Systems, Inc. Event boxcarring of RFID information sent from RFID edge server
US20070093170A1 (en) * 2005-10-21 2007-04-26 Yu Zheng Interactive toy system
US20080305873A1 (en) * 2005-10-21 2008-12-11 Zheng Yu Brian Universal Toy Controller System And Methods
US20080153594A1 (en) * 2005-10-21 2008-06-26 Zheng Yu Brian Interactive Toy System and Methods
US8469766B2 (en) * 2005-10-21 2013-06-25 Patent Category Corp. Interactive toy system
US7808385B2 (en) * 2005-10-21 2010-10-05 Patent Category Corp. Interactive clothing system
US20080303787A1 (en) * 2005-10-21 2008-12-11 Zheng Yu Brian Touch Screen Apparatus And Methods
US20080300061A1 (en) * 2005-10-21 2008-12-04 Zheng Yu Brian Online Interactive Game System And Methods
US8157611B2 (en) * 2005-10-21 2012-04-17 Patent Category Corp. Interactive toy system
US8285784B2 (en) * 2005-11-08 2012-10-09 Alcatel Lucent Service creation via presence messaging
CN101686107B (zh) 2006-02-13 2014-08-13 数字方敦股份有限公司 使用可变fec开销和保护周期的流送和缓冲
TWI289387B (en) * 2006-02-17 2007-11-01 Hon Hai Prec Ind Co Ltd Wireless network multicasting system and method
US9270414B2 (en) 2006-02-21 2016-02-23 Digital Fountain, Inc. Multiple-field based code generator and decoder for communications systems
JP5200204B2 (ja) 2006-03-14 2013-06-05 ディブエックス リミテッド ライアビリティー カンパニー 高信頼性システムを含む連合型デジタル権限管理機構
US8170395B2 (en) * 2006-05-07 2012-05-01 Wellcomemat Llc Methods and systems for handling montage video data
WO2007134196A2 (en) 2006-05-10 2007-11-22 Digital Fountain, Inc. Code generator and decoder using hybrid codes
US20070281606A1 (en) * 2006-05-30 2007-12-06 Baunach Jeremiah J Systems and methods for acquiring songs or products associated with radio broadcasts
TW200745872A (en) * 2006-06-05 2007-12-16 Doublelink Technology Inc Method of accomplishing multicast distant real-time streaming for video transmissions and storing bottlenecks by reflector
US9380096B2 (en) 2006-06-09 2016-06-28 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
US9386064B2 (en) 2006-06-09 2016-07-05 Qualcomm Incorporated Enhanced block-request streaming using URL templates and construction rules
US9432433B2 (en) 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
KR101251193B1 (ko) * 2006-06-09 2013-04-08 삼성전자주식회사 ＰｏＣ 시스템에서 그룹 세션을 개설하기 위한 방법 및 시스템
US9419749B2 (en) 2009-08-19 2016-08-16 Qualcomm Incorporated Methods and apparatus employing FEC codes with permanent inactivation of symbols for encoding and decoding processes
US9178535B2 (en) 2006-06-09 2015-11-03 Digital Fountain, Inc. Dynamic stream interleaving and sub-stream based delivery
US9209934B2 (en) 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
US7966362B2 (en) * 2006-06-21 2011-06-21 Apple Inc. Management of podcasts
US8560463B2 (en) 2006-06-26 2013-10-15 Oracle International Corporation Techniques for correlation of charges in multiple layers for content and service delivery
US9015782B2 (en) * 2006-06-30 2015-04-21 Alcatel Lucent Signal distribution system with interrupt processing and trick play functionality
US20080032275A1 (en) * 2006-07-21 2008-02-07 Yu Zheng Interactive system
US20080032276A1 (en) * 2006-07-21 2008-02-07 Yu Zheng Interactive system
EP4184341A1 (de) 2007-01-05 2023-05-24 DivX, LLC Videoverteilungssystem mit progressiver wiedergabe
US7844723B2 (en) * 2007-02-13 2010-11-30 Microsoft Corporation Live content streaming using file-centric media protocols
US7909697B2 (en) * 2007-04-17 2011-03-22 Patent Catefory Corp. Hand-held interactive game
US20080288870A1 (en) * 2007-05-14 2008-11-20 Yu Brian Zheng System, methods, and apparatus for multi-user video communications
US20080288989A1 (en) * 2007-05-14 2008-11-20 Zheng Yu Brian System, Methods and Apparatus for Video Communications
KR101451239B1 (ko) * 2007-08-13 2014-10-15 삼성전자 주식회사 미디어 파일 포맷에서 메타데이터의 생성 방법, 접근 방법및 그 장치
JP5027305B2 (ja) 2007-09-12 2012-09-19 デジタル ファウンテン， インコーポレイテッド 信頼できる通信を可能にするためのソース識別情報の生成および伝達
WO2009065137A1 (en) 2007-11-16 2009-05-22 Divx, Inc. Hierarchical and reduced index structures for multimedia files
US8926395B2 (en) * 2007-11-28 2015-01-06 Patent Category Corp. System, method, and apparatus for interactive play
US20090249222A1 (en) * 2008-03-25 2009-10-01 Square Products Corporation System and method for simultaneous media presentation
US8392505B2 (en) * 2008-09-26 2013-03-05 Apple Inc. Collaborative playlist management
US9281847B2 (en) 2009-02-27 2016-03-08 Qualcomm Incorporated Mobile reception of digital video broadcasting—terrestrial services
CN101888540B (zh) * 2009-05-13 2012-09-05 中兴通讯股份有限公司 一种在流媒体文件中承载ts流的方法及装置
US9288010B2 (en) 2009-08-19 2016-03-15 Qualcomm Incorporated Universal file delivery methods for providing unequal error protection and bundled file delivery services
US9917874B2 (en) 2009-09-22 2018-03-13 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
EP2507995A4 (de) 2009-12-04 2014-07-09 Sonic Ip Inc Systeme und verfahren zum transport eines kryptographischen materials für elementare bitströme
US9374231B2 (en) * 2010-03-22 2016-06-21 Alcatel Lucent Controller providing gradual transition of multiple terminals from unicast transmission
US8782173B2 (en) 2010-03-23 2014-07-15 International Business Machines Corporation Auditable distribution of a data file
US9485546B2 (en) 2010-06-29 2016-11-01 Qualcomm Incorporated Signaling video samples for trick mode video representations
US8918533B2 (en) 2010-07-13 2014-12-23 Qualcomm Incorporated Video switching for streaming video data
US9185439B2 (en) 2010-07-15 2015-11-10 Qualcomm Incorporated Signaling data for multiplexing video components
US9596447B2 (en) 2010-07-21 2017-03-14 Qualcomm Incorporated Providing frame packing type information for video coding
US8806050B2 (en) 2010-08-10 2014-08-12 Qualcomm Incorporated Manifest file updates for network streaming of coded multimedia data
US20120173749A1 (en) * 2011-01-03 2012-07-05 Kunal Shah Apparatus and Method for Providing On-Demand Multicast of Live Media Streams
US9247312B2 (en) 2011-01-05 2016-01-26 Sonic Ip, Inc. Systems and methods for encoding source media in matroska container files for adaptive bitrate streaming using hypertext transfer protocol
US8958375B2 (en) 2011-02-11 2015-02-17 Qualcomm Incorporated Framing for an improved radio link protocol including FEC
US9270299B2 (en) 2011-02-11 2016-02-23 Qualcomm Incorporated Encoding and decoding using elastic codes with flexible source block mapping
KR101703931B1 (ko) * 2011-05-24 2017-02-07 한화테크윈 주식회사 감시 시스템
US9467708B2 (en) 2011-08-30 2016-10-11 Sonic Ip, Inc. Selection of resolutions for seamless resolution switching of multimedia content
US9253233B2 (en) 2011-08-31 2016-02-02 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive HTTP streaming
US8806188B2 (en) 2011-08-31 2014-08-12 Sonic Ip, Inc. Systems and methods for performing adaptive bitrate streaming using automatically generated top level index files
US8909922B2 (en) 2011-09-01 2014-12-09 Sonic Ip, Inc. Systems and methods for playing back alternative streams of protected content protected using common cryptographic information
US9843844B2 (en) 2011-10-05 2017-12-12 Qualcomm Incorporated Network streaming of media data
US8842840B2 (en) 2011-11-03 2014-09-23 Arvind Gidwani Demand based encryption and key generation and distribution systems and methods
US9294226B2 (en) 2012-03-26 2016-03-22 Qualcomm Incorporated Universal object delivery and template-based file delivery
US10055491B2 (en) * 2012-12-04 2018-08-21 Sonos, Inc. Media content search based on metadata
US9191457B2 (en) 2012-12-31 2015-11-17 Sonic Ip, Inc. Systems, methods, and media for controlling delivery of content
CN113259731B (zh) 2015-01-06 2023-07-04 帝威视有限公司 用于编码内容和在设备之间共享内容的系统和方法
KR101916022B1 (ko) * 2015-10-06 2018-11-07 한국전자통신연구원 세그먼트 기반의 방송 콘텐츠 반복 전송 방법 및 장치
CN106454635B (zh) * 2016-11-16 2020-04-24 深圳Tcl数字技术有限公司 多声道无线音箱之间数据同步的方法及系统
US10719548B2 (en) 2018-10-15 2020-07-21 Navarr Enterprises Inc. Method for territorial filtering, streaming, and downloading media files over a client-server network with local read-write execution capabilities
CN111859028A (zh) * 2019-04-30 2020-10-30 伊姆西Ip控股有限责任公司 创建用于流式存储的索引的方法、设备和计算机程序产品
US10924636B1 (en) * 2020-04-30 2021-02-16 Gopro, Inc. Systems and methods for synchronizing information for videos

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0529864B1 (de) 1991-08-22 2001-10-31 Sun Microsystems, Inc. Netzwerkvideoanbietergerät und-verfahren
DE69428186T2 (de) * 1994-04-28 2002-03-28 Hewlett Packard Co Mehrfachsendeeinrichtung
US5737531A (en) 1995-06-27 1998-04-07 International Business Machines Corporation System for synchronizing by transmitting control packet to omit blocks from transmission, and transmitting second control packet when the timing difference exceeds second predetermined threshold
US5751280A (en) 1995-12-11 1998-05-12 Silicon Graphics, Inc. System and method for media stream synchronization with a base atom index file and an auxiliary atom index file
US6064379A (en) 1996-06-24 2000-05-16 Sun Microsystems, Inc. System and method for synchronizing presentation of media stream playlists with real time
US5936632A (en) * 1996-07-26 1999-08-10 Hewlett-Packard Co. Method for fast downloading of textures to accelerated graphics hardware and the elimination of extra software copies of texels
JPH10254755A (ja) * 1997-03-14 1998-09-25 Fujitsu Ltd 永続オブジェクトシステム、永続オブジェクトの共有方法及び永続オブジェクトデータの更新方法
US5892915A (en) * 1997-04-25 1999-04-06 Emc Corporation System having client sending edit commands to server during transmission of continuous media from one clip in play list for editing the play list
US6029194A (en) * 1997-06-10 2000-02-22 Tektronix, Inc. Audio/video media server for distributed editing over networks
US6744763B1 (en) * 1998-01-15 2004-06-01 Apple Computer, Inc. Method and apparatus for media data transmission
US7653923B2 (en) * 2000-02-18 2010-01-26 Prime Research Alliance E, Inc. Scheduling and presenting IPG ads in conjunction with programming ads in a television environment
US20010049620A1 (en) * 2000-02-29 2001-12-06 Blasko John P. Privacy-protected targeting system
US7159233B2 (en) * 2000-01-28 2007-01-02 Sedna Patent Services, Llc Method and apparatus for preprocessing and postprocessing content in an interactive information distribution system
US6857130B2 (en) * 2000-04-08 2005-02-15 Sun Microsystems, Inc. Resynchronizing media during streaming
US20020178445A1 (en) * 2001-04-03 2002-11-28 Charles Eldering Subscriber selected advertisement display and scheduling
US20020178447A1 (en) * 2001-04-03 2002-11-28 Plotnick Michael A. Behavioral targeted advertising

Also Published As

Publication number Publication date
WO2001077870A3 (en) 2002-05-16
EP1273152A2 (de) 2003-01-08
DE60121930D1 (de) 2006-09-14
JP4640723B2 (ja) 2011-03-02
JP2003530745A (ja) 2003-10-14
WO2001077870A2 (en) 2001-10-18
EP1273152B1 (de) 2006-08-02
US7073191B2 (en) 2006-07-04
US20020056126A1 (en) 2002-05-09
AU2001251353A1 (en) 2001-10-23

Similar Documents

Publication Publication Date Title
DE60121930T2 (de) Methode zum streamen einer einzelnen medienspur zu mehreren clients
US6857130B2 (en) Resynchronizing media during streaming
DE69633578T2 (de) Verfahren und Vorrichtung zum rastergenauen Zugriff auf digitale audiovisuelle Information
DE69812994T9 (de) Verfahren und vorrichtung für nicht-sequentiellen zugang zu einem laufenden videoprogramm
DE602005003471T2 (de) Verfahren und system zur interaktiven steuerung von medien über ein netzwerk
US8332530B2 (en) User interface including concurrent display of video program, histogram, and transcript
US7290057B2 (en) Media streaming of web content data
DE69837726T2 (de) Verfahren und Vorrichtung zum Realisieren einer nahtlosen Wiedergabe von kontinuierlichen Medien-Zuführungen
DE602004006981T2 (de) Datenabrufende und -übertragende vorrichtungen und verfahren
US8806341B2 (en) Method and apparatus for navigating a media program via a histogram of popular segments
DE69834080T2 (de) Verfahren zur verteilten Bearbeitung von Video-Clips über ein Telekommunikationsnetz
DE69925254T2 (de) Verfahren und vorichtung zur mediendatenübertragung
DE69630428T2 (de) Steuerung von Multicastdatensendungen
DE112011101911T5 (de) Fragmentierte Dateistruktur für die Ausgabe von Live-Medien-Streams
DE112012002159T5 (de) Kontextsensitive Client-Pufferschwellenwerte
DE112011103333T5 (de) Medienkonvergenzplattform
CN107615756A (zh) 实现快速平滑视点切换的多视点视频流媒体
DE112013001136T5 (de) Effiziente Abgrenzung und Verteilung von Media-Segmenten
DE112011101908T5 (de) Qualitätseinstellung unter Verwendung eines fragmentierten Medienstroms
DE60130104T2 (de) System und verfahren zur sofortigen wiederholung mit mehreren perspektiven
DE19960741A1 (de) System zum Austausch von Daten
DE102008003894A1 (de) Datenverbreitung und Zwischenspeicherung
DE602004012370T2 (de) Verfahren für das nahtlose Aufteilen und Verketten eines Datenstromes in Echtzeit
JP2004236240A (ja) ネットワーク放送システム、コンテンツ配信方法、及び番組提供装置
DE112016004480T5 (de) Synchronisierung des Renderns von Medien in heterogenen Netzwerkumgebungen

Legal Events

Date Code Title Description
8364 No opposition during term of opposition