A parameterized media content template real-time preview system

CN122698792BActive Publication Date: 2026-10-16海看网络科技(山东)股份有限公司
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202611151878.4
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2026-07-31
Publication Date
2026-10-16
Estimated Expiration
2046-07-31

AI Technical Summary

Technical Problem

其一,无法支持多用户并发隔离,该类框架及其配套预览工具均以单用户、单会话、本地开发为设计前提,整个预览服务仅服务一个预览上下文,不能同时为多个在线用户提供相互隔离的预览,若以"每用户独立进程/独立渲染容器"做隔离,资源开销巨大,不可扩展;

Benefits of technology

1、本发明以预览上下文为隔离单元,为每个预览请求创建相互独立的逻辑空间,各上下文在访问标识层面彼此隔离、互不干扰。隔离不依赖“每上下文一独立进程或容器”,使得该类方案从单用户开发工具真正走向在线多用户平台。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122698792B_ABST
    Figure CN122698792B_ABST
Patent Text Reader

Abstract

The application discloses a kind of parameterization media content template real-time preview system, mainly related to media content template preview technical field.It mainly includes: server system and client browser, server system is equipped with preview context manager, the preview context manager includes state management unit and life cycle control unit;State management unit generates the project state data corresponding to the request only according to preview request, and life cycle control unit allocates independent access identification for project state data;Preview stage does not start headless browser process, does not execute pixel-level synthesis, and the preview picture is output by the native rendering pipeline of client browser;After receiving rendering export request, the project state data generated in preview stage is directly provided to rendering module for reuse.The beneficial effects of the present application are that it realizes the context reuse of preview and rendering export, and can be used for efficient real-time preview of parameterized media template.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of media content template preview technology, specifically a parameterized media content template real-time preview system based on a reusable preview context. Background Technology

[0002] Online video editing / compositing platforms aim to allow users to complete the entire process of "selecting a template → uploading materials → adjusting parameters → real-time preview → confirming export" within a browser. However, implementing rich video previews on the web presents a fundamental contradiction: placing the rendering engine on the client side increases development difficulty and limits browser capabilities; placing it on the server side requires waiting for the entire rendering process to complete each preview, making real-time preview impossible.

[0003] In recent years, solutions that describe video using Web standard technologies and use browsers as the rendering pipeline (such as Remotion and HyperFrames) have offered new ideas: the final video is captured and composited frame by frame on the server side, reducing the cost of "rich rendering" from self-developed engines to web page development. However, these frameworks remain at the "developer tool" level, and their server-side rendering often uses "one independent heavy container / sandbox per request." When implemented as a multi-user online platform, two technical pain points remain unresolved: First, it cannot support multi-user concurrent isolation. Such frameworks and their accompanying preview tools are designed based on single-user, single-session, and local development. The entire preview service only serves one preview context and cannot provide isolated previews for multiple online users at the same time. If isolation is achieved by "independent process / independent rendering container for each user", the resource overhead is huge and it is not scalable. Secondly, cross-origin interception prevents the parent page from controlling the preview frame. When the preview content is embedded in the host page's iframe, if the two are from different origins, the browser's same-origin policy prevents the host from accessing the control interface, and the real-time preview is driven by the host and fails.

[0004] Therefore, there is an urgent need for a real-time preview system for parameterized media content templates based on reusable preview contexts to solve the above problems. Summary of the Invention

[0005] The purpose of this invention is to provide a real-time preview system for parameterized media content templates based on a reusable preview context. It enables the reuse of the preview and rendering export contexts and can be used for efficient real-time preview of parameterized media templates.

