JPH1093924A - System and method for distributing digital data on demand - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an inexpensive system which can be adjusted to various conditions and which can be extended in accordance with the increase of demands by processing a command from a client, scheduling the reproduction of a video stream, managing a video file structure and controlling the flow of video data to distribution modules by respective central control modules. SOLUTION: A video server 105 is provided with the central control modules 110, the distribution modules 120 and a storage module 130. The respective central control modules 110 receive and process a video control command from the client 101. The central control modules 110 execute a multi-task processing by using a program code stored in DRAM 232 connected to CPU 112. The program code contains a multi-processing thread executed by CPU 112 and the multi-processing thread reproduces the multiple video streams by the demand by the client 101 and execute the various control commands.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

FIELD OF THE INVENTION The present invention relates generally to real-time server systems and processes, and more particularly, to systems and processes for distributing video streams to client locations.

[0002]

2. Description of the Related Art With the improvement of data storage, retrieval and compression techniques, the use of real-time server systems, in particular the use of video-on-demand systems, has become widespread. Video-on-demand applications include hospitality facilities (ie, hotels, motels, condominiums, and hospitals), karaoke (which generally involves the playback of audio recordings, and some that involve the playback of image information), and content in information centers. (Ie, content) distribution. Video-on-demand systems store selected video files (generally each video file corresponds to a movie, brief information display, or other type of video content), and the selected video file under user control. Is read out (that is, reproduced). Thus, when using a video-on-demand system, one or more users select and access (ie, play) a video file via a client network. In addition, conventional video-on-demand systems generally provide the user with various control functions such as play, stop, pause, rewind, and fast-forward, such as those found in conventional video cassette recorders (VCRs). Here, it will be understood that the term "video" includes content having audio and image portions, or audio-only content, or image-only content, or other types of digital content.

[0003]

The channel requirements for a video on demand system (ie, the number of video streams distributed by a server) are different for each particular video on demand system. For example, large hotels require more channels than small hotels, and information centers may serve more or fewer clients based on the location of the information center and the type of information provided. In addition, video-on-demand systems may be installed wherever large channel capacity is required. For example, systems installed in hospitality facilities (ie, hotels, motels, condominiums, and hospitals) initially serve a small number of rooms or devices, but as the size of the facilities increases, or As consumers become aware of the service, the demand for the system will increase. This problem is likely to be even more acute in applications such as information centers where the physical infrastructure required to provide additional client locations cannot be avoided.

[0004] In addition, the video storage requirements of video-on-demand systems will vary with the particular application.
For example, a hospitality facility would like to offer a large selection of feature-length video movies, and thus would have a fairly large storage requirement. Information centers, on the other hand, tend to have much smaller storage requirements, especially when the information content is small compared to feature films.

[0005] Many conventional video-on-demand systems have a high cost architecture. In particular, some conventional video-on-demand systems use high-end workstations or especially high-speed computers to perform real-time distribution of multiple video streams. Other conventional video-on-demand systems use computers with multiple processors for multi-task processing of events to meet the processing requirements for distributing multiple video streams. Conventional video-on-demand systems are generally very expensive due to the use of high-end and / or specialized hardware. Such conventional video-on-demand systems have the further disadvantage that they are generally designed to accommodate a specified maximum number of video streams, and therefore cannot be easily expanded beyond their capacity.

[0006] To provide a single, low-cost video-on-demand system that can be tailored to the different requirements of various video-on-demand applications, and that can scale as the demands of individual server locations grow. Is desirable.

[0007] Accordingly, there is a need for an adjustable, scalable, and cost-effective method and process for distributing multiple video streams and other digital data streams in parallel.

In addition, an important part of a computer system in general, and in particular of a video-on-demand system, is its mass storage part. As for the video server (video on demand), the mass storage part stores the video content. For other types of computer systems, the mass storage portion stores other types of digital content, such as computer programs, databases, images, data, and the like. Whether the particular application is in a video-on-demand system or another type of computer system, the size, speed, and cost of mass storage devices affect system specifications, performance, and cost. Will be exerted.

Some conventional mass storage architectures use a redundant disk drive array (RAID) of inexpensive disk drives. Traditionally, such architectures typically use a drive array of smaller, cheaper, and more reliable drives than previously available high performance, large, and expensive disk drives. Some of these conventional RAID systems use striping, in which data objects are divided into "multiple data stripes" which are then stripped of performance by parallel disk operations. Interleaved on the disk array to achieve improvement. Also, each data stripe may be further subdivided into data blocks of a size sufficient to facilitate disk access. In general, conventional disk arrays will incorporate redundancy in the form of a mirror or a parity-based mechanism to increase reliability.

Specifically, conventional RAID level 1 uses mirror processing, and other higher level conventional R
The AID system uses a parity block for error correction. Conventionally, this parity block is generated by exclusive-ORing the data blocks across one stripe slice (ie, across the disk array). Conventionally, each parity block is stored on a different disk than its associated data stripe. Therefore, when a disk failure occurs, the data blocks stored in the failed disk use the parity blocks (parity blocks corresponding to all other data blocks in the data stripe slice). By performing an exclusive OR operation of

Therefore, a RAID with N disks
In the system, if a disk fails, (N-1) is used to reconstruct one lost data block.
It is necessary to read (N-1) data blocks from the disks. Read operations on (N-1) disks are performed in parallel to reduce the response time if the load performance of the subsystem permits, but when such a failure occurs, a considerable load is still applied to the load performance. Will be imposed. As the number of disks (N) in the system increases, the performance penalty in failure mode increases. Therefore, it is desirable to limit the number of disks (N) to a relatively small value in order to limit the performance disadvantage.

