Video stream overtime recovery method and system

Abstract

The invention relates to the technical field of video stream communication, in particular to a video stream timeout recovery method and system, and the method comprises the steps: detecting a video stream based on a preset multi-stage timeout mechanism, and determining that a timeout action occurs; in response to the timeout action, acquiring context information of the video stream; acquiring a timeout error type of the video stream based on the context information; and performing recovery retry on the video stream based on the timeout error type until the connection of the video stream is recovered. According to the method, a user does not need to carry out manual retry, based on preset multi-stage timeout mechanism detection, whether the timeout action occurs at multiple action nodes of the video stream is detected, and when the timeout action occurs at the video stream, the error type causing timeout of the video stream is analyzed according to context information, so that the timeout of the video stream is avoided. And corresponding recovery retry strategies are executed according to different super error types, so that differentiated video stream recovery retry strategies are implemented for different levels of timeout error reasons, and the video stream timeout recovery efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of video stream communication, and in particular to a method and system for recovering a video stream timeout. Background Art

[0002] In existing video surveillance and video scheduling systems, when a client initiates a video stream request from a video source such as a camera or streaming server, the request often fails to receive a response within the preset timeout period due to factors such as unstable network transmission links, excessive server resource load, or device / service failures. This results in a request timeout. The current common approach is to return a simple error message to the client and rely on the user to manually re-initiate the request. This approach has significant drawbacks:

[0003] 1) Poor user experience: Frequent manual retry operations are cumbersome, especially in scenarios such as security monitoring centers and traffic control and dispatching that require continuous attention to multiple video sources. This can easily distract users and reduce work efficiency.

[0004] 2) Low system availability: Manual intervention cannot guarantee the rapid recovery of video streams. In critical business scenarios such as emergency command and real-time monitoring, it may lead to interruption or loss of important video information, failing to meet high availability requirements.

[0005] 3) Insufficient adaptability: Existing technologies lack the ability to deeply perceive and distinguish the network environment, specific error causes, and the current status of the server / device, and are unable to implement differentiated and efficient recovery strategies based on specific situations.

[0006] Therefore, there is an urgent need for a smarter and more automated video stream request timeout processing and recovery mechanism to improve the success rate of video stream acquisition and the overall availability of the system. Summary of the Invention

[0007] The present invention aims to provide a video stream timeout recovery method and system to achieve the purpose of improving the efficiency of video stream timeout recovery, thereby solving the technical problems of the existing technology that frequent manual retry operations are required and differentiated recovery and retry strategies cannot be implemented according to specific circumstances.

[0008] In order to achieve the above object, the first aspect of the present invention provides a video stream timeout recovery method, which is applicable to video streams and includes the following steps:

[0009] Detecting the video stream based on a preset multi-level timeout mechanism to confirm that a timeout action has occurred;

[0010] In response to the timeout action, obtaining context information of the video stream;

[0011] Acquire a timeout error type of the video stream based on the context information;

[0012] The video stream is recovered and retried based on the timeout error type until the video stream is restored.

[0013] The above-mentioned video stream timeout recovery method does not require the user to manually retry; the method is based on a preset multi-level timeout mechanism detection, and detects whether a timeout action occurs at multiple action nodes of the video stream. When a timeout action occurs in the video stream, the error type that causes the video stream timeout is analyzed based on the context information, and then the corresponding recovery retry strategy is executed according to different super error types, thereby implementing differentiated video stream recovery and retry strategies for different levels of timeout error causes, thereby improving the efficiency of video stream timeout recovery.

[0014] Furthermore, the detecting whether a timeout occurs in the video stream based on a preset multi-level timeout mechanism includes:

[0015] Detecting real-time actions of the video stream, and then obtaining the action time of the video stream;

[0016] If the action time exceeds the preset timeout threshold, confirming that the timeout action occurs;

[0017] The real-time actions include connection request action, connection establishment action, first frame reception action and playback interruption operation.

[0018] This implementation method detects multiple process nodes of the video stream to determine whether a timeout has occurred. The process nodes cover the video stream connection request initiation stage, connection establishment stage, first frame reception stage of the video stream, and stage of interruption of video stream playback. Compared with the current single timeout detection mechanism, it expands the monitoring scope of video stream timeout, thereby improving the efficiency of video stream timeout response.

[0019] Furthermore, the context information includes network information, server information, device information, and permission information; and obtaining the timeout error type of the video stream based on the video stream context information includes:

[0020] Analyze network packet loss rate, network delay, and network continuity based on the network information to obtain a network score;

[0021] Analyze the server CPU usage, server memory usage, server connection number and server error code based on the server information, and then obtain a server score;

[0022] Analyze the device's historical offline status, device's historical response status, and device's historical failure frequency based on the device information, and thereby obtain a device score;

[0023] Analyzing the user authentication status and user access rights based on the permission information, and then obtaining a permission score;

[0024] The timeout error type of the video stream is obtained based on the network score, the server score, the device score, and the permission score, specifically:

[0025] If the network score exceeds a preset network score threshold, the video stream is of a network error type;

