A method for rendering control of a multimedia playing window based on mutual exclusion switching

Abstract

This invention discloses a multimedia playback window rendering control method based on mutual exclusion switching. First, the window is initialized to the first rendering state and rendering is enabled. A session identifier is generated in response to a streaming command, and a timer is started, maintaining the first rendering display during this period. Upon receiving a callback, a synchronization lock is acquired, and session verification and duplicate signal filtering are performed. After successful verification, an atomic switching sequence is executed: after disabling the first rendering enable, a second rendering component is activated to take over the window handle to render the video. This invention provides tiered timeout determination, automatically rendering waiting or error frames when blocked; and supports a last-frame retention mode, locking the screen and automatically recovering via heartbeat detection when the stream is interrupted. This invention solves the flickering and black screen problems in asynchronous environments through atomic timing control and session filtering under a synchronization lock, improving display stability, logical robustness, and visual consistency.

Description

Technical Field

[0001] This invention relates to the field of multimedia playback and video surveillance technology, specifically to a rendering control method based on the mutual exclusion switching between application framework rendering and decoding library rendering. Background Technology

[0002] In client applications such as video surveillance and streaming media playback, the playback window typically needs to support multiple display states, including a default background when no stream is being pulled, a streaming wait message, real-time video during playback, and error messages when playback fails. A common approach is to utilize the application framework's (such as a general-purpose GUI rendering engine) window redrawing mechanism to display the default image or error messages, and to use the decoding library's rendering interface to directly manage the window area to display the real-time video stream.

[0003] However, this dual-rendering mechanism has the following shortcomings in complex network environments or frequent human-computer interaction scenarios: Lack of rigorous mutual exclusion control during rendering switching: Since the UI thread of the application framework and the callback thread of the decoding library are often in an asynchronous state, if the control logic is not rigorous at the moment of rendering permission handover, it is easy for two rendering methods to write data to the same window handle at the same time, resulting in obvious flickering or overlapping conflicts on the screen.

[0004] There is a state vacuum period during the switching process. If there is a lack of accurate awareness of the actual rendering state of the decoding library during the transition from application framework rendering to decoding library rendering, the video stream may not be successfully displayed on the screen after the application framework rendering is closed, resulting in a brief black screen in the playback window, which seriously affects the user experience.

[0005] The lack of consistency checks in the streaming session can lead to timing reversals in multiple asynchronously triggered decoding callback events when frequent reconnections are triggered by network fluctuations. If the system cannot recognize expired callback instructions, it may cause rendering state machine transition errors, resulting in a mismatch between the window display and the actual business logic.

[0006] In abnormal scenarios, the display is inflexible. When the stream is interrupted or the network fluctuates, existing solutions typically adopt a strategy of "hardly switching back to the erroneous screen". However, in some security monitoring scenarios, users prefer to retain the last valid frame as a reference. Existing rendering scheduling mechanisms cannot balance the flexibility of business operations with the continuity of display.

[0007] In summary, how to achieve precise mutual exclusion between rendering components, smooth coverage of transition states, and flexible control of abnormal display modes under complex network fluctuations and high-frequency reconnection scenarios, in order to improve the stability and visual consistency of multimedia playback, is a technical problem that urgently needs to be solved. Summary of the Invention

[0008] The purpose of this invention is to provide a multimedia playback window rendering control method based on mutual exclusion switching. This method aims to overcome the shortcomings of existing technologies, such as screen overlap and flickering caused by asynchronous conflicts between application framework rendering and decoding library rendering, brief black screens caused by switching vacuum periods, state transition distortion caused by inconsistent stream callback sessions, and a single and inflexible display strategy in abnormal streaming scenarios. By constructing a rendering state machine with atomic constraints, the invention achieves precise mutual exclusion and smooth takeover of playback window rendering permissions by the application framework and decoding library, ensuring that the playback window has a unique active rendering source at each stage, including initialization, stream fetching, playback, and abnormal shutdown. Furthermore, it introduces session identifier verification and a multi-level fallback scheduling mechanism to achieve precise filtering of asynchronous callback instructions and steady-state display control in abnormal states, supporting multiple abnormal recovery modes, including retaining the last frame. Ultimately, this improves the display stability, logical robustness, and visual continuity of the multimedia playback window in complex network fluctuations and high-frequency interaction scenarios.

