Key frame cache and stall self-recovery transmission method and system of cloud interactive terminal

Abstract

This invention belongs to the field of streaming media transmission technology. It provides a keyframe caching and stuttering self-healing transmission method and system for cloud-based interactive terminals. The method includes: achieving instant first-frame playback through multi-role permission isolation, keyframe caching, and retransmission; combining dual-channel detection of hidden stuttering and implementing layered self-healing according to a strategy; controlling resource release through keyframe request frequency limiting and grace period sleep mechanisms; addressing the cache pollution problem caused by parallel streaming of new and old streams, calculating the cleaning waiting window based on fragment transmission latency and asynchronous signaling delay, predicting conflict risks, clearing the cache after confirming the old stream link is disconnected, binding a unique identifier to the bitstream and constructing same-source verification rules, updating the cache with a clean bitstream and issuing decoding context, while filtering invalid keyframe requests; this invention effectively solves the cache pollution and playback anomaly problems caused by parallel streaming of new and old bitstreams through latency prediction, residual data cleanup, same-source isolation, and signaling filtering, ensuring same-source decoding and achieving seamless switching between new and old streams.

Description

Technical Field

[0001] This invention belongs to the field of streaming media transmission technology, specifically a key frame caching and stuttering self-healing transmission method and system for cloud-based interactive terminals. Background Technology

[0002] In real-time audio and video transmission systems, stream switching is a high-frequency operation scenario for cloud-based interactive terminals. While existing systems can meet the basic management and control requirements for steady-state operation of a single stream, they have significant shortcomings in cache management and link timing control during new stream switching.

[0003] When the old streaming source is not completely disconnected and the new streaming source simultaneously initiates an access request, the old and new streams run concurrently, causing multiple technical problems. The server lacks risk prediction and continuous verification methods before streaming switching, and cannot quantify the network latency of residual data from the old streaming source. When the old streaming link is not completely disconnected and delayed segments are not fully received, the old and new streams are mixed and written to the same buffer area, causing a mismatch between decoder parameters and keyframes, resulting in repeated black screens, screen tearing, stuttering, and flickering. Simultaneously, the server lacks stream tracing and dynamic isolation mechanisms. Delayed segments from the old streaming source arrive late after the switch, and are mistakenly identified as continuously polluting the cache with new streaming data. Furthermore, the uplink keyframe request signaling from the pull stream lacks matching verification with the streaming source. Requests abnormally triggered by delayed segments from the old streaming source are forwarded normally, causing unnecessary cache refreshes and parameter reloading, further exacerbating the room playback disorder.

[0004] To address this, the present invention provides a method and system for keyframe caching and stuttering self-healing transmission in a cloud-based interactive terminal. Summary of the Invention

[0005] In order to overcome the shortcomings of the prior art, at least one technical problem raised in the background art is solved.

[0006] The technical solution adopted by this invention to solve its technical problem is: a key frame caching and stuttering self-healing transmission method for cloud-based interactive terminals, comprising the following steps: Step 1: The push and pull ends connect to the room relay service respectively. The server verifies the access permissions and distinguishes between ordinary viewing clients and control-only clients. If the current access party is a new push end, the server clears the room's historical cache, synchronously establishes the mapping relationship between the room status and the user connection, and builds the basic communication framework. Step 2: Based on the basic communication framework, the server parses the video stream from the push end, identifies and caches the SPS / PPS parameter set and IDR keyframes. When a new ordinary viewing client joins the meeting, it resends the cached frames and requests keyframes from the push end. It only controls the client to forward control commands and provides basic decoding data for the pull end. Step 3: Based on the decoding base data, the streaming end synchronously monitors the data packet reception time and screen rendering time to identify hidden stutters. Combined with the user's activity status, the stutter critical time is dynamically adjusted, and the layered self-healing is carried out according to the low cost priority strategy, and key frame recovery requests are initiated. Step 4: For keyframe requests, the streaming end responds to the keyframe request with frequency limiting and calls the encoder to output synchronous IDR frames; when there are no viewing clients in the room, a grace period timer is started. If no new users join during the grace period, the image acquisition and encoder work are stopped to release cloud computing power and network resources.

[0007] As a further aspect of the present invention: In step two, the process of identifying and caching the SPS / PPS parameter set and IDR keyframes is as follows: The server obtains the RTP-encapsulated video stream from the streaming end through the media receiving channel; Each RTP packet is decapsulated, the NAL unit is extracted, and identification is performed by reading the type field in the header of the NAL unit; When a NAL unit of type SPS or PPS is identified, the server updates the complete parameter set data to the parameter set cache corresponding to the streaming source. When an IDR frame is identified, the server stores the encoded data of the IDR frame along with the associated current SPS / PPS parameter set into the keyframe buffer, overwriting the previously cached old IDR frames.

[0008] As a further aspect of the present invention: in step three, the process of identifying hidden stutters is as follows: After the streaming end completes decoder initialization and starts rendering, it starts monitoring the screen rendering time. The decoded video frames are sent to the rendering queue, and the timestamp difference between each frame entering the rendering queue and being actually drawn to the screen is recorded. When the difference continues to increase or exceeds the preset absolute threshold and does not match the vertical synchronization interval, it is determined to be a hidden stutter. As a further aspect of the present invention, the keyframe buffering and stuttering self-healing transmission method further includes the following steps: Step S1: In response to the new streaming client's room access request, the server opens the streaming switching mutex lock, collects video segment transmission latency and connection signaling asynchronous latency indicators, calculates the waiting window period for cleaning up residual data in the old streaming link, and identifies the risk of parallel conflict between the new and old streaming. Step S2: If it is determined that there is a risk of parallel conflict, continuously check the status of the old push stream connection link and the uplink buffer stagnant bit stream. After the old push stream link is completely disconnected and all uplink delayed fragments are received, clear the video configuration, SPS / PPS parameter set, IDR key frame cache and cached P / B video frame data stored locally. Step S3: Complete the cache resource reset operation, bind a unique push stream identifier to each uplink bitstream, construct real-time same-source bitstream verification and matching rules, filter delayed segments that are not currently active push streams, and intercept heterogeneous bitstreams written to video configuration, SPS / PPS parameter set, IDR keyframe and P / B video frame buffer area. Step S4: Update the room's global keyframe cache with a clean bitstream that has passed the same-source verification, send matching decoding context data to the online streaming end, identify and intercept keyframe request signaling triggered by heterogeneous bitstreams, and only retain the valid signaling corresponding to the currently active streaming for forwarding.

[0009] As a further aspect of the present invention: In step S1, the process of calculating the waiting window period for cleaning up residual data in the old push stream link is as follows: Based on the real-time collected average transmission latency of video segments and asynchronous latency of connection signaling, and superimposed with network jitter redundancy duration, the waiting window period for cleaning up residual data in old push links is dynamically calculated. The waiting window for cleaning up residual data in the old push link is the sum of the average transmission latency of video segments, the asynchronous latency of connection signaling, and the network jitter redundancy duration. Among them, the network jitter redundancy duration is taken as a multiple of the standard deviation of historical transmission delay.

[0010] As a further aspect of the present invention: In step S1, the process of identifying the risk of parallel conflict between new and old push streams is as follows: Based on the estimated end time of the old push link being completely cleared and the remaining fragments being fully received, it is determined whether there is an overlap in the working timing of the old and new push links; If there is an overlap in time periods, it is determined that there is a risk of conflict.

