Weak network delay confrontation method and system applied to Android equipment environment

Abstract

The invention relates to a weak network delay confrontation method and system applied to an Android equipment environment, and the method comprises the steps: monitoring a network environment of an Android client when the Android client carries out the audio and video transmission; when the network environment is lower than 5G, acquiring a data packet arrival timestamp of the Android client in a current period, and constructing a delay time sequence; inputting the delay time sequence into a pre-trained delay prediction model to obtain a delay prediction result of the next period; adjusting an audio and video playing buffer area of the Android client according to the delay prediction result of the next period; determining the packet loss rate of the Android client in the current period; if the packet loss rate of the Android client in the current period is greater than a first packet loss rate threshold value, or the delay prediction result is greater than a first delay threshold value, reducing the code rate of the next period by one stage; and if the packet loss rate of the Android client in the current period is smaller than a second packet loss rate threshold value and the delay prediction result is smaller than a second delay threshold value, the code rate of the next period is increased by one stage.

Description

Technical Field

[0001] This application relates to the field of mobile communication technology, and in particular to a method and system for combating weak network latency in Android device environments. Background Technology

[0002] With the widespread application of mobile communication technology, users' demand for real-time audio and video communication on mobile devices is increasing. In weak network environments, such as when 4G signal coverage is insufficient or the network is unstable, audio and video transmission often encounters high latency, data packet loss, and jitter, resulting in call stuttering, degraded picture quality, or interruption.

[0003] Existing technologies often employ dynamic bitrate adjustment mechanisms to adjust the video encoding bitrate in real time based on changes in current network bandwidth. Simultaneously, buffer optimization strategies are used, such as setting a fixed buffer size to absorb network fluctuations. Furthermore, bandwidth adaptive algorithms are applied to match available bandwidth resources. However, these solutions face multiple challenges in the Android device environment.

[0004] First, dynamic bitrate adjustment is usually based only on the instantaneous network state and lacks the ability to predict future network latency. This causes the bitrate switching decision to lag behind network changes and fail to respond in time to sudden network deterioration, which can easily lead to video stuttering or sudden quality changes.

[0005] Secondly, buffer management strategies often rely on fixed thresholds or simple rules, and cannot dynamically adjust the buffer size according to the predicted latency trend. This results in frequent stuttering due to an excessively small buffer size under weak network conditions, or additional latency due to an excessively large buffer size.

[0006] Furthermore, the Android device ecosystem is highly fragmented, with different manufacturers, system versions, and hardware configurations exhibiting varying network processing mechanisms. Universal optimization solutions struggle to adapt to all devices, leading to performance instability. Particularly during periods of significant network fluctuation, existing technologies fail to effectively combine packet loss rate monitoring and latency prediction for coordinated optimization. The disconnect between bitrate adjustment and buffer management further exacerbates user experience issues. Summary of the Invention

[0007] To at least partially overcome the problems of high latency, data packet loss, and jitter that often occur in audio and video transmission on Android devices in weak network environments, leading to call stuttering, degraded picture quality, or interruption, this application provides a method and system for combating weak network latency in Android device environments.

[0008] The proposed solution is as follows: According to a first aspect of the embodiments of this application, an improved method for combating weak network latency in an Android device environment is provided, comprising: When transmitting audio and video on an Android client, monitor its network environment; When the network environment is below 5G, obtain the arrival timestamps of data packets from the Android client in the current period and construct a delay time series. The delay time series is input into a pre-trained delay prediction model to obtain the delay prediction result for the next period; Based on the delay prediction results for the next cycle, adjust the audio and video playback buffer of the Android client; Determine the packet loss rate of the Android client in the current period; If the packet loss rate of the Android client in the current period is greater than the first packet loss rate threshold, or the delay prediction result is greater than the first delay threshold, then the bitrate of the next period will be reduced by one stage. If the packet loss rate of the Android client in the current period is less than the second packet loss rate threshold, and the delay prediction result is less than the second delay threshold, then the bitrate of the next period will be increased by one stage. Specifically, based on the latency prediction results for the next cycle, adjustments are made to the audio and video playback buffers of the Android client, including: Pre-set the upper limit of the buffer, the lower limit of the buffer, the step value for adjustment, the step value for adjustment, the trigger threshold for adjustment, the trigger threshold for adjustment, and the number of cycles for the stability criterion; Based on the delay time series within the current period, determine the delay jitter amplitude and current buffer latency for the current period; The target buffer delay is the weighted result of the delay prediction result of the next period and the delay jitter amplitude of the current period, and the target buffer delay is limited between the upper limit and the lower limit of the buffer. When the target buffer latency is higher than the current buffer latency and exceeds the upward trigger threshold, the audio and video playback buffer is gradually increased based on the upward step value until the current buffer latency reaches and is not higher than the target buffer latency. When the target buffer latency is lower than the current buffer latency and exceeds the reduction trigger threshold, and the stability criterion period is met continuously, the audio and video playback buffer is gradually reduced based on the reduction step value until the current buffer latency reaches and is not lower than the target buffer latency.

[0009] Preferably, the method further includes: If the current period's bitrate is the minimum bitrate lower limit, then no bitrate reduction phase processing will be performed for the current period; If the current period's bitrate is the lower limit of the highest bitrate, then no bitrate increase phase processing will be performed for the current period.

[0010] Preferably, the method further includes: If the packet loss rate of the Android client exceeds the third packet loss rate threshold within the preset time window and does not show a downward trend, the data packets sent by the server will be detected. Mark abnormal data packets in the data packets sent by the server and suspend the transmission of abnormal data packets; One cycle consists of multiple time windows.

[0011] Preferably, after gradually reducing the audio / video playback buffer based on the downward adjustment step value, the method further includes: Adjust the audio and video playback rate of the Android client by a preset range; Merge consecutive idle or placeholder frames in the audio and video played by the Android client, and delay rendering non-keyframes. Increase the rendering and presentation priority of keyframes.

[0012] Preferably, the delay prediction model is an adaptive weighted moving average prediction model; The adaptive weighted moving average prediction model, after inputting the current period's delay time series, calls the historical smoothed delay prediction results, adaptively allocates the weights of the current period's delay time series and the historical smoothed delay prediction results according to the volatility of the network environment, and outputs the delay prediction results for the next period based on the current period's delay time series, the historical smoothed delay prediction results and their corresponding weights. The volatility is characterized by multiple indicators, including: delay jitter amplitude, delay range, out-of-order ratio, short-term packet loss rate variation amplitude, and arrival time stability. The adaptive weight allocation includes: increasing the weight of the current period's delayed time series when volatility increases, increasing the weight of historical smoothed delayed predictions when volatility decreases, and limiting the weights to preset upper and lower limits, and limiting the magnitude of weight changes to preset step upper limits.

[0013] Preferably, the first packet loss rate threshold is at least twice the second packet loss rate threshold; The first delay threshold is at least twice the second delay threshold.

[0014] Preferably, the bitrate stages are discretized according to a preset bitrate ladder; The bitrate ladder includes a binding combination of video bitrate and audio bitrate, and introduces a protection period when the video resolution, encoding preset, or frame rate changes.

[0015] Preferably, if the packet loss rate of the Android client in the current period is less than the second packet loss rate threshold, and the delay prediction result is less than the second delay threshold, the prediction delay trend is determined based on the delay prediction result; If the predicted delay trend is that the predicted delay value shows a monotonically increasing relationship within a period of no less than a preset number of consecutive cycles, the preset collaborative strategy is executed. The collaborative strategy includes at least one of the following strategies: Adjust the keyframe interval parameter of the video encoder to reduce the amount of data bursts per unit time; Reduce the number of enhancement layers in scalable video coding to prioritize the continuous transmission of base layer data.

[0016] According to a second aspect of the embodiments of this application, an improved weak network latency mitigation system applied to an Android device environment is provided, comprising: Processor and memory; The processor and memory are connected via a communication bus: The processor is used to call and execute the program stored in the memory; The memory is used to store a program, which is at least used to execute a weak network latency countermeasure method applied to an Android device environment as described in any of the above.

[0017] The technical solution provided in this application may include the following beneficial effects: This technical solution achieves coordinated optimization of bitrate adjustment and buffer management by predicting network latency trends in real time and dynamically adjusting buffer and bitrate strategies. It effectively addresses latency and packet loss issues in weak network environments, has the ability to predict network latency trends in real time, and can optimize buffer and bitrate strategies in advance, effectively reducing audio and video stuttering and improving the user experience in weak network environments.

[0018] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] Figure 1 This is a flowchart illustrating a method for mitigating weak network latency in an Android device environment, provided in one embodiment of this application. Figure 2 This is a schematic diagram of a weak network latency mitigation system applied to an Android device environment, provided by one embodiment of this application.

[0021] Reference numerals: Processor-21; Memory-22. Detailed Implementation

[0022] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0023] Example 1 In mobile communication applications, Android devices experience transmission instability and quality degradation when conducting audio and video communication under weak network conditions. Traditional fixed-rate solutions struggle to adapt to the diversity and volatility of network environments, leading to stuttering and packet loss during data transmission. The root cause of this problem lies in insufficient real-time network status monitoring and delayed response of adjustment strategies. This prevents the system from responding promptly to network changes, impacting the continuity and reliability of audio and video transmission. Furthermore, signal attenuation caused by network fluctuations is not effectively quantified, resulting in a mismatch between buffer configuration and bitrate adjustment.

[0024] For example, in a subway tunnel environment, when an Android mobile device makes a real-time video call, the network environment is constantly changing due to discontinuous and fluctuating 4G signal coverage. In this scenario, traditional fixed bitrate solutions cannot dynamically respond to signal attenuation, the sequence fluctuations of data packet arrival timestamps are not monitored, and the audio and video playback buffer capacity is fixed, leading to frequent video freezing and audio interruptions. Simultaneously, the increased packet loss rate is caused by network jitter, resulting in decreased communication quality. Users need to repeatedly operate to maintain the connection, and the latency characteristics of network environments below 5G are not predicted, further exacerbating the risk of transmission interruption.

[0025] If the above problems are not addressed, audio and video communication under weak network conditions will struggle to meet basic quality of service requirements, leading to communication interruptions and reduced data transmission efficiency. The overall performance of mobile communication systems will be weakened, user dissatisfaction with services will increase, and the popularity and usage of related applications will be affected. Resource waste and user experience degradation caused by network fluctuations will persist for a long time, further hindering the effective application of mobile communication technology in complex environments.

[0026] Figure 1 This is a flowchart illustrating a method for mitigating weak network latency in an Android device environment, provided in one embodiment of this application. (Refer to...) Figure 1 A method for mitigating latency issues in weak network environments, applicable to Android devices, includes: S11: Monitor the network environment when transmitting audio and video on the Android client; S12: When the network environment is below 5G, obtain the arrival timestamps of data packets from the Android client in the current period and construct a delay time series; S13: Input the delayed time series into the pre-trained delay prediction model to obtain the delay prediction result for the next period; S14: Adjust the audio and video playback buffer of the Android client based on the delay prediction results of the next cycle; S15: Determine the packet loss rate of the Android client in the current period; S16: If the packet loss rate of the Android client in the current period is greater than the first packet loss rate threshold, or the delay prediction result is greater than the first delay threshold, then the bitrate of the next period will be reduced by one stage. S17: If the packet loss rate of the Android client in the current period is less than the second packet loss rate threshold, and the delay prediction result is less than the second delay threshold, then the bitrate of the next period will be increased by one stage.

[0027] This embodiment relates to a method for combating network latency in Android device environments. Network environment monitoring refers to the process of collecting network signal strength, bandwidth, and connection status in real time during audio and video transmission on Android clients. This can be achieved by periodically polling the network interface status or listening to system network event callbacks. For example, network type information can be obtained through the ConnectivityManager class provided by the Android system. The main purpose is to continuously track network conditions and provide basic data support for subsequent decisions.

[0028] Delay time series construction refers to generating time series data based on the arrival timestamps of data packets received within the current period. This can be achieved by arranging the timestamps in the order of receipt to form a sequence or by calculating the difference between adjacent timestamps as sequence elements. For example, timestamps can be converted into millisecond-level time differences and stored as an array structure. Its main purpose is to quantify the network delay fluctuation characteristics and use them as input for prediction models.

[0029] A delay prediction model is a mathematical model used to infer the delay value of the next cycle based on the current cycle delay time series. It can be implemented using an autoregressive moving average prediction model (ARMA) or a long short-term memory neural network (LSTM), such as a regression prediction algorithm trained on historical delay data. Its main purpose is to achieve early prediction of network state changes and avoid the lag of traditional reactive strategies.

[0030] Audio and video playback buffer adjustment refers to the operation of dynamically changing the buffer storage capacity based on the delay prediction result. It can be achieved by linearly scaling the buffer size according to the predicted delay value or by directly setting the target buffer delay based on a threshold range. For example, the target buffer delay can be set to 1.5 times the predicted delay and limited to a preset range. Its main purpose is to absorb network jitter to maintain playback continuity.

[0031] Packet loss rate determination refers to the proportion of data packets that are not successfully received within the current period. It can be achieved by comparing the difference between the sent sequence number and the received sequence number or by parsing the network layer packet loss report. For example, the packet loss rate can be calculated through the packet loss tolerance mechanism in the RTP protocol. Its main purpose is to provide a quantitative indicator of network quality to support bitrate decisions.

[0032] As a preferred implementation, the bitrate adjustment logic is triggered by both packet loss rate and latency prediction results. The bitrate stage can be implemented using equally spaced discrete steps or non-uniform steps predefined based on service requirements. For example, the video bitrate can be divided into three fixed levels: 500kbps, 1Mbps, and 2Mbps. This is mainly to reduce the transmission load when the packet loss rate exceeds the threshold or the predicted latency deteriorates, and to gradually improve the quality when the network improves in order to balance smoothness and image quality.

[0033] Therefore, the core innovation of this application lies in generating forward-looking latency prediction results through a latency prediction model, and using this to drive the coordinated dynamic adjustment of the buffer and bitrate. This transforms the traditional reactive strategy that relies solely on the current network state into a prediction-based proactive prevention mechanism, effectively solving the problem of stuttering and experience degradation caused by the inability of the fixed bitrate method to adapt to environmental fluctuations under weak network conditions, while avoiding unnecessary resource consumption under stable network conditions.

[0034] As one specific implementation, the Android client can be a smartphone device running the Android 11 operating system.

[0035] Preferably, the first packet loss rate threshold is at least twice the second packet loss rate threshold; The first delay threshold is at least twice the second delay threshold.

[0036] For example, the first packet loss rate threshold is 5%, the second packet loss rate threshold is 2%; the first latency threshold is 300ms, and the second latency threshold is 150ms.

[0037] If the packet loss rate of the Android client in the current period is >5%, or the delay prediction result is >300ms, then the bitrate of the next period will be reduced by one stage. If the Android client has a packet loss rate of less than 2% and a latency of less than 150ms in the current cycle, the bitrate for the next cycle will be increased by one stage.

[0038] Specifically, the solution in this application sets the first packet loss rate threshold to at least twice the second packet loss rate threshold, so that the system maintains the current bitrate state when the packet loss rate is between the second and first thresholds, avoiding unnecessary bitrate adjustment operations triggered by small fluctuations in the packet loss rate. At the same time, setting the first delay threshold to at least twice the second delay threshold ensures that the buffer and bitrate remain stable when the delay prediction result changes within a reasonable range. Thus, by constructing a lag region formed by the proportional relationship, the sensitivity of bitrate adjustment is effectively suppressed, ensuring a smooth transition of audio and video transmission.

[0039] The above solution effectively reduces the frequency of bitrate adjustments, avoids oscillations in audio and video transmission, and improves the stability and smoothness of the user experience.

[0040] Preferably, the bitrate stages are discretized according to a preset bitrate ladder; Bitrate ladders include a binding combination of video bitrate and audio bitrate, and introduce a protection period when video resolution, encoding preset, or frame rate changes.

