United States Patent (19)
`Winter et al.
`
`USOO5996O23A
`Patent Number:
`11
`(45) Date of Patent:
`
`5,996,023
`Nov.30, 1999
`
`54) EFFICIENT PRE-ALARM BUFFER
`MANAGEMENT IN INTELLIGENT WIDEO
`INFORMATION MANAGEMENT SYSTEM
`
`75 Inventors: Gerhard Josef Winter; Sen Lin-Liu;
`David Ross MacCormack, all of San
`Diego, Calif.
`
`73 Assignee: Sensormatic Electronics Corporation,
`Boca Raton, Fla.
`
`56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`5,724,475 3/1998 Kirsten .................................... 386/109
`5,822,542 10/1998 Smith et al. ............................ 709/247
`5,825,969 10/1998 Ono et al. ................................. 386/94
`5,854,902 12/1998 Wilson et al. .......................... 709/247
`5,862,342
`1/1999 Winter et al. ........................... 709/231
`5,909,548 6/1999 Klein et al. ........................ 340/825.06
`Primary Examiner Thomas R. Peeso
`Attorney, Agent, or Firm-Robin, Blecker & Daley
`
`22 Filed:
`
`Apr. 29, 1998
`Related U.S. Application Data
`63 Continuation-in-part of application No. 08/740,627, Oct. 31,
`1996, Pat. No. 5,884,042.
`6
`51) Int. Cl. ....................................................... H04N 9/79
`52 U.S. Cl. .......................... 709/253; 348/394; 358/538;
`358/539; 709/231
`58 Field of Search ..................................... 348/394, 407,
`348/262; 358/538,539; 709/231; 345/334,
`339; 382/107,123, 203, 206
`
`A hard disk in a Video data Storage apparatus includes a first
`ENNE, "...N.I., E.R.A.
`video data is Stored Subject to rewriting after a short period
`of time. If an alarm event occurs, Some or all of the data in
`the Second Section may be Secured for permanent Storage.
`The process to be employed in Securing the data in the
`Second Section for permanent Storage is adapted to the
`proportion of the data in the Second Section which is desired
`to be Secured.
`
`9 Claims, 8 Drawing Sheets
`
`
`
`
`
`
`
`
`
`
`
`FRONT END
`PROCESSING |
`COMPRESSION
`
`46
`
`VIDEON, AUDIO IN,
`ALARMS IN | OUT,
`VCR INI OUT
`
`MOTHER BOARD
`
`uPROC. I-44
`
`(TO DISPLAY)
`VIDEO
`OUT
`40
`
`OTHER
`INPUT |
`OUTPUT
`
`
`
`TOf
`FROM
`HARD
`DRIVES
`AND OTHER
`STORAGE
`DEVICES
`
`

`

`U.S. Patent
`U.S. Patent
`
`
`
`s
`FIG.|
`
`20N
`
`Nov. 30, 1999
`Nov.30, 1999
`
`Sheet 1 of 8
`Sheet 1 of 8
`
`5,996,023
`5.996,023
`
`Motorola v. Stellar
`
`Motorola Exhibit 1005
`Page 002
`
`

`

`U.S. Patent
`
`
`
`
`
`97
`
`Z 50/-/
`
`OOHd
`CINE | NOH
`
`NOISSEHGWOO | €)NISSE
`
`WOH | Ol
`
`

`

`U.S. Patent
`
`Nov.30, 1999
`
`Sheet 3 of 8
`
`89
`
`WOH-]/O|
`
`
`
`
`
`Z TENNWHO
`
`Cj/\/
`
`Z TENNWHO
`
`9 TENNWHO
`
`0NI}{OOT
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`5.996,023
`
`
`
`HEH LOW
`
`CHWO809
`
`