[0009] To achieve the above objectives, the present invention provides a multimedia playback window rendering control method based on mutual exclusion switching, the method comprising: The rendering state machine of the playback window is initialized to the first rendering state, and the rendering update enable interface of the first rendering component of the playback window is activated so as to render the preset screen in the playback window through the first rendering component. In response to the streaming command for the target video stream, a session identifier corresponding to the current streaming task is generated, a fallback detection timer is started, and the rendering start interface of the second rendering component is called. During the second rendering component's preparation for rendering, the rendering state machine is maintained in the first rendering state. In response to receiving a rendering ready callback signal triggered by the second rendering component, the rendering synchronization lock corresponding to the rendering state machine is obtained, and the validity of the rendering ready callback signal is verified based on the session identifier. After the legality check is passed, the switching process is executed, that is, the rendering mutual exclusion switching sequence is executed based on the rendering synchronization lock, including: the state of the rendering state machine is switched to a transition state, and an atomic switching operation is performed in the transition state: the rendering update enable interface of the first rendering component is disabled, and then the second rendering component is activated to take over the handle of the playback window, so that the second rendering component renders the real-time picture of the target video stream in the playback window. Update the state of the rendering state machine to the second rendering state, stop the fallback detection timer, and release the rendering synchronization lock.

[0010] Furthermore, the validity of the rendering-ready callback signal is verified based on the session identifier, including: Extract the callback session identifier carried in the rendering ready callback signal; Determine whether the callback session identifier matches the currently active session identifier in the system; If a match is found, the render-ready callback signal is further checked to see if it is a repeating callback signal for the current session. If it is not a repeating callback signal, then the rendering ready callback signal is determined to be a valid signal.

[0011] Furthermore, the validity verification of the rendering-ready callback signal based on the session identifier also includes a callback delay check: Calculate the time difference between the time the stream fetching command is issued and the time the rendering ready callback signal is received; If the time difference exceeds the preset callback delay threshold, the rendering ready callback signal is determined to be an abnormal callback, and the error display process is forcibly executed.

[0012] Furthermore, the method also includes a first-level timeout determination process based on the fallback detection timer: If the fallback detection timer does not receive a valid rendering ready callback signal within the preset first timeout threshold, the rendering state machine remains in the first rendering state. The first rendering component renders a preset buffer waiting prompt screen in the playback window.

[0013] Furthermore, the method also includes a two-stage timeout determination process: If the fallback detection timer fails to detect a valid rendering ready callback signal within the preset second timeout threshold, the stream retrieval is determined to have failed. The stop interface of the second rendering component is invoked to maintain the first rendering state and control the first rendering component to render a preset error message screen.

[0014] Furthermore, the execution of the rendering mutual exclusion switching sequence includes: under the protection of the rendering synchronization lock, ensuring that the rendering update enable interface of the first rendering component is completely disabled, and then triggering the video frame on-screen operation of the second rendering component, so as to realize the atomic transfer of the takeover rights of the playback window by the first rendering component and the second rendering component on the timeline.

[0015] Furthermore, the method also includes a display mode determination process in response to playback error events: In response to a stream interruption event of the target video stream, identify the current abnormal display mode; If the abnormal display mode is an error-closed mode, then the process of switching back from the second rendering state to the first rendering state is executed; If a preset abnormal display mode configuration instruction is received and the abnormal display mode is the last frame retention mode, then the retention display process will begin.

[0016] Furthermore, the process of entering the reserved display includes: The rendering state machine is kept in the second rendering state, and the rendering update enable interface of the first rendering component is kept in the disabled state. Calls to the stop interface of the second rendering component are prohibited, so as to control the second rendering component to remain locked in the playback window and display the last frame of video before the stream was interrupted.

[0017] Furthermore, the retained display process also includes automated control logic for resumption and exit: A recovery detection mechanism is initiated to continuously monitor the recovery status of the target video stream through heartbeat detection or status query interfaces; If stream recovery is detected within the preset retention timeout threshold, the stream retrieval session is re-initiated and the switching process is executed. If no stream recovery is detected within the retention timeout threshold, the stop interface of the second rendering component is forcibly invoked, and the rendering update enable interface of the first rendering component is restored to switch back to the first rendering state.

[0018] Furthermore, the method also includes the user actively stopping the process: In response to a user-triggered stop command, the rendering synchronization lock is acquired, and the stop interface of the second rendering component is called to release window takeover permissions; Reactivate the rendering update enable interface of the first rendering component, reset the rendering state machine to the first rendering state, and then release the rendering synchronization lock.

