CN116684660B - IP camera takeover method, device, network video recorder and storage medium - Google Patents

IP camera takeover method, device, network video recorder and storage medium Download PDF

Info

Publication number
CN116684660B
CN116684660B CN202310967719.1A CN202310967719A CN116684660B CN 116684660 B CN116684660 B CN 116684660B CN 202310967719 A CN202310967719 A CN 202310967719A CN 116684660 B CN116684660 B CN 116684660B
Authority
CN
China
Prior art keywords
nvr
camera
cameras
taken over
fault
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202310967719.1A
Other languages
Chinese (zh)
Other versions
CN116684660A (en
Inventor
汤杰皓
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shenzhen Fanlian Information Technology Co ltd
Original Assignee
Shenzhen Fanlian Information Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shenzhen Fanlian Information Technology Co ltd filed Critical Shenzhen Fanlian Information Technology Co ltd
Priority to CN202310967719.1A priority Critical patent/CN116684660B/en
Publication of CN116684660A publication Critical patent/CN116684660A/en
Application granted granted Critical
Publication of CN116684660B publication Critical patent/CN116684660B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/232—Content retrieval operation locally within server, e.g. reading video streams from disk arrays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
    • H04N21/25808—Management of client data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26208—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44231—Monitoring of peripheral device or external card, e.g. to detect processing problems in a handheld device or the failure of an external recording device
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Graphics (AREA)
  • Automation & Control Theory (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Closed-Circuit Television Systems (AREA)

Abstract

The embodiment of the application provides an IP camera take-over method, an IP camera take-over device, a network video recorder and a storage medium, and relates to the technical field of video monitoring. Acquiring all IP cameras managed by the fault NVR from a database server; and determining the IP camera to be taken over according to the position of the IP camera in the NVR equipment table. The IP camera self-management is realized through the distributed NVR, and once the NVR fails, the NVR which runs normally automatically acquires the IP camera to be taken over, so that the high reliability and the expandability of the system are ensured.

Description

IP camera takeover method, device, network video recorder and storage medium
Technical Field
The application relates to the technical field of video monitoring, in particular to an IP camera takeover method, an IP camera takeover device, a network video recorder and a storage medium.
Background
The secure storage of video data in video surveillance systems is critical, and currently, video surveillance systems mainly use network video recorders (Network Video Recorder, abbreviated as NVR) to receive, process, record and store data from network cameras (Internet Protocol Camera, abbreviated as IP cameras) or network video streams.
In order to reduce the risk of video stream data loss, a dual active-active NVR architecture design is generally adopted, and all IP cameras in a video monitoring system are allocated to each NVR in a mutually backup mode. After the two NVRs start to operate, each NVR simultaneously receives video stream data of each IP camera and stores the video stream data on a respective hard disk, so that when one NVR fails, the other NVR can normally receive video stream data of all the IP cameras.
Obviously, the video stream data of each IP camera needs to be received and stored by two NVRs on respective hard disks, which leads to increased cost and higher occupation of network bandwidth, thereby affecting the video stream data transmission speed and stability of the IP cameras, and meanwhile, the video stream data is limited by the performance bottleneck of a single NVR device, so that the number of manageable IP cameras is very limited.
Disclosure of Invention
In view of the above, the present application aims to provide an IP camera takeover method, an apparatus, a network video recorder and a storage medium, which implement IP camera self-management by a distributed NVR shared access database server, each NVR managing an IP camera that is not overlapped with each other. Once the NVR fails, the NVR which is in normal operation automatically acquires the IP camera to be taken over through an IP camera dynamic allocation algorithm so as to timely receive and store the audio and video data of the IP camera to be taken over, thereby ensuring high reliability and expandability of the system and further avoiding the occurrence of a central node performance bottleneck.
In order to achieve the above object, the technical scheme adopted by the embodiment of the application is as follows:
in a first aspect, the present application provides an IP camera takeover method, the method comprising:
the NVR sends an update instruction to a database server at regular time according to the update period, so that the database server updates the latest running time corresponding to the NVR in the NVR equipment table according to the current time in the update instruction;
the NVR acquires the NVR equipment list from the database server according to the fault period timing, and determines the fault NVR according to the latest running time and the current time of each NVR in the NVR equipment list;
acquiring all IP cameras managed by the fault NVR from the database server; IP cameras respectively managed by each NVR are not overlapped with each other;
and determining the IP camera to be taken over according to the position of the IP camera to be taken over in the NVR equipment table so as to receive the audio and video data of the IP camera to be taken over.
In an alternative embodiment, the step of determining the failed NVR based on the latest running time and the current time of each NVR in the NVR device table includes:
calculating a difference between the current time and each of the latest running times;
and when the difference value is larger than the take-over time threshold value, determining the corresponding NVR as the fault NVR.
In an alternative embodiment, the step of determining the IP camera to be taken over according to its position in the NVR device table includes:
determining a normal NVR according to the NVR equipment table and the fault NVR;
and determining the IP camera to be taken over according to the positions of the IP camera to be taken over in all the normal NVRs.
In an alternative embodiment, the step of determining the IP camera to be taken over according to its own location in all the normal NVRs includes:
according to an average allocation principle, determining the number of IP cameras to be taken over by each normal NVR according to all IP cameras managed by the normal NVR and the fault NVR;
and determining the IP camera to be taken over according to the positions of the IP camera and the number of the IP cameras in all the normal NVRs.
In an alternative embodiment, the step of determining the IP camera to be taken over according to its own position in all the normal NVRs and the number includes:
and when the IP camera is the normal NVR with the position at the last position, determining all the IP cameras which are not taken over as the IP cameras to be taken over.
In an alternative embodiment, the method further comprises:
each NVR sets the time sent by the third party clock server as the current time.
In a second aspect, the present application provides an IP camera takeover apparatus, the apparatus comprising:
the updating module is used for sending an updating instruction to the database server at regular time according to the updating period so that the database server can update the latest running time corresponding to the NVR in the NVR equipment table according to the current time in the updating instruction;
the take-over module is used for acquiring the NVR equipment list from the database server according to the fault period timing, and determining the fault NVR according to the latest running time and the current time of each NVR in the NVR equipment list; acquiring all IP cameras managed by the fault NVR from the database server; IP cameras respectively managed by each NVR are not overlapped with each other; and determining the IP camera to be taken over according to the position of the IP camera to be taken over in the NVR equipment table so as to receive the audio and video data of the IP camera to be taken over.
In an alternative embodiment, the take-over module is configured to calculate a difference between the current time and each of the latest running times; and when the difference value is larger than the take-over time threshold value, determining the corresponding NVR as the fault NVR.
In a third aspect, the present application provides a network video recorder comprising a processor and a memory, the memory storing machine executable instructions executable by the processor, the processor being executable by the machine executable instructions to implement the IP camera takeover method according to any of the preceding embodiments.
In a fourth aspect, the present application provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements an IP camera takeover method as in any of the preceding embodiments.
Compared with the prior art, the IP camera takeover method, the device, the network video recorder and the storage medium provided by the embodiment of the application have the advantages that the NVR sends the update command to the database server at regular time according to the update period, so that the database server updates the latest operation time corresponding to the NVR in the NVR equipment table according to the current time in the update command, thereby indicating that the NVR operates normally, and once the latest operation time is not updated, the NVR can be found out to have faults in time. The NVR acquires the NVR equipment list from the database server according to the fault period timing, and determines the fault NVR according to the latest running time and the current time of each NVR in the NVR equipment list. Acquiring all IP cameras managed by the fault NVR from a database server; IP cameras managed by each NVR are not overlapped with each other, so that audio and video data of the IP cameras are ensured to be transmitted once on a network, and network throughput is improved. And determining the IP camera to be taken over according to the position of the IP camera to be taken over in the NVR equipment table so as to receive the audio and video data of the IP camera to be taken over. The application realizes the self-management of the IP cameras through the distributed NVR shared access database server, and each NVR respectively manages the IP cameras which are not overlapped with each other. Once the NVR fails, the NVR which is in normal operation automatically acquires the IP camera to be taken over through an IP camera dynamic allocation algorithm so as to timely receive and store the audio and video data of the IP camera to be taken over, thereby ensuring high reliability and expandability of the system and further avoiding the occurrence of a central node performance bottleneck.
In order to make the above objects, features and advantages of the present application more comprehensible, preferred embodiments accompanied with figures are described in detail below.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the embodiments will be briefly described below, it being understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and other related drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
Fig. 1 shows a schematic diagram of an application scenario of a primary and a secondary NVR in the prior art.
Fig. 2 shows an application scenario schematic diagram provided by the embodiment of the application.
Fig. 3 shows a schematic diagram of an IP camera takeover method according to an embodiment of the present application.
Fig. 4 shows a schematic flow chart of the substep S4 of fig. 3.
Fig. 5 shows a schematic flow chart of the substep of step S42 in fig. 4.
Fig. 6 shows a block schematic diagram of an IP camera takeover device according to an embodiment of the present application.
Fig. 7 is a block diagram of a network video recorder according to an embodiment of the present application.
Icon: 10-a network video recorder; a 20-IP camera; 30-a database server; 110-memory; a 120-processor; 130-a communication module; 200-IP camera take over device; 201-initializing a module; 202-an update module; 203-take over module.
Detailed Description
The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments. The components of the embodiments of the present application generally described and illustrated in the figures herein may be arranged and designed in a wide variety of different configurations.
Thus, the following detailed description of the embodiments of the application, as presented in the figures, is not intended to limit the scope of the application, as claimed, but is merely representative of selected embodiments of the application. All other embodiments, which can be made by a person skilled in the art without making any inventive effort, are intended to be within the scope of the present application.
It is noted that relational terms such as "first" and "second", and the like, are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The network video recorder is a digital video recording device for a video monitoring system, and different from the traditional analog video recorder, the NVR uses a digital signal processing technology to encode and decode video stream signals, so that the network video recorder has higher image quality and flexibility. The video streaming system is usually used together with an IP camera and other network equipment, and can realize real-time monitoring, recording, playback and remote access of video streaming.
The most important function of each NVR is to receive the audio and video data of the IP camera through a standard network transmission protocol, store and forward the audio and video data. The method can be widely compatible with the coding formats of different devices of various factories and applied to a video monitoring system, thereby realizing the advantages of distributed architecture and modular access brought by networking.
In order to improve the reliability of audio and video data of the IP cameras, a dual active NVR architecture is generally adopted, as shown in fig. 1, a video monitoring system includes two NVRs with the same configuration as a main NVR and a standby NVR, the main and standby NVRs and a plurality of IP cameras are connected into the same IP network, and each NVR is connected with each other through the IP network and each IP camera. The administrator configures the information such as the IP address of each IP camera and the real-time streaming protocol (Real Time Streaming Protocol, abbreviated as RTSP) pull stream address through the front end, and saves the information in the database table. Each NVR queries the database table at normal run time. If the configuration information of the IP cameras changes, the configuration information of the IP cameras locally cached by the NVR is updated in time, and each NVR receives the audio and video data of each IP camera through the RTSP streaming address of each IP camera.
Once the main NVR or the standby NVR fails, the other NVR can still receive the audio and video data sent by all the IP cameras, and the video monitoring system is kept in a usable state. However, because two devices are used to store the audio and video data of the same batch of IP cameras, that is, the audio and video data of each IP camera needs to be transmitted twice in the IP network, and the audio and video data is transmitted to the main NVR and the standby NVR respectively, compared with the case that the NVR receives the audio and video data of different IP cameras, the audio and video data of different IP cameras occupies more than 1 time of bandwidth, thereby resulting in increased use cost of the video monitoring system and higher network bandwidth occupation, and meanwhile, the configuration performance of a single NVR directly affects the number of supportable IP cameras.
Based on the above, the embodiment of the application provides an IP camera taking over method, an IP camera taking over device, a network video recorder and a storage medium, the IP camera self-management is realized through a distributed NVR shared access database server, and each NVR respectively manages IP cameras which are not overlapped with each other. Once the NVR fails, the NVR which is in normal operation automatically acquires the IP camera to be taken over through the dynamic allocation algorithm of the IP camera without depending on redundant NVR, so that the audio and video data of the IP camera to be taken over are timely received and stored, the high reliability and the expandability of the system are ensured, and the performance bottleneck of a central node is further avoided.
Referring to fig. 2, fig. 2 shows a schematic view of an application scenario suitable for use in an embodiment of the present application. In fig. 2, the video surveillance system includes a plurality of NVRs 10, a plurality of IP cameras 20, and a database server 30, each of which is communicatively connected to at least one IP camera 20 via an IP network, and to the database server 30. Each NVR10 is configured to receive and store audio/video data sent by the managed IP camera 20, and the NVR10 executes steps S1 to S4 and corresponding sub-steps in the following examples at regular time, so as to achieve corresponding technical effects. The IP camera 20 is configured to receive an instruction from the NVR10 to acquire audio and video data, and send the audio and video data to the NVR10 according to the instruction. The database server 30 is used to store NVR device tables, IP camera device tables, and device association tables, and to process operations from the NVR10.
Embodiments of the present application will be described in detail below with reference to the accompanying drawings.
Fig. 3 is a schematic diagram of an IP camera takeover method according to an embodiment of the present application, where an execution subject of the method may be one of the network video recorders described above, referring to fig. 3, and the method includes the following steps:
and step S1, the NVR sends an update instruction to the database server at regular time according to the update period, so that the database server updates the latest running time corresponding to the NVR in the NVR equipment table according to the current time in the update instruction.
When an administrator configures the video monitoring system, a uniformly addressed NVR identifier and an IP address are allocated to each NVR, and a uniformly addressed IP camera identifier and an IP address are allocated to each IP camera. And distributing all IP cameras to each NVR according to the NVR service capability or according to an average distribution principle, wherein each NVR manages a part of IP cameras, and the IP cameras respectively managed by the NVRs are not overlapped with each other. And finally, creating an NVR equipment table, an IP camera equipment table and an equipment association table on the database server.
The NVR equipment table is used for recording NVR identification, NVR IP address and latest running time of each NVR, the IP camera equipment table is used for recording IP camera identification, IP camera IP address and RTSP streaming address of each IP camera, and the equipment association table is used for recording the corresponding relation between the NVR identification and the IP camera identification.
In the embodiment of the application, each NVR sends an update instruction to the database server according to the update period, wherein the update instruction comprises an NVR identifier and the current time. The database server manages NVR information for all NVRs using the NVR device table, wherein the NVR information comprises an NVR identification, an NVR IP address, and a latest runtime. And the database server determines target NVR information matched with the NVR identification from the NVR equipment table according to the NVR identification in the received updating instruction, and updates the latest running time of the target NVR information to the current time in the updating instruction.
It should be noted that the preset update period of each NVR is the same, for example, 1 second, so that the latest running time of each NVR is guaranteed to be updated in time, which indicates that the NVR is operating normally. The NVR identifier and the IP camera identifier may be IDs or names, and the present application is not limited thereto. The following description will be made with the ID as the NVR identifier and the IP camera identifier, the NVR device table is shown in table 1, the IP camera device table is shown in table 2, and the device association table is shown in table 3.
TABLE 1
TABLE 2
TABLE 3 Table 3
And S2, the NVR acquires an NVR equipment list from the database server according to the fault period timing, and determines the fault NVR according to the latest running time and the current time of each NVR in the NVR equipment list.
In the embodiment of the application, the preset fault period of each NVR is the same, each NVR acquires the NVR equipment list from the database server at the same time according to the fault period, acquires the current time on the NVR and the latest running time of each NVR in the NVR equipment list, and determines the fault NVR according to each latest running time and the current time. Wherein a failed NVR characterizes an NVR whose operation has failed.
It should be noted that, the update period and the failure period may be preset by an administrator through an interactive interface or a third party server. The update period is smaller than the fault period, so that the NVR fault condition can be accurately monitored.
S3, acquiring all IP cameras managed by the fault NVR from a database server; the IP cameras each NVR manages are not coincident with each other.
When the NVR fails (e.g., is down or shut down), the failed NVR will not be able to receive the audio and video data of the IP cameras managed by itself, which then become non-primary IP cameras that other NVRs operating normally will automatically take over.
In the embodiment of the application, an NVR sends an IP camera query instruction to a database server, the IP camera query instruction comprises a fault NVR identifier, the database server determines a target IP camera identifier managed by the fault NVR according to the received fault NVR identifier and an equipment association table, then determines a target IP camera IP and a target RTSP pulling address according to the target IP camera identifier and an IP camera equipment table, the database server sends the target IP camera IP and the target RTSP pulling address to each NVR, and the NVR determines all IP cameras managed by the fault NVR according to the target IP camera IP and the target RTSP pulling address.
Because each NVR manages a part of IP cameras and the managed IP cameras are not overlapped with each other, only one NVR of the audio and video data of each IP camera can be guaranteed to be in a stream receiving state, and the audio and video data of the IP camera can be guaranteed to be stored only on the NVR in the stream receiving state.
And S4, determining the IP camera to be taken over according to the position of the IP camera to be taken over in the NVR equipment table so as to receive the audio and video data of the IP camera to be taken over.
In the embodiment of the application, the NVR identifiers in the NVR equipment table can be sequenced according to the size sequence, and the position of the NVR identifiers in the NVR equipment table is determined to determine the IP camera to be taken over, so that the NVR can timely receive the audio and video data of the managed IP camera and the IP camera to be taken over, and the interruption of the data storage of the IP camera managed by the NVR with faults is avoided.
It should be noted that, the NVR acquires the NVR device table from the database server at regular time according to the failure period to determine whether there is a failure NVR, if there is a failure NVR, acquires the IP cameras managed by itself while acquiring all the IP cameras managed by the failure NVR, and receives the IP cameras managed by itself and the audio/video data of the camera to be taken over until the next failure period dynamically allocates the IP cameras as required; if no fault NVR exists, the IP camera managed by the database server is obtained, and the audio and video data of the IP camera managed by the database server is received until the IP camera is dynamically allocated as required in the next fault period.
In summary, according to the IP camera takeover method provided by the embodiment of the present application, the NVR sends the update command to the database server at regular time according to the update period, so that the database server updates the latest running time corresponding to the NVR in the NVR device table according to the current time in the update command, thereby indicating that the NVR is running normally, and once the latest running time is not updated, the NVR can be found out that a fault occurs in time. The NVR acquires the NVR equipment list from the database server according to the fault period timing, and determines the fault NVR according to the latest running time and the current time of each NVR in the NVR equipment list. Acquiring all IP cameras managed by the fault NVR from a database server; IP cameras managed by each NVR are not overlapped with each other, so that audio and video data of the IP cameras are ensured to be transmitted once on a network, and network throughput is improved. And determining the IP camera to be taken over according to the position of the IP camera to be taken over in the NVR equipment table so as to receive the audio and video data of the IP camera to be taken over. The application realizes the self-management of the IP cameras through the distributed NVR shared access database server, and each NVR respectively manages the IP cameras which are not overlapped with each other. Once the NVR fails, the NVR which is in normal operation automatically acquires the IP camera to be taken over through an IP camera dynamic allocation algorithm so as to timely receive and store the audio and video data of the IP camera to be taken over, thereby ensuring high reliability and expandability of the system and further avoiding the occurrence of a central node performance bottleneck.
Optionally, in practical application, once the latest running time of the NVR is not updated in time, it is indicated that the NVR may fail, and the audio and video data of the IP camera cannot be received normally. Referring to fig. 3, the determining a faulty NVR in step S2 according to the latest running time and the current time of each NVR in the NVR device table may include:
calculating the difference between the current time and each latest running time; when the difference is greater than the take over time threshold, the corresponding NVR is determined to be a failed NVR.
In the embodiment of the application, since each NVR periodically updates the local current time to the latest running time corresponding to the NVR in the NVR equipment table, whether the latest running time is updated in time or not can be judged according to the difference value between the current time and the latest operation time of each NVR, and when the difference value is larger than the take-over time threshold, the fact that the corresponding NVR fails to update the latest running time in time is indicated, and the corresponding NVR has failed and is taken as the failed NVR.
Optionally, in practical application, when an NVR in the video monitoring system fails, the NVR that operates normally needs to take over the IP cameras managed by the failed NVR, so as to ensure that the audio and video data of all the IP cameras are received and stored normally. Referring to fig. 4, the determining the sub-step of the IP camera to be taken over according to the position of the IP camera in the NVR device table in step S4 may include:
step S41, determining normal NVR according to the NVR equipment list and the fault NVR;
in the embodiment of the application, the NVR identifiers in normal operation are screened out through all the NVR identifiers and the fault NVR identifiers in the NVR equipment table, and the NVR corresponding to the NVR identifiers in normal operation is used as the normal NVR.
Step S42, determining the IP camera to be taken over according to the positions of the IP camera in all normal NVRs.
In the embodiment of the application, each normal NVR judges the position of the normal NVR in all normal NVRs, and then determines the IP camera managed by the fault NVR which needs to be taken over by the normal NVR according to the position.
When there are a plurality of faulty NVRs, the IP cameras managed by all the faulty NVRs are collected and then reassigned, and the specific manner of collection is not limited to the present application, as long as the same manner of collection is used for each of the NVRs.
Alternatively, in practical applications, tasks are typically allocated dynamically according to device traffic capabilities or according to an average allocation principle. Referring to fig. 5, the substeps of step S42 may include:
step S421, according to the average allocation principle, determining the number of IP cameras required to be taken over by each normal NVR according to all IP cameras managed by the normal NVR and the fault NVR;
as an implementation manner, assuming that the number of NVRs (i.e., normal NVRs) that query the NVR device table to obtain normal operation is m, all IP cameras managed by the query-associated device table to obtain the failed NVR are n, where m and n are both greater than 0. According to the average allocation principle, the number of the IP cameras to be taken over by each normal NVR is m/n, and when m/n is not an integer, the number of the IP cameras to be taken over by each normal NVR is calculated in a downward rounding or upward rounding mode.
It should be noted that if m/n is smaller than 1, the number of IP cameras to be taken over is set to 1.
Step S422, according to the positions and the number of the self-bodies in all normal NVRs, the IP camera to be taken over is determined.
In the embodiment of the application, the IP cameras to be taken over are determined according to the positions of the IP cameras in all normal NVRs and the number of the IP cameras to be taken over. For example, 2 normal NVRs, for which 10 IP cameras are required to take over, each normal NVR needs to take over 5 IP cameras. The first normal NVR takes over the first 5 IP cameras and the second normal NVR takes over the last 5 IP cameras.
Alternatively, in practical applications, the IP cameras may or may not be equally distributed by the normal NVR. Referring to fig. 5, the substeps of step S422 may include:
when the position is the last normal NVR, all the IP cameras which are not taken over are determined to be the IP cameras to be taken over.
In the embodiment of the application, when the IP cameras needing to be taken over cannot be just equally distributed by the normal NVR, the number of the IP cameras needing to be taken over by each normal NVR can be calculated by rounding up or rounding down, other normal nodes except the last normal NVR take over the IP cameras according to the calculated number sequence, and finally all the IP cameras which are not taken over are dynamically distributed to the last normal NVR.
When the fault NVR resumes normal operation, the fault NVR updates the latest operation time to the database server according to the update period, and when the other normal NVRs in the next fault period judge the fault NVR according to the latest operation time of each NVR, the fault NVR is judged to be the normal NVR because the latest operation time is updated, the IP camera taken over before will not continue to take over, and the NVR resuming normal operation continues to manage the IP camera of the IP camera to receive and store the audio and video data of the IP camera, thereby ensuring that the audio and video data storage of the IP camera is not interrupted.
Optionally, in practical application, in order to accurately determine whether an NVR fails, the current running time of the system of each NVR needs to be set synchronously. The IP camera takeover method provided by the embodiment of the application further comprises the following steps:
each NVR sets the time of the third party clock server transmission as the current time.
When an administrator installs the video monitoring system, a time synchronization task is started through an installation tool, the installation tool records the IP addresses of a third-party clock server, all NVRs, all IP cameras and a database server, the timing synchronization task sends a synchronization instruction to the third-party clock server, the synchronization instruction comprises the IP addresses of all NVRs, all IP cameras and the database server, the third-party clock server sends time to be synchronized to all NVRs, all IP cameras and the database server according to each IP address, and all NVRs, all IP cameras and the database server set the received time to be synchronized as the current time so as to ensure time synchronization of all NVRs, all IP cameras and the database server, further monitor fault NVRs more accurately and avoid audio and video data storage interruption of the IP cameras as much as possible.
In the normal running process of the video monitoring system, all NVRs, all IP cameras and the database server can acquire time to the third-party clock server at regular time to update the current time of the video monitoring system, or the third-party clock server synchronously updates the current time to all NVRs, all IP cameras and the database server at regular time so as to correct the current time deviation of each device at any time.
Based on the same inventive concept, the embodiment of the application also provides an IP camera take-over device. The basic principle and the technical effects are the same as those of the above embodiments, and for brevity, reference is made to the corresponding matters in the above embodiments where the description of the present embodiment is omitted.
Referring to fig. 6, fig. 6 is a block diagram illustrating an IP camera takeover apparatus 200 according to an embodiment of the present application. The IP camera takeover apparatus 200 comprises an update module 202 and a takeover module 203.
The update module 202 is configured to send an update instruction to the database server at regular time according to an update period, so that the database server updates the latest running time corresponding to the NVR in the NVR device table according to the current time in the update instruction;
the take-over module 203 is configured to obtain an NVR device table from the database server at regular time according to the failure period, and determine a failed NVR according to the latest running time and the current time of each NVR in the NVR device table; acquiring all IP cameras managed by the fault NVR from a database server; IP cameras managed by each NVR are not overlapped with each other; and determining the IP camera to be taken over according to the position of the IP camera to be taken over in the NVR equipment table so as to receive the audio and video data of the IP camera to be taken over.
In summary, the IP camera takeover device provided by the embodiment of the present application includes an update module and a takeover module. The update module is used for sending an update instruction to the database server at regular time according to the update period, so that the database server updates the latest running time corresponding to the NVR in the NVR equipment table according to the current time in the update instruction. The take-over module is used for the NVR to acquire an NVR equipment list from the database server according to the fault period at regular time, and determining the fault NVR according to the latest running time and the current time of each NVR in the NVR equipment list; acquiring all IP cameras managed by the fault NVR from a database server; IP cameras managed by each NVR are not overlapped with each other; and determining the IP camera to be taken over according to the position of the IP camera to be taken over in the NVR equipment table so as to receive the audio and video data of the IP camera to be taken over. The application realizes the self-management of the IP cameras through the distributed NVR shared access database server, and each NVR respectively manages the IP cameras which are not overlapped with each other. Once the NVR fails, the NVR which is in normal operation automatically acquires the IP camera to be taken over through an IP camera dynamic allocation algorithm so as to timely receive and store the audio and video data of the IP camera to be taken over, thereby ensuring high reliability and expandability of the system and further avoiding the occurrence of a central node performance bottleneck.
Optionally, the take-over module 203 is configured to calculate a difference between the current time and each of the latest running times; when the difference is greater than the take over time threshold, the corresponding NVR is determined to be a failed NVR.
Optionally, the take-over module 203 is configured to determine a normal NVR according to the NVR device table and the failed NVR; and determining the IP camera to be taken over according to the positions of the IP camera in all the normal NVRs.
Optionally, the take-over module 203 is configured to determine, according to an average allocation principle, the number of IP cameras that need to be taken over by each normal NVR according to all IP cameras managed by the normal NVR and the failed NVR; and determining the IP camera to be taken over according to the positions and the number of the IP cameras in all the normal NVRs.
Optionally, the takeover module 203 is configured to determine, when the location is itself the last normal NVR, all IP cameras that remain not taken over as IP cameras to be taken over.
Optionally, the IP camera takeover apparatus 200 further includes an initialization module 201, where the initialization module 201 is configured to set, by each NVR, a time sent by the third party clock server as a current time.
Referring to fig. 7, fig. 7 is a block diagram illustrating a network video recorder 10 according to an embodiment of the application. The network video recorder 10 includes a memory 110, a processor 120, and a communication module 130. The memory 110, the processor 120, and the communication module 130 are electrically connected directly or indirectly to each other to realize data transmission or interaction. For example, the components may be electrically connected to each other via one or more communication buses or signal lines.
Wherein the memory 110 is used for storing programs or data. The Memory 110 may be, but is not limited to, random access Memory (Random Access Memory, RAM), read Only Memory (ROM), programmable Read Only Memory (Programmable Read-Only Memory, PROM), erasable Read Only Memory (Erasable Programmable Read-Only Memory, EPROM), electrically erasable Read Only Memory (Electric Erasable Programmable Read-Only Memory, EEPROM), etc.
The processor 120 is used to read/write data or programs stored in the memory 110 and perform corresponding functions. For example, the IP camera takeover method disclosed in the above embodiments may be implemented when the computer program stored in the memory 110 is executed by the processor 120.
The communication module 130 is used for establishing a communication connection between the network video recorder 10 and other communication terminals through a network, and for transceiving data through the network.
It should be understood that the architecture shown in fig. 7 is merely a schematic diagram of the architecture of the network video recorder 10, and that the network video recorder 10 may also include more or fewer components than shown in fig. 7, or have a different configuration than shown in fig. 7. The components shown in fig. 7 may be implemented in hardware, software, or a combination thereof.
Embodiments of the present application also provide a computer-readable storage medium having stored thereon a computer program which, when executed by the processor 120, implements the IP camera takeover method disclosed in the above embodiments.
In the several embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. The apparatus embodiments described above are merely illustrative, for example, of the flowcharts and block diagrams in the figures that illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
In addition, functional modules in the embodiments of the present application may be integrated together to form a single part, or each module may exist alone, or two or more modules may be integrated to form a single part.
The functions, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, comprising several instructions for causing a computer device (which may be a personal computer, a server, a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.
The above description is only of the preferred embodiments of the present application and is not intended to limit the present application, but various modifications and variations can be made to the present application by those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims (10)

1. An IP camera takeover method, the method comprising:
the NVR sends an update instruction to a database server at regular time according to the update period, so that the database server updates the latest running time corresponding to the NVR in the NVR equipment table according to the current time in the update instruction;
the NVR acquires the NVR equipment list from the database server according to the fault period timing, and determines the fault NVR according to the latest running time and the current time of each NVR in the NVR equipment list;
the NVR acquires all IP cameras managed by the fault NVR from the database server; IP cameras respectively managed by each NVR are not overlapped with each other;
and the NVR determines the IP camera to be taken over according to the position of the NVR in the NVR equipment table so as to receive the audio and video data of the IP camera to be taken over.
2. The IP camera takeover method of claim 1, wherein said step of determining a failed NVR based on the latest run time and current time of each NVR in said NVR device table comprises:
calculating a difference between the current time and each of the latest running times;
and when the difference value is larger than the take-over time threshold value, determining the corresponding NVR as the fault NVR.
3. The IP camera takeover method according to claim 1, wherein the step of the NVR determining the IP camera to be taken over according to its position in the NVR device table includes:
the NVR determines normal NVR according to the NVR equipment list and the fault NVR;
and the NVR determines the IP camera to be taken over according to the positions of the NVR in all the normal NVRs.
4. The IP camera takeover method according to claim 3, wherein the step of determining the IP camera to be taken over by the NVR according to its own position in all of the normal NVRs includes:
according to an average allocation principle, the NVR determines the number of IP cameras to be taken over by each normal NVR according to all IP cameras managed by the normal NVR and the fault NVR;
and the NVR determines the IP camera to be taken over according to the positions and the number of the NVR in all the normal NVRs.
5. The IP camera takeover method according to claim 4, wherein the step of determining the IP camera to be taken over by the NVR based on its own position and the number in all of the normal NVRs includes:
and when the NVR is the normal NVR with the last position, determining all the IP cameras which are not taken over as the IP cameras to be taken over by the NVR.
6. The IP camera takeover method of claim 1, further comprising:
each NVR sets the time sent by the third party clock server as the current time.
7. An IP camera takeover device, the device comprising:
the updating module is used for sending an updating instruction to the database server at regular time according to the updating period so that the database server can update the latest running time corresponding to the NVR in the NVR equipment table according to the current time in the updating instruction;
the take-over module is used for acquiring the NVR equipment list from the database server according to the fault period timing, and determining the fault NVR according to the latest running time and the current time of each NVR in the NVR equipment list; the NVR acquires all IP cameras managed by the fault NVR from the database server; IP cameras respectively managed by each NVR are not overlapped with each other; and the NVR determines the IP camera to be taken over according to the position of the NVR in the NVR equipment table so as to receive the audio and video data of the IP camera to be taken over.
8. The IP camera takeover apparatus of claim 7, wherein said takeover module is configured to calculate a difference between said current time and each of said latest run times; and when the difference value is larger than the take-over time threshold value, determining the corresponding NVR as the fault NVR.
9. A network video recorder comprising a processor and a memory, the memory storing machine executable instructions executable by the processor, the processor being executable by the machine executable instructions to implement the IP camera takeover method of any one of claims 1-6.
10. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the IP camera takeover method according to any one of claims 1-6.
CN202310967719.1A 2023-08-03 2023-08-03 IP camera takeover method, device, network video recorder and storage medium Active CN116684660B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310967719.1A CN116684660B (en) 2023-08-03 2023-08-03 IP camera takeover method, device, network video recorder and storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310967719.1A CN116684660B (en) 2023-08-03 2023-08-03 IP camera takeover method, device, network video recorder and storage medium

Publications (2)

Publication Number Publication Date
CN116684660A CN116684660A (en) 2023-09-01
CN116684660B true CN116684660B (en) 2023-10-20

Family

ID=87782258

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310967719.1A Active CN116684660B (en) 2023-08-03 2023-08-03 IP camera takeover method, device, network video recorder and storage medium

Country Status (1)

Country Link
CN (1) CN116684660B (en)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101877783A (en) * 2009-11-06 2010-11-03 北京邦诺存储科技有限公司 Network video recorder cluster video monitoring system and method
CN102984501A (en) * 2012-11-15 2013-03-20 杭州瑞网广通信息技术有限公司 Network video-recording cluster system
CN103856760A (en) * 2014-03-04 2014-06-11 浙江宇视科技有限公司 Longitudinal virtualization device between video surveillance devices
KR101466007B1 (en) * 2014-06-27 2014-12-11 (주)진명아이앤씨 A multiple duplexed network video recorder and the recording method thereof
CN105430327A (en) * 2015-11-05 2016-03-23 成都基业长青科技有限责任公司 NVR cluster backup method and device
KR102108547B1 (en) * 2019-03-28 2020-05-07 주식회사 열림정보기술 NVR backup and recovery system and method at whole subway station

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI504274B (en) * 2013-11-18 2015-10-11 Delta Electronics Inc Network video monitoring system and auto-configuration method for the monitoring system

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101877783A (en) * 2009-11-06 2010-11-03 北京邦诺存储科技有限公司 Network video recorder cluster video monitoring system and method
CN102984501A (en) * 2012-11-15 2013-03-20 杭州瑞网广通信息技术有限公司 Network video-recording cluster system
CN103856760A (en) * 2014-03-04 2014-06-11 浙江宇视科技有限公司 Longitudinal virtualization device between video surveillance devices
KR101466007B1 (en) * 2014-06-27 2014-12-11 (주)진명아이앤씨 A multiple duplexed network video recorder and the recording method thereof
CN105430327A (en) * 2015-11-05 2016-03-23 成都基业长青科技有限责任公司 NVR cluster backup method and device
KR102108547B1 (en) * 2019-03-28 2020-05-07 주식회사 열림정보기술 NVR backup and recovery system and method at whole subway station

Also Published As

Publication number Publication date
CN116684660A (en) 2023-09-01

Similar Documents

Publication Publication Date Title
JP4562196B2 (en) Highly available blade-based distributed computing system
US7590886B2 (en) Method and apparatus for facilitating device redundancy in a fault-tolerant system
US8467303B2 (en) Method and apparatus for preventing network conflict
CN110830283B (en) Fault detection method, device, equipment and system
CN107404394B (en) IPTV system disaster tolerance method and IPTV disaster tolerance system
CN111796959B (en) Self-healing method, device and system for host container
CN105959078B (en) A kind of cluster method for synchronizing time, cluster and clock synchronization system
CN110418154A (en) A kind of multi-medium data method for pushing, apparatus and system
CN103856760A (en) Longitudinal virtualization device between video surveillance devices
CN112887367B (en) Method, system and computer readable medium for realizing high availability of distributed cluster
CN106254814B (en) Conference recovery method, service management center and system
CN114979158A (en) Resource monitoring method, system, equipment and computer readable storage medium
CN104427223A (en) Monitoring camera device and monitoring camera system
CN113489601B (en) Anti-destruction method and device based on autonomous cloud network architecture of video networking
CN108509296B (en) Method and system for processing equipment fault
CN113467953B (en) Service state switching method and device, server and storage medium
CN116684660B (en) IP camera takeover method, device, network video recorder and storage medium
CN116455920A (en) Data storage method, system, computer equipment and storage medium
KR101466007B1 (en) A multiple duplexed network video recorder and the recording method thereof
JP2009282735A (en) Information recording system and information recording method
CN111897657A (en) Remote teaching method, scheduling equipment, server and electronic equipment
CN110830281B (en) Hot standby method and system based on mesh network structure
CN114077409A (en) Screen projection method and device, electronic equipment and computer readable medium
KR102462867B1 (en) NVR(Network Video Recorder) recording failover
CN114390007B (en) Data processing method, device, storage medium and processor

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant