A NOVEL INTERFACE FOR PREVIEWING RECORDS OF A NETWORK VIDEO RECORDER

Field of the Invention

The present invention relates to the field of video surveillance systems. More particularly, the invention relates to a novel application with an interface for rapidly previewing records acquired and stored by a Digital Video Recorder (DVR) and a Network Video Recorder (NVR).

Background of the Invention

Many modern monitoring and surveillance systems turn analog cameras into digital and also employ IP-based video systems by combining high- quality cameras and software for managing networks of video cameras. Such systems are directed to traffic monitoring for intelligent transportation systems, industrial facility security, and security for ports, banks and other public facilities. Such systems are scalable from a few cameras to hundreds or even thousands. Most of the conventional DVR / NVR systems collect Analog / Digital video data from many video cameras and digitally store them in records using digital storage devices (e.g., hard disks), usually in MJPEG, , H.264 or any type of MPEG, such as MPEGl/2 MPEG4 formats (MPEG-4 is a standard used primarily to compress audio and visual digital data). Each record comprises a video stream of a predetermined time length or number of frames, usually categorized by timing parameters and is related to a specific camera. The timing parameters are the date, start time of the stream and end time of the stream.

The stored records are used for retrieving and playing video streams that are related to previous events of interest. This task is done by using appropriate software application that manages the records by means of indexation and allows the system administrator to retrieve stored records and play them.

Existing software applications offer user interfaces through which records of interest may be retrieved for playback, such as search engines that use the indexation data and/or timing parameters. However, these software applications suffer from several major drawbacks: The first one is the need to enter each record in order to have information whether or not a particular record actually contains a video stream of interest. This need exists, since the timing and indexation do not provide sufficient information about the content of each record. This drawback results in an inefficient interface, which is time consuming and cumbersome due to the fact that each record should be configured for playback before its content can be viewed. This problem is even more severe when using the records in MPEG4 standard due to the fact that MPEG4 comprises a series of Key- Frame and therefore, is more difficult to be managed by software. The second drawback is the need to read an entire block of indexes each time, in order to reach a single frame of interest. The third drawback is the need to access the disk on which the record is stored twice, in order to reach that frame. This requires many resources from the server which is required to move the read/write head to different locations on the disk, especially when the server is loaded with other tasks. The fourth drawback arises from the fact that the video file (mostly in *.avi format) itself also contains the indexing data. This requires parsing the video file in order to reach the right index. Therefore, these drawbacks introduce a substantial overhead to the

system, which results in resource consumption and delayed performance, particularly when the request for a particular record is sent over a data network in which the response time of the communication channels is relatively long (e.g., the internet, local network, cellular network of a network with GPRS channels, in which switching operations are complex).

All the methods described above have not yet provided satisfactory solutions to the problem of providing software for managing DVR / NVR records with an efficient interface that does not require playback for reaching a desired record.

It is therefore an object of the present invention to provide software for managing DVR / NVR records with an efficient interface that does not require playback for reaching a desired record.

It is another object of the present invention to provide software for managing DVR / NVR records with an efficient interface that supports records stored in MPEG4 standard.

It is still another object of the present invention to provide software for managing DVR / NVR records which is capable to keep continuity of a desired video stream in the absence of a Key-Frame.

It is yet another object of the present invention to provide software for managing DVR / NVR records which reduces the overhead required to reach a desired record.

Other objects and advantages of the invention will become apparent as the description proceeds.

Summary of the Invention