[0011] As a further aspect of the present invention: In step S3, the process of binding a unique push stream identifier to each uplink bitstream is as follows: The server performs a global reset and calibration of local video cache resources; The video configuration cache, SPS / PPS parameter set cache, IDR keyframe cache and P / B video frame cache, which were cleared, will be uniformly restored to their initial blank state. At the same time, the mutex lock for push stream switching is kept locked to prevent unverified and unfamiliar bit streams from being written to the buffer area in advance; Once the cache resource reset is complete, the stream identifier generation program assigns a globally unique stream identifier to each new uplink stream and binds it to the current room stream session.

[0012] As a further aspect of the present invention: In step S3, the process of constructing real-time same-source code stream verification and matching rules is as follows: Based on the unique identifier of the bound push stream, the server builds the same source code stream verification and matching rules to adapt to the push stream switching scenario, and establishes a unique admission mechanism for cache writing; The specific rules are as follows: only video segments and frame data carrying the unique identifier of the current active push stream have local cache write permissions. All messages, segments, and frame data that are not the unique identifier of the current active push stream are judged as heterogeneous illegal bitstreams and are prohibited from being written to the cache area.

[0013] As a further aspect of the present invention: In step S4, the process of updating the room's global keyframe cache using a clean bitstream that has passed source verification is as follows: Based on the same source stream verification and matching rules, the uplink new push stream data is filtered in real time, heterogeneous old stream fragments are eliminated, and only pure stream data carrying the unique identifier of the current active push stream is retained; Based on the clean new streaming bitstream, the room's global cache resources are iteratively updated, refreshing the global video configuration, SPS / PPS parameter set, IDR keyframes and P / B video frame cache one by one, replacing the blank initialization data in the cache, and completing the full coverage update of the room's global bitstream cache.

[0014] The keyframe caching and stuttering self-healing transmission system for cloud-based interactive terminals includes the following modules: Push stream access authentication module: The push stream end and pull stream end respectively connect to the room relay service. The server verifies the access permission and distinguishes between ordinary viewing clients and control-only clients. If the current access party is a new push stream end, the server clears the room's historical cache, synchronously establishes the mapping relationship between the room status and the user connection, and builds the basic communication framework. The bitstream caching and resending module is based on the basic communication framework. The server parses the video bitstream from the push end, identifies and caches the SPS / PPS parameter set and IDR keyframes. When a new ordinary viewing client joins the meeting, the cached frames are resent and the keyframes are requested from the push end. The module only controls the client to forward control commands and provides basic decoding data for the pull end. Layered self-healing module for stuttering: Based on decoding base data, the streaming end synchronously monitors the data packet reception time and screen rendering time to identify hidden stuttering. It dynamically adjusts the critical stuttering time in combination with the user's activity status, and self-heals in layers according to a low-cost priority strategy and initiates key frame recovery requests. Frequency limiting and sleep control module: In response to key frame requests, the streaming end limits the frequency of the key frame request and calls the encoder to output synchronous IDR frames; when there are no viewing clients in the room, a grace period timer is started. If no new users are connected within the grace period, the image acquisition and encoder work are stopped to release cloud computing power and network resources. The latency prediction and risk control module responds to the room access request from the new streaming end, opens the streaming switching mutex lock on the server, collects video segment transmission latency and connection signaling asynchronous latency indicators, calculates the waiting window period for cleaning up residual data in the old streaming link, and identifies the risk of parallel conflict between the new and old streaming. Old stream monitoring and clearing module: If it is determined that there is a risk of parallel conflict, it continuously checks the status of the old push stream connection link and the stray bit stream in the uplink buffer. After the old push stream link is completely disconnected and all uplink delayed fragments are received, it clears the video configuration, SPS / PPS parameter set, IDR key frame cache and cached P / B video frame data stored locally. Same-source identifier isolation module: completes cache resource reset operation, binds a unique push stream identifier to each uplink bitstream, constructs real-time same-source bitstream verification and matching rules, filters delayed fragments that are not currently active push streams, and intercepts heterogeneous bitstreams from being written into video configuration, SPS / PPS parameter sets, IDR keyframes and P / B video frame buffer areas. Pure stream distribution module: Updates the room's global keyframe cache with pure streams that have passed same-source verification, sends matching decoding context data to online streaming terminals, identifies and intercepts keyframe request signaling triggered by heterogeneous streams, and only retains valid signaling corresponding to the currently active streaming for forwarding.

[0015] The beneficial effects of this invention are as follows: By implementing push-pull streaming interaction, client roles are differentiated for access and resources are isolated, distinguishing between ordinary viewing clients and control-only clients and allocating media forwarding resources as needed, thus solving the problem of control terminals ineffectively occupying bandwidth and reducing system resource consumption; Automatic cache clearing and link status reset are triggered by new stream access, preventing old stream residue from causing decoder reference frame errors; Real-time caching of SPS / PPS parameter sets and IDR keyframes on the server side and proactive resending to newly joined terminals solves the problems of first-frame black screen and decoding initialization delay, improving broadcast response speed; Dual-layer monitoring combined with user activity status to set dynamic stuttering thresholds compensates for the inability of traditional network monitoring to identify implicit rendering stuttering, improving playback smoothness in weak network environments; Keyframe request frequency limiting merging and grace period resource hibernation reclamation prevent concurrent requests from impacting the encoder and idle resources from running idle. Building upon this foundation, full-process risk management is achieved through push stream switching scheduling. Relying on switching mutex locks, network latency collection, and dynamic window period calculation, the problems of unquantifiable residual fragments in weak networks and difficulty in predicting conflicts between new and old push streams are solved, enabling early identification of switching risks. By continuously monitoring link and cache status in conflict scenarios, the problem of incomplete cleaning of heterogeneous data in old streams is effectively solved, completing data purification before switching. By assigning a unique identifier to the new push stream and constructing same-source code stream verification rules, the problems of lagging old stream fragments and heterogeneous code streams polluting the cache are solved, ensuring that cached data is single and of the same source throughout the process. By updating the global cache with a same-source clean code stream, issuing decoding context, and intercepting abnormal signaling, the problems of switching screen distortion and decoding errors caused by mixed parameters of new and old code streams and timing conflicts are solved, ultimately achieving a smooth and seamless switching between new and old push streams. Attached Figure Description

[0016] The invention will now be further described with reference to the accompanying drawings.

[0017] Figure 1 This is a flowchart of the key frame caching and stuttering self-healing transmission method for a cloud-based interactive terminal as described in Embodiment 1 of the present invention; Figure 2 This is a logic judgment diagram of the key frame caching and stuttering self-healing transmission method for the cloud interactive terminal described in Embodiment 1 of the present invention; Figure 3 This is a flowchart of the key frame caching and stuttering self-healing transmission method for a cloud-based interactive terminal as described in Embodiment 2 of the present invention; Figure 4 This is a logic judgment diagram of the key frame caching and stuttering self-healing transmission method for the cloud interactive terminal described in Embodiment 2 of the present invention; Figure 5 This is a flowchart of the keyframe caching and stuttering self-healing transmission method for cloud-based interactive terminals described in this invention. Detailed Implementation

[0018] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below in conjunction with specific embodiments.