[0026] If the server score exceeds a preset server score threshold, the video stream is of server error type;

[0027] If the device score exceeds a preset device score threshold, the video stream is of device error type;

[0028] If the permission score exceeds a preset permission score threshold, the video stream is of a permission error type.

[0029] In this implementation, by collecting and analyzing the contextual information that occurs when the video stream times out, multi-dimensional analysis is performed to determine the cause of the video stream timeout, thereby improving the information resolution of the video stream timeout situation, and then implementing differentiated recovery and retry strategies for specific timeout information to improve the recovery and retry efficiency.

[0030] Furthermore, the recovering and retrying the video stream based on the timeout error type until the video stream is restored to a connection includes:

[0031] Obtaining a first retry delay time based on the timeout error type;

[0032] Obtaining the device importance corresponding to the video stream, and then obtaining a second retry delay time and a retry number threshold based on the device importance;

[0033] Calculating a final retry delay time based on the first retry delay time and the second retry delay time by an exponential backoff algorithm;

[0034] The video stream is retried several times based on the final retry delay time until the video stream is reconnected or the number of retry attempts reaches the retry number threshold.

[0035] This implementation uses a targeted first retry delay based on the type of video stream timeout error, and a targeted second retry delay based on the device importance of the video stream. This results in differentiated retry strategies tailored to different video stream timeout scenarios. Furthermore, this implementation incorporates an exponential backoff algorithm to determine the final retry delay, which serves as the final recovery retry interval, further improving recovery retry efficiency.

[0036] Furthermore, the retrying the video stream several times based on the final retry delay time until the video stream is restored or the number of retry attempts reaches a retry threshold includes:

[0037] Monitor the real-time network packet loss rate, server CPU load rate, and device status corresponding to the video stream;

[0038] Acquire the current environment status of the video stream based on the real-time packet loss rate of the network, the real-time load rate of the server CPU, and the real-time status of the device;

[0039] If the current environmental status meets the preset improvement condition, the video stream is restored and retried.

[0040] In this implementation, retry is further triggered based on environmental improvement conditions such as improved network conditions or reduced server load. When the current environmental status meets the improvement conditions, recovery retry is immediately triggered without waiting for the time interval of the final recovery retry delay time, thereby improving the video stream recovery efficiency and success rate.

[0041] Furthermore, the recovering and retrying the video stream based on the timeout error type until the video stream is restored to a connection includes:

[0042] In response to timeout actions of a plurality of the video streams, obtaining priorities of all the video streams, and then constructing a video stream priority queue based on the priorities of all the video streams;

[0043] Based on the timeout error type and priority of each video stream, each video stream in the video stream priority queue is recovered and retried in turn.

[0044] In this implementation, for the timeout actions of multiple video streams, a priority recovery strategy is formulated by analyzing the priority of each video stream, so that video streams with high priority are restored and retried first, thereby improving the recovery efficiency of key video streams and improving the efficiency of system resource utilization.

[0045] Furthermore, in response to timeout signals of the plurality of video streams, obtaining the priorities of all the video streams, and then constructing a video stream priority queue based on the priorities of all the video streams, includes:

[0046] For any of the video streams, obtaining the user attention, event importance, device importance, and resource occupancy corresponding to the video stream, and then obtaining the priority of the video stream based on the user attention, event importance, device attention, and resource occupancy;

[0047] All the video streams are sorted based on their priorities, thereby obtaining the video stream priority queue.

[0048] In this implementation, video streams with high user attention, high event importance, high device importance and low resource occupancy are set as high-priority video streams, and the specific priority score of each video stream is calculated based on multiple dimensions such as user attention, event importance, device importance and resource occupancy, so that all the video streams can be sorted to obtain the video stream priority queue, thereby improving the recovery efficiency of key video streams.

[0049] Furthermore, the recovering and retrying each of the video streams in the video stream priority queue in sequence based on the timeout error type and priority of each of the video streams includes:

[0050] Obtaining system resource occupancy, and then obtaining the number of parallel recovery operations based on the system resource occupancy;

[0051] Based on the parallel recovery quantity and the timeout error type and priority of each video stream, recovery retries are performed on several video streams in the video stream priority queue in sequence.

[0052] In this implementation, the maximum number N of video streams that can be recovered and retried simultaneously is set according to the currently available resources of the system, and then the top N video streams with the highest priority are taken out from the video stream priority queue according to high priority sorting and recovered simultaneously, thereby further improving the recovery efficiency of key video streams and improving the efficiency of system resource utilization.

[0053] Furthermore, the video stream timeout recovery method further includes:

[0054] estimating a recovery retry time based on the context information and the number of recovery retries;

[0055] The user is prompted with a recovery retry progress based on the recovery retry time.

[0056] This implementation method estimates the recovery retry event and prompts the user with the recovery retry progress, thereby providing the user with clear video stream recovery retry status feedback and expectation management, improving the user experience.

[0057] A second aspect of the present invention provides a video stream timeout recovery system, comprising a multi-stage timeout detection module, a timeout error analysis module, and a recovery and retry module, wherein:

