WO2001022682A2 - Procede et systeme de services en continu en temps reel - Google Patents

Procede et systeme de services en continu en temps reel Download PDF

Info

Publication number
WO2001022682A2
WO2001022682A2 PCT/US2000/026084 US0026084W WO0122682A2 WO 2001022682 A2 WO2001022682 A2 WO 2001022682A2 US 0026084 W US0026084 W US 0026084W WO 0122682 A2 WO0122682 A2 WO 0122682A2
Authority
WO
WIPO (PCT)
Prior art keywords
streaming
manager
file
data
request
Prior art date
Application number
PCT/US2000/026084
Other languages
English (en)
Other versions
WO2001022682A3 (fr
Inventor
Ray T. F. Ngai
Horng-Juing Lee
Yen-Jen Lee
Joe M-J. Lin
Original Assignee
Streaming21, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Streaming21, Inc. filed Critical Streaming21, Inc.
Priority to AU40224/01A priority Critical patent/AU4022401A/en
Publication of WO2001022682A2 publication Critical patent/WO2001022682A2/fr
Publication of WO2001022682A3 publication Critical patent/WO2001022682A3/fr

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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/27—Server based end-user applications
    • H04N21/274—Storing end-user multimedia data in response to end-user request, e.g. network recorder
    • H04N21/2743—Video hosting of uploaded data from client
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/401—Support for services or applications wherein the services involve a main real-time session and one or more additional parallel real-time or time sensitive sessions, e.g. white board sharing or spawning of a subconference
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • 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/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet

Definitions

  • the invention generally relates to methods and/or devices related to data transmission. More particularly, the invention in various aspects, relates to methods and systems for providing real-time multimedia streaming over a communication network.
  • the Internet is a rapidly growing communication network of interconnected computers around the world. Together, these millions of connected computers form a vast repository of hypermedia information that is readily accessible by users through any of the connected computers from anywhere and anytime. As there is an increasing number of users who are connected to the Internet and surf for various information, there meanwhile is created tremendous demand for more content to be available and methods to deliver that content on the Internet.
  • the most commonly available media information that is deliverable on the Internet may include text information, images and graphics, videos and audio clips.
  • streaming media information such as videos and audio
  • streaming data For example, streaming video is a sequence of
  • moving images that are sent in compressed form over a network and displayed by a viewer as they arrive.
  • streaming video or streaming media a Web user does not have to wait to download a large file before seeing the video or hearing the sound.
  • the media is sent in a continuous stream and is played as it arrives, though generally with some delay for buffering the media.
  • the user uses a player (either hardware or software) to play the media.
  • a player either hardware or software
  • a special program is executed to uncompress and send video data to a display screen and audio data to speakers.
  • Specialized streaming servers typically include streaming media delivery software for managing the real-time deliver of data and also include a specialized file system or format for storing data prior to streaming.
  • a specialized file system or format for storing data prior to streaming.
  • the link between a particular specialized file system and the logic functions that managing the streaming sessions is very tight and is highly optimized.
  • the present invention in specific embodiments, involves an innovative software engine (at times referred to herein as Real-Time Streaming Engine (RTSE)) that handles large-scale real-time streaming services.
  • RTSE Real-Time Streaming Engine
  • each stream can be understood as a user access from a client on one computer to a server on the other computer.
  • Users access real-time data such as audio or video from a server and the server delivers, or streams, the real-time audio, video or other data with certain time constraints to client via a computer or communications network.
  • an RTSE according to the present invention has an architecture that allows the central engine software to work with a variety of streaming file systems and conventional file systems as well as a variety of live-data hardware and/or software encoders.
  • the present invention accomplishes this through a innovative combination of known and innovative components into a new architecture for providing streaming services.
  • the invention includes innovative methods for providing and/or managing streaming media according to this flexible design.
  • the invention therefore in specific aspects handles streaming video/audio signals that can be played on various types of video-capable terminal devices operating under any type of operating system and regardless of what type of players are preinstalled in the terminal devices.
  • the RTSE accomplishes effective handling of streaming sessions with a flexible and extensible architecture by dividing tasks among a plurality of managers, such as Reception Manager, Streaming File Manager, Encoding File Manager, Network Manager,
  • the present invention has the ability to handle various types of file systems (e.g. the software according to the invention can be adapted to different streaming and conventional file systems, thus the architecture is able to be adapted to a generic streaming file system) and various types of software and hardware encoding modules, database engines, networking protocols, real-time media, streaming engines, etc.
  • file systems e.g. the software according to the invention can be adapted to different streaming and conventional file systems, thus the architecture is able to be adapted to a generic streaming file system
  • software and hardware encoding modules e.g. the software according to the invention can be adapted to different streaming and conventional file systems, thus the architecture is able to be adapted to a generic streaming file system
  • a server device when loaded with and executing the server module, will provide large scale real-time streaming media services (which can include both delivering and/or accepting streaming data) to support a large number of streaming sessions without compromising the quality of services in delivering the streaming media information over a network.
  • the network may include a cable network, a local area network, a network of other private networks and the Internet.
  • the invention as described further below can be implemented in numerous ways including a method, a computer readable medium, a system, and/or an apparatus.
  • the advantages of the invention are numerous and certain embodiments of the invention can have one or more of the following advantages.
  • One advantage of the invention is that it provides a great deal of flexibility over the quality of service provided with respect to delivering real-time streaming media data over a network.
  • Another advantage of the invention is that all that task-specific managers collaborate with each other to achieve the large-scale real-time streaming service. Still another advantage of the invention is that implementation and configuration of all the managers are easy to manage and install.
  • the media delivery system is described herein based on video streaming signals, those skilled in the art can appreciate that the description can be equally applied to continuous data delivery that may include streaming audio.
  • the present invention is presented largely in terms of procedures, steps, logic blocks, processing, and other symbolic representations that resemble data processing devices. These process descriptions and representations are the means used by those experienced or skilled in the art to most effectively convey the substance of their work to others skilled in the art.
  • the method along with the system to be described in detail below and the appendix is a self-consistent sequence of processes or steps leading to a desired result. These steps or processes are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities may take the form of electrical signals capable of being stored, transferred, combined, compared, displayed and otherwise manipulated in a computer system or electronic computing devices.
  • FIG. 1 illustrates an exemplary configuration of a data network in which the present invention may be practiced.
  • FIG. 2 is a general diagram showing various components of a system according to various specific embodiments of the present invention.
  • FIG. 3 is a block diagram showing a general architecture arrangement of a streaming service according to specific embodiments of the present invention.
  • FIG. 4 is a block diagram illustrating a further example architecture of a streaming service according to specific embodiments of the invention.
  • FIG. 5 is a block diagram illustrating a further example architecture of a streaming server according to specific embodiments of the invention.
  • FIG. 6 is a block diagram illustrating an example system diagram of a Streaming File Manager according to specific embodiments of the invention.
  • FIG. 7 is a block diagram illustrating an example encoding manager according to specific embodiments of the invention.
  • FIG. 8 is a flow chart illustrating example encoder operation according to specific embodiments of the invention.
  • FIG. 9 is a block diagram showing a representative example logic device in which aspects of the present invention may be embodied.
  • FIG. 1 illustrates an exemplary configuration in which the present invention may be practiced.
  • Central video server 102 together with a video database 104 is a video source comprising video files that can be accessed on demand.
  • a video source can also be provided by live encoders as described below.
  • video files or titles are referred to any video footage, video films and/or video/audio clips that typically in a compressed format such as MPEG or MP3. It should be noted, however, that the exact format of the video files do not affect the operations of the present invention. As will be noted and appreciated, the present invention applies to any formats of the video files.
  • data network 106 is a data network backbone, namely a larger transmission line.
  • a backbone is a line or set of lines that local area networks connect to for a wide area network connection or within a local area network to span distances efficiently (for example, between buildings).
  • a backbone is a set of paths that local or regional networks connect to for long-distance interconnection.
  • proxy servers 108 and 110 that each service representative terminal devices 116-119 via data network 112 and 114 respectively.
  • video server 102 named "central" does not necessary mean that video server 102 is only served as a repository of all the video titles.
  • central video server 102 may service terminal devices directly and may retrieve other video titles from other servers such as proxy servers 108 and 110.
  • a compiled version and linked version of the present invention, as a server version, may be employed or installed in any of servers 102, 108 and 110.
  • Data network 112 and 114 are typically the Internet, a local area network or phone/cable network through which terminal devices can receive video files.
  • the terminal devices may include, but not be limited to, multimedia computers (e.g. 116 and
  • terminal devices are equipped with applications or capabilities to execute and display received video files.
  • applications or capabilities to execute and display received video files.
  • one of the popular applications is an
  • MPEG player provided in WINDOWS 98 from Microsoft.
  • the video file can be displayed on a display screen of the computer.
  • one of the terminal devices may send in a request that may comprise the title of the desired video or another identifier. Additionally the request may include a subscriber identification if the video services allow only authorized access.
  • the proxy server Upon receiving the request, the proxy server will first check in its cache if the selected video is provided therein, meanwhile the request is recorded by a network manager in the server module.
  • the selected video will be provided as a streaming video to the terminal device if the entire video is in the cache. Otherwise the proxy server proceeds to send a request to video central server 102 for the rest of the video if there are some units of the video in a cache memory of the proxy server or the entire video if there is no any unit of the video.
  • FIG. 2 illustrates various components that may be included in a server corresponding to server 102, 108 or 110 in FIG. 1.
  • the server is loaded with a server module implemented in a compiled and linked version of an embodiment of the present invention, when the server module is executed by the processor, the server will perform the desired features as described above and further in the description below.
  • FIG. 3 is a block diagram showing a general architecture arrangement of a streaming service according to specific embodiments of the present invention.
  • This general architecture illustrates in concept how the present invention achieves the flexible streaming server design by providing a central (or core) Reception Manager that provides an interface for other parts of the streaming server.
  • the architectural design according to the present invention can be further understood by considering the modules/managers described below.
  • FIG. 4 is a block diagram illustrating a further example architecture of a streaming service according to specific embodiments of the invention. This figure shows an arrangement of a server in a specific embodiment.
  • FIG. 5 is a block diagram illustrating a further example architecture of a streaming server according to specific embodiments of the invention. This figure shows an arrangement of a server in a specific embodiment providing additional details and components.
  • Core Reception Manager (RM)
  • RM defines a set of communication principles (protocols) for other managers to use in collaborating with each other to complete streaming/management requests from clients/consoles (e.g. users or administrators). This is the core manager in the RTSE architecture to control/integrate loosely coupled managers to work together seamlessly and coherently. RM provides an RTSE an extension capability because the RM design allows easier adopting/integrating of streaming, file, encoding, network, database, administration and/or user-interaction managers, whether additional proprietary managers or written by third parties.
  • the RM provides the user authentication and access control to provide different level of security with interface to various formats of user profile repositories.
  • RTSE messaging the RM is the middleman to gather, handle, store, and or redistribute messages among managers. Different types of managers can communicate and collaborate with each other with predefined disciplines to achieve real-time tasks.
  • tasks of the RM include one or more of the followings: (1) retrieving stored data from real-time Streaming File Manager (FM); (2) retrieving live data from real-time Encoding File Manager (EM); (3) processing requests from real-time Network Manager (NM) via a network; (4) processing requests from real-time Administration Manager (AM) via a network; (5) processing database requests to/from Real-time Database Manager (DBM); (6) processing user interaction requests from User Interaction Manager (UIM); (7) processing requests from Real-time Streaming Manager (SM); (8) processing error handling of the whole engine; and (9) processing special events of the whole engine.
  • FM real-time Streaming File Manager
  • EM real-time Encoding File Manager
  • NM real-time Network Manager
  • AM real-time Administration Manager
  • DBM Real-time Database Manager
  • UIM User Interaction Manager
  • SM Real-time Streaming Manager
  • SM Real-time Streaming Manager
  • FMs manage stored real-time data in storage systems such as Disk Array, CD- ROM Jukebox, MO Jukebox, and tape storage. FM schedules concurrent stream requests from Streaming Manager and is designed to satisfy all accepted stream requests in real-time fashion.
  • FM includes several components such as Admission Control module, Real-time scheduler, Media Disk module, and Cache module. FM communicates with subsystems such as a proprietary Streaming File System (SFS), Window File System (WFS), and/or other 3 rd party file systems.
  • FFS Streaming File System
  • WFS Window File System
  • FM provides a generic Applications Programming
  • API Application Interface
  • API is a set of functions, possibly with associated data (such as class definitions in C++), that programs or other logic modules can use to access system provided services, such as operating system services, file system services, etc.
  • SM Streaming Manager
  • SM handles requests from
  • Streaming Manager receives data from either
  • EM and EM instances bridge different vendors of hardware and software encoders to Reception Manager to handle real-time encoding of audio and video and deliver the real-time data to Reception Manager using RTSE's generic File System API.
  • EM schedules concurrent stream requests from Streaming Manager. EM is required to satisfy all accepted stream requests in real-time fashion.
  • the Encoding File Manager includes several components as discussed in more detail below.
  • NM listens to incoming requests from remote clients and performs the corresponding actions for each request. NM handles single listen thread or multiple collaborating threads to work together to improve the load balance and performance of the RTSE.
  • DBM handles requests related to user management profile, log and event profile, file system profile, and media meta-files. DBM isolates database-related requests with a generic API to access information stored on data servers such as (but not excluding) Jet Database, SQL Database server, or other database engines or in plain text file data storage.
  • data servers such as (but not excluding) Jet Database, SQL Database server, or other database engines or in plain text file data storage.
  • AM Administration Manager
  • VIM User Interface Manager
  • UIM queries Reception Manager for management, monitoring, status report, and more and is designed to provide a user-friendly graphical interface to expose the functionality of the whole RTSE through the Reception Manager.
  • UIM enables a verified user (such as a network administrator) to perform user authentication, server control, media object management, user profile management & server settings configuration.
  • FIG. 4 is a block diagram illustrating a further example architecture of a streaming service according to specific embodiments of the invention.
  • a Real-time Reception Manager according to specific embodiments of the present invention, may be wrapped by a set of core APIs.
  • FIG. 4 shows additional details and structure of an example server module constructed according to the architectural principals illustrated in FIG. 3, with the general API wrapping of FIG. 3 further specified as the four different APIs illustrated.
  • the distinctions of the different APIs shown in FIG. 4 can be understood as an implementation feature of specific systems, and API definitions, in some embodiments, may be universal and accessible to various external managers.
  • FIG. 5 is a block diagram illustrating a further example architecture of a streaming server according to specific embodiments of the invention. This figure shows an as implemented configuration of a server according to the present invention, and provides further details of data flow.
  • RM defines a set of communication principles (protocols) for other managers to use to complete streaming/management requests.
  • RM does this by defining various standard interfaces (e.g. APIs) for use by each of the interacting managers and then by providing the necessary logic to translate a access request coming from, for example, the network manager through the server reception API, to, for example a File Manager to determine the availability of a file location, and then to a Streaming Manager to handle the time critical exchange of data.
  • APIs e.g. APIs
  • RM. RM internally decides which managers to invoke to service a particular request and invokes those managers and gathers results to present to the requesting process.
  • an RM according to specific embodiments can be understood to include the following components.
  • SRAPI Server Reception API
  • Interface/Administration Managers that can provide administrative access either through a local system console or through an network protocol that allows for system administration, such as SNMP.
  • SRAPI provides various interface functionality.
  • General examples of the types of functions that can be defined within SRAPI and called by managers that interact with SRAPI are provided below. Other functions may also be defined within SRAPI.
  • a manager calls the function with the arguments defined for the function and receives function-defined returned results.
  • the various managers are responsible for translating between the specific device or protocol that they are managing (such as HTTP, for example) and the SRAPI interface.
  • Each called SRAPI function is received by the RM, which coordinates a response with other managers and through other APIs, as discussed below, and then returns any results back to the calling manager in the API defined format. The manager then translates any results to an appropriate format or device (such as HTTP).
  • SRAPI can include functions such as those shown below. For these and other function examples provided, the function names will indicate to those of skill in the art generally what the functions do.
  • managers for various protocols, encoders, services or file systems will include logic for translating valid API requests to the command format or protocol required by the underlying entity to which those managers relate and will include logic for translating back from the entities native response format to a format specified by the API.
  • This generally will be a straight forward programming tasks given a defined set of APIs and a particular native format.
  • functions specified by SRAPI include: Server Reception Specific
  • Data Management API provides access to one or more various data sources to facilitate various functions, such as, in specific embodiments, user authentication and access, session and event logging, and storage and retrieval of file or streaming clip data.
  • DAPI Data Management API
  • RM For each function, generally the RM calls the function with the arguments defined for the function and receives function-defined returned results.
  • the various managers are responsible for translating between the specific device or protocol that they are managing (such as flat text storage or a particular DBMS, for example) and the DAPI interface.
  • DAPI can include functions such as:
  • a DAPI may also include a set of functions for storing and retrieving data relating to files or clips stored in 3 rd party file systems, where that data is not supported by those file systems. This data might include such items as clip duration, clip ID, owner, # of frames, etc.
  • a File System Manager will ensure that this additional data is stored and can be retrieved from a separate data source, through functions provided in DAPI.
  • File Systems API (FSAPI): provides a standard interface to various underlying file systems and/or encoding systems and their associated managers. General examples of the types of functions that can be defined within FSAPI are provided below. Other functions may also be defined within FSAPI. For each function, generally either RM or a streaming manager as described herein calls the function with the arguments defined for the function and receives function-defined returned results.
  • FSAPI can include functions such as: System Management
  • Streaming Systems API provides a standard interface to underlying streaming services and their associated managers.
  • General examples of the types of functions that can be defined within SSAPI are provided below.
  • Other functions may also be defined within SSAPI.
  • For each function generally RM calls the function with the arguments defined for the function and receives function-defined returned results.
  • SSAPI provides access to managers that handle time-critical exchanges of data.
  • This API provides a set of objects and/or functions that can be accessed by RM and in some cases by FM relating to streaming services.
  • SSAPI can include functions such as:
  • RM is shown in FIG. 4 and in FIG. 5 with a number delineated internal functional modules. These are illustrated to provide further understanding of the internal functions handled by the RM, though the RM may in fact be implemented as a single logic routine without the individually delineated modules shown.
  • Server Master This module can be understood to provide various accessing and scheduling logic within the RM, including communication between the Streaming System Master and the File System Master. This module is a part of the RM and can be understood as a helper module in the RM.
  • File System Master This module can be understood to provide various overall control and interface functions to of various file system devices.
  • This module can be understood to provide various overall control of streaming sessions provided by the RTSE.
  • This logic/module can be understood as the internal RM logic that handles these functions and communicates with other managers. This function also could be understood as a separate manager communicating through the User Profile API to the data storage for the user profile.
  • This logic/module can be understood as the internal RM logic that handles these functions and communicates with other managers. This function also could be understood as a separate manager communicating through the Event Log API and Session Log API to various possible data storage for this data.
  • RM can be understood as performing an overall manager/coordinator role for
  • RM performs message routing (e.g. job distribution), co-ordination, and outside-interfacing duties.
  • RM generally has application and packaging knowledge that other managers do not. RM performs functions such as: Initialization - bring up the appropriate modules/managers for different applications of the RTSE. After the initialization, all managers are ready to report their current status to Reception Manager for central control.
  • Access Control Ensure different level of access control for various Function calls and requests to playback or record various media clips, login/logout, etc., so that other managers do not have to perform these functions.
  • User Interface control - RM can perform various tasks based on data in the user profile, such as translating between file system paths and a user home directory path. RM can also perform disk quota checking for users and groups; License Key Checking (Expiration, Application Type, etc.); Format Guard (disable this functionality according to License Key); System Guard (disable this functionality according to License Key).
  • RM determines the application packaging and co-relation of the other managers, because managers can be packaged differently for different specific implementations.
  • a main executable e.g. a server UI
  • RM will pass RM the application type to be launched.
  • Verifications can include such things as application, expiry date, machine name, version, platform, server maximum capability, etc.
  • RM reads some parameters/settings from non-volatile storage (e.g. an OS Registry) Parameters can include data for such things as security level; event logging storage type (DB file, text file, etc.) corresponding to different Event Logging Modules; User Profile type (DB file, LDAP, text file, etc.) corresponding to different User Profile Modules; streaming session logging storage type (DB file, or W3c format text file, etc.).
  • event logging storage type DB file, text file, etc.
  • User Profile type DB file, LDAP, text file, etc.
  • streaming session logging storage type DB file, or W3c format text file, etc.
  • RM will then initialize the appropriate managers in appropriate sequence.
  • RM initializes a Server Master (a helper inside RM), which is responsible to bring up File System Master first, then Streaming System Master.
  • the File System Master (another helper inside RM) will bring up the appropriate/adequate file system managers (e.g. according to license and application) and can also perform inter-file-systems functions (e.g. Xcopy) and group functions.
  • Streaming System Master (another helper inside RM) will initialize the appropriate/adequate streaming managers (e.g. according to license and application) and can also perform inter- streaming-systems functions and group functions.
  • the Server Master will pass a handle of the File-System-Master to each of Streaming Managers, so that individual Streaming Managers can talk directly to File-
  • System-Master (therefore, all file managers) to perform data retrieval and recording.
  • RM will also bring up other necessary modules, such as User Profile
  • Authentication and Access Control one or more of the Messaging and Logging modules, and one or more of Session Logging Modules. These modules can communicate with Database Management APIs to store or retrieve data in a variety of data formats.
  • This check-list can include such tasks as: test if the operator launching the server could perform low-level disk access; ask the appropriate File Manager to test the machine's disk capability/availability; ask the appropriate Streaming Manager to test the machine's network capability/availability; ask the appropriate User-Profile Manager, and challenge it if it does not contain adequate tables/accounts/groups.
  • RM When RTSE is running, RM performs User Request Handling. RM handles the User login/logout request. For a successful login, the caller will receive a UserHandle number from RM. For the same user raising any other request, the request coming into RM should include that UserHandle for identification. In specific implementations, exchanges of the UserHandle will be encrypted to increase security. For every single user request, RM will check if the user can perform such a function-call and also check if the user can access (read or write) to the target media object (if applicable) based on such parameters as: the system's security level, the user's profile, and/or the target media object's properties. If the security control is passed, RM will also enforce some other restriction specified in the software license key; for example, a user cannot access
  • Mpeg2 media object if the key specified MP3 files only.
  • RM handles most of these inter-manager tasks, eliminating most of the need for inter-manager direct communication. If the checks are passed, in specific embodiments, RM will check if the request's parameters have to be transformed. For example, RM may convert file paths containing '-' to a user's home directory (e.g. /usr/username) using data stored in the user's profile to support a user home directory shortcut without requiring each file manager to be aware of a particular request's user 'home directory' or of the home directory shortcut notation.
  • a user's home directory e.g. /usr/username
  • RM will pass the request and parameters to the appropriate manager(s) to handle the request.
  • a UserHandle will be removed from the parameters list before passing to the appropriate manager(s), while RM will keep track of the user information for returning results.
  • streaming manager will directly send requests to file manager (via File System Master in some embodiments) for real-time data retrieval and or data storing.
  • file manager via File System Master in some embodiments
  • other managers do not talk to one another, but instead direct requests to RM, which translates and passes messages to other managers.
  • Streaming Manager -> File Manager it is originated by a user request through RM to the Streaming Manager to start streaming a media file. Therefore, RM has already ensured that the user request is under the security control and that's why this inter-manager communications need not to subsequently involve RM.
  • RM When the RTSE is running, event/session message handling is performed by RM. RM can receive event/session messages from all other managers and in specific instances can consolidate and possibly redistribute messages. Here, messages is just one way of information passing, not a request. Therefore, the sender does not expect a result or reply.
  • RM If RM receives an Event message, it will send it to the appropriate Event Logging Module(s). Also, if a main executable (e.g. Server UIM) is registered by RM to receive an event message, RM will forward the message to that executable. Likewise, if RM receives a session message, it will send it to the appropriate Session Logging Module(s). Also, if the main executable (e.g. Server UIM) is registered by RM to receive session message, RM will forward the message to that executable. Therefore, various managers need not to talk to Event/Session Logging Modules directly.
  • a main executable e.g. Server UIM
  • a Streaming File Manager according to specific embodiments of the present invention is used and provides an overhead-reduced file system kernel designed to perform real-time (e.g. time-critical) media streaming.
  • the module is simple but powerful enough to handle real-time streaming requests.
  • an FM according to specific embodiments of the present invention supports both time-sensitive Streaming File Systems (superior support for continuous media streaming) and one or more widely-used conventional commercial file systems (one generalized example is a Window File System).
  • a Streaming File System can support high-performance streaming service and the Window File System can provide less-powerful streaming but rich third party support for file manipulation.
  • the present invention may also create a proxy relation between these two file systems.
  • a Cache Module views the Window File System as a media archival and Streaming File System as a proxy streaming engine.
  • all media content manipulation can be either by file system provided commands, file system provided utilities, or third party applications.
  • the Streaming File System can act as a proxy to handle real-time streaming services.
  • Streaming File Manager and the Encoding File Manager can generally be referred to as Streaming
  • both types of managers are accessed through the same File System APIs and to external modules may be accessed as generic streaming data sources.
  • FIG. 6 is a block diagram illustrating an example system diagram of a Streaming
  • Media Disk Handler can configure a storage device to be used as streaming storage for a streaming file system. This consists of two major tasks: format and performance measurement. As mentioned above, RTSE needs to guarantee the streaming service, therefore, knowing the performance limitation on the underlying storage device is a pre-requisite. For a proprietary Streaming File System, the file format and storage allocation is totally under RTSE control and is not compatible with commercial file systems. To layout the disk as Streaming File System format, a configuration module provides a format function for formatting the storage in a Streaming File System Format. (As discussed below, for Window File Systems or other standard file systems, there is no need to perform a streaming specific "format" operation.) API Handler interacts with Real-time Reception Manager to receive all file system service calls. It may call related internal modules to perform the service call or forward the service call to appropriate modules.
  • Real-time Scheduler When there are many streaming sessions running concurrently, RTSE needs to arrange the service sequence among them to ensure every session can maintain the necessary quality of service. Real-time Scheduler is responsible for this. Because every session requires various amount of system resource (for instance, a session requesting a high quality MPEG-2 video consumes more resources than the one asking for low quality MP3 music clip), the module must ensure the resource is used in a consistent and coherent way. Buffer Manager manages data buffers reserved for streaming purposes. In a particular embodiment, each streaming session has its own buffer to store the media data retrieved by Disk Scheduler.
  • Admission Control controls the license issue at this point in the RTSE.
  • RTSE uses two parameters to do the license protection: maximum number of streams and maximum streaming bandwidth. For each individual media file, RTSE limits the maximum number of streams accessing the file. Therefore, when a new request comes in and is passed to Admission Control for verifying. The module ensures the new request will satisfy both levels of license control.
  • Disk Scheduler arranges the IO requests and performs the storage read write.
  • RTSE can generate multiple Disk Scheduler threads and have them work concurrently to improve overall system performance. Having multiple threads also facilitates balanced system operation.
  • Cache Manager manages cache arrangements, especially between the streaming file system and the conventional file system when that system is used as an archive for the streaming file system.
  • Cache Manager receives requests for streaming media files and fetches profiles of the requested media file.
  • Cache Manager in a streaming FS File Manager can determine whether a media file exists in the cache space (e.g. Streaming File System) and if not issue requests to a conventional File System to download the media file into a Streaming File System and after download has been started, returns the media profile information to API Handler.
  • Cache Manager can receive the requests from the streaming FS manager and coordinate delivery of the data to the streaming FS.
  • the modules shown as Windows File System API and Streaming File System API are the APIs that handle the interface with various underlying file systems.
  • Case 1 Real-time Reception Manager issues a playback request for a particular media file.
  • API Handler receives the request and issues a request to Cache Manager to get the profile of the requested media file.
  • Cache Manager checks whether the media file exists in the cache space (e.g. Streaming File System).
  • Cache Manager If Cache Manager cannot find media file in the cache space, it issues a request to the conventional (e.g. Windows) File System to download the media file into Streaming File System. After download has been started for a period (e.g. a couple of seconds), the Cache Manager returns the media profile information to API Handler.
  • conventional e.g. Windows
  • API Handler After download has been started for a period (e.g. a couple of seconds), the Cache Manager returns the media profile information to API Handler.
  • API Handler receives the media profile information and asks Admission Control module to verify the operation, e.g. it asks Admission Control whether a user can access the file at the present time without violating operating parameters. 5. Admission Control checks the license setting and make sure that admitting the new request will not violate the license setting for the whole system as well as for the requested media file.
  • API Handler passes the request to Real-time Scheduler to ask the scheduler to create a streaming session.
  • Real-time Scheduler sends a buffer allocation request to Buffer Manager.
  • Buffer Manager approves the request, it returns a block of memory space, and the memory space pointer is returned.
  • Real-time Scheduler gets the memory space pointer and reserves the memory space for the newly created streaming session, creates a unique session ID for the request, and puts the session into the session schedule list for service.
  • API Handler receives the read request for a session (granted in Case 1) from Real- time Reception Manager.
  • Real-time Scheduler checks the session ID and determines where the data is stored for the particular read operation and updates its internal session structure to reflect the current media file offset location.
  • API Handler returns the data to the caller.
  • Case 3 Reception Manager issues a recording request for a particular media file.
  • API Handler receives the request and issues a request to Cache Manager to check the existence of the file in current file system. 2. If the file is not available, API Handler asks Admission Control module to verify the operation. 3. Admission Control checks the license setting and make sure that admitting the new request will not violate the license setting for the whole system.
  • API Handler passes the request to Real-time Scheduler to ask it to create a streaming session. 5.
  • Real-time Scheduler sends buffer allocation request to Buffer Manager.
  • Buffer Manager approves and returns a block of memory space, the memory space pointer is returned.
  • Real-time Scheduler gets the memory space pointer and reserves the memory space for the newly created streaming session. Then, it creates a unique session ID for the request and put the session into the session schedule list for service. In the meantime, it updates the system media profile to reflect the new media file information.
  • the Real-time Scheduler running in the background continues scanning through the session scheduling list and will interact with other modules to satisfy each scheduled session need.
  • Cache Manager issues a get media profile operation to Window File System for a particular file.
  • Cache Manager asks Admission Control module to verify the operation.
  • Admission Control checks the license setting and makes sure that admitting the new request will not violate the license setting for the whole system as well as for the requested media file. 4. If approved, Cache Manager passes the request to Real-time Scheduler to ask it to create a streaming session.
  • Real-time Scheduler sends buffer allocation request to Buffer Manager.
  • Real-time Scheduler gets the memory space pointer and reserves the memory space for the newly created streaming session. Then, it creates a unique session ID for the request and puts the session into the session schedule list for service. 8. If session is created successfully, the unique ID will return to the caller.
  • Cache Manager uses the session ID to continuously retrieve data by issue read operations to Real-time Scheduler.
  • Cache Manager After accumulating a period of data (such as a couple of second's worth of data), Cache Manager creates another recording request (specific to Streaming File
  • the newly created recording session retrieves the data from data accumulated by playback request (at Window File System).
  • This producer and consumer operation forms a data pipe between Window File System and Streaming File System.
  • the download operation completes when all data is in Streaming File System.
  • Streaming File System updates its internal structure to reflect the new media file.
  • FM interface shown in FIG. 6 is duplicated in separate instances for different conventional file systems and different streaming file systems. In specific embodiments, it will be understood that there is a separate FM for each file system and may also be a separate encoder instance for each encoder.
  • FIG. 7 is a block diagram illustrating an example encoding manager according to specific embodiments of the invention.
  • An example flow chart of Encoding Module operation is shown in FIG. 8.
  • This module provides encoding device initialization/termination, logical mapping of encoding device to file system object, supporting file system semantics, routing control messages, set/get logical encoding parameters, and generating video/audio bit-stream.
  • there are two logical objects within the Encoding Module e.g., Encoder Manager and Configuration Manager.
  • a specific example of runtime procedures may be understood as follows.
  • Scan installed e ⁇ coder(s) The scanning process enables the system to recognize installed encoding devices, either hardware or software implementations.
  • the Encoding Module calls an API "GetDeviceCount” defined in Encoder Manager for known encoder driver(s). The implementation of the API returns the number of encoding devices available.
  • the Encoder Manger also assigns unique "Selector ID” and "Device ID” for each encoding device.
  • the Selector ID is pre-registered in the Encoding Module for each driver, but the Device ID is determined at runtime. Thus, any addition or removal of any hardware or software encoding device will be automatically recognized at this discovery process. It also provides a logical enumeration of encoding devices, free from vendor-specific or system-specific device enumeration.
  • Encoder Manager manages every instance. Thus, all of the control operations (enable, disable, start, stop, pause, and resume) are transparent to the callers for the heterogeneous encoding devices.
  • Each encoding device has its own capability and format in encoding video/audio bit- stream.
  • standards by ITU, ISO, or vendors are set standards by ITU, ISO, or vendors.
  • the values of the settings vary by encoders, the general physical requirements do not change.
  • the input connector types are standard ones.
  • the color adjustments for video are well-known coloring schemes.
  • the audio adjustments are also adhered to audio engineering standards.
  • Configuration Manager defines and manages a logical parameter set. The translation of these parameters to device- specific settings is also provided by Configuration Manager so that it is transparent to the callers, and can be tagged by the Selector ID.
  • Encoder Manager works in accord with Configuration Manager. Configuration Manager translates the settings to physically applicable values for the target device. Encoder Manager applies the translated values to the target device. This logical functionality separation between Encoder Manager and Configuration Manager ensures that the Encoding Module can be further extended or scaled down. In a scaled down application, the application might have several sets of pre-defined non- changeable parameters that Encoder Manager at runtime can use directly. Such application may run on embedded system or memory-stringent environments.
  • Bit-stream generation is one of the most important end results.
  • handling of the bit-stream varies. Some implementations require installation of software callback functions to retrieve hardware-generated data in real-time; other implementations use an asynchronous software event object to signal the availability of real-time encoded data.
  • Encoder Manager manages the per-encoding-instance circular memory buffer for interrupt-driven or event-driven bit-stream handling. Data available through both handling mechanisms are being redirected to the memory buffer.
  • the Encoder Manager provides a transparent API "GetEncoderBitStream" to access in-memory circular buffer.
  • the implementation uses a "laps" concept so that the callers know the bit- stream offset from the beginning of encoded bit-stream. Hence, it provides a synchronization mechanism for callers regardless of the timing or data. It also adheres to the general semantics used in file system internal. Data can be copied or redirected to the other streaming system modules or written to the file systems that are supported by the operating system.
  • the above managers collaborate with each other to achieve large-scale streaming service.
  • the engine is powerful enough to handle various types of real-time file systems, various types of software and hardware encoding modules, various types of database engines, various types of networking protocols, various types of real-time media, and various types of streaming engines.
  • the example engine illustrated in FIG. 4 and FIG. 5 are for illustration purposes. The example sequences described below are further for illustration purposes.
  • Case 1 Client requests to play back pre-recorded real-time media from server 1. Client requests to play back Movie A via web browser or other connection.
  • the request is transmitted to RTSE's Network Manager via Internet or Intranet or other communication channel.
  • Network Manager receives the request and verifies the security level of the remote client and the client identity. 4. If the client has enough access authority, the request is passed to Streaming Manager via Reception Manager.
  • Streaming Manager records down the active stream and passes the request to Streaming File Manager.
  • Streaming File Manager verifies that there are sufficient resources available to handle delivery of the requested stream and decides to accept or reject the current request.
  • Streaming File Manager starts the real-time scheduling to retrieve the requested media to Streaming Manager.
  • Streaming Manager starts the real-time scheduling to deliver requested media to remote client via pre-negotiated network protocols.
  • Client receives the data and presents the pre-recorded media to a user.
  • a client may allow a user to perform virtual VCR functions such as index seek, fast forward, backward, time seeking, pause, etc. These requests reach Network Manager, which passes them through Reception Manager to Streaming Manager to control the stream.
  • Case 2 Client requests to play back live real-time channel from server.
  • Client requests to play Channel B via web browser or other connection.
  • the request is transmitted to RTSE's Network Manager via Internet or Intranet or other communication channel.
  • Network Manager receives the request and verifies the security level of the remote client and the client identity. 4. If the client has enough access authority, the request is passed to Streaming Manager via Reception Manager.
  • Streaming Manager records down the active stream and passes the request to an Encoding File Manager. 6. Encoding File Manager verifies that there are sufficient resources available to handle delivery of the requested stream to decide to accept or reject the current request. 7. If accepted, Encoding File Manager starts the real-time scheduling to deliver the requested media to Streaming Manager. 8. Streaming Manager starts the real-time scheduling to deliver requested media to remote client via pre-negotiated network protocols.
  • Client receives the data and presents the pre-recorded media to a user.
  • a client may allow a user to perform channel surfing functions or other functions appropriate for live data. These requests reach Network Manager, which passes them through Reception
  • RTSE After login, RTSE is ready to report its latest status to the console.
  • the operator may start RTSE services fully or partially using the console, depending on operator needs.
  • the console provides Client Connection Management, Media Object (files or live channels) Management, Server Settings & Managers Configurations.
  • the console may also facilitate Event Log Viewing and Performance Monitoring.
  • the operator may login as a monitoring-only user and allow monitoring windows to run, without risking any unauthorized access while the operator is away from the console. 9.
  • the operator can choose whether to stop RTSE or not.
  • Remote Management Console issues an HTTP-based (or other protocol, such as SNMP) "check server status" request to RTSE's HTTP (or other) Listener.
  • HTTP-based or other protocol, such as SNMP
  • HTTP Listener If RTSE is running, its HTTP Listener will interpret the request and identify the user's rights through a login function. 4. After login, HTTP Listener issues request of "check server status" to Real-time
  • HTTP Listener then packs the result into an HTML page back to the Remote Management Console.
  • Remote Management Console displays the result to Console's display. 7.
  • the Remote Management Console can periodically query RTSE status.
  • Remote Management Console has requests such as “get streaming performance”, “get individual or overall streaming sessions information”, “get streaming events”, “remotely import media file into RTSE”, “remotely export media file out of RTSE”, etc.
  • Case 5 Proxy Example
  • Client requests to play back movie A via web browser or other connection.
  • the request is transmitted to RTSE's Network Manager via Internet or Intranet or other communication channel.
  • Network Manager receives the request and verifies the security level of the remote client and the client identity.
  • the request is passed to Streaming Manager via Reception Manager.
  • Streaming Manager records down the active stream and passes the request to Streaming File Manager. 6. Streaming File Manager verifies that the requested media is available on a Windows or other non-streaming conventional File System. 7. If the request media is not available on a conventional File System, the request is denied.
  • Streaming File Manager verifies the storage resource to decide to accept or reject the current request.
  • Streaming File Manager starts the real-time scheduling to retrieve the requested pre-recorded media to Streaming Manager.
  • Streaming File Manager starts the real-time scheduling to download the requested media from conventional File System into Streaming File System. After a portion of data has been cached in the Streaming File System, Streaming File Manager starts the real-time scheduling to retrieve the requested media (just cached) to Streaming Manager.
  • Streaming Manager starts the real-time scheduling to deliver requested pre-recorded media to remote client via pre-negotiated network protocols.
  • Client receives the data and starts play back of the pre-recorded media
  • a client may allow a user to perform virtual VCR functions such as index seek, fast forward, backward, time seeking, pause, etc. These requests reach Network Manager, which passes them through Reception Manager to Streaming Manager to control the stream.
  • Access Control module in Reception Manager requests to find a specific user profile by a user-name.
  • Data Management first locates the location and access mechanism of the User Profile Table from server settings and configurations.
  • DBM will bring up UserDbODBC to follow up the request, UserDbODBC may get the Profile from all types of DBMS servers which support ODBC. 4. If the access mechanism is DAO, DBM will bring up UserDbDAO to follow up the request.
  • the UserDbDAO is designed to use DAO to talk to Microsoft Jet Database in an optimized way.
  • DBM will bring up UserDbLDAP to follow up the request, UserDbLDAP will interface to the corresponding LDAP server to access a distributed data repository.
  • Example RTSE (Server) Startup Procedure According to specific embodiments of the present invention, as an example, the following steps are performed when an example RTSE server (which may be understood as generally configured as shown in FIG. 4 or FIG. 5) starts and then a client connects:
  • Reception Manager Initialization Internal modules inside the Reception Manager are initialized and passed back their stored settings from non-volatile storage to restore their previous states. Messaging and logging features are then initialized to handle and store any messages coming from other managers. User Authentication and Access Control are then turned on to guard and protect the incoming requests from the managers using the Server Reception API.
  • the Server Master, Streaming System Master and File System
  • User Authentication module maintains user profiles / user groups and stores their operation rights. In specific embodiments, this may be accomplished through use of external database store using the DAPI. Access control module will authorize a request from the logged-in user by the request operation type and the access rights about the involved media objects if any.
  • Reception Manager & other mangers are ready to be configured to the user's preferences.
  • General configurable setting includes aspect of Access Control, Networking, Media Profile, and Logging. Individual manager specific configuration may also be done if needed, e.g. video volume formatting, etc.
  • Each manager has initialization and startup procedure to enable their services.
  • Reception Manager allows these services to be started in a very flexible way.
  • Reception Managers report their performance details when started to RM. Reception Manager redirects this data flow to any parties needed.
  • Media Object Management Through Reception Manager with access rights checking Media Objects among file mangers may be freely copied, pasted, deleted, moved, created, imported and exported by authorized users. Media Objects in all file mangers supports same entry point and hierarchical structure. Each Media Object Profile contains such parameters as media format details, updateable clip title, author, descriptions, license and its user/group access rights. Media Access Control is also applied to directory levels.
  • management or playback clients can establish connections to the server machine and talk to the Reception Manager directly. Each connection can be logged and monitored clearly through Reception
  • the Reception Manager requires each connection to have a valid login. Further requests from the connection will be controlled by a logged-in user's profile. Each login session's details will be stored via the Access Control module. 9. Client Media Object Browsing
  • Clients may browse into all File Mangers' media object directories through the
  • RM will filter out those files that the user has no authority to browse. 10.
  • the Reception Manager accepts client's command to start streaming through a specific streaming manger for a specific file manager's media object.
  • the two managers will coordinate with each other to perform the streaming smoothly.
  • Reception Manager sends messages to other managers to clean the related connection. Login control also reflects the login session removal. 12. Reception Manager Quit: Stop Server, Uninitializing Server, and Release Resource Reception Manager will stop the managers in appropriate sequence, then clean up its internal modules.
  • the invention can be implemented in hardware and/or software. In some embodiments of the invention, different aspects of the invention can be implemented in either client-side logic or a server-side logic, though the present invention will usually be implemented in a server side device.
  • the invention or components thereof may be embodied in a fixed media program component containing logic instructions and/or data that when loaded into an appropriately configured computing device cause that device to perform according to the invention.
  • a fixed media program may be delivered to a user on a fixed media for loading in a user's computer or a fixed media program can reside on a remote server that a user accesses through a communication medium in order to download a program component.
  • FIG. 8 shows an information appliance (or digital device) 700 that may be understood as a logical apparatus that can read instructions from media 717 and/or network port 719. Apparatus 700 can thereafter use those instructions to direct server or client logic, as understood in the art, to embody aspects of the invention.
  • One type of logical apparatus that may embody the invention is a computer system as illustrated in
  • Fixed media 717 may be used to program such a system and may represent a disk-type optical or magnetic media, magnetic tape, solid state memory, etc.
  • the invention may be embodied in whole or in part as software recorded on this fixed media.
  • Communication port 719 may also be used to initially receive instructions that are used to program such a system and may represent any type of communication interface, including telephone modem, network interface, ADSL or cable modem, or wireless interface.
  • the invention also may be embodied in whole or in part within the circuitry of an application specific integrated circuit (ASIC) or a programmable logic device (PLD).
  • ASIC application specific integrated circuit
  • PLD programmable logic device
  • the invention may be embodied in a computer understandable descriptor language which may be used to create an ASIC or PLD that operates as herein described.
  • a streaming system constructed according to specific embodiments of the present invention can handle generic streaming file systems by adapting to those systems through a File Manager and can also utilize non-streaming, or conventional file systems.
  • a streaming system according to the invention can handle streaming data from generic hardware and software encoding modules.
  • the architecture generally described in FIG. 3 and more particularly in FIG. 4 and FIG. 5 also allows a streaming system to handle generic database engines for processing real-time media and various networking protocols to perform streaming service.
  • a system according to specific embodiments of the present invention can schedule large-scale real-time time media concurrently from mass storage, to local memory and remote clients via Internet, Intranet, Cable, and Wireless connections.
  • the present invention also provides for a Real-Time Encoding API wherein the module that implements the API, provides unique software plug-and-play features to scan and instantiate underlying multi-vendor encoding devices.
  • the encoding device can be hardware-based or software-based encoder and may be independent of any system bus architecture.
  • the invention provides a coherent system design to address different market segments. Services can be developed based on a generic File System API, and that File
  • System API can be adapted to work with any real-time bit-stream generating device.
  • a server can enable applications such as Home Security, Secured Live Broadcasting (for financial institutions, government agencies, etc.), and In-house Broadcasting (for mid to large-size corporations and educational institutions), and Remote Sensing & Monitoring.
  • applications such as Home Security, Secured Live Broadcasting (for financial institutions, government agencies, etc.), and In-house Broadcasting (for mid to large-size corporations and educational institutions), and Remote Sensing & Monitoring.
  • a streaming system also easily allows extension to new technologies, such as additions for new encoding hardware/software, new video formats, new file systems, new streaming protocols, etc.
  • new technologies can work seamlessly through the File System API without compromising or rewriting the other collaborating modules/managers.
  • the present invention provides a basis for a Software Development Kit (SDK) for hardware and software vendors that allows vendors to program their hardware or software independent of the rest of the real-time streaming system.
  • SDK Software Development Kit
  • New hardware or software encoding solution can be introduced and integrated with existing or new applications/utilities simply by adapting the new solutions through the File System APIs.
  • the streaming media delivery server module as described herein, in accordance with one aspect of the present invention is robust, operationally efficient and cost- effective.
  • the present invention may be used in connection with presentations of any type, including sales presentations and product/service promotion, which provides the video service providers additional revenue resources. While the forgoing and attached are illustrative of various aspects/embodiments of the present invention, the disclosure of specific sequence/steps and the inclusion of specifics with regard to broader methods and systems are not intended to limit the scope of the invention which finds itself in the various permutations of the features disclosed and described herein as conveyed to one of skill in the art.

Abstract

L'invention concerne un procédé et un système de transmission de médias en continu. Cette invention permet une transmission de médias en continu et une interface avec des systèmes de fichiers génériques, des bases de données, et d'autres composantes.
PCT/US2000/026084 1999-09-22 2000-09-22 Procede et systeme de services en continu en temps reel WO2001022682A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU40224/01A AU4022401A (en) 1999-09-22 2000-09-22 Method and system for providing real-time streaming services

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US15535499P 1999-09-22 1999-09-22
US60/155,354 1999-09-22
US66849800A 2000-09-22 2000-09-22
US09/668,498 2000-09-22

Publications (2)

Publication Number Publication Date
WO2001022682A2 true WO2001022682A2 (fr) 2001-03-29
WO2001022682A3 WO2001022682A3 (fr) 2002-01-24

Family

ID=26852254

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/026084 WO2001022682A2 (fr) 1999-09-22 2000-09-22 Procede et systeme de services en continu en temps reel

Country Status (2)

Country Link
AU (1) AU4022401A (fr)
WO (1) WO2001022682A2 (fr)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003045047A3 (fr) * 2001-11-22 2003-10-09 Sk Telecom Co Ltd Procede permettant de fournir un service de transmission en continu de donnees video
EP1398967A2 (fr) * 2002-09-16 2004-03-17 Michael Thiemann Ordinateur et réseau pour fournir un portail pour une transmission en continue
US7774026B2 (en) 2005-06-10 2010-08-10 Ntt Docomo, Inc. Mobile communication terminal and storage medium
US7836404B2 (en) * 2001-12-13 2010-11-16 International Business Machines Corporation Streaming internet media record and playback software program
US7844723B2 (en) 2007-02-13 2010-11-30 Microsoft Corporation Live content streaming using file-centric media protocols
US8578045B2 (en) 2007-02-14 2013-11-05 Microsoft Corporation Adaptive bandwidth utilization
US9141786B2 (en) 1996-11-08 2015-09-22 Finjan, Inc. Malicious mobile code runtime monitoring system and methods
WO2015119691A3 (fr) * 2013-11-11 2015-10-29 Amazon Technologies, Inc. Options de sécurité configurables par le client pour des flux de données
US9219755B2 (en) 1996-11-08 2015-12-22 Finjan, Inc. Malicious mobile code runtime monitoring system and methods
US10552603B2 (en) 2000-05-17 2020-02-04 Finjan, Inc. Malicious mobile code runtime monitoring system and methods

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ANHALT N ET AL: "INTERAKTIVES VIDEO IM INTERNET" RUNDFUNKTECHNISCHE MITTEILUNGEN,DE,MENSING. NORDERSTEDT, vol. 42, no. 4, December 1998 (1998-12), pages 126-133, XP000799261 ISSN: 0035-9890 *
RADHA H ET AL: "Scalable Internet video using MPEG-4" SIGNAL PROCESSING. IMAGE COMMUNICATION,ELSEVIER SCIENCE PUBLISHERS, AMSTERDAM,NL, vol. 15, no. 1-2, September 1999 (1999-09), pages 95-126, XP004180640 ISSN: 0923-5965 *

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9141786B2 (en) 1996-11-08 2015-09-22 Finjan, Inc. Malicious mobile code runtime monitoring system and methods
US9444844B2 (en) 1996-11-08 2016-09-13 Finjan, Inc. Malicious mobile code runtime monitoring system and methods
US9219755B2 (en) 1996-11-08 2015-12-22 Finjan, Inc. Malicious mobile code runtime monitoring system and methods
US9189621B2 (en) 1996-11-08 2015-11-17 Finjan, Inc. Malicious mobile code runtime monitoring system and methods
US10552603B2 (en) 2000-05-17 2020-02-04 Finjan, Inc. Malicious mobile code runtime monitoring system and methods
CN1299508C (zh) * 2001-11-22 2007-02-07 Sk电信有限公司 一种提供视频数据流服务的方法
WO2003045047A3 (fr) * 2001-11-22 2003-10-09 Sk Telecom Co Ltd Procede permettant de fournir un service de transmission en continu de donnees video
US7130937B2 (en) 2001-11-22 2006-10-31 Sk Telecom Co., Ltd. Method for providing a video data streaming service
US7836404B2 (en) * 2001-12-13 2010-11-16 International Business Machines Corporation Streaming internet media record and playback software program
EP1398967A3 (fr) * 2002-09-16 2006-08-09 Michael Thiemann Ordinateur et réseau pour fournir un portail pour une transmission en continue
EP1398967A2 (fr) * 2002-09-16 2004-03-17 Michael Thiemann Ordinateur et réseau pour fournir un portail pour une transmission en continue
US7774026B2 (en) 2005-06-10 2010-08-10 Ntt Docomo, Inc. Mobile communication terminal and storage medium
US7844723B2 (en) 2007-02-13 2010-11-30 Microsoft Corporation Live content streaming using file-centric media protocols
US8578045B2 (en) 2007-02-14 2013-11-05 Microsoft Corporation Adaptive bandwidth utilization
WO2015119691A3 (fr) * 2013-11-11 2015-10-29 Amazon Technologies, Inc. Options de sécurité configurables par le client pour des flux de données
US9276959B2 (en) 2013-11-11 2016-03-01 Amazon Technologies, Inc. Client-configurable security options for data streams
EP3069495A4 (fr) * 2013-11-11 2017-05-03 Amazon Technologies, Inc. Options de sécurité configurables par le client pour des flux de données

Also Published As

Publication number Publication date
AU4022401A (en) 2001-04-24
WO2001022682A3 (fr) 2002-01-24

Similar Documents

Publication Publication Date Title
JP5368605B2 (ja) 回線容量が制約されたネットワーク上の多メディア資産の送出及び動的プレゼンテーション用システム
US6058424A (en) System and method for transferring a session from one application server to another without losing existing resources
US8386465B2 (en) System and method to manage and distribute media using a predictive media cache
US8037191B2 (en) Low-level remote sharing of local devices in a remote access session across a computer network
US6502137B1 (en) System and method for transferring information over a computer network
US8769528B2 (en) Fixed-function consumer-electronics device providing general-computing functions with virtual machines
EP1811747B1 (fr) Procédé et appareil pour stocker et restaurer des informations d'état d'une interface d'utilisateur à distance
US20070209005A1 (en) Systems and methods for a single development tool of unified online and offline content providing a similar viewing experience
US20070204003A1 (en) Downloading a file over HTTP from multiple servers
US20070204115A1 (en) Systems and methods for storage shuffling techniques to download content to a file
EP2248306B1 (fr) Systèmes de communications unifiés et procédés
KR20080018778A (ko) Ａｖ 컨텐츠를 세그먼트 단위로 실행하는 방법, 제어포인트 장치 및 홈 네트워크 시스템
US20060089981A1 (en) Supporting device information of a combo device in a universal plug and play network
WO2000072168A1 (fr) Procede et appareil d'acces a des informations, et de fourniture d'informations multimedia
JP2003510734A (ja) ストリーミングのエミュレート用ファイル分割
CN108566561A (zh) 视频播放方法、装置及存储介质
WO2001022682A2 (fr) Procede et systeme de services en continu en temps reel
US8782717B2 (en) Method of restoring AV session and a control point for the same
TW582153B (en) Method and system for providing real-time streaming services
FR2964523A1 (fr) Mise a disposition d'informations par un terminal mobile dans un reseau.
EP3930264A1 (fr) Procédé et dispositif de gestion de consommation de contenus dans un réseau domestique étendu
Psaier A Java-based streaming media server
US20110119772A1 (en) Media Content Transfer and Remote License Acquisition
Dan et al. The research server complex manager for large-scale multimedia servers
Karaca Multi-Protocol Video on Demand System for Distance Education with Pedagogical Enhancements

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: A3

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP