Method and device for monitoring and guaranteeing in weak network and network outage scenarios, and electronic equipment

Abstract

This disclosure presents a method, device, and electronic equipment for monitoring in scenarios with weak or no network coverage. Because it can monitor the network quality status of the communication link in real time and prioritize independently decodeable segments of the video stream based on the type of events within the video, it enables hierarchical caching and priority-based uploading of video segments. Simultaneously, it completes segment rearrangement and merging in the cloud. Therefore, it can solve the technical problems of inflexible adjustment of transmission strategies due to fixed bitrate push in complex network environments and the inability to prioritize the return of important event video data. This achieves the technical effect of improving the availability and reliability of video surveillance systems in scenarios with insufficient network bandwidth and link fluctuations, ensuring efficient and stable transmission of critical video data.

Description

Technical Field

[0001] This disclosure relates to the field of data processing technology, and in particular to a method, device, and electronic equipment for monitoring in scenarios with weak network conditions or network outages. Background Technology

[0002] Video surveillance, as a core technology for security and intelligent management, is widely used in government and enterprise parks, public safety, and smart cities. With the rapid development of network technology, video surveillance systems have evolved from traditional local storage architectures to distributed architectures of "real-time terminal push + centralized cloud storage." Through the collaborative operation of video encoding, network transmission, and cloud storage, a complete technical system has been built, encompassing video acquisition, encoding and compression, network transmission, and storage and playback.

[0003] In related technologies, video transmission systems directly adopt a fixed bitrate push mode, which makes it impossible to adjust the transmission strategy in a timely manner when network bandwidth is insufficient, packet loss rate increases or link is interrupted. This makes it impossible to guarantee the priority transmission of important event data, which seriously affects the availability and reliability of video surveillance systems in complex network environments. Summary of the Invention

[0004] This disclosure provides a method, device, and electronic equipment for monitoring in scenarios with weak network conditions or network outages.

[0005] According to the first aspect of this disclosure, a method for ensuring monitoring in weak network outage scenarios is provided, comprising:

[0006] Monitor the network quality status of communication links; Based on the monitored network quality status, the acquired video stream is divided into multiple independently decodeable video segments; wherein, each video segment has a priority corresponding to the event type contained within it. The video segments are stored in a local cache according to their priority. The video segments are scheduled to be uploaded to the cloud according to their priority, and the video segments are rearranged and merged to obtain a continuous video stream.

[0007] Optionally, the monitoring of the network quality status of the communication link includes: Collect network parameters of the communication link; wherein, the network parameters include bandwidth, packet loss rate, latency, jitter and link connection status; The network parameters are calculated using a weighted summation method to obtain a network quality score. The network quality score is compared with a first preset threshold and a second preset threshold to determine the current network status; wherein the network status includes one of normal network, weak network, or network outage.

[0008] Optionally, the step of dividing the acquired video stream into multiple independently decodeable video segments based on the monitored network quality status includes: The segment length of the video clip is determined based on the current network quality status; The video stream is segmented using keyframes as the starting frames of the segments, so that each video segment can be decoded independently. Each segmented video fragment is uniquely identified by generating identification information, which includes the timestamp of the acquisition and the terminal name.

[0009] Optionally, before storing the video segments in a local cache according to the priority, the method further includes: When an alarm event is detected during the acquisition of video clips, the video clips are marked as high priority; When an alarm event is detected during the acquisition of a video clip, the video clip is marked as low priority.

[0010] Optionally, storing the video segments in a local cache according to the priority includes: Video segments of different priorities are stored in corresponding local caches; high-priority segments are stored in the first-level cache, low-priority segments are stored in the second-level cache, and segments temporarily stored for real-time transmission are stored in the third-level cache. In response to insufficient cache space, a first-in-first-out (FIFO) eviction policy is executed in the second-level cache and the third-level cache according to the priority and storage time of the video segments.

[0011] Optionally, after storing the video segments in a local cache according to the priority, the method further includes: Establish a first retransmission queue for managing untransmitted high-priority segments and a second retransmission queue for managing untransmitted low-priority segments; Record the transmission progress of each video segment, and after the communication link is restored, continue transmitting the corresponding video segment from the point of interruption according to the transmission progress.

[0012] Optionally, scheduling the upload of the video segments to the cloud based on their priority includes: Monitor the network quality of at least two communication links; When the quality of the currently used communication link is lower than the preset conditions, switch to the available link with the best network quality.

[0013] Optionally, the step of scheduling the video segments to be uploaded to the cloud according to their priority, and rearranging and merging the video segments to obtain a continuous video stream includes: Video clips from the same terminal are sorted according to the timestamp information carried by the video clips in order to correct out-of-order transmission. By merging the sorted segments with consecutive and non-overlapping timestamps, a complete video stream is obtained.

[0014] According to a second aspect of this disclosure, a monitoring protection device is provided for scenarios involving weak network connections or network outages, comprising: The monitoring unit is used to monitor the network quality status of the communication link; The segmentation unit is used to segment the acquired video stream into multiple independently decodeable video segments based on the monitored network quality status; wherein, the video segments have priorities corresponding to the event types contained within the video segments; Storage unit, used to hierarchically store the video segments in local cache according to the priority; The merging unit is used to schedule the video segments to be uploaded to the cloud according to their priority, and to rearrange and merge the video segments to obtain a continuous video stream.

[0015] Optionally, the monitoring unit is further configured to: Collect network parameters of the communication link; wherein, the network parameters include bandwidth, packet loss rate, latency, jitter and link connection status; The network parameters are calculated using a weighted summation method to obtain a network quality score. The network quality score is compared with a first preset threshold and a second preset threshold to determine the current network status; wherein the network status includes one of normal network, weak network, or network outage.

[0016] Optionally, the segmentation unit is further configured to: The segment length of the video clip is determined based on the current network quality status; The video stream is segmented using keyframes as the starting frames of the segments, so that each video segment can be decoded independently. Each segmented video fragment is uniquely identified by generating identification information, which includes the timestamp of the acquisition and the terminal name.

[0017] Optionally, the device further includes: The first marking unit is used to mark a video segment as high priority when an alarm event is detected during the acquisition of a video segment before the storage unit stores the video segments in the local cache according to the priority. The second marking unit is used to mark a video segment as low priority when an alarm event is detected during the acquisition of a video segment.

[0018] Optionally, the storage unit is further used for: Video segments of different priorities are stored in corresponding local caches; high-priority segments are stored in the first-level cache, low-priority segments are stored in the second-level cache, and segments temporarily stored for real-time transmission are stored in the third-level cache. In response to insufficient cache space, a first-in-first-out (FIFO) eviction policy is executed in the second-level cache and the third-level cache according to the priority and storage time of the video segments.

[0019] Optionally, the device further includes: The establishment unit is used to establish a first retransmission queue for managing high-priority segments that have not been transmitted and a second retransmission queue for managing low-priority segments that have not been transmitted, respectively, after the storage unit stores the video segments in local cache according to the priority. The transmission unit is used to record the transmission progress of each video segment. After the communication link is restored, the corresponding video segment is continued to be transmitted from the point of interruption according to the transmission progress.