[0058] The multi-level timeout detection module is used to detect whether a timeout action occurs in the video stream according to a preset multi-level timeout mechanism;

[0059] The timeout error analysis module obtains context information of the video stream in response to the timeout action, and further obtains the timeout error type of the video stream based on the context information;

[0060] The recovery and retry module is used to recover and retry the video stream according to the timeout error type until the video stream is restored.

[0061] The above-mentioned video stream timeout recovery system does not require users to manually retry; this method is based on a preset multi-level timeout mechanism detection, and detects whether a timeout action occurs at multiple action nodes of the video stream. When a timeout action occurs in the video stream, the error type that causes the video stream timeout is analyzed based on context information, and then the corresponding recovery retry strategy is executed according to different super error types, thereby implementing differentiated video stream recovery and retry strategies for different levels of timeout error causes, thereby improving the efficiency of video stream timeout recovery. BRIEF DESCRIPTION OF THE DRAWINGS

[0062] Figure 1 1 is a flow chart of a method for recovering a video stream timeout provided by an embodiment of the present invention;

[0063] Figure 2 The present invention provides a schematic diagram of the structure of a video stream timeout recovery system. DETAILED DESCRIPTION

[0064] The present invention will be described in detail below with reference to the accompanying drawings and in conjunction with embodiments. It should be noted that the following detailed descriptions are all exemplary descriptions and are intended to provide further detailed descriptions of the present invention. Unless otherwise defined, all technical and scientific terms used herein have the same meanings as those generally understood by those skilled in the art to which this application belongs; the terms used herein in the specification of the application are only for the purpose of describing specific embodiments and are not intended to limit this application; the terms "including" and "having" in the specification and claims of this application and the description of the above-mentioned drawings, as well as any variations thereof, are intended to cover non-exclusive inclusions. The terms "first", "second", etc. in the specification and claims of this application or the above-mentioned drawings are used to distinguish different objects, rather than to describe a specific order.

[0065] It should be understood that although the steps in the flowcharts of the accompanying drawings are shown in sequence as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some of the steps in the flowcharts of the accompanying drawings may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily executed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be executed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0066] In existing video surveillance and video scheduling systems, when a client initiates a video stream request from a video source such as a camera or streaming server, the request often fails to receive a response within the preset timeout due to factors such as unstable network transmission links, excessive server resource load, or device / service failures. This results in a request timeout. The current common approach is to return a simple error message to the client and rely on the user to manually re-initiate the request. This approach has significant drawbacks:

[0067] 1) Poor user experience: Frequent manual retry operations are cumbersome, especially in scenarios such as security monitoring centers and traffic control and dispatching that require continuous attention to multiple video sources. This can easily distract users and reduce work efficiency.

[0068] 2) Low system availability: Manual intervention cannot guarantee the rapid recovery of video streams. In critical business scenarios such as emergency command and real-time monitoring, it may lead to interruption or loss of important video information, failing to meet high availability requirements.

[0069] 3) Insufficient adaptability: Existing technologies lack the ability to deeply perceive and distinguish the network environment, specific error causes, and the current status of the server / device, and are unable to implement differentiated and efficient recovery strategies based on specific situations.

[0070] Therefore, there is an urgent need for a smarter and more automated video stream request timeout processing and recovery mechanism to improve the success rate of video stream acquisition and the overall availability of the system.

[0071] To solve the above problems, see Figure 1 A first aspect of the present invention provides a video stream timeout recovery method, applicable to video streams, the method comprising the following steps:

[0072] S1. Detecting the video stream based on a preset multi-level timeout mechanism to confirm that a timeout action has occurred;

[0073] S2. In response to the timeout action, obtaining context information of the video stream;

[0074] S3. Acquire a timeout error type of the video stream based on the context information;

[0075] S4. Retrieve and recover the video stream based on the timeout error type until the video stream is restored.

[0076] The above-mentioned video stream timeout recovery method does not require the user to manually retry; the method is based on a preset multi-level timeout mechanism detection, and detects whether a timeout action occurs at multiple action nodes of the video stream. When a timeout action occurs in the video stream, the error type that causes the video stream timeout is analyzed based on the context information, and then the corresponding recovery retry strategy is executed according to different super error types, thereby implementing differentiated video stream recovery and retry strategies for different levels of timeout error causes, thereby improving the efficiency of video stream timeout recovery.

[0077] Furthermore, the detecting whether a timeout occurs in the video stream based on a preset multi-level timeout mechanism includes:

[0078] Detecting real-time actions of the video stream, and then obtaining the action time of the video stream;

[0079] If the action time exceeds the preset timeout threshold, confirming that the timeout action occurs;

[0080] The real-time actions include:

[0081] 1) Connection request action, monitoring the initial initiation phase of the video stream request;

[0082] 2) Connection establishment action, monitoring the video stream connection establishment phase of the streaming media server;

[0083] 3) First frame receiving action, monitoring the receiving stage of the first video frame of the video stream;

