Multimedia Distribution Over Wide Area Networks

This invention relates to multimedia file distribution and, more particularly, to the use of existing wide area and local area networks for the distribution of multimedia files from a centralized repository for such files.

Multimedia distribution systems have remained local area network systems (LANs) due to the lack of an available distributed multimedia infrastructure. In existing wide area networks (WANs), the available bandwidth is insufficient to support remote playback of video files, particularly in view of network-related problems such as network latency, jitter and limited throughput. As a result, a typical solution is to maintain large libraries of video files in a large number of geographically dispersed locations in order to provide reasonably rapid access for widely disbursed users. The cost of creation and maintenance of such multiple video libraries, along with the local distribution facilities, is often prohibitive for most users. In addition to the prohibitive cost, the difficulty in scheduling viewing and managing the local distribution of such videos makes video distribution systems rare and inefficient.

In accordance with the illustrative embodiment of the present invention, the distribution of video files over large geographical areas makes use of local video caches along with efficient distribution of such video files to the local caches. High speed local area networks are then able to deliver the video files locally from the local cache in real time, while a slower wide area network is able to transfer video files from one, or more centralized video storage libraries to the local caches at the slower, non-real time rates common to such wide area networks. More particularly, user access to video files utilizes one of three different algorithms, depending on the request and the local availability of a file. If the file is already available locally, for example, the user may obtain full access (browsing, playback, rewind and multiple viewing) over local area network facilities such as those currently available today. If a request specifies a future time for access, a remote file can be scheduled for transfer to the local cache at any convenient time or times prior to viewing. Finally, if a request specifies a video file which is not in the local cache, a "preface" of the video file is immediately transferred to the local cache. The preface is a predetermined initial portion of the video file having a playback duration just long enough to balance the time required to transfer the remainder of the video file to the local cache with the time to play back the entire video file. This latter type of file access is called "speed match" playback.

The combination of access algorithms used in the present invention provides an efficient strategy for accessing video files from one or more remote video file libraries and delivering those video files to a widely distributed geographical area at a reasonable cost over a relatively slow wide area network. The three algorithms can be combined by using a high usage video caching strategy. That is, the most frequently accessed video files and the most recently accessed video files can be loaded into local caches serving the most likely users, thus anticipating likely requests. More significantly, only the prefaces of such most frequently accessed video files need be loaded into the local caches since the balance of the video files can be subsequently transmitted in a timely fashion, using the speed match playback algorithm, after an actual request for the file has been received.

The video distribution management system (VDMS) of the present invention makes video distribution over a wide area network both economically and technically practical. Real time file access is provided from local caches over a high speed local area network while non-real time file service is provided over a slower speed wide area network on a scheduled or "speed match" distribution to local area caches. While not all requests can be filled with these techniques, a sufficient number of requests can be filled within a reasonable length of time to render the video distribution system both technically and economically viable.

A complete understanding of the present invention may be gained by considering the following detailed description in conjunction with the accompanying drawings, in which:

FIG. 1 shows a general block diagram of a video distribution system in accordance with the present invention utilizing both wide area networks and local area networks and local area video caches to support such video distribution;

FIG. 2 shows a general flow chart of the video distribution management system show in FIG. 1, depicting the three alternative access algorithms of the present invention;

FIG. 3 shows a detailed flow chart of the scheduled video playback algorithm shown in general form in FIG. 2;

FIG. 4 shows a detailed flow chart of the speed match playback algorithm in which initial prefaces of video files are transferred for user access prior to the transfer of the balance of the video file, while maintaining continuous user access and playback; and

FIG. 5 shows a detailed flow chart of the preface calculation algorithm by means of which the size of a video preface is determined prior to the transfer of such a preface in the flow chart of FIG. 5.

To facilitate reader understanding, identical reference numerals are used to designate elements common to the figures.