[0020] Optionally, the merging unit is further configured to: Monitor the network quality of at least two communication links; When the quality of the currently used communication link is lower than the preset conditions, switch to the available link with the best network quality.

[0021] Optionally, the merging unit is further configured to: Video clips from the same terminal are sorted according to the timestamp information carried by the video clips in order to correct out-of-order transmission. By merging the sorted segments with consecutive and non-overlapping timestamps, a complete video stream is obtained.

[0022] According to a third aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method described in the first aspect above.

[0023] According to a fourth aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are configured to cause the computer to perform the method described in the first aspect above.

[0024] According to a fifth aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method described in the first aspect above.

[0025] The monitoring protection method, device, and electronic equipment provided in this disclosure for weak network and network outage scenarios, through this application, can monitor the network quality status of the communication link in real time, and divide the video stream into independently decodeable segments based on the event type in the video, realize hierarchical caching and priority-based scheduling of video segments for uploading, and complete segment rearrangement and merging in the cloud. Therefore, it can solve the technical problems of fixed bitrate push not being able to flexibly adjust the transmission strategy and important event video data not being able to be prioritized for back transmission in complex network environments, and achieve the technical effect of improving the availability and reliability of video surveillance systems in scenarios with insufficient network bandwidth and link fluctuations, and ensuring the efficient and stable transmission of key video data.

[0026] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this application, nor is it intended to limit the scope of this application. Other features of this application will become readily apparent from the following description. Attached Figure Description

[0027] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is a flowchart illustrating a monitoring protection method for weak network outage scenarios provided in this embodiment of the disclosure. Figure 2 A flowchart illustrating a monitoring protection method for weak network outage scenarios provided in this application embodiment; Figure 3 A schematic diagram of a monitoring device for weak network outage scenarios provided in this embodiment of the present disclosure; Figure 4 A schematic diagram of the structure of another monitoring protection device for weak network outage scenarios provided in this embodiment of the disclosure; Figure 5 A schematic block diagram of an example electronic device provided for embodiments of this disclosure. Detailed Implementation

[0028] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0029] The following describes, with reference to the accompanying drawings, a method, apparatus, and electronic device for monitoring in weak network outage scenarios according to embodiments of the present disclosure.

[0030] Figure 1This is a flowchart illustrating a monitoring protection method for weak network outage scenarios provided in this embodiment of the present disclosure.

[0031] like Figure 1 As shown, the method includes the following steps: Step 101: Monitor the network quality status of the communication link; In some embodiments, the monitoring process collects physical layer or transport layer parameters of the link and performs comprehensive quantitative analysis on these parameters based on a preset quality assessment model, thereby abstracting the complex network environment into discrete or continuous network quality levels. The collected parameters include, but are not limited to, indicators reflecting link bandwidth, transmission delay, data packet loss rate, and jitter, as well as link connectivity status. Through continuous or periodic monitoring, the system dynamically identifies whether the current link's network quality is normal, weak, or disconnected, providing an adaptive decision-making basis for subsequent data processing strategies.

[0032] The determination of network quality status directly affects the acquisition, encapsulation, storage, and transmission of video data, and is the foundation for ensuring continuous recording and availability optimization of the entire monitoring system in complex network environments. In some embodiments, parameters such as bandwidth, latency, and packet loss rate can be collected at a fixed frequency on the terminal side, and combined with a weighted calculation model and heartbeat detection mechanism, the network status can be quantified into a score between 0 and 1 to distinguish whether the network is in a normal, weak, or disconnected state.

[0033] Step 102: Based on the monitored network quality status, the acquired video stream is divided into multiple independently decodeable video segments; wherein, each video segment has a priority corresponding to the event type contained within it. In some embodiments, the parameters of the segmentation process, such as the duration or size of each video data unit, are not fixed but are adaptively adjusted according to the current network quality status, aiming to optimize caching efficiency and transmission reliability under weak network or network outage conditions; each generated video data unit is assigned a transmission priority attribute that reflects the importance of its content, and the priority is determined based on whether there are preset key events within the time period covered by the video data unit.

[0034] By identifying the event types associated with video data units, such as alarm events and ordinary surveillance recordings, priority marking is completed at the beginning of data generation, thus providing a basis for subsequent differentiated storage and transmission control.

[0035] As one implementation method, the keyframe alignment principle can be strictly followed when segmenting the video stream to ensure that each segment starts with a keyframe to support independent decoding, and the segment length can be dynamically adjusted according to the network quality, such as the segment being shorter when the network is worse; at the same time, by analyzing the video content or sensor signals in real time, segments containing alarm events such as human intrusion and object movement are marked as high priority, while the rest are marked as low priority.

[0036] Step 103: Store the video segments in a local cache according to their priority levels; The terminal's local cache space is logically divided into at least two storage areas with different storage strategies, each used to store video clips of different priorities. High-priority clips are stored in a storage area that employs a priority retention strategy. This area is designed to maximize the persistence of critical data during local caching, ensuring that its data is significantly less likely to be evicted even when cache resources are scarce compared to ordinary data.

[0037] In some embodiments, low-priority segments are stored in a separate storage area, which may employ a first-in, first-out (FIFO) or other conventional caching management strategy. This hierarchical storage mechanism optimizes the allocation of limited local storage resources, allowing storage space to be allocated and protected differently based on the importance of the video data.

[0038] The capacity of each storage area can be preset or dynamically adjusted based on factors such as network status and remaining terminal storage space. As one implementation method, a three-level cache architecture including temporary cache, priority cache, and ordinary cache can be established on the terminal side. The priority cache is dedicated to storing alarm fragments and adopts a priority eviction policy, while the capacity of each level of cache can be dynamically allocated according to the remaining terminal storage space to balance the retention of critical data and the occupation of system resources.

[0039] Step 104: The video segments are scheduled to be uploaded to the cloud according to their priority, and the video segments are rearranged and merged to obtain a continuous video stream.

[0040] The scheduling process prioritizes higher-priority video segments. That is, with limited backhaul bandwidth resources, a differentiated scheduling strategy is used to ensure that high-priority critical data can get a higher transmission opportunity, thereby reducing its end-to-end transmission latency.

[0041] After the video clips are uploaded to the cloud, the cloud performs rearrangement and merging operations on the received clips. Since the video clips may be out of order or have uneven latency during transmission due to network fluctuations, link switching or the aforementioned differentiated scheduling, the cloud sorts the clips from the same terminal based on the timing identifier information carried by each video clip, such as the acquisition timestamp or sequence number, and restores the out-of-order clips to the correct timing order.

[0042] Based on this, temporally adjacent and content-continuous segments are merged to restore a complete, continuous original video stream for subsequent live distribution or recording storage. As one implementation method, the cloud can maintain a global scheduling queue, prioritizing responses to return requests carrying high-priority identifiers. Upon receiving segments, the cloud sorts them in ascending order based on the capture timestamp in the segment ID, merging consecutive, non-overlapping segments into a complete video stream. Simultaneously, segment IDs are used for deduplication to avoid storing redundant data.