On the other hand, in order to obtain a high throughput of the RAID system, a large number (N
It is desirable to have a number of disks so that multiple disk operations can be performed in parallel. This aspect is inconsistent with the desire for a small number of N in failure mode.
Accordingly, there is a need for a RAID system and method that improves system reliability and performance without significant unacceptable performance penalties in failure modes.

[0013]

SUMMARY OF THE INVENTION In accordance with the present invention, there is provided an adjustable and scalable video server system for distributing multiple video streams in real time using conventional low cost components. The system comprises one or more central control modules (CCM), one or more distribution modules (DM), and one or more storage modules (SM). . Each central control module is a conventional computer with two conventional small computer serial interface (SCSI) controller cards, each of its SCS
The I-controller card operates in an "initiator" mode to interface with one or more distribution modules and storage modules. Each central control module also comprises a local memory, which is used as an intermediate buffer memory for storing data retrieved from the storage module prior to distribution to the distribution module. Each central control module also has one user (client) or one
It has a communication interface for coupling with two client networks. Each central control module processes commands received from clients, schedules the playback of multiple video streams, manages video file structures, and controls the flow of video data to one or more distribution modules. Ensure real-time playback.

Also, each distribution module is a conventional computer with a conventional SCSI controller card operating in "target" mode. In addition to having a SCSI controller card, each distribution module has one or more processing modules that process the video stream prior to distribution to the client. In one embodiment, the processing modules are video decoders, each of which is for decompression of a video data stream. In this embodiment, the video decoder is a conventional MPEG-1 or MPEG-2 decoder.

In another embodiment, the processing module is a conventional network interface card, which formats the video data stream and sends the video data stream to the client via an Ethernet, ATM, or PSTN network or the like. Supply of Further, each distribution module includes a local memory used as a video buffer for storing video data prior to processing on the distribution module.

Each of the storage modules is a large-capacity storage medium, and the large-capacity storage medium is configured to store digital information such as video data.
Accessed by the central control module using the CSI protocol. Each storage module is, for example, a hard disk, or a CD-ROM drive, or a bank of hard disks, or a bank of CD-ROMs, or another type of mass storage medium.

Further, in accordance with the present invention, the central control module uses a hybrid file management scheme to achieve improved data access performance and improved memory utilization. The hybrid file management scheme is a customized operating system that runs on a central control module and bypasses a traditional file manager for direct control and access of raw video data stored in storage. File management software. This hybrid scheme optimizes the access time for video data that utilizes operating system file management services to manage raw video data as well as control information about the video storage map.

According to another aspect of the invention, the central control module implements a prioritization method to include in each storage module between the plurality of video data streams generated by the server system. Prioritize the access of the storage device to be accessed. Each time multiple read requests are generated by multiple video data streams, the priority method determines for each read request whether the read request (read message) is urgent or non-urgent. The request is urgent if the requested data cannot be serviced within a predetermined amount of time, causing a problem with the playback of the video data stream.
Also, if no problem occurs in the same case, the request is non-urgent. Preferably, whether the message is urgent or non-urgent is determined by the current state of the video data stream. For example, if the video data stream is currently paused and the request is to resume its playback, the request is non-urgent. However, the request when the video data stream is in the playing state is urgent. The priority method then calculates the final deadline for each urgent message. The priority method then determines if there is enough time to service any non-urgent requests without any urgent messages losing their final deadline. If the condition is met, the system handles the non-urgent request, and if the condition is not met, the urgent request is processed next.

According to another aspect of the invention, a server system and method uses a disk load balancing method to schedule the start of playback of a particular video data stream. The disk load balancing method defines a plurality of time zones. Here, preferably, the number of time periods corresponds to the number of storage devices. The disk load balancing method distributes the processing of the video data streams by allocating each video data stream one at a time. The disk load balancing method determines such an allocation by first identifying the storage device that will provide the video data stream, and then identifying the next “available” time period that will be serviced by that storage device. Is determined. The time period is considered "available" if it has the capacity (bandwidth) to handle additional video data streams. The disk load balancing method then assigns the "available" time period to the newly started video data stream.

In accordance with yet another aspect of the present invention, a server system and method for storing video objects using a redundant disk array (RAID) system and method of separate disks. The RAID system and method divides a video object into a plurality of data blocks and divides the data blocks using a striping process (in a striped configuration) across a plurality of storage devices (ie, N storage devices). (Across the device). According to the system and method, a redundancy factor (M) is selected. The redundancy factor M determines reliability and service time in failure mode during system operation. M is selected to be an integer less than N. According to this aspect of the invention, each time M data blocks are stored, an error recovery block is calculated. Preferably, the error recovery block is a parity code generated by performing an exclusive OR operation on the M data blocks. If N is greater than M, then in the event of a disk failure, the error recovery process is advantageously limited by the redundancy factor M to the number of storage access calls required. In one embodiment, the error recovery blocks are stored interleaved with the data blocks, but the associated data is stored on a different storage device. Such features of the present invention include:
It will be appreciated that the present invention is applicable to systems and methods for storing digital data other than video data, and is also applicable to storage systems other than server systems.

According to yet another aspect of the invention, the central control module, distribution module, and storage module include:
In order to improve the flexibility and expandability of the system, the present invention is also applicable to rack mounting in a rack mounted system.

The features and advantages described herein are not all-inclusive, and those skilled in the art will be able to refer to the drawings, detailed description, and claims which follow.
Many more features and advantages will be apparent. Furthermore, the terms used in the specification are basically selected for the sake of readability and exemplification of the present invention, and are not selected for limiting the gist of the present invention. It should be noted that the gist of the present invention should be determined based on the claims.

[0023]

FIG. 1 is a block diagram illustrating a video on demand (VOD) system 100 according to the present invention. The VOD system 100 includes a control input source 150 and a video server 105. The video server 105 includes one or more central control modules 110, one or more distribution modules 120, and one or more storage modules 130. Because the VOD system 100 is adjustable and scalable, the central control module 110, distribution module 120,
And the number of storage modules 130 depends on factors such as the number of streams to be distributed and the video storage requirements for the particular application. In one preferred embodiment, the video server 105
Has one central control module 110, one distribution module 120, and one storage module 130. Further, to facilitate adjustability and system scalability, video server 105 is preferably a rack mount system. In this case, each sub-component (central control module 110, distribution module 120, and storage module 130) is adapted for rack mounting.

Control input source 150 is any input source that generates control signals for controlling the retrieval and display of stored video information (video data).
A typical control input source 150 would include a keyboard, a remote control, a mouse, a complete computer system, or a network of client computers coupled to the video server 105. In the preferred embodiment,
The control input source 150 is a network of video clients 101 coupled to the video server 105. Each video client 101 is a computer that generates a video control signal. Accordingly, the video client 101 generates a video request signal and a control signal connected to the video server 105, thereby selecting one of the videos provided by the VOD system 100 and controlling the reproduction thereof. Used to do. Video client 101 is connected to video server 105, preferably using an Ethernet network. However, it will be appreciated that other means of connecting the video client 101 to the video server 105 may be used in accordance with the present invention. For example, video client 101 can connect to video server 105 using a local area network, a wireless communication link, an optical link, or other communication means.

Referring again to FIG. The storage module 130 includes one or more storage devices 131. Each of the storage devices 131 is preferably a mass storage device such as a conventional hard disk drive, CD-ROM drive, or tape drive. In the preferred embodiment, storage device 131 is a high capacity (4-9 GByte) disk drive manufactured by Seagate, Inc. The storage module 130 stores a plurality of video objects (video sequences). In one embodiment, each of the video objects is a feature-length video movie. In another embodiment, the video object is another form of video content. Here, it will be understood that the term "video" includes content having audio and image portions, or audio-only content, or image-only content, or other types of digital content. Thus, the term "video" also includes digital music recordings, audio recordings, unvoiced image segments, and the like.

The preferred embodiment of the present invention stores each video object in accordance with the RAID technique of the present invention using "striping", which will be described later.

Using striping, each video object is divided into a plurality of "video stripes", each of which is stored in a different storage device 131. In addition, each video stripe is a "data block"
Multiple 128-kbyte data chunks (chunk:
Into a lump.

The central control module 110 includes a heavy multi-threaded operating system (preferably a Sun Micr
osystems operating system (SOLARIS) CP
U112 (preferably PE manufactured by Intel Corporation)
It is a high-performance personal computer motherboard that runs on the NTIUM processor. The motherboard is AS
MiT, manufactured by USTek Computer Inc.
Mounted on a rack-mounted chassis manufactured by AC Industrial Corporation. The motherboard also includes a peripheral control interface (PCI) bus for connection to peripheral devices such as SCSI controllers and Ethernet controllers.

Each central control module 110 includes initiators 111 and 113 to facilitate communication between the central control module 110 and the storage module 130 and between the central control module 110 and the distribution module 120. Initiators 111 and 113 are licensed from Adaptec, Inc. (Milpitas, California
rnia) and is connected to the CPU 112 using a PCI bus. The memory buffer 114 is a memory space allocated in a dynamic random access memory (DRAM 232 (see FIG. 2)) directly connected to the CPU 112. Preferably, the memory buffers 114 are each 128 kbytes of memory, so each memory buffer 114 is sized to store an entire data block.

Also, the distribution module 120 is preferably a Tya
n High performance personal computer motherboard manufactured by Computer Corporation. The motherboard is mounted on a rack mount chassis manufactured by MiTAC Industrial Corporation. The motherboard further includes a conventional peripheral control interface (PCI) bus. Each distribution module 120 includes a target 124, a CPU 125, a plurality of video processors 121, and a memory buffer 126. C
PU 125 is preferably a PENTIUM processor manufactured by Intel Corporation. Target 124 is Adva
A conventional "target mode capable" SCSI controller card, such as the model ABP-940 SCSI controller manufactured by nsys, Inc. (San Jose, California), which is connected to the CPU 125 using a PCI bus. Here, "target mode is possible" means that it can be adapted to operate in the target mode in order to receive data from the SCSI controller operating in the initiator mode. By using a conventional SCSI controller card to interface between the central control module 110 and the distribution module 120, when the central control module 110 is writing to a conventional disk drive, Allows 110 to write data to distribution module 120, which reduces system cost and complexity and increases system reliability.

Video processor 121 receives video data (forming a video stream) from memory buffer 126 under the control of CPU 125, and then
Process each video stream for distribution to 101.
In one preferred embodiment, the video processor 121 is a Zoran Cor
conventional MPEG-1 decoder and Matrox Electronic Syst manufactured by Poration (Santa Clara, California).
Conventional MPEG-2 manufactured by ems, LTD (Canada)
It is a conventional motion picture expert group (MPEG) decoder such as a decoder. The choice of an MPEG-1 or MPEG-2 decoder is determined by the compression technique used to compress the video data stored in the storage module 130.

One preferred embodiment of the present invention is a distribution module.
120 has 12 video processors 121. Preferably, each video processor 121 operates on one video stream each. Further, in the preferred embodiment, the output of each video processor 121 is compatible with both NTSC and PAL standards (client
101) NTSC / for direct connection to video monitor
This is a PAL composite signal.

In another embodiment, video processor 121 does not perform MPEG decompression, but instead performs other types of decompression. In yet another embodiment, the video processor 121
Performs video stream processing to interface with a network such as an Ethernet, ATM, or PSTN network, or to interface with another client distribution means. In these embodiments, if necessary, video decompression is performed on the distribution module 120 at the client's location or at another point along the video stream path.

The central control module 110 is provided with the SCSI bus 1
41 connects to the storage module 130. Similarly, the central control module 110 is connected to each distribution module 120 by a SCSI bus 142. The SCSI communication includes initiators 111 and 113 disposed in the central control module 110,
And a corresponding SCSI controller (partition module that forms part of the storage module 130 and the distribution module 120).
120 is the target 124, storage module 130 is the SCS
I circuit (not shown). The SCSI controllers on storage module 130 and distribution module 120 operate in a "target" mode. The SCSI interface of the distribution module 120 is a cost-effective interface mechanism whereby each central control module 110 writes data to the distribution module 120 as if it were writing data to a hard disk drive or other conventional SCSI compatible device. Data can be distributed to

While the preferred embodiment uses a single initiator 113 to communicate with the storage modules 130, alternative embodiments may use a larger number of storage modules 130 in the VOD system 100. Multiple initiators 113 to meet the interface requirements of
Can be used. Similarly, in the preferred embodiment, a single initiator 111 was used to communicate with the distribution module 120, but in another embodiment, the VOD
Multiple initiators 111 can be used to meet the interface requirements when more distribution modules 120 are used in system 100.

Although the preferred embodiment uses a single central control module 110, the principles of the present invention can be applied to a VOD system 100 having multiple central control modules 110. By arranging a large number of central control modules 110 in the video server 105, the VOD system 100 can be configured to perform a redundant operation,
This improves system reliability and fault tolerance. In addition, configurations with multiple central control modules 110 increase the bandwidth of the system, thereby increasing the maximum number of video streams generated by VOD system 100.

One preferred system configuration would include a single central control module 110 serving nine distribution modules 120, where each distribution module 120 has twelve video processors 121. have.
Thus, this preferred arrangement will produce up to 108 video streams simultaneously. Another configuration uses eight video processors 121 instead of twelve, thus distributing up to 96 video streams.

Each central control module 110 has one or two
It receives and processes video control commands from one or more clients 101. The video control commands include, for example, playback, storage, pause, fast forward, rewind, video selection, and the like. More specifically, CPU 112 on central control module 110 decodes the received video control commands and controls storage module 130 and distribution module 120 to execute the decoded commands. The central control module 110 has a memory buffer 1
It performs functions such as management and scheduling of asynchronous transmission of video data to and from 14.

Conventionally, video server systems (ie, video on demand systems) fall into one of two categories: streaming systems and non-streaming systems. The streaming system distributes an apparently continuous video stream in response to a playback request, either until another user command is received to change the playback (i.e., pause, stop, etc.), or to update the file. It is done until the end is reached. Also, in a non-streaming system, the video server
It does not distribute the ongoing video stream, but instead distributes video chunks or video segments as required by the client. Preferably, the request from the client 101 should occur frequently enough and generate fast enough to produce a clearly continuous "real-time" video stream for the user. The preferred embodiment of the VOD system is a streaming type video server. The streaming type video server is compared with the non-streaming type video server by the client 101 and the video server 1.
It has the advantage of requiring less dialogue with 05. Thus, streaming-type video servers are less prone to errors, can accommodate multiple channels, and require less complexity at client 101.

The VOD system 100 uses a number of buffer mechanisms to distribute a real-time video stream. Under the control of the CPU 112, the data is stored in the storage module 130.
To the memory buffer 114 (preferably in 128 kbyte chunks). This data is then followed by the CPU
Smaller chunks under control of 112 (preferably 32 kbytes)
Is transmitted to the memory buffer 126 of the distribution module 120. Here, under the control of the CPU 125, each video processor 121 has smaller chunks of data (preferably 32 kbytes).
Transmitted to Each video processor 121 processes a 32 kbyte data chunk to generate a video stream for distribution to client locations.

Preferably, the data transmission between the storage module 130 and the central control module 110 and between the central control module 110 and the distribution module 120 is for obtaining a high-speed memory transmission and during the transmission. It is performed using a direct memory access (DMA) transmission mode to avoid operation using the CPU.

Preferably, the distribution module 120 interfaces with the central control module 110 in a target mode (using a SCSI interface in the target mode) so that the video data and the associated control commands are addressed using an addressing scheme. Distribution module
Sent to 120. Each video stream is assigned to a specified address range on the distribution module 120.
Thus, if the central control module 110 is writing video data for a particular video stream, the destination address on the distribution module 120 is used to uniquely specify the particular data stream. Similarly, control information such as progress, end of encoding, and pausing for each video stream is written to a particular pre-specified address, each mapped to a particular video stream. The address mapping of each video stream and its associated control information is predefined. Alternatively, an address map that maps the data of each video stream to control information for each video stream is received from the distribution module 120 during system startup and then stored in the central control module 110.

FIG. 2 shows a central control module according to the invention.
It is a block diagram which shows 110. In order to service control commands received from the plurality of clients 101, the central control module 110
Multitask processing is performed using the program code 231 stored in M232. DRAM 232 also forms memory buffer 114 (also shown in FIG. 1). D
The RAM 232 is a DRAM attached to a memory expansion slot provided on a conventional computer motherboard included in the central control module 110. The program code 231 includes multi-processing threads 210 to 205 executed by the CPU 112. The multi-processing threads 210 to 205 include a remote procedure call (RPC) thread 202, a callback thread 203,
A stream thread 204, a storage thread 201, and a file thread 205 are provided. Each thread has a CPU 112
Is an active path through a computer program executed by the computer.

In FIG. 2, the central control module 110 also has a system hard disk 235 specific to the central control module 110. The system hard disk 235 stores a program code 231 to be loaded into the DRAM 232. The system hard disk 235 is
Further, it stores a server configuration file 237 and a video catalog subdirectory 236.

FIG. 3 shows a multi-processing thread 201.
It is a state diagram which shows the relationship between. The multi-processing threads 201-205 play (on the client 101) to play multiple video streams and execute various control commands (i.e., pause, stop, rewind, etc.) as requested by the client 101. And executes the function call generated by the client program 206).

The remote procedure call (RPC) thread 202 provides an application program interface (API) to the client program 206, and thus operates to receive control inputs (function calls) received from the client program 206. Central control module 110 creates (executes) a single RPC thread 202 to manage the interface between video server 105 and client 101.

The central control module 110 generates (on the CPU 112) and executes a stream thread 204 for each output video stream. Each stream thread 204 has 1
Manage the playback of two video streams.

The callback thread 203 is executed by the CPU 112 and operates on a message generated by the stream thread 204. The message is generated as a result of an "end of file" or error condition.

The file thread 205 is executed by the CPU 112 and operates file management including creation, deletion, writing, and reading of a video object. The central control module 110 has a number of file threads 205.

Each storage device 131 is managed by one or more storage threads 201. Memory thread 201
Receives message requests from the stream thread 204, the file thread 205, and the RPC thread 202,
The message request is then serviced by performing the appropriate disk access and data retrieval functions. A storage thread 201 that manages a given storage device 131
Is specified in the server configuration file 237. Preferably, two storage threads 201 manage each storage device 131.

Here, FIG. 2 is referred to again. Each storage device
131 has one associated message queue 233 each. The message queue 233 is a first-in first-out (FIFO) message pipe (queue) for storing a disk input / output request message. When it is necessary to read video data from a specific storage device 131, the stream thread 204 sends a (disk access) (disk access) message to a message queue 233 corresponding to the appropriate storage device 131. Send to Each message includes a deadline field calculated by the stream thread 204 that generated the message.

FIG. 4 is a flowchart showing a data structure and a program module 232 used when accessing the storage device. Program code 232 includes a set of linked list data structures 242. The linked list data structure 242 has a free list 240 and a request list 241. One free list 240 and one request list 241 are created for each storage device 131. Free list 240 is an unsorted linked list of free message storage elements, and request list 241 is a linked list of messages sorted according to the deadline field for each message. Each storage thread 201 processes messages by first extracting storage elements from the free list 240. Memory thread 20
1 then retrieves the message from message queue 233 and stores the retrieved message in a storage element. The storage thread 201 then passes the message to the request list 24 according to the deadline field for it.
Link in one.

FIG. 5 is an explanatory diagram showing the request list 241 according to the present invention. The request list 241 is the request list 241
Is a linked list of messages 244 configured to have a zero deadline message 244 at the front end. A non-zero deadline message 244 is stored after the zero deadline message 244, and this non-zero deadline message 244 is transmitted in an emergency,
Least urgent non-zero deadline message 24
4 will be shared at the end of the request list 241.

The request list 241 and the free list 240 both have a mutual exclusion lock 243, so that access to the request list 241 and the free list 240 is continuous. Mutual exclusion lock 243 is a conventional locking mechanism provided by the operating system.

Description of Processing Thread Referring again to FIG. Central control module 110
Is idle until the RPC thread 202 receives a StreamOpen () call from the client program 206. The StreamOpen () call is a request to open a new video stream for playback. Upon receiving the StreamOpen () call, the RPC thread 202 sends a StreamOpen message to the stream thread 204. Next, the stream thread 204 operates playback of the opened video stream.

In manipulating the StreamOpen message, the stream thread 204 stores the first three data blocks of the video object to be played back in the storage device 13.
Message queue 2 of 3 storage threads corresponding to 1
Send a ReadBlock message to each of the 33. In the preferred embodiment, three memory buffers 114 are reserved for each playback stream, so servicing the StreamOpen message will fill the memory buffer 114 associated with the newly opened playback stream.

Each storage thread 201 asynchronously retrieves a ReadBlock message from its message queue 233 and prioritizes the message for processing. When finally processed, the storage thread 201 reads the requested data block (the preferred block size is 128 bytes) from a particular disk and writes the data block to the allocated
Process the eadBlock message. After performing the service of the ReadBlock message, the storage thread 201 reads the ReadB message.
READ- to the stream thread 204 that issued the lock message
Send a RESP message.

The storage thread 201 then processes the next most time-critical (time-critical) message in its message queue 233. However, if the message queue 233 is empty, the storage thread 201 is idle until a message is sent to the message queue 233.

FIG. 6 shows the stream thread shown in FIG.
FIG. 204 is a state diagram of FIG. Stream thread 204
The state is the IDLE state 307 until the Open message is received.

After sending the ReadBlock message to the message queue, the stream thread 204 enters the PRIMING state.
Move to 301. When in the PRIMING state 301, the stream thread 204 waits until a READ-RESP message is received from each storage thread 201 to which the ReadBlock message has been sent. The READ-RESP message sent by the storage thread 201 indicates that the storage thread 201 has processed the ReadBlock request. When the READ-RESP message is received, the stream thread 204 transitions to the PRIMED state 302.

Here, FIG. 3 is referred to again. The RPC thread 202 executes StreamPlay () from the client program 206.
Receive calls asynchronously. Next, the RPC thread 20
2 sends a StreamPlay message to the stream thread 204. Next, the stream thread 204 operates the reproduction of the stream.

Here, FIG. 6 is referred to again. When the stream thread 204 is in the PRIMED state 302, the stream thread 204 waits until a StreamPlay message is received from the RPC thread 202. Stream thread 20
4 manipulates the StreamPlay message by selecting a start time slot for the stream, preferably according to the scheduling protocol described below. After the selection of the start time period, the reproduction is started by extracting the first sub-block (32 kbytes) of the video data from the memory buffer 114 and sending the sub-block to the distribution module 120 including the destination output port. After transmitting the sub-block, the stream thread 204 shifts to the PLAYWAIT state 303.

When in the PLAYWAIT state 303, the stream thread 204
It is determined whether a new message has arrived from any one of the methods 1 and the received message is processed. Messages that may be received include StreamPause messages, S
There are a treamJump message and a READ-RESP message. Each message is operated as follows.

(I) When the StreamPause message is sent from the RPC thread 202, the stream thread 204
Move to the USED state 304.

(Ii) When the StreamJump message is sent from the RPC thread 202, the stream thread 204 sends the memory buffer 1 not yet sent to the distribution module 120.
Discard the data block in 14. Next, the stream thread 204 stores the video data (data blocks) retrieved by the jump to the new location.
Memory buffers 114 that have not been allocated for use by storage thread 201 are allocated for use by storage thread 201. After processing the StreamJump message, the stream thread 204 loops in the PLAYWAIT state 303 to wait for the next message to be received.

(Iii) READ-RESP message is stored thread
If sent from 201, and if the READ-RESP message indicates that the ReadBlock message was operated without error, the stream thread 204 marks the corresponding memory buffer 114 as ready, and then Loop in PLAYWAIT state 303.

(Iv) READ-RESP message is stored thread
If sent from 201 and the READ-RESP message indicates that the ReadBlock message has encountered an error, the stream thread 204 sends an ErrorPlayDone message to the callback thread 203, and the ABEND state 305
Move to Next, the callback thread 203 returns the Err
Upon receiving the orPlayDone message, it makes a callback to the client program 206 that issued the video command to notify the client program 206 that an error has been encountered in the video stream.

In the PLAYWAIT state 303, the stream thread 204 is further controlled by a timer to maintain an isochronous video stream. "Isochronous" means non-bursting or "almost constant velocity". 32kbyt each to maintain isochronous video streams
distribution module 1
Sent to 20. As each data sub-block is sent to the distribution module 120, the stream thread 204 determines whether the data sub-block was the last sub-block in the memory buffer 114. If the data sub-block was the last sub-block, the stream thread 204 marks the memory buffer 114 as “available” and sends additional video data (128 kb) from the storage 131.
Send a ReadBlock message to the appropriate storage thread 201 to begin fetching the yte data block).
The stream thread 204 further determines whether the end of the video file has been reached. If the end of the video file is encountered, the stream thread 204 sends a NormalPlayDone message to the callback thread 203 and transitions to the DONE state 306. Next, the callback thread 203 sends a callback to the client program 206 that has issued the video command to notify the client program 206 that the video stream has been completed normally. However, if the end of the video file has not been reached, the stream thread 204 returns
Loop in LAYWAIT state 303.

When in the DONE state 306, the stream thread 204 processes messages received from the RPC thread 202. (StreamJ from client program 206
RPC thread 202 (as a result of receiving a ump () call)
Sends a StreamJump message from the storage thread 201 to retrieve the video data from the new jump destination position on the stored video file.
Send to After transmitting the address of the memory buffer 114, the stream thread 204 transitions to the PRIMING state 301. If a StreamClose message is sent by the RPC thread 202 (as a result of a StreamClose () call from the client program 206), the stream thread 204
Sends a command to notify the distribution module 120 associated with the stream that the playback of the stream has been closed. Next, the stream thread 204 transitions to the IDLE state 307.

When in the PAUSED state 304, the stream thread 204 processes the message sent by the RPC thread 202. If a StreamJump message is sent from RPC thread 202 (as a result of a StreamJump () call sent by client program 206), stream thread 204 discards any data in memory buffer 114 and returns To retrieve video data starting at the new jump destination position,
The storage thread 201 corresponding to the released memory space
Assign to The stream thread 204 then enters PRIMI
Move to the NG state 301.

(Strea from client program 206)
RPC thread 202 to S (as a result of mClose () call)
When the streamClose message is sent, the stream thread 204 notifies the distribution module 120 associated with the stream that the stream has been closed. Next, the stream thread 204 transitions to the IDLE state 307.

(Strea from client program 206)
St from RPC thread 202 (as a result of mPlay () call)
When the reamPlay message is sent, the stream thread 204 selects a start time slot for the video stream, and after reaching the start time slot, the stream thread 204 stores the current block of 32 kbytes on the video disk (on the central control module 110). From the memory buffer 114) to the distribution module 120 which contains the destination port for the video stream. The stream thread 204 then plays PLAYWA
Move to the IT state 303.

When in the ABEND state 305, the stream thread 204 processes a StreamClose message from the RPC thread. (Str from client program 206
When a StreamClose message is sent from the RPC thread 202 (as a result of an eamClose () call), the stream thread 204 informs the distribution module 120 associated with the stream that the playback of the stream has been closed. Stream thread 204 then goes to IDLE state 307
Move to

Message request by stream thread
The priority VOD system 100 uses a priority scheme to schedule operations on messages requesting disk I / O requests sent from multiple stream threads 204 to each storage thread 201. The priority scheme is preferably such that all requesting stream threads 20
4 will ensure that all messages are completed (operated) so that continuous playback of each video stream can be maintained.

According to the priority scheme, each message has a deadline field associated with it. The stream thread 204 is used by the central control module 110
A storage thread 201 stores a message (ReadBlock message) requesting disk I / O to fill the buffer of
, The stream thread 204 calculates the deadline for the message and sends the deadline along with the message to the storage thread 201. The deadline depends on the current state of the stream thread 204. The deadline is an integer from 0 to a maximum value. Messages without deadlines are given a deadline value of "zero", and messages with deadlines are assigned deadline values corresponding to their urgency, in which case messages with large deadline values The lower the urgency of a message, the higher the urgency of a message with a smaller deadline value.

During normal playback, that is, in the PLAYWAIT state 303, the deadline calculation is performed at the start time of the most recent data write to the distribution module 120 by the stream thread 204 at the start time of all memory buffers 114 for the stream. This is performed by adding the medium data consumption time (that is, the time required for reproducing the video data). Preferably, the data consumption time is determined by multiplying the size of each memory buffer 114 by the number of memory buffers 114 for the video stream, and then dividing the product by the output data rate (ie, buffer size × number of buffers ÷ Data rate).

The deadline is set to zero during initial priming of the buffer before playback of the stream begins (ie, when in the PRIMING state 301) and when in the PRIMED state 302. This "zero" indicates that the messages do not have an absolute deadline, and that if such services would cause other messages in the message queue 233 to not miss their deadlines. Indicates that it should be serviced.

When the stream thread 204 is in the PAUSED state 304 and the stream thread 204 receives a StreamJump () message, the stream thread 204
Is the memory buffer 1 for the stream thread 204
Discard the data in 14. Then stream thread 20
4 sends the address of the memory buffer 114 to the appropriate storage thread 201 to fill with data retrieved from a new (jump-to) location in the stored video object. The deadline for a StreamJump () message is that the message has no absolute deadline, and that such a service would prevent other messages in the message queue 233 from missing those deadlines. Is "zero" indicating that the message should be serviced.

When the stream thread 204 receives the StreamJump () message while the stream thread 204 is in the normal playback mode, that is, in the PLYWAIT state 303, the stream thread 204 Discard the data in the memory buffer 114 that has data that is related and has a deadline that is slower than the current time plus the response time of the storage thread 201. Then the stream thread 204
To fill with data retrieved from the new video location (ie, the jump destination location in the video file) and maintain the same deadline associated with the previously stored data, the data is The address of the discarded memory buffer 114 is sent to an appropriate storage thread 201.

Processing of Storage Thread The storage thread 201 is created when the central control module 110 is started up, and manages access to the storage device 131. Here, FIG. 4 is referred to again. Each storage device 131
Is controlled by a link list (request list 241 and free list 240) associated with each storage device 131. The number of storage threads 201 managing each storage device 131 is determined by reading the configuration file 237. When one or more storage threads 201 are created for each storage device 131, the request list 241
And a lock mechanism (m
utexlock243) is used.

FIG. 7 is a flowchart showing the message queue processing 400 performed by each storage thread 201. The storage thread 201 starts processing by determining whether there are two or more storage threads 201 related to the storage device 131. If there are two or more storage threads 201 related to the storage device 131, the current storage thread 201 sets the mutex lock 24 related to the storage device 131.
After obtaining 3, the link list 242 (request list 241 and free list 240) is locked (step 401).

When the mutex lock 243 is locked (and the link list 242 is locked), the storage thread 201 processes the message. The storage thread 201 then removes (unlinks) the message storage element from the free list 240. The storage thread 201 then stores the retrieved message in the unlinked message storage element (step 403) and inserts the message into the request list 241 according to its associated deadline (step 404). Specifically, if the message to be inserted (the new message) has a non-zero deadline, the storage thread 201 starts searching the request list 241 from its trailing end (ie, the trailing end). Has the least urgent non-zero deadline), inserts the new message into the request list 241 immediately after the first message with a deadline earlier than the new message. If no message in the request list 241 has a deadline earlier than the new message, the new message is
Inserted at the beginning of 241.

However, if the new message has a deadline of zero, the storage thread 201
Starts a search of request list 241 from its leading end (ie, the leading end has the most urgent deadline), and places a new message immediately before the first message with a non-zero deadline. Is inserted into the request list 241. If none of the messages in the request list 241 have a non-zero deadline, the new message is inserted at the end of the request list 241. After the new message is inserted into the request list 241, the storage thread 201 then releases the mutex lock 243 and unlocks the link list 242 (step 405). The storage thread 201 repeats the message queue processing 400 until the message queue 243 is empty. The storage thread 201 then proceeds to process the prioritized messages in the request list 241.

FIG. 8 is a flowchart showing a process 500 by the storage thread 201 of the messages with priorities in the request list 241.

If there are two or more storage threads 201 for the storage device 131, the current storage thread 201 obtains the mutex lock 243 associated with the storage device 131, and obtains the link list data structure 242 (free list 240). And request list 24
1) is locked (step 501).