[0084] 4) Playback interruption operation, monitoring whether there is any interruption in the continuous playback phase of the video stream.

[0085] Specifically, in the video stream connection request initiation stage, a timer is set to monitor whether the video stream request initiation exceeds the timeout threshold. If it exceeds the timeout threshold, the video stream is restored and retried in response to the timeout action; in the video stream connection establishment stage, after the video stream request is successful, when the connection is established, a new timer is set to monitor whether the video stream connection establishment action is timed out. If it exceeds the timeout threshold, the video stream is restored and retried in response to the timeout action; in the video stream first frame reception stage, after the video stream connection is successfully established, a new timer is set to monitor whether the action of the streaming media server receiving the first frame of the video stream is timed out. If it exceeds the timeout threshold, the video stream is restored and retried in response to the timeout action; in the stage where the streaming media successfully receives the first frame of the video stream and the video stream is played normally, a playback stage timer is set to monitor whether the video stream is played normally. If the video stream interruption time exceeds the timeout threshold, the video stream is restored and retried in response to the timeout action.

[0086] Preferably, the system dynamically configures timeout thresholds for connection request, connection establishment, first frame reception, and playback interruption based on the current network type, including but not limited to satellite and public networks. This allows the system to adapt to multi-network environments, optimize timeout handling strategies for different network characteristics, and improve the efficiency of video stream timeout recovery.

[0087] This implementation method detects multiple process nodes of the video stream to determine whether a timeout has occurred. The process nodes cover the video stream connection request initiation stage, connection establishment stage, first frame reception stage of the video stream, and stage of interruption of video stream playback. Compared with the current single timeout detection mechanism, the monitoring scope of video stream timeout is improved, thereby improving the efficiency of video stream timeout response.

[0088] Furthermore, the context information includes network information, server information, device information, and permission information; and obtaining the timeout error type of the video stream based on the video stream context information includes:

[0089] Based on the network information, the network packet loss rate, network delay and network continuity are analyzed to obtain a network score. Specifically, the current network status, delay and packet loss rate are detected to determine whether there is a network problem. The specific steps are as follows:

[0090] Collect network status data. The system collects the current network packet loss rate, delay and bandwidth data through regular network detection.

[0091] Perform packet loss rate comparison analysis and set network status thresholds. Preset packet loss rate thresholds based on different network types. For satellite networks, set the packet loss rate threshold to 15%; for mobile networks, set the packet loss rate threshold to 10%; and for wired networks, set the packet loss rate threshold to 5%. Compare the current network packet loss rate with the corresponding packet loss rate threshold. Optimize the packet loss rate threshold based on different network characteristics to improve video stream timeout recovery efficiency.

[0092] Perform network delay analysis and calculate the current average network delay. If the deviation between the current average network delay and the benchmark delay exceeds 50%, it is considered an abnormal delay.

[0093] Perform a network continuity test to detect the number of network interruptions in the last 5 minutes. If the number exceeds 3, the network is considered unstable.

[0094] Finally, a comprehensive network score is calculated based on the above analysis and calculation results. The calculation formula is as follows: Score = (Packet Loss Rate / Packet Loss Threshold) 0.5 + (Delay Deviation Rate / 50%) 0.3 + (Number of Interruptions / 3) * 0.2. If the network score exceeds 0.8, it is determined to be a network error type.

[0095] Based on the server information, the server CPU usage, server memory usage, server connection number and server error code are analyzed to obtain a server score. Specifically, the server response time and load are detected to determine whether there is a server problem. The specific steps are as follows:

[0096] Collect server status data and obtain server CPU usage, memory usage, and current number of connections through heartbeat packets or API calls. Set server load thresholds, where the CPU usage threshold is 80%, the memory usage threshold is 85%, and the maximum number of concurrent connections for a single server is 1000. Perform response time analysis and calculate the average server response time. Any time exceeding 200ms is considered an abnormality. Detect server error codes and analyze the error codes returned by the server. 5xx series errors (such as 503) indicate a problem with the server. Perform a multi-server consistency check, sending the same request to multiple servers. If only a single server responds abnormally, it indicates a server problem.

[0097] Finally, a comprehensive server score is calculated based on the above analysis and calculation results. The calculation formula is as follows: Server Score = (CPU usage / 80%) + (memory usage / 85%) + (current number of connections / 1000) + (whether there are 5xx errors) + (whether there are any) + (server error). If the server score exceeds 0.75, it is determined to be a server error.

[0098] Based on the device information, the device's historical offline status, historical response status, and historical fault frequency are analyzed to obtain a device score. Specifically, the device's historical online status and response mode are detected to determine whether it is a device problem. The specific steps are as follows:

[0099] Analyze the device's online status history and check the device's online records in the last 24 hours. Set an offline time threshold, and determine that the device may be offline if the last online time exceeds 30 minutes. Detect device response patterns and analyze historical device response patterns, such as the device's average first frame delay, average interruption frequency, etc. Perform device health assessment: Calculate the device health score (0-100 points) based on historical data. Perform multi-device correlation analysis to check whether there are similar faults in devices of the same area or model, and eliminate network factors. Analyze device error logs, check the error logs recently reported by the device, and identify hardware or software failure characteristics.