[0043] In some embodiments, monitoring the network quality status of the communication link includes: Collect network parameters of the communication link; wherein, the network parameters include bandwidth, packet loss rate, latency, jitter and link connection status; The network parameters are calculated using a weighted summation method to obtain a network quality score. The network quality score is compared with a first preset threshold and a second preset threshold to determine the current network status; wherein the network status includes one of normal network, weak network, or network outage.

[0044] As a specific implementation method, monitoring the network quality status of the communication link can be achieved by collecting key network parameters in real time on the terminal side and combining them with a weighted summation model. Specifically, the terminal collects the bandwidth, packet loss rate, latency and jitter parameters of the current communication link at a preset period, such as once per second. At the same time, it obtains the link connection status by performing heartbeat detection with the cloud side or gateway, such as once every 3 seconds.

[0045] Based on this, a network quality assessment model is constructed, and a weighted summation method is used to calculate the network quality score. In the process of calculating the network quality score, the various collected parameters are first normalized: the bandwidth score is calculated based on the ratio of the current bandwidth to the minimum bandwidth required for video transmission, and the value ranges from 0 to 1; the packet loss rate score is calculated based on the deviation of the current packet loss rate from the preset packet loss rate threshold, and the score is 0 when the packet loss rate exceeds the threshold; the latency score and jitter score are calculated based on the deviation of the current latency and jitter from their respective preset thresholds, and the score is 0 when the threshold is exceeded; the link connection status score is 1 when the link is connected and 0 when it is disconnected.

[0046] Preset weights are assigned to each score item, with the sum of all weights being 1. A comprehensive network quality score is obtained by weighted summation, with a value ranging from 0 to 1. Finally, this network quality score is compared with a preset first threshold (e.g., 0.8) and a second threshold (e.g., 0.3): when the score is greater than or equal to the first threshold, it is determined to be a normal network; when the score is less than the first threshold but greater than or equal to the second threshold, it is determined to be a weak network; when the score is less than the second threshold, it is determined to be a network outage. Furthermore, the above thresholds and weights can be configured according to actual application scenarios to adapt to evaluation needs in different network environments. It should be noted that this description is merely an illustrative example and is not intended to limit specific values; the embodiments of this application do not impose any limitations on this.

[0047] In some embodiments, dividing the acquired video stream into multiple independently decodeable video segments based on the monitored network quality status includes: The segment length of the video clip is determined based on the current network quality status; The video stream is segmented using keyframes as the starting frames of the segments, so that each video segment can be decoded independently. Each segmented video fragment is uniquely identified by generating identification information, which includes the timestamp of the acquisition and the terminal name.

[0048] As a specific implementation method, the terminal determines the segment length of the video segment based on the current network quality status: when the network status is normal, a larger maximum segment length is used, such as 10 seconds by default; when the network status is weak, a medium segment length is used, such as 5 seconds by default; when the network status is offline, a smaller minimum segment length is used, such as 2 seconds by default.

[0049] Through the above dynamic adjustments, more and shorter video clips can be generated under weak network or network outage conditions, facilitating terminal cache management and subsequent resume downloads, while reducing segmentation overhead under normal network conditions. During the segmentation process, the terminal strictly adheres to the keyframe alignment principle, meaning that the starting frame of each video clip must be a keyframe in the video stream, and the clip ends in the frame preceding the next keyframe.

[0050] If the next keyframe is not encountered when the segment reaches the set segment length, the segment will automatically extend until the next keyframe appears, thus ensuring that each video segment contains a complete group of images from the first keyframe to the next keyframe, which can be independently decoded and played. Each video segment after segmentation is assigned unique identification information, which includes at least the acquisition timestamp (accurate to milliseconds) and the terminal name or identifier, such as a combination of terminal ID + acquisition timestamp + segment sequence number, for subsequent segment matching during cloud reception, progress tracking during breakpoint resume transmission, and timing restoration during rearrangement and merging.

[0051] In some embodiments, before storing the video segments in a local cache according to the priority, the method further includes: When an alarm event is detected during the acquisition of video clips, the video clips are marked as high priority; When an alarm event is detected during the acquisition of a video clip, the video clip is marked as low priority.

[0052] As a specific implementation, the aforementioned video segment priority marking can be achieved based on the real-time detection results of alarm events during the video stream acquisition process on the terminal side. Specifically, the terminal can be configured with various alarm event detection mechanisms, such as collecting environmental data through integrated infrared sensors, sound sensors, and other physical sensors, or performing real-time analysis of the acquired image frames through built-in video analysis algorithms (such as target detection algorithms and motion detection algorithms). When the terminal detects the occurrence of a preset alarm event, such as human intrusion, object movement, or abnormal sound, the system immediately records the trigger timestamp of the alarm event.

[0053] After video segments are segmented, the terminal matches the capture timestamp of each video segment with the timestamp of the alarm event. If the time range covered by a video segment overlaps with the time range of an alarm event, the video segment is marked as high priority, for example, with a priority flag of 1. If the video segment does not overlap with any alarm event, it is marked as low priority, for example, with a priority flag of 0. To ensure complete recording of alarm events, the time range covered by high-priority segments can be configured to include a preset duration before the alarm is triggered (e.g., the first 3 seconds) and a preset duration after the alarm ends (e.g., the last 5 seconds), thus including the complete context of the alarm event in the high-priority category. After the above priority marking is completed, the marking information is stored together with the video segment for subsequent hierarchical caching and transmission scheduling.

[0054] In some embodiments, storing the video segments in a local cache according to the priority includes: Video segments of different priorities are stored in corresponding local caches; high-priority segments are stored in the first-level cache, low-priority segments are stored in the second-level cache, and segments temporarily stored for real-time transmission are stored in the third-level cache. In response to insufficient cache space, a first-in-first-out (FIFO) eviction policy is executed in the second-level cache and the third-level cache according to the priority and storage time of the video segments.

[0055] As a specific implementation method, tiered storage can be achieved by building a three-level cache architecture on the terminal side, where each level of cache adopts a differentiated storage strategy to adapt to the retention requirements of video segments with different priorities.

[0056] Specifically, the terminal logically divides its local storage space into three levels: Level 1 cache, Level 2 cache, and Level 3 cache. The Level 1 cache, as a priority cache, is specifically used to store video segments marked as high priority. This level of cache employs a priority retention strategy to ensure the maximum persistence of critical alarm data. The Level 2 cache, as a general cache, is used to store video segments marked as low priority. The Level 3 cache, as a temporary cache, is used to temporarily store video segments that are currently being acquired but have not yet completed real-time transmission. Data in this level of cache is cleared after real-time transmission is complete.