[0019] Example 1: Please refer to Figure 1-2 As shown in the embodiment of the present invention, the keyframe caching and stuttering self-healing transmission method for a cloud-based interactive terminal includes the following steps: Step 1: The push and pull ends connect to the room relay service respectively. The server verifies the access permissions and distinguishes between ordinary viewing clients and control-only clients. If the current access party is a new push end, the server clears the room's historical cache, synchronously establishes the mapping relationship between the room status and the user connection, and builds the basic communication framework. In step one, the push and pull streams are connected to the room relay service, and the server verifies access permissions and distinguishes between ordinary viewing clients and control-only clients as follows: The push and pull streams initiate access requests to the room relay service through a signaling channel. The request message includes: unique device identifier, target room number, time-sensitive authentication token, and client type label. It should be noted that the signaling channel is a communication channel used between the client and the server to exchange control messages; The client type tag is injected when the token is issued, including: viewer (ordinary viewing client) and controller (controlling client only), which are used by the server to distinguish roles; After receiving the access request, the server verifies the validity of the authentication token's signature. If the verification fails, the connection is rejected directly; if the verification succeeds, the client type tag in the token is read. If the tag is "viewer", it will be marked as a regular viewing client and media downlink forwarding resources will be pre-allocated; If the tag is controller, it is marked as controlling only the client, and only the signaling and control command forwarding channel is allocated; In step one, the process of determining new streams and clearing historical cache is as follows: The server maintains the stream source identifier of the currently active streaming endpoint in the room status object. The identifier is composed of the unique device identifier of the streaming endpoint and the stream name. When a streaming client connects, the server compares the identifier of the newly connected streaming source with the currently recorded streaming source identifier. If there is no streaming client in the room, or the new identifier does not match the current identifier, the server determines that the currently connected client is a new streaming client. If a new streaming source is identified, the server immediately performs a historical cache clearing operation, which includes: clearing the Sequence Parameter Set (SPS), Image Parameter Set (PPS), and the most recent Instant Decoding Refresh Keyframe (IDR) data in the server-side cache, and resetting the transmission congestion control window, packet loss statistics, and other states related to the room, to ensure that subsequent viewing clients will not receive residual bitstream data belonging to the old streaming source, and to avoid reference frame corruption in the decoder; In step one, the process of establishing the mapping relationship between room status and user connection, and building the basic communication framework, is as follows: The server creates a room status object in memory for each room, which includes: the connection handle of the streaming client, the list of connection handles of the viewing client, the list of connection handles of the control client, and the network transmission address and current activation status of each connection. When any client connects or disconnects, the corresponding list in the room status object is added or deleted synchronously, and the change event is notified to the media forwarding module and the control command routing module to establish a link mapping relationship based on the room. It should be noted that the media forwarding module is a functional unit within the server responsible for copying and distributing audio and video streams, while the control command routing module is a functional unit within the server responsible for signaling routing and delivering control commands. Understandably, the significance of step one is that by identifying access to clients with different roles and differentiating media resource allocation, permission isolation is achieved, avoiding the situation where only the client occupies invalid bandwidth. At the same time, through the cache clearing and state reset mechanism triggered by the new streaming end, the potential risks of data crosstalk and decoding black screen during multi-source switching are eliminated, laying the foundation for building a reliable basic communication framework in the future. Step 2: Based on the basic communication framework, the server parses the video stream from the push end, identifies and caches the SPS / PPS parameter set and IDR keyframes. When a new ordinary viewing client joins the meeting, it resends the cached frames and requests keyframes from the push end. It only controls the client to forward control commands and provides basic decoding data for the pull end. In step two, based on the basic communication framework, the process by which the server parses the video stream from the push end, identifies and caches the SPS / PPS parameter set and IDR keyframes is as follows: The server obtains the video stream encapsulated in Real-Time Transport Protocol (RTP) from the streaming end through the established media receiving channel; It should be noted that once the streaming client is connected and verified, a media receiving channel is established between the server and the streaming client. The incoming RTP packets are decapsulated, and the Network Abstraction Layer (NAL) units are extracted. The type field in the header of the NAL unit is read for identification. When a NAL unit of type SPS parameter set or PPS parameter set is identified, the server updates the complete parameter set data to the parameter set cache area corresponding to the streaming source. When an IDR frame is identified, the server stores the encoded data of the IDR frame along with the associated current SPS / PPS parameter set into the keyframe buffer and overwrites the previously cached old IDR frames. For non-SPS parameter sets, PPS parameter sets, and IDR keyframes, P-frames (forward prediction frames) and B-frames (bidirectional prediction frames) that only record the difference data relative to the reference frame are not cached for a long time and are forwarded or discarded as needed. For example, see Table 1 below for an example of NAL unit processing rules; Table 1: NAL Unit Code Stream Parsing and Cache Processing Rules; In step two, the process of resending cached frames and requesting keyframes from the streaming client when a new regular viewing client joins the service is as follows: When the server detects a new connection from a regular viewing client in the room status object, it immediately performs a resend of cached frames. The media transmission channel pushes cached SPS / PPS parameter set data to newly joined viewing clients and pushes cached IDR keyframe data, enabling the client decoder to obtain parameter initialization and the first complete refresh frame, thus achieving fast rendering of the first frame. While resending cached frames, the server generates a keyframe request signaling and sends it to the streaming end via the signaling channel, requesting the streaming end encoder to output a new IDR frame. This ensures that subsequent streams start from the new keyframe and seamlessly connect with the cached frames already received by newly joined viewing clients, preventing decoding delays caused by excessively long time intervals between cached frames and subsequent frames. For clients that only control the client, the server does not perform video stream parsing and caching operations, does not establish media channels or push media data, but only uses the signaling channel to establish a two-way control command forwarding path, forwarding the control commands issued by the control client to the streaming end in real time and in an orderly manner, and sending back the control response or status returned by the streaming end to the control client, ensuring low latency and reliability of the command path. Understandably, the significance of step two lies in the fact that by actively caching and intelligently resending key decoding information in the bitstream on the server side, the problem of waiting for the first frame and the black screen when a new viewer joins the group is eliminated. At the same time, by distinguishing the transmission strategy that only controls the client, the unnecessary occupation of the server's downlink bandwidth and computing resources is effectively reduced. The timely key frame request initiated to the push streaming end provides a clean and consistent decoding starting point for the subsequent pull streaming end, which is the basic capability support for the recovery of stuttering. Step 3: Based on the decoding base data, the streaming end synchronously monitors the data packet reception time and screen rendering time to identify hidden stutters. Combined with the user's activity status, the stutter critical time is dynamically adjusted, and the layered self-healing is carried out according to the low cost priority strategy, and key frame recovery requests are initiated. In step three, the process of identifying hidden lag and dynamically adjusting the critical lag duration based on user activity is as follows: After the streaming end completes decoder initialization and starts rendering, it initiates a dual monitoring mechanism, with specific monitoring metrics including: Data packet reception time monitoring: Record the time difference from the first to the last RTP packet in the same video frame at the frame level, and also record the interval between the completion times of adjacent complete frames. If the interval between the completion of receiving multiple consecutive frames exceeds the expected frame interval and the deviation is not caused by network jitter, it is marked as a suspected stutter on the receiving side. For example: The streaming end pushes a video stream at a frame rate of 30fps. The normal frame interval is 33ms. When the receiving intervals of three consecutive frames are 78ms, 80ms and 81ms respectively, all of which are far beyond the normal value, and there are multiple timeouts without packet loss, it indicates that the data arrival rate is continuously decreasing, and it is marked as a suspected stutter on the receiving side. Rendering time monitoring: The decoder sends the decoded video frames into the rendering queue and records the time stamp difference between each frame entering the rendering queue and being actually drawn to the screen. When the difference continues to increase or exceeds the preset absolute threshold and does not match the vertical synchronization interval, it is determined to be a hidden stutter. At this time, the video may freeze but no obvious network packet loss alarm is generated. For example: the streaming client pushes a video stream at a frame rate of 30fps, with a normal rendering interval of about 33ms. The preset absolute threshold is set to 120ms. After the decoder sends the frame into the rendering queue, the timestamp difference between the three consecutive frames from queuing to actual rendering is 70ms, 80ms, and 90ms, respectively, which are all far beyond the normal millisecond-level rendering time. Or the rendering time of a single frame suddenly rises to 180ms while the frames before and after are normal. In both cases, the network layer indicators are normal, and it is determined to be a hidden stutter. It should be noted that the data packet reception time monitoring and the screen rendering time monitoring constitute a two-layer stuttering detection system: the former is located at the transport layer and detects abnormalities in the time when the bit stream arrives at the client from the network, while the latter is located at the application layer and detects abnormalities in the time within the decoding and rendering pipeline. The combination of the two layers of monitoring enables stuttering detection to cover the entire link from the network entry point to the screen output, solving the application layer stuttering problem that cannot be detected by a single network layer monitoring. The streaming client defines the user's active state by capturing user input events; If an input event occurs within a preset time (5s), it is marked as active; otherwise, it is marked as inactive. It should be noted that user input events are usually accompanied by continuous operations, such as dragging a progress bar or typing text. From the initiation to completion of a single operation, plus a short pause to observe the feedback effect, a complete micro-interaction cycle is formed within 3 to 5 seconds. If there are no input events for more than 5 seconds, it can be reasonably inferred that the user has stopped actively operating. At the same time, the 5-second window is sufficient to smooth out misjudgments caused by short pauses in the user and avoid frequent switching between active and inactive states. The stuttering threshold duration is dynamically set based on the active state: In the active state, the threshold for determining the duration of stuttering is set to 150ms, that is, a valid stuttering event is confirmed when the continuous packet receiving or rendering timeout reaches 150ms; In the inactive state, the threshold is relaxed to 300ms to avoid excessively frequent recovery operations that bring additional bandwidth and power consumption. If any indicator in the dual monitoring exceeds the corresponding threshold duration in the active state, the self-healing process is triggered. It should be noted that the active state is 150ms: when the end-to-end latency exceeds 150ms, the human eye begins to perceive the discontinuity of the image. Aligning the threshold with the perception boundary can trigger recovery before the user notices it. The inactive state is 300ms: relaxing it to 300ms can filter out fluctuations of less than a second in instantaneous network jitter and avoid frequent triggering of recovery operations. In step three, the process of the low-cost priority strategy layered self-healing and initiating keyframe recovery requests is as follows: After a stuttering event is triggered, the streaming client executes the recovery strategy in the following order: First layer: Request keyframe: The streaming end sends a PLI (Picture Loss Indication) request to the server, requesting the streaming end to output a new IDR keyframe. The request also carries the current stuttering indicator and activity status for the server to merge and limit. At the same time, a recovery waiting timer is started, with the waiting time set to 3 times the current round-trip time (RTT). If a new IDR frame is received within the waiting time and the decoding output returns to smooth, the self-healing is successful and the process ends. It should be noted that the waiting time is set to 3 times RTT based on the following: 1 times RTT covers the PLI request uplink, 1 times RTT covers the IDR frame downlink, and the remaining 1 times RTT covers the encoding scheduling and transmission time and reserves jitter buffer to avoid the waiting time being too short, which may lead to misjudgment of timeout and premature entry into the next layer for recovery. Second layer: Retransmit video parameters: If the first layer fails to recover, the streaming end sends a video parameter retransmission request to the server. After receiving the request, the server retransmits the latest cached SPS / PPS parameter set to the streaming end through the media channel. After receiving the request, the streaming end calls the decoder interface to reconfigure the parameter set and attempts to decode the subsequent bitstream. If the decoding is restored, the self-healing is successful and the process ends. Layer 3: Refreshing the route and reconnecting the transmission channel: If the second layer still fails to recover, the streaming end sends a route refresh request. The server selects a new available media transmission route for the streaming end based on the current network topology and link quality detection results. At the same time, the streaming end disconnects the current media transmission channel, clears the local transport layer session state, and re-initiates media channel negotiation and establishment based on the new route information returned by the server. After the new channel is successfully established, the server resends the cached SPS / PPS parameter set and the latest IDR keyframe through the new channel. The streaming end completes decoder reset and resumes rendering. After a lag is triggered, repair operations are performed sequentially, as shown in Table 2 below for examples; Table 2: Implementation of the Layered Self-Healing Strategy; Understandably, the significance of step three lies in: through dual-channel monitoring of data packet reception and screen rendering, it accurately captures hidden stuttering that is difficult to detect by traditional network statistics, introduces the user's activity status into the dynamic adjustment of the stuttering critical time, and at the same time, the layered self-healing mechanism strictly follows the recovery order of low-cost retransmission first and high-cost key frame request later, ensuring a steady improvement in the smoothness of the viewing end in weak network environments. Step 4: For keyframe requests, the streaming end responds to the keyframe request with frequency limiting and calls the encoder to output synchronous IDR frames; when there are no viewing clients in the room, a grace period timer is started. If no new users join during the grace period, the image acquisition and encoder work are stopped to release cloud computing power and network resources. In step four, the process of the streaming end responding to the keyframe request by limiting the frequency and calling the encoder to output a synchronous IDR frame is as follows: The streaming end maintains a keyframe sending timer window and a request counter, and sets a minimum IDR frame sending interval (e.g., 1 second). When a valid keyframe request is received, if the time since the last forced output of an IDR frame is less than 1 second, the request will be buffered. At the end of the current 1-second window, IDR frame encoding will be triggered only once. Multiple accumulated requests will be merged and responded to prevent the encoder from being impacted by frequent encoding of high-data-volume IDR frames in a short period of time, and avoid instantaneous bandwidth and encoding quality jitter. By issuing a forced IDR frame generation command through the encoder API, the encoder takes the latest acquired frame as the starting point, clears the reference frame buffer, outputs a complete synchronized IDR frame and the associated parameter set, and uses it as the basis to restart encoding subsequent prediction frames. IDR frames are transmitted to the server through the media receiving channel, and the server distributes them to all streaming clients through the media sending channel corresponding to each client. In step four, when there are no viewing clients in the room, a grace period timer is started. If no new users join during the grace period, the image capture and encoder work are stopped, releasing cloud computing power and network resources. The server monitors the length of the client connection list in real time through the room status object. When the length of the list changes from non-zero to zero (i.e. the last ordinary client leaves), the server records the current timestamp and starts a grace period timer. The grace period duration is configurable, with a typical value of 30 seconds. During the grace period, the streaming end continues to capture and encode images, while the server maintains the connection status of the media receiving channel and suspends the forwarding of the bitstream on all media sending channels. If a new regular viewing client connects before the grace period timer expires, the timer is canceled, normal media stream forwarding is restored, cached frames are resent, and the server-side resource status returns to active status. If the grace period timer expires and no new viewing clients join, the server sends a hibernation control command to the streaming client. After receiving the instruction, the streaming end executes the following steps in sequence: stop frame capture by the camera and other image acquisition hardware, call the encoder shutdown interface to release the encoder instance and associated memory and hardware acceleration resources, and close the media receiving channel to stop sending media data, while only maintaining the signaling connection to listen for wake-up commands; With the release of cloud computing power and uplink network bandwidth, when a new viewing client joins the meeting at any time, the server sends a wake-up command to the dormant streaming end through the signaling channel. The streaming end restarts the image acquisition, initializes the encoder, rebuilds the media receiving channel, and resumes normal streaming after the first IDR frame is output. The server resends the cached frames, and the service is restored across the entire link. Understandably, the significance of step four lies in: effectively curbing keyframe request storms in multi-client scenarios through the intelligent frequency limiting mechanism of the streaming end, protecting the encoder from violent impacts, maintaining bitrate smoothness, and achieving true on-demand service based on the grace period resource reclamation strategy of the number of viewing clients. It automatically releases cloud encoding and decoding computing resources and network bandwidth during idle periods when no one is watching, effectively avoiding resource idleness, and can seamlessly and quickly wake up when new users arrive, achieving a balance between resource utilization efficiency and availability.