[0100] Finally, a comprehensive device score is calculated based on the above analysis results. The calculation formula is as follows: Device Score = (Offline Duration / 30 Minutes) + (Health Level) / 100 + (Historical Failure Frequency / Baseline Frequency) + (Error Log Severity) + (Error Log Severity) . If the device score exceeds 0.7, it is determined to be a device error.

[0101] Based on the permission information, the user authentication status and user access rights are analyzed to obtain a permission score. Specifically, by detecting the user's permissions and authentication status, it is determined whether it is a permission issue. The specific steps are as follows:

[0102] Check user authentication status to verify user login status and session validity. Verify user access rights to query whether the user has the permission level to access the target device. Analyze authentication response codes to check error codes in server authentication responses, such as 401 (Unauthorized) or 403 (Forbidden). Check certificate validity. For secure connections, verify whether the SSL / TLS certificate is valid or expired. Perform access token checks to verify that the user's access token is valid and has not expired. Perform time limit checks to check whether the user is within the allowed access time period (some systems restrict access during non-working hours).

[0103] Finally, a comprehensive permission score is calculated based on the above analysis results. The calculation formula is as follows: Permission Score = (Authentication Failed? 1:0) 0.4 + (Insufficient Permissions? 1:0) 0.3 + (401 / 403 Error? 1:0) 0.2 + (Invalid Certificate or Expired Token? 1:0) 0.1. If the permission score exceeds 0.5, it is determined to be a permission error.

[0104] In this implementation, by collecting and analyzing the contextual information that occurs when the video stream times out, multi-dimensional analysis is performed to determine the cause of the video stream timeout, thereby improving the information resolution of the video stream timeout situation, and then implementing differentiated recovery and retry strategies for specific timeout information to improve the recovery and retry efficiency.

[0105] Furthermore, the recovering and retrying the video stream based on the timeout error type until the video stream is restored to a connection includes:

[0106] The first retry delay time is obtained based on the timeout error type. Specifically, the first retry delay time for the network error type, server error type, device error type, and permission error type is designed as follows:

[0107] Network error type: baseDelay = 2000ms (network fluctuations require a shorter waiting time);

[0108] Server error type: baseDelay = 3000ms (server overload requires a long recovery time);

[0109] Device error type: baseDelay = 4000ms (device problems usually require longer recovery time);

[0110] Permission error type: baseDelay = 1000ms (permission issues can usually be resolved quickly).

[0111] Obtain the device importance corresponding to the video stream, and then obtain the second retry delay time and retry count threshold based on the device importance. Specifically, the second retry delay time design for different device importances is as follows:

[0112] High importance (critical monitoring point): priorityFactor = 0.5 (halve the delay time);

[0113] Medium importance (regular monitoring point): priorityFactor = 1.0 (standard delay time);

[0114] Low importance (auxiliary monitoring point): priorityFactor = 1.5 (extend delay time).

[0115] The final retry delay time is calculated based on the first retry delay time and the second retry delay time through the exponential backoff algorithm, and the calculation formula is as follows: finalDelay=baseDelay*(exponential backoff of 1.5)*priority factor priorityFactor.

[0116] The video stream is retried several times based on the final retry delay time until the video stream is reconnected or the number of retry attempts reaches the retry number threshold.

[0117] Specifically, the retry threshold is adjusted according to the difference in device importance: for high importance, the retry threshold is 10 times; for medium importance, the retry threshold is 6 times; for low importance, the retry threshold is 3 times.

[0118] Furthermore, the final retry delay is capped at 30 seconds to prevent the delay from increasing indefinitely, leading to excessively long video stream recovery retries. By setting the retry delay cap, the frequency of video stream recovery retries is guaranteed, thereby improving video stream recovery efficiency.

[0119] Preferably, in a possible embodiment, the video stream is recovered and retried several times based on the final retry delay time until the video stream is restored to connection or the number of recovery retries reaches the retry threshold, including: attempting to recover and retry multiple times through different network paths or server nodes.

[0120] In this implementation, a basic first retry delay is set based on the type of video stream timeout error, and a second retry delay is set based on the device importance of the video stream, resulting in differentiated retry strategies for different video stream timeout situations. Furthermore, this implementation incorporates an exponential backoff algorithm to obtain the final retry delay as the final recovery retry interval, further improving recovery retry efficiency. Furthermore, by attempting multiple recovery retries across different network paths or server nodes, the success rate of video stream recovery is further improved.

[0121] Furthermore, the retrying the video stream several times based on the final retry delay time until the video stream is restored or the number of retry attempts reaches a retry threshold includes:

[0122] Monitor the real-time network packet loss rate, server CPU load rate, and device status corresponding to the video stream;

[0123] Acquire the current environment status of the video stream based on the real-time packet loss rate of the network, the real-time load rate of the server CPU, and the real-time status of the device;