After locking the data structure, the storage thread 201 has sufficient time to service the zero deadline messages in the request list 241 without losing those deadlines to non-zero deadline messages. It is determined whether there is an appropriate time. Memory thread 201
Computes the most recent start time for operations on non-zero deadline messages in request list 241
(Step 503) makes this determination. The most recent start time starts at the end of the request list 241 with the least urgent non-zero deadline, and for each message, the deadline of the previous message and the message associated with the current message. By calculating the most recent start time by subtracting the expected disk access (disk I / O) time from the smaller of the most recent start times calculated for
It is calculated repeatedly.

When calculating the most recent start time, the most recent start time is first initialized to the largest integer value representable by the most recent start time (step 50).
2). Further, the disk access time corresponds to the time required to read one data block (128 kbyte data) from the specific storage device 131 related to the request list 241.

Next, the storage thread 201 performs a comparison at step 504 to determine if there is sufficient time to operate on a zero deadline message given the most recently calculated start time. Determine whether or not. This determination is to compare the current time with the most recent start time and the difference between the expected disk access time from the specific storage device 131 (the time required to read one data block (128 kbyte data)). (Step
504).

If the current time is less than the difference between the most recent start time and the expected disk access time, only manipulate the deadline message of zero and still meet the most recent start time requirement. There is enough time. Accordingly, in such a case, the first message in the request list 241 is removed for processing (step 506). This first message will be the zero deadline message or the most urgent (ie, least deadline) message.