[0019] The multimedia playback window rendering control method based on mutual exclusion switching provided by this invention has at least the following beneficial effects: By introducing a rendering synchronization lock and executing an atomic switching sequence in the transition state of the rendering state machine, the second rendering component takes over the handle of the playback window and triggers the video frame to be displayed only after the rendering update of the first rendering component is completely disabled. This ensures that the frame layer rendering and the kernel layer rendering are absolutely mutually exclusive on the timeline, thereby fundamentally eliminating the flickering problem caused by screen overlap in the asynchronous rendering environment and improving the stability of the display process.

[0020] Using session identifier consistency verification as a prerequisite for triggering rendering mutual exclusion switching ensures that permission transfer is only performed when the second rendering component is ready and the callback is valid. Combined with a preset atomic operation time threshold to lock the switching process, it effectively avoids black screen vacuum periods caused by non-strict timing of rendering component handover, and achieves seamless connection between different rendering sources.

[0021] By using a session identifier matching mechanism and duplicate callback filtering logic to verify the legitimacy of asynchronous signals, the system can accurately identify and intercept expired, out-of-order, or duplicate callback instructions caused by network fluctuations, preventing the rendering state machine from generating incorrect state transitions or logical deadlocks, and enhancing the system's control robustness and logical consistency in complex network environments.

[0022] Based on the status categories such as first-level timeout judgment and second-level timeout judgment output by the fallback detection timer, hierarchical scheduling is implemented, so that when the playback window is blocked, it can automatically display targeted prompt screens according to the waiting time. Combined with the heartbeat detection-based recovery mechanism, it realizes the automatic switching from fault state to real-time playback state, reducing the system's dependence on manual intervention and improving its self-repair capability in abnormal scenarios.

[0023] In response to the abnormal display mode configuration command, it enters the last frame retention mode and locks the display screen by prohibiting the call to the stop interface during the stream interruption. This allows the second rendering component to continue to present the last valid image in the abnormal state instead of hard switching back to the error icon, providing business personnel with key visual reference and ensuring business continuity and visual continuity in specific monitoring scenarios.

[0024] By introducing a state reset mechanism protected by rendering synchronization lock in the user-initiated stop or abnormal shutdown process, the release of rendering resources and the rollback process of the state machine are ensured to be atomic, avoiding the risk of rendering resource residue or state distortion under high-frequency interactive operations, and ultimately improving the controllability of the multimedia playback window throughout its entire lifecycle. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a flowchart of the multimedia playback window rendering control method of the present invention.

[0027] Figure 2This is a schematic diagram of the rendering state transition and underlying control logic of the multimedia playback window in different business stages of the present invention.

[0028] Figure 3 This is a timing diagram of the control of the multimedia playback window in the asynchronous callback environment of the present invention. Detailed Implementation

[0029] 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 numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0030] Example 1

[0031] like Figure 1 As shown, this embodiment provides a multimedia playback window rendering control method based on mutual exclusion switching, the method including: The rendering state machine of the playback window is initialized to the first rendering state, and the rendering update enable interface of the first rendering component of the playback window is activated so that the preset screen is rendered in the playback window through the first rendering component. The rendering state machine, as the globally unique logical control core, ensures that the system has a clear rendering ownership at the moment of startup, avoiding window black screen or display abnormalities caused by undefined rendering source.

[0032] In response to a streaming command for the target video stream, a session identifier corresponding to the current streaming task is generated, a fallback detection timer is started, and the rendering startup interface of the second rendering component is called. During the rendering preparation period of the second rendering component, the rendering state machine is maintained in the first rendering state. By using the generation of the session identifier and the start timer as the pre-atomic operations of the startup interface call, the start time base of the streaming task can be accurately recorded, providing a unique and reliable reference for subsequent timeout determination and callback validity verification.

[0033] In response to receiving the rendering ready callback signal triggered by the second rendering component, the rendering synchronization lock corresponding to the rendering state machine is obtained, and the validity of the rendering ready callback signal is verified based on the session identifier. The rendering synchronization lock locks the critical section of the state machine the moment the asynchronous callback signal is received, which can effectively intercept multiple rendering instruction conflicts in a concurrent environment, ensuring that only one thread can modify the rendering state at the same time, and preventing state transition distortion or program crash caused by thread competition.