[0057] In some embodiments, the terminal monitors the remaining capacity of each level of cache in real time and presets the maximum capacity threshold for each level of cache (e.g., the first-level cache is 4GB by default, the second-level cache is 8GB by default, and the third-level cache is 1GB by default), and can dynamically adjust the capacity allocation of each level according to the total remaining storage space of the terminal. When it is detected that the remaining space of the second-level cache or the third-level cache is insufficient to store newly generated video segments, the system triggers a cache eviction operation. Specifically, in the second-level cache and the third-level cache, a first-in, first-out (FIFO) strategy is used for eviction: for the second-level cache, the lowest priority segment with the earliest storage time is evicted first; for the third-level cache, the segment with the earliest storage time that has not yet been transmitted is evicted first.

[0058] If space is still insufficient after eviction, eviction will continue in chronological order until enough space is freed up. It should be noted that high-priority segments in the L1 cache are not affected by this eviction policy. They are only handled by a separately configured priority eviction mechanism in extreme cases, such as deleting the oldest high-priority segment when the L1 cache overflows. However, this situation takes precedence over the regular eviction of the L2 and L3 caches.

[0059] Through the aforementioned three-level caching architecture and differentiated eviction strategy, this method can prioritize the retention and stability of high-priority critical video recording data when terminal storage resources are limited. At the same time, it can manage ordinary video recordings and temporary transmission data in an orderly manner through a first-in-first-out mechanism, effectively avoiding unexpected data loss caused by cache overflow, and realizing the reasonable allocation and efficient utilization of storage resources among data of different priorities.

[0060] In some embodiments, after storing the video segments in a local cache according to the priority, the method further includes: Establish a first retransmission queue for managing untransmitted high-priority segments and a second retransmission queue for managing untransmitted low-priority segments; Record the transmission progress of each video segment, and after the communication link is restored, continue transmitting the corresponding video segment from the point of interruption according to the transmission progress.

[0061] The terminal establishes a first retransmission queue and a second retransmission queue. The first retransmission queue manages all high-priority segments that have not been transmitted, while the second retransmission queue manages all low-priority segments that have not been transmitted. In the first retransmission queue, segments are sorted in ascending order according to their associated alarm trigger timestamps, ensuring that critical segments with earlier alarm occurrence times are retransmitted first. In the second retransmission queue, segments are sorted in ascending order according to their acquisition timestamps, ensuring that ordinary segments with earlier acquisition times are retransmitted first.

[0062] The terminal maintains a transmission progress record for each video segment, which includes at least the number of bytes that have been transmitted and the number of bytes that have not yet been transmitted. During the initial transmission of a segment or subsequent retransmissions, the terminal transmits data on a segment-by-segment basis and updates the transmission progress to the local record in real time.

[0063] When a communication link is detected to have been restored (e.g., from a network outage to a weak or normal network, or a new link becoming available after a multi-link handover), the terminal iterates through the first and second retransmission queues and initiates retransmission requests sequentially according to the queue order. For each segment to be retransmitted, the terminal continues transmitting the remaining data portion from the point of interruption, based on its recorded transmission progress, rather than retransmitting the entire segment.

[0064] When a segment fails to transmit due to network jitter, the segment is added back to the corresponding retransmission queue and retransmitted again in the next round of scheduling according to its priority and transmission progress. For segments with more than a preset threshold of consecutive failures, the key frame data in them is transmitted first to ensure the integrity of the core decoding information.

[0065] In some embodiments, scheduling the upload of the video segments to the cloud according to their priority includes: Monitor the network quality of at least two communication links; When the quality of the currently used communication link is lower than the preset conditions, switch to the available link with the best network quality.

[0066] As a specific implementation method, multi-link intelligent switching can be achieved by simultaneously monitoring the network quality of at least two communication links on the terminal side and combining preset switching conditions with link quality ranking; the terminal is configured with at least two different types of communication links, such as wired links (including broadband and enterprise private lines) and cellular links (including 4G and 5G), and the terminal continuously evaluates the network quality of each link in real time.

[0067] The evaluation process employs the same network quality scoring mechanism as the aforementioned steps. This involves collecting bandwidth, packet loss rate, latency, and jitter parameters for each link, obtaining link connection status through heartbeat detection, and calculating the network quality score for each link using a weighted summation model. The terminal maintains the currently used communication link and continuously monitors its network quality score, as well as changes in the scores of backup links. When the network quality score of the currently used link falls below a preset handover condition—for example, the score drops below the network outage threshold, or it remains in a weak network range for a preset period without improvement—the terminal triggers a link handover operation.

[0068] During the handover process, the terminal first selects the link with the highest network quality score from all available links as the target handover link. Then, the terminal reuses key parameters from the original transmission session, including the playback Uniform Resource Locator (URL), authentication token, and transmission port, without needing to re-trigger the registration process or perform secondary authentication. A session pool is established between the terminal and the cloud to store the complete parameters of currently active sessions. During the handover, the terminal retrieves the original session information from the session pool to quickly establish a transmission connection, and ensures seamless continuity of the live stream through a preset session hold duration. After the handover is complete, the terminal transfers the data transmission channel to the new link and continues to perform subsequent video segment uploads and re-uploads.

[0069] In some embodiments, the step of scheduling the video segments for upload to the cloud according to their priority, and rearranging and merging the video segments to obtain a continuous video stream includes: Video clips from the same terminal are sorted according to the timestamp information carried by the video clips in order to correct out-of-order transmission. By merging the sorted segments with consecutive and non-overlapping timestamps, a complete video stream is obtained.

[0070] As a specific implementation method, the aforementioned rearrangement and merging of video segments on the cloud side can be achieved through a timestamp-based sorting and continuity detection mechanism. Specifically, after receiving the video segments uploaded by the terminal, the cloud first parses the unique identification information carried by each segment, extracting the acquisition timestamp and terminal identifier from it.

[0071] The cloud maintains a cache of unsorted segments for each terminal, using terminal identifiers as the dimension. When a new segment arrives, the cloud inserts it into the cache and sorts all segments from the same terminal in the cache in ascending order based on their acquisition timestamp, thereby correcting the segment out-of-order problem caused by differences in network transmission latency or link switching.

[0072] After sorting, the cloud performs continuity checks on the sorted segment sequence: it checks whether the timestamps of adjacent segments are consecutive, that is, whether there is a time gap or overlap between the end time of the previous segment and the start time of the next segment. If adjacent segments with consecutive timestamps and no overlap are detected, the cloud merges these two segments to form a longer continuous video segment by splicing the video data streams. For segments with overlapping timestamps, the cloud performs deduplication based on the segment identifier, retaining only the complete set of data.

[0073] For segments with time gaps, the cloud will not merge them temporarily, but will retain the gap markers. The segments corresponding to the gaps will be merged later after they are retransmitted.

[0074] The following example illustrates a monitoring protection method for weak network outage scenarios provided by the embodiments of this application.

[0075] Please see Figure 2 , Figure 2 This is a flowchart illustrating a monitoring protection method for weak network outage scenarios provided in an embodiment of this application. Figure 2 As shown, it includes: Step 1: Real-time network quality assessment The terminal side collects key network parameters in real time, constructs a network quality assessment model based on multi-dimensional indicators, and determines the current network status (normal, weak, or out of service), providing a basis for subsequent data processing and transmission strategy adjustments. Please refer to [link / reference]. Figure 2 Step s102 in the process.