[0020] Example 2: Please refer to Figure 1-2 As shown, based on Embodiment 1, the keyframe caching and stuttering self-healing transmission method for cloud-based interactive terminals described in this embodiment of the invention further includes the following steps: Step S1: In response to the new streaming client's room access request, the server opens the streaming switching mutex lock, collects video segment transmission latency and connection signaling asynchronous latency indicators, calculates the waiting window period for cleaning up residual data in the old streaming link, and identifies the risk of parallel conflict between the new and old streaming. In step S1, the process of the server opening the streaming switching mutex lock in response to the new streaming room access request is as follows: The server continuously listens for uplink push stream access signaling. When a new push stream client initiates an access request message, it wakes up the push stream pre-switching program, pauses unnecessary cache refresh and parameter updates, and locks the current push stream session running state. It should be noted that the streaming pre-switching program is a streaming media switching scheduling logic that is deployed during the system initialization phase and resides in the background. It is used for pre-processing work in response to the scenario of alternating between new and old streaming streams. The moment the access request is responded to, the server immediately calls and applies a push stream switching mutex lock to globally lock operations such as bitstream cache reading and writing, parameter overwriting, link state changes, and frame cache updates. Before the lock is released, it will not respond to other push stream switching requests to avoid parameter corruption caused by concurrent push stream operations of the old and new streams. It should be noted that the mutex is a global resource lock at the streaming media session level. It is pre-initialized and resident in memory to manage concurrency issues during streaming switching scenarios. In step S1, the process of collecting video fragment transmission delay and connection signaling asynchronous delay indicators is as follows: Latency is collected based on message sending and receiving timestamps. The uplink sending timestamp and the server receiving timestamp of video segments are recorded frame by frame. The transmission time of multiple consecutive frames of segments is collected and the average value is calculated to obtain the average transmission latency of video segments. For example: The streaming client sends 3 video segments, and the timestamp of each segment is recorded as follows: Fragment 1: Sending time 0ms, receiving time 12ms → Elapsed time 12ms; Fragment 2: Sending time 10ms, receiving time 23ms → Elapsed time 13ms; Fragment 3: Sending time 20ms, receiving time 31ms → Elapsed time 11ms; The average transmission latency of the video segments is 12ms; Meanwhile, the time difference between the issuance time of the old push link disconnection signaling and the actual completion time of the link disconnection will be used as the asynchronous delay indicator of connection signaling. In step S1, the process of calculating the waiting window period for cleaning up residual data in the old push stream link is as follows: Based on the real-time collected average transmission latency of video segments and asynchronous latency of connection signaling, and superimposed with network jitter redundancy duration, the waiting window period for cleaning up residual data in old push links is dynamically calculated. To elaborate further, the waiting window for cleaning up residual data in the old push stream link is the sum of the average transmission latency of video segments, the asynchronous latency of connection signaling, and the network jitter redundancy duration. It should be noted that the network jitter redundancy duration is a multiple of the historical transmission latency standard deviation. The multiple is configured according to the tolerance of the business scenario for residual data: in standard mode, it is 2 times the standard deviation, covering about 95% of jitter scenarios, balancing switching timeliness and data purity; in zero-tolerance mode, it is 3 times the standard deviation, covering about 99.7% of jitter scenarios, in order to appropriately extend the waiting window period in exchange for the absolute cleanup of residual data. The waiting window period is dynamically calculated by superimposing multi-dimensional latency indicators. For example, see Table 3 below. Table 3: Calculation of the waiting window period for cleaning up residual data from old push streams; In step S1, the process of identifying the risk of parallel conflict between new and old push streams is as follows: Based on the push stream access ready time, and combined with the estimated end time of the old push stream link being completely cleared and the remaining fragments being completely received during the waiting window period, it is determined whether there is an overlapping interval in the working timing of the new and old push stream links; The criteria for determining whether the old push stream link is completely cleared and the remaining fragments are received intact are: Standard 1: The old push stream link handle is completely released, all connection resources are reclaimed, and there is no new message reception behavior; Standard 2: The uplink buffer queue is cleared, with no residual video stream or segment data; Standard 3: Meets the preset waiting window period, with no delays or out-of-order old push stream fragments arriving across timeframes; Standard 4: The old push stream offline status remains unchanged, and there are no abnormal situations such as link reconnection or intermittent packet transmission; It should be noted that "time-lapse arrival" refers to the abnormal message phenomenon where video segments that originally belonged to the old push stream arrive at the server with a delay across cycles after the server issues the old push stream link disconnect command and completes the preset residual data cleanup window period. This is due to the influence of weak network jitter and asynchronous network transmission. "Continuous solidification" means that the state of the old push stream link being closed is not a temporary state, but a long-term stable locked and fixed offline state without rebound. If there is no time overlap, then there is no risk of parallel conflict. If there is a time overlap, it is determined that there is a risk of conflict due to the parallel push of new and old streams and the mixing of code streams; Understandably, the significance of this step lies in the following: by locking protection, quantifying and statistically analyzing network latency, accurately calculating dynamic window periods and comparing time-series overlaps, it enables advance risk prediction before streaming switching, solving the problems of traditional streaming switching being unable to quantify residual data lag time and unable to identify parallel mixing risks in advance, and providing accurate time-series judgment basis for subsequent old stream data cleaning, cache reset, and stream isolation. Step S2: If it is determined that there is a risk of parallel conflict, continuously check the status of the old push stream connection link and the uplink buffer stagnant bit stream. After the old push stream link is completely disconnected and all uplink delayed fragments are received, clear the video configuration, SPS / PPS parameter set, IDR key frame cache and cached P / B video frame data stored locally. In step S2, if a risk of parallel conflict is determined, the process of continuously verifying the status of the old push stream connection link and the stray bitstream in the uplink buffer is as follows: If a risk of parallel conflict is determined, the server will immediately start continuous monitoring of the old push stream link and cached data, terminate the seamless switch execution, lock the current push stream cache read and write permissions, and prohibit the new push stream from being written to the local cache area in advance. It should be noted that the continuous monitoring program is a pre-built, resident background monitoring logic in the server-side streaming media switching scheduling system, responsible for polling the link status, traversing the cache queue, and monitoring the convergence of residual fragments during the push stream switching waiting window. The server performs double verification of the old push stream running status and the cached data status at a fixed sampling period (100ms); It should be noted that a sampling period of 100ms can quickly detect residual old stream fragments and link anomalies in the uplink buffer, avoiding decoding disorder caused by missed detection of delayed packets, and will not significantly increase server computing power due to excessive polling, thus balancing monitoring sensitivity and cloud resource consumption. Real-time monitoring of old push stream link handle resources, heartbeat signals, and connection callback status to confirm the link disconnection progress; It should be noted that the link handle is used to identify the server resources occupied by the push stream connection, and the heartbeat signal is used to provide real-time feedback on the link connectivity status of the push stream end. Continuously traverse the uplink buffer queue, and in real time count the amount of unparsed video fragments, frame data and signaling messages. Dynamically track the consumption progress of residual bit streams, and match the residual data cleaning waiting window period in real time to ensure that the monitoring process fully covers weak network latency and out-of-order fragment scenarios. In step S2, the process of confirming that the old push stream link is completely disconnected and all uplink delayed fragments have been received is as follows: The old push link is completely cleared and the remaining fragments are completely received. When all four criteria are met, it is determined that the old push link is completely disconnected and all uplink delayed fragments have been received. In step S2, the process of clearing the locally stored video configuration, SPS / PPS parameter set, IDR keyframe cache, and cached P / B video frame data is as follows: After confirming that the old streaming link is completely disconnected and the uplink delay fragment is fully received, the server batch clears all the old streaming data in the local cache. The cached data includes: the global video configuration parameters corresponding to the old streaming, the SPS / PPS parameter set required for decoding, the IDR key frame data of the key frame cache, and the P / B video frame data of the temporary cache. Understandably, the significance of this step is as follows: for switching scenarios with parallel conflicts, through continuous link and cache dual monitoring and multi-condition joint verification, the cache clearing operation is performed after the old push stream delay and out-of-order fragments are completely received, clearing the heterogeneous residual data of the old stream, completing the purification of existing data before switching, and providing an interference-free operating environment for subsequent bitstream identifier binding, same-source verification rule deployment, and clean new bitstream cache update; Step S3: Complete the cache resource reset operation, bind a unique push stream identifier to each uplink bitstream, construct real-time same-source bitstream verification and matching rules, filter delayed segments that are not currently active push streams, and intercept heterogeneous bitstreams written to video configuration, SPS / PPS parameter set, IDR keyframe and P / B video frame buffer area. In step S3, the process of resetting the cache resources and binding a unique push stream identifier to each uplink stream is as follows: Based on the complete disconnection of the old streaming link and the batch clearing of all old stream cache data, the server performs a global reset and calibration of local video cache resources; The video configuration cache, SPS / PPS parameter set cache, IDR keyframe cache and P / B video frame cache were uniformly restored to their initial blank state after being cleared, eliminating the hidden dangers of old heterogeneous streaming data; At the same time, the mutex lock for push stream switching is kept locked to prevent unverified and unfamiliar bit streams from being written into the cache area in advance, ensuring that the cached resources after the reset are in a clean and interference-free state. Once the cache resources have been reset, the server calls the system's pre-set stream identifier generation program to assign a globally unique stream identifier to each new uplink stream and bind it to the current room stream session. It should be noted that the stream identifier generation program is a fixed deployment during the initialization phase of the server-side streaming media scheduling system. It is a basic functional module pre-integrated by the system to achieve multi-stream differentiation, same-source verification, and heterogeneous stream interception. The server marks and writes the video segments, signaling messages, and frame data of the newly pushed stream, so that the video segments, SPS / PPS parameter frames, IDR key frames, and P / B ordinary frames produced by the new push stream all carry a unique identifier, enabling accurate traceability of single-channel push stream data and distinguishing between valid new push streams and historical old push stream data. In step S3, the process of constructing real-time same-source stream verification and matching rules is as follows: Based on the unique identifier of the bound push stream, the server builds the same source code stream verification and matching rules to adapt to the push stream switching scenario, and establishes a unique admission mechanism for cache writing; The specific rules are as follows: Only video segments and frame data carrying the unique identifier of the current active push stream have local cache write permissions. All messages, segments, and frame data that are not the unique identifier of the current active push stream are judged as heterogeneous illegal bitstreams and are prohibited from being written to the cache area. It should be noted that the rules reside in memory and take effect in real time, adapting to complex scenarios such as out-of-order fragmentation and cross-time-sequence packet arrival, and realizing real-time identification of the legality of the bitstream; In step S3, the process of filtering delayed segments that are not currently active streams and intercepting heterogeneous bitstreams from being written to the video configuration, SPS / PPS parameter set, IDR keyframes, and P / B video frame buffer areas is as follows: Based on the same-source verification and matching rules, the server performs real-time comparison and verification of the subsequent continuously uploaded video segments, and intercepts and cleans up old push delayed segments, out-of-order segments and residual heterogeneous bitstreams that are outside the coverage of the waiting window period and arrive late. If the historical old stream data that arrives across time delays after the switchover is completed does not match the fragment timing, delay duration and the unique identifier of the current active push stream, it is determined to be an illegal interference stream and is filtered and discarded in real time; The server-side selectively intercepts heterogeneous bitstreams from being written into the core cache area, preventing illegal old stream data from tampering with, overwriting, or polluting the currently clean video configuration parameters, SPS / PPS decoding parameter sets, IDR keyframe cache, and P / B video frame cache. Understandably, the significance of this step lies in the following: Based on the clean environment after cache reset, by binding unique identifiers, constructing same-source verification rules, and filtering heterogeneous bitstreams for a long time, it makes up for the limitations of static cleanup during the window period, removes residual data within the window period, and intercepts ultra-long-delay old stream fragments outside the window period through dynamic real-time verification. It builds a dynamic isolation barrier from the source of data writing, realizes full-time isolation between new and old bitstreams, and provides reliable same-source data support for subsequent clean bitstream cache refresh and stable distribution of decoding parameters. Step S4: Update the room's global keyframe cache with a clean bitstream that has passed the same-source verification, send matching decoding context data to the online streaming end, identify and intercept keyframe request signaling triggered by heterogeneous bitstreams, and only retain the valid signaling corresponding to the currently active streaming for forwarding; In step S4, the process of updating the room's global keyframe buffer using a clean bitstream that has passed source verification is as follows: Based on the same source stream verification and matching rules, the newly pushed uplink stream data is filtered out, and heterogeneous old stream fragments with mismatched identifiers, excessive delays, and out-of-order lags are eliminated. Only clean stream data with unique identifiers of the currently active streams, compliant timing, and unified parameters are retained. Based on the clean and compliant new streaming bitstream, the room's global cache resources are iteratively updated, refreshing the global video configuration, SPS / PPS parameter set, IDR keyframe and P / B video frame cache one by one, replacing the blank initialization data in the cache, and completing the full coverage update of the room's global bitstream cache. The update process continuously relies on push-stream switching mutex locks for read and write protection to prevent heterogeneous data from intruding and tampering during the update process, and to ensure that the global cache data is single and of the same origin, with unified parameters and regular frame sequences; In step S4, the process of sending the matching decoding context data to the online streaming end is as follows: Complete the global keyframe cache update, extract the standard decoding parameter information corresponding to the current new stream, and generate decoding context data adapted to the current bitstream format. The decoding context data includes: bitstream resolution, frame rate, bit rate, encoding format, and SPS / PPS core decoding parameters. For all online streaming terminals in the room, a unified push is made of decoding context data that matches the new streaming encoding characteristics, so that each streaming terminal decoder can complete parameter initialization and decoding environment adaptation. It should be noted that the distributed decoding context data is strictly matched one-to-one with the currently active streaming stream. Unlike the traditional method of using old streaming decoding parameters when switching scenarios, this method can effectively avoid abnormal problems such as decoding failure, black screen, and screen flickering caused by the mixing of old and new encoding parameters and parameter mismatch. It ensures that the streaming end can quickly adapt to the new streaming bitstream and achieve smooth decoding and playback. In step S4, the process of identifying and intercepting keyframe request signaling triggered by heterogeneous bitstreams is as follows: Continuously monitor key frame request signaling from the streaming end in the room in real time, and verify the request signaling by combining the same source identifier verification logic; If the key frame request signaling is triggered by an old push stream delay fragment or a heterogeneous bypass bitstream abnormally, or if the frame data identifier and parameter characteristics corresponding to the request signaling do not match the unique identifier of the currently active push stream, then the request is determined to be an illegal and abnormal signaling. For illegal keyframe request signaling, the server performs real-time interception and discarding to prevent invalid signaling from occupying system scheduling resources and triggering erroneous keyframe refresh and parameter reload operations; In step S4, the process of forwarding only the valid signaling corresponding to the currently active push stream is as follows: All keyframe request signaling is screened for source identifiers and filtered, retaining only valid signaling that completely matches the unique identifier of the currently active push stream and is triggered by playback abnormality at the pull stream end. Valid signaling includes: frame loss compensation request, screen stuttering re-flash request, decoder reset request, and other instructions adapted to the playback repair scenario of the new bitstream; After the compliance verification is completed, the server will forward the selected valid keyframe request signaling to the cache scheduling module normally. Based on the clean source code stream, it will perform operations such as IDR keyframe re-delivery and decoding parameter reload to ensure that all keyframe refresh actions in the room are based on valid push streams. Understandably, the significance of this step is to: complete the standardized update of the room's global cache with the filtered, clean, same-source bitstream; simultaneously distribute the dedicated decoding context adapted to the new push stream to the streaming terminal; unify the decoding benchmark at the playback end; and add a heterogeneous interception mechanism from the signaling interaction link to block interference caused by the old push stream's delayed fragmentation and heterogeneous bitstreams in both uplink and downlink directions. This eliminates multiple playback faults such as parameter conflicts, frame data mixing, and abnormal signaling misscheduling during the switching between old and new push streams, achieving a seamless, stable, and smooth switching effect between old and new push streams.

