1. Field of the Invention
The invention relates generally to delivering continuous video data retrieved from an external storage. More particularly, the invention relates to a client playing video data received from a file server via a network.
2. Background of the Related Art
In network systems, a client can comprise, for example, a hardware system 6 as generally shown in PRIOR ART FIG. 1. In the hardware system 6, random access memory (RAM) 30 stores operating systems including an application program 5, and various other programs (not shown), e.g. driver programs. Main processing unit 26 implements various processes which are stored in RAM 30. Storage devices 8 are common devices used to store data which can be transferred to RAM 30. Interface mechanisms 32 comprise one or more of video display, speakers and a keyboard under control of a respective controller. Input/output (I/O) 24 inputs and outputs data.
After a network server (not shown) receives a request for data which it has stored, the requested data is returned to the client via the network, and when the client requires additional data, another request is made and the data returned to the client. Such read request and return of data should occur within a time period which does not significantly reduce the quality of the particular end use for which the data files are being supplied.
The application program stored in a particular area of RAM 30 enables the system to request and receive video data via the network and to play the video data on the video display. In general, the video data is received via the network and transferred to the RAM memory 30 for playing the data on the video display. To play video data in an satisfactory manner requires the data to be delivered at a certain sustained data rate which is dependent on the specific implementation of the application program for playing the video. For example, assume that to satisfactorily play the video data requires 150 kilobytes a second and that a read request size of the network is 6 kilobytes. This would require 25 requests/second or a request every 40 milliseconds. However, networks are asynchronous in nature and a response to a request for data is dependent on many variables including contention (network use). Thus, for example, at one time a response to a request may require 10 milliseconds and at another time the response to a request may require 300 milliseconds. Given such variance, it is quite likely that there will be periods when the required quantity of video data is not delivered, resulting in the video data playing in an unsatisfactory manner.
Previously, one way of addressing the problem of insufficient delivery of video data has been to increase the size of the read request. However, increasing the size of the read request may "clog" the network channel with the response data stream at a specific point in time which is going to result in other clients having to wait longer. This does not result in an optimum use of the network. In addition, the increased size of the read request requires the application program to have sufficient RAM available to store the larger quantity of data which may not be the case. Still further, when the read request size is increased, the system must wait longer for transfer of the larger quantity data before it can start processing the data. This increase in wait time may result in the required amount of video data not being delivered to the video display, disrupting the playback.
Another way in which the problem of insufficient delivery of video data has been addressed is by using different compression techniques and/or "throttling data" (dropping frames). Throttling usually requires an increase in the raw data rate and server utilization, thereby acerbating the problem. However, these techniques require changes in the data stored by the server which is not always convenient. In addition, the quality of the playback may be adversely affected.
Another problem arises when a read request is made to the network from the application program for data. Since the application program must wait for return of the data before it can issue another read request, the read requests are "blocked". However, the application program may have already determined the next data requirement during the wait interval, but cannot make the read request until the data from the preceding read request is returned. Thus, "blocking" of the read request may also result in the RAM having insufficient video data to provide satisfactorily playback.
USPTO Backgrounds
USPTO Backgrounds