[0124] If the current environmental status meets the preset improvement condition, the video stream is restored and retried.

[0125] Specifically, in a possible embodiment, the step of triggering a recovery retry based on whether the current environmental state meets a preset improvement condition includes:

[0126] Step 1: The system background periodically detects the network status and server load. In one embodiment, the system background detects the network status and server load every two seconds.

[0127] Step 2: Create time series data of network and server status.

[0128] Step 3: Use a sliding window algorithm to analyze the state trend changes of the time series data of the network and server states.

[0129] Step 4. Set and improve different criteria for network error type, server error type, device error type, and permission error type:

[0130] 1) Network improvement conditions: The network packet loss rate drops by more than 30% or there is no packet loss for three consecutive measurements.

[0131] 2) Server improvement conditions: The server CPU load drops by more than 20% or the service CPU load drops below 70%.

[0132] 3) Equipment improvement conditions: The video streaming device is back online or sends normal heartbeat packets.

[0133] Step 5: When the improvement condition is met, immediately trigger the video stream to be retried for recovery without waiting for the retry cycle of the final retry delay time plan.

[0134] Preferably, different sensitivities of improvement condition judgment criteria are set for network error types, server error types, device error types, and permission error types, so as to set differentiated video stream recovery retry strategies for different video stream timeout situations to improve video stream recovery efficiency.

[0135] Preferably, the success rate of the retry triggered by the above-mentioned improved conditions is recorded to optimize future video stream recovery retry triggering decisions and improve the video stream recovery success rate.

[0136] Preferably, a cooling-off period is set for triggering a resumption of retries when conditions are improved, so as to avoid occupation of system resources and waste of resources caused by frequent video stream retries.

[0137] In this implementation, retry is further triggered based on environmental improvement conditions such as improved network conditions or reduced server load. When the current environmental status meets the improvement conditions, recovery retry is immediately triggered without waiting for the time interval of the final recovery retry delay time, thereby improving the video stream recovery efficiency and success rate.

[0138] Furthermore, the recovering and retrying the video stream based on the timeout error type until the video stream is restored to a connection includes:

[0139] In response to timeout actions of a plurality of the video streams, obtaining priorities of all the video streams, and then constructing a video stream priority queue based on the priorities of all the video streams;

[0140] Based on the timeout error type and priority of each video stream, each video stream in the video stream priority queue is recovered and retried in turn.

[0141] In this implementation, for the timeout actions of multiple video streams, a priority recovery strategy is formulated by analyzing the priority of each video stream, so that video streams with high priority are restored and retried first, thereby improving the recovery efficiency of key video streams and improving the efficiency of system resource utilization.

[0142] Furthermore, in response to timeout signals of the plurality of video streams, obtaining the priorities of all the video streams, and then constructing a video stream priority queue based on the priorities of all the video streams, includes:

[0143] For any of the video streams, the user attention, event importance, device importance, and resource occupancy corresponding to the video stream are obtained, and then the priority of the video stream is obtained based on the user attention, event importance, device attention, and resource occupancy. Specifically, the priority calculation steps are as follows:

[0144] Step 1: Initialize the video stream priority score to 0.

[0145] Step 2: Priority scores are accumulated based on device characteristics. For example, a video stream that a user has recently interacted with increases 100 points; a video stream device that a user has marked as a priority increases 50 points; and a video stream device with a major alarm event increases 80 points.

[0146] Furthermore, the importance of video streaming devices is divided into five levels, and the score gradient of each device importance level is 10 points, that is, the device importance increases by 10 points for each level increase.

[0147] Furthermore, the safety area of the video stream is divided into three levels, and the score gradient of each safety area level is 5 points, that is, the safety area level increases by 5 points each time it is upgraded by one level.

[0148] Furthermore, the video stream that triggered the timeout action is deducted based on the current level of system resource usage, with a deduction threshold ranging from 0 to 30 points. Through this deduction mechanism, when system resource usage is high, the priority of newly acquired timed-out video streams is lowered, allowing the system to prioritize high-priority, historically timed-out video streams already in the priority queue, thereby improving the overall efficiency of video stream recovery.

[0149] Step 3: Calculate the final priority score based on the priority score obtained in step 2.

[0150] Step 4: Sort all the video streams based on their priorities, thereby obtaining the video stream priority queue.

[0151] Furthermore, the priority queue updates the video stream priority every five seconds, recalculates the priority score of each video stream in the queue based on real-time information, and thus reprioritizes all video streams to reflect the latest network status, server status, device status and user interaction status, thereby improving the recovery efficiency of key video streams.

[0152] In this implementation, video streams with high user attention, high event importance, high device importance and low resource occupancy are set as high-priority video streams, and the specific priority score of each video stream is calculated based on multiple dimensions such as user attention, event importance, device importance and resource occupancy, so that all the video streams can be sorted to obtain the video stream priority queue, thereby improving the recovery efficiency of key video streams.