[0021] Example 3: Please refer to Figure 3 As shown in the embodiment of the present invention, the keyframe caching and stuttering self-healing transmission system for a cloud-based interactive terminal includes the following modules: Push stream access authentication module: The push stream end and pull stream end respectively connect to the room relay service. The server verifies the access permission and distinguishes between ordinary viewing clients and control-only clients. If the current access party is a new push stream end, the server clears the room's historical cache, synchronously establishes the mapping relationship between the room status and the user connection, and builds the basic communication framework. The bitstream caching and resending module is based on the basic communication framework. The server parses the video bitstream from the push end, identifies and caches the SPS / PPS parameter set and IDR keyframes. When a new ordinary viewing client joins the meeting, the cached frames are resent and the keyframes are requested from the push end. The module only controls the client to forward control commands and provides basic decoding data for the pull end. Layered self-healing module for stuttering: Based on decoding base data, the streaming end synchronously monitors the data packet reception time and screen rendering time to identify hidden stuttering. It dynamically adjusts the critical stuttering time in combination with the user's activity status, and self-heals in layers according to a low-cost priority strategy and initiates key frame recovery requests. Frequency limiting and sleep control module: In response to key frame requests, the streaming end limits the frequency of the key frame request and calls the encoder to output synchronous IDR frames; when there are no viewing clients in the room, a grace period timer is started. If no new users are connected within the grace period, the image acquisition and encoder work are stopped to release cloud computing power and network resources. The latency prediction and risk control module responds to the room access request from the new streaming end, opens the streaming switching mutex lock on the server, collects video segment transmission latency and connection signaling asynchronous latency indicators, calculates the waiting window period for cleaning up residual data in the old streaming link, and identifies the risk of parallel conflict between the new and old streaming. Old stream monitoring and clearing module: If it is determined that there is a risk of parallel conflict, it continuously checks the status of the old push stream connection link and the stray bit stream in the uplink buffer. After the old push stream link is completely disconnected and all uplink delayed fragments are received, it clears the video configuration, SPS / PPS parameter set, IDR key frame cache and cached P / B video frame data stored locally. Same-source identifier isolation module: completes cache resource reset operation, binds a unique push stream identifier to each uplink bitstream, constructs real-time same-source bitstream verification and matching rules, filters delayed fragments that are not currently active push streams, and intercepts heterogeneous bitstreams from being written into video configuration, SPS / PPS parameter sets, IDR keyframes and P / B video frame buffer areas. Pure stream distribution module: Updates the room's global keyframe cache with pure streams that have passed same-source verification, sends matching decoding context data to online streaming terminals, identifies and intercepts keyframe request signaling triggered by heterogeneous streams, and only retains valid signaling corresponding to the currently active streaming for forwarding.

