CA2142380C - Buffer management policy for an on-demand video server - Google Patents
Buffer management policy for an on-demand video server Download PDFInfo
- Publication number
- CA2142380C CA2142380C CA002142380A CA2142380A CA2142380C CA 2142380 C CA2142380 C CA 2142380C CA 002142380 A CA002142380 A CA 002142380A CA 2142380 A CA2142380 A CA 2142380A CA 2142380 C CA2142380 C CA 2142380C
- Authority
- CA
- Canada
- Prior art keywords
- buffer
- stream
- clients
- video
- streams
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/16—Analogue secrecy systems; Analogue subscription systems
- H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N7/00—Television systems
- H04N7/16—Analogue secrecy systems; Analogue subscription systems
- H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
- H04N7/17309—Transmission or handling of upstream communications
- H04N7/17336—Handling of requests in head-ends
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
- G06F3/0656—Data buffering arrangements
Abstract
A method for reducing the disk bandwidth capacity required by a multimedia server by selectively retaining blocks that have already been read in by one stream for re-use by another. Due to stream-dependent block buffering, the storage requirement is less than that for whole-movie buffering and because the policy is dynamic, it also adapts rapidly to changing access patterns.
Description
2142~~0 BUFFER MANAGEMENT POLICY FOR ON-DEMAND VIDEO SERVER
I. Background of the Invention a. Field of the Invention The present invention relates to a movie (video) on demand system of the type wherein multiple clients are serviced by video streams delivered from a central video server.
b. Related Art I0 With the advent of digital video technology, it is feasible to provide video-on-demand services to a large number of clients over a geographically distributed network.
Because of the hard real-time constraints on response time, sufficient resources are reserved on the server to guarantee continuous delivery of a video stream to the client. With a large number of users, the required disk bandwidth can be very high. With falling memory prices, efficient buffering of video data can be cost-effective in reducing the disk bandwidth requirement.
Traditional buffer management policies employed by various software systems are based upon the concept of a "hot set" of data which is much smaller in size than the total address space. Applying this concept to the video-on-demand environment is not very useful since each multimedia object (e.g. movie) is very large. Some video objects may be more popular than the others, however buffering even a small number of popular video objects requires a very large memory space. Buffering policies which operate at the block level (e.g. single page) do not make sense for the following reasons. First, the unpredictable nature of the buffer hits under an algorithm such as LRU makes it difficult for the server to guarantee continuous delivery of the stream as required for multimedia applications. Additionally, as with whole file buffering, the buffer hit probability will be very small unless a very large buffer size is used.
v II. Summary of the Invention In light of the above, the inventors have discovered a buffer management policy that overcomes both of the above constraints. The policy is based on the following principle. For any two consecutive requests for the same movie, the later stream can read the data brought into the buffer by the earlier stream if the data is retained in the buffer until it is read by the later stream. Two streams SI and S2 are defined as consecutive if S2 is the stream that next reads the blocks that have just been read by Sl. The two streams of such a pair of consecutive streams are referred to, respectively, as the preceding and the following streams.
Understanding such dependencies makes it possible to guarantee continuous delivery of the later stream with a small amount of buffer. With a larger number of concurrent streams reading the same movie, the present invention enables a video server to choose the streams to be retained so as to maximize the number of streams read from the buffer.
Note that inter-arrival times are not uniform due to statistical fluctuations. The ability to choose a small set of inter-arrival times from a large set of samples enables the present invention to exploit the variation in the inter-arrival times.
In addition when multiple clients share a common retrieval stream (also referred to as multicasting) and one of the clients sends a pause request to the server, a small amount of buffer is allocated on behalf of the paused client to retain the blocks brought in by the common retrieval stream. Thus, if the client resumes within a short period of time he can be serviced from the buffer. Note that this creates a new consecutive pair wherein the preceding stream is the common retrieval stream and the fcjllowing stream is the newly created stream (provided from the buffer) for the resumed client. Thus, if the client does resume within the short period of time, buffer management of the consecutive pair continues as previously described. If the client does not resume within the amount of time it takes to fill the allocated buffer, the buffer contents are discarded and the buffer is freed for other use.
~~4238~
III. Brief Description of the Drawings FIG. I is a block diagram of a video-on-demand system according to an embodiment of the present invention;
FIG. 2 shows data structures maintained by the buffer manager of FIG. 1;
FIGS 3A-3C are a flow chart of the handling of a start or resume request by the buffer manager of FIG. 1;
FIG. 4 is a flow chart of the actions taken by the buffer manager of FIG. 1 on receipt of a stop request;
FIG. 5 is a flow chart of the actions taken by the buffer manager of FIG. I on receipt of a pause request;
FIG. 6 is a flow chart of the steps taken by the buffer manager of FIG. I to find buffered streams when new buffer becomes available; and, FIGS. 7A and 7B show, respectively, the interactions between the disk I/O
process and the communication process with the buffer manager of FIG. 1.
IV. Detailed Description of a Preferred Embodiimcnt The buffer requirement for a following stream to read the data from its preceding stream is a function of the time interval between the two streams and the compression method used.
Such an estimate can be obtained at the time when a new stream is created. The policy orders requests for all movies in increasing order of their buffer requirements. The policy then allocates buffer to as many of the atreams as possible. The ordering of consecutive streams and allocation of buffer takes place only due to the arrival of a new stream or the changing of an existing consecutive relationship due to ending or pausing of a stream.
If the buffer requirement of a newly started stream is smaller than that of a stream to which buffer has already been allocated then the buffer may be taken away from the earlier buffered stream.
Fig. 1 is a block diagram of a video-on-demand system according to an embodiment of the present invention. it is assumed that clients 10 make requests from a video server 30 via a communication network 20. Clients can submit start, stop, pause and resume requests. The video server contains a number of components. The buffer storage is subdivided into two pools - the free pool 70 that contains free blocks that can be used for the storage of data and the buffer pool 40 that has blocks containing data ready for transmission to the users. The buffer pool contains a sub-buffer pool 45 (the small buffer pool) consisting of a collection of small buffers (e.g. each enough to hold 30 seconds worth video). The disk I/O
process 50 reads video data into empty buffers obtained from the free pool 70 and inserts the buffers into the buffer pool. The communication process 60 transmits video data to the clients. The video data that has been read into the buffer for a client can be retained for re-transmission to other clients. This conserves server resources since the re-transmitted block does not have to be re-read from disk. Hence the buffer manager 80 selects a set of clients whose blocks will be retained in the buffer for subsequent re-transmission to other clients.
Clients receiving I S re-transmitted blocks will be referred to as buffered clients and streams serving the re-transmitted blocks to the buffered clients will be referred to as buffered streams.
As shown in Fig. 2, a number of data structures are maintained by the buffer manager. The stream table 110 contains one stream entry 115 for each movie stream currently active. The stream entry includes the identifier of the stream (Stream I D) 120, the movie identifier (movie Number) 125, the current block being displayed (Current Block) 130, the read state of the stream (Read State) 135, the amount of buffer required to serve the stream from a buffer (Buffer Reqd) 140, size list pointers (Size List Ptr) 145 and movie list pointer (Movie List Ptr) 150. The read state 135 can take on 5 values - DISK if the stream is reading from disk, BUFFER if the stream is a buffered stream, DISK-TO-BUFFER if the stream is in the process of being switched from the disk to the buffer, BUFFER-TO-DISK if the stream is in the process of being switched from the buffer to disk and SMALL-BUFFER if the stream is reading from a small buffer. The buffer reqd. 140 is the amount of buffer necessary to store all of the blocks between the current stream and the immediately preceding stream (i.e.
the difference between the current block number of the preceding stream and the current block number 130 of the current stream).
The size list 160 is a doubly linked list of all the active streams in ascending order of the buffer reqd. field. In the present embodiment, the size list 160 is formed by chaining the size list pointers 145 of all entries in the stream table. Alternatively, the size list can be provided as a separate table of stream identifiers l20 in ascending order of buffer required 140 size.
The size list ptr 145 of each stream entry points to the next and previous entries in the size list. There are additional global pointers 1 C 5, 170, to the largest and smallest elements in the size list and the largest buffered stream (pointer 171) and the disk stream with the smallest buffer required 140. (pointer 172).
For each active movie, there is a movie list 180 which is formed by chaining the movie list pointers 150 of all entries in the stream table that are carrying the active movie. Pointers 182, 183 to the first and last entries of the movie list for each movie are stored in a movie table I75. The movie list is a list of all the stream entries for that movie in ascending order of current block. The movie list ptr 150 for each entry points to the next entry in the movie list.
Two counters - the nominal free space 18.5 and the actual free space 190 are used to keep track of the amount of buffer space available. The actual free space counter is initialized to the total amount of buffer available. The actual free space counter is used to keep track of the actual amount of buffer available. The nominal free space counter is initialized to some high fraction (such as 90%) of the total buffer space available. The nominal free space counter is used by the buffer manager when allocating and deallocating space;
i.e.when allocating buffer space, the buffer manager will allocate only the amount of space specified by the nominal free space counter. This is because fluctuations in compression ratios may cause the actual amount of buffer required by a stream to vary; hence at times a stream may 214~~80 require more or less buffer space than allocated to it by the buffer manager.
The difference between the initial values of the nominal and actual free space counters (10%
in the example) is a safety buffer used for accommodating this variation.
A flow chart of the handling of a start or resume request by the buffer manager is shown in Figs. 3A-3C. If an entry does not already exist for the stream, a new stream entry is created for the request. A new stream entry 1 I S is created for the request in step 214 and inserted into the stream table 110. The read state of the new stream entry is set to DISK. The current block 130 is set to the requested block and the stream entry is inserted into the movie list 180 for the movie using the current block to determine its position.
In step 215, the buffer manager determines if the movie can be serviced from the small buffer pool 45 by checking the read state. 1f the read state is SMALL-BUFFER, the buffer manager starts servicing the movie from the small buffer pool and exits in step 217. Here the resumed stream uses data from the multicast stream in a continuous fashion by reading the stored stream data from the small buffer. If the movie cannot be serviced from the small buffer pool, in step 218 the buffer manager uses the position of the stream entry for the request to deter-mine if the request falls between two requests where The following request is being served from a buffer (i.e. is a buffered stream). If the request falls between two requests where the following request is being served from a buffer, the current stream can also be served from the buffer. 1n step 2l9 the buffer manager recomputes the buffer reqd.
field 140 of the following request as well as that of the current request, adjusts the position of the following request in the size lest (by adjusting the size list pointers), sets the read state of the current request to BUFFER. The buffer manager also adjusts the pointers of the stream entry of the current request in the size list and the movie list and exits in step 220.
If the stream is not inside a buffered pair, in step 222 the movie list is used to determine the closest preceding stream if any for the movie (i.e. the stream among all the streams reading this movie whose current block is closest to the current block of this request). If no such block exists, the buffer manager task exits in step 225. If such a request exists in step 230 the buffer reqd. 140 in the stream entry is set to the amount of storage required to buffer all the blocks between the immediately preceding stream and the current request. The stream entry is then inserted into the size list 160 using the buffer reqd. field to determine its position.
Next, in step 235 the buffer manager examines the nominal free space counter.
185 to determine if enough free buffer space exists to accommodate this request. If enough free buffer space exists, the buffer manager initiates the steps (270-280) necessary to buffer the request. If enough free buffer is not available, the buffer manager executes a buffer scan consisting of steps 240 to 260 to determine if this stream should be buffered by displacing some other stream. First, the scan pointer is initialized in step 240 to the largest buffered stream 171. The buffer manager then checks in step 24.5 if the buffer reqd. by the scanned stream is larger than the buffer required by the current request. 1f it is not, the buffer manager exits in step 250. if it is larger, the buffer manager checks in step 255 if the scanned stream can be moved to disk. 1f the stream cannot be moved, in step 260 the buffer manager examines the size list and advances the scan pointer to the buffered stream with the next smallest buffer reqd..
f the scanned stream can be moved, in step 265 its read state is set Lo DISK
and the nominal free buff er space counter is incremented by the buffer reqd. field of the scanned stream. This effectively frees the buffer held by the scanned stream. In step 270, the buffer manager changes the read state of the request to DISK-TO-BUFFER and decrements the nominal free space counter by the buffer reqd. in step 27.5. In step 280, the buffer manager exits.
The actions taken on receipt of a stop request arc shown in Fig. 4. In step 320, the stream entry for the stream is removed from the stream table 1 t 0, the size list 160 and the movie list 175. In step 330, the buffer manager determines if the stream had allocated buffer by 2z4~~~0 examining its read state 135 (BUFFER or DISK-TO-BUFFER). If not, the buffer manager exits in step 340. If the stream had allocated buffer, in step 350 the buffer manager frees the buffer by incrementing the nominal free space counter 185 by the buffer reqd.
140. The buffer manager then executes the "Look for new buffered stream" steps shown in Fig. 6.
Fig. 5 shows the actions taken on receipt of a pause request. First, in step 511 the buffer manager determines whether the stream is a multicast stream. If it is, in step 512 it checks to see if a small buffer is available in the small buffer pool. If no small buffer is available, then the buffer manager continues with normal processing in step 515. If a small buffer is available, it is allocated to the stream in step 513 and the buffer manager exits in step 514.
If the stream is not a multicast stream, in step 51.5 the stream entry for this stream is removed from the stream table 110, and the size list and movie list pointers 145, 150 for the remaining entries are adjusted accordingly.
If the current stream had allocated buffer (read state BUFFER or DISK-TO-BUFFER), the nominal free space counter I85 is inerernented by the buffer reqd.fteld 140 of the current stream. The buffer manager then rccomputes in step 520 the buffer reqd. 140 of the immediately following stream. The position of the following stream in the size list 160 is adjusted (based upon the new value of the buffer reqd. field.) to maintain the ascending order.
In .step 525, the buffer manager checks if the current stream had a read state 135 of BUFFER or SMALL-BUFFER. If the stream had such a read state, in step 530 the buffer manager checks to see if the following stream was a buffered stream (read state BUFFER, DISK-TO-BUFFER or SMALL-BUFFER). If the following stream also was buffered, the buffer manager is allocates it additional buffer in step .535 by decrementing the nominal free space counter by the buffer reqd. field of the current stream and exits in step 540. If the following stream was not buffered,the buffer manager initiates the actions needed to free the YO9-94-004 9 2 ~ 4 2 3 8 a buffer held by the current stream in step 560.
If the current stream did not have a read state of BUFFER or SMALL-BUFFER in step 525,the buffer manager checks in step 545 if the following stream is reading from the buffer (read state BUFFER, SMALL-BUFFER or DISK-TO-BUFFER). If it is not reading from the buffer, the buffer manager exits in step 550. If it is reading from buffer, the buffer manager moves the following stream to disk in step 555 by setting the read state to DISK.
It then frees the buffer held by the following stream by incrementing the nominal free space counter 185 by the buffer rcqd. field 140 of the following stream. Lt then executes the "Look for new buffered stream" steps shown in Fig. 6. The buffer manager continuously monitors the small buffers to determine when they are exhausted. If the small buffer allocated to a paused client is exhausted (i.e. the client did not resume within the time taken to fill the buffer), in step 565 the buffer manager frees the small buffer and executes pause processing starting at step 515.
Fig. 6 shows the steps taken by the buffer manager to find buffered streams when new buffer becomes available. In step 620, the buffer manager checks to see if the smallest disk stream 172 can be buffered by comparing its buffer reqd. field 140 to the nominal free space counter 185. If the nominal free space counter is smaller, there is not sufficient buffer space,and the buffer manager exits in step 630. 1f there is sufficient space, the buffer manager changes the read state of the stream to DISK-TO-BUFFER, decrements the nominal free space counter by the buffer reqd.field, updates the smallest disk stream pointer and loops back to step 620.
Figs. 7A and 7B show, respectively, the interactions between the disk I/O
process 50 and the communication process 60 with the buffer manager. Before initiating an I/O to read a requested block, the disk 1/O process looks in the buffer pool in step 720 to see if the requested block has been read in. If it has, the disk I/O process checks the read state of the stream to see if it is DISK TO_BUFFER in step 723. If it is not, the process exits in step 214~~'8~
730. if it is DISK TO_BUFFER, the disk I/O process changes the read state to BUFFER
in step 726 and exits in step 730. If not, in step 740 the disk I/O process gets a free buffer from the free pool, decrements the actual free space counter starts the I/O
and exits in step 750.
After transmitting a block, the communication process checks the read state of the following stream in step 760. If the read state is BUFFER or DISK TO-BUFFER, the communications process exits in step 770. Otherwise, the process increments the actual free space counter 190 and returns the block to the free pool 70.
Now that the invention has been described by way of the preferred embodiment, various modifications and improvements will occur to those of skill in the art. Thus, it should be understood that the preferred embodiment has been provided as an example and not as a limitation. The scope of the invention is defined by the appended claims.
I. Background of the Invention a. Field of the Invention The present invention relates to a movie (video) on demand system of the type wherein multiple clients are serviced by video streams delivered from a central video server.
b. Related Art I0 With the advent of digital video technology, it is feasible to provide video-on-demand services to a large number of clients over a geographically distributed network.
Because of the hard real-time constraints on response time, sufficient resources are reserved on the server to guarantee continuous delivery of a video stream to the client. With a large number of users, the required disk bandwidth can be very high. With falling memory prices, efficient buffering of video data can be cost-effective in reducing the disk bandwidth requirement.
Traditional buffer management policies employed by various software systems are based upon the concept of a "hot set" of data which is much smaller in size than the total address space. Applying this concept to the video-on-demand environment is not very useful since each multimedia object (e.g. movie) is very large. Some video objects may be more popular than the others, however buffering even a small number of popular video objects requires a very large memory space. Buffering policies which operate at the block level (e.g. single page) do not make sense for the following reasons. First, the unpredictable nature of the buffer hits under an algorithm such as LRU makes it difficult for the server to guarantee continuous delivery of the stream as required for multimedia applications. Additionally, as with whole file buffering, the buffer hit probability will be very small unless a very large buffer size is used.
v II. Summary of the Invention In light of the above, the inventors have discovered a buffer management policy that overcomes both of the above constraints. The policy is based on the following principle. For any two consecutive requests for the same movie, the later stream can read the data brought into the buffer by the earlier stream if the data is retained in the buffer until it is read by the later stream. Two streams SI and S2 are defined as consecutive if S2 is the stream that next reads the blocks that have just been read by Sl. The two streams of such a pair of consecutive streams are referred to, respectively, as the preceding and the following streams.
Understanding such dependencies makes it possible to guarantee continuous delivery of the later stream with a small amount of buffer. With a larger number of concurrent streams reading the same movie, the present invention enables a video server to choose the streams to be retained so as to maximize the number of streams read from the buffer.
Note that inter-arrival times are not uniform due to statistical fluctuations. The ability to choose a small set of inter-arrival times from a large set of samples enables the present invention to exploit the variation in the inter-arrival times.
In addition when multiple clients share a common retrieval stream (also referred to as multicasting) and one of the clients sends a pause request to the server, a small amount of buffer is allocated on behalf of the paused client to retain the blocks brought in by the common retrieval stream. Thus, if the client resumes within a short period of time he can be serviced from the buffer. Note that this creates a new consecutive pair wherein the preceding stream is the common retrieval stream and the fcjllowing stream is the newly created stream (provided from the buffer) for the resumed client. Thus, if the client does resume within the short period of time, buffer management of the consecutive pair continues as previously described. If the client does not resume within the amount of time it takes to fill the allocated buffer, the buffer contents are discarded and the buffer is freed for other use.
~~4238~
III. Brief Description of the Drawings FIG. I is a block diagram of a video-on-demand system according to an embodiment of the present invention;
FIG. 2 shows data structures maintained by the buffer manager of FIG. 1;
FIGS 3A-3C are a flow chart of the handling of a start or resume request by the buffer manager of FIG. 1;
FIG. 4 is a flow chart of the actions taken by the buffer manager of FIG. 1 on receipt of a stop request;
FIG. 5 is a flow chart of the actions taken by the buffer manager of FIG. I on receipt of a pause request;
FIG. 6 is a flow chart of the steps taken by the buffer manager of FIG. I to find buffered streams when new buffer becomes available; and, FIGS. 7A and 7B show, respectively, the interactions between the disk I/O
process and the communication process with the buffer manager of FIG. 1.
IV. Detailed Description of a Preferred Embodiimcnt The buffer requirement for a following stream to read the data from its preceding stream is a function of the time interval between the two streams and the compression method used.
Such an estimate can be obtained at the time when a new stream is created. The policy orders requests for all movies in increasing order of their buffer requirements. The policy then allocates buffer to as many of the atreams as possible. The ordering of consecutive streams and allocation of buffer takes place only due to the arrival of a new stream or the changing of an existing consecutive relationship due to ending or pausing of a stream.
If the buffer requirement of a newly started stream is smaller than that of a stream to which buffer has already been allocated then the buffer may be taken away from the earlier buffered stream.
Fig. 1 is a block diagram of a video-on-demand system according to an embodiment of the present invention. it is assumed that clients 10 make requests from a video server 30 via a communication network 20. Clients can submit start, stop, pause and resume requests. The video server contains a number of components. The buffer storage is subdivided into two pools - the free pool 70 that contains free blocks that can be used for the storage of data and the buffer pool 40 that has blocks containing data ready for transmission to the users. The buffer pool contains a sub-buffer pool 45 (the small buffer pool) consisting of a collection of small buffers (e.g. each enough to hold 30 seconds worth video). The disk I/O
process 50 reads video data into empty buffers obtained from the free pool 70 and inserts the buffers into the buffer pool. The communication process 60 transmits video data to the clients. The video data that has been read into the buffer for a client can be retained for re-transmission to other clients. This conserves server resources since the re-transmitted block does not have to be re-read from disk. Hence the buffer manager 80 selects a set of clients whose blocks will be retained in the buffer for subsequent re-transmission to other clients.
Clients receiving I S re-transmitted blocks will be referred to as buffered clients and streams serving the re-transmitted blocks to the buffered clients will be referred to as buffered streams.
As shown in Fig. 2, a number of data structures are maintained by the buffer manager. The stream table 110 contains one stream entry 115 for each movie stream currently active. The stream entry includes the identifier of the stream (Stream I D) 120, the movie identifier (movie Number) 125, the current block being displayed (Current Block) 130, the read state of the stream (Read State) 135, the amount of buffer required to serve the stream from a buffer (Buffer Reqd) 140, size list pointers (Size List Ptr) 145 and movie list pointer (Movie List Ptr) 150. The read state 135 can take on 5 values - DISK if the stream is reading from disk, BUFFER if the stream is a buffered stream, DISK-TO-BUFFER if the stream is in the process of being switched from the disk to the buffer, BUFFER-TO-DISK if the stream is in the process of being switched from the buffer to disk and SMALL-BUFFER if the stream is reading from a small buffer. The buffer reqd. 140 is the amount of buffer necessary to store all of the blocks between the current stream and the immediately preceding stream (i.e.
the difference between the current block number of the preceding stream and the current block number 130 of the current stream).
The size list 160 is a doubly linked list of all the active streams in ascending order of the buffer reqd. field. In the present embodiment, the size list 160 is formed by chaining the size list pointers 145 of all entries in the stream table. Alternatively, the size list can be provided as a separate table of stream identifiers l20 in ascending order of buffer required 140 size.
The size list ptr 145 of each stream entry points to the next and previous entries in the size list. There are additional global pointers 1 C 5, 170, to the largest and smallest elements in the size list and the largest buffered stream (pointer 171) and the disk stream with the smallest buffer required 140. (pointer 172).
For each active movie, there is a movie list 180 which is formed by chaining the movie list pointers 150 of all entries in the stream table that are carrying the active movie. Pointers 182, 183 to the first and last entries of the movie list for each movie are stored in a movie table I75. The movie list is a list of all the stream entries for that movie in ascending order of current block. The movie list ptr 150 for each entry points to the next entry in the movie list.
Two counters - the nominal free space 18.5 and the actual free space 190 are used to keep track of the amount of buffer space available. The actual free space counter is initialized to the total amount of buffer available. The actual free space counter is used to keep track of the actual amount of buffer available. The nominal free space counter is initialized to some high fraction (such as 90%) of the total buffer space available. The nominal free space counter is used by the buffer manager when allocating and deallocating space;
i.e.when allocating buffer space, the buffer manager will allocate only the amount of space specified by the nominal free space counter. This is because fluctuations in compression ratios may cause the actual amount of buffer required by a stream to vary; hence at times a stream may 214~~80 require more or less buffer space than allocated to it by the buffer manager.
The difference between the initial values of the nominal and actual free space counters (10%
in the example) is a safety buffer used for accommodating this variation.
A flow chart of the handling of a start or resume request by the buffer manager is shown in Figs. 3A-3C. If an entry does not already exist for the stream, a new stream entry is created for the request. A new stream entry 1 I S is created for the request in step 214 and inserted into the stream table 110. The read state of the new stream entry is set to DISK. The current block 130 is set to the requested block and the stream entry is inserted into the movie list 180 for the movie using the current block to determine its position.
In step 215, the buffer manager determines if the movie can be serviced from the small buffer pool 45 by checking the read state. 1f the read state is SMALL-BUFFER, the buffer manager starts servicing the movie from the small buffer pool and exits in step 217. Here the resumed stream uses data from the multicast stream in a continuous fashion by reading the stored stream data from the small buffer. If the movie cannot be serviced from the small buffer pool, in step 218 the buffer manager uses the position of the stream entry for the request to deter-mine if the request falls between two requests where The following request is being served from a buffer (i.e. is a buffered stream). If the request falls between two requests where the following request is being served from a buffer, the current stream can also be served from the buffer. 1n step 2l9 the buffer manager recomputes the buffer reqd.
field 140 of the following request as well as that of the current request, adjusts the position of the following request in the size lest (by adjusting the size list pointers), sets the read state of the current request to BUFFER. The buffer manager also adjusts the pointers of the stream entry of the current request in the size list and the movie list and exits in step 220.
If the stream is not inside a buffered pair, in step 222 the movie list is used to determine the closest preceding stream if any for the movie (i.e. the stream among all the streams reading this movie whose current block is closest to the current block of this request). If no such block exists, the buffer manager task exits in step 225. If such a request exists in step 230 the buffer reqd. 140 in the stream entry is set to the amount of storage required to buffer all the blocks between the immediately preceding stream and the current request. The stream entry is then inserted into the size list 160 using the buffer reqd. field to determine its position.
Next, in step 235 the buffer manager examines the nominal free space counter.
185 to determine if enough free buffer space exists to accommodate this request. If enough free buffer space exists, the buffer manager initiates the steps (270-280) necessary to buffer the request. If enough free buffer is not available, the buffer manager executes a buffer scan consisting of steps 240 to 260 to determine if this stream should be buffered by displacing some other stream. First, the scan pointer is initialized in step 240 to the largest buffered stream 171. The buffer manager then checks in step 24.5 if the buffer reqd. by the scanned stream is larger than the buffer required by the current request. 1f it is not, the buffer manager exits in step 250. if it is larger, the buffer manager checks in step 255 if the scanned stream can be moved to disk. 1f the stream cannot be moved, in step 260 the buffer manager examines the size list and advances the scan pointer to the buffered stream with the next smallest buffer reqd..
f the scanned stream can be moved, in step 265 its read state is set Lo DISK
and the nominal free buff er space counter is incremented by the buffer reqd. field of the scanned stream. This effectively frees the buffer held by the scanned stream. In step 270, the buffer manager changes the read state of the request to DISK-TO-BUFFER and decrements the nominal free space counter by the buffer reqd. in step 27.5. In step 280, the buffer manager exits.
The actions taken on receipt of a stop request arc shown in Fig. 4. In step 320, the stream entry for the stream is removed from the stream table 1 t 0, the size list 160 and the movie list 175. In step 330, the buffer manager determines if the stream had allocated buffer by 2z4~~~0 examining its read state 135 (BUFFER or DISK-TO-BUFFER). If not, the buffer manager exits in step 340. If the stream had allocated buffer, in step 350 the buffer manager frees the buffer by incrementing the nominal free space counter 185 by the buffer reqd.
140. The buffer manager then executes the "Look for new buffered stream" steps shown in Fig. 6.
Fig. 5 shows the actions taken on receipt of a pause request. First, in step 511 the buffer manager determines whether the stream is a multicast stream. If it is, in step 512 it checks to see if a small buffer is available in the small buffer pool. If no small buffer is available, then the buffer manager continues with normal processing in step 515. If a small buffer is available, it is allocated to the stream in step 513 and the buffer manager exits in step 514.
If the stream is not a multicast stream, in step 51.5 the stream entry for this stream is removed from the stream table 110, and the size list and movie list pointers 145, 150 for the remaining entries are adjusted accordingly.
If the current stream had allocated buffer (read state BUFFER or DISK-TO-BUFFER), the nominal free space counter I85 is inerernented by the buffer reqd.fteld 140 of the current stream. The buffer manager then rccomputes in step 520 the buffer reqd. 140 of the immediately following stream. The position of the following stream in the size list 160 is adjusted (based upon the new value of the buffer reqd. field.) to maintain the ascending order.
In .step 525, the buffer manager checks if the current stream had a read state 135 of BUFFER or SMALL-BUFFER. If the stream had such a read state, in step 530 the buffer manager checks to see if the following stream was a buffered stream (read state BUFFER, DISK-TO-BUFFER or SMALL-BUFFER). If the following stream also was buffered, the buffer manager is allocates it additional buffer in step .535 by decrementing the nominal free space counter by the buffer reqd. field of the current stream and exits in step 540. If the following stream was not buffered,the buffer manager initiates the actions needed to free the YO9-94-004 9 2 ~ 4 2 3 8 a buffer held by the current stream in step 560.
If the current stream did not have a read state of BUFFER or SMALL-BUFFER in step 525,the buffer manager checks in step 545 if the following stream is reading from the buffer (read state BUFFER, SMALL-BUFFER or DISK-TO-BUFFER). If it is not reading from the buffer, the buffer manager exits in step 550. If it is reading from buffer, the buffer manager moves the following stream to disk in step 555 by setting the read state to DISK.
It then frees the buffer held by the following stream by incrementing the nominal free space counter 185 by the buffer rcqd. field 140 of the following stream. Lt then executes the "Look for new buffered stream" steps shown in Fig. 6. The buffer manager continuously monitors the small buffers to determine when they are exhausted. If the small buffer allocated to a paused client is exhausted (i.e. the client did not resume within the time taken to fill the buffer), in step 565 the buffer manager frees the small buffer and executes pause processing starting at step 515.
Fig. 6 shows the steps taken by the buffer manager to find buffered streams when new buffer becomes available. In step 620, the buffer manager checks to see if the smallest disk stream 172 can be buffered by comparing its buffer reqd. field 140 to the nominal free space counter 185. If the nominal free space counter is smaller, there is not sufficient buffer space,and the buffer manager exits in step 630. 1f there is sufficient space, the buffer manager changes the read state of the stream to DISK-TO-BUFFER, decrements the nominal free space counter by the buffer reqd.field, updates the smallest disk stream pointer and loops back to step 620.
Figs. 7A and 7B show, respectively, the interactions between the disk I/O
process 50 and the communication process 60 with the buffer manager. Before initiating an I/O to read a requested block, the disk 1/O process looks in the buffer pool in step 720 to see if the requested block has been read in. If it has, the disk I/O process checks the read state of the stream to see if it is DISK TO_BUFFER in step 723. If it is not, the process exits in step 214~~'8~
730. if it is DISK TO_BUFFER, the disk I/O process changes the read state to BUFFER
in step 726 and exits in step 730. If not, in step 740 the disk I/O process gets a free buffer from the free pool, decrements the actual free space counter starts the I/O
and exits in step 750.
After transmitting a block, the communication process checks the read state of the following stream in step 760. If the read state is BUFFER or DISK TO-BUFFER, the communications process exits in step 770. Otherwise, the process increments the actual free space counter 190 and returns the block to the free pool 70.
Now that the invention has been described by way of the preferred embodiment, various modifications and improvements will occur to those of skill in the art. Thus, it should be understood that the preferred embodiment has been provided as an example and not as a limitation. The scope of the invention is defined by the appended claims.
Claims (12)
1. A method of managing memory buffer in a video server, wherein a plurality of clients are served from video streams provided from disks, comprising the step o~
determining buffer requirements of a plurality of the video streams, the buffer requirements being a number of frames separating each video stream from an immediately previous video stream carrying the same video;
creating a list of streams ordered by the buffer requirements;
allocating the buffer starting from a stream with a smallest buffer requirement and proceeding to streams with larger buffer requirements until the buffer requirement of a stream can not be satisfied;
retaining blocks of the immediately previous stream in the buffer allocated to a following stream and discarding the blocks from the buffer as they are read by a client viewing the following stream;
updating the list when any of starting, stopping, pausing and resuming of a video occurs; and, responsive to the updating, reallocating the buffer starting from a stream with a smallest buffer requirement and proceeding to streams with larger buffer requirements until the buffer requirement of a stream can not be satisfied.
determining buffer requirements of a plurality of the video streams, the buffer requirements being a number of frames separating each video stream from an immediately previous video stream carrying the same video;
creating a list of streams ordered by the buffer requirements;
allocating the buffer starting from a stream with a smallest buffer requirement and proceeding to streams with larger buffer requirements until the buffer requirement of a stream can not be satisfied;
retaining blocks of the immediately previous stream in the buffer allocated to a following stream and discarding the blocks from the buffer as they are read by a client viewing the following stream;
updating the list when any of starting, stopping, pausing and resuming of a video occurs; and, responsive to the updating, reallocating the buffer starting from a stream with a smallest buffer requirement and proceeding to streams with larger buffer requirements until the buffer requirement of a stream can not be satisfied.
2. The method of claim 1 wherein a plurality of clients share a common one of the video streams, comprising the further steps of determining when one of the clients sharing the common one of the video streams has paused;
allocating a portion of the buffer to retain the blocks of the common one of the video streams on behalf of the client who has paused;
determining when the portion of the buffer is full;
determining when a resume request has been received from the paused client;
when the buffer is full and a resume request has not been received from the paused client for whom buffer was allocated before the buffer is full, deallocating the buffer;
when a resume request is received before the portion of the buffer is full, serving the client from the buffer and discarding blocks from the buffer as they are consumed by the client.
allocating a portion of the buffer to retain the blocks of the common one of the video streams on behalf of the client who has paused;
determining when the portion of the buffer is full;
determining when a resume request has been received from the paused client;
when the buffer is full and a resume request has not been received from the paused client for whom buffer was allocated before the buffer is full, deallocating the buffer;
when a resume request is received before the portion of the buffer is full, serving the client from the buffer and discarding blocks from the buffer as they are consumed by the client.
3. A method of managing memory buffer in a video server, wherein a plurality of clients are served from video streams provided from disks, comprising the step of:
determining buffer requirements of a plurality of the video streams, the buffer requirements being a number of frames separating each video stream from an immediately previous video stream carrying the same video; and, examining the buffer requirements and as a function thereof, allocating the buffer so as to maximize a number of streams that can be provided therefrom;
retaining blocks of the immediately preceding stream in the buffer allocated to a following stream and discarding the blocks from the buffer as they are read by a client viewing the following stream.
determining buffer requirements of a plurality of the video streams, the buffer requirements being a number of frames separating each video stream from an immediately previous video stream carrying the same video; and, examining the buffer requirements and as a function thereof, allocating the buffer so as to maximize a number of streams that can be provided therefrom;
retaining blocks of the immediately preceding stream in the buffer allocated to a following stream and discarding the blocks from the buffer as they are read by a client viewing the following stream.
4. The method of claim 3 comprising the further steps of:
determining when one of the clients has paused;
allocating a portion of the buffer to retain blocks of the video streams on behalf of the one of the clients who has paused; and, when a resume request is received from the one of the clients, serving the one of the clients from the buffer.
determining when one of the clients has paused;
allocating a portion of the buffer to retain blocks of the video streams on behalf of the one of the clients who has paused; and, when a resume request is received from the one of the clients, serving the one of the clients from the buffer.
5. The method of claim 4 wherein at least some memory buffer is locally disposed at a site of the one of the clients and wherein when the resume request is received from the one of the clients before the portion of the buffer is full, the one of the clients is served from the memory buffer which is locally disposed.
6. The method of claim 3 wherein a plurality of clients share a common one of the video streams, comprising the further steps of:
determining when one of the clients sharing the common one of the video streams has paused;
allocating a portion of the buffer to retain the blocks of the common one of the video streams on behalf of the client who has paused;
determining when the portion of the buffer is full;
determining when a resume request has been received from the paused client;
when the buffer is full and a resume request has not been received from the paused client for whom buffer was allocated before the buffer is full, deallocating the buffer;
when a resume request is received before the portion of the buffer is full, serving the client from the buffer and discarding blocks from the buffer as they are consumed by the client.
determining when one of the clients sharing the common one of the video streams has paused;
allocating a portion of the buffer to retain the blocks of the common one of the video streams on behalf of the client who has paused;
determining when the portion of the buffer is full;
determining when a resume request has been received from the paused client;
when the buffer is full and a resume request has not been received from the paused client for whom buffer was allocated before the buffer is full, deallocating the buffer;
when a resume request is received before the portion of the buffer is full, serving the client from the buffer and discarding blocks from the buffer as they are consumed by the client.
7. A method of managing memory buffer in a video server, wherein a plurality of clients are served from video streams provided from disks, comprising the steps of:
determining when one of the clients sharing one of the video streams has paused;
allocating a portion of the buffer to retain the blocks of the one of the video streams on behalf of the one of the clients;
determining when the portion of the buffer is full;
determining when a resume request has been received from the one of the clients;
when the buffer is full and a resume request has not been received from the one of the clients before the buffer is full, deallocating the buffer; and, when a resume request is received from the one of the clients before the portion of the buffer is full, serving the one of the clients from the buffer and discarding blocks from the buffer as they are consumed by the one of the clients.
determining when one of the clients sharing one of the video streams has paused;
allocating a portion of the buffer to retain the blocks of the one of the video streams on behalf of the one of the clients;
determining when the portion of the buffer is full;
determining when a resume request has been received from the one of the clients;
when the buffer is full and a resume request has not been received from the one of the clients before the buffer is full, deallocating the buffer; and, when a resume request is received from the one of the clients before the portion of the buffer is full, serving the one of the clients from the buffer and discarding blocks from the buffer as they are consumed by the one of the clients.
8. A system for managing memory buffer in a video server, wherein a plurality of clients are served from video streams provided from disks, comprising:
means for determining buffer requirements of a plurality of the video streams, the buffer requirements being a number of frames separating each video stream from an immediately previous video stream carrying the same video;
means for examining the buffer requirements and as a function thereof, allocating the buffer so as to maximize a number of streams that can be provided therefrom; and, means for retaining blocks of the immediately previous stream in the buffer and discarding the blocks from the buffer as they are read from the buffer by a client.
means for determining buffer requirements of a plurality of the video streams, the buffer requirements being a number of frames separating each video stream from an immediately previous video stream carrying the same video;
means for examining the buffer requirements and as a function thereof, allocating the buffer so as to maximize a number of streams that can be provided therefrom; and, means for retaining blocks of the immediately previous stream in the buffer and discarding the blocks from the buffer as they are read from the buffer by a client.
9. A method of managing memory buffer in a system, wherein a plurality of data consumers are served from data streams provided from at least one storage device, comprising the steps of:
determining buffer requirements of a plurality of the data streams, the buffer requirements being a number of data blocks separating each data stream from an immediately previous data stream carrying the same information; and based on the buffer requirements, allocating the buffer so as to maximize a number of data streams that can be provided therefrom.
determining buffer requirements of a plurality of the data streams, the buffer requirements being a number of data blocks separating each data stream from an immediately previous data stream carrying the same information; and based on the buffer requirements, allocating the buffer so as to maximize a number of data streams that can be provided therefrom.
10. A method of managing memory buffer in a system wherein a plurality of data consumers are served from data streams, comprising the step of:
determining buffer requirements of a plurality of the data streams, the buffer requirements being a number of data blocks separating each data stream from a previously commenced data stream carrying the same information;
allocating the buffer starting from a data stream with the smallest buffer requirement and proceeding to data streams with larger buffer requirements until the buffer requirements of one of the data streams can not be satisfied;
retaining blocks of a previously commenced data streams in the buffer allocated to a corresponding subsequently commenced data stream carrying the same information; and, servicing a data consumer from the subsequently commenced data streams using data blocks provided by way of the buffer.
determining buffer requirements of a plurality of the data streams, the buffer requirements being a number of data blocks separating each data stream from a previously commenced data stream carrying the same information;
allocating the buffer starting from a data stream with the smallest buffer requirement and proceeding to data streams with larger buffer requirements until the buffer requirements of one of the data streams can not be satisfied;
retaining blocks of a previously commenced data streams in the buffer allocated to a corresponding subsequently commenced data stream carrying the same information; and, servicing a data consumer from the subsequently commenced data streams using data blocks provided by way of the buffer.
11. The system of claim 8 further comprising:
means for determining when one of the clients has paused;
means for allocating a portion of the buffer to retain blocks of the video streams on behalf of the one of the clients who has paused; and, means for determining when a resume request is received from the one of the clients, and for serving the one of the clients from the buffer in response thereto.
means for determining when one of the clients has paused;
means for allocating a portion of the buffer to retain blocks of the video streams on behalf of the one of the clients who has paused; and, means for determining when a resume request is received from the one of the clients, and for serving the one of the clients from the buffer in response thereto.
12. The system of claim 8 further comprising:
means for determining when one of the clients has paused;
a local memory buffer disposed at a site of the one of the clients;
means for causing the memory buffer to retain blocks of the video streams on behalf of the one of the clients who has paused; and, means for determining when a resume request is received from the one of the clients, and for serving the one of the clients from the buffer in response thereto.
means for determining when one of the clients has paused;
a local memory buffer disposed at a site of the one of the clients;
means for causing the memory buffer to retain blocks of the video streams on behalf of the one of the clients who has paused; and, means for determining when a resume request is received from the one of the clients, and for serving the one of the clients from the buffer in response thereto.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US204,038 | 1994-03-01 | ||
| US08/204,038 US5572645A (en) | 1994-03-01 | 1994-03-01 | Buffer management policy for an on-demand video server |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2142380A1 CA2142380A1 (en) | 1995-09-02 |
| CA2142380C true CA2142380C (en) | 2001-04-24 |
Family
ID=22756361
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002142380A Expired - Fee Related CA2142380C (en) | 1994-03-01 | 1995-02-13 | Buffer management policy for an on-demand video server |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US5572645A (en) |
| EP (1) | EP0670542B1 (en) |
| JP (1) | JP2642072B2 (en) |
| KR (1) | KR0146567B1 (en) |
| CA (1) | CA2142380C (en) |
| DE (1) | DE69516441T2 (en) |
Families Citing this family (37)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2130395C (en) * | 1993-12-09 | 1999-01-19 | David G. Greenwood | Multimedia distribution over wide area networks |
| US5544327A (en) * | 1994-03-01 | 1996-08-06 | International Business Machines Corporation | Load balancing in video-on-demand servers by allocating buffer to streams with successively larger buffer requirements until the buffer requirements of a stream can not be satisfied |
| US5754773A (en) * | 1994-06-16 | 1998-05-19 | Lucent Technologies, Inc. | Multimedia on-demand server having different transfer rates |
| US5978843A (en) * | 1995-12-06 | 1999-11-02 | Industrial Technology Research Institute | Scalable architecture for media-on-demand servers |
| US5931903A (en) * | 1995-12-20 | 1999-08-03 | Tandem Computers Incorporated | Computer system data I/O by reference among multiple CPUS |
| US5790807A (en) * | 1995-12-20 | 1998-08-04 | Tandem Computers Incorporated | Computer sysem data I/O by reference among CPUS and I/O devices |
| US5941959A (en) * | 1995-12-20 | 1999-08-24 | Tandem Computers Incorporated | System for transferring a data stream to a requestor without copying data segments to each one of multiple data source/sinks during data stream building |
| US5954794A (en) * | 1995-12-20 | 1999-09-21 | Tandem Computers Incorporated | Computer system data I/O by reference among I/O devices and multiple memory units |
| US5852719A (en) * | 1995-12-20 | 1998-12-22 | Tandem Computers Incorporated | System for transferring data over a network in which a data source sends only a descriptor which a data sink uses to retrieve data |
| US5907717A (en) * | 1996-02-23 | 1999-05-25 | Lsi Logic Corporation | Cross-connected memory system for allocating pool buffers in each frame buffer and providing addresses thereof |
| US5870551A (en) * | 1996-04-08 | 1999-02-09 | Lucent Technologies Inc. | Lookahead buffer replacement method using ratio of clients access order offsets and buffer data block offsets |
| JP3972381B2 (en) * | 1996-04-12 | 2007-09-05 | ソニー株式会社 | Information transfer apparatus and information transfer method |
| GB2313529B (en) * | 1996-05-23 | 2000-11-15 | Sony Uk Ltd | Video data system |
| US5916303A (en) * | 1997-05-21 | 1999-06-29 | International Business Machines Corporation | Optimal movie distribution on video servers in an n-level interactive TV system |
| US6502137B1 (en) | 1997-10-09 | 2002-12-31 | International Business Machines Corporation | System and method for transferring information over a computer network |
| US6016507A (en) * | 1997-11-21 | 2000-01-18 | International Business Machines Corporation | Method and apparatus for deleting a portion of a video or audio file from data storage prior to completion of broadcast or presentation |
| US6938268B1 (en) * | 1998-01-08 | 2005-08-30 | Winston W. Hodge | Video stream sharing |
| US6889257B1 (en) * | 1999-12-03 | 2005-05-03 | Realnetworks, Inc. | System and method of transmitting data packets |
| US6725272B1 (en) * | 2000-02-18 | 2004-04-20 | Netscaler, Inc. | Apparatus, method and computer program product for guaranteed content delivery incorporating putting a client on-hold based on response time |
| US6854018B1 (en) * | 2000-03-20 | 2005-02-08 | Nec Corporation | System and method for intelligent web content fetch and delivery of any whole and partial undelivered objects in ascending order of object size |
| KR20010093875A (en) * | 2000-04-01 | 2001-10-31 | 이승룡 | An integrated push/pull buffer management method at client-side in multimedia streaming environments |
| US6678794B1 (en) * | 2000-06-14 | 2004-01-13 | International Business Machines Corporation | Smoothing bursts of disk load in a file system |
| EP1936982A3 (en) * | 2001-02-21 | 2010-12-15 | United Video Properties, Inc. | Systems and method for interactive program guides with personal video recording features |
| US7051112B2 (en) * | 2001-10-02 | 2006-05-23 | Tropic Networks Inc. | System and method for distribution of software |
| KR20030032414A (en) * | 2001-10-18 | 2003-04-26 | 주식회사 엠씨글로벌 | Buffering method of multimedia data |
| FI116167B (en) * | 2001-12-18 | 2005-09-30 | Valtion Teknillinen | Archive file server |
| US7155373B2 (en) * | 2002-02-22 | 2006-12-26 | 3M Innovative Properties Company | Selection of orthodontic brackets |
| US8468570B2 (en) * | 2002-09-05 | 2013-06-18 | Thomson Licensing | Method and system for memory PVR functions in a broadcast environment |
| KR100490410B1 (en) * | 2002-09-12 | 2005-05-17 | 삼성전자주식회사 | Apparatus and method for buffering a multi-media document based on data structure |
| EP1644803A4 (en) * | 2003-07-02 | 2011-11-09 | Rovi Solutions Corp | A networked personal video recording system |
| US8244939B2 (en) * | 2010-06-11 | 2012-08-14 | Dot Hill Systems Corporation | Method and apparatus for dynamically allocating queue depth by initiator |
| US8874845B2 (en) | 2012-04-10 | 2014-10-28 | Cisco Technology, Inc. | Cache storage optimization in a cache network |
| US9286328B2 (en) * | 2013-07-19 | 2016-03-15 | International Business Machines Corporation | Producing an image copy of a database object based on information within database buffer pools |
| CN103618911B (en) * | 2013-10-12 | 2017-02-01 | 北京视博云科技有限公司 | Video streaming providing method and device based on video attribute information |
| US20150271072A1 (en) * | 2014-03-24 | 2015-09-24 | Cisco Technology, Inc. | Method and apparatus for rate controlled content streaming from cache |
| PT3419245T (en) * | 2014-03-26 | 2021-11-04 | Tivo Solutions Inc | Multimedia pipeline architecture |
| KR102387935B1 (en) | 2017-10-23 | 2022-04-15 | 삼성전자주식회사 | A data storage device including nonexclusive and exclusive memory region |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5150472A (en) * | 1989-10-20 | 1992-09-22 | International Business Machines Corp. | Cache management method and apparatus for shared, sequentially-accessed, data |
| US5341474A (en) * | 1992-05-15 | 1994-08-23 | Bell Communications Research, Inc. | Communications architecture and buffer for distributing information services |
| US5442390A (en) * | 1993-07-07 | 1995-08-15 | Digital Equipment Corporation | Video on demand with memory accessing and or like functions |
| EP0653884A1 (en) * | 1993-11-17 | 1995-05-17 | BELL TELEPHONE MANUFACTURING COMPANY Naamloze Vennootschap | Interactive video on demand network |
-
1994
- 1994-03-01 US US08/204,038 patent/US5572645A/en not_active Expired - Lifetime
- 1994-12-16 JP JP6313473A patent/JP2642072B2/en not_active Expired - Lifetime
-
1995
- 1995-02-01 EP EP95101351A patent/EP0670542B1/en not_active Expired - Lifetime
- 1995-02-01 DE DE69516441T patent/DE69516441T2/en not_active Expired - Lifetime
- 1995-02-13 CA CA002142380A patent/CA2142380C/en not_active Expired - Fee Related
- 1995-02-27 KR KR1019950003882A patent/KR0146567B1/en not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| KR950027576A (en) | 1995-10-18 |
| JP2642072B2 (en) | 1997-08-20 |
| EP0670542B1 (en) | 2000-04-26 |
| DE69516441T2 (en) | 2000-10-19 |
| CA2142380A1 (en) | 1995-09-02 |
| EP0670542A1 (en) | 1995-09-06 |
| DE69516441D1 (en) | 2000-05-31 |
| US5572645A (en) | 1996-11-05 |
| JPH07248972A (en) | 1995-09-26 |
| KR0146567B1 (en) | 1998-09-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2142380C (en) | Buffer management policy for an on-demand video server | |
| EP0673159B1 (en) | Scheduling policies with grouping for providing VCR control functions in a video server | |
| EP0759676B1 (en) | Scheduling videos in a video-on-demand system and video-on-demand system for applying the same | |
| US5809239A (en) | Load balancing in servers by allocating buffer to streams with successively larger buffer requirements until the buffer requirements of a stream can not be satisfied | |
| US5815662A (en) | Predictive memory caching for media-on-demand systems | |
| EP0673160B1 (en) | Look-ahead scheduling to support video-on-demand applications | |
| US6714986B2 (en) | File system for handling real-time and non-real-time data | |
| US6240243B1 (en) | Method and apparatus for storing and retrieving scalable video data in a disk-array-based video server | |
| US5561637A (en) | Pace control for multicasting in a video server environment | |
| Feng et al. | Critical bandwidth allocation for the delivery of compressed video | |
| JP3338451B2 (en) | Staggered stream support for video on demand | |
| US5787472A (en) | Disk caching system for selectively providing interval caching or segment caching of vided data | |
| EP0660605B1 (en) | Video storage and delivery apparatus and method | |
| Ghose et al. | Scheduling video streams in video-on-demand systems: A survey | |
| US5926481A (en) | Timer Interrupt method for achieving quality-of-service criteria in a media-on-demand server system | |
| KR20030025386A (en) | Method for pause/resume a video playback in a video system | |
| Makaroff et al. | Design and implementation of a VBR continuous media file server | |
| Rautenberg et al. | A control system for an interactive Video on Demand server handling variable data rates | |
| Paul et al. | Real-time scheduling for synchronized presentation of multimedia information in distributed multimedia systems | |
| Kang et al. | Aggregated smoothing of VBR video streams | |
| Aggarwal et al. | Optimization issues in multimedia systems | |
| Basu et al. | Server-Based Service Aggregation Schemes for Interactive Video-on-Demand | |
| Park et al. | A caching policy for continuous media objects based on logical caches and object partitioning | |
| Harizopoulos et al. | PASTENSE: a Fast Start-up Algorithm for Scalable Video Libraries | |
| Harizopoulos et al. | PASTENSE: a Fast Start-up Algorithm for Scalable Video Libraries (CMU-CS-01-105) |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKLA | Lapsed | ||
| MKLA | Lapsed |
Effective date: 20060213 |