[0006] To achieve the above objectives, the present invention employs the following technical solution: A real-time preview system for parameterized media content templates is provided, comprising a server-side system and a client-side browser. The server-side system includes a communication interface, a project storage unit, and a rendering module. The client-side browser includes a preview loading module and a state-driven module. Its features are: The server system also includes a preview context manager, which comprises a state management unit and a lifecycle control unit. The state management unit is configured to obtain the template identifier, parameter values, and media resource locations carried in the preview request; read the corresponding template file from the project storage unit according to the template identifier; inject the parameter values ​​into the variable placeholder positions of the template file using text replacement; replace the media resource placeholders in the template file with the media resource locations carried in the preview request; generate project state data uniquely corresponding to the preview request; and store it in the dedicated storage space allocated for the preview context in the project storage unit. The state management unit processes the template file with text replacement as the operation boundary. The input of the text replacement is the template file and parameter values, and the output is an instantiated template file, which is a hypertext markup language file and a script file. The lifecycle control unit is configured to assign an independent access identifier to the project status data, so that the project status data corresponding to different preview requests are isolated from each other in the logical access space. In response to the preview request during the preview phase, the preview context manager returns the project status data to the client browser as a static file through the communication interface. The client browser's preview loading module then calls the browser's native rendering pipeline to execute the screen output. Upon receiving the rendering export request, the lifecycle control unit directly provides the same project status data generated during the preview phase to the rendering module for reuse. The rendering module then launches a headless browser to load the project status data and execute the final rendering output.

[0007] Preferably, the project status data includes: the template instantiation file after parameter injection, parameter injection record, media resource location mapping table, control interface script, and the independent access identifier.

[0008] Preferably, the lifecycle control unit defines the persistence state of the project storage resource corresponding to each preview context as a finite state machine; the state set of the finite state machine includes: Created status: The dedicated storage space has been allocated, but the complete writing of project status data has not yet been completed; Ready status: The dedicated storage space has completed the full writing of project status data, and the independent access identifier has taken effect; Active status: The dedicated storage space is referenced by at least one holder through the independent access identifier, and the reference count is greater than zero; Reusable state: The reference count is zeroed, and the dedicated storage space and its access identifier are retained but not referenced by any holder; Failure status: The dedicated storage space is marked as pending reclamation, and the access identifier has been removed; Destroyed status: The dedicated storage space has been reclaimed, and the access identifier has been deleted; The state transitions of the finite state machine include: When the project status data is completely written to the dedicated storage space, the project transitions from the created state to the ready state. When the client browser loads the project status data for the first time through the access identifier, it transitions from the ready state to the active state. When all holders release references to the access identifier, the process transitions from the active state to the reusable state. When the preview context is idle for more than a preset maximum retention period in the reusable state, it is transitioned from the reusable state to the invalid state. When the dedicated storage space in the failed state is reclaimed, it is transitioned from the failed state to the destroyed state.

[0009] Preferably, the lifecycle control unit further includes a state verification submodule, which stores the current state flag and verifies whether the current state belongs to a valid preceding state of the state to be migrated before each state transition is performed; if it does not belong to the preceding state, the transition is rejected and an abnormal event is recorded.

[0010] Preferably, the lifecycle control unit includes a reference count register configured to record the number of references to the preview context by the holder; when each holder acquires access to the project status data through the access identifier, the value of the reference count register is incremented by one; when each holder releases access, the value of the reference count register is decremented by one; the lifecycle control unit only allows the reclamation of the dedicated storage space when the reference count register reaches zero and the current state is a reusable state or an invalid state.

[0011] Preferably, the lifecycle control unit further includes a lease management subunit, which is configured to issue a lease token with a validity period to each holder. The holder must send a renewal signal through the communication interface before the expiration of the validity period. If the lease management subunit does not receive a renewal signal within the validity period, it determines that the holder has disappeared and sets the holder's contribution value to the reference count register to zero. The lease management subunit works in a complementary manner with the reference count register: the reference count register decrements by one in response to a release signal actively sent by the holder, covering the normal path of active release by the holder; the lease management subunit sets the lease to zero in response to a lease timeout event, covering the abnormal path where the holder is unable to actively send a release signal due to page closure, network interruption, or process crash.

[0012] Preferably, the lifecycle control unit further includes a recovery subunit, which is configured to regenerate the project status data in the project storage unit based on the persistent template identifier, parameter injection record, and media resource location mapping relationship when the project status data in the project storage unit is detected to be corrupted or unreadable due to an anomaly, so that the preview context is restored to a ready state.