[0076] The key network parameters collected include: bandwidth (B, in Mbps), packet loss rate (L, in %), latency (D, in ms), jitter (J, in ms), and link connection status (S, 1 indicates connection, 0 indicates disconnection). Network quality assessment model: A weighted summation method is used to calculate the network quality score. The formula is as follows:

[0077] in, Bandwidth rating is based on the current bandwidth and the minimum bandwidth required for video transmission. Calculation of the ratio of ), ,when hour, =1; hour, = . Score the packet loss rate. ,in The packet loss rate threshold (configurable, default 5%) is set when... hour, ;when hour, It increases as the packet loss rate decreases. To delay the scoring, ,in The delay threshold (configurable, default 100ms) is set when... hour, ;when hour, It increases as the delay decreases. Rate the shaking. ,in The jitter threshold (configurable, default 50ms) is set when... hour, ;when hour, It increases as the shaking decreases. Score the link connectivity status. At that time, the score was 1; , rating 0. , , , , The weights of each indicator satisfy the following: Configuration based on actual scenarios (default: , , =0.2, , ). The range of values ​​is ,according to The value is used to determine the network state; This is a normal network. For weak networks; The internet is down.

[0078] Bandwidth, packet loss rate, latency, and jitter are collected in real time through the terminal-side network interface (collection frequency 1 time / second). Link connection status is determined by heartbeat detection between the terminal and the gateway / cloud (heartbeat interval 3 seconds). When there is no response for 3 consecutive heartbeats, it is determined as a network outage. ) Step 2: Video segmentation and I-frame alignment The terminal side segments the acquired raw video stream based on network quality assessment results. The segmentation process strictly adheres to the I-frame alignment principle to ensure that each video segment can be decoded and played independently. Please refer to [link to relevant documentation]. Figure 2 Step s104 in the process.

[0079] The segmentation length is dynamically adjusted based on the current network quality score. The segment length T is set using the following formula:

[0080] in, This is the maximum segment length (default 10 seconds). Medium clip length (default 5 seconds). The minimum segment length is set (default 2 seconds). Adjusting the segment length ensures that the terminal buffer can store more segments during weak / disconnected network conditions, preventing overflow, and reducing segmentation overhead during normal network conditions. I-frame alignment is required: each video segment must begin as an I-frame (keyframe) and end as the frame preceding the next I-frame. If the set segment length is reached without encountering the next I-frame, the segment is extended until the next I-frame appears, ensuring that the segment can be decoded independently.

[0081] Each segmented video segment is assigned a unique identifier (ID), which includes the terminal ID, the acquisition timestamp (accurate to milliseconds), and the segment sequence number. This identifier is used for segment matching during subsequent breakpoint resume transmission and cloud-side reordering and merging.

[0082] Step 3: Prioritize video segments On the terminal side, each segmented video clip is prioritized based on the event type it corresponds to, categorizing them into high-priority (alarm clips) and low-priority (normal recording clips). This prioritizes the data for subsequent priority scheduling and transmission back to the cloud side. Please refer to [link / reference]. Figure 2 Step s106 in the process.