Referring more particularly to FIG. 1, there is shown a general block diagram of an interactive video distribution system comprising a wide area network (WAN 13) and at least one local area network (LAN 16). WAN 13 is a point-to-point or switched data packet transmission system of the type well known in the art, over which communication is enabled using standard wide area protocols such as SNA/LU 6.2 as described in "SNA/LU 6.2 Reference: Peer Protocols," IBM Publication, 1990, and TCP/IP as described in Internetworking with TCP/IP, by Douglas Comer, Prentice Hall, Englewood Cliffs, N.J., 1988. LAN 16 is a backbone or ring configured, high speed data interconnection system such as ETHERNETr or Token Ring over which communication is enabled using standard local area protocols such as NetBIOS or TCP/IP as disclosed in Communications for Cooperating Systems: OSI, SNA and TCP/IP, by R. J. Cypser, Addison-Wesley, New York, 1991. While LAN 16 is capable of carrying wide band video data at a rate consistent with video playback, WAN 13 is not generally capable of carrying digital video data at the required rate.

One or more centralized video libraries such as library 11 are connected to WAN 13 by way of a wide area servers like server 10 which deliver video files from library 11 to WAN 13 on demand and at a rate which can be supported by WAN 13 but not generally at a rate consistent with video playback. Local area network 16 is appropriately connected to WAN 13 by way of local area server 14 which forms an interface between the high speed LAN 16 and the lower speed WAN 13. A local area cache storage facility 15 is connected to local area server 14 and provides a local storage facility for all or portions of copies of video files from video library 11. Video files in cache 15 can be delivered interactively and in real time to video display stations such as station 17 on LAN 16. Of course, LAN 16 serves a large number of video display stations like station 17, and all of such other video display stations can likewise receive video files from cache 15 interactively and in real time. Similarly, WAN 13 serves other local area networks which, like LAN 16, utilize their own local area video caches like cache 15 connected to local area servers like server 14. Together, video library 11, WAN 13 and all of these local area networks, each served by a local area server 14 and a local area cache 15, each in turn serving a plurality of viewing stations 17, comprise the video distribution system shown in FIG. 1.

The video distribution management portion of FIG. 1, providing file service functions, is comprised of the video library 11, the wide area server 10, WAN 13 and video distribution management system 12. The video playback portion, providing interactive video access, comprises local area server 14, LAN 16, local area video cache 15 and a plurality of video display stations like station 17. Local area server 14 serves as a rate changing interface between the high speed LAN 16 and the lower speed WAN 13. As will be described hereinafter, video distribution management system (VDMS) 12 receives requests from all of the video display stations, such as station 17, connected to all of the LANs, such as LAN 16, connected to WAN 13, and provides interactive playback of video files by downloading such video files from library 11 to local caches 15 at the transmission rate of WAN 13, and then provides interactive, real time video playback of these same files from local cache 15 to stations 17 over LAN 16.

In FIG. 2 there is shown a general flow chart of the video distribution management system (VDMS) 12 of FIG. 1. Starting at start box 20, the flow chart of FIG. 2 enters decisions box 21 where it is decided whether or not a video request has been received by VDMS 12 from any of the stations, similar to station 17, connected to the video distribution system of FIG. 1. If no video request has been received, box 22 is entered where information regarding the most recent activity in the local video caches like cache 15 of FIG. 1 is collected and, in box 23, stored for later reference. Such cache activity can be monitored, for example, by counting the number of times each video file has been accessed and by recording the date and time at which each video file was accessed. Other ordering algorithms can be used to select the most active video files. By ordering a set of identifiers for all of the video files currently in each local cache from most active to least active, candidates for deletion from that cache can be determined. These "cache statistics" can subsequently be used should it become necessary to make space in the cache (by removing little-used resident files) if requests for video files not presently in the cache are received. This information is used in both scheduled video playback and in speed match video playback, as described below. Following the update of the cache statistics in box 23, decision box 21 is re-entered to await the receipt of the next video request or to repeat the cache monitoring process in box 22 described above.