[0013] Preferably, the server system further includes a reverse proxy unit, which is configured to map the independent access identifiers of each preview context to a URL sub-path that is from the same origin as the host page of the client browser; the preview loading module loads the project entry file through the URL sub-path and directly calls the control interface script in the project status data through the URL sub-path that is from the same origin, without the need for cross-domain communication intermediaries.

[0014] Preferably, the state-driven module includes a renewal timer and a rendering-driven loop, wherein the renewal timer and the rendering-driven loop are independent of each other; the renewal timer is configured to send a periodic renewal signal to the communication interface at a clock independent of the rendering frame, and the rendering-driven loop is driven by the browser's native request for animation frame callback or timer recursion to perform state positioning operations; the renewal timer and the rendering-driven loop are independent of each other, so that when the client browser switches to a background tab, the rendering-driven loop is throttled or paused while the renewal signal of the renewal timer continues to be sent normally.

[0015] Preferably, the state management unit further includes a rendering entry generation submodule. The rendering entry generation submodule is configured to obtain the project state data held by the preview context manager when the communication interface receives a rendering export request, replace the media resource location in the project state data with the local storage path, and generate a rendering entry file for the rendering module to load, so that the media resource reading in the rendering stage bypasses the reverse proxy unit and directly accesses the local storage.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This invention uses the preview context as an isolation unit, creating independent logical spaces for each preview request. Each context is isolated from the others at the access identifier level, ensuring no interference. This isolation does not rely on "one independent process or container per context," enabling this type of solution to truly move from single-user development tools to online multi-user platforms.

[0017] 2. In this invention, the rendering stage directly reuses the same context instance established in the preview stage, instead of reloading the code and re-initializing the runtime environment. What you see in the preview is what you get in the rendering, and parameter tuning decisions based on the preview screen are reliable, avoiding state drift caused by rebuilding the environment on both sides.

[0018] 3. The preview context, by definition, does not contain a rendering engine or a headless browser. During the preview stage, the server only handles project state and access isolation, without performing pixel-level compositing or encoding. Therefore, the single-context server footprint is extremely small, and concurrency capabilities are no longer limited by memory or CPU, but are determined by lightweight system resources such as file descriptors. This fundamentally avoids the resource bottleneck of the traditional "one independent rendering container per request" and significantly improves the system's concurrency capacity.

[0019] 4. After adjusting the parameters in the browser, users can see a near-finished preview effect within seconds without waiting for the server to render and composite the entire process. This greatly reduces the cost of rework and improves creative efficiency.

[0020] 5. This invention uses the browser's native rendering pipeline to output preview images. The platform does not need to develop its own dedicated rendering engine based on Canvas or WebGL. The video effects are described using Web standard technologies, resulting in low development threshold and high iteration efficiency. Attached Figure Description

[0021] Figure 1 This is a block diagram of the overall architecture of the real-time preview system for parameterized media content templates of this invention; Figure 2 This is a sequence diagram of the preview and rendering export context reuse process of the present invention; Figure 3 This is a schematic diagram of the reverse proxy same-origin mapping structure of the present invention. Detailed Implementation

[0022] The present invention will be further illustrated below with reference to specific embodiments. It should be understood that these embodiments are for illustrative purposes only and are not intended to limit the scope of the invention. Furthermore, it should be understood that after reading the teachings of this invention, those skilled in the art can make various alterations or modifications to the invention, and these equivalent forms also fall within the scope defined in this application.

[0023] In this invention, terms such as "upper," "lower," "left," "right," "front," "back," "vertical," "horizontal," "side," and "bottom" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. These terms are used only to facilitate the description of the structural relationships of the various components or elements of this invention and do not specifically refer to any component or element in this invention. They should not be construed as limiting the invention.

[0024] Example: like Figure 1 As shown, this embodiment provides a parameterized media content template real-time preview system, which includes two main parts: a client browser and a server system.

[0025] The client browser runs on the user's terminal device and includes a preview loading module and a state-driven module. The preview loading module loads the project entry file returned by the server and calls the browser's native rendering pipeline to output the preview screen; the state-driven module sends state positioning instructions to the preview context at a preset step frequency, driving the browser's native rendering pipeline to update the screen frame by frame.