However, if the current time is greater than the difference between the most recent start time and the expected disk access time, then the zero deadline message will be manipulated and the most recent start time requirement will still be in effect. There is not enough time to fill. Accordingly, in such a case, the first non-zero deadline message in the request list 241 is removed for processing (step 505).

After removing the message for processing (step 505 or 506), the storage thread 201 unlocks the linked list data structure 242 (step 507)
Next, the message is processed (step 508). After this processing, the storage thread 201 then locks the linked list data structure 242 (step 509) and inserts the message storage element occupied by the message processed in step 508 into the free list 240 (step 510). After this insertion, the linked list data structure 242 is unlocked (step 511).

After completion of the storage thread process 500, the storage thread 201 proceeds to the message queue process 400 shown in FIG. 7 to retrieve the message written to the message queue 233 since the start of the storage thread process 500. And return the process.

Data Structure and Access of Storage Module
The mechanism VOD system 100 uses a hybrid file management mechanism to manage the storage of video objects.
The hybrid file management mechanism simplifies the task of managing a large number of named video objects (i.e., video files) and fully utilizes the full performance bandwidth of raw disk drives by using a central control module 110. It includes both file system services provided by the operating system running on it and raw disk access methods.

In general, the size of a video object itself is determined by control information (for example,
Video attribute, creation date, storage map, etc.). Typically, the size of a video object is Gbyte, and the size of its control information is kbyte or less. Further, the number of input / output operations for the video object greatly exceeds the number of input / output operations for the control information. VOD
System 100 uses a raw disk method for storing and accessing the video objects themselves. Thus, spatial requirements are minimized and performance is optimized by avoiding (bypassing) the space and performance overhead associated with the operating system file system.

