Method and device for awakening network camera and network camera
By obtaining the wake-up reason and matching the wake-up strategy, the wake-up startup of network cameras is optimized, which solves the problem of insufficient response capability caused by the fixed startup strategy in the existing technology, and realizes a more efficient wake-up process and resource management.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-01-29
- Publication Date
- 2026-04-07
AI Technical Summary
Existing low-power network cameras use a fixed startup strategy when waking up, which makes it difficult to meet the actual business needs of various wake-up reasons, resulting in insufficient response capability.
By obtaining the wake-up reason corresponding to the wake-up command, the wake-up strategy that matches it is determined, and the wake-up startup mechanism is optimized by controlling the sequential startup of each module in the network camera according to the wake-up strategy.
It improves the responsiveness and operating efficiency of network cameras under different wake-up reasons, reduces unnecessary resource consumption and power consumption, and shortens the overall wake-up latency.
Smart Images
Figure CN121815071A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of network cameras, and more particularly to a method, apparatus, and network camera for waking up a network camera. Background Technology
[0002] With the rapid development of IoT and smart security technologies, network cameras are gradually evolving towards lower power consumption and longer battery life. In particular, the demand for low-power network cameras is becoming increasingly prominent in battery-powered or power-constrained scenarios.
[0003] Low-power network cameras, by introducing a combined sleep and wake-up mechanism, can significantly extend their service life and effectively reduce the frequency of maintenance and power supply replacements while ensuring normal monitoring functionality. Therefore, optimizing the wake-up mechanism of network cameras while meeting functional requirements has become an important research direction in the design and application of low-power network cameras. Summary of the Invention
[0004] In view of this, this application provides a method, apparatus and network camera for waking up a network camera, so as to optimize the wake-up mechanism of the network camera and improve the response capability of the network camera.
[0005] A first aspect of this application provides a method for waking up a network camera, the method being applied to a network camera, the method comprising:
[0006] In response to the currently detected wake-up command, obtain the wake-up reason corresponding to the wake-up command;
[0007] Based on the wake-up reason, a wake-up strategy matching the wake-up reason is determined; wherein, the wake-up strategy is used to indicate the startup order of each module in the network camera during the wake-up process; different wake-up reasons are matched with different wake-up strategies;
[0008] The network camera's modules are started sequentially according to the startup order indicated by the wake-up strategy.
[0009] A second aspect of this application provides a device for waking up a network camera. The device is applied to a network camera and includes an acquisition module, a processing module, and a control module.
[0010] The acquisition module is used to acquire the wake-up reason corresponding to the currently detected wake-up command in response to the wake-up command.
[0011] The processing module is used to determine a wake-up strategy that matches the wake-up reason based on the wake-up reason; wherein, the wake-up strategy is used to indicate the startup order of each module in the network camera during the wake-up process; different wake-up reasons are matched with different wake-up strategies;
[0012] The control module is used to control the sequential startup of each module in the network camera according to the startup order indicated by the wake-up strategy.
[0013] A third aspect of this application provides a network camera, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of any of the methods provided in the first aspect of this application.
[0014] The method, apparatus, and network camera for waking up a network camera provided in this application obtain the corresponding wake-up reason after detecting a wake-up command, and match the corresponding wake-up strategy according to different wake-up reasons. Then, the startup order of each module in the network camera is finely controlled through the wake-up strategy. In this way, the wake-up process can better meet the actual business needs, reduce unnecessary resource occupation and power consumption, shorten the overall wake-up latency of the network camera, and thus improve the response capability and operating efficiency of the network camera under different wake-up reasons.
[0015] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description
[0016] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:
[0017] Figure 1 A flowchart of an embodiment of the method for waking up a network camera provided in this application;
[0018] Figure 2 A flowchart of Embodiment 2 of the method for waking up a network camera provided in this application;
[0019] Figure 3 A flowchart of Embodiment 3 of the method for waking up a network camera provided in this application;
[0020] Figure 4 A flowchart of Embodiment 4 of the method for waking up a network camera provided in this application;
[0021] Figure 5This is a hardware structure diagram of a network camera containing a device for waking up a network camera, as shown in an exemplary embodiment of this application.
[0022] Figure 6 This is a schematic diagram of the structure of a device for waking up a network camera provided in this application. Detailed Implementation
[0023] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application.
[0024] The terminology used in this application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. The singular forms “a,” “the,” and “the” used herein are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.
[0025] It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."
[0026] In low-power network cameras, the sleep-wake mechanism is a key technology for balancing power consumption and response speed. Regarding wake-up mechanisms, network cameras typically employ a fixed startup strategy, meaning that regardless of the wake-up reason, all modules are started in a preset, uniform order. This makes it difficult to meet the actual business needs arising from various wake-up reasons.
[0027] In view of this, this application provides a method, apparatus and network camera for waking up a network camera, so as to optimize the wake-up mechanism of the network camera and improve the response capability of the network camera.
[0028] The following specific embodiments are given to illustrate the technical solution of this application in detail.
[0029] Figure 1 A flowchart illustrating an embodiment of the method for waking up a network camera provided in this application. Please refer to... Figure 1 The method provided in this embodiment may include:
[0030] S101. In response to the currently detected wake-up command, obtain the wake-up reason corresponding to the wake-up command.
[0031] The method and apparatus for waking up a network camera provided in this application are applied to a low-power network camera that is in a sleep state when idle in order to save power and increase battery life. Furthermore, in the sleep state, it will be woken up when a wake-up command is detected.
[0032] Optionally, in one possible implementation, the wake-up command is generated when any of the following wake-up reasons are detected: a specified event, a streaming command, or a specified key being pressed.
[0033] It should be noted that the specific content of the designated event is set according to actual needs, and is not limited in this embodiment. For example, in one embodiment, the designated event may include events triggered by a passive infrared PIR (PIR) sensor, events triggered by an image acquisition module, events triggered by an audio acquisition module, etc. For example, when a PIR sensor detects a change in infrared radiation energy within the monitoring area, and the magnitude or duration of the change meets preset conditions, a corresponding event is generated. As another example, in sleep mode, the image acquisition module acquires video frames at a low frame rate or low resolution, and determines whether motion detection conditions are met based on the differences between adjacent video frames. If motion detection conditions are met, a corresponding video motion detection event is generated. As yet another example, in sleep mode, the audio acquisition module samples ambient sound and performs audio anomaly detection based on sound energy, spectral characteristics, or sound change rate. When an audio anomaly is detected, an audio anomaly event is generated.
[0034] Furthermore, the streaming command can be from either the client or the server. Additionally, which specific button is designated is determined based on actual needs, and this embodiment does not limit this. For example, in one possible implementation, the designated button could be a call button or a reset button.
[0035] It is understandable that when a network camera generates a wake-up command, it records the triggering reason corresponding to that command, i.e., it records the corresponding wake-up reason. In this step, when a wake-up command is detected, the wake-up reason corresponding to that command is obtained. For example, in one embodiment, the obtained wake-up reason is a streaming command.
[0036] S102. Based on the wake-up reason, determine a wake-up strategy that matches the wake-up reason; wherein, the wake-up strategy is used to indicate the startup order of each module in the network camera during the wake-up process; different wake-up reasons are matched with different wake-up strategies.
[0037] It should be noted that network cameras typically include multiple modules, which work together to achieve functions such as image acquisition, processing, and storage. In sleep mode, each of these functional modules is either turned off or in a low-power state to varying degrees.
[0038] It is understandable that different wake-up reasons correspond to different business requirements. The method provided in this embodiment determines different wake-up strategies for different wake-up reasons. The wake-up strategy is used to record the startup order of each module during the wake-up process. In this way, under different wake-up reasons, the modules in the network camera are started sequentially according to different startup orders to meet the actual business requirements of each wake-up reason.
[0039] In practice, wake-up strategies can be pre-configured or dynamically generated to match different wake-up reasons. This allows the wake-up strategy to reflect the differences in importance of each module in the corresponding business scenario. In this way, during the wake-up process, each module is instructed to start in sequence according to the startup order that best meets the current needs. This can improve wake-up efficiency and enhance business responsiveness.
[0040] For example, in an event-driven wake-up scenario, the video encoding module and SD card module can be prioritized to ensure that 5 seconds of video before and after the event are completely written to local storage, thus optimizing recording integrity. In a pull-stream command wake-up scenario, the video encoding module, media processing module, and network communication module can be prioritized to shorten the client's first frame display latency to within 500ms, optimizing real-time video quality. As another example, in a button-activated wake-up scenario, the access control module and network communication module are prioritized when a button-activated wake-up call is made, ensuring that the call request is pushed to the client within 200ms; while in a reset button-activated wake-up call, the configuration module is prioritized to immediately restart the system after deleting configuration information, completing the reset operation within 3 seconds.
[0041] Optionally, in one possible implementation, determining a wake-up strategy matching the wake-up reason may include:
[0042] Search for a wake-up strategy that matches the wake-up reason from a pre-established table of correspondences between wake-up reasons and wake-up strategies.
[0043] It should be noted that the pre-established correspondence between wake-up reasons and wake-up strategies is used to record the one-to-one correspondence between wake-up reasons and wake-up strategies. The wake-up strategy corresponding to each wake-up reason records the startup order of each module in the network camera during the wake-up process. Furthermore, the specific content of the wake-up strategy corresponding to each wake-up reason is set according to actual needs, and is not limited in this embodiment. For example, Table 1 shows a pre-established correspondence between wake-up reasons and wake-up strategies illustrated in an exemplary embodiment of this application:
[0044] Table 1. Pre-established correspondence between wake-up reasons and wake-up strategies
[0045]
[0046] Combining the previous examples, for instance, when the wake-up reason is a streaming command, the wake-up strategy that matches this wake-up reason is determined to be wake-up strategy B.
[0047] It should be noted that by pre-establishing the correspondence between wake-up reasons and wake-up strategies, and directly searching for a matching wake-up strategy from this correspondence after a wake-up reason is detected, dynamic decision-making during each wake-up can be avoided, thereby reducing operational overhead and shortening wake-up response time. Furthermore, pre-configuring appropriate module startup sequences based on different wake-up reasons enhances the determinism and stability of the wake-up process. This not only facilitates fast and reliable wake-up control in resource-constrained low-power network cameras but also optimizes the wake-up mechanism and improves service responsiveness.
[0048] S103. Control each module in the network camera to start sequentially according to the startup order indicated by the wake-up strategy.
[0049] In this step, the various modules are started sequentially according to the startup order indicated by the wake-up strategy. Referring to the example above, when the wake-up reason is a streaming command, this step first controls the video encoding module to start, then the media processing module, then the network communication module, and finally the other modules.
[0050] In one specific implementation, after a module successfully starts, the startup of another module following that module can be further controlled to start sequentially. In another implementation, a module can be started at preset time intervals to start sequentially.
[0051] It should be noted that the preset time interval is set according to actual needs, and is not limited in this embodiment. For example, in one possible implementation, the preset time interval can be 2 seconds.
[0052] In this embodiment, wake-up reason awareness technology is used to achieve intelligent classification of different wake-up reasons, and the wake-up strategy is adaptively adjusted accordingly to ensure rapid response to critical events and improve business responsiveness.
[0053] The method for waking up a network camera provided in this embodiment obtains the corresponding wake-up reason after detecting the wake-up command, matches the corresponding wake-up strategy according to different wake-up reasons, and then performs fine-grained control over the startup order of each module in the network camera through the wake-up strategy. In this way, the wake-up process can better meet the actual business needs, reduce unnecessary resource occupation and power consumption, shorten the overall wake-up latency of the network camera, and thus improve the response capability and operating efficiency of the network camera under different wake-up reasons.
[0054] Figure 2 A flowchart illustrating a second embodiment of the method for waking up a network camera provided in this application. Please refer to... Figure 2 In one possible implementation, based on the above embodiments, determining a wake-up strategy matching the wake-up reason may include:
[0055] S201. For each module in the network camera, determine the priority score of that module under the wake-up reason.
[0056] The priority score for each module under the given wake-up reason is used to characterize the priority at which the module is launched under that wake-up reason. The higher the priority score, the higher the priority, meaning the higher the priority level and the earlier the module is launched.
[0057] Optionally, in one embodiment, the specific implementation process of this step may include:
[0058] (1) Find the target gain coefficient sequence corresponding to the wake-up reason from the pre-established gain coefficient sequence corresponding to each wake-up reason; wherein, the gain coefficient sequence corresponding to each wake-up reason is used to record the gain coefficient of each module in the network camera under the wake-up reason.
[0059] Specifically, the gain coefficient sequence corresponding to each wake-up reason is used to record the gain coefficient of each module in the network camera under that wake-up reason. The gain coefficient sequence includes N elements, where N is the number of modules included in the network camera. Each element corresponds to a module and represents the gain coefficient of that module.
[0060] Specifically, the gain coefficient of a module under the wake-up reason is used to characterize the importance of the module under the wake-up reason. The higher the value, the more important it is and the more it should be started first.
[0061] It should be noted that the pre-established gain coefficient sequence corresponding to each wake-up reason is set according to actual needs, and is not limited in this embodiment. In specific implementation, for a certain wake-up reason, when setting the gain coefficient of each module under that wake-up reason, a reasonable gain coefficient can be assigned to each module according to the importance of each module in the service corresponding to the current wake-up reason and the dependency relationship between each module, so as to reflect its relative importance under the current wake-up reason. Specifically, Table 2 shows the pre-established gain coefficient sequence corresponding to various wake-up reasons in an exemplary embodiment of this application:
[0062] Table 2. Pre-established gain coefficient sequence for each wake-up reason
[0063]
[0064] Referring to the examples shown in Table 2, for instance, when the wake-up reason is specified as a pull stream, the target gain coefficient sequence corresponding to that wake-up reason is determined to be the second set of gain coefficient sequences.
[0065] (2) For each module in the network camera, determine the priority score of the module under the wake-up reason based on the initial weight set for the module in advance and the gain coefficient of the module under the wake-up reason.
[0066] It should be noted that the specific values of the initial weights pre-set for each module are used to characterize the importance of that module in the network camera; the higher the value, the higher its importance in the network camera. The specific values of the initial weights pre-set for each module are determined according to actual needs, and are not limited in this embodiment. In practice, initial weights can be pre-set for each module based on its functional importance and the dependencies between modules. The range of the pre-set initial weights for each module can be [0.3, 0.8].
[0067] Furthermore, in one possible implementation, for each module, the product of the initial weight pre-set for that module and the gain coefficient of that module under that wake-up reason can be determined as the priority score of that module under that wake-up reason.
[0068] Combining the above example, for example, for module 1, the initial weight set for this module is 0.8, and its gain coefficient under the pull command is: gain coefficient 21 of module 1. At this time, its priority score is determined as: priority score of module 1 = gain coefficient 21 of module 1 × 0.8.
[0069] S202. Sort all modules according to the priority score of all modules in the network camera under the wake-up reason and the dependency relationship between the modules in the network camera to obtain the sorting result.
[0070] It should be noted that the dependency relationship between modules refers to the fact that the normal startup of a certain module (denoted as the dependent module) depends on the prior startup of other modules (denoted as the dependent module). Among them, the module that should start before the module that depends on it is denoted as the dependent module, and the module that must wait for the module it depends on to start before it can start is denoted as the dependent module.
[0071] In practice, modules can be sorted from highest to lowest priority based on their priority scores for the given wake-up reason. Furthermore, the initial sorting is adjusted according to the dependencies between modules to obtain the final sorting result.
[0072] It is understandable that the final sorting result satisfies the dependencies between the modules, that is, the module being depended on is placed before the module that depends on it.
[0073] S203. Determine a wake-up strategy that matches the wake-up reason based on the sorting result.
[0074] In practical implementation, the sorting results can be directly stored as a module startup list or array, with each element corresponding to a module in the network camera. The order of the modules in the list is the startup order indicated by the wake-up strategy. Through this wake-up strategy, when the network camera responds to the current wake-up command, it can gradually start each module in the planned order, achieving an efficient, stable, and business-compliant wake-up process.
[0075] The method for waking up a network camera provided in this embodiment determines the priority score of each module in the network camera, and sorts the modules by combining the priority scores of each module and the dependencies between the modules. Based on the sorting results, a wake-up strategy matching the current wake-up reason is determined. This avoids the resource waste or startup conflict problems caused by using a fixed startup order, and enables more flexible and efficient wake-up control in different wake-up scenarios, thereby shortening the overall wake-up latency and improving the network camera's responsiveness to different service requirements.
[0076] Figure 3 The flowchart illustrates a third embodiment of the method for waking up a network camera provided in this application. Please refer to... Figure 3 In one possible implementation, based on the above embodiments, determining the priority score of the module under the wake-up reason may include:
[0077] S301. Search for the target gain coefficient sequence corresponding to each wake-up reason from the pre-established gain coefficient sequence corresponding to each wake-up reason; wherein, the gain coefficient sequence corresponding to each wake-up reason is used to record the gain coefficient of each module in the network camera under the wake-up reason.
[0078] S302. For each module in the network camera, obtain the gain coefficient of that module under the wake-up reason from the target gain coefficient sequence.
[0079] For details on the implementation process and principle of steps S301 and S302, please refer to the description in Embodiment 2, which will not be repeated here.
[0080] S303. Obtain the initial weight of the module, the CPU utilization rate of the module at startup, and the normalized startup time of the module.
[0081] It should be noted that, referring to the description in Embodiment 2, in one possible implementation, the initial weights of each module are pre-set and stored in the network camera. In this step, the initial weights of each module can be directly obtained from the network camera.
[0082] Furthermore, the module startup CPU utilization rate refers to the proportion of the network camera's processor resources occupied by the module during the module startup process. It is used to quantify its resource consumption (prioritizing the startup of modules with lower resource consumption), and it is equal to the difference between the CPU utilization rate after the module starts and the CPU utilization rate before the module starts.
[0083] As described above, it is understandable that in the priority scoring calculation, the CPU utilization rate of a module startup reflects the degree of impact of the module startup on system resources. Modules with high CPU utilization rates can have their priority appropriately reduced to avoid system resource conflicts or blocking the startup of other critical modules.
[0084] Furthermore, the normalized startup time of a module refers to the normalized value of the startup time from the issuance of the startup command to successful startup. In specific implementation, the difference between the maximum startup time of all modules and the actual startup time of the module can be determined, and then the ratio of this difference to the maximum startup time of all modules can be determined as the normalized startup time of the module.
[0085] As described above, it can be understood that the smaller the startup time of a module, the larger its normalized startup time, which is in the range of [0, 1].
[0086] As described above, normalized startup time is used to characterize the startup efficiency of a module; the larger the value, the shorter the startup time and the higher the startup efficiency. In practice, normalized startup time is used as a positive evaluation factor in priority scoring calculations, giving modules with higher startup efficiency higher priority.
[0087] It should be noted that the modules can be started in a test environment to pre-determine and save the CPU utilization and normalized startup time of each module, which can then be directly obtained from the network camera. Alternatively, in one possible implementation, statistics and calculations can be performed based on historical startup data; this embodiment does not limit this approach.
[0088] S304. Based on the module's initial weight, the module's gain coefficient under the wake-up reason, the module's startup CPU utilization, and the module's normalized startup time, determine the module's priority score under the wake-up reason.
[0089] Optionally, in one possible implementation, for the third Each module can have its priority score determined based on the following formula for the wake-up reason:
[0090] ;
[0091] in, Indicates the first Priority rating of each module;
[0092] Indicates the first The specific value of the j-th evaluation indicator of each module; j ranges from 1 to 4, representing 4 evaluation indicators, which are the initial weight of the module, the gain coefficient of the module under the wake-up reason, the startup CPU utilization of the module, and the normalized startup time of the module.
[0093] This represents the weight of the j-th evaluation indicator, which is a preset value.
[0094] It should be noted that the weights of each evaluation indicator are set according to actual needs, and are not limited in this embodiment. For example, in one possible implementation, the weights of each evaluation indicator can be the same or different.
[0095] Optionally, in another possible implementation, determining the priority score of the module under the wake-up reason based on the module's initial weight, the module's gain coefficient under the wake-up reason, the module's startup CPU utilization, and the module's normalized startup time includes:
[0096] (1) Determine the startup efficiency factor of the module based on the startup CPU utilization rate and the normalized startup time of the module.
[0097] In practice, the startup efficiency factor of this module can be calculated using the following formula:
[0098] ;
[0099] in, Indicates the first The startup efficiency factor of each module. For the first CPU utilization during the startup of each module; For the first The normalized startup time of each module, where A is the weight corresponding to the startup CPU utilization rate, and (1-A) is the weight corresponding to the normalized startup time.
[0100] It should be noted that the specific value of A is determined based on actual needs, and is not limited in this embodiment. For example, in one possible implementation, A is 0.3.
[0101] The startup efficiency factor is used to comprehensively quantify the resource consumption and startup latency of a module during startup. In this embodiment, the startup CPU utilization and normalized startup time are assigned corresponding weights, and a weighted summation method is used to calculate the startup efficiency factor of the module. This allows modules with lower startup CPU utilization and shorter startup time to obtain a larger startup efficiency factor. Therefore, in the subsequent priority scoring calculation, the resource friendliness and startup efficiency of the module can be comprehensively considered, thereby prioritizing the startup of modules that have less impact on system resources and can complete startup quickly, reducing overall wake-up latency and improving wake-up efficiency.
[0102] (2) Determine the priority score of the module under the wake-up reason based on the initial weight of the module, the gain coefficient of the module under the wake-up reason, and the startup efficiency factor of the module.
[0103] In a specific implementation, one possible approach is to calculate the priority score of the module under the wake-up reason using the following formula:
[0104] ;
[0105] in, Indicates the first Priority rating of each module;
[0106] For the first The initial weights of each module.
[0107] For the first The gain coefficient of each module under this wake-up reason.
[0108] In another possible implementation, the priority score of the module under the wake-up reason can be calculated according to the following formula:
[0109] ;
[0110] It should be noted that in this embodiment, a startup efficiency factor is first constructed based on the module's startup CPU utilization and normalized startup time. This factor provides a unified measure of the startup efficiency cost of the module, avoiding imbalance caused by directly adding multiple heterogeneous indicators in priority calculation. Furthermore, based on this, the startup efficiency factor is calculated as a whole with the initial weight and the gain coefficient under the corresponding wake-up reason. This introduces constraints on startup efficiency while ensuring business importance and scenario relevance. The priority score reflects both the business value of the module in the current wake-up scenario and the system resource consumption and response time, enabling fine-grained management of the module startup order, reducing instantaneous resource pressure during the wake-up process, and improving overall startup efficiency.
[0111] The method for waking up a network camera provided in this embodiment combines the initial weight of the module, the CPU utilization rate at startup, and the normalized startup time, etc., to comprehensively and quantitatively evaluate the priority score of the module. This avoids the one-sidedness caused by evaluating based on only a single indicator. In this way, the startup priority of each module can be adaptively adjusted under different wake-up reasons, so that key modules are started first, and modules with high resource consumption and low value are delayed or started on demand. This effectively reduces the instantaneous load, shortens the overall wake-up response time, and improves the operating efficiency and response capability of the network camera in multiple scenarios.
[0112] It is understood that, in one possible implementation, the wake-up strategy matching each wake-up reason can be predetermined based on the method provided in Embodiment 2 and / or Embodiment 3, thereby establishing a correspondence between wake-up reasons and wake-up strategies, and then the wake-up command can be responded to based on this correspondence.
[0113] Figure 4 The flowchart below shows a fourth embodiment of the method for waking up a network camera provided in this application. Please refer to... Figure 4 In one possible implementation, based on the above embodiments, the startup CPU utilization rate and normalized startup time of each module are predetermined; the process of determining the startup CPU utilization rate and normalized startup time of each module may include:
[0114] S401. Perform a predicted number of wake-up tests on the network camera, and during each wake-up test, record the first CPU utilization rate of the network camera before each module starts, the second CPU utilization rate of the network camera after each module starts, and the actual startup time of each module.
[0115] Specifically, the CPU usage rate and normalized startup time of each module can be pre-determined and stored in the network camera before it leaves the factory.
[0116] In practice, during a wake-up test, each module can be started sequentially according to the standard startup order. Before starting a certain module, the network camera is made to run stably first to obtain the first CPU usage of the network camera before the module starts. Then, the module is controlled to start, and after the module starts successfully, the second CPU usage of the network camera after the module starts, as well as the actual startup time of the module, are obtained.
[0117] S402. For each wake-up test, based on the first CPU utilization rate of the network camera before each module starts and the second CPU utilization rate of the network camera after each module starts, determine the actual startup CPU utilization rate of each module in this wake-up test.
[0118] As described above, it can be understood that for each module, the actual CPU utilization rate during the wake-up test is equal to the difference between the network camera's second CPU utilization rate after the module starts and the network camera's first CPU utilization rate before the module starts.
[0119] S403. Based on the actual startup time of each module and the maximum value of the actual startup time of all modules, determine the actual normalized startup time of each module in this wake-up test.
[0120] Specifically, the actual normalized startup time for each module in this wake-up test can be calculated using the following formula:
[0121] ;
[0122] in, For the first The actual normalized startup time of each module;
[0123] For the first The actual startup time of each module;
[0124] This represents the maximum actual startup time among all modules.
[0125] S404. The average value of the actual startup CPU utilization rate of each module in the preset number of wake-up tests is determined as the startup CPU utilization rate of each module, and the average value of the actual normalized startup time of each module in the preset number of wake-up tests is determined as the normalized startup time of each module.
[0126] In this step, by averaging the actual startup CPU utilization rates of each module across a preset number of wake-up tests, occasional interference factors in a single test can be effectively eliminated, resulting in a more stable and representative startup CPU utilization rate. Similarly, by averaging the actual normalized startup times of each module across a preset number of wake-up tests, a normalized startup time reflecting the overall startup efficiency level of that module can be obtained. This makes the subsequent priority scoring based on this calculation more accurate and reliable.
[0127] The method provided in this embodiment performs a preset number of wake-up tests on the network camera, and acquires the startup CPU utilization and startup time of each module during the actual startup process. The average of the results from multiple tests is then calculated, which more accurately reflects the true startup characteristics of each module. Compared to single tests or static preset values, this method effectively reduces the impact of occasional fluctuations or abnormal data on module performance evaluation, making the predetermined startup CPU utilization and normalized startup time more representative and reliable. Therefore, the priority score calculated based on these parameters can more accurately reflect the startup priority order of the modules.
[0128] Optionally, in one possible implementation, the method further includes:
[0129] During the process of controlling the sequential startup of each module in the network camera according to the startup order indicated by the wake-up strategy, the real-time startup CPU utilization and real-time normalized startup time of each module are obtained.
[0130] The pre-determined startup CPU utilization of each module is updated based on the real-time startup CPU utilization of each module, and the pre-determined normalized startup time of each module is updated based on the real-time normalized startup time of each module.
[0131] Specifically, during the process of controlling the sequential startup of various modules in the network camera according to the startup order indicated by the wake-up strategy, the CPU utilization rate of the network camera before and after the startup of a certain module, as well as the real-time startup time of that module, can be recorded. Furthermore, the difference between the CPU utilization rate of the network camera after the module starts and the CPU utilization rate before the module starts can be used to determine the real-time startup CPU utilization rate of that module. In addition, the real-time normalized startup time of that module can be determined using the real-time startup time of that module and the maximum real-time startup time of all modules. Referring to the previous description, the real-time normalized startup time is equal to the ratio of the difference between the maximum real-time startup time of all modules and the real-time startup time of that module, to the real-time startup time of that module.
[0132] In this way, we can obtain the real-time CPU utilization rate of each module during the startup process, as well as the real-time normalized startup time.
[0133] After a preset number of startups, the real-time CPU utilization and real-time normalized startup time of each module during the preset number of startups can be obtained. The specific value of the preset number of startups is set according to actual needs; in this embodiment, it is not limited.
[0134] Furthermore, for a specific module, the average value of the real-time CPU utilization rate of the module during a preset number of startup processes is calculated, and the pre-determined startup CPU utilization rate of the module is updated to this average value.
[0135] Similarly, calculate the average of a preset number of normalized startup times for the module during a preset number of startup processes, and update the predetermined normalized startup time of the module to this average value.
[0136] The method provided in this embodiment obtains the real-time startup CPU utilization and real-time normalized startup time of each module during the sequential startup process, and updates the predetermined startup CPU utilization and predetermined normalized startup time based on this. This allows the updated data to better reflect the actual performance characteristics of the network camera under the current operating environment and actual load conditions, which is beneficial to improving the accuracy and reliability of subsequent priority scoring calculations. As a result, the wake-up strategy determined based on the priority scoring can more reasonably reflect the actual startup efficiency of each module, further reducing the overall wake-up latency and improving the operational stability and response performance of the network camera.
[0137] Corresponding to the aforementioned embodiment of a method for waking up a network camera, this application also provides an embodiment of a device for waking up a network camera.
[0138] An embodiment of the device for waking up a network camera disclosed in this application can be applied to a network camera. The device embodiment can be implemented through software, hardware, or a combination of both. Taking software implementation as an example, as a logical device, it is formed by the processor of the network camera loading the corresponding computer program instructions from non-volatile memory into memory for execution. From a hardware perspective, such as... Figure 5 As shown, Figure 5 This is an exemplary embodiment of the hardware structure diagram of a network camera containing a device for waking up the network camera, except... Figure 5 In addition to the processor, memory, network interface, and non-volatile memory shown, the network camera in which the device is located in the embodiment may also include other hardware depending on the actual function of the device, which will not be described in detail here.
[0139] Figure 6 This is a schematic diagram of the structure of an embodiment of the device for waking up a network camera provided in this application. Please refer to... Figure 6 The device provided in this embodiment is applied to a network camera, and includes an acquisition module 610, a processing module 620, and a control module 630; wherein,
[0140] The acquisition module 610 is used to acquire the wake-up reason corresponding to the currently detected wake-up command in response to the wake-up command.
[0141] The processing module 620 is used to determine a wake-up strategy that matches the wake-up reason based on the wake-up reason; wherein, the wake-up strategy is used to indicate the startup order of each module in the network camera during the wake-up process; different wake-up reasons are matched with different wake-up strategies;
[0142] The control module 630 is used to control the sequential startup of each module in the network camera according to the startup order indicated by the wake-up strategy.
[0143] The apparatus of this embodiment can be used to perform... Figure 1 The steps of the method embodiment shown are similar in principle and process, and will not be repeated here.
[0144] Optionally, in one possible implementation, the processing module 620 is specifically used for:
[0145] For each module in the network camera, determine the priority score of that module under the wake-up reason;
[0146] Based on the priority scores of all modules in the network camera under the wake-up reason and the dependencies between the modules in the network camera, all modules are sorted to obtain the sorting result;
[0147] Based on the sorting results, a wake-up strategy matching the wake-up reason is determined.
[0148] Optionally, in one possible implementation, the processing module 620 is specifically used for:
[0149] The target gain coefficient sequence corresponding to each wake-up reason is found from the pre-established gain coefficient sequence corresponding to each wake-up reason; wherein, the gain coefficient sequence corresponding to each wake-up reason is used to record the gain coefficient of each module in the network camera under the wake-up reason;
[0150] For each module in the network camera, the gain coefficient of that module under the wake-up cause is obtained from the target gain coefficient sequence;
[0151] Obtain the initial weight of the module, the CPU utilization rate of the module at startup, and the normalized startup time of the module;
[0152] Based on the module's initial weight, the module's gain coefficient under the wake-up reason, the module's startup CPU utilization, and the module's normalized startup time, the priority score of the module under the wake-up reason is determined.
[0153] Optionally, in one possible implementation, the processing module 620 is specifically used for:
[0154] The startup efficiency factor of the module is determined based on the module's startup CPU utilization and normalized startup time.
[0155] The priority score of a module for a given wake-up reason is determined based on its initial weight, its gain coefficient for that wake-up reason, and its startup efficiency factor.
[0156] Optionally, in one possible implementation, the startup CPU utilization rate and normalized startup time of each module are predetermined; the process of determining the startup CPU utilization rate and normalized startup time of each module includes: performing a predicted number of wake-up tests on the network camera, and recording the first CPU utilization rate of the network camera before each module starts, the second CPU utilization rate of the network camera after each module starts, and the actual startup time of each module during each wake-up test.
[0157] For each wake-up test, the actual startup CPU utilization of each module in the wake-up test is determined based on the first CPU utilization of the network camera before each module starts and the second CPU utilization of the network camera after each module starts.
[0158] Based on the actual startup time of each module and the maximum value of the actual startup time of all modules, determine the actual normalized startup time of each module in this wake-up test.
[0159] The average value of the actual startup CPU utilization rate of each module in the preset number of wake-up tests is determined as the startup CPU utilization rate of each module, and the average value of the actual normalized startup time of each module in the preset number of wake-up tests is determined as the normalized startup time of each module.
[0160] Optionally, in one possible implementation, the processing module 620 is further configured to:
[0161] During the process of controlling the sequential startup of each module in the network camera according to the startup order indicated by the wake-up strategy, the real-time startup CPU utilization and real-time normalized startup time of each module are obtained.
[0162] The pre-determined startup CPU utilization of each module is updated based on the real-time startup CPU utilization of each module, and the pre-determined normalized startup time of each module is updated based on the real-time normalized startup time of each module.
[0163] Optionally, in one possible implementation, the processing module 620 is specifically used to search for a wake-up strategy that matches the wake-up reason from a pre-established correspondence between wake-up reasons and wake-up strategies.
[0164] Please continue to refer to Figure 5 This application also provides a network camera, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of any of the methods provided in the first aspect of this application.
[0165] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.
[0166] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.
[0167] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.
Claims
1. A method for waking up a network camera, characterized in that, The method is applied to a network camera, and the method includes: In response to the currently detected wake-up command, obtain the wake-up reason corresponding to the wake-up command; Based on the wake-up reason, a wake-up strategy matching the wake-up reason is determined; wherein, the wake-up strategy is used to indicate the startup order of each module in the network camera during the wake-up process; different wake-up reasons are matched with different wake-up strategies; The network camera's modules are started sequentially according to the startup order indicated by the wake-up strategy.
2. The method according to claim 1, characterized in that, The step of determining a wake-up strategy matching the wake-up reason includes: For each module in the network camera, determine the priority score of that module under the wake-up reason; Based on the priority scores of all modules in the network camera under the wake-up reason and the dependencies between the modules in the network camera, all modules are sorted to obtain the sorting result; Based on the sorting results, a wake-up strategy matching the wake-up reason is determined.
3. The method according to claim 2, characterized in that, Determining the priority score of the module under the wake-up reason includes: The target gain coefficient sequence corresponding to each wake-up reason is found from the pre-established gain coefficient sequence corresponding to each wake-up reason; wherein, the gain coefficient sequence corresponding to each wake-up reason is used to record the gain coefficient of each module in the network camera under the wake-up reason; For each module in the network camera, obtain the gain coefficient of that module under the wake-up cause from the target gain coefficient sequence; Obtain the initial weight of the module, the CPU utilization rate of the module at startup, and the normalized startup time of the module; Based on the module's initial weight, the module's gain coefficient under the wake-up reason, the module's startup CPU utilization, and the module's normalized startup time, the priority score of the module under the wake-up reason is determined.
4. The method according to claim 3, characterized in that, The priority score of the module under the wake-up reason is determined based on the module's initial weight, the module's gain coefficient under the wake-up reason, the module's startup CPU utilization, and the module's normalized startup time, including: The startup efficiency factor of the module is determined based on the module's startup CPU utilization and normalized startup time. The priority score of a module for a given wake-up reason is determined based on its initial weight, its gain coefficient for that wake-up reason, and its startup efficiency factor.
5. The method according to claim 3 or 4, characterized in that, The startup CPU utilization and normalized startup time of each module are predetermined. The process of determining the startup CPU utilization and normalized startup time of each module includes: performing a predicted number of wake-up tests on the network camera, and recording the first CPU utilization of the network camera before each module starts, the second CPU utilization of the network camera after each module starts, and the actual startup time of each module during each wake-up test. For each wake-up test, the actual startup CPU utilization of each module in the wake-up test is determined based on the first CPU utilization of the network camera before each module starts and the second CPU utilization of the network camera after each module starts. Based on the actual startup time of each module and the maximum value of the actual startup time of all modules, determine the actual normalized startup time of each module in this wake-up test. The average value of the actual startup CPU utilization rate of each module in the preset number of wake-up tests is determined as the startup CPU utilization rate of each module, and the average value of the actual normalized startup time of each module in the preset number of wake-up tests is determined as the normalized startup time of each module.
6. The method according to claim 5, characterized in that, The method further includes: During the process of controlling the sequential startup of each module in the network camera according to the startup order indicated by the wake-up strategy, the real-time startup CPU utilization and real-time normalized startup time of each module are obtained. The pre-determined startup CPU utilization of each module is updated based on the real-time startup CPU utilization of each module, and the pre-determined normalized startup time of each module is updated based on the real-time normalized startup time of each module.
7. The method according to claim 1, characterized in that, The step of determining a wake-up strategy matching the wake-up reason includes: Find the wake-up strategy that matches the wake-up reason from the pre-established correspondence between wake-up reasons and wake-up strategies.
8. The method according to claim 1, characterized in that, The wake-up command is generated when any of the following wake-up reasons are detected: The specified event, the pull command, or the specified key is pressed.
9. A device for waking up a network camera, characterized in that, The device is applied to a network camera, and includes an acquisition module, a processing module, and a control module; wherein... The acquisition module is used to acquire the wake-up reason corresponding to the currently detected wake-up command in response to the wake-up command. The processing module is used to determine a wake-up strategy that matches the wake-up reason based on the wake-up reason; wherein, the wake-up strategy is used to indicate the startup order of each module in the network camera during the wake-up process; different wake-up reasons are matched with different wake-up strategies; The control module is used to control the sequential startup of each module in the network camera according to the startup order indicated by the wake-up strategy.
10. A network camera, characterized in that, The method includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method according to any one of claims 1 to 8.