[0041] The preset bitrate ladder refers to dividing continuous bitrate changes into discrete ladder levels. It can be implemented using equally spaced bitrate values ​​or non-linear intervals based on network conditions. Its purpose is to avoid frequent bitrate switching caused by network fluctuations, making the adjustment process more controllable and predictable. The bitrate ladder includes the binding combination of video and audio bitrates. This can be understood as the video and audio bitrates changing synchronously as a whole unit during the bitrate adjustment phase. It can be implemented using predefined bitrate pairs or dynamically calculated binding relationships. Its purpose is to prevent audio and video from being out of sync and improve playback coordination. The protection duration specifically refers to a fixed time window set after a parameter switching event occurs. It can be implemented using a timer mechanism or a trigger signal based on the switching event. Its purpose is to prevent multiple triggers of bitrate adjustment in a short period of time and ensure a smooth and stable transition process.

[0042] Specifically, the solution in this application discretizes the bitrate stages into preset bitrate steps, and combines audio and video bitrate binding with a protection period mechanism to achieve structured management of bitrate adjustment. When a video resolution, encoding parameter, or frame rate switching event is detected, the system immediately introduces a protection period to suspend the bitrate stage adjustment request. During this period, the discretization of the bitrate steps ensures a step-by-step change in adjustment, avoiding instability caused by continuous adjustments. At the same time, the binding combination of audio and video bitrates ensures that they change synchronously, preventing audio and video desynchronization caused by individual adjustments. After the protection period ends, the system adjusts the bitrate stage within the discrete steps based on network monitoring results, thus forming a complete closed loop of bitrate management and effectively responding to fluctuations caused by parameter switching.

[0043] Preferably, when the Android client detects a change in video resolution, the system immediately activates a protection timer. During this period, bitrate adjustment is frozen, maintaining the current bitrate level. Simultaneously, the bitrate ladder is configured with multiple discrete levels, each level specifying a combination of video bitrate and corresponding audio bitrate. For example, low, medium, and high levels correspond to basic, standard, and high-quality audio and video transmission requirements, respectively. After the protection period ends, the system selects an appropriate bitrate level within the preset bitrate ladder for adjustment based on network environment monitoring results.

[0044] Through the above solution, this application effectively reduces the frequent bitrate adjustments caused by video resolution, encoding parameters or frame rate switching, avoids sudden changes in audio and video quality and playback stuttering, and improves the continuity of audio and video transmission and user experience in weak network environments.

[0045] Example 2 It should be noted that the method also includes: If the current period's bitrate is the minimum bitrate lower limit, then no bitrate reduction phase processing will be performed for the current period; If the current period's bitrate is the lower limit of the highest bitrate, then no bitrate increase phase processing will be performed for the current period.

[0046] The minimum bitrate limit refers to the lowest threshold during the bitrate adjustment process. It can be set to a preset fixed baseline value or dynamically determined according to the device's decoding capability. Its purpose is to prevent the audio and video quality from being severely degraded due to excessively low bitrate. The maximum bitrate limit refers to the highest threshold during the bitrate adjustment process. It can be set based on the network bandwidth limit or the encoder's processing capability. Its purpose is to avoid network congestion or waste of system resources caused by excessively high bitrate.

[0047] Specifically, during the bitrate adjustment decision-making phase, the system monitors the bitrate status of the current period in real time. When the bitrate reaches the minimum bitrate lower limit, the system automatically suppresses the execution of processing instructions during the falling phase, thereby maintaining the basic playability of audio and video. When the bitrate reaches the maximum bitrate lower limit, the system automatically suppresses the execution of processing instructions during the rising phase, thereby preventing an increase in packet loss rate or latency fluctuations due to data overload. This boundary protection mechanism works in conjunction with network environment monitoring and latency prediction models to ensure that bitrate adjustments are always performed within feasible limits, avoiding the disruption of transmission continuity caused by invalid operations.

[0048] When the Android client is running in a weak network environment, if it detects that the current bitrate is already at the minimum bitrate limit, the system will maintain the current bitrate even if the network packet loss rate exceeds the threshold. Similarly, if the bitrate is already at the maximum bitrate limit, the system will ignore requests to increase the bitrate, thereby ensuring the stability of the transmission process.

[0049] Through the above solution, this application effectively prevents invalid adjustment operations at bitrate boundaries, avoids audio and video transmission interruptions and quality degradation, and improves the reliability and user experience of audio and video communication in weak network environments.

[0050] Example 3 It should be noted that the method also includes: If the packet loss rate of the Android client exceeds the third packet loss rate threshold within the preset time window and does not show a downward trend, the data packets sent by the server will be detected. Mark abnormal data packets in the data packets sent by the server and suspend the transmission of abnormal data packets; One cycle consists of multiple time windows.

[0051] The preset time window refers to a fixed time interval used to evaluate the network status. It can be implemented using a sliding window mechanism or a fixed time slice method, with the aim of providing fine-grained packet loss rate monitoring.

[0052] The third packet loss rate threshold can be understood as the critical value that triggers anomaly detection. It can be dynamically set based on historical network data or preset to a fixed percentage. Its purpose is to distinguish between normal network fluctuations and persistent packet loss problems.