[0083] High priority ( During video segment acquisition, if the terminal detects an alarm event (such as human intrusion, object movement, abnormal sound, etc.), the segment is marked as high priority. The alarm event is triggered by the terminal-side sensor (infrared sensor, sound sensor) or video analysis algorithm (target detection algorithm). When triggered, the alarm timestamp is recorded and matched with the video segment acquisition timestamp to determine the range of alarm segments. low priority ( ): Ordinary video clips that did not detect any alarm events are marked as low priority.

[0084] High-priority segments include a complete segment from 3 seconds before the alarm is triggered to 5 seconds after the alarm ends (configurable) to ensure complete recording of critical events; high-priority segments on the same terminal have higher priority than all low-priority segments, and high-priority segments on different terminals are sorted by alarm trigger timestamp (earlier timestamps take precedence).

[0085] Step 4: Terminal-side hierarchical caching and retransmission queue management The terminal side employs a tiered caching mechanism, caching the segmented video segments according to network status and segment priority. Simultaneously, a retransmission queue is constructed to enable resume transmission from where interrupted and priority retransmission of keyframes. Please refer to [link / reference]. Figure 2 Step s108 in the process.

[0086] The terminal-side cache is divided into three levels, and the capacity and storage strategy of each level are as follows: Level 1 Cache (Temporary Cache): Capacity C1 (default 1GB), adopts FIFO (First In First Out) strategy, stores video segments currently being captured and awaiting real-time transmission, only stores segments that have not yet been transmitted, and deletes them immediately after transmission is completed; Second-level cache (priority cache): capacity C2 (default 4GB), adopts a priority eviction policy, only stores high-priority (alarm) fragments. When the cache overflows, the oldest stored high-priority fragment is deleted (if all are fragments that have not been returned, the fragments with the most recent alarm trigger time are retained first). Level 3 cache (normal cache): capacity C3 (default 8GB), adopts FIFO strategy, stores low-priority (normal) segments, when the cache overflows, deletes the oldest stored normal segment (segments that have been returned are deleted first).

[0087] Based on the remaining storage space of the terminal and network quality score The capacity of each cache level is dynamically adjusted using the following formula:

[0088]

[0089]

[0090] in, Audit the terminal's storage space (collect data in real time, once per minute) to ensure that the cache capacity does not exceed the terminal's remaining storage space and avoids consuming too many terminal resources.

[0091] Construct and manage the retransmission queue. The retransmission queue is divided into a high-priority queue Q1 and a low-priority queue Q2. Q1 stores high-priority segments that have not been returned, and Q2 stores low-priority segments that have not been returned. The queue sorting rules are as follows: segments in Q1 are sorted in ascending order by alarm trigger timestamp (earlier triggers are prioritized for retransmission), and segments in Q2 are sorted in ascending order by acquisition timestamp (earlier acquisitions are prioritized for retransmission). The keyframe priority retransmission rule is that when retransmitting each video segment, I-frames within the segment are transmitted first, followed by P-frames and B-frames, ensuring that the cloud side can quickly decode and play the retransmitted segments, reducing live streaming stuttering. The breakpoint resume mechanism is as follows: the terminal side records the return progress of each segment (number of bytes returned and number of bytes not returned). When the network recovers or switches, based on the segment ID and return progress, transmission resumes from the breakpoint, avoiding duplicate transmission of returned data.

[0092] Step 5: Adaptive Backhaul Window and Multi-Link Switching Adjust the return window size and control the return rate based on Wang Kuo's quality; session parameters will be reused during multi-link switching to avoid live stream interruptions; please refer to [link / reference]. Figure 2 Step s110 in the process.

[0093] Based on network quality assessment results, the terminal side dynamically adjusts the backhaul window size and controls the backhaul rate to avoid network congestion during the backhaul process; at the same time, it achieves session persistence during intelligent switching of multiple links to ensure seamless live streaming.

[0094] Adaptive return window adjustment: The return window size W is defined as the number of video segments that can be returned simultaneously. It is dynamically adjusted based on the network quality score Q and the current bandwidth B using a bandwidth prediction model, as shown in the following formula: ,in, Set as the bandwidth utilization factor (default 0.7) to avoid backhaul consuming all bandwidth and reserve some bandwidth for live streaming and other terminal services. The average transmission bandwidth requirement (in Mbps) for a single video segment is calculated based on video encoding parameters (resolution, frame rate, bitrate). , This is the video bitrate (unit: kbps, configurable, default 4096kbps). The segment length (in seconds). This indicates rounding down; the range of values ​​for W is... , The maximum return window size (default 5 seconds) is used to avoid network congestion caused by excessively large windows. Data is collected based on bandwidth usage over the past 10 seconds. The bandwidth for the next second is predicted using the moving average method. , When predicting bandwidth At the same time, reduce the backhaul window W to ensure that the backhaul rate matches the network bandwidth.

[0095] Intelligent multi-link switching and session persistence. The terminal supports at least two types of links (wired links: broadband, enterprise dedicated lines; cellular links: 4G / 5G), and monitors the network quality of each link in real time (calculating the Q value of each link according to the evaluation model in step 1). When the network quality score Q of the currently used link is less than 0.3 (network outage), or Q is less than 0.5 for 5 consecutive seconds (weak network with no improvement), link switching is triggered, switching to the available link with the highest current Q value. During link switching, the original transmission session parameters are reused, including the playback URL, authentication token, and transmission port, without the need to regenerate the URL or trigger secondary authentication. A session pool is established between the terminal and the cloud to store the parameters of the currently active sessions. After switching links, the original session parameters are retrieved from the session pool to quickly establish a transmission connection. The session persistence time is 30 seconds by default (configurable) to ensure seamless live streaming.

[0096] Step 6: Cloud-side priority scheduling backhaul and fragment rearrangement merging For videos experiencing motion sickness, high-priority segments are prioritized for transmission. After verifying the integrity of the segments, they are rearranged and merged into a complete video stream based on timestamps, enabling continuous storage during live streaming. Please refer to [link to relevant documentation]. Figure 2 Step s112 in the process.

[0097] The cloud receives the transmission request from the terminal and, based on the priority of the video segments, adopts a priority scheduling strategy to prioritize the transmission of high-priority segments. At the same time, the transmitted segments are rearranged and merged to ensure the continuity of the video stream, enabling continuous recording storage and live playback.

[0098] Cloud-side priority scheduling strategy. The cloud maintains a global scheduling queue to receive all terminal return requests. Each return request includes the terminal ID, fragment ID, fragment priority, fragment size, and return progress. The scheduling rule is that return requests for high-priority fragments take precedence over low-priority fragments. Within the same priority level, fragments with a return progress of more than 50% are prioritized for scheduling (breakpoint resumption is prioritized), and the remaining fragments are scheduled according to the request submission time. Scheduling is performed every 1 second to dynamically adjust the allocation of return tasks, ensuring that high-priority fragments are returned quickly, while avoiding a single terminal consuming too much cloud-side bandwidth (the maximum return bandwidth for a single terminal does not exceed 20% of the cloud-side allocated bandwidth).

[0099] Cloud-side segment reordering and merging. After receiving each video segment, the cloud verifies the segment's integrity (whether there are missing frames or transmission errors) based on the segment ID and acquisition timestamp. If errors are found, a retransmission request is sent to the terminal (only the erroneous part is retransmitted, not the entire segment). Based on the segment's acquisition timestamp, all returned segments from the same terminal are sorted in ascending order to correct segment disorder caused by network latency. The sorted consecutive segments (with consecutive timestamps, no overlap, and no missing segments) are merged into a complete video stream and stored in the cloud-side storage system. At the same time, the playback address of the live stream is updated (reusing the original URL and only updating the stream content) to ensure the continuity of live streaming and playback. During the merging process, duplicate transmitted segments are deleted (based on segment ID) to avoid storing redundant data and save cloud-side storage space.

[0100] Step 7: Exception Handling and Dynamic Optimization Emergency strategies are implemented to address anomalies such as network outages and data transmission failures. Cloud-side parameters are regularly optimized to improve solution adaptability. Please refer to [link / reference]. Figure 2 Step s114 in the process.

[0101] When the terminal detects a network outage ( Immediately stop real-time transmission, store the acquired video segments into the corresponding buffers according to priority, and start link detection (detection frequency increased to 1 time / 0.5 seconds) to wait for network recovery; if a packet loss rate L≥L_th (default 5%) or a delay D≥D_th (default 100ms) occurs during segment transmission, it is determined as a transmission failure, and the segment is added back to the corresponding retransmission queue to wait for the next round of scheduling transmission. For segments with more than 3 transmission failures, key frame retransmission is given priority; when all three levels of buffers are overflowing, the transmitted segments in the low-priority segments are deleted first. If all segments are not transmitted, the earliest acquired low-priority segment is deleted to ensure that high-priority segments are not deleted.

[0102] The cloud side periodically (hourly) collects network quality data and backhaul efficiency data (retransmission success rate, average backhaul latency) for each terminal, and dynamically adjusts the weights of the network quality assessment model. and key parameters Optimize transmission strategies to adapt to network characteristics in different scenarios.

[0103] This embodiment takes a government and enterprise park monitoring scenario as an example. The scenario is configured with 10 monitoring terminals and adopts a dual-link mode of "government and enterprise dedicated line + 5G backup". The terminal video encoding parameters are: resolution 1080P, frame rate 25fps, bit rate R=4096kbps, and minimum bandwidth requirement for video transmission B_min=5Mbps; the cloud storage capacity is 100TB, which supports concurrent transmission from multiple terminals and live distribution.

[0104] Occasionally, the dedicated government and enterprise lines experience failures (network outages), causing live streaming interruptions when switching to 5G links; occasional intrusion alarms occur within the park, and the existing system's alarm recordings are delayed, making recording loss likely; live streaming experiences severe buffering during periods of weak network connectivity (such as peak hours when dedicated line bandwidth fluctuates).

[0105] The specific implementation process of the method of the present invention is as follows: Step 1: Real-time network quality assessment The terminal side collects network parameters of the dedicated line link every second: bandwidth B, packet loss rate L, latency D, and jitter J. Simultaneously, it performs a heartbeat check with the cloud side every 3 seconds to determine the link connection status S. The configuration parameters are as follows: , , , Weight , , , , Suppose the leased link parameters collected at a certain moment are as follows: , , , , Calculate network quality score .

[0106]

[0107]

[0108]

[0109]

[0110]

[0111] The network was determined to be weak.

[0112] Step 2: Align video clip slices with I-frames based on (Network disconnection threshold Q < 0.3), set segment length Seconds; In the video stream captured by the terminal, the I-frame interval is 1 second (one I-frame every 1 second). The segmentation process follows the I-frame alignment principle. The starting frame of each segment is an I-frame, the length is 2 seconds, and it contains 2 I-frames and 48 P / B frames.

[0113] Each segment is assigned a unique identifier ID: Terminal ID (001) + Collection timestamp (20260212100000000) + Segment number (001) to ensure that the segment can be uniquely identified.

[0114] Step 3: Prioritize video segments At a certain moment, the infrared sensor of terminal 001 triggers a human intrusion alarm (alarm timestamp 20260212100001000). The terminal marks the video segment from the 3 seconds before the alarm trigger (100000000-100002999) to the 5 seconds after the alarm ends (100001000-100006999) as high priority. The remaining segments that did not trigger alarms were marked as low priority. ).

[0115] Step 4: Terminal-side hierarchical caching and retransmission queue management Remaining storage space of terminal 001 Dynamically adjust the capacity of each cache level:

[0116]

[0117]

[0118] Store high-priority alarm fragments in the second-level cache (priority cache) and low-priority fragments in the third-level cache (normal cache); construct a retransmission queue. Alarm fragments are stored in the high-priority queue (in ascending order of alarm timestamp). (Low priority queue) stores ordinary fragments (in ascending order of collection timestamp).

[0119] At this time, the leased link is a weak network and cannot transmit data back in real time. The terminal stops transmitting data back and stores all untransmitted segments in the corresponding cache, waiting for the network to recover.

[0120] Step 5: Adaptive Backhaul Window Adjustment and Intelligent Multi-Link Switching Ten seconds later, the leased link failed. , The terminal triggers a link switch to the 5G link. During the switch, the original playback URL (http: / / xxx.xxx.xxx / 001) and authentication token (Token:xxxxxxx) are reused. The session is maintained for 30 seconds, the live broadcast is not interrupted, and the user is unaware of it.

[0121] Network parameters collected after switching to the 5G link: , , , , ,calculate The network is working properly.

[0122] Calculate postback window size , ; This means that up to 3 segments can be transmitted back at the same time.

[0123] Step 6: Cloud-side priority scheduling backhaul and fragment rearrangement merging The cloud-side receiving terminal 001 sends a return request (containing 3 high-priority segments and 5 low-priority segments). Based on the priority scheduling strategy, it prioritizes scheduling the data. High-priority segments in the queue are sent back and then rescheduled. Low-priority segments in the queue; within the same queue, scheduling is done in ascending order of timestamp.

[0124] After receiving the video clips, the cloud side verifies the integrity of the clips based on the clip ID and the acquisition timestamp (no packet loss, no transmission errors), rearranges the clips (in ascending order of acquisition timestamp), merges them into a complete video stream, and stores it in the cloud storage system; at the same time, it updates the live stream content (reusing the original URL) to ensure the continuity of the live stream.

[0125] Step 7: Exception Handling and Dynamic Optimization During the transmission, a low-priority segment experienced packet loss. If the transmission fails, the cloud sends a retransmission request to the terminal, and the terminal re-adds the segment. The queue prioritizes retransmitting the I-frame of this segment during the next round of scheduling to ensure that the segment is transmitted back completely.

[0126] The cloud side statistically analyzes the return data of terminal 001 every hour: the retransmission success rate is 99.8%, the average return latency is 0.5 seconds, and the weights of the network quality assessment model are dynamically optimized (adjusted). (Increase the weight of packet loss rate) to ensure that subsequent transmission strategies are more suitable for this scenario. Corresponding to the aforementioned methods for ensuring monitoring in weak network outage scenarios, this invention also proposes a monitoring protection device for such scenarios. Since the device embodiments of this invention correspond to the method embodiments described above, details not disclosed in the device embodiments can be referred to in the method embodiments, and will not be repeated here.

[0127] Figure 3 This is a schematic diagram of a monitoring device for weak network outage scenarios provided in this embodiment of the disclosure, as shown below. Figure 3 As shown, it includes: Monitoring unit 21 is used to monitor the network quality status of the communication link; The segmentation unit 22 is used to segment the acquired video stream into multiple independently decodeable video segments according to the monitored network quality status; wherein, the video segments have priorities corresponding to the event types contained within the video segments; Storage unit 23 is used to store the video segments in a local cache according to the priority. The merging unit 24 is used to schedule the video segments to be uploaded to the cloud according to their priority, and to rearrange and merge the video segments to obtain a continuous video stream.

[0128] Furthermore, in one possible implementation of this disclosure, the monitoring unit 21 is further configured to: Collect network parameters of the communication link; wherein, the network parameters include bandwidth, packet loss rate, latency, jitter and link connection status; The network parameters are calculated using a weighted summation method to obtain a network quality score. The network quality score is compared with a first preset threshold and a second preset threshold to determine the current network status; wherein the network status includes one of normal network, weak network, or network outage.

[0129] Furthermore, in one possible implementation of this disclosure, the segmentation unit 22 is further configured to: The segment length of the video clip is determined based on the current network quality status; The video stream is segmented using keyframes as the starting frames of the segments, so that each video segment can be decoded independently. Each segmented video fragment is uniquely identified by generating identification information, which includes the timestamp of the acquisition and the terminal name.

[0130] Furthermore, in one possible implementation of the embodiments of this disclosure, such as Figure 4 As shown, the device further includes: The first marking unit 25 is used to mark a video segment as high priority when an alarm event is detected during the acquisition of a video segment before the storage unit 23 stores the video segments in the local cache according to the priority. The second marking unit 26 is used to mark the video segment as low priority when an alarm event is detected during the acquisition of the video segment.

[0131] Furthermore, in one possible implementation of this disclosure, the storage unit 23 is further used for: Video segments of different priorities are stored in corresponding local caches; high-priority segments are stored in the first-level cache, low-priority segments are stored in the second-level cache, and segments temporarily stored for real-time transmission are stored in the third-level cache. In response to insufficient cache space, a first-in-first-out (FIFO) eviction policy is executed in the second-level cache and the third-level cache according to the priority and storage time of the video segments.

[0132] Furthermore, in one possible implementation of the embodiments of this disclosure, such as Figure 4 As shown, the device further includes: Establishment unit 27 is used to establish a first retransmission queue for managing high-priority segments that have not been transmitted and a second retransmission queue for managing low-priority segments that have not been transmitted, respectively, after storage unit 23 stores the video segments in local cache according to the priority. The transmission unit 28 is used to record the transmission progress of each video segment. After the communication link is restored, the corresponding video segment is continued to be transmitted from the point of interruption according to the transmission progress.

[0133] Furthermore, in one possible implementation of this disclosure, the merging unit 24 is further configured to: Monitor the network quality of at least two communication links; When the quality of the currently used communication link is lower than the preset conditions, switch to the available link with the best network quality.

[0134] Furthermore, in one possible implementation of this disclosure, the merging unit 24 is further configured to: Video clips from the same terminal are sorted according to the timestamp information carried by the video clips in order to correct out-of-order transmission. By merging the sorted segments with consecutive and non-overlapping timestamps, a complete video stream is obtained.

[0135] It should be noted that the foregoing explanation of the method embodiments also applies to the apparatus of the embodiments of this disclosure, and the principle is the same. Therefore, the embodiments of this disclosure are not limited thereto.

[0136] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0137] Figure 5 A schematic block diagram of an example electronic device 400 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0138] like Figure 5As shown, device 400 includes a computing unit 401, which can perform various appropriate actions and processes based on a computer program stored in ROM (Read-Only Memory) 402 or a computer program loaded from storage unit 408 into RAM (Random Access Memory) 403. RAM 403 may also store various programs and data required for the operation of device 400. The computing unit 401, ROM 402, and RAM 403 are interconnected via bus 404. I / O (Input / Output) interface 405 is also connected to bus 404.