However, VOD system 100 uses the operating system's file system to store control information associated with each video object. By using such a file system,
Name space mapping of video objects
The complexity of managing mappings, maintaining directory information, and dynamically allocating and deallocating storage space for control information is eliminated. Moreover, software testing, system maintenance, and preparation for future upgrades are simplified. At the same time, the penalties caused by storage space and performance overhead are minimized. This is due to the relatively small size of the control data and the relatively small number of input / output requests as compared to the video object.

Here, FIG. 2 is referred to again. The system disk 235 in the central control module 110 contains a video catalog subdirectory 236 and a server configuration file 237.

The video catalog subdirectory 236 is a directory (for example, "/ svsdrive / cat") and has a plurality of named files. In this case, each named file corresponds to a video object of the same name stored in the storage module 130.
Such named files contain control information such as video attributes, playback data rate, and the maximum number of concurrent users.

The server configuration file 237 (for example, “drive-confuguration”) contains information on the storage allocation of the storage device 131 in the storage module 130. Such information includes, for example, information on the raw device name, stripe segment size, and redundancy. The server configuration file 237 is read at system startup and used to configure the VOD system 100.

Further, the system disk 235 has as many mount points as the number of storage devices 131 in the storage module 130. During normal operation, the control partition of each storage device 1313 is mounted on one of the mount points.

During the configuration of the VOD system 100, each storage device 131 is formatted into two partitions, a control partition and a data partition.

During the format of the storage device 131, a file system is created in each control partition. Each control partition
Contains a free space bitmap that specifies segment availability for the corresponding data partition.