[0053] The absence of a decreasing trend in packet loss rate specifically refers to the packet loss rate remaining stable or increasing within a time window sequence. This can be achieved through linear regression analysis or moving average trend judgment, with the aim of avoiding erroneous responses to instantaneous network jitter.

[0054] Server-side packet inspection refers to the process of verifying the integrity and timing validity of data packets. It can be implemented using checksum verification or sequence number continuity checks, with the aim of accurately locating anomalies at the data packet level.

[0055] Abnormal data packet marking can be understood as attaching identification information to detected invalid data packets. It can be implemented through metadata marking or special data header settings, and its purpose is to facilitate identification in subsequent processing.

[0056] Suspending the transmission of abnormal data packets specifically refers to temporarily halting the transmission of marked data packets. This can be achieved by adjusting flow control protocols or retransmission policies, with the aim of blocking invalid data streams from occupying network resources.

[0057] A cycle comprising multiple time windows refers to dividing the monitoring period into smaller evaluation units. This can be achieved by dividing the period into equal time intervals or by dynamically adjusting the number of windows. The purpose is to improve the accuracy of packet loss rate assessment and the sensitivity of trend judgment.

[0058] Specifically, the proposed solution triggers a server-side packet detection mechanism by combining a packet loss rate threshold with trend analysis. When the packet loss rate consistently exceeds a third packet loss rate threshold within a preset time window without showing a downward trend, the system automatically initiates a packet integrity verification process. This verification process directly affects the packets sent by the server, identifying and marking corrupted or out-of-order abnormal packets through a verification mechanism. The transmission of these abnormal packets is then suspended to block invalid data streams. Furthermore, due to the structural design that divides a period into multiple time windows, packet loss rate assessment is performed on a more granular time scale, enabling the system to more accurately capture the continuous trend of packet loss rate changes. This mechanism, by distinguishing between network transmission failures and server-side data anomalies, avoids the blind reliance on bitrate adjustments alone, ensuring targeted elimination of the root cause of problems in scenarios with persistently high packet loss.

[0059] The specific implementation is as follows: The Android client divides each period into 20 time windows of 500 milliseconds each. When the packet loss rate exceeds 15% for five consecutive time windows and does not show a decreasing trend, the client sends a packet detection request to the server. The server uses the CRC32 checksum algorithm to verify the integrity of the packets, marks packets that fail the checksum as abnormal, and suspends the retransmission of these abnormal packets through the TCP sliding window mechanism. During this process, the client continues to receive normal packets to maintain basic communication, while simultaneously feeding back the abnormal packet information to the server for subsequent optimization.

[0060] Through the above solution, this application can accurately identify the difference between abnormal data packets on the server side and network transmission problems, avoid invalid bitrate adjustment operations in continuous high packet loss scenarios, reduce client processing burden and network resource consumption, effectively prevent further deterioration of audio and video transmission quality, and thus improve communication stability and user experience in weak network environments.

[0061] Example 4 It should be noted that, based on the latency prediction results for the next cycle, adjustments will be made to the audio and video playback buffers of the Android client, including: Pre-set the upper limit of the buffer, the lower limit of the buffer, the step value for adjustment, the step value for adjustment, the trigger threshold for adjustment, the trigger threshold for adjustment, and the number of cycles for the stability criterion; Based on the delay time series within the current period, determine the delay jitter amplitude and current buffer latency for the current period; The target buffer latency is calculated by weighting the delay prediction result of the next period with the delay jitter amplitude of the current period, and the target buffer latency is limited to between the upper and lower limits of the buffer. When the target buffer latency is higher than the current buffer latency and exceeds the upward trigger threshold, the audio and video playback buffer is gradually increased based on the upward step value until the current buffer latency reaches and is not higher than the target buffer latency. When the target buffer latency is lower than the current buffer latency and exceeds the reduction trigger threshold, and the stability criterion period is met continuously, the audio and video playback buffer is gradually reduced based on the reduction step value until the current buffer latency reaches and is not lower than the target buffer latency.

[0062] Among them, the buffer upper limit is a preset upper limit to prevent the buffer from becoming too large and causing an increase in latency. It can be implemented by a dynamic calculation method based on network bandwidth characteristics. The buffer lower limit is a preset lower limit to avoid lag caused by an excessively small buffer. It can be implemented using statistical methods based on historical network stability. The upstep and downstep values ​​refer to the incremental parameters that control the adjustment range of the buffer, which can be implemented using a fixed step size or an adaptive step size algorithm. Raising and lowering the trigger threshold refer to the critical values ​​for adjusting the trigger buffer, which can be achieved using dynamic thresholds based on the current network jitter level. The stability criterion period number refers to the number of consecutive periods that ensure network trend stability, which can be achieved using a sliding window mechanism. Delay jitter is a quantitative indicator of network latency fluctuation, which can be calculated using the range or standard deviation of a time series. The target buffer delay refers to the expected buffer delay that combines the prediction results and real-time jitter, and it can be achieved using a weighted average algorithm.

[0063] Specifically, the solution in this application constructs an adjustment framework by pre-setting parameters such as buffer upper limit and buffer lower limit. It determines the delay jitter amplitude and current buffer delay based on the current period delay time series to quantify the network state. The target buffer delay is obtained by weighting the delay prediction result of the next period with the delay jitter amplitude and limiting it within a safe range. When the target buffer delay exceeds the upward adjustment trigger threshold, the buffer is gradually increased based on the upward adjustment step value. When the target buffer delay is lower than the downward adjustment trigger threshold and the stability criterion period is met continuously, the buffer is gradually decreased based on the downward adjustment step value, thereby achieving smooth and stable buffer adjustment.