[0139] Multiple components in device 400 are connected to I / O interface 405, including: input unit 406, such as keyboard, mouse, etc.; output unit 407, such as various types of monitors, speakers, etc.; storage unit 408, such as disk, optical disk, etc.; and communication unit 409, such as network card, modem, wireless transceiver, etc. Communication unit 409 allows device 400 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0140] The computing unit 401 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 401 include, but are not limited to, CPUs (Central Processing Units), GPUs (Graphics Processing Units), various special-purpose AI (Artificial Intelligence) computing chips, various computing units running machine learning model algorithms, DSPs (Digital Signal Processors), and any suitable processor, controller, microcontroller, etc. The computing unit 401 performs the various methods and processes described above, such as the protection method for monitoring in weak network outage scenarios. For example, in some embodiments, the protection method for monitoring in weak network outage scenarios can be implemented as a computer software program, which is tangibly contained in a machine-readable medium, such as storage unit 408. In some embodiments, part or all of the computer program can be loaded and / or installed on device 400 via ROM 402 and / or communication unit 409. When the computer program is loaded into RAM 403 and executed by the computing unit 401, one or more steps of the methods described above can be performed. Alternatively, in other embodiments, the computing unit 401 may be configured in any other suitable manner (e.g., by means of firmware) to perform the aforementioned monitoring safeguard method for weak network outage scenarios.