The control section also contains a number of named files, each of which contains one space map of video object stripes. One space map maps address information for each of the 128 kbyte data blocks included in one video stripe. Therefore, the space map indicates one of the video stripes on the storage device 131.
Used to locate each of the 28 kbyte data blocks. More specifically, the space map translates logical block numbers within a stripe of a video object into physical segment numbers within a data partition on the same storage device 131. The name of the space map file is formed by adding a stripe number to the name of the corresponding video object.

The data partition of each storage device 131 is formed as a raw disk partition (ie, the disk is formatted without any operating system information). Access and storage management for the data partitions is performed entirely under the control of the central control module 110. More specifically, a storage thread 201 controls access and storage management of data partitions.

The format of the storage device in the storage module
The matting storage device 131 is organized into a plurality of groups (called stripe groups), and each group is assigned a number (called a stripe group number) one by one. When a video object is divided into multiple video stripes, those video stripes are assigned to a specific stripe group. Each video stripe in the video object is stored on a separate storage device 131 within the assigned stripe group. Each storage device 131 in the storage module 130 is formatted specifically for the VOD system 100.

At the time of the formatting process, the user specifies storage information such as a stripe group number, a stripe number, a raw device address, a stripe segment size, and a primary / secondary indicator relating to a disk to be formatted. The user also creates a mount point using the desired naming convention, for example, "/ svsdrive / G2 / 4" for disks in stripe group 2 and stripe 4.

Next, "/ svsdrive / drive-configuration"
The server configuration file 237 is opened. If the server configuration file 237 does not exist, a new server configuration file 237 is created. The storage format information specified by the user is checked for validity with respect to the server configuration file 237. After the validation, the new drive name and information are added to the server configuration file 237.

Next, the disk is formatted into two partitions. Partition 0 (control partition) is defined as mountable, and a file system is created in partition 0. Section 1 (data section) is defined as unmountable.

Next, partition 0 is mounted at the previously created mount point. Therefore, "freespace.ma
A file such as p "is created in partition 0 as a free space bitmap. The file is then initialized to indicate that all segments in partition 1 are available (unallocated) ( However, segment 0
except for). Then, partition 0 is unmounted.

Next, the partition 1 is opened, and the stripe group number, stripe number, mount point for stripe, primary / secondary flag, active disk flag, raw device name for primary disk, and secondary disk Information such as the name of the raw device for writing is written in segment 0.

After writing to segment 0, partition 1 and the configuration file are closed.

[0111] After the format of the start-up processing storage device 131 of the storage module, it is possible to start up the VOD system 100. The startup process is performed in the server configuration file 237 "
/ svsdrive / drive-configuration "into the DRAM 232 and then perform a validation by comparing the configuration information in the server configuration file 237 with the actual hardware configuration.

The server configuration file 23
After 7 validations, each disk is initialized by the following process.

(I) Copy the control partition (partition 0) of the disk to its corresponding mount point (for example, "/ svsdrive / G3 /
2 "), and (ii) read the free space bitmap file into memory from the control partition and efficiently access and update the file during normal operation to allocate and deallocate space. And (iii) opening the data partition (partition 1) on the disk for subsequent normal access to the stripes of video objects on the disk.

[0114] open VOD system 100 of the video object has completed the start-up process, the client program 206 will wait until the FileOpen () function call in order to create a video object. For example, the client program 206
Can call the FileOpen () function to create a video object called "xyz" (step 620).

In response to the FileOpen () call, the VOD system 100 performs the video open processing shown in the flowchart of FIG. 9 to open the video object on the storage module 130.

The video open processing is performed in the video catalog directory 236 (for example, directory “/ svsdrive / ca”).
t ") begins by creating a video catalog file" xyz "in step 601. The VOD system 100 then stores control information such as video attributes, data rate, video length, and creation date and time in the video catalog file. Write to "xyz" (step 602).

Next, the external processing generates a space map for each storage device 131 in the stripe group (step 603). The space map converts each data block of a specific video stripe into an address on the storage device 131. The space map is stored in each storage device 131.
In the control section (ie, section 0). The name of the space map file is preferably generated by appending the total number of stripes and a specific stripe number to the video object name. For example, if the video "xyz" has six stripes, the space map file associated with stripe 3 of the video object contains "xyz
The space map generation process 603 is repeated for each stripe of the video object. The space map files are then opened for a write operation.

Next, for each space map file created and opened, the VOD system 100 inserts a control block into the file control block chain corresponding to the storage device 131 (step 605). Each storage device 131
Has one file control block chain. The file control block chain is a series of control blocks and is shared in the DRAM 232. The control block is a copy of the control information associated with each video stripe, and in particular includes a copy of the space map stored in the control partition of storage device 131. The control block in the file control block chain is a DRAM 232
, The space map in the control block has a faster access time than the actual space map shared by each control partition.

Next, the client program 206
FileWrit for writing video object data
Call the e () function (step 621) and
The system 100 selects, for each data block, a storage device 131 in a specific stripe group for storing the data block (step 607). After selecting the storage device 131, the VOD system 100 allocates memory for the data block by searching the corresponding free space pit map for available space (step 608).

After the memory for storing the video object data has been allocated, the central control module 110
Updates the file control block for each stripe of the video object (step 609) and updates the free space bitmap to reflect the storage allocation
(Step 609). Next, the central control module 110 generates a raw disk write operation to write the video object data to the partition 1 of each storage device 131 present in the stripe group according to the space map.
(Step 610). After writing all data blocks,
The client program 206 calls the FileClose () function. Upon receiving the FileClose () function, the VOD system 100 updates the space map stored in each storage device 131.

Reproduction of Video Object The reproduction of the video object is performed by the client program.
206 begins by generating a StreamOpen () and then a StreamPlay () function call. For example, StreamOpen () and StreamP
The layback () function can be called to start playing the video object named "xyz". FIG. 10 is a flowchart showing processing for opening a video object for reproduction.

When the StreamOpen () function is called (step 720), the program code 231 opens the video catalog file 237 (for example, "svsdrive / cat / xyz") (step 701), and its contents (ie, contents). Is read. Information (stream data rate, video object size, etc.) read from the video catalog file 237 is used to control the reproduction of the video object.

Next, for each stripe of the video object, the program code 231 reads the space map file (stored in the storage device 131 assigned to the specific video stripe) (step 70).
2), generate control blocks. Next, the program code 231 searches the control block chain associated with the storage device 131 to which the video stripe is assigned (step 703). If the control block for the video stripe already exists in the control block chain, the program code 231 increments the usage count (step 704). If the control block does not already exist in the control block chain, the program code 231 adds the control block to the control block chain (step 705) and sets the use count to one.

After performing the search 703, the program code 231 performs a raw disk read operation on the partition 1 of the storage device 131 by using the space map information stored in the control block (step 703). 706),
The video object data is read into the memory buffer 114.

Subsequently, when the StreamPlay () function is called by the client program 206 (step 721), the central control module 110 sends the video object data from the memory buffer 114 to the distribution module 120 for processing. Program code 231
Continues the raw disk read operation until the end of the video object is reached or until a blocking condition, such as an end condition (eg, time limit) specified by the user, occurs (step 708). Then, program code 231
Calls the client by the callback function and terminates the playback by the client program 20.
Inform 6

Next, the client program 206
Call the eamClose () function. Next, the program code 231 performs a closing process for each stripe of the video object in response to the StreamClose () function call.

The closing process includes determining a use count for a space map file in the control block chain. After the determination, if the usage count is zero, the control block is deleted from the control block chain.

After the determination, the program code 231 closes the space map file related to the stripe of the video object.

Finally, the program code 231 is used to store the video catalog file 237 related to the video object.
(Eg "/ svsdrive / cat / xyz").

Disk Load Balancing (Scheduling
G) In the multi-stream VOD system 100, if the start time of each video playback stream is not adjusted,
One or more storage devices 131 may be overloaded by receiving too many messages simultaneously requesting a read. When this occurs, messages may not be timely acted to meet the time requirements for continuous stream playback. This causes undesirable defects in video playback. The VOD system 100 preferably
Multiple storage devices 131 using data stripe scheme
Interleave the storage of video objects into
Furthermore, the start time of each video stream is adjusted using a scheduling method, so that none of the plurality of storage devices 131 is overloaded. The scheduling method also minimizes the time delay before the start of the stream.

Preferably, the scheduling method is used individually for each set of disks in a stripe group.

The start of the reproduction of the video stream is distributed using the time zone, thereby avoiding the concentration (overload) of disk accesses. Each video stream is scheduled (assigned) to start at a specific time slot. According to the scheduling method,
There are M time zones (where M is the number of storage devices 131 in the stripe group). The M time zones are represented as Z ₁ ... Z _m .