[0022] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. A keyframe caching and stuttering self-healing transmission method for cloud-based interactive terminals, characterized in that: Includes the following steps: Step 1: The push and pull ends connect to the room relay service respectively. The server verifies the access permissions and distinguishes between ordinary viewing clients and control-only clients. If the current access party is a new push end, the server clears the room's historical cache, synchronously establishes the mapping relationship between the room status and the user connection, and builds the basic communication framework. Step 2: Based on the basic communication framework, the server parses the video stream from the push end, identifies and caches the SPS / PPS parameter set and IDR keyframes. When a new ordinary viewing client joins the meeting, it resends the cached frames and requests keyframes from the push end. It only controls the client to forward control commands and provides basic decoding data for the pull end. Step 3: Based on the decoding base data, the streaming end synchronously monitors the data packet reception time and screen rendering time to identify hidden stutters. Combined with the user's activity status, the stutter critical time is dynamically adjusted, and the layered self-healing is carried out according to the low cost priority strategy, and key frame recovery requests are initiated. Step 4: For keyframe requests, the streaming end responds to the keyframe request with frequency limiting and calls the encoder to output synchronous IDR frames; when there are no viewing clients in the room, a grace period timer is started. If no new users join during the grace period, the image acquisition and encoder work are stopped to release cloud computing power and network resources.