[0141] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, FPGAs (Field Programmable Gate Arrays), ASICs (Application-Specific Integrated Circuits), ASSPs (Application-Specific Standard Products), SOCs (System-on-Chips), CPLDs (Complex Programmable Logic Devices), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0142] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0143] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, RAM, ROM, EPROM (Electrically Programmable Read-Only Memory) or flash memory, optical fiber, CD-ROM (Compact Disc Read-Only Memory), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0144] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (Cathode-Ray Tube) or LCD (Liquid Crystal Display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0145] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include LANs (Local Area Networks), WANs (Wide Area Networks), the Internet, and blockchain networks.

[0146] Computer systems can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. A server can be a cloud server, also known as a cloud computing server or cloud host, a hosting product within the cloud computing service system that addresses the shortcomings of traditional physical hosts and VPS (Virtual Private Server) services, such as high management difficulty and weak business scalability. Servers can also be servers for distributed systems or servers incorporating blockchain technology.

[0147] It's important to note that artificial intelligence (AI) is the study of enabling computers to simulate certain human thought processes and intelligent behaviors (such as learning, reasoning, thinking, and planning). It encompasses both hardware and software technologies. AI hardware technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, and big data processing. AI software technologies primarily include computer vision, speech recognition, natural language processing, machine learning / deep learning, big data processing, and knowledge graph technologies.

[0148] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0149] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for ensuring monitoring in weak network outage scenarios, characterized in that, include: Monitor the network quality status of communication links; Based on the monitored network quality status, the acquired video stream is divided into multiple independently decodeable video segments; wherein, each video segment has a priority corresponding to the event type contained within it. The video segments are stored in a local cache according to their priority. The video segments are scheduled to be uploaded to the cloud according to their priority, and the video segments are rearranged and merged to obtain a continuous video stream.

2. The method according to claim 1, characterized in that, The network quality status of the monitored communication link includes: Collect network parameters of the communication link; wherein, the network parameters include bandwidth, packet loss rate, latency, jitter and link connection status; The network parameters are calculated using a weighted summation method to obtain a network quality score. The network quality score is compared with a first preset threshold and a second preset threshold to determine the current network status; wherein the network status includes one of normal network, weak network, or network outage.

3. The method according to claim 2, characterized in that, The step of dividing the acquired video stream into multiple independently decodeable video segments based on the monitored network quality status includes: The segment length of the video clip is determined based on the current network quality status; The video stream is segmented using keyframes as the starting frames of the segments, so that each video segment can be decoded independently. Each segmented video fragment is uniquely identified by an identifier; the identifier includes the timestamp of the acquisition and the terminal name.

4. The method according to claim 1, characterized in that, Before storing the video segments in a local cache according to the priority, the method further includes: When an alarm event is detected during the acquisition of video clips, the video clips are marked as high priority; When an alarm event is detected during the acquisition of a video clip, the video clip is marked as low priority.

5. The method according to claim 1, characterized in that, The step of storing the video segments in a local cache according to their priority includes: Video segments of different priorities are stored in corresponding local caches; high-priority segments are stored in the first-level cache, low-priority segments are stored in the second-level cache, and segments temporarily stored for real-time transmission are stored in the third-level cache. In response to insufficient cache space, a first-in-first-out (FIFO) eviction policy is executed in the second-level cache and the third-level cache according to the priority and storage time of the video segments.

6. The method according to claim 5, characterized in that, After storing the video segments in a local cache according to their priority, the method further includes: Establish a first retransmission queue for managing untransmitted high-priority segments and a second retransmission queue for managing untransmitted low-priority segments; Record the transmission progress of each video segment, and after the communication link is restored, continue transmitting the corresponding video segment from the point of interruption according to the transmission progress.

7. The method according to claim 1, characterized in that, The process of scheduling the upload of the video segments to the cloud based on their priority includes: Monitor the network quality of at least two communication links; When the quality of the currently used communication link is lower than the preset conditions, switch to the available link with the best network quality.

8. The method according to claim 1, characterized in that, The process of scheduling and uploading video segments to the cloud according to their priority, and rearranging and merging the video segments to obtain a continuous video stream includes: Video clips from the same terminal are sorted according to the timestamp information carried by the video clips in order to correct out-of-order transmission. By merging the sorted segments with consecutive and non-overlapping timestamps, a complete video stream is obtained.

9. A monitoring protection device for weak network outage scenarios, characterized in that, include: The monitoring unit is used to monitor the network quality status of the communication link; The segmentation unit is used to segment the acquired video stream into multiple independently decodeable video segments based on the monitored network quality status; wherein, the video segments have priorities corresponding to the event types contained within the video segments; Storage unit, used to hierarchically store the video segments in local cache according to the priority; The merging unit is used to schedule the video segments to be uploaded to the cloud according to their priority, and to rearrange and merge the video segments to obtain a continuous video stream.

10. An electronic device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-8.

Images