[0026] The server-side system is deployed on a server cluster and includes a communication interface, project storage unit, preview context manager, rendering module, and reverse proxy unit.

[0027] The communication interface is an HTTP / HTTPS protocol interface, configured to receive preview requests and rendering export requests from the client's browser, and return the server-side processing results to the client.

[0028] The project storage unit is a distributed file storage system configured to store template source files and project status data generated for each preview request. Each preview context is allocated its own dedicated storage space within the project storage unit, and the storage spaces of different preview contexts are isolated from each other at the file system level.

[0029] The preview context manager is the core management module in this embodiment, including a state management unit and a lifecycle control unit.

[0030] The state management unit is configured to create, read, and update project state data. Upon receiving a preview request, the state management unit retrieves the template identifier, parameterized variable values, and media resource locations carried in the request. Based on the template identifier, it reads the corresponding template source file from the project storage unit, injects the parameterized variable values ​​into the variable placeholder positions in the template file using text replacement, and replaces the media resource placeholders in the template file with the media resource locations, generating project state data uniquely corresponding to the preview request. The text replacement and injection operations only involve string-level processing and do not involve pixel-level image compositing, video frame encoding, or media stream compression calculations; therefore, the processing speed is extremely fast, typically completed in milliseconds.

[0031] Project status data includes: the template instantiation file after parameter injection, parameter injection records, a media resource location mapping table, control interface scripts, and independent access identifiers. The template instantiation file is in HTML format and contains a complete page structure and style definitions; the parameter injection records store the mapping relationship between the original values ​​and injected values ​​of all variables, used for subsequent state recovery; the media resource location mapping table records the actual access addresses of all media resources (images, videos, audio, etc.) referenced in the template; and the control interface script provides a state control API for external calls, used to drive playback progress, adjust parameters, and perform other operations.

[0032] The lifecycle control unit is configured to assign independent access identifiers and control the lifespan of project status data. Each preview context is assigned a globally unique independent access identifier (UUID format), and the project status data corresponding to different preview requests are logically isolated from each other in the access space through this access identifier. The isolation is a lightweight logical isolation that does not rely on independent processes or containers, but is only achieved through file system directory partitioning and URL routing. Therefore, a single server can support thousands of concurrent preview contexts simultaneously.

[0033] The lifecycle control unit defines the persistence state of the project storage resource corresponding to each preview context as a finite state machine. The state set of the finite state machine includes six states: (1) Created status: Dedicated storage space has been allocated, but the project status data has not yet been fully written. At this time, the access identifier is not yet effective, and the client cannot access the project data through this identifier.

[0034] (2) Ready state: The dedicated storage space has completed the writing of the project status data, and the independent access identifier has taken effect, allowing access by the client browser. At this time, the preview context awaits the client's first loading.

[0035] (3) Active state: The dedicated storage space is referenced by at least one holder through an independent access identifier, and the reference count is greater than zero. At this time, the preview context is in normal use, and the server must ensure the integrity of the data and the availability of access.

[0036] (4) Reusable state: The reference count is zero, and the exclusive storage space and its access identifier are retained but not referenced by any holder. At this time, the preview context is in an idle retention state. If a new request with the same parameters arrives within the preset maximum retention period, the context can be reused directly without recreating it.

[0037] (5) Failure status: The dedicated storage space is marked as pending reclamation, and the access identifier has been removed. At this time, the client can no longer access the context using the original access identifier, and the storage space awaits the reclamation process for cleanup.

[0038] (6) Destroyed: The dedicated storage space has been reclaimed and the access identifier has been deleted. At this time, all resources of the preview context have been released and cannot be recovered.

[0039] The state transition rules for a finite state machine are as follows: When the project status data is completely written to the dedicated storage space, it will transition from the created state to the ready state. When the client browser first loads the project status data through the access identifier, it transitions from the ready state to the active state. When all holders release references to the access token, the process transitions from an active state to a reusable state. When the preview context is idle in the reusable state for more than the preset maximum retention period (e.g., 30 minutes), it will be transitioned from the reusable state to the invalid state. When the dedicated storage space in the failed state is reclaimed by the recycling process, it transitions from the failed state to the destroyed state.