2. The key frame caching and stall self-recovery transmission method for cloud interactive terminal according to claim 1, characterized in that: In step two, the process of identifying and caching the SPS / PPS parameter set and IDR keyframes is as follows: The server obtains the RTP-encapsulated video stream from the streaming end through the media receiving channel; Each RTP packet is decapsulated, the NAL unit is extracted, and identification is performed by reading the type field in the header of the NAL unit; When a NAL unit of type SPS or PPS is identified, the server updates the complete parameter set data to the parameter set cache corresponding to the streaming source. When an IDR frame is identified, the server stores the encoded data of the IDR frame along with the associated current SPS / PPS parameter set into the keyframe buffer, overwriting the previously cached old IDR frames.

3. The key frame caching and stall self-recovery transmission method for cloud interactive terminal according to claim 1, characterized in that: In step three, the process of identifying hidden stutters is as follows: After the streaming end completes decoder initialization and starts rendering, it starts monitoring the screen rendering time. The decoded video frames are sent to the rendering queue, and the timestamp difference between each frame entering the rendering queue and being actually drawn to the screen is recorded. When the difference continues to increase or exceeds the preset absolute threshold and does not match the vertical synchronization interval, it is determined to be a hidden stutter.

4. The key frame caching and stall self-recovery transmission method for cloud interactive terminal according to claim 1, characterized in that: The keyframe buffering and stuttering self-healing transmission method also includes the following steps: Step S1: In response to the new streaming client's room access request, the server opens the streaming switching mutex lock, collects video segment transmission latency and connection signaling asynchronous latency indicators, calculates the waiting window period for cleaning up residual data in the old streaming link, and identifies the risk of parallel conflict between the new and old streaming. Step S2: If it is determined that there is a risk of parallel conflict, continuously check the status of the old push stream connection link and the uplink buffer stagnant bit stream. After the old push stream link is completely disconnected and all uplink delayed fragments are received, clear the video configuration, SPS / PPS parameter set, IDR key frame cache and cached P / B video frame data stored locally. Step S3: Complete the cache resource reset operation, bind a unique push stream identifier to each uplink bitstream, construct real-time same-source bitstream verification and matching rules, filter delayed segments that are not currently active push streams, and intercept heterogeneous bitstreams from being written into the video configuration, SPS / PPS parameter set, IDR keyframes, and P / B video frame buffer areas; Step S4: Update the room's global keyframe cache with a clean bitstream that has passed the same-source verification, send matching decoding context data to the online streaming end, identify and intercept keyframe request signaling triggered by heterogeneous bitstreams, and only retain the valid signaling corresponding to the currently active streaming for forwarding.