If a video request is present, as determined in decision box 21, decision box 24 is entered where it is determined whether the request is for immediate viewing of the video file or the request is for scheduling a future viewing of the video file. If the request is for scheduling a future viewing of the video file, box 25 is entered where the future video playback is scheduled, as will be described in detail in connection with the flow chart of FIG. 3.

If the request is for immediate viewing, as determined in decision box 24, decision box 26 is entered to determine whether or not the requested video file is in the local cache, corresponding to cache 15, serving the local area network, corresponding to LAN 16, from which the request originated. If the video file is in the local cache, decision box 27 is entered where it is determined whether or not the entire video file is in the local cache, or whether only a preface of the video file is in the local cache. For the purposes of the present invention, a preface to a video file is an initial portion of the video file having a duration which is adequate, when viewed in real time at a user station such as station 17, to permit the transmission of the balance of that video file from the remote library 11 to the local cache over the WAN 13 such that the video can be played continuously and without interruption. The calculation of the length of such prefaces is shown in detail in FIG. 5, to be described in detail hereinafter.

If the entire video file is in the local cache, rather than only the preface of that file, as determined by decision box 27, box 28 is entered to allow fully interactive real time playback of the video file from the local cache to the user station over the interconnecting local area network. Interactive, real time playback includes such things as pause, rewind, and multiple viewings of the same video file at a rate consistent with continuous video playback. If only the preface of the video file is in the local cache, as determined by decision box 27, box 29 is entered where so-called "speed match" playback takes place for that video file. As will be described in detail in connection with FIG. 4, speed match playback involves the interactive viewing of an initial portion of the video file while the balance of that video file is being delivered to the local video cache from the library 11 over WAN 13. If the requested video file is not is the local cache, as determined by decision box 26, the same speed match playback algorithm of box 29 is used, but requiring the initial transmission of the preface for viewing before the transmission of the balance of the video file.

The multiple strategies of the video distribution management system of the flow chart of FIG. 2 efficiently matches the high speed access capabilities of existing local area networks with the lower speed distribution capabilities of existing wide area networks to provide an economical overall video distribution system in accordance with the present invention.

In FIG. 3 there is shown a flow chart of the scheduled video playback process suggested in box 25 of FIG. 2. In FIG. 3, the scheduled playback process starts in start box 30 where box 31 is entered to receive the scheduled playback request, parameterized by such attributes as video file name, date and time required, and so forth, transmitted from a viewing station, such as station 17 of FIG. 1, over a local area network, such as LAN 16, through a local area server such as server 14 to video distribution management system 12 of FIG. 1. In FIG. 3, decision box 32 is entered where it is determined whether the requested video file is in the local cache. This determination can be made alternatively by keeping a record of the contents of all local area caches in VDMS 12, or by launching an inquiry to the local area cache in response the receipt of the request.

If the requested video file is already in the local cache, possibly in response to a previous user requesting this video file and this file not yet having been deleted from the cache, box 39 is entered where the requesting viewing station can be given full interactive access to the video file in the local cache at any time, particularly at the time indicated in the video request. The process can then be terminated in stop box 40. If, however, the requested video file is not in the local cache when the request is received, as determined by decision box 32, decision box 33 is entered where it is determined whether or not adequate bandwidth is available in WAN 13 to transmit the video file from the library 11 to the local cache similar to cache 15 in FIG. 1, in sufficient time to meet the schedule. If sufficient bandwidth is not available to transfer the video file in time to meet the schedule, as determined by box 33, box 37 is entered to return a rejection of the request, or an alternative schedule, to the requesting station. The process is then terminated in stop box 40.