[0064] The specific implementation is as follows: When the Android client detects that the network environment is below 5G, it constructs a delay time series by collecting the arrival timestamps of data packets and calculates the delay jitter amplitude of the current period; it pre-sets the upper and lower limits of the buffer to define the safe range of the buffer, and uses fixed small increments for the upward and downward adjustment steps. The upward and downward trigger thresholds are dynamically set according to the degree of network fluctuation, and the stability criterion period number is set to a number of consecutive periods; when the target buffer delay is higher than the current buffer delay and exceeds the upward trigger threshold, the buffer is gradually increased in fixed steps; when the target buffer delay is lower than the current buffer delay and continuously meets the stability criterion period number, the buffer is gradually decreased in fixed steps.

[0065] The above technical solution effectively avoids frequent abrupt changes and oscillations in buffer adjustment, reduces audio and video playback stuttering and sudden increases in latency, and thus maintains a stable user experience in weak network environments.

[0066] Furthermore, after gradually reducing the audio and video playback buffer based on adjusting the step value, the method also includes: Adjust the audio and video playback rate of the Android client by a preset range; Merge consecutive idle or placeholder frames in the audio and video played by the Android client, and delay rendering non-keyframes. Increase the rendering and presentation priority of keyframes.

[0067] Among them, adjusting the audio and video playback rate by a preset amplitude refers to dynamically adjusting the playback speed according to the data supply status of the buffer. This can be achieved by using a feedback control algorithm based on the buffer level or a preset rate adjustment table. The purpose is to avoid abrupt stuttering caused by insufficient data, while ensuring that the rate change is smooth and perceptible, and maintaining the continuity of the user's auditory and visual experience. Merging consecutive idle or placeholder frames refers to identifying and integrating redundant frame data to reduce invalid rendering overhead. This can be achieved using frame content similarity analysis algorithms or predefined idle frame pattern matching mechanisms. The goal is to prioritize the release of system resources for critical content transmission, thereby maximizing the use of limited bandwidth when data is scarce. Improving the rendering and presentation priority of keyframes means giving keyframes a higher processing weight in resource scheduling. This can be achieved by using priority queue scheduling strategies or real-time task allocation mechanisms. The purpose is to ensure the integrity of the video infrastructure and prevent screen tearing or quality collapse caused by weak network fluctuations.

[0068] Specifically, the solution proposed in this application directly responds to changes in data supply through dynamic fine-tuning of the playback rate, avoiding the risk of playback interruption caused by buffer shrinkage. Simultaneously, the frame merging operation reduces redundant rendering overhead, and the resources freed up are allocated in real-time to the keyframe processing stage. Furthermore, the increased priority of keyframes ensures that core information is decoded and displayed preferentially in resource scheduling, forming an organic synergistic mechanism. Because the data supply status changes after the buffer shrinks, the system smoothly adjusts the playback rate based on a preset amplitude, thereby maintaining a dynamic balance between data flow and playback demand. On this basis, consecutive idle or placeholder frames are identified and merged to reduce rendering load, non-keyframe rendering tasks are delayed, and the freed computing resources are concentrated on the timely decoding of keyframes, thus effectively addressing the problem of tight data supply in weak network environments.

[0069] The specific implementation is as follows: In the Android client, as the audio and video playback buffer is gradually reduced, the system dynamically fine-tunes the playback rate to be slightly lower or higher than the nominal rate range to adapt to the real-time data stream; at the same time, it detects continuous idle frames (such as static background images) in the audio and video stream, merges them into a single frame representation, and postpones the rendering tasks of non-critical frames (such as P-frames) to periods when the system load is low; in addition, critical frames (such as I-frames) are given the highest rendering priority to ensure that they are decoded and displayed first in the resource scheduling queue.

[0070] Through the above solution, this application effectively alleviates the problem of data supply shortage caused by buffer shrinkage, significantly reduces the probability of audio and video stuttering and quality fluctuations in weak network environments, and ensures the continuity and stability of user communication experience.

[0071] Example 5 It should be noted that the delayed prediction model is an adaptive weighted moving average prediction model; The adaptive weighted moving average prediction model, after inputting the current period's delay time series, calls the historical smoothed delay prediction results, adaptively allocates the weights of the current period's delay time series and the historical smoothed delay prediction results according to the volatility of the network environment, and outputs the delay prediction results for the next period based on the current period's delay time series, the historical smoothed delay prediction results and their corresponding weights. Among them, volatility is characterized by multiple indicators, including: delay jitter amplitude, delay range, out-of-order ratio, short-term packet loss rate variation amplitude, and arrival time stability. The adaptive weight allocation includes: increasing the weight of the current period's delayed time series when volatility increases, increasing the weight of historical smoothed delayed predictions when volatility decreases, and limiting the weights to preset upper and lower limits, and limiting the magnitude of weight changes to preset step upper limits.