5. The key frame caching and stall self-recovery transmission method of cloud interactive terminal according to claim 4, characterized in that: In step S1, the process of calculating the waiting window period for cleaning up residual data in the old push stream link is as follows: Based on the real-time collected average transmission latency of video segments and asynchronous latency of connection signaling, and superimposed with network jitter redundancy duration, the waiting window period for cleaning up residual data in old push links is dynamically calculated. The waiting window for cleaning up residual data in the old push link is the sum of the average transmission latency of video segments, the asynchronous latency of connection signaling, and the network jitter redundancy duration. Among them, the network jitter redundancy duration is taken as a multiple of the standard deviation of historical transmission delay.

6. The keyframe caching and stuttering self-healing transmission method for a cloud-based interactive terminal according to claim 4, characterized in that: In step S1, the process of identifying the risk of parallel conflict between new and old push streams is as follows: Based on the estimated end time of the old push link being completely cleared and the remaining fragments being fully received, it is determined whether there is an overlap in the working timing of the old and new push links; If there is an overlap in time periods, it is determined that there is a risk of conflict.

7. The keyframe caching and stuttering self-healing transmission method for a cloud-based interactive terminal according to claim 4, characterized in that: In step S3, the process of binding a unique push stream identifier to each uplink bitstream is as follows: The server performs a global reset and calibration of local video cache resources; The video configuration cache, SPS / PPS parameter set cache, IDR keyframe cache and P / B video frame cache, which were cleared, will be uniformly restored to their initial blank state. At the same time, the mutex lock for push stream switching is kept locked to prevent unverified and unfamiliar bit streams from being written to the buffer area in advance; Once the cache resource reset is complete, the stream identifier generation program assigns a globally unique stream identifier to each new uplink stream and binds it to the current room stream session.

8. The keyframe caching and stuttering self-healing transmission method for a cloud-based interactive terminal according to claim 7, characterized in that: In step S3, the process of constructing real-time same-source stream verification and matching rules is as follows: Based on the unique identifier of the bound push stream, the server builds the same source code stream verification and matching rules to adapt to the push stream switching scenario, and establishes a unique admission mechanism for cache writing; The specific rules are as follows: only video segments and frame data carrying the unique identifier of the current active push stream have local cache write permissions. All messages, segments, and frame data that are not the unique identifier of the current active push stream are judged as heterogeneous illegal bitstreams and are prohibited from being written to the cache area.

9. The keyframe caching and stuttering self-healing transmission method for a cloud-based interactive terminal according to claim 8, characterized in that: In step S4, the process of updating the room's global keyframe cache using a clean bitstream that has passed source verification is as follows: Based on the same source stream verification and matching rules, the uplink new push stream data is filtered in real time, heterogeneous old stream fragments are eliminated, and only pure stream data carrying the unique identifier of the current active push stream is retained; Based on the clean new streaming bitstream, the room's global cache resources are iteratively updated, refreshing the global video configuration, SPS / PPS parameter set, IDR keyframes and P / B video frame cache one by one, replacing the blank initialization data in the cache, and completing the full coverage update of the room's global bitstream cache.

10. A keyframe caching and stuttering self-healing transmission system for a cloud-based interactive terminal, characterized in that: The system is used to execute any one of the control methods of claims 1-9 above, and includes the following modules: Push stream access authentication module: The push stream end and pull stream end respectively connect to the room relay service. The server verifies the access permission and distinguishes between ordinary viewing clients and control-only clients. If the current access party is a new push stream end, the server clears the room's historical cache, synchronously establishes the mapping relationship between the room status and the user connection, and builds the basic communication framework. The bitstream caching and resending module is based on the basic communication framework. The server parses the video bitstream from the push end, identifies and caches the SPS / PPS parameter set and IDR keyframes. When a new ordinary viewing client joins the meeting, the cached frames are resent and the keyframes are requested from the push end. The module only controls the client to forward control commands and provides basic decoding data for the pull end. Layered self-healing module for stuttering: Based on decoding base data, the streaming end synchronously monitors the data packet reception time and screen rendering time to identify hidden stuttering. It dynamically adjusts the critical stuttering time in combination with the user's activity status, and self-heals in layers according to a low-cost priority strategy and initiates key frame recovery requests. Frequency limiting and sleep control module: In response to key frame requests, the streaming end limits the frequency of the key frame request and calls the encoder to output synchronous IDR frames; when there are no viewing clients in the room, a grace period timer is started. If no new users are connected within the grace period, the image acquisition and encoder work are stopped to release cloud computing power and network resources. The latency prediction and risk control module responds to the room access request from the new streaming end, opens the streaming switching mutex lock on the server, collects video segment transmission latency and connection signaling asynchronous latency indicators, calculates the waiting window period for cleaning up residual data in the old streaming link, and identifies the risk of parallel conflict between the new and old streaming. Old stream monitoring and clearing module: If it is determined that there is a risk of parallel conflict, it continuously checks the status of the old push stream connection link and the stray bit stream in the uplink buffer. After the old push stream link is completely disconnected and all uplink delayed fragments are received, it clears the video configuration, SPS / PPS parameter set, IDR key frame cache and cached P / B video frame data stored locally. Same-source identifier isolation module: completes cache resource reset operation, binds a unique push stream identifier to each uplink bitstream, constructs real-time same-source bitstream verification and matching rules, filters delayed fragments that are not currently active push streams, and intercepts heterogeneous bitstreams from being written into video configuration, SPS / PPS parameter sets, IDR keyframes and P / B video frame buffer areas. Pure stream distribution module: Updates the room's global keyframe cache with pure streams that have passed same-source verification, sends matching decoding context data to online streaming terminals, identifies and intercepts keyframe request signaling triggered by heterogeneous streams, and only retains valid signaling corresponding to the currently active streaming for forwarding.

Images