If adequate bandwidth is available in WAN 13 to transmit the requested video file from library 11 to the local cache, as determined by decision box 33, decision box 34 is entered where it is determined whether or not there is sufficient storage capability remaining in the local cache (like cache 15 in FIG. 1) to hold the requested video file. If it is determined in decision box 34 that there is insufficient storage capacity available in the local cache, box 36 is entered where the cache statistics, supplied from cache statistics box 38, are used to determine which of the least active files can be deleted to "make space" for the requested video file. These cache statistics are created and updated as shown in FIG. 2 by boxes 22 and 23, and include an ordered list of video file activity. Files which have the least activity should and can be deleted to make space for newly requested video files. In this way, the video cache will always contain those files most frequently requested and most recently accessed. If it is determined in box 36 that sufficient space can be created to hold the requested video file, box 35 is entered where the required video file transfer is actually scheduled. If, on the other hand, sufficient storage space cannot be created, box 37 is entered to return a rejection of the request. The process terminates in stop box 37.

If it is determined in decision box 34 that sufficient storage capacity exists in the local cache to hold the requested video file, box 35 is entered to schedule the video file transfer. This scheduling is designed to ensure the arrival of the video file prior to the scheduled viewing time, and, at the same time, optimize the use of WAN 13. Once the video file is in the local cache, box 39 is entered where the requesting user is given full access to the video file. The process is thereafter terminated in stop box 40. In optimizing the use of WAN 13 for video file transfers, a number of scheduled video requests may be simultaneously outstanding from a number of viewing stations. The overlap of their required use of WAN 13 to transfer the video files can be accommodated by appropriately scheduling the outstanding transfers such that WAN 13 is seldom idle and such that each schedule is still met.

It can be seen that the scheduled video playback process of FIG. 3 optimizes the use of the wide area network 13 of FIG. 1 while, at the same time, makes the use of a remote video library 11 economically feasible. As will be described hereinafter, this scheduled video playback can be combined with the speed match process to be discussed in connection with the flow chart of FIG. 4 to further enhance the efficiency of the overall system.

In FIG. 4 there is show a flow chart of the so-called "speed match playback" process described in general terms in connection with box 29 of FIG. 2. Starting in start box 40, box 41 is entered where the video request is received in the video distribution management system 12 of FIG. 1. In decision box 42, it is determined whether or not the requested video file is in the local cache. If the requested video file is in the local cache, box 43 is entered to determine if the full video file is in the cache, or only the preface of that video file. For the purposes of the present invention, a preface to a video file is an initial portion of the video file having a duration which is adequate to permit the transmission of the balance of that video file from the remote library 11 to the local cache over the WAN 13, while permitting viewing of the entire video file without interruption at the user station such as station 17 of FIG. 1. The process for calculating the appropriate size of the preface is shown in the flow chart of FIG. 5, to be described hereinafter.

If it is determined in decision box 43 that the full video file is present in the local cache, box 54 is entered immediately to give the user full access to the video file. The process is then terminated in stop box 55. If, however, only the preface is held in the local cache, decision box 44 is entered to determine whether there is sufficient bandwidth currently available in WAN 13 to transmit the balance of the video file at a rate consistent with the size of the preface. If there is currently insufficient bandwidth available, as determined by decision box 44, box 45 is entered to recalculate an appropriate preface size that matches the currently available bandwidth in WAN 13. If it is determined that sufficient bandwidth is available, decision box 46 is entered to determine if there is sufficient local cache storage capacity to hold the balance of the video file. The process continues thereafter the same as from box 45.

If it is determined in decision box 42 that the requested video file is not in the local cache, box 45 is entered where the relationship between the bandwidth available on WAN 13, the size of the video file, and the rate at which the video file is played back to the user station are used to determine the size of the preface required for speed match playback, as discussed in connection with FIG. 5. Once the size of the preface is calculated in box 45, decision box 46 is entered where it is determined whether there is enough local cache storage capacity to accommodate either the entire video file, if the preface is not already in the cache, or the balance of the video file if the preface is already present in the cache. If it is determined that there is insufficient local cache to store the video file, box 48 is entered where, as was described in detail for box 36 of FIG. 3, the cache statistics from box 47 are used to recover space in the local cache. When using the speed match playback process, however, the entire least active video file need not be deleted. If the preface of the file to be deleted is retained in the cache and only the balance of the file deleted, then the overall performance of the video distribution system is further enhanced. Any subsequent request for that video file will find the preface still in the cache to permit immediate access for playback. In effect, a hybrid speed match and direct video cache retrieval technique can thus be used for providing essentially transparent local area access to the remote video library 11.