`

`U.S. Patent
`
`Nov.30, 1999
`
`Sheet 4 of 8
`
`5.996,023
`
`A/G 4
`VIDEO DATA FORMAT ON DISK
`104
`104
`
`100
`N
`
`FILE
`
`CAM. STREAM
`CAM.2 STREAM
`
`FILE I:2
`20mb.
`
`
`
`
`
`
`
`
`
`16 STREAM
`AV FILE
`
`
`
`106
`
`
`
`108
`
`
`
`110
`
`102 -
`112
`
`CAM.16 STREAM
`
`PRE-ALARM BUFFER
`
`
`
`UP TO 16 CAMS.
`INTERLEAVED/MULT
`STREAM SIGNAL
`
`INDEXES
`INDEX OF FILES:
`1: <START-DATE/TIME -<END-DATE/TIME
`
`
`
`FILE INDEX-DATE TIMECAM.EVENT CONF E.
`(FILE 1)
`O
`
`
`
`
`
`EVENT EVENT 1
`1
`CONF.%
`
`EVENT EVENT 2 EVENT
`2
`CONF.%
`3
`
`
`
`114
`
`114
`
`

`

`U.S. Patent
`
`Nov.30, 1999
`
`Sheet 5 of 8
`
`5,996,023
`
`GYO0sYWHYTV
`
`WayTVOldav
`
`SWILWHVTV
`
`
`
`uOs‘MAIL
`
`ISH
`
`QNSLXS/L3S
`
`9c
`
`S$OA
`
`YaTCNVHWavy
`
`JONANOASSY
`
`OLSVHSWVO
`
`
`
`VesSCNTONI
`
`OLLOAPENS
`
`WavTV
`
`TWNOIS
`
`LNOWav
`
`9€|SaA
`
`
`
`NMOdLAYS
`
`YAWIL
`
`TISL
`
`OAdIA
`
`JOVEOLS
`
`NOILONNA
`
`AYNLdVOOL
`
`WV1V-Sdd
`
`d345ne
`
`vivd
`
`81
`
`vel
`
`col
`
`WOLSND
`
`sel8WHS300030
`
`
`
`AWLL8SdALLNSAS
`
`ot
`
`OFIN3AddNHOO)
`
`
`
`1dldOS3SNOdS3Y
`
`IdlddSNIGNVWNOOwiHOwHO
`
`OblSNdVv3u
`
`ob!SSWIGOONA
`
`OSt
`
`“YIGWALSASOLGNSS
`
`Motorola v. Stellar
`
`Motorola Exhibit 1005
`Page 006
`
`
`
`
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Nov.30, 1999
`
`Sheet 6 of 8
`
`5.996,023
`
`Oli EAOIN
`
`
`XANTHO IXEN
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`9 30/-/
`
`ON
`
`703Ö
`
`557 < NEWTWEEg
`
`

`

`U.S. Patent
`
`Nov.30, 1999
`
`Sheet 7 of 8
`
`5.996,023
`
`WHWTW-EHd
`SHEHH^8 ).
`
`WEWTV-EHd | WEWTV-EHd || 692
`
`093
`
`082
`
`CEAW ETHELNI
`
`
`XOOTE
`
`HELNI-NON
`
`
`
`XOOTE CEAWET
`
`
`
`CEAW ETHELNI
`
`XOOTE
`
`WWEHLS-ET?NIS
`
`
`
`HEXAHWIN XOOT8
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Nov.30, 1999
`
`Sheet 8 of 8
`
`5.996,023
`
`FIG. 8
`ALARM HANDLING
`NON-INTERLEAVED
`PRE-ALARMBUFFER
`
`NORMAL
`PRE-ALARM
`BUFFERING
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`FOREVERY
`IMPLICATED
`CAMERA
`
`
`
`
`
`REDESIGNATE
`238 THE CAMERA'S
`RING BUFFER
`FOR PERMANENT
`STORAGE
`
`
`
`
`
`
`
`240
`
`
`
`
`
`SETA NEW
`RING BUFFER
`FOR THE
`CAMERA
`
`
`
`
`
`

`

