DE69812994T9 - Verfahren und vorrichtung für nicht-sequentiellen zugang zu einem laufenden videoprogramm - Google Patents

Verfahren und vorrichtung für nicht-sequentiellen zugang zu einem laufenden videoprogramm Download PDF

Info

Publication number
DE69812994T9
DE69812994T9 DE69812994T DE69812994T DE69812994T9 DE 69812994 T9 DE69812994 T9 DE 69812994T9 DE 69812994 T DE69812994 T DE 69812994T DE 69812994 T DE69812994 T DE 69812994T DE 69812994 T9 DE69812994 T9 DE 69812994T9
Authority
DE
Germany
Prior art keywords
data
content data
video
tag
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.)
Active
Application number
DE69812994T
Other languages
English (en)
Other versions
DE69812994T2 (de
DE69812994D1 (de
Inventor
Daniel Weaver
A. Mark PORTER
J. David PAWSON
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.)
Thirdspace Living Ltd
NCube Corp
Original Assignee
Thirdspace Living Ltd
NCube Corp
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
Family has litigation
First worldwide family litigation filed litigation Critical https://patents.darts-ip.com/?family=25498000&utm_source=google_patent&utm_medium=platform_link&utm_campaign=public_patent_search&patent=DE69812994(T9) "Global patent litigation dataset” by Darts-ip is licensed under a Creative Commons Attribution 4.0 International License.
Application filed by Thirdspace Living Ltd, NCube Corp filed Critical Thirdspace Living Ltd
Publication of DE69812994D1 publication Critical patent/DE69812994D1/de
Publication of DE69812994T2 publication Critical patent/DE69812994T2/de
Application granted granted Critical
Publication of DE69812994T9 publication Critical patent/DE69812994T9/de
Active legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8455—Structuring of content, e.g. decomposing content into time segments involving pointers to the content, e.g. pointers to the I-frames of the video stream
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
    • G11B27/02—Editing, e.g. varying the order of information signals recorded on, or reproduced from, record carriers
    • G11B27/031—Electronic editing of digitised analogue information signals, e.g. audio or video signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/115—Selection of the code volume for a coding unit prior to coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/102—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or selection affected or controlled by the adaptive coding
    • H04N19/132—Sampling, masking or truncation of coding units, e.g. adaptive resampling, frame skipping, frame interpolation or high-frequency transform coefficient masking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/146—Data rate or code amount at the encoder output
    • H04N19/152—Data rate or code amount at the encoder output by measuring the fullness of the transmission buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/162—User input
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/172—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a picture, frame or field
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/17—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object
    • H04N19/176—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being an image region, e.g. an object the region being a block, e.g. a macroblock
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/169—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding
    • H04N19/187—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the coding unit, i.e. the structural portion or semantic portion of the video signal being the object or the subject of the adaptive coding the unit being a scalable video layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/46—Embedding additional information in the video signal during the compression process
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/587—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding involving temporal sub-sampling or interpolation, e.g. decimation or subsequent interpolation of pictures in a video sequence
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/70—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals characterised by syntax aspects related to video coding, e.g. related to compression standards
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/232—Content retrieval operation locally within server, e.g. reading video streams from disk arrays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/23805—Controlling the feeding rate to the network, e.g. by controlling the video pump
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/238—Interfacing the downstream path of the transmission network, e.g. adapting the transmission rate of a video stream to network bandwidth; Processing of multiplex streams
    • H04N21/2387—Stream processing in response to a playback request from an end-user, e.g. for trick-play
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/239—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests
    • H04N21/2393—Interfacing the upstream path of the transmission network, e.g. prioritizing client content requests involving handling client requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4305—Synchronising client clock from received content stream, e.g. locking decoder clock with encoder clock, extraction of the PCR packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream, rendering scenes according to MPEG-4 scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47202—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8547—Content authoring involving timestamps for synchronizing content
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8549—Creating video summaries, e.g. movie trailer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17336—Handling of requests in head-ends
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/20—Disc-shaped record carriers
    • G—PHYSICS
    • G11—INFORMATION STORAGE
    • G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
    • G11B2220/00—Record carriers by type
    • G11B2220/40—Combinations of multiple record carriers
    • G11B2220/41—Flat as opposed to hierarchical combination, e.g. library of tapes or discs, CD changer, or groups of record carriers that together store one title
    • G11B2220/415—Redundant array of inexpensive disks [RAID] systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/146—Data rate or code amount at the encoder output

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Human Computer Interaction (AREA)
  • Television Signal Processing For Recording (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)

Description

  • Verwandte Anmeldungen
  • Die Anmeldung bezieht sich auf: US-Patent US-A-6 112 226, betitelt mit „Method and Apparatus for Concurrently Encoding and Tagging Digital Information for Allowing Non-Sequential Access During Playback", eingereicht von Daniel Weaver, Mark A. Porter und David J. Pawson am 22. Oktober 1997, und
    US-Patent US-A-6 138 147, betitelt mit „Method and Apparatus for Implementing Seamless Playback of Continuous Media Feeds", eingereicht von Daniel Weaver und David J. Pawson am 22. Oktober 1997.
  • Gebiet der Erfindung
  • Die Erfindung betrifft ein Verfahren und eine Vorrichtung zum Verarbeiten audio-visueller Information und insbesondere ein Verfahren und eine Vorrichtung zum Bereitstellen eines nicht-sequenziellen Zugriffs auf audio-visuelle Information, die in einem Live-Content-Strom dargestellt ist.
  • Hintergrund der Erfindung
  • In den letzten Jahren hat die Medienindustrie ihren Horizont über die traditionellen analogen Technologien hinaus erweitert. Töne, Fotografien und selbst Spielfilme werden nun in digitale Formate aufgezeichnet oder umgewandelt. Um die Kompatibilität zwischen Produkten zu fördern, wurden in vielen der Medienkategorien Standardformate entwickelt.
  • Wie erwartet wurde, wünschen die Zuschauer eines digitalen Videos von den Herstellern digitaler Videos die gleiche Funktionalität, wie sie sie nun genießen, während sie sich analoge Videobänder in Video-Kassettenrekordern anschauen. Beispielsweise möchten Zuschauer befähigt sein, im Video vorwärts zu springen, zurück zu springen, vorzuspulen, zurückzuspulen, langsam vorzuspulen, langsam zurückzuspulen und ein Bild einzufrieren.
  • Es wurden verschiedene Ansätze entwickelt, um eine nicht-sequenzielle Wiedergabe digitaler Videodaten bereitzustellen. In Bezug auf digitale Videodaten betrifft die nicht-sequenzielle Wiedergabe eine Wiedergabe-Operation, bei der nicht alle der kodierten Bilder genau in der Reihenfolge in der Sequenz anzeigt werden, in der sie kodiert worden sind. Beispielsweise sind die Operationen des Vorwärtsspringens und des schnellen Vorspulens in der Hinsicht nicht-sequenziell, dass einige Bilder übersprungen werden. Die Operationen des Zurückspulens mit irgendeiner Geschwindigkeit sind während dieser Rückspul-Operation in der Hinsicht nicht-sequenziell, dass Bilder nicht in der Reihenfolge abgespielt werden, in der sie kodiert sind.
  • Ein Ansatz zum Bereitstellen einer nicht-sequenziellen Wiedergabe digitaler Videodaten, an dieser Stelle bezeichnet als Tag-basierter Ansatz, ist im US-Patent US-A-5 659 539, betitelt mit „Method and Apparatus for Frame Accurate Access of Digital Audio-visual Information", das Mark A. Porter et al am 19. August 1997 erteilt worden ist, beschrieben. Gemäß dem Tag-basierten Ansatz wird eine gespeicherte digitale Videodatei geparst, um „Tag-Informationen" über einzelne Bilder innerhalb der Datei zu erzeugen.
  • Insbesondere enthält die Tag-Datei Informationen über den Zustand einer oder mehrerer Zustandsmaschinen, die verwendet werden, um die digitale Darstellung zu dekodieren. Die Zustandsinformation variiert abhängig von der spezifischen Technik, die verwendet wird, um die audio-visuelle Arbeit zu kodieren. Für MPEG 2-Dateien beispielsweise weist die Tag-Datei Informationen über den Zustand der Packetized Elementary Stream-Zustandsmaschine, der Video-Zustandsmaschine und der Transportschicht-Zustandsmaschine auf.
  • Während der Durchführung der audio-visuellen Arbeit werden Daten von der digitalen Darstellung von einer Videopumpe an einen Dekoder gesendet. Die Information in der Tag-Datei wird verwendet, um die Operationen des Suchens, des schnellen Vorspulens, des schnellen Zurückspulens, des langsamen Vorspulens und des langsamen Zurückspulens während der Durchführung der audio-visuellen Arbeit durchzuführen. Such-Operationen werden durchgeführt, indem die Videopumpe dazu gebracht wird, das Übertragen von Daten von der aktuellen Position in der digitalen Darstellung anzuhalten und das Übertragen von Daten von einer neuen Position in der digitalen Darstellung an zu starten. Die Information in der Tag-Datei wird untersucht, um die neue Position zu ermitteln, von der begonnen werden soll, die Daten zu übertragen. Um sicherzustellen, dass der Datenstrom, der mittels der Videopumpe übertragen wird, gemäß dem anwendbaren Videoformat verwaltet wird, werden Präfix-Daten, die eine geeignete Header-Information aufweisen, mittels der Videopumpe übertragen, bevor die Daten von der neuen Position an übertragen werden.
  • Die Operationen des schnellen Vorspulens, des schnellen Zurückspulens, des langsamen Vorspulens und des langsamen Zurückspulens werden durch Auswählen von Videobildern basierend auf der Information, die in der Tag-Datei enthalten ist, und der gewünschten Darstellungsrate und mittels Erzeugens eines Datenstroms durchgeführt, der Daten enthält, die die ausgewählten Videobilder darstellen. Bei dem Auswahlprozess wird eine Vielzahl von Faktoren beachtet, inklusive der Datentransferrate des Kanals, auf dem die Daten zu senden sind, dem Bild-Typ der Bilder, einer minimalen Auffüllrate und der Möglichkeit eines Puffer-Überlaufs im Dekoder. Präfix- und Suffix-Daten werden in den übertragenen Datenstrom vor und nach den Daten für jedes Bild eingefügt, um die Einhaltung des Datenstrom-Formats aufrechtzuerhalten, das vom Dekoder erwartet wird.
  • Der Tag-basierte Ansatz funktioniert gut, wenn es genügend Zeit zwischen dem Erzeugen des ursprünglichen digitalen Videostroms und dem Anschauen des digitalen Videostroms gibt, sodass es möglich ist, dass der ursprüngliche digitale Videostrom geparst wird, um die Tag-Information zu erzeugen. Wenn jedoch der digitale Videostrom angeschaut wird, während er erzeugt wird, wird das Parsen des digitalen Videostroms unpraktikabel. Die Größe der Rechenkraft, die erforderlich ist, um den digitalen Videostrom zu parsen, sobald er ankommt, würde unerschwinglich teuer sein. Andererseits wird es als nicht akzeptabel betrachtet, die Latenzzeit zwischen dem Auftreten vieler Typen von Videozuführungen (beispielsweise Sportereignissen) und der Zeit zu erhöhen, zu der solche Zuführungen einem Publikum zum Anschauen verfügbar sind.
  • Wird ein Videostrom zum Anschauen verfügbar gemacht, bevor die Erzeugung des Streams abgeschlossen ist, ist der Videostrom eine so genannte „Live-Zufuhr". Auf professioneller Ebene können nichtlineare digitale Editoren verwendet werden, um Filmmaterial einer Live-Zufuhr für einen einzelnen Nutzer schnell zu überprüfen. Jedoch sind diese Systeme nicht ausgerichtet und können nicht einfach angepasst werden daran, vielen Nutzern zu dienen. Wenn beispielsweise hundert Nutzer die gleiche Live-Zufuhr sehen würden, aber zu unterschiedlichen Zeiten die Zufuhr zurückspulen, anhalten und schnell vorspulen möchten, würde jeder einen separaten nichtlinearen digitalen Editor benötigen.
  • Ein anderes Problem, das mit dem Bereitstellen eines nicht-linearen Zugriffs auf digitale Live-Videoströme verbunden ist, ist, dass Nutzer versuchen könnten, in Abschnitte des Videostroms schnell vorzuspulen, die noch nicht existieren. Beispielsweise kann ein Zuschauer versuchen, eine Live-Zufuhr schnell vorzuspulen, um den Endstand eines Spiels zu sehen, das in Wirklichkeit noch nicht beendet ist. Es ist wünschenswert, Techniken zum Behandeln dieser Typen von Situationen in einer Weise bereitzustellen, die sicherstellt, dass weder der Dekoder den Videostrom einfriert, noch dass der Videostrom zerstört wird.
  • Basierend auf dem Vorangegangenen ist es klar wünschenswert, ein Verfahren und eine Vorrichtung zum sequenziellen Anzeigen nicht-sequenzieller Bilder eines digitalen Live-Videos bereitzustellen. Es ist ferner wünschenswert, einen nicht-sequenziellen Zugriff auf ein digitales Live-Video in einer Weise bereitzustellen, sodass es nicht erforderlich ist, dass jeder Zuschauer eine unerschwinglich teure Hardware betreibt. Es ist ferner wünschenswert, Vorkehrungen zu treffen gegen Versuche, auf Bereiche eines digitalen Live-Videostroms zuzugreifen, die noch nicht existieren.
  • Ferner offenbaren EP-A-0 748 122 und US-A-5,659,539 ein Verfahren zum Zuführen einer Live-Zufuhr einem Client, aufweisend die Schritte des Erzeugens von Inhalts-Daten mit einem Koder und des Erzeugens von Tag-Daten.
  • US-A-5,568,180 offenbart ein Verfahren zum Bereitstellen von Videodaten, wobei die Inhalts-Dateien auf Platten gespeichert werden und Tag-Dateien für die Inhalts-Dateien bereits verfügbar sind.
  • Zusammenfassung der Erfindung
  • Ein Verfahren und ein System zum Bereitstellen einer Live-Zufuhr einem Client werden bereitgestellt. Gemäß einem Aspekt der Erfindung werden Inhalts-Daten mittels eines Koders erzeugt. Tag-Daten, die Positionen von Videobild-Daten innerhalb der Inhalts-Daten kennzeichnen, werden erzeugt, während die Inhalts-Daten erzeugt werden. Gemäß einem Ausführungsbeispiel werden die Tag-Daten mittels des Koders erzeugt. Gemäß einem alternativen Ausführungsbeispiel werden die Tag-Daten mittels Parsens der Inhalts-Daten erzeugt.
  • Die Inhalts-Daten befinden sich an einer Position, von der die Inhalts-Daten dem Client zugeführt werden. Die Tag-Daten sind an einer Position gespeichert, von der die Tag-Daten verwendet werden können, dem Client einen nicht-sequenziellen Zugriff auf die Inhalts-Daten bereitzustellen.
  • Bevor der Koder das Erzeugen der Inhalts-Daten beendet, wird eine Anforderung vom Client für einen nicht-sequenziellen Zugriff auf die Inhalts-Daten empfangen, zweite Inhalts-Daten werden basierend auf den Inhalts-Daten, den Tag-Daten und der Anforderung für einen nicht-sequenziellen Zugriff erzeugt, und die zweiten Inhalts-Daten werden an den Client gesendet.
  • Kurzbeschreibung der Figuren
  • Die Erfindung ist im Wege eines Beispiels und nicht im Wege einer Beschränkung in den Figuren der beigefügten Zeichnungen dargestellt, bei denen sich gleiche Bezugszeichen auf gleiche Elemente beziehen und bei denen:
  • 1 ein Blockdiagramm ist, das ein Video-Zuführsystem gemäß einem Ausführungsbeispiel der Erfindung zeigt;
  • 2A ein Blockdiagramm ist, das das Format einer MPEG-Datei zeigt;
  • 2B ein Blockdiagramm einer beispielhaften Tag-Datei gemäß einem Ausführungsbeispiel der Erfindung ist;
  • 2C ein Blockdiagramm ist, das die Tag-Information darstellt, die für jedes Bild in einer MPEG 1-Datei gemäß einem Ausführungsbeispiel der Erfindung erzeugt worden ist;
  • 3A ein Blockdiagramm ist, das ein Speichersystem darstellt, bei dem gemäß einem Ausführungsbeispiel der Erfindung eine RAID-Fehlerkorrektur-Technik angewendet wird;
  • 3B ein Blockdiagramm ist, das ein Speichersystem darstellt, bei dem gemäß einem Ausführungsbeispiel der Erfindung eine RAID-Fehlerkorrektur und ein Platten-Striping kombiniert sind;
  • 4 ein Blockdiagramm ist, das eine Folge von Inhalts-Dateien darstellt, die verwendet werden, um den Inhalt einer kontinuierlichen Zufuhr gemäß einem Ausführungsbeispiel der Erfindung zu speichern; und
  • 5 ein Blockdiagramm ist, das die Migration von Tag-Information von einer alten Tag-Datei in eine neue Tag-Datei als Antwort auf das Ablaufen der Tag-Daten innerhalb der alten Tag-Datei darstellt.
  • Ausführliche Beschreibung des bevorzugten Ausführungsbeispiels
  • Ein Verfahren und eine Vorrichtung zum Bereitstellen eines nicht-sequenziellen Zugriffs auf einen digitalen Live-Videostrom werden beschrieben. In der folgenden Beschreibung werden zum Zwecke der Erläuterung zahlreiche spezifische Details dargelegt, um ein gründliches Verständnis der Erfindung bereitzustellen. Es wird jedoch einem Fachmann offenbar, dass die Erfindung ohne diese spezifischen Details ausgeführt werden kann. Bei anderen Beispielen sind wohlbekannte Strukturen und Vorrichtungen in Blockdiagramm-Form gezeigt, um unnötige Verwirrung bei der Erfindung zu vermeiden.
  • Funktions-Übersicht
  • Gemäß einem bevorzugten Ausführungsbeispiel der Erfindung wird der Schwierigkeit, die mit dem Anwenden des Tag-basierten Ansatzes auf Live-Digital-Videozuführungen verbunden ist, durch das Beseitigen des Erfordernisses begegnet, einen eingehenden digitalen Videostrom in Echtzeit zu parsen. Anstelle des Erzeugens von Tag-Daten mittels Parsens des digitalen Videostroms behält die Einheit, die für das Kodieren der Live-Zufuhr zuständig ist, die Information darüber, wie die Daten kodiert worden sind, und überträgt diese Information zusammen mit den kodierten Daten zum Video-Server. Die Tag-Information kommt am Video-Server zusammen mit dem entsprechenden Inhalt an, so dass der Inhalt selbst nicht geparst werden muss.
  • Erfindungsgemäß ist der Video-Server derart eingerichtet, dass sichergestellt ist, dass der Client nicht hinter dem Ende des empfangenen Inhalts suchen oder abtasten kann. Infolge der Tatsache, dass es eine gewisse Menge an Verzerrung zwischen der Ankunftszeit des Inhalts und der entsprechenden Tags geben kann, ist der Server eingerichtet sicherzustellen, dass die Tags nicht verfrüht verwendet werden, d. h., dass sie den Server dazu bringen würden, sich hinter das Ende des verfügbaren Inhalts zu bewegen.
  • Beispielhaftes System
  • 1 ist ein Blockdiagramm, das ein beispielhaftes audio-visuelles Informations-Zuführsystem 100 zum Zuführen und Bereitstellen eines nicht-sequenziellen Zugriffs auf digitale Live-Video-Zuführungen darstellt. Das audio-visuelle Informations-Zuführsystem 100 weist im Allgemeinen einen Koder 101, einen Video-Server 106, einen Medien-Datenspeicher (MDS) 112, eine Datenbank 116, einen Stream-Server 118, eine Videopumpe 120 und einen Client 122 auf.
  • Der Koder
  • Der Koder 101 empfängt eine audio-visuelle Eingabe und erzeugt einen digitalen Datenstrom, in dem die audio-visuelle Eingabe gemäß einem bestimmten Format kodiert ist. Es wurden verschiedene Video-Kodierformate entwickelt und sind in der Industrie wohlbekannt. Beispielsweise sind die MPEG-Formate ausführlich in den folgenden internationalen Standards beschrieben: ISO/IEC 13818-1, 2, 3 (MPEG 2) und ISO/IEC 11172-1, 2, 3 (MPEG 1). Dokumente, in denen diese Standards beschrieben sind, (weiterhin bezeichnet als „MPEG-Spezifikationen"), sind verfügbar bei ISO/IEC Copyright Office, Postfach 56, CH-1211 Genf 20, Schweiz. Während sich an dieser Stelle zum Zwecke der Erläuterung auf bestimmte Formate bezogen wird, ist die Erfindung nicht auf irgendein spezielles digitales Stream-Format beschränkt.
  • Der Koder 101 weist einen Koder/Dekoder (CODEC) 102 und einen Multiplexer (MUX) 104 auf. Der CODEC 102 wandelt visuelle oder audio-visuelle Information von einer Eingabequelle in komprimierte digitale Daten um. Der CODEC 102 kann beispielsweise ein Fraktal-Kompressor oder ein MPEG-Kompressor sein. Zum Zwecke der Darstellung soll angenommen werden, dass die Videoquelle, die mittels des CODEC 102 abgefangen wird, eine Live-Quelle ist, und dass folglich der CODEC 102 das Video mit einfacher Rate (1X) in Bezug auf die Echtzeit kodiert. Jedoch kann die Video-Quelle alternativ eine gespeicherte Video-Quelle sein, die der CODEC 102 mit irgendeiner Rate in Bezug auf die Echtzeit kodiert.
  • Der MUX 104 multiplext die komprimierte Audio- und visuelle Information, die vom CODEC 102 erzeugt worden ist, um einen komprimierten Videostrom zu erzeugen. In dem komprimierten Videostrom werden die Daten, die Videobilder und Töne darstellen, gemäß dem speziellen digitalen Format gemischt und formatiert, das vom Koder 101 unterstützt wird. Die spezifischen Operationen, die während des Mischprozesses durchgeführt werden, variieren basierend auf dem Typ des angewendeten Koders. Beispielsweise kann der Mischprozess das Ermitteln der Reihenfolge und der Position von Abschnitten digitalisierter Töne und Videos im Strom sowie das Einfügen von Metadaten an verschiedenen Punkten innerhalb des Stroms beinhalten. Die Metadaten können beispielsweise die Form von Header-Information annehmen, die den Startpunkt und den Inhalt von „Paketen" innerhalb des Stroms identifiziert. Der Strom komprimierter audio-visueller Information, der mittels des MUX 104 aufgebaut worden ist, wird vom Koder 101 zum Video-Server 106 mittels eines Kommunikationskanals 128 übertragen.
  • Steuerinformation
  • Gemäß einem bevorzugten Ausführungsbeispiel sendet der Koder 101 Steuerinformation mittels eines Kommunikationskanals 130 an den Video-Server 106 parallel mit dem Videostrom. Die Steuerinformation, die mittels des Kanals 130 gesendet worden ist, weist spezifische Information darüber auf, wie der Koder 101 den Videostrom aufgebaut hat. Diese Steuerinformation weist Tag-Daten auf, die vom Stream-Server 188 verwendet werden, um einen nicht-sequenziellen Zugriff auf den Videostrom bereitzustellen. Insbesondere kann die Steuerinformation Informationen über den Typ, die Länge und die Grenzen der verschiedenen Bilder, die in dem Videostrom kodiert sind, ebenso wie Header-Information aufweisen, die die Komprimierungsrate, die Bitrate und andere Typen von Information spezifiziert, die der Video-Server 106 benötigt, um zu ermitteln, wie der Videostrom zu verarbeiten ist.
  • Es ist bedeutsam, dass die Erzeugung der Steuerinformation eine minimale zusätzliche Rechenkraft einbezieht, da der MUX 104 das meiste der Information bereits während des Aufbaus des Content-Stroms erzeugt. Insbesondere ordnet der MUX 104 die digitalen Video- und Audiodaten von dem CODEC 102 an und kapselt sie ein. Da der MUX 104 den Inhalt paketiert, kennt der MUX 104 die Inhalte und die Grenzen zwischen den Paketen.
  • Kommunikation zwischen dem Koder und dem Video-Server
  • Während der CODEC 102 typischerweise in einer hartverdrahteten Schaltung implementiert ist, ist der MUX 104 bevorzugt mittels einer programmgesteuerten Schaltung, wie beispielsweise eines Prozessors, implementiert, der programmiert ist, um eine bestimmte Sequenz von Befehlen auszuführen, die in einem Speicher gespeichert sind. Folglich kann der MUX 104 einen Prozessor aufweisen, der ein herkömmliches Multiplex-Programm ausführt, das mit einer Software-Bibliothek gekoppelt worden ist und an diese Aufrufe durchführt, wobei mittels dieser Bibliothek die Kommunikation mit dem Video-Server 106 gesteuert wird.
  • Alle zwischen dem Koder 101 und dem Video-Server 106 übertragenen Daten werden bevorzugt unter Verwenden eines zuverlässigen Kommunikationsmechanismus' gesendet. Gemäß einem Ausführungsbeispiel wird der Video-Inhalt auf dem Kommunikationskanal 128 als ein einfacher Byte-Strom behandelt und wird mittels eines Leichtgewicht (Light Weight) – sowie zuverlässigen Protokolls übertragen. Beispielsweise ist TCP bei gering belasteten Netzwerken ausreichend. Die Steuerinformation und Metadaten auf dem Kommunikationskanal 130 beinhalten mehrere komplizierte Datentypen und werden mittels eines objektorientierten Protokolls übertragen, wie beispielsweise Common Object Request Broker Architecture Interface Definition Language („CORBA IDL").
  • Die Kommunikation zwischen dem Koder 101 und dem Video-Server 106 erfolgt in Sitzungen. Gemäß einem Ausführungsbeispiel wird eine Sitzung in 3 Phasen durchgeführt: Öffnen (OPEN), Senden (SEND) und Schließen (CLOSE). Die während jeder dieser Phasen durchgeführten Operationen sind wie folgt:
    OPEN – jede Bereitstellung, die der Video-Server 106 durchführen muss für die Netzwerk- oder Platten-Bandbreite oder den Plattenspeicher. Eine Pipe für die Videostrom-Daten (den „Inhalt") wird erzeugt.
    SEND TAGS und SEND DATA – diese Aufrufe werden so viele Male durchgeführt, wie der Inhalt kodiert wird. Der Video-Server 106 speichert den gesamten Inhalt unmittelbar auf eine Platte und aktualisiert eine Ende-der-Datei-Position. Tags werden im Speicher gehalten, bis die beigefügten Inhalts-Daten gespeichert sind. Tags werden für eine zusätzliche Zeitdauer gehalten, um zu garantieren, dass eine Suche nach solch einem Tag erfolgreich sein wird, d. h., dass die Videopumpe 120 nicht in Bezug auf die Daten stillstehen wird.
    CLOSE – die Inhalts-Pipe wird abgeschnitten (torn down). Server-Ressourcen werden freigegeben, und inhaltsbezogene Dienste sowie Clients werden benachrichtigt, dass die Zufuhr zu einem normalen statischen Bestandteil des Inhalts geworden ist.
  • Der Koder 101 erzeugt parallel Inhalts-Daten und Steuerdaten. Jedoch werden die Steuerdaten, die einem bestimmten Abschnitt des Inhalts zugeordnet sind, nicht notwendigerweise vom Koder 101 zur gleichen Zeit erzeugt, wie der spezielle Inhalts-Abschnitt. Beispielsweise kann der Koder 101 tatsächlich ermitteln, wie das Aufreihen von Inhalts-Bildern stattfindet, bevor der Koder 101 die Bilder eigentlich aufreiht. Unter diesen Umständen können die Steuerdaten, die kennzeichnen, wie die Bilder aufgereiht worden sind, vom Koder 101 vor den Inhalts-Daten übertragen werden, die die Bilder enthalten.
  • Der Video-Server
  • Der Video-Server 106 empfängt den Videostrom und die Steuerdaten von dem Koder 101 und bewirkt, dass die Daten im MDS 112 gespeichert werden. Bei dem dargestellten System sendet der Video-Server 106 einen MPEG-Videostrom an den MDS-Server 110, und der MDS-Server 110 speichert den MPEG-Videostrom in einer MPEG-Datei 134. Parallel dazu sendet der Video-Server 106 Tag-Information an den MDS-Server 110, die aus den Steuerdaten extrahiert worden ist, die auf der Leitung 130 empfangen worden sind. Die Tag-Daten werden in einer Tag-Datei 132 auf Platten 114 gespeichert. Der Video-Server 106 kann ferner die Information über den Inhalt, der die Tag-Daten aufweist, senden, um sie in der Datenbank 116 zu speichern.
  • Sind die Daten einmal mittels des Video-Servers 106 übertragen, kann irgendein anderes Gerät in dem System, inklusive der Videopumpe 120, die Tag-Daten verwenden, um einen Zugriff auf den Inhalt zu versuchen, der den Tag-Daten zugeordnet ist. Folglich kann die unmittelbare Übertragung von Tag-Daten an den MDS-Server 110 zu Fehlern führen, wenn die Tag-Daten beispielsweise am Video-Server 106 vor den entsprechenden Inhalts-Daten ankommen. Daher puffert der Video-Server 106 vor dem Senden der Tag-Daten an den MDS-Server 110 jedes Tag-Daten-Item in einem Tag-Puffer 108, bis es für Geräte, wie beispielsweise eine Videopumpe 120, sicher ist, auf den Inhalt zuzugreifen, der dem Tag-Daten-Item zugeordnet ist. Die Verwendung des Tag-Puffers 108, um ein verfrühtes Lesen von Inhalts-Daten zu verhindern, ist ausführlicher weiter unten beschrieben.
  • Beispielhafte MPEG-Datei
  • Bei digitalen audio-visuellen Speicherformaten, ob komprimiert oder nicht, werden Zustandsmaschinen und Pakete verschiedener Strukturen verwendet. Die an dieser Stelle beschriebenen Techniken werden auf all diese Speicherformate angewendet. Während die Erfindung nicht auf irgendein bestimmtes digitales audio-visuelles Format beschränkt ist, soll die MPEG 2-Transportdatei-Struktur zum Zwecke der Darstellung beschrieben werden.
  • Bezugnehmend auf 2A stellt diese die Struktur einer MPEG 2-Transportdatei 134 in größerem Detail dar. Die Daten innerhalb der MPEG-Datei 134 sind in drei Schichten paketiert: einer Packetized Elementary Stream(„PES")-Schicht, einer Transportschicht und einer Videoschicht. Diese Schichten sind ausführlich in den MPEG 2-Spezifikationen beschrieben. In der PES-Schicht besteht die MPEG-Datei 134 aus einer Sequenz von PES-Paketen. In der Transportschicht besteht die MPEG-Datei 134 aus einer Sequenz von Transportpaketen. In der Videoschicht besteht die MPEG-Datei 134 aus einer Sequenz von Bildpaketen. Jedes Bildpaket enthält die Daten für ein Videobild.
  • Jedes PES-Paket weist einen Header auf, der die Länge und die Inhalte des PES-Paketes identifiziert. Bei dem dargestellten Beispiel enthält ein PES-Paket 250 einen Header 248, gefolgt von einer Sequenz von Transportpaketen 251–262. Die PES-Paket-Grenzen fallen mit gültigen Transportpaket-Grenzen zusammen. Jedes Transportpaket enthält auschließlich einen Datentyp. Bei dem dargestellten Beispiel enthalten die Transportpakete 251, 256, 258, 259, 260 und 262 Videodaten. Die Transportpakete 252, 257 und 261 enthalten Audio-Daten. Das Transportpaket 253 enthält Steuer-Daten. Das Transportpaket 254 enthält Zeitsteuerungs-Daten. Das Transportpaket 255 ist ein Auffüll-Paket.
  • Jedes Transportpaket weist einen Header auf. Der Header weist einen Paket-ID („PID") für das Paket auf. Pakete, denen der PID 0 zugeordnet ist, sind Steuerpakete. Beispielsweise kann dem Paket 253 der PID 0 zugeordnet sein. Andere Pakete, inklusive andere Steuerpakete, werden in den PID 0-Paketen referenziert. Insbesondere weisen die PID 0-Steuerpakete Tabellen auf, die die Pakettypen der Pakete aufweisen, die den PID 0-Steuerpaketen unmittelbar folgen. Für alle Pakete, die keine PID 0-Steuerpakete sind, enthalten die Header PIDs, die als Zeiger auf die Tabelle dienen, die in dem PID 0-Steuerpaket enthalten ist, das den Paketen unmittelbar vorausgeht. Beispielsweise würde der Datentyp, der in einem Paket mit einem PID 100 enthalten ist, durch das Untersuchen des Eintrags, der dem PID 100 zugeordnet ist, in der Tabelle des PID 0-Steuerpaketes ermittelt, das dem Paket am nächsten vorgelagert ist.
  • In der Videoschicht wird die MPEG-Datei 134 gemäß den Grenzen der Bild-Daten aufgeteilt. Wie oben erwähnt, gibt es keine Korrelation zwischen den Grenzen der Daten, die Videobilder repräsentieren, und den Transportpaket-Grenzen. Bei dem dargestellten Beispiel sind die Bild-Daten für ein Videobild "F" positioniert, wie mittels Klammern 270 gekennzeichnet. Insbesondere sind die Bild-Daten für das Bild „F" von einem Punkt 280 innerhalb des Video-Paketes 251 bis zum Ende des Video-Paketes 251, im Video-Paket 256 und vom Beginn des Video-Paketes 258 bis zu einem Punkt 282 innerhalb des Video-Paketes 258 positioniert. Daher stellen die Punkte 280 und 282 die Grenzen für das Bildpaket für das Bild „F" dar. Die Bild-Daten für ein zweites Videobild „G" sind positioniert, wie mittels Klammern 272 gekennzeichnet. Die Grenzen für das Bildpaket für das Bild „G" sind mittels der Klammern 276 gekennzeichnet.
  • Strukturen, die analog denen sind, wie oben für die MPEG 2-Transport-Ströme beschrieben, gibt es auch bei anderen digitalen audio-visuellen Speicherformaten, inklusive MPEG 1, Quicktime, AVI, Proshare und H.261-Formaten. Bei einem bevorzugten Ausführungsbeispiel werden Kennzeichner für Video-Zugreifpunkte, Zeitstempel, Datei-Positionen usw. derart gespeichert, dass auf die vielen digitalen audio-visuellen Speicherformate vom gleichen Server zugegriffen werden kann, um gleichzeitig unterschiedlichen Clients mit einer großen Vielfalt von Speicherformaten zu dienen. Bevorzugt sind all die formatspezifischen Informationen und Techniken im Tag-Generator und im Stream-Server integriert. All die anderen Elemente des Servers sind formatunabhängig.
  • Beispielhafte Tag-Datei
  • Die Inhalte einer beispielhaften Tag-Datei 132 sollen nun unter Bezugnahme auf 2B gezeigt werden. In 2B weist die Tag-Datei 132 einen Dateityp-Identifizierer 202, einen Längen-Kennzeichner 204, einen Bitraten-Kennzeichner 206, einen Spieldauer-Kennzeichner 208, einen Bildanzahl-Kennzeichner 210, eine Stream-Zugriffsinformation 212 und einen initialen MPEG-Zeit-Offset 213 auf. Der Dateityp-Identifizierer 202 kennzeichnet das physikalische Wrapping in der MPEG-Datei 134. Beispielsweise würde der Dateityp-Identifizierer 202 anzeigen, ob die MPEG-Datei 134 eine MPEG 2- oder eine MPEG 1-Datei ist.
  • Der Längen-Kennzeichner 204 zeigt die Länge der MPEG-Datei 134 an. Der Bitraten-Kennzeichner 206 zeigt die Bitrate an, mit der die Inhalte der MPEG-Datei 134 an einen Client während einer Wiedergabe zu senden sind. Der Spieldauer-Kennzeichner 208 spezifiziert die Zeitdauer in Millisekunden, die erforderlich ist, die gesamten Inhalte der MPEG-Datei 134 während eines normalen Wiedergabebetriebs wiederzugeben. Der Bildanzahl-Kennzeichner 210 zeigt die Gesamtanzahl der Bilder an, die in der MPEG-Datei 134 dargestellt sind.
  • Die Stream-Zugriffsinformation 212 ist eine Information, die erforderlich ist, um auf die Video- und Audio-Ströme zuzugreifen, die in der MPEG-Datei 134 gespeichert sind. Die Stream-Zugriffsinformation 212 weist einen Video-Elementar-Stream-ID und einen Audio-Elementar-Stream-ID auf. Für MPEG 2-Dateien weist die Stream-Zugriffsinformation 212 ferner einen Video-PID und einen Audio-PID auf. Der Tag-Datei-Header kann ferner andere Information enthalten, die verwendet werden kann, um andere Merkmale zu implementieren.
  • Zusätzlich zu der oben beschriebenen eigenen Information enthält die Tag-Datei 132 einen Eintrag für jedes Bild innerhalb der MPEG-Datei 134. Der Eintrag für ein Videobild weist Informationen über den Zustand der verschiedenen MPEG-Schichten in Bezug auf die Position der Daten auf, die das Bild darstellen. Für eine MPEG 2-Datei weist jeder Eintrag den Zustand der MPEG 2-Transport-Zustandsmaschine, den Zustand der Packetized Elementary Stream-Zustandsmaschine und den Zustand der Video-Zustandsmaschine auf. Für eine MPEG 1-Datei weist jeder Eintrag den aktuellen Zustand des Pack-System-MPEG-Stroms und den Zustand der Video-Zustandsmaschine auf.
  • Der Tag-Datei-Eintrag 214 stellt in größerem Detail die Tag-Information dar, die für ein einzelnes MPEG 2-Videobild „F" gespeichert ist. Bezüglich des Zustands der Packetized Elementary Stream-Zustandsmaschine weist der Tag-Eintrag 214 die Information auf, wie in Tabelle 1 gezeigt.
  • Tabelle 1
    Figure 00160001
  • Figure 00170001
  • Bezüglich des Zustands der Video-Zustandsmaschine weist der Tag-Eintrag 214 die Information auf, wie in Tabelle 2 gezeigt.
  • Tabelle 2
    Figure 00170002
  • Unter Bezugnahme auf den Zustand der Transportschicht-Zustandsmaschine weist der Tag-Eintrag 214 die Information auf, wie in Tabelle 3 gezeigt.
  • Tabelle 3
    Figure 00180001
  • Angenommen, dass der Eintrag 214 beispielsweise für das Bild „F" von 2B ist. Die Größe 220, die dem Bild „F" zugeordnet ist, würde die Bitanzahl sein, die von Klammern 274 umgeben ist. Die Anzahl 222 von Nicht-Video-Paketen würde 5 sein (Pakete 252, 253, 254, 255 und 257). Die Anzahl 224 von Auffüll-Paketen würde 1 sein (Paket 255). Die Anfangsposition 226 würde der Abstand zwischen dem Start der MPEG- Datei 134 und dem Punkt 280 sein. Der Start-Offset 234 würde der Abstand zwischen dem Start des Paketes 251 und dem Punkt 280 sein. Der Ende-Offset 236 würde der Abstand zwischen dem Punkt 282 und dem Ende des Paketes 258 sein.
  • Die Tag-Information, die für jedes Bild in einer MPEG 1-Datei erzeugt wird, ist in 2C dargestellt. Bezugnehmend auf 2C weist der Eintrag 214 Daten auf, die den Zustand dreier Zustandsmaschinen anzeigen: einer System-Zustandsmaschine, einer Paketierungs-Zustandsmaschine und einer Video-Zustandsmaschine. Insbesondere weist der Tag-Eintrag 214 die Information auf, wie in Tabelle 4 gezeigt.
  • Tabelle 4
    Figure 00190001
  • Figure 00200001
  • Die Tag-Information weist Daten auf, die den Zustand der relevanten Zustandsmaschinen am Beginn von Videobildern anzeigt. Jedoch unterscheiden sich die Zustandsmaschinen, die mit anderen digitalen audio-visuellen Formaten angewendet werden, von denen, wie oben beschrieben, ebenso wie sich die Zustandsmaschinen, die beim MPEG 1-Format angewendet werden, von denen bei MPEG 2 unterscheiden. Folglich wird die spezifische Tag-Information, die für jedes Bild des Videos gespeichert ist, basierend auf dem digitalen Audio-Videoformat der Datei variieren, der sie zugeordnet ist.
  • Der MDS
  • Der MDS 112 weist einen MDS-Server 110 und einen oder mehrere Nichtflüchtig-Speicher-Einrichtungen, wie beispielsweise Platten 114, auf. Bei dem dargestellten Ausführungsbeispiel wird die MPEG-Datei 134 über viele Platten 114 hinweg gespeichert, um die Fehlertoleranz des Systems zu erhöhen. Betrachtet wird beispielsweise ein Mehrfach-Plattensystem 300, wie in 3 dargestellt. Das System 300 weist N + 1 Plattenlaufwerke auf. Eine MPEG-Datei wird auf N der N + 1 Platten gespeichert. Die MPEG-Datei wird in Abschnitte 350, 352, 354 und 356 aufgeteilt. Jeder Abschnitt wird in N Blöcke aufgeteilt, wobei N die Anzahl der Platten ist, die verwendet werden, um die MPEG-Datei zu speichern. Jede Platte speichert einen Block eines gegebenen Abschnitts.
  • Bei dem dargestellten Beispiel weist der erste Abschnitt 350 der MPEG-Datei Blöcke 310, 312 und 314 auf, die auf Platten 302, 304 bzw. 306 gespeichert sind. Der zweite Abschnitt 352 weist Blöcke 316, 318 und 320 auf, die auf Platten 302, 304 bzw. 306 gespeichert sind. Der dritte Abschnitt 354 weist Blöcke 322, 324 und 326 auf, die auf Platten 302, 304 bzw. 306 gespeichert sind. Der vierte Abschnitt 356 weist Blöcke 328, 330 und 332 auf, die auf Platten 302, 304 bzw. 306 gespeichert sind.
  • Die Platte 308, die nicht verwendet wird, um die MPEG-Datei zu speichern, wird verwendet, um Prüf-Bits zu speichern. Jeder Satz von Prüf-Bits entspricht einem Abschnitt der MPEG-Datei und wird basierend auf den verschiedenen Blöcken aufgebaut, die zu dem entsprechenden Abschnitt gehören. Beispielsweise entsprechen die Prüfbits 334 dem Abschnitt 350 und werden mittels Durchführens einer Exklusiv-ODER(XOR)-Operation auf all den Blöcken im ersten Abschnitt 350 erzeugt. Auf die gleiche Weise sind die Prüf-Bits 336, 338 und 340 die Ergebnisse einer Exklusiv-ODER-Operation, die auf all den Blöcken im Abschnitt 352, 354 bzw. 356 durchgeführt worden ist.
  • Das System 300 hat eine höhere Fehlertoleranz als ein Einzel-Plattensystem in der Hinsicht auf, dass, wenn eine Platte im System aufhört, korrekt zu arbeiten, die Inhalte der kaputten Platte basierend auf den Inhalten der verbliebenen Platten rekonstruiert werden können. Wenn beispielsweise die Platte 304 aufhört zu funktionieren, können die Inhalte des Blocks 312 basierend auf den verbliebenen Blöcken im Abschnitt 350 und den Prüf-Bits 334, die dem Abschnitt 350 zugeordnet sind, rekonstruiert werden. Auf die gleiche Weise kann der Block 318 basierend auf den verbliebenen Blöcken im Abschnitt 352 und den Prüf-Bits 336, die dem Abschnitt 352 zugeordnet sind, aufgebaut werden. Diese Fehlererfassung und -Korrekturtechnik ist allgemein bekannt als „redundantes Feld preisgünstiger Platten" (Redundant Array of Inexpensive Disk – RAID).
  • Während einer Echtzeit-Wiedergabe unter Verwenden von RAID liest eine Videopumpe 120 die MPEG-Datei auf einer Abschnitt-für-Abschnitt-Basis und verarbeitet sie, so dass all die Information verfügbar ist, um irgendwelche Daten, die von einer Platte fehlerhaft gelesen worden sind, zu rekonstruieren. Techniken zum Durchführen von RAID in Echtzeit sind beschrieben im US-Patent Nr. US-A-5,623,595, betitelt mit „Method and Apparatus for Transparent, Real Time Reconstruction of Corrupted Data In A Redundant Array Data Storage System".
  • Während normaler Wiedergabe-Operationen ist genügend Zeit, um die Platten-Zugriffe durchzuführen, die erforderlich sind, um einen gesamten Abschnitt zu lesen, während die Daten vom vorherigen Abschnitt im MPEG-Datenstrom übertragen werden. Jedoch werden bei den Operationen des schnellen Vorspulens und des schnellen Zurückspulens weniger als all die Daten in jedem Abschnitt im MPEG-Datenstrom gesendet. Da weniger Daten gesendet werden, nimmt die Übertragungszeit der Daten weniger Zeit in Anspruch. Folglich ist weniger Zeit verfügbar, um den folgenden Abschnitt zu lesen und zu verarbeiten.
  • Beispielsweise wird angenommen, dass lediglich ein Bild X des Abschnitts 350 zur Anzeige während einer Operation des schnellen Vorspulens ausgewählt war. Während der Zeit, die in Anspruch genommen wird, das Segment für das Bild X zu übertragen, werden die Daten für das nächste ausgewählte Bild Y gelesen und verarbeitet. Es wird angenommen, dass das nächste Bild Y in Abschnitt 352 positioniert ist. Wenn die MPEG-Datei auf einer Abschnitts-Basis gelesen und verarbeitet wird (erforderlich für RAID), dann werden all die Blöcke im Abschnitt 352 während der Übertragung des einzelnen Bildes X gelesen und verarbeitet. Selbst wenn es möglich ist, all die Blöcke im Abschnitt 352 in der zugewiesenen Zeit zu lesen und zu verarbeiten, kann es nicht wünschenswert sein, dies wegen der Ressourcen, die beim Durchführen der erforderlichen Plattenzugriffe verbraucht würden, so durchzuführen.
  • Im Licht des Vorangegangenen nutzt die Videopumpe 120 nicht RAID während der Operationen des schnellen Vorspulens und des schnellen Zurückspulens. Stattdessen liest, verarbeitet und überträgt die Videopumpe 120 nur die Daten, die in den Befehlen gekennzeichnet sind, die sie vom Stream-Server 118 empfängt. Daher würden bei dem oben gegebenen Beispiel lediglich die Bild-Daten für das Bild Y während der Übertragung des Segments für das Bild X gelesen und verarbeitet. Unter Umgehung von RAID während der Operationen des schnellen Vorspulens und des schnellen Zurückspulens bleibt die Platten-Bandbreite auf der gleichen Stufe oder unter der Stufe, die während des normalen Wiedergabebetriebs verwendet wird.
  • Da RAID nicht während der Operationen des Echtzeit-Vorspulens und des Echtzeit-Zurückspulens verwendet wird, können fehlerhafte Daten während dieser Operationen nicht rekonstruiert werden. Folglich, wenn die Videopumpe 120 erfasst, dass die Daten für ein selektiertes Bild zerstört oder nicht verfügbar sind, verwirft die Videopumpe 120 das gesamte Segment, das dem problematischen Bild zugeordnet ist. Deshalb werden die Präfix- und Suffix-Daten für das Bild ebenfalls nicht gesendet, wenn die dem Bild zugeordneten Daten nicht gesendet werden können. Jedoch werden einige Auffüll-Pakete, die mit dem Präfix- oder Suffix-Daten zu senden sind, weiterhin gesendet.
  • Mittels des Sendens von Daten in Gesamt-„Segmenten" wird die Konformität mit dem digitalen Audio-Visuell-Format beibehalten. Bei einem Ausführungsbeispiel wird die Videopumpe 120 Auffüll-Pakete senden, um die Leitung aufzufüllen, um die korrekte Darstellungsrate beizubehalten. Bei dem bevorzugten Ausführungsbeispiel ist dieses Verhalten vom Client auswählbar.
  • Data-Striping
  • Die oben beschriebenen RAID-Techniken verbessern sowohl den Durchsatz (da alle Daten von allen Platten in einem Feld parallel gelesen werden) als auch die Zuverlässigkeit (infolge der Fehlerkorrektur). Um den Durchsatz weiter zu erhöhen, kann RAID in Verbindung mit Data-Striping verwendet werden. Unter Verwenden von Data-Striping werden Segmente von logisch hintereinander liegenden Daten auf viele physikalische Geräte (oder Sätze von physikalischen Geräten) in einer Round-Robin-Weise geschrieben. Die Menge gespeicherter Daten auf jedem Speicherelement in der Round-Robin-Sequenz wird als ein „Stripe" bezeichnet. Wenn jedes Speicherelement in der Round-Robin-Sequenz ein Feld von RAID-Platten ist, wird jedes Datensegment als RAID-Stripe bezeichnet.
  • 3B stellt ein System dar, bei dem Data-Striping in Verbindung mit RAID verwendet wird. Das System in 3B ist gleich dem von 3A mit der Ausnahme, dass jede der Platten in 3A durch einen Folge von M Platten ersetzt ist. Daher ist die Platte 302 durch Platten 302-1 bis 302-M ersetzt worden. Die Segment-Abschnitte, die auf Platten 302 gespeichert worden sind, sind auf Platten 302-1 bis 302-M in einer sequenziellen Round-Robin-Weise gespeichert. Beispielsweise wird angenommen, dass die MPEG-Datei in 50 Segmente aufgeteilt ist und dass die Platte 302 durch 25 Platten ersetzt worden ist. Unter diesen Umständen würde die Platte 302-1 den ersten Abschnitt der Segmente 1 und 26 speichern. Die Platte 302-2 würde den ersten Abschnitt der Segmente 2 und 27 speichern usw.
  • Durch das Data-Striping wird der Durchsatz erhöht, da verschiedene Prozesse von verschiedenen Platten-Feldern parallel lesen können. Beispielsweise kann eine Datenpumpe das erste Segment einer MPEG-Datei aus dem RAID-Feld lesen, das die Platten Disk_1,1 bis Disk_1,N + 1 aufweist, während eine andere Datenpumpe konkurrent das zweite Segment der gleichen MPEG-Datei aus dem RAID-Feld liest, das die Platten Disk_2,1 bis Disk_2,N + 1 aufweist.
  • Aus Durchsatz-Performanz-Gründen erfolgt das Lesen und das Schreiben in diskreten Blöcken, typischerweise in Platten-RAID-Stripes. Bei einem typischen digitalen Video-Zuführsystem ist jede Zugriffseinheit 256 kByte oder 2 Megabit, und der Inhalt ist ein 2 MB/s-MPEG. Folglich entspricht jedes RAID-Stripe ungefähr einer Sekunde eines Videos, obwohl diese leicht im Bereich von ungefähr 0,2 bis 10 Sekunde pro Stripe abhängig von der Inhalts-Bitrate und der Serverkonfiguration variieren kann.
  • Der Client
  • Das audio-visuelle Informations-Zuführsystem 100 enthält einen oder mehrere Clients, wie beispielsweise den Client 122. Der Client 122 repräsentiert im Allgemeinen Geräte, die eingerichtet sind, audio-visuelle Information zu dekodieren, die in einem Strom digitaler audio-visueller Daten enthalten ist. Beispielsweise kann der Client 122 eine Set-Top-Wandlerbox sein, die mit einer Ausgabe-Anzeige, wie beispielsweise einem Fernsehgerät, gekoppelt ist. Der Client 122 weist einen Dekoder 126 zum Dekodieren eines digitalen Datenstroms und eine Steuereinheit 124 zum Übertragen von Information zu dem Stream-Server 118 auf.
  • Der Stream-Server 118 ist befähigt, Informationen von Client 122 mittels eines Steuernetzwerks 140 zu empfangen. Das Steuernetzwerk 140 kann irgendein Netzwerk sein, das die Kommunikation zwischen zwei oder mehr Geräten ermöglicht. Beispielsweise kann das Steuernetzwerk 140 ein Netzwerk hoher Bandbreite, eine X.25-Schaltung oder eine Electronic Industry Association (EIA) 232 (RS-232) serielle Leitung sein.
  • Der Client 122 kommuniziert mit dem Stream-Server 188 und der Datenbank 116 mittels des Steuernetzwerks 140. Beispielsweise kann der Client 122 eine Anfrage an die Datenbank 116 senden, dabei eine Information abfragend, was zurzeit zum Anschauen verfügbar ist. Die Datenbank 116 antwortet auf das Senden der angeforderten Information zurück an den Client 122. Der Nutzer des Clients 122 kann dann eine Ansicht einer bestimmten audio-visuellen Arbeit auswählen, beginnend an einer bestimmten Position und mit einer bestimmten Geschwindigkeit. Der Client 122 überträgt Anforderungen, um die Übertragung von audio-visuellen Datenströmen und von Steuerinformation zu initiieren, um im Stream-Server 118 die Wiedergabe digitaler audio-visueller Übertragungen mittels des Netzwerks 140 zu bewirken.
  • Die Videopumpe und der Stream-Server
  • Die Videopumpe 120 ist mit dem Stream-Server 118 gekoppelt und empfängt Befehle von dem Stream-Server 118. Die Videopumpe 120 ist mit den Platten 114 derart gekoppelt, dass die Videopumpe 120 Daten speichert und von den Platten 114 abfragt.
  • Zusätzlich zum Kommunizieren mit dem Stream-Server 118 empfängt der Client 122 Informationen von der Videopumpe 120 mittels eines Netzwerks 150 hoher Bandbreite. Das Netzwerk 150 hoher Bandbreite kann irgendein Typ einer schaltungsartigen Netzwerkverbindung sein, die befähigt ist, große Datenmengen zu übertragen. Eine schaltungsartige Netzwerkverbindung ist derart konfiguriert, dass das Ziel der Daten durch das darunter liegende Netzwerk garantiert wird, und nicht durch das Übertragungsprotokoll. Beispielsweise kann das Netzwerk 150 hoher Bandbreite eine asynchrone Übertragungsmodus(ATM)-Schaltung oder ein physikalischer Typ einer Leitung sein, wie beispielsweise eine T1- oder E1-Leitung. Zusätzlich können bei dem Netzwerk 150 hoher Bandbreite ein faseroptisches Kabel, Twisted Pair-Leitungen, Koaxialkabel oder ein kabelloses Kommunikationssystem, wie beispielsweise ein Mikrowellen-Kommunikationssystem, verwendet werden.
  • Das Netzwerk 150 kann alternativ ein Netzwerk relativ geringer Bandbreite oder eine Kombination von Kommunikationsmedien hoher und geringer Bandbreite sein. Beispielsweise kann ein Abschnitt des Netzwerks 150 eine ATM-Schaltung relativ hoher Bandbreite aufweisen, während netzabwärts ein Gerät relativ niedriger Bandbreite, wie beispielsweise ein 28.8K-Modem, verwendet wird, um vom Netzwerk die Videoinformation dem Client 122 zuzuführen.
  • Das audio-visuelle Informations-Zuführsystem 100 erlaubt es einem Server, wie beispielsweise der Videopumpe 120, große Datenmengen von den Platten 114 mittels des Netzwerks 150 hoher Bandbreite an den Client 122 mit minimalem Overhead zu übertragen. Zusätzlich erlaubt das audio-visuelle Informations-Zuführsystem 100 dem Client 122, Anforderungen zu dem Stream-Server 118 unter Verwenden eines Standard-Netzwerkprotokolls mittels des Steuernetzwerks 140 zu übertragen. Bei einem bevorzugten Ausführungsbeispiel ist das darunter liegende Protokoll für das Netzwerk 150 hoher Bandbreite und für das Steuernetzwerk 140 das gleiche. Der Stream-Server 118 kann aus einem einzigen Computersystem oder aus einer Mehrzahl von Computergeräten bestehen, die als Server konfiguriert sind. Auf die gleiche Weise kann die Videopumpe 120 aus einer einzigen Server-Einrichtung bestehen oder kann eine Mehrzahl solcher Server aufweisen.
  • Um einen digitalen audio-visuellen Datenstrom aus einer bestimmten digitalen audio-visuellen Datei zu empfangen, überträgt der Client 122 eine Anforderung an den Stream-Server 118. Als Antwort auf die Anforderung überträgt der Stream-Server 118 Befehle an die Videopumpe 120, um die Videopumpe 120 dazu zu bringen, den angeforderten digitalen audio-visuellen Datenstrom an den Client zu übertragen, der den digitalen audio-visuellen Datenstrom angefordert hat. Für Live-Zuführungen wird der Videoserver 106 den Videostrom in die Videodatei zur gleichen Zeit speichern, zu der die Videopumpe 120 einen Videostrom von der Datei 134 an den Client 122 sendet.
  • Die von dem Stream-Server 118 an die Videopumpe 120 übertragenen Befehle weisen Steuerinformation auf, die für die Client-Anforderung spezifisch ist. Beispielsweise identifiziert die Steuerinformation die gewünschte digitale audio-visuelle Datei, den Start-Offset der gewünschten Daten innerhalb der digitalen audio-visuellen Datei und die Adresse des Client. Um einen gültigen digitalen audio-visuellen Strom an dem spezifizierten Offset zu erzeugen, sendet der Stream-Server 118 ferner „Präfix-Daten" an die Videopumpe 120 und fordert die Videopumpe 120 an, die Präfix-Daten an den Client zu senden. Wie weiter unten ausführlicher beschrieben wird, sind Präfix-Daten Daten, mit denen der Client vorbereitet wird, digitale audio-visuelle Daten von der spezifizierten Position in der digitalen audio-visuellen Datei zu empfangen.
  • Die Videopumpe 120 beginnt nach dem Empfangen der Befehle und der Steuerinformation von dem Stream-Server 118, digitale audio-visuelle Daten von der spezifizierten Position in der spezifizierten digitalen audio-visuellen Datei auf den Platten 114 abzufragen. Zum Zweck der Erläuterung soll angenommen werden, dass das audio-visuelle Informations-Zuführsystem 100 audio-visuelle Information gemäß einem oder mehrerer der MPEG-Formate liefert. Folglich wird die Videopumpe 120 die audio-visuellen Daten von einer MPEG-Datei 134 auf den Platten 114 abfragen.
  • Die Videopumpe 120 überträgt die Präfix-Daten an den Client und überträgt dann ruckfrei die MPEG-Daten zu dem Client, die von den Platten 114 abgefragt worden sind, beginnend an der spezifizierten Position. Die Präfix-Daten weisen einen Paket-Header auf, mittels dessen, wenn gefolgt von den MPEG-Daten, die an einer spezifizierten Position positioniert sind, ein MPEG-konformes Übertragungspaket erzeugt wird. Die Daten, die dem ersten Paket folgen, werden sequenziell von der MPEG-Datei 134 abgefragt und bilden deshalb eine Folge MPEG-konformer Pakete. Die Videopumpe 120 überträgt diese Pakete an den anfordernden Client mittels des Netzwerks 150 hoher Bandbreite.
  • Der anfordernde Client empfängt den MPEG-Datenstrom, beginnend mit den Präfix-Daten. Der Client dekodiert den MPEG-Datenstrom, um die audio-visuelle Sequenz wiederzugeben, die in dem MPEG-Datenstrom dargestellt ist.
  • Verhindern eines verfrühten Lesens
  • Wenn der Client 122 einen MPEG-Strom zur gleichen Zeit abspielt, zu der der MPEG-Strom vom Koder 101 erzeugt wird, sollten Vorkehrungen getroffen werden, um sicherzustellen, dass der Client 122 nicht stehen bleibt (da er das Ende der gültigen Inhalts-Daten erreicht hat) oder dass er ungültige Daten abspielt (weil er hinter das Ende der aktuell verfügbaren Inhalts-Daten gelesen hat). Wenn die Videopumpe 120 von den Platten 114 einen Stripe verfrüht liest, wird die Videopumpe 120 ungültige Daten an den Client 122 senden, was zu einer Anzeige von nicht erzieltem Inhalt oder von Müll (unsauberem Inhalt) führt. Solch ein verfrühtes Lesen tritt beispielsweise auf, wenn ein Nutzer die Anzeige eines Abschnitts des Videostroms anfordert, der noch nicht auf den Platten 114 gespeichert ist. Um dies zu verhindern, wird eine Ende-der-Datei-Information für die MPEG-Datei 134 verwaltet, um das aktuelle Ende der Datei 134 zu kennzeichnen. Wenn mehrere Inhalts-Daten zu der Datei 134 hinzugefügt worden sind, wird die Ende-der-Datei-Information so aktualisiert, dass auf die neuen Daten zugegriffen werden kann.
  • Ein Ansatz, verfrühtes Lesen zu verhindern, ist die wiederholte Aktualisierung einer Inhalts-Tabelle auf den Platten 114 mit einem neuen Ende-der-Datei-Wert, und dass die Videopumpe 120 diesen Wert prüft, bevor die Stripes von den Platten 114 gelesen werden. Der MDS-Server 110 aktualisiert das Ende der Datei, um zu kennzeichnen, dass die Inhalts-Datei 134 neuen Inhalt aufweist, nur, nachdem geprüft worden ist, dass der neue Inhalt erfolgreich auf den Platten 114 gespeichert ist. Unglücklicherweise führt diese Technik zu einer Schwankung in der Latenzzeit der Aktualisierungen, die schwer vorherzusagen ist, es sei denn, es wird garantiert, dass die Ende-der-Datei-Information in einem dynamischen Speicher gehalten wird.
  • Ein anderer Ansatz, um ein verfrühtes Lesen zu verhindern, ist für den MDS-Server 110, die neue Ende-der-Datei-Information aktiv an alle Prozesse zu übertragen, die den Inhalt lesen. Deshalb speichert der MDS-Server 110 die Inhalts-Daten in die Datei 134 auf den Platten 114, wartet auf eine Verifikation, dass der Inhalt gespeichert ist, und überträgt dann Nachrichten, die die Existenz des neuen gespeicherten Inhalts anzeigen, an alle Prozesse, die die Inhalts-Daten lesen (beispielsweise Videopumpe 120). Der MDS-Server 110 kann solche Ende-der-Datei-Benachrichtigungs-Nachrichten periodisch (beispielsweise alle 5 Sekunden) oder nach dem erfolgreichen Speichern einer vorbestimmten Menge von neuen Inhalts-Daten (beispielsweise jeweils nach 1 Megabyte) erstellen. Unglücklicherweise werden die Benachrichtigungs-Zeiten ebenfalls infolge der Variationen der Ankunftszeiten des Inhalts schwanken, die eine Funktion des Koders 101 und des Netzwerks zwischen dem Koder 101 und dem Videoserver 106 sind.
  • Gemäß einem Ausführungsbeispiel wird die Tag-Information verwendet, um das aktuelle Ende der Datei zu kennzeichnen. Insbesondere aktualisiert der Video-Server 106 effektiv die Ende-der-Datei-Information der Datei 134 mittels Sendens von Tag-Information vom Tag-Puffer 108 zur Speicherung mittels des MDS 112. Sobald die Tag-Information, die einem bestimmten Abschnitt des Inhalts entspricht, vom Video-Server 106 übertragen worden ist, ist die Videopumpe 120 frei darin, eine Suche nach diesem bestimmten Abschnitt des Videos durchzuführen. Bis die Tag-Information, die einem bestimmten Abschnitt des Videos entspricht, freigegeben ist, darf die Videopumpe 120 keine Suche nach dem entsprechenden Abschnitt des Videos durchführen. Da die neueste Tag-Information das aktuelle Ende der Datei kennzeichnet, können neu angeschlossene Nutzer leicht den Inhalt suchen, der der neuesten Tag-Information zugeordnet ist, und das Abspielen der Zuführung mit einer Echtzeit-Rate starten.
  • Minimale Tag-Verzögerungszeit
  • Um den Client 122 daran zu hindern, stehenzubleiben oder ungültige Daten abzuspielen, wird die Übertragung von Tag-Daten vom Tag-Puffer 108 zum MDS 112 verzögert. Bevorzugt ist die Verzögerungsdauer lang genug, um sicherzustellen, dass auf die zugeordneten Inhalts-Daten nicht verfrüht zugegriffen wird. Andererseits erhöht die Verzögerung der Tag-Daten mehr als notwendig die Latenzzeit zwischen dem Zeitpunkt, zu dem der Inhalt kodiert ist, und dem Zeitpunkt, zu dem die Nutzer den Inhalt suchen oder abtasten können. Folglich ist es wünschenswert, eine minimale Tag-Verzögerungs-Zeitdauer zu ermitteln und die Puffer-Tag-Daten in dem Tag-Puffer 108 für eine minimale Tag-Verzögerungs-Zeitdauer zu puffern. Die minimale Tag-Verzögerungs-Zeitdauer für ein Tag-Daten-Item wird mittels der maximalen Latenzzeit ermittelt, die mit dem Zuführen der entsprechenden Inhalts-Daten von dem Koder 101 der Videopumpe 120 verbunden ist.
  • Der Video-Server 106 weist einen Netzwerk-Puffer 152 und einen Schreib-Puffer 154 auf. Typischerweise wird der Videoserver 106 die Inhalts-Daten vom Kanal 128 in einen Netzwerk-Puffer 152 zur gleichen Zeit lesen, zu der der Video-Server 106 die Inhalts-Daten vom Schreib-Puffer 154 auf die Platten 114 schreibt. Bei Ausführungsbeispielen, bei denen Raid-Speichertechniken verwendet werden, werden Inhalts-Daten im Inneren des Video-Servers 106 in Einheiten empfangen und gepuffert, die einem Raid-Stripe entsprechen.
  • Die Videopumpe 120 weist eine Vorauslese-Einheit 146 und einen Puffer 144 auf. Die Videopumpe 120 liest die Inhalts-Daten asynchron von den Platten 114. Um die Inhalts-Daten zu lesen, fordert die Vorauslese-Einheit 146 die Übertragung eines bestimmten Abschnitts von Inhalts-Daten an, und die Platten 114 antworten entweder mittels Sendens der angeforderten Inhalts-Daten oder mittels Anzeigens, dass die angeforderten Daten nicht gesendet werden können. Einige Latenzzeit tritt zwischen der Zeit auf, zu der die Vorauslese-Einheit 146 die Daten anfordert, und der Zeit, zu der die Daten von der Videopumpe 120 empfangen werden.
  • Wenn die Inhalts-Daten von der Datei 134 bei der Videopumpe 120 ankommen, speichert die Videopumpe 120 die Inhalts-Daten von der Datei 134 in den Puffer 144. Sobald die Bandbreite auf dem Netzwerk 150 verfügbar wird, überträgt die Videopumpe 120 die Inhalts-Daten vom Puffer 144 über das Netzwerk 150 zu dem Client 122. Wie bei dem Video-Server 106 werden Inhalts-Daten im Voraus gelesen und in der Videopumpe 120 in Einheiten gepuffert, die einem Raid-Stripe entsprechen, wenn Raid-Speichertechniken verwendet werden.
  • Wie oben erläutert, kopiert die Videopumpe 120 typischerweise Daten von einem Raid-Stripe in Netzwerk-Puffer und liest den folgenden Stripe im Voraus. Auf ähnliche Weise schreibt der Videoserver 106 einen Inhalt-Raid-Stripe in den Datenspeicher und empfängt Daten vom Netzwerk in einen zweiten Speicherpuffer. Folglich sind typischerweise vier Raid-Stripes „in der Übertragung", so dass die Latenz zwischen dem Zeitpunkt, zu dem irgendwelche Inhalts-Daten erzeugt werden, und dem Zeitpunkt, zu dem sie verfügbar sind, um abgespielt zu werden, ungefähr die Zeit ist, die notwendig ist, um vier Raid-Stripes, gefüllt mit Daten, zuzuführen.
  • Raid-Stripes betragen gewöhnlicherweise 128 KBit oder 256 KBit pro Platte. Die kombinierte Gesamtgröße aller Platten in einem Raid-Stripe beträgt deshalb 1 bis 2 Megabit. Bei typischen MPEG-Dateien wird jeder Raid-Stripe ungefähr einer Sekunde des Videos entsprechen. Folglich führt dies mit vier Raid-Stripes auf dem Wege zu einer minimalen Latenzzeit von ungefähr 4 Sekunden.
  • Die Auswirkung auf Tag-Daten ist die, dass ein Tag von dem Video-Server 106 zur Verwendung durch andere Geräte freigegeben werden kann, wenn der entsprechende Inhalt verfügbar ist, abgespielt zu werden (d. h., der Inhalt für zwei Sekunden wurde erfolgreich auf der Platte gespeichert). Daher werden bei einem Video-Zuführsystem, bei dem die Inhalts-Zuführung vier Sekunden Latenzzeit benötigt, die Tag-Daten, die im Tag-Puffer 108 verblieben sind, nicht eher als vier Sekunden nach der Erzeugung des entsprechenden Inhalts übertragen.
  • Gemäß einem Ausführungsbeispiel werden die Schwankung und das Stehenbleiben beide durch das Übertragen eines Stapels von Tag-Daten vom Tag-Puffer 108 zum MDS 112 alle 12 Sekunden verhindert. Der Tag-Daten-Stapel, der in einem Intervall von jeweils 12 Sekunden übertragen wird, weist alle Tag-Informationen im Tag-Puffer 108 auf, die zumindest 12 Sekunden alt sind. Die Tag-Daten, die weniger als 12 Sekunden alt sind, bleiben im Tag-Puffer 108 erhalten und werden zum MDS 112 in einem Stapel am Ende des nächsten 12-Sekunden-Intervalls übertragen. Der MDS-Server 110 sendet die Tag-Daten an verschiedene Geräte (beispielsweise die Videopumpe 120), die die Videodatei 134 lesen, und speichert dann die Tag-Information auf den Platten 114.
  • Digitale Kanäle
  • Videodateien, die für spezifische audio-visuelle Arbeiten, wie beispielsweise Sportereignisse, erzeugt worden sind, weisen eine endliche Länge auf. Folglich verbrauchen deren entsprechende Inhalts-Dateien ebenfalls eine endliche Menge an Speicher, was es praktikabel macht, die gesamte Inhalts-Datei für eine spätere Ansicht zu speichern. Jedoch ist ein herkömmlicher Fernseh-„Kanal" aus einer nicht endenden Sequenz von audio-visuellen Arbeiten zusammengesetzt. Das fortwährende Verbleiben des gesamten Inhalts des digitalen Kanals würde den kontinuierlichen Speicherverbrauch auf einen unakzeptabel hohen Wert treiben. Andererseits ist es wünschenswert, Nutzern zu ermöglichen, sich Programme anzusehen, die sie noch nicht befähigt waren, sich zu der Zeit anzuschauen, zu der die Programme ursprünglich gesendet worden sind. Beispielsweise wäre es für einen Zuschauer wünschenswert, einen Zugriff auf die letzten 24 Stunden des Programms zu haben, das über einen digitalen Kanal ausgesendet worden ist. Gemäß einem Ausführungsbeispiel der Erfindung wird das herkömmliche Anschauen für eine Endlos-Zuführung durch die Verwendung eines kontinuierlichen endlichen Puffers bereitgestellt, wobei ältere Daten „ablaufen" und mit neuen Daten überschrieben werden.
  • Inhalts-Ablauf
  • Um einen kontinuierlichen Daten-Puffer zu haben, beispielsweise die letzten 24 Stunden der Lebenszeit, Fernsehen für Frauen, muss älterer Inhalt mit den entsprechenden Tags gelöscht werden. Es können verschiedene Ansätze verwendet werden, um solch einen kontinuierlichen Puffer zu implementieren.
  • In Bezug auf die Inhalts-Daten ist der einfachste Ansatz, um einen kontinuierlichen Puffer zu implementieren, eine einzelne Datei zu erzeugen, die groß genug ist, Filmmaterial mit einer Länge von 24 Stunden zu halten. Die Datei wird dann als Ring-Puffer behandelt. Insbesondere würde der MDS-Server 110 nach der Erzeugung der initialen 24 Stunden-Datei den Beginn der Datei als den aktuellen „Einstiegspunkt" setzen. Der MDS-Server 110 würde dann die neuen Inhalts-Daten über die alten Daten am Einstiegspunkt speichern und den Einstiegspunkt an das Ende der neuen Daten bewegen. Wenn der Einstiegspunkt auf das Ende der Datei trifft, wird er umlaufend erneut auf den Beginn der Datei gesetzt.
  • Unglücklicherweise macht es dieser Einzel-Datei-Ringpuffer-Ansatz schwierig, die Zeitdauer der Datei zu vergrößern oder zu verkleinern. Beispielsweise wird angenommen, dass sich der Einstiegspunkt in der Mitte der Datei befindet, und eine Entscheidung wird getätigt, die Datei zu vergrößern, so dass sie 48 Stunden fasst. Unter diesen Umständen könnte der MDS-Server 110 nicht beginnen, die Zeit zu erhöhen, für die weitere 12 Stunden abgedeckt sind, wenn der Einstiegspunkt das Ende der Datei erreicht haben würde. Unter Verwenden des Einzel-Ringpuffer-Ansatzes ist es ebenso schwierig zu erfassen, wenn ein Client pausiert hat und sich der „Horizont" über die Einstiegspunkt-Position bewegt hat, so dass, wenn der Client den Inhalt fortsetzt, er sehen würde, dass der Inhalt überschrieben ist.
  • 4 stellt einen alternativen, flexibleren Ansatz zum Puffern einer vorbestimmten Menge einer Endlos-Videozufuhr dar. Bezugnehmend auf 4 werden die Inhalts-Daten in einer Gruppe kleinerer Dateien 402–414 gespeichert. Jede der kleineren Dateien speichert einen Teil(Sub)-Satz der gepufferten Inhalts-Daten. Bei dem dargestellten Ausführungsbeispiel speichert jede der Dateien 402–412 zwei Stunden Nutzinhalt. Die Datei 414 speichert zurzeit eine Stunde Inhalt. Der aktuelle Einstiegspunkt befindet sich am Ende der Datei 414. Erreicht die Datei 414 zwei Stunden Inhalt, wird die Datei 414 geschlossen, und eine neue Inhalts-Datei wird erzeugt. Da Inhalts-Dateien altern, werden die älteren Inhalts-Dateien gelöscht, um Plattenspeicher für neue Dateien freizumachen. Während der Wiedergabe werden die Dateien von der Videopumpe nahtlos zusammengefügt, wie die Inhalts-Daten an den Client gesendet werden.
  • Wenn die Pufferungstechnik, wie in 4 dargestellt, verwendet wird, kann eine nachsichtige Ablauf-Strategie eingestellt werden. Insbesondere kann eine Strategie aufgestellt werden, dass eine Datei nicht gelöscht wird, bis alle Clients die Datei abgeschlossen haben (die Datei und irgendwelche Dateien, die der Datei vorausgehen). Beispielsweise wird angenommen, dass es Nutzern ermöglicht wird, auf die letzten 12 Stunden einer Zuführung zuzugreifen. Ist die Datei 414 abgeschlossen, enthalten die Dateien 404–414 die letzten 12 Stunden, so dass die Datei 402 nicht länger erforderlich ist. Jedoch kann sich ein Client die Inhalte der Datei 402 zurzeit anschauen. Folglich wird die Datei 402 nicht unmittelbar gelöscht. Stattdessen werden neue Clients daran gehindert, auf die Datei 402 zuzugreifen, aber dem Client, der zurzeit auf die Datei 402 zugreift, wird ermöglicht, das Abspielen der Datei 402 zu beenden. Wenn der letzte Client das Abspielen der Datei 402 beendet hat, wird die Datei 402 gelöscht.
  • Um einen Abschluss auf die Anzahl bestehender Dateien zu setzen, kann für Clients eine zeitliche Grenze aufgestellt werden, um das Abspielen alter Dateien zu beenden. Beispielsweise, wenn die Datei 414 abgeschlossen ist, werden nicht nur neue Clients daran gehindert, auf die Datei 402 zuzugreifen, sondern den Clients, die zurzeit auf die Datei 402 zugreifen, wird zwei Stunden gegeben, um das Abspielen der Datei 402 zu beenden. Am Ende der zwei Stunden wird dann die Datei 402 gelöscht, um Plattenspeicher freizumachen, unabhängig davon, ob irgendeiner der Clients immer noch die Datei 402 liest.
  • Tag-Ablauf
  • Wird eine Inhalts-Datei (beispielsweise Datei 402) gelöscht, werden die Tags, die der gelöschten Datei entsprechen, als „abgelaufen" betrachtet, und können deshalb gelöscht werden. Idealerweise sind Tags in einem Format gespeichert, wie beispielsweise einer Datenbank-Tabelle, was es ermöglicht, alte Tags leicht zu löschen ebenso wie neue hinzuzufügen. Unglücklicherweise kann der Overhead, der mit dem Speichern und Abfragen von Tags von einer Datenbank-Tabelle verbunden ist, zu teuer sein, um praktikabel unter Live-Zuführ-Bedingungen zu sein. Für einen einfachen und schnellen Zugriff werden Tags deshalb typischerweise in einer flachen Datei (Flat File) gespeichert.
  • Bezugnehmend auf 5 ist dort eine flache Tag-Datei 500 dargestellt. Die flache Tag-Datei 500 weist einen Header 502 auf, gefolgt von einem Satz von Tags 504. Der Header 502 kennzeichnet Informationen über den Inhalt der Tag-Datei 500 inklusive des Satzes von Inhalts-Dateien, denen die Tags innerhalb der Tag-Datei 500 entsprechen.
  • Kommen neue Tags hinzu, werden die Tags an die Tag-Datei 500 angehängt. Da die Tag-Datei 500 einer kontinuierlichen Zuführung zugeordnet ist, wird die Tag-Datei undefinierbar groß, wenn kein Mechanismus zum Löschen abgelaufener Tags vorgesehen ist. Jedoch sollte die Tag-Datei 500 selbst gültig bleiben, selbst nach dem Ablauf einiger Tags (beispielsweise der Tags 510) innerhalb der Tag-Datei 500, da Clients auf die Tags 512 innerhalb der Tag-Datei 500 zugreifen können und diese nutzen können, die noch nicht abgelaufen sind. Daher kann der Ablauf-Mechanismus nicht einfach die abgelaufenen Tags 510 aus der Tag-Datei 500 löschen.
  • Stattdessen wird eine temporäre Tag-Datei 514 mittels Erstellens eines neuen Headers 506 und Anhängens des neuen Headers 506 als Kopie der nicht abgelaufenen Tags 512 von der alten Tag-Datei 500 aufgebaut, als dass die abgelaufenen Tags innerhalb der Tag-Datei 500 direkt aus ihr gelöscht werden. Der neue Header 506 weist die gleiche Information auf wie der alte Header 502, abgesehen davon, dass die Daten innerhalb des Headers 502 kennzeichnen, dass die Tag-Datei 500 Tags für die gelöschte Inhalts-Datei aufweist, während die Daten innerhalb des Headers 506 dies nicht tun.
  • Während die neue Tag-Datei 514 erzeugt wird, werden neue Tag-Daten sowohl an die neue Tag-Datei 514 als auch an die alte Tag-Datei 500 angehängt. Nachdem die neue Tag-Datei 514 erzeugt worden ist, werden neue Tag-Daten an die neue Tag- Datei 514 angehängt, statt dass sie an die alte Tag-Datei 500 angehängt werden. Um sicherzustellen, dass die neuen Tag-Daten nach den Tag-Daten 512 angehängt werden, ist im Voraus ein Speicherbereich für die zu kopierenden Tags 512 in der neuen Tag-Datei 514 vorgesehen, und die neuen Tags werden nach dem vorgegebenen Speicherbereich angehängt, während die bestehenden Tags 512 in den vorgegebenen Speicherbereich kopiert werden.
  • Wenn alle der nicht abgelaufenen Tags 512 in die neue Tag-Datei 514 kopiert worden sind, wird die alte Tag-Datei 500 geschlossen, und die neue Tag-Datei 514 wird auf den Namen der alten Tag-Datei 500 umbenannt. Nachdem die neue Tag-Datei 514 umbenannt worden ist, werden die Tag-Datei-Lesevorrichtungen (beispielsweise der Stream-Server 118), die die alte Tag-Datei 500 verwendet haben, basierend auf der Information zurückgesetzt, die im Header der neuen Tag-Datei 514 enthalten ist. Gemäß einem Ausführungsbeispiel (dem „Push-Modell") werden Nachrichten an die Tag-Datei-Lesevorrichtungen gesendet, um sie ausdrücklich zu informieren, dass die Tag-Datei geändert worden ist, und dass sie sich selbst basierend auf der Header-Information in der neuen Tag-Datei 514 aktualisieren sollen.
  • Gemäß einem alternativen „Pull-Modell"-Ausführungsbeispiel werden die Tag-Datei-Lesevorrichtungen nicht ausdrücklich informiert. Stattdessen sind diese so konfiguriert, dass sie basierend auf der Header-Information der neuen Tag-Datei selbst lesen und sich aktualisieren, wann immer sie bei einem Versuch, ein Tag zu lesen, fehlschlagen. Der Pull-Modell-Ansatz hat den Vorteil, dass er die Übertragung von Nachrichten verhindert, die unter vielen Umständen nicht notwendig sind.
  • Wenn Tags, die einem bestimmten Inhaltsegment zugeordnet sind, gelöscht werden, können Clients fortsetzen, sich das Inhalts-Segment anzuschauen. Jedoch sind die Clients nicht befähigt, einen nicht-sequenziellen Zugriff auf Operationen durchzuführen, die die gelöschte Tag-Information erfordern, wie beispielsweise schnelles Vorspulen und Zurückspulen.
  • Zuweisung von Datum und Uhrzeit
  • Die Tag-Information weist eine Zeitstempel-Information für jedes der Bilder in den entsprechenden Inhalts-Daten auf. Zum Zwecke des Dekodierens stellt die Zeitstempel-Information typischerweise die Zeit in Bezug zum Beginn einer Zuführung (d. h. die „Darstellungszeit") dar und wird auf den Byte-Offset in der Inhalts-Datei des Bildes abgebildet, der dieser Darstellungszeit entspricht. Jedoch können für solche kontinuierlichen Zuführungen solche relativen Zeitwerte nicht bedeutsam sein. Beispielsweise würde ein Nutzer wollen, eine Wiedergabe, beginnend am 21. Januar 1997, 16:30:23 Uhr, anzufordern, statt dass er 5 345 789,76 Sekunden nach der Zeit an startet, zu der eine Station begonnen hat zu senden.
  • Absolute Zeitwerte werden mittels Speicherns eines absoluten Zeitwertes unterstützt, der dem relativen Zeitwert „0" entspricht. Deshalb wird der absolute Zeitwert, der „0" zugeordnet ist, wenn ein Client die Wiedergabe von einer absoluten Zeit bestimmt, vom bestimmten absoluten Zeitwert subtrahiert, um einen relativen Zeitwert zu erhalten. Der relative Zeitwert wird dann mittels des Stream-Servers 118 verwendet, um die geeignete Tag-Information zu identifizieren, und die Tag-Information wird vom Stream-Server 118 verwendet, eine Videopumpe 120 dazu zu bringen, das Senden von Inhalt von der geeigneten Position in der Inhalts-Datei 134 an zu senden.
  • Typischerweise stellen die Transportformate digitaler Videos eine feste Anzahl von Bits (beispielsweise 33 Bit) bereit, um Zeitstempel darzustellen. Für kontinuierliche Zuführ-Umgebungen werden die relativen Zeitstempelwerte unvermeidlich Zahlen erreichen, die nicht mit der Bit-Anzahl darstellbar sind, die im Transportformat verfügbar ist. Wenn dies geschieht, „laufen" die Zeitstempelwerte „um" und beginnen wieder bei 0.
  • Um dem Umlauf-Problem zu begegnen, wird ein Umlaufwert mit höherer Genauigkeit (beispielsweise 64 Bit) verwaltet. Beim Durchführen einer Suche oder eines anderen nichtsequenziellen Zugriffs verwendet der Stream-Server 118 die Zeitstempelwerte mit höherer Genauigkeit. Beim Übertragen von Inhalt an einen Client sendet die Videopumpe 120 die Zeitstempel mit geringerer Genauigkeit.
  • Die Video-Kodier- und Zuführ-Techniken, wie an dieser Stelle beschrieben, ermächtigen Nutzer mit Funktionssteuerungen, die sich vorher ausschließlich in der Domäne von Programm-Anbietern befanden. Beispielsweise bestimmen zurzeit Programm-Anbieter, welche Spiele der SuperBow1 Zuschauern wiedergegeben werden, die Geschwindigkeit, mit der sie wiedergegeben werden, und wie oft sie wiedergegeben werden.
  • Jedoch haben Zuschauer meist stark unterschiedliche Meinungen darüber, wie die Leistungen des mehrfachen Zuschauens zu bewerten sind. Beispielsweise können zwei Zuschauer die Genauigkeit eines bestimmten Anrufs diskutieren. Jedoch kann der Programm-Anbieter das Spiel nicht beachten, das es einen Anstieg in der Bedeutung auf den Anruf hin gegeben hat, um bedeutsam genug zu sein, das Spiel zu wiederholen. Unter Verwenden der an dieser Stelle bereitgestellten Techniken können Zuschauer selbst entscheiden, welche Spiele unmittelbar wiederholt werden sollen, mit welcher Geschwindigkeit sie wiederholt werden sollen, und wie oft sie wiederholt werden sollen.
  • In der vorangegangenen Beschreibung wurde die Erfindung unter Bezugnahme auf deren spezifische Ausführungsbeispiele beschrieben. Es ist jedoch offensichtlich, dass verschiedene Modifikationen und Änderungen machbar sind. Die Beschreibung und die Figuren sind demgemäß eher in einem erläuternden als in einem einschränkenden Sinne zu beachten.

Claims (23)

  1. Verfahren zum Zuführen einer Direkt-Eingabe einem Client (122), aufweisend die Schritte des Erzeugens von Tag-Daten (132), welche die Position von Video-Frame-Daten innerhalb von Inhalts-Daten anzeigen, wobei die Daten-Frames in einer besonderen Kodier-Reihenfolge innerhalb der Inhalts-Daten kodiert sind, wobei die Inhalts-Daten an einer Position gespeichert werden, von der die Inhalts-Daten dem Client (122) zugeführt werden, wobei das Verfahren gekennzeichnet ist durch: Speichern der Tag-Daten (132) an einer Position, von der die Tag-Daten (132) verwendet werden können, um dem Client (122) einen nicht-sequenziellen Zugriff auf die Inhalts-Daten bereitzustellen, wobei der Zugriff nur bereitgestellt wird, nachdem eine Verzögerungszeit in Bezug auf den Zeitpunkt abgelaufen ist, zu dem die entsprechenden Inhalts-Daten verfügbar gemacht worden sind; bevor die Inhalts-Daten vollständig erzeugt sind, Durchführen der Schritte: Empfangen einer Anforderung vom Client (122) für einen nicht-sequenziellen Zugriff auf die Inhalts-Daten, wobei mittels der Anforderung für den nicht-sequenziellen Zugriff Daten-Frames angefordert werden, die an den Client (122) in einer Reihenfolge zu senden sind, die sich von der besonderen Kodier-Reihenfolge unterscheidet; Erstellen von zweiten Inhalts-Daten basierend auf den Inhalts-Daten, der Tag-Daten (132) und der Anforderung für einen nicht-sequenziellen Zugriff, wobei die zweiten Inhalts-Daten Daten-Frames aus den Inhalts-Daten aufweisen, die in der Reihenfolge angeordnet sind, die sich von der besonderen Kodier-Reihenfolge unterscheidet; und Übertragen der zweiten Inhalts-Daten an den Client (122).
  2. Verfahren gemäß Anspruch 1, ferner dadurch gekennzeichnet, dass: die Inhalts-Daten eine Sequenz von Video-Frame-Daten enthalten; jedes der Video-Frame-Daten in der Sequenz von Video-Frame-Daten einem Video-Frame entspricht; der Schritt des Erstellens der zweiten Inhalts-Daten die Schritte aufweist: Auswählen eines ausgewählten Satzes von Video-Frames innerhalb der Inhalts-Daten basierend auf den Tag-Daten (132) als Antwort auf die Anforderungen vom Client (122) für einen nicht-sequenziellen Zugriff; und Erstellen der zweiten Inhalts-Daten, sodass sie die Video-Frame-Daten aufweisen, die jeweils einem Video-Frame des ausgewählten Satzes von Video-Frames entsprechen.
  3. Verfahren gemäß Anspruch 1, wobei der Schritt des Erzeugens der Tag-Daten (132) ein Parsen der Inhalts-Daten aufweist.
  4. Verfahren gemäß Anspruch 1, wobei der Schritt des Erzeugens der Tag-Daten (132) mittels eines Kodierers (101) durchgeführt wird, wobei das Erzeugen beginnt, bevor die Inhalts-Daten vollständig kodiert sind.
  5. Verfahren gemäß Anspruch 4, wobei der Schritt des Erzeugens der Tag-Daten (132) mittels des Kodierers (101) durchgeführt wird, während der Kodierer (101) die Inhalts-Daten erzeugt.
  6. Verfahren gemäß Anspruch 1, ferner aufweisend den Schritt des Bringens einer Video-Pumpe (120), die mit einem Kommunikationskanal gekoppelt ist, dazu, die Inhalts-Daten an den Client (122) mittels des Kommunikationskanals zu übertragen und dem Client (122) einen nicht-sequenziellen Zugriff auf die Inhalts-Daten basierend auf den Tag-Daten (132) bereitzustellen.
  7. Verfahren gemäß Anspruch 6, ferner aufweisend den Schritt des Bringens eines Video-Servers (106), der mit der Video- Pumpe (120) gekoppelt ist, dazu, die Tag-Daten (132) der Video-Pumpe (120) verfügbar zu machen.
  8. Verfahren gemäß Anspruch 6, ferner aufweisend ein Speichersystem (112), das mit der Video-Pumpe (120) gekoppelt ist, wobei das Speichersystem einen Server aufweist, der die Inhalts-Daten an die Video-Pumpe (120) überträgt, wenn dies die Video-Pumpe (120) anfordert, und der eine Ende-der-Datei-Information für die Inhalts-Daten an die Video-Pumpe (120) sendet, ohne dass die Video-Pumpe (120) die Ende-der-Datei-Information anfordert.
  9. Verfahren gemäß Anspruch 6, ferner gekennzeichnet durch: Erzeugen digitaler Information, wobei die digitale Information mittels eines CODEC (102) als Antwort auf das Empfangen visueller Information erzeugt wird; Anordnen der mittels des CODEC (1029) erzeugten digitalen Information gemäß einem digitalen Videoformat mittels eines Multiplexers (104), der mit dem CODEC (102) gekoppelt ist; und Erzeugen der Tag-Daten (132) mittels des Multiplexers (104), um zu kennzeichnen, wie der Multiplexer (104) die digitale Information angeordnet hat.
  10. Verfahren gemäß Anspruch 6, ferner gekennzeichnet durch: Empfangen der Inhalts-Daten und der Tag-Daten (132) an einem Video-Server (106), wobei die Inhalts- und Tag-Daten (132) von einem Kodierer (101) empfangen werden, der mit dem Video-Server (106) gekoppelt ist; Übertragen der Inhalts-Daten und der Tag-Daten (132) von dem Video-Server (106) zu einem Medien-Daten-Speicher(MDS)-System (112); Empfangen der Inhalts-Daten und der Tag-Daten (132) von dem Video-Server (106) an dem MDS-System und Speichern der Inhalts-Daten und der Tag-Daten (132) auf einem oder mehreren Speichereinrichtungen, die dem MDS-System (112) zugeordnet sind; und Lesen der Inhalts-Daten von einem oder mehreren der Speichereinrichtungen des MDS-Systems (112) mittels der Video-Pumpe (120).
  11. Computerlesbares Medium, das Sequenzen von Befehlen trägt zum Zuführen einer Direkt-Eingabe an einen Client (122), wobei das computerlesbare Medium Befehle zum Erzeugen von Tag-Daten (132) trägt, die Positionen von Video-Frame-Daten innerhalb der Inhalts-Daten anzeigen, wobei die Daten-Frames in einer besonderen Kodier-Reihenfolge innerhalb der Inhalts-Daten kodiert sind, und das ferner Befehle trägt zum Speichern der Inhalts-Daten an einer Position, von der die Inhalts-Daten dem Client (122) zugeführt werden, wobei das computerlesbare Medium dadurch gekennzeichnet ist, dass es Sequenzen von Befehlen aufweist zum Ausführen der Schritte: Speichern der Tag-Daten (132) an einer Position, von der die Tag-Daten (132) verwendet werden können, um dem Client (122) einen nicht-sequenziellen Zugriff auf die Inhalts-Daten bereitzustellen, wobei der Zugriff nur bereitgestellt wird, nachdem eine Verzögerungszeit in Bezug auf den Zeitpunkt abgelaufen ist, zu dem die entsprechenden Inhalts-Daten verfügbar gemacht worden sind; bevor die Inhalts-Daten vollständig erzeugt worden sind, Durchführen der Schritte: Empfangen einer Anforderung vom Client (122) für einen nicht-sequenziellen Zugriff auf die Inhalts-Daten, wobei mittels der Anforderung für den nicht-sequenziellen Zugriff Daten-Frames angefordert werden, die an den Client (122) in einer Reihenfolge zu senden sind, die sich von der besonderen Kodier-Reihenfolge unterscheidet; Erstellen von zweiten Inhalts-Daten basierend auf den Inhalts-Daten, der Tag-Daten (132) und der Anforderung für einen nicht-sequenziellen Zugriff, wobei die zweiten Inhalts-Daten Daten-Frames aus den Inhalts-Daten aufweisen, die in der Reihenfolge angeordnet sind, die sich von der besonderen Kodier-Reihenfolge unterscheidet; und Übertragen der zweiten Inhalts-Daten an den Client (122).
  12. Computerlesbares Medium gemäß Anspruch 11, ferner dadurch gekennzeichnet, dass: die Inhalts-Daten eine Sequenz von Video-Frame-Daten enthalten; jedes der Video-Frame-Daten in der Sequenz von Video-Frame-Daten einem Video-Frame entspricht; der Schritt des Erstellens der zweiten Inhalts-Daten die Schritte aufweist: Auswählen eines ausgewählten Satzes von Video-Frames innerhalb der Inhalts-Daten basierend auf den Tag-Daten (132) als Antwort auf die Anforderung vom Client (122) für den nicht-sequenziellen Zugriff; und Erstellen der zweiten Inhalts-Daten, sodass sie die Video-Frame-Daten aufweisen, die jeweils einem Video-Frame des ausgewählten Satzes von Video-Frames entsprechen.
  13. Computerlesbares Medium gemäß Anspruch 11, wobei der Schritt des Erzeugens der Tag-Daten (132) ein Parsen der Inhalts-Daten aufweist.
  14. Computerlesbares Medium gemäß Anspruch 11, wobei der Schritt des Erzeugens der Tag-Daten (132) mittels eines Kodierers (101) durchgeführt wird, wobei das Erzeugen beginnt, bevor die Inhalts-Daten vollständig kodiert sind.
  15. Computerlesbares Medium gemäß Anspruch 14, wobei der Schritt des Erzeugens der Tag-Daten (132) mittels des Kodierers (101) durchgeführt wird, während der Kodierer (101) die Inhalts-Daten erzeugt.
  16. Computerlesbares Medium gemäß Anspruch 11, ferner aufweisend Befehle zum Durchführen des Schrittes des Bringens einer Video-Pumpe (120), die mit einem Kommunikationskanal gekoppelt ist, dazu, die Inhalts-Daten an den Client (122) mittels des Kommunikationskanals zu übertragen und dem Client (122) einen nicht-sequenziellen Zugriff auf die Inhalts-Daten basierend auf den Tag-Daten (132) bereitzustellen.
  17. Computerlesbares Medium gemäß Anspruch 16, ferner aufweisend Befehle zum Durchführen des Schrittes des Bringens eines Video-Servers (106), der mit der Video-Pumpe (120) gekoppelt ist, dazu, die Tag-Daten (132) der Video-Pumpe (120) verfügbar zu machen.
  18. Video-Zuführ-System (100), das einen Mechanismus zum Erzeugen von Tag-Daten (132) aufweist, die Positionen von Video-Frame-Daten innerhalb der Inhalts-Daten anzeigen, wobei die Daten-Frames in einer besonderen Kodier-Reihenfolge innerhalb der Inhalts-Daten kodiert sind, wobei ein Video-Server (106) derart konfiguriert ist, dass er Inhalts-Daten an einer Position speichert, von der die Inhalts-Daten einem Client (122) zugeführt werden, gekennzeichnet durch: ein Speichersystem, das die Tag-Daten (132) an einer bestimmten Position derart speichert, dass die Tag-Daten (132) verwendet werden können, um dem Client (122) einen nicht-sequenziellen Zugriff auf die Inhalts-Daten bereitzustellen, wobei der Zugriff nur bereitgestellt wird, nachdem eine Verzögerungszeit in Bezug auf den Zeitpunkt abgelaufen ist, zu dem die entsprechenden Inhalts-Daten verfügbar gemacht worden sind; und ein Video-Zuführ-Subsystem, das derart konfiguriert ist, dass, bevor die Inhalts-Daten vollständig erzeugt sind, die folgenden Aktionen durchgeführt werden: Empfangen einer Anforderung vom Client (122) für einen nicht-sequenziellen Zugriff auf die Inhalts-Daten, wobei mittels der Anforderung für den nicht-sequenziellen Zugriff Daten-Frames angefordert werden, die an den Client (122) in einer Reihenfolge zu senden sind, die sich von der besonderen Kodier-Reihenfolge unterscheidet; Erstellen von zweiten Inhalts-Daten basierend auf den Inhalts-Daten, den Tag-Daten (132) und den Anforderungen für einen nicht-sequenziellen Zugriff, wobei die zweiten Inhalts-Daten Daten-Frames aus den Inhalts-Daten aufweisen, die in der Reihenfolge angeordnet sind, die sich von der besonderen Kodier-Reihenfolge unterscheidet; und Übertragen der zweiten Inhalts-Daten an den Client (122).
  19. System gemäß Anspruch 18, ferner dadurch gekennzeichnet, dass: die Inhalts-Daten eine Sequenz von Video-Frame-Daten enthalten; jedes der Video-Frame-Daten in der Sequenz von Video-Frame-Daten einem Video-Frame entspricht; das Video-Zuführ-Subsystem derart konfiguriert ist, dass es die zweiten Inhalts-Daten erstellt mittels: Auswählens eines ausgewählten Satzes von Video-Frames innerhalb der Inhalts-Daten basierend auf den Tag-Daten (132) als Antwort auf die Anforderung vom Client (122) für einen nicht-sequenziellen Zugriff; und Erstellens der zweiten Inhalts-Daten, sodass sie die Video-Frame-Daten aufweisen, die jeweils einem Video-Frame des ausgewählten Satzes von Video-Frames entsprechen.
  20. System gemäß Anspruch 18, wobei mittels des Mechanismus Tag-Daten (132) mittels Parsens der Inhalts-Daten erzeugt werden.
  21. System gemäß Anspruch 18, wobei der Mechanismus ein Kodierer (101) ist, der die Inhalts-Daten erzeugt, wobei das Erzeugen beginnt, bevor die Inhalts-Daten vollständig kodiert sind.
  22. System gemäß Anspruch 18, ferner aufweisend: einen Kodierer (101), der die Inhalts-Daten erzeugt; eine Video-Pumpe (120), die zwischen dem Kodierer (101) und einem Kommunikations-Kanal gekoppelt ist, wobei die Video-Pumpe (120) konfiguriert ist, um die Inhalts-Daten an den Client (122) mittels des Kommunikationskanals zu übertragen und dem Client (122) einen nicht-sequenziellen Zugriff auf die Inhalts-Daten basierend auf den Tag-Daten (132) bereitzustellen.
  23. System gemäß Anspruch 22, wobei der Video-Server (106) zwischen dem Kodierer (101) und der Video-Pumpe (120) gekoppelt ist, wobei der Video-Server (106) derart konfiguriert ist, dass er der Video-Pumpe (120) die Tag-Daten (132) verfügbar macht.
DE69812994T 1997-10-22 1998-10-19 Verfahren und vorrichtung für nicht-sequentiellen zugang zu einem laufenden videoprogramm Active DE69812994T9 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US956263 1997-10-22
US08/956,263 US6119154A (en) 1995-07-14 1997-10-22 Method and apparatus for non-sequential access to an in-progress video feed
PCT/US1998/022014 WO1999021363A1 (en) 1997-10-22 1998-10-19 Method and apparatus for non-sequential access to an in-progress video feed

Publications (3)

Publication Number Publication Date
DE69812994D1 DE69812994D1 (de) 2003-05-08
DE69812994T2 DE69812994T2 (de) 2004-02-12
DE69812994T9 true DE69812994T9 (de) 2005-02-03

Family

ID=25498000

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69812994T Active DE69812994T9 (de) 1997-10-22 1998-10-19 Verfahren und vorrichtung für nicht-sequentiellen zugang zu einem laufenden videoprogramm

Country Status (8)

Country Link
US (1) US6119154A (de)
EP (1) EP1025700B1 (de)
JP (1) JP4936592B2 (de)
AU (1) AU755447B2 (de)
CA (1) CA2306934C (de)
DE (1) DE69812994T9 (de)
HK (1) HK1028859A1 (de)
WO (1) WO1999021363A1 (de)

Families Citing this family (111)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5990927A (en) 1992-12-09 1999-11-23 Discovery Communications, Inc. Advanced set top terminal for cable television delivery systems
US7721307B2 (en) * 1992-12-09 2010-05-18 Comcast Ip Holdings I, Llc Method and apparatus for targeting of interactive virtual objects
US9286294B2 (en) * 1992-12-09 2016-03-15 Comcast Ip Holdings I, Llc Video and digital multimedia aggregator content suggestion engine
US7168084B1 (en) 1992-12-09 2007-01-23 Sedna Patent Services, Llc Method and apparatus for targeting virtual objects
US6292837B1 (en) * 1997-10-30 2001-09-18 Daniel Miller Apparatus and method for non-sequential image data transmission and display
US6453355B1 (en) * 1998-01-15 2002-09-17 Apple Computer, Inc. Method and apparatus for media data transmission
US6134243A (en) 1998-01-15 2000-10-17 Apple Computer, Inc. Method and apparatus for media data transmission
US8220017B1 (en) * 1998-04-30 2012-07-10 International Business Machines Corporation System and method for programmatic generation of continuous media presentations
US9009773B1 (en) 1998-06-30 2015-04-14 Cox Communications, Inc. Method and apparatus for providing broadcast data services
US6748421B1 (en) * 1998-12-23 2004-06-08 Canon Kabushiki Kaisha Method and system for conveying video messages
CN100435569C (zh) * 1999-07-14 2008-11-19 松下电器产业株式会社 信息提供装置、信息提供方法以及信息通信系统
US6711619B1 (en) * 1999-12-15 2004-03-23 Hewlett-Packard Development Company, L.P. Method, system, and apparatus for distributing and using computer-based applications over a network
SE9904685D0 (sv) * 1999-12-17 1999-12-17 Switchcore Ab A programmable packet decoder
AU2001237978A1 (en) * 2000-01-28 2001-08-07 Diva Systems Corporation A system for preprocessing content for streaming server
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
US7788686B1 (en) * 2000-03-01 2010-08-31 Andrews Christopher C Method of and apparatus for describing, promoting, publishing, aggregating, distributing and accessing live content information
JP2001285806A (ja) * 2000-04-03 2001-10-12 Nec Corp 映像・音声作製方法およびシステム
US7260564B1 (en) 2000-04-07 2007-08-21 Virage, Inc. Network video guide and spidering
US8171509B1 (en) 2000-04-07 2012-05-01 Virage, Inc. System and method for applying a database to video multimedia
US7962948B1 (en) 2000-04-07 2011-06-14 Virage, Inc. Video-enabled community building
US7222163B1 (en) * 2000-04-07 2007-05-22 Virage, Inc. System and method for hosting of video content over a network
JP4538908B2 (ja) * 2000-06-14 2010-09-08 ソニー株式会社 データ変換装置及び方法
US7743330B1 (en) 2000-06-19 2010-06-22 Comcast Ip Holdings I, Llc Method and apparatus for placing virtual objects
US6892391B1 (en) * 2000-07-13 2005-05-10 Stefan Jones Dynamic generation of video content for presentation by a media server
JP4296461B2 (ja) * 2000-09-07 2009-07-15 ソニー株式会社 記録再生システム、サーバ装置、端末装置、映像データ提供方法、再生方法及びコンピュータ読取可能な記録媒体
US7861272B2 (en) * 2000-11-14 2010-12-28 Russ Samuel H Networked subscriber television distribution
US8127326B2 (en) 2000-11-14 2012-02-28 Claussen Paul J Proximity detection using wireless connectivity in a communications system
US7188357B1 (en) * 2000-11-16 2007-03-06 Unisys Corporation Video-on demand video server disk/memory streaming selection methodology
US20020120929A1 (en) * 2001-02-28 2002-08-29 Schwalb Eddie M. Method and system for mass customization of digital television broadcasts
US7143353B2 (en) * 2001-03-30 2006-11-28 Koninklijke Philips Electronics, N.V. Streaming video bookmarks
US6925649B2 (en) * 2001-03-30 2005-08-02 Sharp Laboratories Of America, Inc. Methods and systems for mass customization of digital television broadcasts in DASE environments
GB0108354D0 (en) * 2001-04-03 2001-05-23 Thirdspace Living Ltd System and method for providing a user with access to a plurality of sevices and content from a broadband television service
CA2386303C (en) 2001-05-14 2005-07-05 At&T Corp. Method for content-based non-linear control of multimedia playback
DE10125309C1 (de) * 2001-05-21 2002-12-12 Humatic Gmbh Verfahren und Anordnung zum Steuern von audiovisuellen medialen Inhalten
WO2002097611A1 (en) * 2001-05-25 2002-12-05 N2 Broadband, Inc. System and method for scheduling the distribution of assets from multiple asset providers to multiple receivers
US8024766B2 (en) * 2001-08-01 2011-09-20 Ericsson Television, Inc. System and method for distributing network-based personal video
US7908628B2 (en) 2001-08-03 2011-03-15 Comcast Ip Holdings I, Llc Video and digital multimedia aggregator content coding and formatting
US20030028890A1 (en) * 2001-08-03 2003-02-06 Swart William D. Video and digital multimedia acquisition and delivery system and method
US7793326B2 (en) 2001-08-03 2010-09-07 Comcast Ip Holdings I, Llc Video and digital multimedia aggregator
US8285701B2 (en) * 2001-08-03 2012-10-09 Comcast Ip Holdings I, Llc Video and digital multimedia aggregator remote content crawler
US20030028884A1 (en) * 2001-08-03 2003-02-06 Swart William D. Video and digital multimedia aggregator content availability notification system and method
US20090282444A1 (en) * 2001-12-04 2009-11-12 Vixs Systems, Inc. System and method for managing the presentation of video
FI116167B (fi) * 2001-12-18 2005-09-30 Valtion Teknillinen Arkistoiva tiedostopalvelin
US7764863B1 (en) * 2002-03-06 2010-07-27 Bigband Networks Inc. System and method for providing trick modes
KR20020057837A (ko) * 2002-03-29 2002-07-12 문의선 스트리밍 서비스 방법 및 장치
US7899924B2 (en) * 2002-04-19 2011-03-01 Oesterreicher Richard T Flexible streaming hardware
US20040006635A1 (en) * 2002-04-19 2004-01-08 Oesterreicher Richard T. Hybrid streaming platform
US20040006636A1 (en) * 2002-04-19 2004-01-08 Oesterreicher Richard T. Optimized digital media delivery engine
US20040025185A1 (en) * 2002-04-29 2004-02-05 John Goci Digital video jukebox network enterprise system
US20040010800A1 (en) * 2002-04-29 2004-01-15 John Goci Digital video jukebox network enterprise system
US7516470B2 (en) 2002-08-02 2009-04-07 Cisco Technology, Inc. Locally-updated interactive program guide
US7596630B2 (en) * 2002-09-30 2009-09-29 International Business Machines Corporation Method, system and computer program product for parsing an encoding
US7908625B2 (en) 2002-10-02 2011-03-15 Robertson Neil C Networked multimedia system
US8046806B2 (en) 2002-10-04 2011-10-25 Wall William E Multiroom point of deployment module
US7360235B2 (en) 2002-10-04 2008-04-15 Scientific-Atlanta, Inc. Systems and methods for operating a peripheral record/playback device in a networked multimedia system
US8094640B2 (en) 2003-01-15 2012-01-10 Robertson Neil C Full duplex wideband communications system for a local coaxial network
US20070058943A1 (en) * 2003-11-10 2007-03-15 Disclive, Inc. System, method and apparatus for rapid mass production of content-inclusive physical media
US7568209B1 (en) 2003-11-14 2009-07-28 Tanderberg Television, Inc. Method and system for the management of targeted material insertion using a campaign manager
US20050177616A1 (en) * 2003-12-19 2005-08-11 N2 Broadband, Inc. Method and system for distributing services in a digital asset environment
US7346617B2 (en) * 2004-01-23 2008-03-18 Oracle International Corporation Multi-table access control
US20050289338A1 (en) * 2004-02-04 2005-12-29 Braden Stadlman Recording, editing, encoding and immediately distributing a live performance
US8825702B2 (en) * 2004-02-24 2014-09-02 Oracle International Corporation Sending control information with database statement
EP1782287A2 (de) * 2004-07-21 2007-05-09 Beach Unlimited LLC Auf blockkarten-caching basierende verteilte speicherarchitektur und vfs-stapelbare dateisystemmodule
EP1772016A2 (de) * 2004-07-23 2007-04-11 Beach Unlimited LLC Trick-modi und geschwindigkeitswechsel
US7561784B2 (en) * 2004-10-01 2009-07-14 Flir Systems, Inc. Gimbal system
US20060235883A1 (en) 2005-04-18 2006-10-19 Krebs Mark S Multimedia system for mobile client platforms
US20070022215A1 (en) * 2005-07-19 2007-01-25 Singer David W Method and apparatus for media data transmission
US7876998B2 (en) 2005-10-05 2011-01-25 Wall William E DVD playback over multi-room by copying to HDD
KR20080078255A (ko) * 2007-02-22 2008-08-27 삼성전자주식회사 파일 관리 방법 및 장치와 그 파일을 저장한 정보저장매체
JP4885051B2 (ja) * 2007-04-27 2012-02-29 ソニー株式会社 コンテンツ送信装置、コンテンツ受信装置およびコンテンツ送受信システム
US7797391B2 (en) 2007-09-19 2010-09-14 The Chinese University Of Hong Kong Load balancing and admission scheduling in pull-based parallel video servers
US20090083811A1 (en) * 2007-09-26 2009-03-26 Verivue, Inc. Unicast Delivery of Multimedia Content
US9769544B1 (en) * 2007-12-10 2017-09-19 Google Inc. Presenting content with video content based on time
US8364892B2 (en) * 2008-01-11 2013-01-29 Verivue, Inc. Asynchronous and distributed storage of data
US8799535B2 (en) * 2008-01-11 2014-08-05 Akamai Technologies, Inc. Storage of data utilizing scheduling queue locations associated with different data rates
US8311111B2 (en) * 2008-09-11 2012-11-13 Google Inc. System and method for decoding using parallel processing
US8325796B2 (en) 2008-09-11 2012-12-04 Google Inc. System and method for video coding using adaptive segmentation
US8326075B2 (en) 2008-09-11 2012-12-04 Google Inc. System and method for video encoding using adaptive loop filter
US8743906B2 (en) * 2009-01-23 2014-06-03 Akamai Technologies, Inc. Scalable seamless digital video stream splicing
US10699469B2 (en) 2009-02-03 2020-06-30 Calgary Scientific Inc. Configurable depth-of-field raycaster for medical imaging
US9565397B2 (en) * 2009-02-26 2017-02-07 Akamai Technologies, Inc. Deterministically skewing transmission of content streams
US9906757B2 (en) * 2009-02-26 2018-02-27 Akamai Technologies, Inc. Deterministically skewing synchronized events for content streams
EP2302845B1 (de) 2009-09-23 2012-06-20 Google, Inc. Verfahren und Vorrichtung zur Bestimmung eines Jitterpuffer-Niveaus
CA2715769A1 (en) * 2009-09-25 2011-03-25 Calgary Scientific Inc. Level set segmentation of volume data
KR20110047768A (ko) * 2009-10-30 2011-05-09 삼성전자주식회사 멀티미디어 컨텐츠 재생 장치 및 방법
US8477050B1 (en) 2010-09-16 2013-07-02 Google Inc. Apparatus and method for encoding using signal fragments for redundant transmission of data
WO2012050832A1 (en) 2010-09-28 2012-04-19 Google Inc. Systems and methods utilizing efficient video compression techniques for providing static image data
US8856212B1 (en) 2011-02-08 2014-10-07 Google Inc. Web-based configurable pipeline for media processing
US9154799B2 (en) 2011-04-07 2015-10-06 Google Inc. Encoding and decoding motion via image segmentation
US8780996B2 (en) 2011-04-07 2014-07-15 Google, Inc. System and method for encoding and decoding video data
US8781004B1 (en) 2011-04-07 2014-07-15 Google Inc. System and method for encoding video using variable loop filter
US8780971B1 (en) 2011-04-07 2014-07-15 Google, Inc. System and method of encoding using selectable loop filters
US9767195B2 (en) 2011-04-21 2017-09-19 Touchstream Technologies, Inc. Virtualized hosting and displaying of content using a swappable media player
WO2013001344A2 (en) * 2011-06-29 2013-01-03 Calgary Scientific Inc. Method for cataloguing and accessing digital cinema frame content
US9369723B2 (en) 2011-07-14 2016-06-14 Comcast Cable Communications, Llc Preserving image quality in temporally compressed video streams
US8885706B2 (en) 2011-09-16 2014-11-11 Google Inc. Apparatus and methodology for a video codec system with noise reduction capability
US9100657B1 (en) 2011-12-07 2015-08-04 Google Inc. Encoding time management in parallel real-time video encoding
US9262670B2 (en) 2012-02-10 2016-02-16 Google Inc. Adaptive region of interest
US9094681B1 (en) 2012-02-28 2015-07-28 Google Inc. Adaptive segmentation
US9131073B1 (en) 2012-03-02 2015-09-08 Google Inc. Motion estimation aided noise reduction
US9344729B1 (en) 2012-07-11 2016-05-17 Google Inc. Selective prediction signal filtering
US9479805B2 (en) 2013-02-15 2016-10-25 Cox Communications, Inc. Entitlement validation and quality control of content in a cloud-enabled network-based digital video recorder
US9450934B2 (en) 2013-03-15 2016-09-20 Cox Communications, Inc. Managed access to content and services
US11425395B2 (en) 2013-08-20 2022-08-23 Google Llc Encoding and decoding using tiling
US9392272B1 (en) 2014-06-02 2016-07-12 Google Inc. Video coding using adaptive source variance based partitioning
US9578324B1 (en) 2014-06-27 2017-02-21 Google Inc. Video coding using statistical-based spatially differentiated partitioning
US10102613B2 (en) 2014-09-25 2018-10-16 Google Llc Frequency-domain denoising
US10477260B2 (en) 2014-10-17 2019-11-12 Cox Communications, Inc. Network based digital video recorder playback adapter
US9794574B2 (en) 2016-01-11 2017-10-17 Google Inc. Adaptive tile data size coding for video and image compression
US10542258B2 (en) 2016-01-25 2020-01-21 Google Llc Tile copying for video compression
US10567461B2 (en) * 2016-08-04 2020-02-18 Twitter, Inc. Low-latency HTTP live streaming

Family Cites Families (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5426513A (en) * 1989-06-16 1995-06-20 Harris Corporation Prioritized image transmission system and method
US5267351A (en) * 1989-12-22 1993-11-30 Avid Technology, Inc. Media storage and retrieval system
FR2659779B1 (fr) * 1990-03-16 1997-01-24 Thomson Consumer Electronics Recepteur-enregistreur d'emissions de television.
JP3449734B2 (ja) * 1991-08-20 2003-09-22 ソニー株式会社 情報再生装置および情報再生方法
EP0529864B1 (de) * 1991-08-22 2001-10-31 Sun Microsystems, Inc. Netzwerkvideoanbietergerät und-verfahren
GB9124337D0 (en) * 1991-11-15 1992-01-08 Philips Electronic Associated Method of storing user information items and apparatus for reproducing stored items
WO1994001964A1 (en) * 1992-07-08 1994-01-20 Bell Atlantic Network Services, Inc. Media server for supplying video and multi-media data over the public telephone switched network
EP0622002B1 (de) * 1992-09-22 1998-08-26 Sony Corporation Vorrichtung und verfahren zur verarbeitung von digitalen videosignalen
US5442389A (en) * 1992-12-28 1995-08-15 At&T Corp. Program server for interactive television system
EP0625857B1 (de) * 1993-05-19 1998-06-24 ALCATEL BELL Naamloze Vennootschap Videoserver
US5610841A (en) * 1993-09-30 1997-03-11 Matsushita Electric Industrial Co., Ltd. Video server
DE69332379T2 (de) * 1993-11-23 2003-07-10 Hewlett Packard Co Tintenwiedergabe
US5465120A (en) * 1994-02-07 1995-11-07 The Grass Valley Group, Inc. Spiral buffer for non-linear editing
US5629732A (en) * 1994-03-29 1997-05-13 The Trustees Of Columbia University In The City Of New York Viewer controllable on-demand multimedia service
US5566174A (en) * 1994-04-08 1996-10-15 Philips Electronics North America Corporation MPEG information signal conversion system
JP2742383B2 (ja) * 1994-04-11 1998-04-22 松下電器産業株式会社 要求番組提供装置及びその方法
US5559999A (en) * 1994-09-09 1996-09-24 Lsi Logic Corporation MPEG decoding system including tag list for associating presentation time stamps with encoded data units
US5559562A (en) * 1994-11-01 1996-09-24 Ferster; William MPEG editor method and apparatus
US5510844A (en) * 1994-11-18 1996-04-23 At&T Corp. Video bitstream regeneration using previously agreed to high priority segments
US5729279A (en) * 1995-01-26 1998-03-17 Spectravision, Inc. Video distribution system
US5721878A (en) * 1995-06-07 1998-02-24 International Business Machines Corporation Multimedia control system and method for controlling multimedia program presentation
US5659539A (en) * 1995-07-14 1997-08-19 Oracle Corporation Method and apparatus for frame accurate access of digital audio-visual information
JPH09139937A (ja) * 1995-11-14 1997-05-27 Fujitsu Ltd 動画ストリーム変換装置
US5828370A (en) * 1996-07-01 1998-10-27 Thompson Consumer Electronics Inc. Video delivery system and method for displaying indexing slider bar on the subscriber video screen
JP3409652B2 (ja) * 1996-09-02 2003-05-26 松下電器産業株式会社 マルチメディア情報提供装置

Also Published As

Publication number Publication date
CA2306934C (en) 2008-01-08
EP1025700B1 (de) 2003-04-02
CA2306934A1 (en) 1999-04-29
JP4936592B2 (ja) 2012-05-23
AU755447B2 (en) 2002-12-12
DE69812994T2 (de) 2004-02-12
AU1100699A (en) 1999-05-10
DE69812994D1 (de) 2003-05-08
EP1025700A1 (de) 2000-08-09
US6119154A (en) 2000-09-12
HK1028859A1 (en) 2001-03-02
WO1999021363A1 (en) 1999-04-29
JP2001521341A (ja) 2001-11-06

Similar Documents

Publication Publication Date Title
DE69812994T9 (de) Verfahren und vorrichtung für nicht-sequentiellen zugang zu einem laufenden videoprogramm
DE69837726T2 (de) Verfahren und Vorrichtung zum Realisieren einer nahtlosen Wiedergabe von kontinuierlichen Medien-Zuführungen
US6112226A (en) Method and apparatus for concurrently encoding and tagging digital information for allowing non-sequential access during playback
DE69633552T2 (de) Verfahren und vorrichtung zum bildgenauen zugriff auf digitale audiovisuelle information
DE60102831T2 (de) System und verfahren zur verarbeitung von mpeg-stroemen fuer die einfuegung von dateiindex
DE69637410T2 (de) Video-auf-anfragesystem mit verzögerung und fernsehverfahren dazu
US8116609B2 (en) Method and apparatus for traversing a multiplexed data packet stream
DE102012201534B4 (de) Vorrichtung zur Zwischenspeicherung einer skalierbaren Original-Datei
CA2328230C (en) Method for creating a digital data stream
Ghandeharizadeh et al. Scalable video browsing techniques for intranet video servers

Legal Events

Date Code Title Description
8364 No opposition during term of opposition