[0034] After the legality verification is passed, a rendering mutual exclusion switching sequence is executed based on the rendering synchronization lock, including: switching the state of the rendering state machine to a transition state, and performing an atomic switching operation in the transition state: disabling the rendering update enable interface of the first rendering component, and then activating the second rendering component's takeover right of the playback window handle, so that the second rendering component renders the real-time picture of the target video stream in the playback window; the atomic operation sequence of "disabling first, then taking over" in the transition state can ensure that the drawing redrawing instructions of the first rendering component are completely suspended at the physical layer before the second rendering component starts writing video frames to the window handle, thereby realizing zero-overlap transfer of rendering rights on the time axis, fundamentally eliminating the picture overlap and flicker caused by asynchronous rendering.

[0035] The rendering state machine is updated to the second rendering state, the fallback detection timer is stopped, and the rendering synchronization lock is released. By releasing the synchronization lock and stopping the timer promptly after the steady state is established, the system's computing power overhead can be reduced and mutually exclusive resources can be released, ensuring the real-time response performance of subsequent business logic.

[0036] As one implementation method, this embodiment performs a validity check on the rendering-ready callback signal based on the session identifier, including: extracting the callback session identifier carried in the rendering-ready callback signal; determining whether the callback session identifier matches the currently active session identifier in the system; if they match, further checking whether the rendering-ready callback signal is a duplicate callback signal for the current session; if it is not a duplicate callback signal, determining that the rendering-ready callback signal is a valid signal. By performing deep validation of the session identifier and introducing a duplicate callback filtering mechanism, expired, out-of-order, or redundant signals generated in network reconnection scenarios can be accurately identified and eliminated, ensuring that the rendering state machine only responds to the currently active service session, significantly improving the system's control robustness in complex network environments.

[0037] As one implementation method, this embodiment performs a validity check on the rendering-ready callback signal based on the session identifier, and also includes a callback delay check: Calculate the time difference between the time the stream fetching command is issued and the time the rendering ready callback signal is received; If the time difference exceeds a preset callback delay threshold, the rendering-ready callback signal is determined to be an abnormal callback, and the error display process is forcibly executed. By introducing a delay check mechanism based on time difference, the system can detect potential link blockages or performance bottlenecks, and stop the damage in time when the callback signal arrives but has failed, thus avoiding the technical risk of displaying outdated or stuttering images.

[0038] As one implementation method, the method in this embodiment further includes a first-level timeout determination process based on the fallback detection timer: If the fallback detection timer does not receive a valid rendering ready callback signal within a preset first timeout threshold, the rendering state machine remains in the first rendering state; and a preset buffer waiting prompt screen is rendered in the playback window through the first rendering component. This tiered judgment mechanism, by actively presenting buffer prompts during the waiting period, can smoothly cover the vacuum period in the video stream loading process, eliminate the user's psychological anxiety, and improve the continuity of visual interaction.

[0039] As one implementation method, the method described in this embodiment further includes a two-stage timeout determination process: If the fallback detection timer fails to detect a valid rendering ready callback signal within the preset second timeout threshold, the stream acquisition is deemed a failure. The stop interface of the second rendering component is then invoked to maintain the first rendering state and control the first rendering component to render a preset error message. By forcibly reverting to the error display state, the system is ensured not to enter an infinite loop due to the unresponsiveness of underlying components, achieving safe closed-loop control in abnormal scenarios.

[0040] As one implementation method, the execution of the rendering mutual exclusion switching sequence in this embodiment includes: under the protection of the rendering synchronization lock, ensuring that the rendering update enable interface of the first rendering component is completely disabled, and then triggering the video frame loading operation of the second rendering component, so as to achieve the atomic transfer of the takeover rights of the playback window by the first rendering component and the second rendering component on the timeline. This step further clarifies that "complete disabling" is a prerequisite for "frame loading", and through strict constraints on the microsecond-level timing, it ensures that the writing source of the window pixel area is physically unique.

[0041] As one implementation, the method in this embodiment further includes a display mode determination process in response to playback anomaly events: in response to a stream interruption event of the target video stream, the current abnormal display mode is identified; if the abnormal display mode is an error-closed mode, a switchback process from the second rendering state to the first rendering state is executed; if a preset abnormal display mode configuration instruction is received and the abnormal display mode is a last frame retention mode, a retention display process is entered. By introducing an abnormal display mode configuration instruction, the rendering scheduling mechanism can adaptively adjust the display behavior according to different business strategies (such as security alerts or regular playback), greatly enhancing the business adaptability of the solution.