Table 1 below shows a preferred time zone rotation in a system having four storage devices 131 per stripe group.

[0134]

[Table 1]

Time is measured at predetermined fixed-length time intervals called time slots (T _n ). For example, during timeslot T _1, the disc 1, to start only video streams assigned to time zone Z _1, the disk 2
But to start only video streams assigned to time slot Z ₂ (same hereinafter). Similarly, time slot T
During _2, (hereinafter the same) of the disk 1, to start only video streams assigned to time slot Z _2, disk 2, to start only video streams assigned to time zone Z _3. Rather than assigning each video object to a predetermined fixed time period (Z _i ) as was done in the conventional manner, the earliest available time associated with storage 131 where the video stream will start. The reproduction start of the video object is assigned to the band (Z _i ). The earliest available time period (Z _i ) is the next time period (Z _i ) that has sufficient capacity to operate playback without causing any defects in the video stream currently assigned to time period Z _i. Z _i ).

In one preferred embodiment, M = 6. In another embodiment, different numbers of storage devices 131 are assigned to a particular stripe group.

FIG. 11 is a flowchart showing a scheduling method 800 by the VOD system having M storage devices 131 in one stripe group.

The scheduling method 800 includes a StreamPlay message for starting reproduction of a video stream.
It starts when the stream thread 204 receives 820.
Next, the stream thread 204 determines the disk number n of the storage device 131 storing the first data block to be read (step 801). Next, the stream thread 204 acquires the current time (t) (step 802).

Next, the storage thread 201 calculates an index value (C) representing the current time zone (step 80).
3). The index value (C) is calculated according to the following equation.

C = (floor (t / T) -n) modM where: t = current time T = time interval for reproducing data block (that is, Z = data block size / stream reproduction data rate) n = Number of storage devices in stripe group M = Total number of storage devices in stripe group Floor = Function to return by truncating variables to return an integer value The scheduling method 800 uses a time zone having M elements The column Z [1... M] is used. The M elements are each initially set to zero and represent the number of active playback streams assigned to each of the corresponding M time periods.

After calculating the index value C in step 803, the stream thread 204 sets C to the index I. The stream thread 204 then compares the value of the I-th element of the time zone usage column Z with the maximum number of streams that can be assigned to one time zone (step 80).
Four). The maximum number of streams for one time slot is determined by the access time for a specific storage device 131. If the comparing step 804 returns a result indicating that the time period is full (ie, already has the maximum number of streams), the method updates the index value I according to the following equation: (Step 805).

I = (I + 1) Mod M After updating the index value in step 805, the method returns to the comparison step 804.

[0143] However, the comparison step 804, when it returns a result indicating that the time zone is not full is updated time zone using column Z (step 806), the video stream is assigned to a time period T _i ( Step 807).

After the video stream has been assigned to the time period T _i , the video stream starts playing after a time delay according to the following equation:

Time delay = ((I + M + C) mod M) + T This time delay is introduced to start playback at the desired (selected) time slot.

The stream thread 204 has a StreamPause ()
When receiving a call, or when completing the playback of the stream, decrements the usage values Z ₁ regarding regeneration stream.

RAID System and Method The VOD system 100 uses the inexpensive disk redundant disk array (RAID) system and method according to the present invention. According to the present invention, the storage module 130
A plurality of storage devices 131 are used to store a plurality of video objects. It will be appreciated that the RAID system and method according to the present invention is not limited to video server applications, but will be useful in any computer system or configuration that uses an array of storage devices.

The RAID system and method according to the present invention provide a storage subsystem composed of multiple disks.
(Storage module 130) achieves high throughput with respect to data access and the performance penalty of dynamically reconstructing the data lost when one or more disks fail. Allows you to limit.
The system and method further achieves dynamic data reconstruction in the event that N / (M + 1) or less storage devices 131 (disks) in a disk array of N disks fail. Enables continuous operation. Here, (1) M is the redundancy factor specified (or assigned as a default value) by the creator of the data object when the data object is stored in the disk array, and (2) failed 2
The distance between two disks is greater than M.

The system and method interleave the storage of data objects on N disks. Here, N can be made as large as desired to obtain high performance by allowing multiple parallel disk operations and to create a parity block every M data blocks. is there. In addition,
M is an integer smaller than N, and is made as small as desired to limit the performance penalty during dynamic data reconfiguration (if M = 1 is selected, the RAID level 1 mirror Equivalent), so that performance levels can be guaranteed in all situations. The fact that M is small means that the storage overhead for redundant data is large.

A typical application of the present invention is a multi-stream VOD system 100, where the total disk throughput is from tens of Mbytes / sec to hundreds or thousands of Mbytes / s.
ec range. One video object stored on video server 105 may be requested by tens, hundreds, or thousands of users simultaneously. Therefore, it is essential that video objects can be striped on a large number of discs. For example,
Video object striping is performed on 20 disks, and all 20 disks operate in parallel to satisfy the requirements of hundreds of users. In this case, the redundancy factor M for the video object is, for example,
It is possible to select 4 so that only four parallel disk reads are needed to reconstruct the data blocks lost in the event of a disk failure. This not only guarantees a response time in such a case, but also hardly increases the workload of the entire system. The reason is that those four disk reads are closely related to the lost data and are absolutely needed during normal video playback, so they are special (compared to normal access). It is not a simple disk operation. For the purposes of this description, assume that there are N disks (numbered 0-N) in the array. Also, preferably, when a data object (such as a video object) is created, data is continuously distributed in stripe block sizes (data blocks are numbered 0, 1, 2,...). .

FIG. 12 is a flowchart illustrating a RAID method 900 for storing video objects according to the present invention. The method first performs a setup process 901. In a setup process 901, a creator of a video object (eg, a computer program or a user) specifies a redundancy factor M for the video object. M is an integer of 1 to N-1. Where N
Is the number of storage devices 131 in the storage module 130.

Next, during a setup process 901, the method determines whether the redundancy factor M
Is stored. The method further initializes index (I) to zero and defines and initializes a parity buffer on DRAM 232.

Next, the system retrieves a data block to be written to the video object (step 902). For each data block, the method uses an exclusive OR of the I-th data block with respect to the parity buffer.
An operation is performed (step 903). The method 900 then writes the Ith data block to the Jth disk (step 904). Here, J = {floor (I / M) · (M + 1) + (I mod M)} mod N.

Further, the I-th data block is written as the K-th block of the stripe of the video object on the J-th disk. Here, K = floor ({floor (I / M) · (M + 1) + (I mod M)} /
N).

The method then proceeds to the current data block.
A test is performed to determine whether (I-th data block) is the last data block in the redundancy group (step 905). In the test 905, the following determination is made.

(I) Is I not less than (M-1)?

(Ii) Is ((I + 1) mod M) = 0?

If such a condition is satisfied, the method
900 writes the parity buffer to the J-th disk (step 906). Here, J = {(I + 1) / M · (M + 1) −1} mod N.

The parity buffer is written as the Kth block of the stripe of the data object on the Jth disk (step 906). Where K = flo
or ({(I + 1) / M. (M + 1) -1} / N).

After writing the parity buffer in the J-th disk, the parity buffer is cleared (initialized again) (step 907).

Next, the method 900 increments the index (I) by one (step 908). The method 900
Then performs a test to determine whether the last data block of the video object has been written to disk (step 909). If the writing of the last data block has not been completed (ie, there are more data blocks to be written), the method
900 returns to step 902 to retrieve the next block of data to write to the video object,
To continue. Also, if the last data block has been written, the method 900 determines whether the current data block (I-th data block) is the last data block in the redundancy group. (Step 910). The test 910 is (Imod
M). If (Imod M) is not zero, then the redundancy group has less than M data blocks, so the method 900 proceeds to step 911, where one data block is filled with all zeros. Is written to the J-th disk. Where J =
{floor (I / M) · (M + 1) + (I mod M)} mod N.

At step 911, the I-th data block is written as the K-th block in the stripe of the data object on the J-th disk. Here, K = floor ({floor (I / M) · (M + 1) + (I mod M)} /
N).

Next, the method 900 performs a test to determine whether the I-th data block is the last data block in the redundancy group (step 912).
The condition will be satisfied if:

(I) I is equal to or more than (M-1).

(Ii) ((I + 1) mod M) = 0.

If the condition is satisfied, the method 900
Writes the parity buffer to the Jth disk
(Step 913). Here, J = {(I + 1) / M · (M + 1) −1} mod N.

Furthermore, the parity buffer is written as the K-th block of the stripe of the data object on the J-th disk (step 913). Here, K = floor ({(I + 1) / M. (M + 1) -1} / N).