If it is determined in box 48 that sufficient space can be made available to hold the requested video file, box 49 is entered where the transfer of the preface actually occurs. If, on the other hand, sufficient storage capacity cannot be created by the make space process of box 48, box 51 is entered to return a rejection of the request. The process then terminates in stop box 55. If it is determined in decision box 46 that there is sufficient storage capacity in the local cache to hold the video file, or if the make space process of box 48 succeeds, box 49 is entered where the transfer of the preface of the requested video file actually occurs. If, on the other hand, the preface is already in the local cache (by way of boxes 42 and 43), then this step is skipped and the process continues in boxes 50 and 52. To transfer the preface of the video file, any file transfer method known in the art can be used such as a technique which exploits the sockets programming interface with the TCP/IP communications protocol, as described in the Comer text identified above.

After completing the transfer of the preface of the video file from the remote video library 11 to the local cache 15 over WAN 13, two actions are taken simultaneously. Box 52 is entered where the user is given full access to the preface of the video file; box 50 is simultaneously entered where the transfer of the balance of the requested video file is initiated. The user has full access to the preface and to that portion of the balance of the video file already transferred to the local video cache. This gives the user real time, continuous playback of the video file at the user station such as station 17 in FIG. 1. After initiation of the transfer of the balance of the video file to the local cache in box 50, box 53 is entered where the user is given access to the balance of the video file while not exceeding that portion which is currently in the local cache. In this way, the user can begin and continue video playback while the file is actually being transferred into the local cache. The process terminates in stop box 55 once the entire balance of the video file has been transferred to the local cache.

In FIG. 5 there is shown a flow chart of the preface calculation algorithm used in box 45 of FIG. 4. Starting in start box 70, box 71 is entered where the request for the size of the preface for a file "X" is received. In order to calculate the size of the preface, box 72 is entered where information concerning the video file "X" is obtained from a data storage device 73. Data store 73 is, of course, continually updated as new video files are added to or removed from library 11 in FIG. 1. This information includes, among other things, the size of the requested video file "X" and the rate (RATE.sub.P, where P stands for playback) at which that file "X" must be accessed to provide real time viewing of the file. Thereafter, in box 74, information concerning the state of WAN 13 (FIG. 1) is obtained from data storage device 75. The information in store 75 is supplied by the host computer operating all or part of the WAN 13 or a node thereof, or by other facilities in the network, and varies by time-of-day (TOD), network loading, congestion conditions, and other traffic-dependent parameters. This information is continually updated, and includes, among other things, the rate (RATE.sub.T, where T stands for Transfer) at which the identified video file "X" can be transmitted through WAN 13 from library 11 to local cache 15.

The information obtained in boxes 72 and 74 is used in box 76 to calculate the size of the preface in accordance with the formula:

Size.sub.Preface =Size.sub.X =(Rate.sub.playback -Rate.sub.Transfer)/Rate.sub.playback

This preface size value is returned to the speed match box 53 of FIG. 5 in box 77. The process is terminated in stop box 78.

It can be seen that the processes described in FIGS. 2 through 5 cooperate to provide efficient and economical distribution of video files from a remote video library to a large number of widely distributed video file users, using a wide area network and a plurality of local area networks as the transmission vehicles for such video distribution.

It should be clear to those skilled in the art that further embodiments of the present invention may be made by those skilled in the art without departing from the teachings of the present invention.