[0072] Among them, the adaptive weighted moving average prediction model can be understood as a prediction mechanism that dynamically adjusts data dependencies based on network status. It can be implemented using a weight optimization algorithm based on feedback control, and its purpose is to solve the problem of insufficient adaptability of the fixed weight method in a fluctuating environment. Historical smoothing delay prediction results refer to reference values ​​generated after trending historical delay data. These can be achieved using exponential smoothing or low-pass filtering methods, with the aim of preserving the long-term trend characteristics of the network state. Volatility can be understood as a comprehensive quantitative representation of the instability of the network environment. It can be calculated by integrating multiple network performance indicators, and its purpose is to fully capture the essential characteristics of network volatility. Delay jitter refers to the degree of dispersion of the delay time, which can be calculated using statistical variance or standard deviation. Its purpose is to reflect the intensity of random fluctuations in the delay. The delay range refers to the difference between the maximum and minimum delay, which reflects the extreme range of delay variation; the out-of-order ratio refers to the proportion of data packets arriving out of order, which can be detected by sequence number continuity detection. The short-term packet loss rate variation refers to the fluctuation of the packet loss rate within a short time window, which can be evaluated using the difference method. Arrival time stability refers to the regularity of data packet arrival times, which can be achieved through time series autocorrelation analysis. Adaptive weight allocation refers to a strategy that dynamically adjusts the contribution of data sources based on volatility. It can be implemented using threshold switching or continuous function mapping, with the aim of balancing real-time response capability and historical trend stability. Weight constraints can be understood as a safety constraint mechanism for weight parameters. It can set the weights to change linearly within a reasonable range, with the magnitude of the change being controlled. Its purpose is to avoid prediction oscillations caused by sudden changes in weights.

[0073] Specifically, the proposed solution uses an adaptive weighted moving average prediction model to achieve dynamic coupling between network state and prediction parameters. During periods of severe network fluctuations, real-time data is prioritized to capture abrupt changes, while historical data is emphasized to maintain prediction stability during periods of network stability. This results in a highly adaptable and robust delayed prediction mechanism.

[0074] Through the above scheme, this application can dynamically optimize the delay prediction process according to the actual fluctuation state of the network environment, effectively avoiding the problem of delayed response or oversensitivity in a stable state of the fixed weight method during violent fluctuations. It significantly improves the accuracy and reliability of the delay prediction results, thereby providing a precise decision basis for buffer adjustment and bit rate control, reducing the stuttering phenomenon of audio and video transmission in weak network environments, and ensuring a smooth experience for users under complex network conditions.

[0075] Example 6 It should be noted that if the packet loss rate of the Android client in the current period is less than the second packet loss rate threshold, and the delay prediction result is less than the second delay threshold, the prediction delay trend is determined based on the delay prediction result. If the predicted delay trend is that the predicted delay value shows a monotonically increasing relationship within a period of no less than a preset number of consecutive cycles, the preset collaborative strategy is executed. The collaborative strategy includes at least one of the following strategies: Adjust the keyframe interval parameter of the video encoder to reduce the amount of data bursts per unit time; Reduce the number of enhancement layers in scalable video coding to prioritize the continuous transmission of base layer data.

[0076] Among them, judging the predicted delay trend based on the delay prediction results refers to identifying the evolution direction of network delay by analyzing the continuous change pattern of historical delay prediction data. This can be achieved by using statistical methods such as the sliding window averaging method or the exponential smoothing model. The purpose is to transform instantaneous prediction values ​​into trend analysis and capture the signs of network fluctuations in advance. The execution of the preset collaborative strategy can be understood as the proactive triggering of an alternative optimization mechanism when a worsening latency trend is detected. This can be achieved using a predefined strategy table or a rule-based decision engine, with the aim of avoiding network overload caused by blindly increasing the bitrate. Increasing the keyframe interval refers to extending the time interval between keyframe transmissions. This can be achieved by dynamically adjusting the keyframe insertion frequency parameter of the video encoder. The purpose is to reduce the data transmission pressure per unit time and reduce sudden traffic surges. Reducing the number of scalable coding layers refers to trimming unnecessary data layers in the layered coding structure. This can be achieved by selectively discarding enhancement layers or reducing inter-layer dependencies. The goal is to prioritize the reliability of the base layer transmission, sacrificing some image quality details for overall smooth transmission.

[0077] Specifically, the solution of this application introduces a dynamic latency trend perception mechanism when the bitrate increase condition is met. It uses the continuous change pattern of historical prediction data to identify the latency increase trend. When the trend continues to rise, it actively executes a collaborative strategy, including increasing the key frame interval to reduce data transmission pressure and reducing the number of scalable coding layers to prioritize the transmission of the base layer. This avoids bitrate increase operations in potential network deterioration scenarios, prevents the chain of negative effects caused by network overload, and maintains the continuity and stability of audio and video transmission.

[0078] Through the above scheme, this application can effectively avoid blindly increasing the bit rate due to the rising latency trend when the conditions of low packet loss rate and low latency prediction are met, thereby preventing the network burden from increasing, reducing the subsequent surge in packet loss rate or latency deterioration, and significantly improving the continuity and stability of audio and video transmission in weak network environments.

[0079] Example 7 Figure 2 This is a schematic diagram of a weak network latency mitigation system applied to an Android device environment, provided in one embodiment of this application. (Refer to...) Figure 2 A weak network latency mitigation system for Android devices includes: Processor 21 and memory 22; Processor 21 and memory 22 are connected via a communication bus: The processor 21 is used to call and execute the program stored in the memory 22; The memory 22 is used to store a program, which is at least used to execute a weak network latency countermeasure method applied to an Android device environment as described in the above embodiments.

[0080] It is understood that the same or similar parts in the above embodiments can be referred to each other, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0081] It should be noted that in the description of this application, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this application, unless otherwise stated, "a plurality of" means at least two.