[0153] Specifically, the present invention formulates a recovery priority strategy based on the importance of video streams and user attention, among which video streams that users actively click on are restored first; devices that users have marked as paying attention are restored first; monitoring points where abnormal events occur are restored first; and the recovery priority is dynamically adjusted according to the current system resource status, thereby obtaining the video stream priority queue and improving the recovery efficiency of key video streams.

[0154] Furthermore, the recovering and retrying each of the video streams in the video stream priority queue in sequence based on the timeout error type and priority of each of the video streams includes:

[0155] Obtaining system resource occupancy, and then obtaining the number of parallel recovery operations based on the system resource occupancy;

[0156] Based on the parallel recovery quantity and the timeout error type and priority of each video stream, recovery retries are performed on several video streams in the video stream priority queue in sequence.

[0157] Specifically, the system sets the maximum number of devices N that can be restored simultaneously based on the currently available resources, and then takes out the top N video streams with the highest priority from the priority queue and performs recovery retries simultaneously, and removes the devices that have been successfully restored from the priority queue.

[0158] Preferably, the video stream device with a priority score below the threshold in the queue can be replaced by a high-priority video stream with a new timeout action, thereby releasing system resources, optimizing system resource allocation, and further improving the recovery efficiency of key video streams and improving system resource utilization efficiency.

[0159] In this implementation, the maximum number N of video streams that can be recovered and retried simultaneously is set according to the currently available resources of the system, and then the top N video streams with the highest priority are taken out from the video stream priority queue according to high priority sorting and recovered simultaneously, thereby further improving the recovery efficiency of key video streams and improving the efficiency of system resource utilization.

[0160] Furthermore, the video stream timeout recovery method further includes:

[0161] estimating a recovery retry time based on the context information and the number of recovery retries;

[0162] The user is prompted with a recovery retry progress based on the recovery retry time.

[0163] Specifically, in order to optimize the user's video experience, in a possible embodiment, a video stream recovery and retry UI system is constructed to display the video stream timeout status and video stream recovery and retry status to customers and provide users with video stream timeout recovery options, including a progressive loading prompt for displaying the video loading progress and the current stage; an estimated recovery time operation for estimating the recovery time based on historical data and the current status; an alternative solution recommendation solution for recommending alternative video sources or other alternative solutions when the video stream cannot be restored; and a background recovery notification solution for notifying the user after the video is restored when the user has switched to other interfaces.

[0164] The implementation process of the above user experience optimization mechanism is as follows:

[0165] Step 1. Display the corresponding status text according to the current loading stage: if it is in the initial connection request stage of the video stream, display "Requesting video stream" to the user; if it is in the video stream connection establishment stage, display "Establishing connection" to the user; if it is in the video stream playback interruption stage, display "Buffering video" to the user.

[0166] Step 2: Calculate and display the video stream loading progress percentage to the user.

[0167] Step 3: When a timeout is detected in the video stream, the video stream timeout error type is obtained, and an error type prompt is displayed to the user. At the same time, the recovery retry time is estimated based on the context information and the number of recovery retries.

[0168] Step 4: If there is an alternative video source, provide the user with an alternative video source switching plan; if there is no alternative video source, display the video stream recovery and retry plan to the user;

[0169] Step 5: When the video stream is successfully restored, the video stream timeout status is cleared and a successful restoration prompt is displayed. If the user has switched to another interface, a desktop notification is sent to the user.

[0170] This implementation method estimates the recovery retry event and prompts the user with the recovery retry progress, thereby providing the user with clear video stream recovery retry status feedback and expectation management, improving the user experience.

[0171] A second aspect of the present invention provides a video stream timeout recovery system, comprising a multi-stage timeout detection module 100, a timeout error analysis module 200, and a recovery retry module 300, wherein:

[0172] The multi-level timeout detection module 100 is used to detect whether a timeout action occurs in the video stream according to a preset multi-level timeout mechanism;

[0173] The timeout error analysis module 200 obtains the context information of the video stream in response to the timeout action, and then obtains the timeout error type of the video stream based on the context information;

[0174] The recovery and retry module 300 is used to recover and retry the video stream according to the timeout error type until the video stream is restored.

[0175] The video stream timeout recovery method and system provided by the present invention have at least the following advantages over the prior art:

[0176] The above-mentioned video stream timeout recovery method and system do not require the user to manually retry; the method is based on a preset multi-level timeout mechanism detection, and detects whether a timeout action occurs at multiple action nodes of the video stream. When a timeout action occurs in the video stream, the error type that causes the video stream timeout is analyzed based on context information, and then the corresponding recovery retry strategy is executed according to different super error types, thereby implementing differentiated video stream recovery and retry strategies for different levels of timeout error causes, thereby improving the efficiency of video stream timeout recovery.

[0177] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, database or other media used in the embodiments provided in this application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processor involved in the various embodiments provided herein may be, but are not limited to, a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic unit, a data processing logic unit based on quantum computing, and the like.