[0040] The lifecycle control unit also includes a state verification submodule. This submodule stores the current state flag and verifies whether the current state belongs to a valid preceding state of the state to be migrated before each state transition. If it does not belong to the preceding state, the transition is rejected and an exception event is recorded. This mechanism effectively prevents system inconsistencies caused by illegal state transitions.

[0041] The lifecycle control unit also includes a reference count register, configured to record the number of references to the preview context by each holder. The reference count register is incremented by one each time a holder gains access to the project status data via an access identifier; it is decremented by one each time a holder releases access. The lifecycle control unit only allows the reclamation of dedicated storage space when the reference count register reaches zero and the current state is either reusable or invalid.

[0042] The lifecycle control unit also includes a lease management subunit, which is configured to issue a lease token with a validity period (e.g., 30 seconds) to each holder. The holder must send a renewal signal via the communication interface before the validity period expires; if the lease management subunit does not receive a renewal signal within the validity period, it determines that the holder has disappeared and sets the holder's contribution value to the reference count register to zero.

[0043] The lease management subunit and the reference count register work in tandem: the reference count register decrements by one in response to a release signal actively sent by the holder, covering the normal path of active release by the holder; the lease management subunit sets the reference count to zero in response to lease timeout events, covering the abnormal path where the holder is unable to actively send a release signal due to page closure, network interruption, or process crash. Together, they ensure the accuracy of the reference count and prevent resource leaks caused by abnormal exits of the holder.

[0044] The lifecycle control unit also includes a recovery subunit. This subunit is configured to regenerate the project state data in the project storage unit when it detects that the project state data in the project storage unit is corrupted or unreadable due to anomalies (such as disk errors, file corruption, or system crashes). This restores the preview context to a ready state. This mechanism significantly improves the system's fault tolerance and availability.

[0045] The workflow for reusing the preview and rendering export context in this embodiment is as follows: Step S1: The client browser sends a preview request to the communication interface, which includes the template identifier, parameterized variable values, and media resource location information. Step S2: The communication interface forwards the preview request to the preview context manager. The status management unit generates project status data based on the request parameters and writes it to the dedicated storage space of the project storage unit. Step S3: The lifecycle control unit assigns an independent access identifier to the project's status data and sets the preview context status to the ready state; Step S4: The communication interface returns the access address containing the unique access identifier to the client browser; Step S5: The client browser's preview loading module loads the project entry file through the access address and calls the browser's native rendering pipeline to output the preview screen; the state-driven module drives the rendering pipeline to update the screen frame by frame according to a preset step frequency to achieve a real-time preview effect. Step S6: When the user adjusts the parameters during the preview process, the client browser sends a parameter update request to the server, the status management unit updates the corresponding parameter value in the project status data, and the client reloads and renders, realizing real-time feedback on parameter adjustments; Step S7: When the user confirms the preview effect and requests rendering and export, the client browser sends a rendering and export request to the communication interface, carrying the access identifier of the original preview context in the request; Step S8: The lifecycle control unit locates the corresponding preview context based on the access identifier and directly provides the same project status data generated in the preview stage to the rendering module for reuse, without the need for re-creation and initialization; Step S9: The rendering module launches a headless browser (such as HeadlessChrome) to load project state data, perform frame-by-frame rendering and video encoding, and output the final media file; Step S10: After rendering is complete, the rendering module returns the output media file to the user, and the preview context can be retained or released according to the configuration.

[0046] The preview context manager does not launch a headless browser process or perform pixel-level compositing and encoding of media frames during the preview phase. The preview screen is entirely output by the client browser's native rendering pipeline. The rendering module only launches the headless browser to perform rendering during the final rendering and export phase. This design results in extremely low server-side resource consumption during the preview phase, allowing a single server to support a large number of concurrent preview users.

[0047] like Figure 3 As shown, the server system also includes a reverse proxy unit, which is configured to map the independent access identifiers of each preview context to URL subpaths that are from the same origin as the host page of the client browser.