[0042] As one implementation method, the process of entering the reserved display in this embodiment includes: The rendering state machine is maintained in the second rendering state, and the rendering update enable interface of the first rendering component is kept disabled. Calls to the stop interface of the second rendering component are prohibited, so that the second rendering component continues to lock and display the last frame of video before the stream interruption in the playback window. By locking the handle and not resetting the rendering update enable during the display period, the static locking of the image can be achieved using the memory-resident characteristic of the second rendering component, providing crucial visual references for business personnel and ensuring business continuity.

[0043] As one implementation method, the retained display process in this embodiment further includes automated control logic for resumption and exit: A recovery detection mechanism is initiated to continuously monitor the recovery status of the target video stream through heartbeat detection or status query interfaces; If stream recovery is detected within the preset retention timeout threshold, the stream retrieval session is re-initiated and the switching process is executed. If no stream recovery is detected within the retention timeout threshold, the stop interface of the second rendering component is forcibly invoked, and the rendering update enable interface of the first rendering component is restored to switch back to the first rendering state. This automated recovery logic achieves smooth reconnection from "static retained frames" to "dynamic real-time streams" through continuous state awareness, reducing the operational cost of manual reset and improving the system's self-healing capability.

[0044] As one implementation, the method in this embodiment further includes a user-initiated stop process: in response to a user-triggered stop command, the rendering synchronization lock is acquired, and the stop interface of the second rendering component is called to release window takeover permissions; the rendering update enable interface of the first rendering component is reactivated, and the rendering state machine is reset to the first rendering state, followed by releasing the rendering synchronization lock. By reintroducing synchronization lock protection during the user exit phase, the consistency of the rendering resource state during the release process is ensured, avoiding potential resource residue or memory leaks under frequent "play / stop" operations.

[0045] This embodiment achieves smooth, mutually exclusive takeover from general application framework rendering to professional decoding library rendering by constructing a closed-loop control architecture consisting of a rendering state machine, session consistency verification logic, and physical synchronization locks. Through precise filtering of asynchronous callback signals and atomic control of the rendering update interface, it solves common screen flickering and black screen issues in multi-threaded concurrent environments. While ensuring the robustness of the display logic, it significantly improves the visual consistency and user experience of the multimedia playback window in various abnormal scenarios and high-frequency interaction processes.

[0046] Example 2

[0047] In this embodiment, a general idea for a multimedia playback window rendering control method based on mutual exclusion switching is proposed. By precisely controlling the start and stop of the first rendering component (e.g., a rendering engine based on the QT framework) and the second rendering component (e.g., a video decoding library rendering engine), it is ensured that the two are mutually exclusive at any time and that at least one rendering mode is active. This solves the problem of two heterogeneous rendering logics competing for the same display resource at the physical level, and achieves flicker-free and black-screen-free display of the playback window.

[0048] In this embodiment, a rendering state machine and a mutual exclusion constraint mechanism are defined. The rendering states of the playback window include the following three types: QT_RENDERING (first rendering active state, second rendering inactive, used to display the default screen, waiting prompts, error messages, etc.); DECODER_RENDERING (second rendering active state, first rendering inactive, used to display the real-time video stream); and TRANSITION (transition state). The transition state exists only at the moment of switching, and its duration is preferably less than 50 milliseconds to ensure the atomicity of the switching process and ensure that the system is in a clearly controlled intermediate state during the permission transfer period.

[0049] In this embodiment, to ensure the rigor of rendering switching, the following mutual exclusion constraints are defined: First, state mutual exclusion, requiring that the playback window can only be in either the first rendering or the second rendering state at any given time, strictly prohibiting the simultaneous activation of both rendering modes; second, switching atomicity, requiring that when switching from the first rendering to the second rendering, the operations of disabling the first rendering redraw, confirming the second rendering readiness callback, and finally updating the state must be executed in sequence; third, reverse switching rules, requiring that when switching back from the second rendering to the first rendering, the second rendering output must be stopped before enabling the first rendering; and finally, state persistence, requiring that the new state must remain stable after the switch is completed. By implementing the above strict logical constraints, the problems of image overlap, timing disorder, and display jitter caused by asynchronous control are eliminated at the source.

[0050] In this embodiment, the rendering state is managed using a state machine pattern, and a rendering synchronization lock (stateMutex) is used to ensure safe state transitions in a multi-threaded environment. Before the processor executes a state transition, the rendering synchronization lock is acquired to lock the critical section, ensuring that only one thread can drive the state transition at any given time, thereby preventing potential state distortion or program abnormalities in multi-callback concurrent scenarios.