`1
`EFFICIENT PRE-ALARM BUFFER
`MANAGEMENT IN INTELLIGENT WIDEO
`INFORMATION MANAGEMENT SYSTEM
`
`2
`information will be permanently recorded. The present
`application is concerned with techniques for efficiently
`managing pre-alarm buffering operations.
`
`5,996,023
`
`CROSS-REFERENCE TO RELATED
`APPLICATION
`This application is a continuation-in-part of prior appli
`cation Ser. No. 08/740,627, filed Oct. 31, 1996, now U.S.
`Pat. No. 5,884,042. The disclosure of the parent application,
`Ser. No. 08/740,627, is incorporated herein by reference.
`Also to be noted is another related application, Ser. No.
`08/729,620, also filed Oct. 31, 1996 (for which the issue fee
`has been paid), now U.S. Pat. No. 5,822,542.
`BACKGROUND OF THE INVENTION
`The above-referenced parent patent application discloses
`a digital video recorder which has intelligent Video infor
`mation management capabilities. A preferred application of
`the recorder of the parent application, as disclosed therein,
`is for Selective recording of Video signal Streams generated
`by closed-circuit Video Security Surveillance cameras. For
`this application, the recorder disclosed in the parent appli
`cation is adapted to receive simultaneous input video signal
`Streams from up to 16 cameras.
`It is often desirable to record Signal Streams output from
`Surveillance Video cameras in order to preserve a record of
`unusual events captured by the video cameras. However,
`because of the enormous quantity of raw information present
`in a Video Signal Stream, it is difficult to provide in an
`economical manner Sufficient Storage capacity for Video
`Signals corresponding to long periods of time. There have
`been a number of proposals intended to provide for efficient
`Storage of Surveillance Video Signals. For example, it has
`been proposed to record Surveillance Video Signal Streams
`only at very low frame rates (say, on the order of one field
`or frame per second). Low frame rate recording, however,
`carries the risk that crucial images will go unrecorded.
`The difficulties in providing adequate Storage capacity are
`increased when it is desired to have more than one video
`camera share a Single recording device. One technique that
`has been utilized to improve the effectiveness of a shared
`recording device is to allocate larger portions of the record
`ing bandwidth to Video Signal Streams in which motion is
`detected. The premise is that signal Streams representative of
`Static images are unlikely to include information that is
`important. While this is a useful Strategy, there remain
`significant risks that important information will be left out of
`the Stream of images actually Selected for recording.
`The parent patent application discloses an additional
`Strategy, referred to as pre-alarm buffering, which also
`promotes efficient use of limited Signal Storage capacity. The
`basic concept is that the respective video Streams generated
`by Some or all of the cameras connected to the recorder are
`not usually Selected for permanent Storage. Instead, a ring
`buffer is provided to record the Signal Streams at a given
`(perhaps shared) field rate for a limited period of time, say
`one minute. If a significant event is detected, Such as tripping
`of an alarm Sensor, actuation of an alarm condition by a
`human operator, or detection of a predetermined character
`istic of an incoming image Stream by machine analysis of the
`image Stream, then the Video signal Stream in the ring buffer,
`which would normally have been overwritten, is preserved
`for permanent Storage. Pre-alarm buffering represents a
`desirable compromise which avoids devoting permanent
`Storage capacity to large quantities of uninteresting
`information, while increasing the likelihood that significant
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`OBJECTS AND SUMMARY OF THE
`INVENTION
`It is accordingly an object of the invention to provide a
`digital Video recorder with pre-alarm buffering capabilities.
`It is a further object of the invention to provide a digital
`Video recorder in which the Signal Storage capability is
`efficiently utilized.
`According to a first aspect of the invention, there is
`provided a video data Storage apparatus, including a plural
`ity of Video cameras, each generating a respective Stream of
`Video signals, conversion circuitry, connected to the plural
`ity of Video signals, for Selectively converting the Streams of
`Video signals into respective Streams of Video data Signals,
`a circular data buffer for Selectively storing ones of the
`Streams of Video data Signals Subject to overwriting by more
`current Video data Signals, a main data Store for Selectively
`Storing ones of the Streams of Video signals and for writing
`the Video data Signals in the main data Store to a removable
`archive recording medium; a detection circuit for detecting
`an alarm condition; and a control circuit for Selecting
`between a first proceSS and a Second process different from
`the first process, on the basis of the alarm condition detected
`by the detection circuit, the first and Second processes both
`being processes for transferring a Stream of Video data
`Signals from the circular data buffer to the main data Store.
`According to this aspect of the invention, the circular data
`buffer and the main data Store may respectively include first
`and second portions of a hard disk drive. Moreover, the first
`process may include reading the Stream of Video data Signals
`to be transferred from the circular data buffer and rewriting
`that Stream of Video data Signals to the main data Store, and
`the Second process may include designating the first portion
`of the hard disk to be a portion of the main data Store.
`According to a Second aspect of the invention, there is
`provided a method of operating a digital Video recorder
`which includes a disk-shaped Storage medium and which
`Selectively records on the Storage medium digital data
`Signals representing respective Streams of Video signals
`generated by a plurality of Video cameras connected to the
`recorder, the recorder including a pre-alarm buffer as a
`designated portion of the Storage medium, and the method
`including the Steps of detecting an alarm condition,
`Selecting, on the basis of the detected alarm condition, one
`of two processes for designating for permanent Storage
`Video data Signals Stored in the pre-alarm buffer, and execut
`ing the Selected one of the two processes, wherein the first
`of the two processes includes reading Some but not all of the
`Video data Signals Stored in the pre-alarm buffer and writing
`the read video data Signals into a portion of the Storage
`medium different from the pre-alarm buffer, and the second
`of the two processes includes (i) redesignating the desig
`nated portion of the Storage medium corresponding to the
`pre-alarm buffer Such that all of the Video data Signals Stored
`in the designated portion are appointed for permanent
`Storage, and (ii) designating a new portion of the Storage
`medium to be the pre-alarm buffer.
`According to a third aspect of the invention, there is
`provided a method of operating a digital Video recorder
`which includes a disk-shaped Storage medium and which
`Selectively records on the Storage medium digital data
`Signals representing respective Streams of Video signals
`generated by a plurality of Video cameras connected to the
`
`

`

`5,996,023
`
`3
`recorder, the method including the Steps of Selecting ones of
`the Video cameras for recording on the Storage medium in a
`pre-alarm buffer mode; for each of the selected video
`cameras, designating a respective portion of the Storage
`medium to Serve as a circular buffer for temporarily Storing
`Video data Signals representing Video signals generated by
`the respective camera; temporarily Storing in the designated
`portions video data Signals representing video signals gen
`erated by the respective Selected cameras, detecting an alarm
`condition; determining that at least one of the Selected
`cameras is relevant to the detected alarm condition; and, for
`each camera determined to be relevant to the detected alarm
`condition: (i) re-designating for permanent storage the
`respective portion of the Storage medium previously desig
`nated to be the circular buffer for the respective camera, and
`(ii) designating a portion of the Storage medium, different
`from the redesignated portion, to Serve as a circular buffer
`for temporarily Storing video data Signals generated by the
`respective camera.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 is a perspective View of a Video recording/personal
`computer (VR/PC) unit provided in accordance with the
`invention.
`FIG. 2 is a Summary block diagram representation of
`electronic components of the VR/PC unit of FIG. 1.
`FIG. 3 is a Summary block diagram representation of a
`front end processing/compression component shown in FIG.
`2.
`FIG. 4 illustrates video data and index data formats
`utilized by the VR/PC unit in storing video data on the hard
`disk provided therein.
`FIG. 5 illustrateS processing carried on by a main pro
`cessor in the VR/PC unit in response to an indication of an
`alarm condition.
`FIG. 6 illustrates in flow-chart form a video storage
`processing Software module, provided in accordance with
`the invention, for the main processor of the VR/PC unit.
`FIG. 7 illustrates an alternative video data format
`provided, according to an aspect of the invention, for the
`VR/PC hard disk.
`FIG. 8 is a flow-chart illustrating an alternative pre-alarm
`buffer management technique provided in accordance with
`the invention.
`
`DESCRIPTION OF PREFERRED
`EMBODIMENTS
`FIG. 1 is a perspective view of an integrated device which
`combines digital video recording, random access retrieval of
`recorded Video data, and user-friendly personal-computer
`based functionality. Reference numeral 20 generally indi
`cates the integrated device, which may be referred to as a
`video recording/personal computer or “VR/PC' unit. The
`VR/PC unit is adapted to receive streams of video signals
`generated by one or more Video cameras. A preferred
`embodiment is configured to receive simultaneous input
`from 16 cameras (which are not shown in FIG. 1). The
`VR/PC unit also provides an output video signal, either live
`from one or more Video cameras, or reproduced from Video
`data storage facilities provided within the VR/PC unit, to
`drive one or more display monitors, which also are not
`shown in FIG. 1.
`The internal components of the VR/PC unit 20 are con
`tained within a molded plastic housing 22. AS will be seen,
`the internal components include control and Signal proceSS
`
`4
`ing circuitry, as well as a number of data recording devices.
`For example, integrated within the VR/PC unit there are
`preferably two or more fixed or “hard’ data recording drives
`of the magnetic type, as well as at least one drive for a
`removable data Storage medium. A preferred embodiment
`includes both a floppy disk drive and a digital audio tape
`(DAT) drive. The floppy drive may be used for loading
`Software programs; the DAT drive may be used to Store
`video data, retrieved from the internal hard drives, for
`permanent or archival Storage on a magnetic tape formatted
`in accordance with the standard DAT format. Access to the
`drives for removable media (which are not shown in the
`drawing) may be had via a hinged dust-shield 24 provided
`at a front elevation 26 of the housing 22. Also provided at
`the front elevation 26 is a front panel 28 on which a plurality
`of Switches are mounted. The Switches permit the user to
`control various functions Such as Selecting input cameras for
`displaying, Setting a format for a displayed Video Signal, and
`controlling playback operations.
`A commercial embodiment of a VR/PC unit, of a type in
`which the present invention may be applied, is currently
`being sold under the trademark “INTELLEX” by the
`assignee of the present invention, Sensormatic Electronics
`Corporation, Boca Raton, Fla.
`An overview of the internal components of the VR/PC
`unit will now be provided, with reference to FIG. 2. As seen
`from FIG. 2, primary components include a motherboard 40
`and front end processing/compression electronics 42.
`The motherboard 40 provides the overall intelligence and
`control for the VR/PC unit. Preferably, the motherboard 40
`is constructed in accordance with conventional architecture
`for personal computer motherboards. The central processing
`unit for the motherboard is preferably constituted by a
`conventional microprocessor 44, which may, for example,
`be one of the models of the well known Pentium line of
`microprocessors.
`The motherboard 40 controls, and exchanges data with,
`data Storage devices Such as the above-mentioned hard disk
`drives, DAT drive and floppy disk drive. The motherboard is
`also adapted to receive user control Signals, which may be
`input via the front panel 28 (FIG. 1) or via conventional user
`input devices (not shown) Such as a mouse and/or a key
`board. The motherboard 40 also exchanges data with the
`front end processing/compression electronics 42 while
`receiving an input digital Video signal from the front end
`electronicS 42, and providing an output video signal to a
`display monitor, which is not explicitly shown in FIG. 2.
`It should be understood that the motherboard 40 includes
`conventional features Such as program memory, working
`memory, input and output data communication ports, data
`Signal bus connections, interfaces for recording medium
`drives, and Video interface ports. All of these are preferably
`of conventional construction.
`The front end electronics 42 provide Signal processing
`with respect to input video signals received via a back panel
`46. The arrangement of the front end electronics 42 may be
`like that incorporated in the above-mentioned INTELLEX
`Video recorder and/or as disclosed in the above-referenced
`parent patent application.
`Certain features of the front end electronics 42 are sche
`matically illustrated in FIG. 3. At the inputside of the front
`end electronics 42 is a multiplexer 50 which selects ones of
`the input camera Streams for recording and/or display by the
`VR/PC unit. Any one of the input video signal streams may
`be assigned to any one of three Video signal locking channels
`52-1, 52-2 and 52-3. At the outputside of the signal locking
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`

`

`S
`channels, a channel-Selection multiplexer 54 is arranged to
`assign any one of the three Signal locking channels to either
`one of two signal conversion channels 56-1 and 56-2. The
`Signal conversion channels are provided to convert the
`Selected Stream of analog video signals into a Sequence of
`digital Video data. The resulting digital Video data is then
`Subjected to further processing, including data compression,
`as indicated at 58 in FIG. 3. The processed data is then made
`available for Storage Via the motherboard and/or for display.
`Preferably, the digital Video data is also Supplied to a
`Signal processing circuit (not separately shown in FIG. 3)
`which Selectively applies image content analysis algorithms
`to one or more of the input video streams in order to detect
`Significant characteristics of the images represented by the
`Video Streams. Among other possibilities, the Signal pro
`cessing circuit may be programmed to detect motion, or
`certain types of motion, in the input video signal Streams.
`FIG. 4 illustrates a format in which compressed video data
`is stored on one or more of the hard disk drives of the VR/PC
`unit. As seen from FIG. 4, the data stored on the hard drives
`includes compressed video data 100 and indexed data 102.
`The Video data corresponds to the incoming Streams from all
`16 cameras (if as many as 16 cameras are connected to the
`VR/PC, are in operation, and are selected for either perma
`nent or pre-alarm buffer recording). The video data is
`preferably stored in an audio/video interleave (AVI) format.
`The data corresponding to the Streams of incoming video
`Signals are Stored interleaved together in the form of fixed
`length files 104, of which N files 104 are shown in FIG. 4
`as being recorded on the hard disk. A preferred size for each
`of the files 104 is about 20 megabytes. By dividing up the
`continuous Streams of Video data into files, loSS of data due
`to a drop out or data corruption on the hard disk can be
`limited.
`Even with data compression, the Storage capacity pro
`vided by the files 104 is limited. It is therefore a preferred
`mode of operating the VR/PC that the video data files be
`transferred to a removable Storage medium, Such as a
`magnetic tape, for archival Storage.
`In addition to the quasi-permanent video data files 104,
`there is also Stored on the hard disk Video data maintained
`in a pre-alarm buffer Section of the disk (reference numeral
`106). The pre-alarm buffer 106 preferably stores video data
`corresponding to the incoming video signals from all 16
`cameras in an interleaved fashion and at what is Substan
`tially the full frame rate for the system (e.g., 45 fields per
`Second divided among the 16 cameras). By contrast, it
`should be understood that some or all of the 16 cameras may
`not be currently recorded at all in the quasi-permanent files
`104, or may be stored at a “time lapse' rate that is substan
`tially less frequent than 45/16 fields per second. The pre
`alarm buffer 106 is preferably implemented as a ring buffer
`on the hard disk and may, for example, Store all of the Video
`fields captured at the front end electronics over the past 60
`Seconds. AS in the files 104, the respective signal Streams are
`stored in an interleaved fashion in the pre-alarm buffer 106.
`It should also be understood that at least Some of the 16
`cameras may be placed in an “inactive” mode, Such that not
`even pre-alarm buffering is performed for the Signals gen
`erated from Such cameras. In this case, greater Storage
`bandwidth for each other camera is available in the pre
`alarm buffer.
`Turning now to the indeX data on the hard disk, overall
`indexing information covering all of the files 104 is indi
`cated at reference numeral 108. For each of the N files 104,
`a starting date and time and an ending date and time are
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`5,996,023
`
`6
`provided. An additional, file-specific indeX is provided with
`respect to each one of the individual files 104. This file
`specific index is illustrated at 110 and provides, for each
`field of video data, the date and time at which the field was
`captured, the camera by which the field was captured,
`event-related information, and the offset within the file at
`which the field can be found. AS indicated at reference
`numeral 112, the event information given for a particular
`field may include data indicative of the occurrence of more
`than one type of event at the time that the field was captured.
`The detection of events may be accomplished through alarm
`sensors interfaced to the VR/PC unit, and/or by analysis of
`characteristics of the image Stream. The analysis may have
`occurred either at the time the image Stream was received or
`by playing back the image Stream at a later time. The image
`Stream analysis algorithms used to detect the events may
`return confidence factor values in addition to detecting that
`an event itself has occurred. In Such cases, the data indicat
`ing that an event has been detected may be accompanied by
`the confidence factor provided by the event detection
`algorithm, as indicated at reference numeral 114.
`In a preferred embodiment of the invention, the indexing
`information 102 is stored on the same hard disk with the
`associated video data files 100, and the indexing information
`is also Stored on a Second hard disk. The Second hard disk
`may then be accessed in order to Search for the locations on
`the first hard disk of video data that is of interest to the user,
`while access to the first hard disk for the purpose of Storing
`new video data thereon continues without interruption for
`indeX Searching. In one embodiment of the invention, two
`hard disks are provided, of which one is used for Video data
`Storage (and associated indexing) while the other hard disk
`is not used for video data storage, but rather is dedicated to
`backup or “shadow' indeX information and Storage of pro
`grams or the like. In another embodiment of the invention,
`three or more hard disk drives are provided. In the latter
`embodiment, one of the hard drives is dedicated to the
`Shadow indeX and program information Storage, and the
`other two or more hard disks are available for video data
`Storage.
`There will now be described an alarm handler Software
`component which controls operation of the microprocessor
`44 (FIG. 2) in connection with responding to detection of
`alarm conditions. The alarm handler Software component is
`illustrated in flow-chart form in FIG. 5. For the purposes of
`FIG. 5, it is assumed that an alarm message has been
`received by the microprocessor 44 from the front end
`electronics 42. It is then determined, at step 120, whether a
`user of the VR/PC unit has elected to have alarms handled
`according to a Standard protocol or a custom protocol. If a
`Standard protocol has been Selected, then Step 122 follows
`step 120. At step 122, one or more predetermined “alarm
`out' signals are generated according to the type of alarm
`message that was received. For example, the "alarm out”
`Signal or Signals may automatically close or lock doors,
`actuate Sirens or visible alarm indications, or the like.
`Following Step 122 is Step 124, at which a message is
`generated to cause the front end electronicS 42 to change the
`Sequence in which the Video Signal fields are captured from
`the respective cameras attached to the VR/PC unit. For
`example, cameras expected to produce images relevant to
`the alarm condition may be added to the Sequence of
`cameras Selected for recording, or may have their share of
`the recording bandwidth increased.
`The next step is step 126, at which it is determined
`whether the VR/PC unit is being operated in a pre-alarm
`buffering mode. If so, then step 128 follows step 126. In step
`
`

`

`7
`128, a Software message is dispatched to instruct a Video
`Storage Software component to capture for permanent Stor
`age relevant data in the pre-alarm buffer, as will be described
`in more detail below.
`Following step 128 is step 130 (which directly follows
`step 126 if the VR/PC is not being operated in a pre-alarm
`buffering mode). At step 130, the alarm timer is set (or
`extended, if an alarm condition is already in effect), and the
`detected alarm event is added to a list of alarm events
`maintained by the microprocessor 44.
`Step 132 follows step 130. Step 132 indicates that the
`recording Sequence established at Step 124 is maintained
`until the alarm timer times out. The determination as to
`whether the last alarm has timed out is made at Step 134, and
`if this occurs, the alarm timer is shut down (step 136).
`If at step 120 it was determined that a custom alarm
`handling mode is in effect, then step 138 follows step 120.
`At Step 138, the determination is made as to the camera, type
`of event and the time of occurrence relative to the alarm
`condition which has been detected. There follows step 140,
`at which the relevant camera, event type and time data are
`used to fetch the appropriate event response Script from an
`event response script database 142. Following step 140 is a
`Software loop, indicated at Step 144, which is carried out for
`each command in the retrieved event response Script. The
`loop is made up of steps 146, 148 and 150. At step 146, the
`command corresponding to the present line in the Script is
`read. At Step 148, a message corresponding to the command
`is encoded, and at Step 150 the message is Sent to a System
`director Software component, which functions as a message
`clearing house for the Software which programs the micro
`processor 44. It will be understood that the command
`messages Sent to the System director Software component
`will trigger appropriate responses in other Software compo
`nents which control operation of the microprocessor 44.
`An example of a typical event response Script follows:
`
`Event Response Script (Example)
`
`ALARM1 OUT = ON
`ALARM2 OUT = ON
`CAMERA1RATE = 30
`CAMERA1 = ON
`WAIT = 30
`RESUME
`
`(1)
`(2)
`(3)
`(4)
`(5)
`(6)
`
`It will be observed that the exemplary event response
`script set forth above consists of six lines. The first line
`indicates that the alarm 1 output signal is to be turned on.
`This may be, for example, a signal to actuate a visual alarm
`indicator Such as a flashing light. The Second line indicates
`that the alarm 2 output signal is to be turned on. This may
`operate, for example, an audible alarm indicator, Such as a
`Siren.
`The third line indicates that the rate at which fields from
`camera 1 are to be captured for recording is set to 30 fields
`per Second. The remaining recording bandwidth will then be
`allocated among other cameras which had previously been
`Sequenced for recording.
`The fourth line indicates that recording Status for camera
`1 is to be set to “on”. This command would override any
`previous command that had Software-disabled camera 1.
`The fifth command indicates that the status defined by the
`first four lines of the response Script is to be maintained for
`30 seconds.
`The sixth and final line of the script indicates that the prior
`operating Status of the System is to resume after the
`30-second alarm response.
`
`5,996,023
`
`8
`The exemplary event response Script shown above con
`tains no commands in regard to Video data that has been
`pre-alarm buffered, but it will be appreciated that the script
`may include commands to Secure for permanent Storage
`relevant Video data in the pre-alarm buffer, as discussed
`above in connection with step 128.
`The above-mentioned Video Storage Software component
`will now be described. The video storage software compo
`nent performs the functions of managing pre-alarm video
`data buffering on the hard disk or disks, Storing incoming
`Video Streams on the hard disk, and indexing the Stored
`video data on the hard disk. The video data format on the
`disk was described above, in connection with FIG. 4.
`The Video Storage Software component is illustrated in
`flow-chart form on FIG. 6. Initially, it is determined at step
`200 whether the video storage software component is now
`engaged in the pre-alarm buffer management portion of its
`function or the function of Storing incoming Video data for
`quasi-permanent recording (represented by block 202). For
`the sake of the further discussion, it will be assumed that the
`Video Storage Software component is engaged in pre-alarm
`buffer management. In this case, it is determined, as repre
`Sented at decision Step 204, whether an alarm condition has
`been detected. If not, the next "chunk” of video data to be
`Stored in the pre-alarm buffer is placed at the next Storage
`location in the portion of the hard disk utilized as a ring
`buffer for pre-alarm storage (step 206; it will be recalled that
`the pre-alarm buffer portion of the hard disk’s Space was
`indicated by reference numeral 106 in FIG. 4; it should also
`be understood that a “chunk” of video data corresponds to a
`quantity of data that is conveniently handled and buffered in
`preparation for writing the data onto the hard disk). After
`step 206, it is determined whether the end of the ring buffer
`portion 106 of the hard disk has been reached (step 208). If
`So, the pointer indicative of the next Storage location in the
`ring buffer 106 is moved to the front of the ring buffer (step
`210). Otherwise, the pointer is simply moved to the next
`storage location in the ring buffer 106 (step 212).
`If at step 204 an alarm condition was found to have been
`detected, then step 214 follows step 204. Step 214 represents
`a decision point in the Video storage Software component, at
`which a Selection is made between alternative processes for
`preventing Video data Stored in the pre-alarm buffer from
`being overwr