[0048] Specifically, assuming the host page's domain is https: / / editor.example.com, the reverse proxy unit maps each preview context to: https: / / editor.example.com / preview / ctx-a1b2c3 / ; https: / / editor.example.com / preview / ctx-d4e5f6 / ; https: / / editor.example.com / preview / ctx-g7h8i9 / Among them, ctx-a1b2c3, ctx-d4e5f6, and ctx-g7h8i9 are independent access identifiers for different preview contexts. Since these URLs belong to the same domain as the host page, editor.example.com, they comply with the browser's same-origin policy.

[0049] The preview loading module loads the project entry file via the aforementioned same-origin URL subpath and directly calls the control interface script in the project status data via the same-origin URL subpath, without the need for cross-domain communication intermediaries. This design solves the cross-domain communication problem when embedding previews in traditional iframes, allowing the host page to directly call the control interface of the preview frame, achieving seamless real-time parameter adjustment and status synchronization.

[0050] The state-driven module includes a renewal timer and a rendering-driven loop, which are independent of each other. The renewal timer is configured to send a periodic renewal signal to the communication interface at a clock independent of the rendering frame (e.g., once per second); the rendering-driven loop is driven by browser native requestAnimationFrame callbacks or timer recursion to perform state positioning operations.

[0051] The independent design of the lease renewal timer and the rendering drive loop ensures that when the client browser switches to a background tab, the browser's rendering drive loop may be throttled or paused, but the lease renewal timer's renewal signal will still be sent normally. This guarantees that even if the user switches the preview page to the background, the preview context will not be incorrectly reclaimed due to lease expiration.

[0052] The state management unit also includes a rendering entry generation submodule. This submodule is configured to, upon receiving a rendering export request via the communication interface, retrieve the project state data held by the preview context manager, replace the media resource location in the project state data with the local storage path, and generate a rendering entry file for the rendering module to load. Since the rendering module runs locally on the server, it can directly access locally stored media resources. Therefore, media resource reading during the rendering phase bypasses the reverse proxy unit and directly accesses the local file system, significantly improving resource loading speed during rendering.

[0053] The above is a detailed description of the preferred embodiments of the present invention, but the present invention is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention, and these equivalent modifications or substitutions are all included within the scope defined by the claims of this application.

Claims

1. A real-time preview system for parameterized media content templates, comprising a server-side system and a client-side browser, wherein the server-side system is equipped with a communication interface, a project storage unit, and a rendering module, and the client-side browser is equipped with a preview loading module and a state-driven module; characterized in that: The server system also includes a preview context manager, which comprises a state management unit and a lifecycle control unit. The state management unit is configured to obtain the template identifier, parameter values, and media resource location carried in the preview request; read the corresponding template file from the project storage unit according to the template identifier; inject the parameter values ​​into the variable placeholder positions of the template file by text replacement; replace the media resource placeholders in the template file with the media resource location carried in the preview request; generate project state data uniquely corresponding to the preview request; and store it in the dedicated storage space allocated for the preview context in the project storage unit. The state management unit processes the template file with text replacement as the operation boundary. The input of text replacement is the template file and parameter values, and the output is an instantiated template file, which is a hypertext markup language file and a script file. The lifecycle control unit is configured to assign independent access identifiers to project status data, so that the project status data corresponding to different preview requests are isolated from each other in the logical access space. In response to the preview request during the preview phase, the preview context manager returns the project status data to the client browser in the form of a static file through the communication interface. The client browser's preview loading module then calls the browser's native rendering pipeline to execute the screen output. After receiving the rendering export request, the lifecycle control unit directly provides the same project status data generated during the preview phase to the rendering module for reuse. The rendering module then launches the headless browser to load the project status data to execute the final rendering output.

2. The system according to claim 1, characterized in that, The project status data includes: the template instantiation file after parameter injection, parameter injection records, media resource location mapping table, control interface script, and the independent access identifier.