[0051] In this embodiment, a session consistency mechanism and exception handling rules are introduced for the callbacks of the second rendering component. The system introduces a session identifier mechanism, generating a unique session identifier (sessionId) each time streaming begins to identify the current operation. The system requires that callback signals triggered by the second rendering component must carry the session identifier, and achieves precise identification of asynchronous signals by forcibly verifying whether the sessionId carried by the callback signal matches the currently active sessionId of the system. This verification method eliminates interference from expired historical sessions on the current interface, significantly enhancing control accuracy in a multi-concurrency environment. Simultaneously, the system presets a session timeout mechanism; if no valid callback is received within a preset time T seconds (e.g., 30 seconds) after streaming begins, the current session is determined to have timed out and exception handling is triggered.

[0052] In this embodiment, handling rules for callback anomalies are defined. Callbacks with session mismatches are identified as expired signals and discarded directly. For duplicate callbacks, only the first signal is processed, ignoring subsequent redundancies, effectively avoiding system computational overhead and interface flickering risks caused by repeatedly executing switching sequences. Callbacks with delays exceeding a threshold (e.g., 5 seconds) are identified as abnormal signals and forcibly switched to error display mode. Furthermore, the system periodically checks the consistency between the stream fetching status and the callback status using a timer. If a callback loss is detected, the following fallback control strategy is triggered.

[0053] In this embodiment, a multi-layered fallback control strategy is designed for scenarios involving missing callbacks or timeouts. The system starts a timer (e.g., checking once every 1 second) to continuously monitor the connection status and perform tiered judgments. If no valid callback is received within a preset first timeout threshold T1 seconds (e.g., 10 seconds) after streaming begins, it is determined that the callback is missing. The system triggers a first-level timeout judgment, maintains the first rendering state, and the first rendering component renders a "Waiting for video stream" prompt. This mechanism smoothly covers the logical "vacuum period" during the video stream loading process by actively presenting feedback during the waiting period, eliminating the user's sense of interactive interruption. If no signal is received after a preset second timeout threshold T2 seconds (e.g., 30 seconds), it is determined that streaming has failed, triggering a second-level timeout judgment. The system stops the second rendering component, and the first rendering component renders an error prompt (e.g., "Streaming timeout").

[0054] In this embodiment, the entry conditions, exit conditions, and recovery methods for retaining the last frame in abnormal display mode are refined. When the stream is abnormal but the service requires the screen to be retained, or when the user actively triggers it, or when it is triggered according to a preset service strategy, the system enters the retention mode. After entering this mode, the system uses the technical means of not calling the stop interface of the second rendering component and not restoring the enable interface of the first rendering component, and uses the video memory resident characteristics to lock the screen at the moment of interruption, providing the service personnel with key visual reference and ensuring information retention in extreme scenarios. The system automatically exits this mode when it detects stream recovery, user manual stop operation, or retention time exceeding the preset retention timeout threshold (e.g., 60 seconds). During the recovery process, the system senses the stream status through a heartbeat mechanism. After detecting recovery, the first rendering component first displays a "Recovering..." prompt, and then re-initiates stream retrieval. This self-healing method achieves an unattended smooth transition from "static stub" to "real-time stream".

[0055] In this embodiment, combined with Figure 2 This document provides a detailed explanation of the rendering state transitions and underlying control logic of the multimedia playback window at different business stages. The system starts from the initialization phase, at which point rendering rights are allocated to the first rendering component to implement the default QT rendering screen. This allows the system to utilize the application framework's built-in GUI rendering capabilities to fill the window with a preset static background or guide information the moment it is created, ensuring the window's visual integrity before it reaches "system ready." Upon detecting a system ready signal, the system responds to the streaming request and enters the streaming start state. During this period, although the streaming command has been issued, the system maintains rendering output handled by the first rendering component because media negotiation is not yet complete. When the backend successfully receives video stream n (triggered by a callback), the system performs rendering takeover from the first rendering component to the second rendering component. Figure 2 The "F" in the code represents the system calling the rendering update enable interface (i.e., executing the `updatesEnabled` property configuration) to force its parameter to false. This method physically suspends the redraw request, providing a "clean" environment for subsequent permission transfer. After the "F" instruction takes effect, the system executes the decoding library rendering and the decoder takeover rendering, with the second rendering component writing real-time video frames to the window buffer. The system presets three processing paths based on different termination triggers: Path 1 responds to the user's active cessation of the normal shutdown process, ensuring safe resource reclamation; Path 2 responds to the stream interruption and enters an error shutdown state, at which point the `updatesEnabled=T` instruction (i.e., setting it to true) is executed and a QT rendering error message is displayed, improving feedback friendliness; Path 3 responds to special instructions (such as abnormal display mode configuration instructions) and enters the process of retaining the last frame, using the video memory resident feature to lock the screen. In summary, Figure 2The logic shown constructs a closed-loop control system by atomically switching the enable attribute between "F" and "T".