The present invention is directed to a method for storing and retrieving digital a plurality of records, each of which is associated with a camera and originated from an DVR / NVE-. The number of desired frames per record is defined for each camera in the DVR, / NVR. A series of nonsequential indices representing pointers to groups of frames that belong to the record are generated for each record that is a part of a video stream file. It is also possible to generate a first indexation file containing indices representing the first type pointers to frames that belong to the record in the plurality, as well as a second indexation file containing second type pointers to the first type pointers and metadata of the video stream file, for each record that is a part of a video stream file. An image file containing a frame, selected from the record is determined for each record. Whenever a specific record from the video stream file is sought for playback, a graphical user interface that comprises a video player and a display window is displayed. This interface displays all records in the window by graphical representations, ordered according to the second indexation file. The user selects the corresponding record via the interface, using its graphical representation and the image file is retrieved form the video stream and displaying it by the video player as a preview of the specific record. Than the user loads the specific record onto the video player and play the record, selects another record or plays all the subsequent records.

The video stream may be encoded using MPEGl/2; MPEG4; H.264 formats or any video stream that uses GOP. The image file may comprise the first frame in the selected record. The user may select a

record using a mouse cursor or a keyboard, or toggle between records using a scroll bar. Alternatively, toggling between records may be carried out automatically according to predetermined order and timing.

Whenever a key-frame is missing from the video stream, the closest preceding intermediating frame may be used as a substitute.

The series of non- sequential indices is generated in advance, only after the first access to a desired record or from the video stream file, after recording.

The record may be loaded to and played on a camera with internal memory; a PC with a video player; or a cellular mobile device.

Brief Description of the Drawings

The above and other characteristics and advantages of the invention will be better understood through the following illustrative and non- limitative detailed description of preferred embodiments thereof, with reference to the appended drawings, wherein:

Fig. 1 illustrates a unique representation of DVR / NVR group of records taken during one hour, according to a preferred embodiment of the present invention;

Fig. 2 illustrates a unique interface for allowing the user to access the stored records, according to a preferred embodiment of the present invention;

Fig. 3 illustrates the dialog box for determining the storage settings of each record, according to a preferred embodiment of the present invention; and

Fig. 4 schematically illustrates the process for allowing the user to quickly preview the first frame of each record, while toggling between records.

Detailed Description of Preferred Embodiments