[0168] The method 900 then clears the parity buffer (step 916), and then closes all N stripes for the data object (step 9).
15). On the other hand, if the condition was not met at test 912, the method 900 then increments I.
(Step 914) Then, returning to Step 910, it is determined whether or not the current data block (I-th data block) is the last data block in the redundant group.

FIG. 13 is a flowchart illustrating a RAID method 1000 for accessing a video object according to the present invention. The method 1000 requires the stream thread 204 to read an Ith data block from a video object stored on a Jth disk.
(Step 1001) starts. Upon receiving the read request, the method 1000 reads a redundancy factor M for the video object (step 1002). The method 1000 then performs a test to determine a fault condition (step 1003). Test 1003 that no failure occurred
, The method 1000 retrieves the data block from the appropriate disk (Jth disk). However, if the test 1003 determines that a failure has occurred, the method 1000 initializes the data reconstruction buffer to all zeros (step 1004). Then, the method 1000 includes:
The index P is initialized to zero (step 1005).
By initializing P to zero, P is initialized to point to the first data block in the redundancy group.

Next, the method 1000 performs a test to determine whether the Pth data block is stored on the failed disk (step 1006). If it is determined that the Pth data block is stored on the failed disk, the method 1000 proceeds to read the Kth data block of the stripe on the Lth storage device. Here, L = {J + N− (Imod M) + P} mod N J = {floor (I / M) · (M + 1) + (Imod M)} mod NK = floor ({floor (I / M) · ( M + 1) + (P mod M)} /
N).

Next, the method performs an exclusive OR operation on the extracted data and the data stored in the reconstruction buffer (step 1008). The method then comprises the step 1
Proceeding to 009, the index P is incremented. After the increment, the method 1000 performs a test to determine whether the reconstruction is complete (ie, whether P> M) (step 1010). If the reconstruction is complete, the method 1000 returns the data in the reconstruction buffer to the stream thread 204. If the reconstruction has not been completed, the method 1000 returns to step 1006.

The above description is merely exemplary of the methods and embodiments of the present invention. As will be appreciated by those skilled in the art, the present invention may be embodied in other specific forms without departing from its spirit and essential characteristics. Accordingly, the disclosure of the present invention is intended to be illustrative, and not limiting, of the scope of the invention, which is set forth in the following claims.

[Brief description of the drawings]

FIG. 1 is a block diagram illustrating a video on demand system according to the present invention.

FIG. 2 is a block diagram showing a central control module including a program module (processing thread) used in the video-on-demand system of FIG. 1;

FIG. 3 is a state diagram showing the interaction of processing threads used in the central control module shown in FIG.

FIG. 4 is a flowchart showing a data structure and a program module used for accessing the storage device.

FIG. 5 is an explanatory diagram of a “request list” shown in FIG. 4;

6 is a state diagram showing a processing state of the stream thread shown in FIG. 3 according to the present invention.

FIG. 7 is a flowchart illustrating a message queue process performed by each storage thread.

FIG. 8 is a flowchart showing processing by a storage thread of a message in the “request list”.

FIG. 9 is a flowchart showing a video object open process for storage in the storage module shown in FIG. 1;

FIG. 10 is a flowchart showing a video object open process for reproduction.

11 is a flowchart illustrating a scheduling method for temporally balancing access loads across a plurality of storage devices illustrated in FIG. 1;

FIG. 12 is a flowchart illustrating a method of storing a video object in a disk drive array using a redundancy factor (M) to generate a parity code for every M data blocks.

FIG. 13 is a flowchart showing a process of retrieving a data block stored according to the method shown in FIG.

[Explanation of symbols]

 100 VOD system 101 Video client 105 Video server 110 Central control module 120 Distribution module 130 Storage module 150 Control input source

──────────────────────────────────────────────────の Continued on the front page (51) Int.Cl. ⁶ Identification code FI G06F 17/30 G11B 20/10 Z G11B 20/10 H04N 7/16 A H04N 7/16 7/173 7/173 G06F 15/40 370D

Claims (17)

[Claims] 1. A video server system for providing a video client service, comprising: a mass storage module for storing a plurality of video selections; and a SCSI interface for emulating a SCSI device by operating in a target mode. A distribution module having one or more processing modules, each processing module for processing video data to be distributed to a video client; Is the SCSI
A distribution module programmed to receive video data via the interface, buffer the received video data, and distribute the buffered video data to the client; Connected first SCSI
A central control module having an interface and a second SCSI interface connected to the distribution module, wherein the central control module receives a video control command from a client and controls playback of the video selection in response to the received video control command. And a central control module. 2. The video processing apparatus according to claim 1, wherein at least one processing module included in said distribution module is video data decompression means for decompressing the compressed video data.
The video server system according to claim 1. 3. The video server system according to claim 2, wherein said video data decompression means decompresses data according to the Motion Picture Expert Group (MPEG) standard. 4. The computer readable medium of claim 1, wherein the distribution module is a computer motherboard mounted on a rack mountable chassis, and the central control module is a computer motherboard mounted on a rack mountable chassis. A video server system as described. 5. The video server system according to claim 1, wherein the at least one processing module included in the distribution module is an Ethernet format module for formatting video data for distribution via an Ethernet network. 6. The video server system according to claim 1, wherein the at least one processing module included in the distribution module is an asynchronous transfer mode (ATM) module for formatting video data for distribution over an ATM network. . 7. The system according to claim 1, further comprising one or more additional distribution modules, wherein said mass storage module comprises a plurality of SCSI compatible storage devices, and wherein said central control module comprises: A first plurality of SCSI interfaces connected to a storage device and a second plurality of SCSI interfaces each connected to one or more of the distribution modules;
The video server system according to claim 1. 8. The video selection, wherein each of the video selections includes control data and video data, wherein the control data is stored using a file management system associated with an operating system running on the central control module; The video server system according to claim 1, wherein data is stored in a raw format, bypassing the file management system. 9. The control data according to claim 1, wherein the control data includes an address map indicating an address of an unused memory on the storage device, and an address map for mapping each data block of the video object to an address on the storage device. Item 9. A video server system according to item 8. 10. The central control module generates a plurality of read requests for reading video data stored in the mass storage device, a message queue for storing the read requests, and the message 2. The video server system according to claim 1, further comprising a prioritizing means connected to a queue for prioritizing said read requests. 11. The prioritizing means determines whether each read request is an urgent read request, calculates a deadline for each urgent read request, and serves a non-urgent read request. To determine if an urgent read request will miss the deadline by servicing a non-emergency read request. Servicing a non-emergency read request in response to a non-emergency read request and providing a read request with an emergency deadline in response to a determination that the emergency read request will miss its deadline. The video server system according to claim 10, wherein the video server system implements a method comprising the steps of servicing. 12. The mass storage module includes a plurality of storage devices, wherein a plurality of the video selections are stored in a stripe configuration over the plurality of storage devices, and a plurality of video selections corresponding to a received control command are stored. The control of playback defines a plurality of time slots, identifies a storage device on which playback is to be initiated, schedules playback of the video selection in a first available time slot for the identified storage device, 2. The video server system according to claim 1, wherein the storage device performs a plurality of time slot services in rotation. 13. The mass storage module comprises a plurality of storage devices, wherein at least one video selection includes a plurality of data blocks and is stored in a stripe configuration across the plurality of storage devices. 2. The apparatus of claim 1, further comprising an error block calculated every M data blocks, wherein M is an integer redundancy factor less than the number of storage devices used in the stripe configuration. Video server system. 14. A method for prioritizing services of a received control command in a video server system configured to receive a plurality of control commands including a time critical command and a non-time critical command, the method comprising: Determine deadline for each time-critical command, determine whether non-time-critical command can be serviced without missing the deadline for time-critical command, and miss the deadline for time-critical command Service a non-time critical command in response to a determination that the non-time critical command can be serviced without the need for a non-time critical command without losing its deadline to the time critical command. A method for prioritizing the service of a control command received in a video server system, comprising the steps of: servicing a time-critical command in response to a determination that the command cannot be performed. 15. A method for storing digital data in a plurality of (N) storage devices, comprising: dividing the digital data into data blocks; storing the plurality of data blocks in each storage device; Selecting a redundancy factor (M), generating an error recovery block for each of the M data blocks, and storing the error recovery block in a storage device different from the storage device storing the associated data block. A method for storing digital data in a plurality of storage devices, characterized by comprising: 16. The method of claim 15, wherein generating the error recovery block comprises calculating a parity code. 17. The method of claim 16, wherein storing the plurality of data blocks on each storage device comprises striping the data blocks across the plurality of storage devices.