[0056] In this embodiment, combined with Figure 3 The document provides further detailed explanations of the precise control timing, security verification logic, and anomaly self-healing path for multimedia playback windows in an asynchronous callback environment. Upon initialization, the system executes initialization logic, at which point the rendering state machine is in the QT_RENDERING state. The system explicitly executes the rendering update enable interface instruction `setUpdatesEnabled=true`, and the application framework is responsible for displaying the default screen. When the system detects a user operation to start fetching, it triggers the following concurrent processing logic: first, the instruction is issued, i.e., a synchronous call to `VARender_Start→PLAY_Play`; second, a new sessionId is generated; and finally, a fallback timer is started. This approach ensures accurate identification of subsequent out-of-order callbacks by assigning a globally unique identifier to the fetching task and introducing time-dimensional monitoring. When the system receives the decoding library's start-rendering callback signal, it first enters the critical section to verify the sessionId and the repeated callback logic, and performs a verification pass / fail check. If the check fails, the signal is discarded and the system returns to the QT_RENDERING state; if the check succeeds, an atomic mutual exclusion switching sequence is executed. The processor calls the interface to execute `setUpdatesEnabled=false` to suspend the redraw, and simultaneously stops the fallback timer and switches to the DECODER_RENDERING state. At this point, the playback window is rendered by the second rendering component, entering a stable DECODER_RENDERING state and being rendered in real-time by the decoding library. This strict "close-then-start" sequential control completely resolves the screen flickering issue. When a playback end / abnormal event is triggered, the system executes different paths: if the user actively stops the playback, it performs a normal shutdown, calling VARender_Stop→PLAY_Stop and setting setUpdatesEnabled=true to display the default screen; if the stream is interrupted / an error occurs, it performs an error shutdown and displays an error message; if a special instruction is received, it enters the last frame retention mode and continues rendering by the decoding library. In DECODER_RENDERING (retention mode), the window displays the last frame, and the system synchronously starts a recovery detection mechanism. If stream recovery is detected, the system automatically loops back to normal playback; if recovery fails within a timeout, it forcibly switches to the error display process, calling VARender_Stop→PLAY_Stop and setting setUpdatesEnabled=true to display an error message. Figure 3 A scheduling closed loop with self-calibration, self-defense and self-healing characteristics was constructed.

[0057] This embodiment clarifies the system architecture and main implementation process. The playback window supports rendering by both a first rendering component and a second rendering component. First, initialization is performed: the window enable attribute is set to true by default, and the state machine is in QT_RENDERING. Next, the stream fetching begins: the second rendering component's start rendering interface (e.g., VARender_Start → PLAY_Play) is called, simultaneously generating a new sessionId and starting a fallback timer to maintain the first rendering and continue displaying the default screen. Then, the ready callback is executed: upon receiving a notification, session consistency is verified and duplicate callbacks are checked. If verification is successful, setUpdatesEnabled(false) is executed, and the second rendering takes over the window display, switching the state to DECODER_RENDERING and stopping the timer. Finally, normal shutdown is performed: VARender_Stop → PLAY_Stop is called to stop rendering and restore the first rendering enable to display the default screen. If a stream error occurs: the second rendering stops and the first rendering resumes to display an error message (e.g., "Stream fetching failed" or "Timeout"). Finally, the last frame is retained: if the entry condition is met, the stop rendering interface is not called and the first rendering is not resumed. The system remains in DECODER_RENDERING (retained mode) and continues to display the last frame. The system initiates a recovery check; if the stream resumes, it automatically exits retained mode; otherwise, it switches to error display.

[0058] In this embodiment, the core functional modules are defined in detail. The first rendering control module is responsible for starting and stopping application framework rendering via the rendering update enable interface, and managing the display of default, waiting, and error screens. The second rendering control module is responsible for starting and stopping video stream rendering via the VARender_Start / Stop and PLAY_Play / Stop interfaces. The state switching control module precisely switches modes based on callbacks, errors, and other events, implementing state machine management to ensure atomicity and consistency. The session management module manages session identifiers and lifecycles, and handles timeout exceptions. The fallback control module detects missing callbacks to ensure that the playback window always has a display. The reserved mode management module manages the entry, exit, and restoration of locked screens.

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