[0178] The "embodiment" mentioned in this document means that the specific features, structures or characteristics described in conjunction with the embodiment may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment that is mutually exclusive with other embodiments. It is explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments. In order to make the description concise, not all possible combinations of the various technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0179] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make several improvements and substitutions without departing from the scope of the present application, and such improvements and substitutions should also be considered within the scope of protection of the present invention. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A video stream timeout recovery method, characterized in that: Applicable to video streaming, the method comprises the following steps: Detecting the video stream based on a preset multi-level timeout mechanism to confirm that a timeout action has occurred; In response to the timeout action, obtaining context information of the video stream; Acquire a timeout error type of the video stream based on the context information; The video stream is recovered and retried based on the timeout error type until the video stream is restored.

2. A video stream timeout recovery method according to claim 1, characterized in that: The detecting whether the video stream has timed out based on a preset multi-level timeout mechanism includes: Detecting real-time actions of the video stream, and then obtaining the action time of the video stream; If the action time exceeds the preset timeout threshold, confirming that the timeout action occurs; The real-time actions include connection request action, connection establishment action, first frame reception action and playback interruption operation.

3. A video stream timeout recovery method according to claim 1, characterized in that: The context information includes network information, server information, device information, and permission information; and obtaining the timeout error type of the video stream based on the video stream context information includes: Analyze network packet loss rate, network delay, and network continuity based on the network information to obtain a network score; Analyze the server CPU usage, server memory usage, server connection number and server error code based on the server information, and then obtain a server score; Analyze the device's historical offline status, device's historical response status, and device's historical failure frequency based on the device information, and thereby obtain a device score; Analyzing the user authentication status and user access rights based on the permission information, and then obtaining a permission score; The timeout error type of the video stream is obtained based on the network score, the server score, the device score, and the permission score, specifically: If the network score exceeds a preset network score threshold, the video stream is of a network error type; If the server score exceeds a preset server score threshold, the video stream is of server error type; If the device score exceeds a preset device score threshold, the video stream is of device error type; If the permission score exceeds a preset permission score threshold, the video stream is of a permission error type.

4. A video stream timeout recovery method according to claim 1, characterized in that: The recovering and retrying the video stream based on the timeout error type until the video stream is restored to a connection includes: Obtaining a first retry delay time based on the timeout error type; Obtaining the device importance corresponding to the video stream, and then obtaining a second retry delay time and a retry number threshold based on the device importance; Calculating a final retry delay time based on the first retry delay time and the second retry delay time by an exponential backoff algorithm; The video stream is retried several times based on the final retry delay time until the video stream is reconnected or the number of retry attempts reaches the retry number threshold.

5. A video stream timeout recovery method according to claim 4, characterized in that: The retrying the video stream several times based on the final retry delay time until the video stream is restored or the number of retry attempts reaches a retry number threshold includes: Monitor the real-time network packet loss rate, server CPU load rate, and device status corresponding to the video stream; Acquire the current environment status of the video stream based on the real-time packet loss rate of the network, the real-time load rate of the server CPU, and the real-time status of the device; If the current environmental status meets the preset improvement condition, the video stream is restored and retried.

6. A video stream timeout recovery method according to claim 1, characterized in that: The recovering and retrying the video stream based on the timeout error type until the video stream is restored to a connection includes: In response to timeout actions of a plurality of the video streams, obtaining priorities of all the video streams, and then constructing a video stream priority queue based on the priorities of all the video streams; Based on the timeout error type and priority of each video stream, each video stream in the video stream priority queue is recovered and retried in turn.

7. A video stream timeout recovery method according to claim 6, characterized in that: The step of obtaining priorities of all the video streams in response to timeout signals of the plurality of video streams, and then constructing a video stream priority queue based on the priorities of all the video streams, comprises: For any of the video streams, obtaining the user attention, event importance, device importance, and resource occupancy corresponding to the video stream, and then obtaining the priority of the video stream based on the user attention, event importance, device attention, and resource occupancy; All the video streams are sorted based on their priorities, thereby obtaining the video stream priority queue.

8. A video stream timeout recovery method according to claim 6, characterized in that: The recovering and retrying each of the video streams in the video stream priority queue in sequence based on the timeout error type and priority of each of the video streams comprises: Obtaining system resource occupancy, and then obtaining the number of parallel recovery operations based on the system resource occupancy; Based on the parallel recovery quantity and the timeout error type and priority of each video stream, recovery retries are performed on several video streams in the video stream priority queue in sequence.

9. A video stream timeout recovery method according to claim 1, characterized in that: Also includes: estimating a recovery retry time based on the context information and the number of recovery retries; The user is prompted with a recovery retry progress based on the recovery retry time.

10. A video stream timeout recovery system, characterized in that: It includes a multi-level timeout detection module, a timeout error analysis module, and a recovery and retry module, among which: The multi-level timeout detection module is used to detect whether a timeout action occurs in the video stream according to a preset multi-level timeout mechanism; The timeout error analysis module obtains context information of the video stream in response to the timeout action, and further obtains the timeout error type of the video stream based on the context information; The recovery and retry module is used to recover and retry the video stream according to the timeout error type until the video stream is restored.

Images