[0082] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the function involved, as will be understood by those skilled in the art to which embodiments of this application pertain.

[0083] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0084] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it includes one or a combination of the steps of the method embodiments.

[0085] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0086] The storage media mentioned above can be read-only memory, disk, or optical disk, etc.

[0087] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0088] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A weak network delay countermeasure method applied to an Android device environment, characterized in that, The method comprises the following steps: monitoring the network environment of the Android client during audio and video transmission; when the network environment is lower than 5G, obtaining the packet arrival timestamp of the Android client in the current period, and constructing a delay time sequence; inputting the delay time sequence into a pre-trained delay prediction model to obtain a delay prediction result of the next period; adjusting the audio and video playback buffer of the Android client according to the delay prediction result of the next period; determining the packet loss rate of the Android client in the current period; if the packet loss rate of the Android client in the current period is greater than a first packet loss rate threshold, or the delay prediction result is greater than a first delay threshold, then the code rate of the next period is decreased by one stage; if the packet loss rate of the Android client in the current period is less than a second packet loss rate threshold, and the delay prediction result is less than a second delay threshold, then the code rate of the next period is increased by one stage; wherein, according to the delay prediction result of the next period, adjusting the audio and video playback buffer of the Android client comprises: pre-setting a buffer upper limit value, a buffer lower limit value, an up-regulation step value, a down-regulation step value, an up-regulation trigger threshold, a down-regulation trigger threshold, and a stable criterion period number; determining the delay jitter amplitude and the current buffer delay of the current period according to the delay time sequence in the current period; using the weighted result of the delay prediction result of the next period and the delay jitter amplitude of the current period as a target buffer delay, and limiting the target buffer delay between the buffer upper limit value and the buffer lower limit value; when the target buffer delay is higher than the current buffer delay and exceeds the up-regulation trigger threshold, gradually increasing the audio and video playback buffer based on the up-regulation step value until the current buffer delay reaches and is not higher than the target buffer delay; when the target buffer delay is lower than the current buffer delay and exceeds the down-regulation trigger threshold, and continuously meets the stable criterion period number, gradually reducing the audio and video playback buffer based on the down-regulation step value until the current buffer delay reaches and is not lower than the target buffer delay.

2. The method of claim 1, wherein, The method further comprises: if the code rate of the current period is the lowest code rate lower limit, then no decrease stage processing is performed on the code rate of the current period; if the code rate of the current period is the highest code rate lower limit, then no increase stage processing is performed on the code rate of the current period.

3. The method of claim 1, wherein, The method further comprises: if the packet loss rate of the Android client in a preset time window exceeds a third packet loss rate threshold and no downward trend appears, then detecting the data packets sent by the server; marking the abnormal data packets in the data packets sent by the server, and pausing the sending of the abnormal data packets; wherein, one period comprises a plurality of time windows.

4. The method of claim 1, wherein, After gradually reducing the audio and video playback buffer based on the down-regulation step value, the method further comprises: adjusting the audio and video playback rate of the Android client by a preset amplitude; merging consecutive idle frames or placeholder frames in the audio and video played by the Android client, and delaying the rendering of non-key frames; improving the rendering and presentation priority of key frames.

5. The method of claim 1, wherein, The delay prediction model is an adaptive weighted moving average prediction model. The adaptive weighted moving average prediction model calls historical smoothed delay prediction results after inputting the delay time series of the current period, adaptively allocates the weights of the delay time series of the current period and the historical smoothed delay prediction results according to the fluctuation degree of the network environment, and outputs the delay prediction result of the next period according to the delay time series of the current period, the historical smoothed delay prediction result and the corresponding weights. The fluctuation degree is represented by multiple indexes, including: delay jitter amplitude, delay range, out-of-order ratio, short-time packet loss rate change amplitude and arrival time stability. The adaptive weight allocation includes: increasing the weight of the delay time series of the current period when the fluctuation degree rises, increasing the weight of the historical smoothed delay prediction when the fluctuation degree falls, limiting the weight within a preset upper and lower limit, and limiting the weight change amplitude within a preset step upper limit.

6. The method of claim 1, wherein, The first packet loss rate threshold is at least twice the second packet loss rate threshold. The first delay threshold is at least twice the second delay threshold.

7. The method of claim 1, wherein, The stages of the code rate are discretized according to preset code rate steps. The code rate steps include a bound combination of video code rate and audio code rate, and a protection time length is introduced when the video resolution, encoding preset or frame rate is switched.

8. The method of claim 1, wherein, If the packet loss rate of the Android client in the current period is less than the second packet loss rate threshold, and the delay prediction result is less than the second delay threshold, the prediction delay trend is determined according to the delay prediction result. If the prediction delay trend is that the predicted delay value shows a monotonic increasing relationship in consecutive periods not less than a preset number of times, a preset cooperative strategy is executed. The cooperative strategy includes at least one of the following strategies: Adjusting the key frame interval parameter of the video encoder to reduce the data burst quantity per unit time; Reducing the number of enhancement layers in scalable video coding to preferentially guarantee the continuous transmission of basic layer data.

9. A weak network delay countermeasure system applied to an Android device environment, characterized in that, It includes: a processor and a memory; The processor and the memory are connected through a communication bus: The processor is used to call and execute the program stored in the memory. The memory is used to store programs, and the programs are used to execute the method of claim 1-8.

Images