The software for managing DVR / NVR records, proposed by the present invention comprised a unique representation of each record, as shown in Fig. 1. Each group of records corresponds to video data taken by a specific camera (in this example, Camera # 1) and consists of a combination of 3 different files: the *.VFR file: this file Cam01100411.VRF comprises the video stream (in a compressed binary form of bit stream) that was taken by Camera # 1 on Apr 10, 2007 from 11:00 till 12:00 pm (hh-11). The *.VFR file may also comprise unique digital signatures in addition to the raw video data, in order to generate unique headers to protect the raw data and allow playing it only on authorized players. Alternatively, the raw video data may be encoded by a special key, which will be required also by the video player. This way, it will be possible to play this file only on dedicated players, rather than on any standard video player.

- the MNX file: this file Cam01100411.INX comprises a group of pointers of a first type, indicating the timing and the bit, which begins every frame, as well as the bit which ends every frame, in the *VFR file (in this example #1)

- the *.FND file: this file Cam01100411.FND comprises a group of pointers of a second type indicating the pointers of a first type that correspond to the beginning and the end of every record, as well as the timing which begins an ends every record (in this example #1)

In this example, directory hh-11 comprises 8 groups of 3 files each, taken by 8 Cameras: # 1, 2, 3, 7, 8, 9, 10 and 11.

According to the invention, the user can access the stored records by using a unique interface, shown in Fig. 2. On the right side of the displayed screen there is a window, in which all the records that correspond to a specific camera are displayed one after the other as ordered lines. Each line comprises metadata that includes the index of the record, the date, the number of frames in the video stream of that record, its start time and its end time. The lines are ordered by the software, which first accesses the corresponding *.FND file that comprises the index of that row (i.e., its location in the row list).

A video player window is displayed on the left side of the displayed screen, by which a selected record can be displayed. As long as the cursor points on a specific record, the software accesses the corresponding *.VFR file that comprises the first frame of that record and display it in the video player window as a still image. This is one of the main advantages of the present invention, since it allows the user to preview the initial content of that record without the need to play the record. Furthermore, the user may scroll the cursor quickly over the records, without the need to play the record. Once the record of interest is reached, the user can view its first frame (or any other desired frame) and decide that he wishes to play the relevant video stream on the video player. In addition, the video player constantly displays the start time (on the left) and the end time (on the right) of that record. At this stage, all he has to do is to activate the video player to start displaying the video stream (e.g., by double clicking on corresponding row or using the 'ENTER" key). Only then the software accesses and loads the

corresponding *.VFR file that comprises the video stream onto the player.

According to another embodiment, the software can switch to an automatic preview mode of the records, by periodically toggling the cursor in an ascending or descending order, so as to allow a supervisor or a user to preview the first frames of all the video streams, one by one.

According to another preferred embodiment of the invention, the proposed software also overcomes discontinuity problems that may occur while using MPEG4 video streams, due to the lack of a Key-Frame (sometimes also called a Group Of Pictures - GOP (in video motion, a frame that starts and ends a video stream and refreshes the previous view. The intermediating frames comprise only the difference between a frame and its neighboring frames). In this case, in order to maintain continuity even in states when the CPU which execute the managing software is overloaded (since the CPU has to allocate resources to other applications), the software continues displaying the closest preceding intermediating frames as substitutes. This is the reason for the slight differences in the number of frames per record, as shown in Fig. 2.

Fig. 3 illustrates the dialog box for determining the storage settings of each record. The number of pictures (frames) in each record can be determined separately for each camera. The "Number of Pictures in Record" defines the quantity of video frames in each record and may comprise between 1-1000 frames in all types of video formats (e.g. MJPEG, MPEG4, etc.). In this example, the record for Camera #1 is set to 100 frames when actually the software will create the record that typically comprise 100 frames, while adding or removing few frames, according to the CPU capability.

Fig. 4 schematically illustrates the process for allowing the user to quickly preview the first frame of each record, while toggling between records. The managing software (that includes the video player) first accesses the *.FND file and reads the records' information from its second type pointers. This allows the managing software to obtain the (textual) data required for properly ordering all the records within the corresponding *.VFR file in rows. Whenever a selected record should be played, the managing software reads its *.INX file, and accesses its first type pointers. This allows the managing software to obtain the (textual) data required for properly determining which frames within in the *.VFR file are included in each record. This way, the managing software identifies the state of the cursor and automatically retrieves the first frame of the corresponding record and retrieves it for preview. Since both the *.FND and *.INX files are textual, the managing software is able to arrange the content of the corresponding *.VFR file very quickly, so as to allow the user to quickly toggle between records, while previewing the first frame, without the need to play the entire *.VFR file. This is specifically efficient in case when the network is overloaded with data flow, since even then, toggling between records, according to the invention still can be done quicker (up to half time) than conventional players.

According to the invention, the software allows very fast access to each frame of interest (according to the time of interest) obtains the indexes of all records by reading a single block from a file of non- sequential indexes that is generated once the video file is firstly accessed. This file is then sent to the client side, which demands the records, in order to save unnecessary further access. This way, access is provided to a group of frames, e.g., 100 frames simultaneously.

The file of non- sequential indexes may be generated in advance (like the *.FND file described above) or only after the first time the record is accessed on the server. Alternatively, the file of non-sequential indexes, as well as the *.FND and *.INX files described above may be generated after recording has been completed, from the *.AVI file itself.

It is also possible not to generate such a file and instead, just forward a series of non- sequential indexes that is serially transferred to the player at the client side. In addition, the group of *.VFR, *.FND and *.INX files may be converted to a single standard video file in *.AVI format. The record may also be loaded to a camera with internal memory, to a PC with a video player or to a cellular mobile device and played thereon.

The above examples and description have of course been provided only for the purpose of illustration, and are not intended to limit the invention in any way. As will be appreciated by the skilled person, the invention can be carried out in a great variety of ways, employing more than one technique from those described above, all without exceeding the scope of the invention.