Claims

1. A multimedia playback window rendering control method based on mutual exclusion switching, characterized in that: The method includes: The rendering state machine of the playback window is initialized to the first rendering state, and the rendering update enable interface of the first rendering component of the playback window is activated so as to render the preset screen in the playback window through the first rendering component. In response to the streaming command for the target video stream, a session identifier corresponding to the current streaming task is generated, a fallback detection timer is started, and the rendering start interface of the second rendering component is called. During the second rendering component's preparation for rendering, the rendering state machine is maintained in the first rendering state. In response to receiving a rendering ready callback signal triggered by the second rendering component, the rendering synchronization lock corresponding to the rendering state machine is obtained, and the validity of the rendering ready callback signal is verified based on the session identifier. After the legality check is passed, the switching process is executed, that is, the rendering mutual exclusion switching sequence is executed based on the rendering synchronization lock, including: the state of the rendering state machine is switched to a transition state, and an atomic switching operation is performed in the transition state: the rendering update enable interface of the first rendering component is disabled, and then the second rendering component is activated to take over the handle of the playback window, so that the second rendering component renders the real-time picture of the target video stream in the playback window. Update the state of the rendering state machine to the second rendering state, stop the fallback detection timer, and release the rendering synchronization lock; The method also includes a first-level timeout determination process based on the fallback detection timer: If the fallback detection timer does not receive a valid rendering ready callback signal within the preset first timeout threshold, the rendering state machine remains in the first rendering state. The first rendering component renders a preset buffer waiting prompt screen in the playback window; The method also includes a two-stage timeout determination process: If the fallback detection timer fails to detect a valid rendering ready callback signal within the preset second timeout threshold, the stream retrieval is determined to have failed. Call the stop interface of the second rendering component to maintain the first rendering state and control the first rendering component to render the preset error message screen; The method also includes a display mode determination process in response to playback error events: In response to a stream interruption event of the target video stream, identify the current abnormal display mode; If the abnormal display mode is an error-closed mode, then the process of switching back from the second rendering state to the first rendering state is executed; If a preset abnormal display mode configuration instruction is received and the abnormal display mode is the last frame retention mode, then the retention display process will be entered. The process of entering the reserved display includes: The rendering state machine is kept in the second rendering state, and the rendering update enable interface of the first rendering component is kept in the disabled state. The call to the stop interface of the second rendering component is prohibited, so as to control the second rendering component to remain locked in the playback window and display the last frame of video before the stream was interrupted; The reserved display process also includes automated control logic for resumption and exit: A recovery detection mechanism is initiated to continuously monitor the recovery status of the target video stream through heartbeat detection or status query interfaces; If stream recovery is detected within the preset retention timeout threshold, the stream retrieval session is re-initiated and the switching process is executed. If no stream recovery is detected within the retention timeout threshold, the stop interface of the second rendering component is forcibly invoked, and the rendering update enable interface of the first rendering component is restored to switch back to the first rendering state. The validity of the rendering-ready callback signal is verified based on the session identifier, including: Extract the callback session identifier carried in the rendering ready callback signal; Determine whether the callback session identifier matches the currently active session identifier in the system; If a match is found, the render-ready callback signal is further checked to see if it is a repeating callback signal for the current session. If it is not a repeating callback signal, then the rendering ready callback signal is determined to be a valid signal.

2. The method according to claim 1, characterized in that: The validity of the rendering-ready callback signal is validated based on the session identifier, and the callback delay check is also included. Calculate the time difference between the time the stream fetching command is issued and the time the rendering ready callback signal is received; If the time difference exceeds the preset callback delay threshold, the rendering ready callback signal is determined to be an abnormal callback, and the error display process is forcibly executed.

3. The method according to claim 1, characterized in that: The execution of the rendering mutual exclusion switching sequence includes: under the protection of the rendering synchronization lock, ensuring that the rendering update enable interface of the first rendering component is completely disabled, and then triggering the video frame on-screen operation of the second rendering component, so as to realize the atomic transfer of the takeover rights of the playback window by the first rendering component and the second rendering component on the timeline.

4. The method according to claim 1, characterized in that: The method also includes the user actively stopping the process: In response to a user-triggered stop command, the rendering synchronization lock is acquired, and the stop interface of the second rendering component is called to release window takeover permissions; Reactivate the rendering update enable interface of the first rendering component, reset the rendering state machine to the first rendering state, and then release the rendering synchronization lock.

Images