3. The system according to claim 1, characterized in that, The lifecycle control unit defines the persistence state of the project storage resource corresponding to each preview context as a finite state machine; the state set of the finite state machine includes: Created status: The dedicated storage space has been allocated, but the complete writing of project status data has not yet been completed; Ready status: The dedicated storage space has completed the full writing of project status data, and the independent access identifier has taken effect; Active status: The dedicated storage space is referenced by at least one holder through the independent access identifier, and the reference count is greater than zero; Reusable state: The reference count is zeroed, and the dedicated storage space and its access identifier are retained but not referenced by any holder; Failure status: The dedicated storage space is marked as pending reclamation, and the access identifier has been removed; Destroyed status: The dedicated storage space has been reclaimed, and the access identifier has been deleted; The state transitions of the finite state machine include: When the project status data is completely written to the dedicated storage space, it transitions from the created state to the ready state; When the client browser first loads the project status data through the access identifier, it transitions from the ready state to the active state. When all holders release references to the access token, the process transitions from an active state to a reusable state. When the preview context is idle for more than the preset maximum retention period in the reusable state, it will transition from the reusable state to the invalid state. When the dedicated storage space in a failed state is reclaimed, it is transitioned from a failed state to a destroyed state.

4. The system according to claim 3, characterized in that, The lifecycle control unit also includes a state verification submodule, which stores the current state flag and verifies whether the current state belongs to the valid preceding state of the state to be migrated before each state transition is executed; if it does not belong to the preceding state, the transition is rejected and the abnormal event is recorded.

5. The system according to claim 1, characterized in that, The lifecycle control unit includes a reference count register configured to record the number of references to the preview context by the holder; when each holder obtains access to the project status data through the access identifier, the value of the reference count register is incremented by one; when each holder releases access, the value of the reference count register is decremented by one; the lifecycle control unit only allows the reclamation of the dedicated storage space when the reference count register is zero and the current state is a reusable state or an invalid state.

6. The system according to claim 5, characterized in that, The lifecycle control unit also includes a lease management subunit, which is configured to issue a lease token with a validity period to each holder. The holder must send a renewal signal through the communication interface before the expiration of the validity period. If the lease management subunit does not receive a renewal signal within the validity period, it determines that the holder has disappeared and sets the holder's contribution value to the reference count register to zero. The lease management subunit works in a complementary manner with the reference count register: the reference count register decrements by one in response to a release signal actively sent by the holder, covering the normal path of active release by the holder; the lease management subunit sets the lease to zero in response to a lease timeout event, covering the abnormal path where the holder is unable to actively send a release signal due to page closure, network interruption, or process crash.

7. The system according to claim 1, characterized in that, The lifecycle control unit further includes a recovery subunit, which is configured to regenerate the project status data in the project storage unit based on the persistent template identifier, parameter injection record, and media resource location mapping relationship when the project status data in the project storage unit is detected to be corrupted or unreadable due to an anomaly, so that the preview context is restored to a ready state.

8. The system according to claim 1, characterized in that, The server-side system also includes a reverse proxy unit, which is configured to map the independent access identifier of each preview context to a URL sub-path that is from the same origin as the host page of the client browser. The preview loading module loads the project entry file through the URL sub-path and directly calls the control interface script in the project status data through the same origin URL sub-path, without the need for cross-domain communication intermediaries.

9. The system according to claim 6, characterized in that, The state-driven module includes a renewal timer and a rendering drive loop, which are independent of each other. The renewal timer is configured to send a periodic renewal signal to the communication interface at a clock independent of the rendering frame. The rendering drive loop is driven by the browser's native request for animation frame callbacks or timer recursion to perform state positioning operations. The independence of the renewal timer and the rendering drive loop ensures that when the client browser switches to a background tab, the rendering drive loop is throttled or paused while the renewal signal of the renewal timer continues to be sent normally.

10. The system according to claim 1, characterized in that, The state management unit also includes a rendering entry generation submodule. The rendering entry generation submodule is configured to obtain the project state data held by the preview context manager when the communication interface receives a rendering export request, replace the media resource location in the project state data with the local storage path, and generate a rendering entry file for the rendering module to load, so that the media resource reading in the rendering stage bypasses the reverse proxy unit and directly accesses the local storage.

Citation Information

Patent Citations

  • Page pre-rendering method, system and equipment based on server browser

    CN115329225A

  • Video preview method and device, medium, equipment and computer program product

    CN115967824A