A presentation synchronization method based on file page identifiers

Abstract

The application relates to a speech synchronization method based on a file page identifier, which comprises the following steps: a speech terminal captures a file page identifier of current display content, and sends the file page identifier to a center server through a long connection communication channel; the center server encapsulates the received file page identifier into a synchronization instruction, and broadcasts the synchronization instruction to participating terminals through the long connection communication channel; the participating terminals extract the file page identifier in the synchronization instruction, acquire corresponding file content from a local cache or a file server based on the file page identifier, and locally render and display a picture corresponding to the current display content. By changing the speech synchronization from video stream transmission to data transmission based on the file page identifier, the limitation of traditional screen sharing is broken, the speech terminal only captures a file ID and a page number to generate a light identifier and sends the light identifier, the participating terminals autonomously acquire files from the local or the server after receiving the light identifier, and independently render the files, so that the participating terminals no longer passively receive video pictures.

Description

Technical Field

[0001] This application relates to the field of data synchronization, and in particular to a presentation synchronization method based on file page identifiers. Background Technology

[0002] Current general-purpose conferencing software typically uses "remote video communication" as its core architecture, and its content sharing function is mainly implemented through screen mirroring (screen sharing). When the presenter shares content, the system encodes the presenter's entire screen into a video stream in real time and transmits it to other participants' terminals over the network. This mechanism has the following shortcomings: I. The video streaming mechanism leads to deep coupling between content sharing and terminal operation. Participants' terminals can only passively receive and play video streams, with the entire screen display area occupied by the projected image. Independent operations such as reviewing other materials, searching case information, and taking notes are impossible within the meeting software. The essence of the problem is that the existing solution treats shared content as a continuous stream of video pixels, failing to decouple content sharing from local terminal operations.

[0003] II. Lack of a file-object-oriented page-level synchronization control mechanism Because screen mirroring only transmits video, the system cannot perceive or distinguish structured objects such as "files" and "pages." When a speaker turns pages or switches materials, all terminals only see the screen change and cannot perform precise synchronization control at the file / page level. Simultaneously, new participants cannot automatically obtain the specific file and page number of the current presentation and can only passively wait for the next screen refresh, lacking the ability to actively follow and synchronize in real time. The essence of this problem lies in the fact that the existing solution lacks a data transmission and synchronization model based on file / page identifiers as the basic unit.

[0004] In summary, existing technologies, limited by the video streaming architecture, cannot decouple content sharing from independent terminal operation, nor can they achieve precise page-level synchronization at the file object level. Therefore, there is an urgent need for a presentation synchronization method based on data transmission rather than video streaming to solve these problems. Summary of the Invention

[0005] This application provides a presentation synchronization method based on file page identifiers, which at least solves the problem of inability to achieve accurate synchronization in related technologies.

[0006] In a first aspect, embodiments of this application provide a presentation synchronization method based on file page identifiers, applied to a conferencing system where a central server and terminals collaborate. The terminals include a presenting terminal and at least one participating terminal. After activating the presentation mode, the method includes: The presentation terminal captures the file page identifier of the currently displayed content and sends the file page identifier to the central server through a long-connection communication channel; The central server encapsulates the received file page identifier into a synchronization instruction, uses the synchronization instruction as the authoritative synchronization status of the current presentation, and broadcasts the synchronization instruction to the participating terminals through a long-connection communication channel; The terminal extracts the file page identifier from the synchronization command, retrieves the corresponding file content from the local cache or file server based on the file page identifier, and renders and displays the corresponding currently displayed content locally. The file page identifier must include at least a unique file identifier and page number information.

[0007] In one embodiment, the presentation terminal captures the file page identifier of the currently displayed content and sends the file page identifier to the central server via a long-connection communication channel, including: The presentation terminal monitors the speaker's actions on the currently displayed content, captures the currently displayed content based on the actions, and generates a file page identifier. The file page identifier is reported to the central server through a long-connection communication channel.

[0008] In one embodiment, the central server encapsulates the received file page identifier into a synchronization instruction, uses the synchronization instruction as the authoritative synchronization status of the current presentation, and broadcasts the synchronization instruction to participating terminals through a long-connection communication channel, including: The central server encapsulates the received file page identifier into a synchronization instruction, verifies the file page identifier, and stores it as the authoritative synchronization status of the current presentation. The central server locates participating terminals based on the meeting identifier, decouples and distributes the data across multiple nodes through a message middleware, and pushes synchronization instructions to the participating terminals.

[0009] In one embodiment, the participating terminal extracts the file page identifier from the synchronization instruction, retrieves the corresponding file content from the local cache or file server based on the file page identifier, and renders and displays the screen corresponding to the currently displayed content locally, including: The terminal parses the file's unique identifier and page number parameters in the synchronization command, and retrieves the file content corresponding to the file's page identifier from the local cache based on the file's unique identifier. If the local cache is not found, the file unique identifier is used to request the corresponding file from the file server as needed; Once the file content is obtained, the target page is accurately located based on the page number. Combined with the current split-screen layout parameters, local rendering is completed and the display is adapted to the screen area.

[0010] In one embodiment, the method further includes a pre-storage operation of the file content, comprising: During the meeting preparation phase, pre-download the file content belonging to the currently displayed content in batches based on the list of documents associated with the meeting. If a synchronization command is received during a meeting but the file content has not yet been cached, the participating terminal will retrieve the file content from the file server in real time and write it to the local cache. Each time the local cache is read, the file content is checked for integrity. When the version of the file content changes, an automatic cache refresh is triggered.

[0011] In one embodiment, before locally rendering and displaying the screen corresponding to the currently displayed content, the method further includes: The original file content is pre-converted into a PDF file through a separate file conversion module, and the original file and the PDF file each maintain independent integrity verification information.

[0012] In one embodiment, the original file and the PDF file each maintain independent integrity verification information, including: In split-screen mode, each file independently maintains its file identifier, page number, and layout position, and the rendering process of each file is completely decoupled. When the speaker switches between one file, the display of the other files remains unchanged.

[0013] In one embodiment, it further includes: The presentation terminal and the participating terminal are equipped with a rendering module for rendering executable files, and a synchronization module for synchronizing the presentation. The rendering module relies solely on file path and page number parameters to complete the local rendering of the page, while the synchronization module is responsible for receiving synchronization instructions pushed through the long-connection communication channel. The rendering module and the synchronization module exchange data through a shared file page identifier, and are independent of each other in terms of execution logic; In the event of a brief interruption of the long-connection communication channel, the rendering modules that are already in place will maintain the normal display of the current page.

[0014] In one embodiment, while rendering and displaying the screen corresponding to the currently displayed content locally, an annotation synchronization display operation is also performed, including: An independent transparent annotation canvas layer is overlaid on the screen displayed on the participating terminal; Listen for pointer events on the transparent annotation canvas layer, capture user annotation operations, and generate annotation data messages; the annotation data messages include annotation identifier, file identifier, page number, drawing type, color, line width, coordinate trajectory, timestamp, and operator identifier; The annotation data message is sent to the central server through the real-time data channel; The central server will broadcast the annotation data message to other online participants in the current meeting; Other online participating terminals receive and parse the annotation data messages, and render the annotation trajectory in the same style at the same coordinate position on the corresponding page of the corresponding file, so as to realize the real-time synchronous display of annotations.

[0015] In one embodiment, listening to pointer events on the transparent annotation canvas layer, capturing user annotation operations, and generating annotation data messages includes: When the pointer is pressed, the absolute coordinates of the pen stroke are recorded and the corresponding graphic object is created. Based on the currently selected drawing tool type, the corresponding basic graphic element is generated, and a unique client identifier is assigned to each graphic element. During pointer movement, the geometric parameters of the graphic elements are updated in real time; for brush tools, the path coordinate point sequence is continuously accumulated according to the preset sampling frequency; for shape tools, every movement event is fully responded to, the graphic size is dynamically adjusted and rendered in real time. After the pointer lift event is triggered, incremental recognition is performed on the graphical objects generated within a complete operation cycle, and new annotations are determined by comparing the client's unique identifier with the persisted data. The newly added annotations are serialized into a preset data structure. The data structure includes the geometric parameters of the annotation area under the basic scaling reference, the drawing type identifier, the line width and color attributes. The trajectory of the brush tool is encapsulated in the form of an array of coordinate points. The encapsulated annotation data message is transmitted through both a persistent interface and a real-time broadcast channel. Other online participating terminals use the same coordinate reference system to reverse-parse the annotation data messages and restore them into renderable graphical description data.

[0016] The presentation synchronization method based on file page identifiers provided in this application has at least the following technical effects.

[0017] This invention fundamentally overcomes the limitations of traditional screen sharing by transforming presentation synchronization from video streaming to data transmission based on file page identifiers. Addressing the issue of coupling content sharing with terminal operation, the presenting terminal only captures the file ID and page number to generate a lightweight identifier and sends it. Participating terminals, upon receiving this identifier, autonomously retrieve the file from their local machine or server and render it independently, no longer passively receiving video feeds. This frees up the screen, supporting parallel independent operations such as note-taking and browsing, achieving decoupling. Addressing the lack of page-level synchronization control, the identifier precisely locates the displayed content at the file object and page number granularity. The central server encapsulates this into a synchronization command and stores it as an authoritative state. All terminals synchronize precisely based on this, and newly joined terminals can obtain this state at any time to actively follow without waiting for the next page turn, establishing a fine-grained synchronization mechanism at the file page level. This invention ensures original image quality with extremely low bandwidth, endows terminals with multitasking capabilities, and significantly improves the real-time performance, flexibility, and interactive efficiency of meetings.

[0018] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0019] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart of presentation synchronization based on file page identifiers provided by relevant technologies; Figure 2 This is a flowchart of step S30 provided by relevant technology; Figure 3 This is a flowchart of step S50 provided by relevant technology. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0021] Obviously, the accompanying drawings described below are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar scenarios based on these drawings without any inventive effort. Furthermore, it is understood that although the efforts made in this development process may be complex and lengthy, for those skilled in the art related to the content disclosed in this application, any changes to design, manufacturing, or production based on the technical content disclosed in this application are merely conventional technical means and should not be construed as insufficient disclosure of the content of this application.

[0022] This application provides a presentation synchronization method based on file page identifiers, applied to a conferencing system where a central server and terminals collaborate. The terminals include a presenting terminal and at least one participating terminal. After activating the presentation mode... Figure 1 This is a flowchart of the method, such as... Figure 1 As shown, it includes: In step S10, the presentation terminal captures the file page identifier of the currently displayed content and sends the file page identifier to the central server via a long-connection communication channel. The file page identifier contains at least a unique file identifier and page number information.

[0023] The presentation terminal monitors the speaker's page turning and file switching operations, automatically extracts the unique identifier and page number of the currently displayed file, generates a lightweight file page identifier, and sends it to the central server in real time via a long-connection communication channel, without capturing the screen or performing video encoding. By replacing the video stream with structured data, pixel-by-pixel transmission is avoided at the source, enabling independent operation of the terminal. At the same time, the identifier precisely defines the synchronization granularity with file ID and page number, laying the foundation for page-level control.

[0024] In step S30, the central server encapsulates the received file page identifier into a synchronization instruction, uses the synchronization instruction as the authoritative synchronization status of the current presentation, and broadcasts the synchronization instruction to the participating terminals through a long-connection communication channel.

[0025] The central server encapsulates the received identifier into a standard synchronization command, stores it as the unique authoritative synchronization state for the current meeting (e.g., written to a cache), and broadcasts it to all participating terminals via a long-lived connection. This authoritative state allows newly joined terminals to instantly query and synchronize the current page, resolving the "inability to actively follow" issue; unified broadcasting ensures all terminals receive the same page identifier, achieving precise synchronization control at the file page level.

[0026] In step S50, the participating terminal extracts the file page identifier from the synchronization instruction, retrieves the corresponding file content from the local cache or file server based on the file page identifier, and renders and displays the screen corresponding to the currently displayed content locally.

[0027] The process involves the terminal parsing synchronization commands to obtain the file ID and page number, prioritizing the search for the corresponding file in the local cache. If the file is not found, it requests the file from the file server as needed. Finally, the local rendering engine independently completes the page rendering and display. The terminal autonomously loads and renders files, completely eliminating its passive dependence on video streams. This frees up screen space, allowing for parallel execution of operations such as note-taking and browsing within independent interface modules, achieving complete decoupling between content sharing and independent terminal operation.

[0028] The core of the above solution lies in transmitting a lightweight file page identifier, rather than a video stream. This brings the following benefits: Extremely low bandwidth consumption: Synchronization commands consist of only short data packets containing file IDs and page numbers. Compared to transmitting high-definition video streams, network bandwidth consumption is reduced by several orders of magnitude, ensuring smooth operation even in mobile or weak network environments.

[0029] Lossless image quality: Each participating terminal renders the file content independently on its local machine, displaying vector or high-fidelity PDF pages, completely avoiding issues such as image quality degradation, blurring, or compression artifacts caused by video encoding.

[0030] Operation and display can proceed in parallel: Since rendering is based on local files, while the terminal displays the presentation page, other operations (such as looking up information or taking notes) can be performed in an independent interface module. These operations do not occupy the presentation synchronization channel or affect the display of the main screen, thus achieving true multi-tasking in parallel.

[0031] Content consistency guarantee: The central server broadcasts the received file page identifier as the authoritative synchronization status, ensuring that all participating terminals display the same page of the same file, eliminating display differences between multiple terminals.

[0032] In one embodiment, step S10 includes: Step S11: The presentation terminal listens to the speaker's actions on the currently displayed content, captures the currently displayed content based on the actions, and generates a file page identifier.

[0033] Step S12: The file page identifier is reported to the central server through a long-connection communication channel.

[0034] In implementation, after the meeting begins, the speaker activates presentation mode on their presentation terminal. At this time, a lightweight monitoring process is initiated on the presentation terminal to continuously monitor the user's actions on the currently displayed document. Assume the speaker is presenting a PDF document titled "2025 Market Plan" to the attendees, currently on page 5. When the speaker turns to page 6, the monitoring process immediately captures this action. The captured content is not simply a screenshot, but rather the extraction of a set of structured data from the currently displayed document object, namely the document page identifier. This identifier is a data tuple whose key fields include at least two parts: a unique document identifier and page number information, for example: `file-id`: A unique file identifier. For example, a globally unique string "FILE-2025-MARKET-PLAN-V3" is used to precisely locate a specific file in the system, unaffected by filename changes. `pageNum`: Page number information. For example, the integer "6" represents the currently displayed page number. The generated `{file-id: "FILE-2025-MARKET-PLAN-V3", pageNum: 6}` is the core data for this synchronization. The presentation terminal then reports this file page identifier as a payload to the central server via a long-lived communication channel (such as a WebSocket connection) maintained with the central server, using a lightweight message body (such as JSON format).

[0035] Specifically, this section provides a more detailed explanation of how to dynamically capture the currently displayed content based on user actions.

[0036] Unlike static screenshots, this step captures changes in the file display state caused by user actions. The presentation terminal has a built-in state monitoring engine, which registers as an event listener for the operating system or application software. The specific implementation process is as follows: Event registration and interception: When the presentation mode is started, the listening engine subscribes to specific events in the file display area through the accessibility API or application plugin interface provided by the operating system. These events mainly include: mouse click events (corresponding to page turning buttons), keyboard events (corresponding to PageUp / PageDown keys), touch screen swipe events, and file tab switching events.

[0037] State Snapshot Generation: When the listening engine captures a predefined event, it doesn't capture screen pixels; instead, it immediately queries the internal state of the application currently displaying the file. For example, if the query finds that the currently focused file object is a document with the file-id "FILE-2025-MARKET-PLAN-V3" and its current view page number attribute is "6", the listening engine immediately assembles these two pieces of information to generate a file page identifier.

[0038] Real-time reporting: The action of generating identifiers is instantaneous. Each valid operation (such as a page turn or a file switch) triggers an atomic "capture-generate-report" operation, ensuring that the reporting of identifiers is strictly synchronized with the speaker's actions in real time. For example, when the speaker quickly presses the PageDown key three times in succession, the listening engine will capture the state changes of page 5 → page 6, page 6 → page 7, and page 7 → page 8 in sequence, and continuously generate and report three corresponding file page identifiers.

[0039] This step further defines the specific method by which the presentation terminal captures file page identifiers. By monitoring the speaker's actions (such as page turning and file switching), the current presentation state is automatically captured and identifiers are generated. This eliminates the need for the speaker to manually trigger synchronization commands, freeing their hands and allowing them to focus on the content presentation, resulting in a more natural flow. Simultaneously, the actions, identifier generation, and reporting are completed synchronously, achieving instant synchronization of page switching and avoiding delays and omissions associated with traditional manual push or timed screenshot methods. Directly extracting file identifiers and page numbers based on actions ensures strict consistency between the synchronization state and the actual content presented by the speaker, eliminating errors caused by human error.

[0040] In one embodiment, such as Figure 2 As shown, step S30 includes: In step S31, the central server encapsulates the received file page identifier into a synchronization instruction, verifies the file page identifier, and stores it as the authoritative synchronization status of the current presentation.

[0041] In step S32, the central server locates participating terminals based on the meeting identifier, performs multi-node decoupling and distribution through message middleware, and pushes synchronization instructions to participating terminals.

[0042] In implementation, the technical feature of "encapsulating the received file page identifier into a synchronization instruction" is explained in detail from two dimensions: the purpose of encapsulation and the specific processing steps.

[0043] A simple file page identifier (such as {file-id: “xxx”, pageNum: 5}) is merely a set of data values ​​and does not constitute a complete instruction that can be reliably transmitted, traceable, and scalable in a distributed system. Meanwhile, the conference system contains multiple concurrent conferences and a large number of terminals. The encapsulation process adds metadata fields such as conference identifier, initiator identifier, timestamp, and instruction type to the instruction. This enables broadcast nodes to accurately route instructions based on the conference ID, allows receiving ends to identify the source of instructions and perform deduplication and sorting, and provides a complete operational context for subsequent playback auditing.

[0044] The packaging process includes the following steps: Step 1: The long-connection gateway of the central server receives the original message reported by the speaking terminal.

[0045] Step 2: The synchronization processing module extracts the original file page identifier from the payload and performs validation operations, including field integrity checks and data type checks. If the validation fails, an error response is returned directly and the encapsulation process is terminated; if the validation succeeds, the process proceeds to the next step.

[0046] Step 3: After successful verification, generate a series of instruction-level metadata for this synchronization operation, including: instruction unique identifier, timestamp, session identifier, initiator identifier, instruction type identifier, and protocol version number.

[0047] Step 4: Assemble the verified original file page identifier and the metadata generated in Step 3 according to the predefined data structure to form a self-contained synchronization command message.

[0048] Step 5: The assembled instruction object is serialized into a compact binary format and delivered according to the subsequent processing path: Authoritative state storage path: The serialized instruction is used as the value to establish the authoritative synchronization state of the current meeting; Message middleware delivery path: The serialized instruction is delivered to the agreed topic of the message middleware for each service node to consume and execute broadcast.

[0049] The original file page identifier, which only contains business data, is transformed into a standardized synchronization instruction with a complete context, independent routing, traceable origin, and scalable version, enabling reliable, efficient, and asynchronous distribution in distributed systems.

[0050] After receiving the file page identifier reported by the speaking terminal, the central server executes a crucial authoritative synchronization state establishment and broadcasting process. This is one of the core features that distinguishes this application from simple message forwarding, and the specific process and purpose are as follows: First, the server validates the received data, checking things like whether the file-id is associated with a valid file for the current meeting and whether the pageNum is within a valid range. If the validation passes, the server doesn't broadcast immediately. Instead, it writes this {file-id, pageNum} data, along with the speaker ID and the current timestamp, into a cache and assigns a key-value pair to establish this data as the authoritative speaker's synchronization status for the current meeting.

[0051] Secondly, after completing state storage, the server encapsulates the file page identifier into a standard synchronization command. To improve the system's concurrent processing capabilities, the server uses a message queue (MQ) for decoupled distribution across multiple nodes. Specifically, the server delivers the synchronization command to the message queue. Each distributed service node, as a consumer of this topic, receives this message. Based on the conference identifier contained in the message, each service node retrieves all long-lived connections belonging to the online participating terminals in this conference from its in-memory connection pool. Finally, the synchronization command is pushed to these participating terminals one by one in an asynchronous, non-blocking manner.

[0052] The synchronized status of the authoritative speech mentioned above has the following uses: 1) As a data source for broadcasting: ensure that all participating terminals receive synchronization information from the same authoritative record.

[0053] 2) Support for new terminal joining: If a user joins the meeting midway through a presentation, their terminal will first request the current authoritative synchronization status of the meeting from the server. The server directly reads this status from the cache and returns it, allowing the new terminal to immediately synchronize to the speaker's current page without waiting for the next page turn, achieving seamless integration.

[0054] 3) Status recovery and auditing: After the presentation terminal is unexpectedly disconnected and reconnected, its status can be restored; at the same time, the status record can also be used to generate presentation playback or attendance reports.

[0055] This embodiment details how the central server implements verification, authoritative state storage, and decoupling using message middleware. Multiple service nodes are pre-deployed to form a cluster, and each node can independently process requests.

[0056] An access and verification layer, a status management service, an asynchronous message distribution layer, and a multi-node consumption and broadcast layer are set up on the central server.

[0057] Access and Authentication Layer: The message containing the file page identifier {file-id, pageNum} reported by the presenting terminal via a long connection is first received by the gateway service. The gateway service performs protocol parsing and first-layer session validity verification to confirm that the connection belongs to a valid and ongoing conference.

[0058] State Management Service: Messages are routed to the state management service. This service executes core business logic: material validity verification and authoritative state storage.

[0059] Asynchronous message distribution layer: After completing storage, the state management service, acting as a producer, delivers a message containing meetingId, file-id, and pageNum to a message middleware (such as RabbitMQ or Kafka). Upon successful delivery, the message is persisted and decoupled from upstream services.

[0060] Multi-node Consumption and Broadcast Layer: This layer consists of synchronous broadcaster components deployed on various service nodes. Each broadcaster, upon receiving a message, parses the meetingId and retrieves the session list of all online terminals for that meeting from the channel manager in its local memory. It iterates through this list, skipping the sourceClientId marked in the message (i.e., the speaking terminal itself), pushes the synchronous command out via the asynchronous write interface, and registers callbacks to handle sending failures. Through this mechanism, one service node handles the reporting request, while all nodes in the cluster can participate in broadcasting, significantly improving the system's horizontal scalability and broadcast throughput.

[0061] This step refines the central server's processing of synchronization commands, verifying and storing the file page identifier as the authoritative synchronization state. This ensures the uniqueness and correctness of the data source, providing accurate status recovery basis for terminals joining midway and achieving seamless integration. The central server first verifies, stores, and returns a response, then broadcasts asynchronously. The presenting terminal does not need to wait for all participating terminals to finish receiving the message to receive confirmation, resulting in extremely low perceived latency and a smooth user experience. Multi-node decoupling and distribution are achieved through a message middleware, with each service node independently consuming messages and executing broadcasts. This allows the system to easily scale horizontally, supporting massive concurrent synchronization of terminals in large-scale conferences.

[0062] In one embodiment, such as Figure 3As shown, step S50 includes: Step S51: The participating terminal parses the file unique identifier and page number parameter in the synchronization instruction, and searches for the file content corresponding to the file page identifier from the local cache based on the file unique identifier.

[0063] In implementation, the terminal first parses the file-id and pageNum from the instruction. Then, using the file-id as the key, it first searches for the corresponding file content in the local cache. For example, the terminal searches its local cache directory to see if a file named FILE-2025-MARKET-PLAN-V3.pdf already exists. If the cache is hit, indicating the file exists, it proceeds directly to the next rendering stage.

[0064] Step S52: If the local cache is not found, the file unique identifier is requested from the file server to obtain the corresponding file as needed.

[0065] In practice, a cache miss indicates that the file does not exist. The terminal immediately initiates an asynchronous task, sending an HTTP request to a dedicated file server based on the file-id to download the PDF file and store it in the local cache. Simultaneously, it records the file's hash checksum for later use. If, during a cache read, the checksum reveals a discrepancy between the local file hash and the hash of the latest version corresponding to that file-id on the server, a cache refresh is triggered, automatically clearing the old file and initiating the download of the new version.

[0066] Step S53: Obtain the file content, accurately locate the target page according to the page number, and combine it with the current split-screen layout parameters to complete local rendering and adapt the display based on the screen area.

[0067] In practice, after obtaining the file content, the local rendering engine of the participating terminal is activated. This engine is independent and self-contained, working only based on the input file path and page number parameters. The engine locates page 6 of the PDF file, parses it into renderable graphic elements, and precisely adapts it according to the current terminal's screen size, resolution, and user-defined split-screen layout (such as displaying the presentation content on the left half and notes on the right half), ultimately rendering a screen consistent with the presentation terminal.

[0068] In split-screen layout adaptation: If user A's terminal is configured with split-screen mode: the left split screen (occupying 60% of the screen width) is used to display the presentation content, and the right split screen (occupying 40%) is used for their personal note-taking application. After receiving the "file ready" notification, the rendering engine obtains the currently active split-screen layout parameter object, which defines the {x, y, width, height} of each screen block. The engine renders page 6 of the PDF to an off-screen canvas, and then, based on the layout parameters {x:0, y:0, width:1080, height:1920} corresponding to the presentation content area, calls the graphics drawing interface to accurately draw the content of this off-screen canvas onto the specified rectangular area of ​​the screen. The entire process requires only one page parsing and one partial screen refresh, which is efficient and completely isolated from the content of the right-side note area.

[0069] A significant advantage of this participating terminal is that file rendering is entirely performed locally, and the data channel synchronized with the presentation is logically decoupled. Therefore, users can simultaneously perform tasks such as searching for information, browsing other files, and taking personal notes in the terminal's sidebar or another independent window. These operations do not occupy the synchronization channel and are completely independent of the main presentation screen, without interfering with each other.

[0070] In one embodiment, the method further includes a pre-storage operation of the file content, comprising: During the meeting preparation phase, pre-download the file content belonging to the currently displayed content in batches based on the list of documents associated with the meeting. If a synchronization command is received during a meeting but the file content has not yet been cached, the participating terminal will retrieve the file content from the file server in real time and write it to the local cache. Each time the local cache is read, the file content is checked for integrity. When the version of the file content changes, an automatic cache refresh is triggered.

[0071] In implementation, related files are pre-downloaded in batches before the meeting begins, virtually eliminating waiting time during the meeting due to file downloads. It's ready to use immediately upon startup, providing a smooth user experience. If a file is missing when a synchronization command is received during the meeting, it can be immediately retrieved from the server and written to the cache, balancing thorough preparation with flexibility in handling dynamic changes. Integrity checks are performed each time the cache is read, and it is automatically refreshed when the version changes, ensuring that the terminal always uses the latest and intact files. This avoids display anomalies caused by corrupted or expired files, improving reliability.

[0072] In one embodiment, before locally rendering and displaying the screen corresponding to the currently displayed content, i.e., step S40, the method further includes: The original file content is pre-converted into a PDF file through a separate file conversion module, and the original file and the PDF file each maintain independent integrity verification information.

[0073] In split-screen mode, each file independently maintains its file identifier, page number, and layout position, and the rendering process of each file is completely decoupled. When the speaker switches between one file, the display of the other files remains unchanged.

[0074] In practice, this embodiment further illustrates how the system achieves rendering decoupling and seamless switching when displaying two different files simultaneously in a split-screen format.

[0075] When the speaker shares their screen, they use a comparison presentation mode, with the left screen displaying the "Market Planning Document" (file-id: FILE-001) and the right screen displaying the "Sales Data Report" (file-id: FILE-002).

[0076] The terminal system creates and maintains separate state objects for these two file blocks. Each state object contains its own {file-id, pageNum} and its bound screen layout position {x, y, w, h}.

[0077] State object A: {file-id: FILE-001, pageNum: 5, layout: leftRegion}, State object B: {file-id: FILE-002, pageNum: 3, layout: rightRegion}. These two state objects are completely decoupled; they are managed separately in memory and have their own independent file cache paths and rendering instances.

[0078] When a speaker performs a page-turning operation, their action explicitly specifies the operation target, such as "turn to page 6 of FILE-001". The synchronization instruction packet broadcast by the central server carries this operation target information. After receiving the instruction, the participating terminal's synchronization module updates the pageNum of state object A, which matches file-id: FILE-001, to 6, and triggers a partial refresh of the left-side rendering area. However, state object B and the right-side rendering area it controls are completely unaffected by this instruction; their internal state and screen display remain unchanged.

[0079] If the speaker decides to close FILE-002 and open a new "Competitive Analysis Report" (file-id: FILE-003) to display on the right screen, the system will generate and broadcast a "file switching + positioning" command for the right screen area. Upon receiving this command, the participating terminal will only destroy state object B, create a new state object C, and independently execute the cache lookup / download and homepage rendering process for FILE-003 on the right screen area. Throughout this process, the display of FILE-001 on the left will not experience any flickering, stuttering, or state loss, truly achieving complete decoupling of multi-file rendering in split-screen mode.

[0080] In one embodiment, it further includes a separately configured rendering module and a synchronization module, specifically: The presentation terminal and the participating terminal are equipped with a rendering module for rendering executable files, and a synchronization module for synchronizing the presentation. The rendering module relies solely on file path and page number parameters to complete the local rendering of the page, while the synchronization module is responsible for receiving synchronization instructions pushed through the long-connection communication channel. The rendering module and the synchronization module exchange data through a shared file page identifier, and are independent of each other in terms of execution logic; In the event of a brief interruption of the long-connection communication channel, the rendering modules that are already in place will maintain the normal display of the current page.

[0081] In implementation, the rendering module and the synchronization module are logically independent through architectural design, so that even if the synchronization channel is briefly interrupted, the rendered content will not be affected.

[0082] The system strictly separates the terminal's synchronization and display functions into two independent modules at the software level: The synchronization module runs as an independent background service, and its sole responsibility is to manage the long-lived connection with the central server and listen for and parse synchronization commands.

[0083] The rendering module, as an independent UI component, does not interact directly with the network. It only subscribes to changes in state synchronization variables. When the value of the state synchronization variables is updated, the rendering module is awakened and automatically uses the new parameters to drive the file loading and page rendering process.

[0084] When a user's network experiences fluctuations, causing a brief interruption of the persistent connection, the synchronization module enters a "disconnected" state, unable to receive new instructions, and the state synchronization variable remains at the value of the last successfully received instruction. However, the rendering module itself is completely unaware of this interruption; it does not report errors or freeze due to the synchronization module's disconnection. It continues to maintain the normal display of the current page on the screen, allowing users to smoothly scroll and zoom the currently cached page or perform offline operations in other independent interface modules. Only after the network is restored, the synchronization module reconnects, and receives the latest instructions will the state synchronization variable be updated, and the rendering module will smoothly transition to the latest page. This design greatly enhances the system's robustness and user experience.

[0085] In addition to the synchronized display method described above, when rendering and displaying the screen corresponding to the currently displayed content locally, an annotation synchronized display operation is also performed, namely step S60, which includes: Step S61: Overlay an independent transparent annotation canvas layer onto the screen displayed on the participating terminal.

[0086] Step S62: Listen for pointer events on the transparent annotation canvas layer, capture user annotation operations, and generate annotation data messages. The annotation data messages include annotation identifier, file identifier, page number, drawing type, color, line width, coordinate trajectory, timestamp, and operator identifier.

[0087] Step S63: Send the annotation data message to the central server through the real-time data channel.

[0088] In step S64, the central server broadcasts the annotation data message to other online participating terminals in the current meeting.

[0089] In step S65, other online participating terminals receive and parse the annotation data message, and render the annotation trajectory in the same style at the same coordinate position on the corresponding page of the corresponding file, so as to realize the real-time synchronous display of the annotation.

[0090] In practice, this embodiment provides a detailed description of the complete process of annotation synchronization.

[0091] Step 1: Annotation Operation Capture and Graphical Object Generation The system overlays a fully transparent HTML5 Canvas element above all PDF pages rendered on all terminals, serving as the annotation canvas. All annotation operations are performed on this canvas. When a user executes an annotation event on the canvas, the system records the (x, y) coordinates of the pen's point, which are pixel coordinates relative to the current PDF page rendering area. During the continuous triggering of the annotation event, the system collects coordinate points according to the browser's native pointer event sampling frequency (typically around 60 Hz) and appends them to the coordinate point sequence array. Simultaneously, to improve the smoothness of real-time rendering, algorithms such as Bézier curves are used to smooth these discrete points, and smooth strokes are drawn instantly on the local annotation canvas.

[0092] Step 2: Serialization and dual transmission of annotation data. After identifying the annotation object, it is serialized and converted into a preset, device-resolution-independent standardized data structure.

[0093] Step 3: After receiving the annotation message from the real-time channel, the central server executes a decoupled broadcast mechanism similar to that used for presentation synchronization, pushing it to all other online participating terminals in the conference. Upon receiving the annotation message, the receiving terminal performs a reverse parsing process. Based on the actual rendering area size of its own screen, it recalculates the normalized coordinate point sequence in the message into actual pixel coordinates. Then, it draws the exact same annotation trajectory on its local annotation canvas. Because the entire process is based on the same coordinate reference system and data structure, precise synchronization of annotations across all terminals is ensured.

[0094] Building upon the synchronous presentation, a synchronized annotation display function has been added. This function captures the drawing process through a separate transparent annotation canvas layer and broadcasts it in real time. All online participating terminals can simultaneously see the annotation drawing process, achieving a remote collaboration experience similar to "pointing on the same piece of paper." The annotation data message contains complete information such as drawing type, color, line width, and coordinate trajectory. The receiving end can render it in the corresponding position with the same style, ensuring visual consistency and accuracy of information transmission.

[0095] In one embodiment, the detailed implementation process of step S62 is as follows: Step 1: When the pointer is pressed, record the absolute coordinates of the pen stroke and create the corresponding graphic object. Generate basic graphic elements of the corresponding type according to the currently selected drawing tool type, and assign a unique client identifier to each graphic element.

[0096] Step 2: During pointer movement, update the geometric parameters of graphic elements in real time; for brush tools, continuously accumulate the path coordinate point sequence according to the preset sampling frequency; for shape tools, fully respond to each movement event, dynamically adjust the graphic size and render it in real time.

[0097] Step 3: After the pointer lift event is triggered, incremental recognition is performed on the graphical objects generated within a complete operation cycle. The newly added annotation is determined by comparing the client's unique identifier with the persisted data.

[0098] Step 4: Serialize the new annotation into a preset data structure. The data structure includes the geometric parameters of the annotation area under the basic scaling reference, the drawing type identifier, the line width and color attributes. The trajectory of the brush tool is encapsulated in the form of an array of coordinate points.

[0099] Step 5: Transmit the encapsulated annotation data message through both the persistent interface and the real-time broadcast channel.

[0100] Step 6: Other online participating terminals reverse-parse the annotation data messages and restore them into renderable graphic description data based on the same coordinate reference system.

[0101] This embodiment further refines the process of generating annotation data messages, and has the following outstanding technical effects: Incremental identification with minimal data transfer: By assigning a unique client identifier to each graphical object and comparing it with the persisted data upon lifting, only new annotations are reported, avoiding duplicate transmissions and significantly saving network bandwidth and server processing overhead.

[0102] High-precision trajectory acquisition: Paint tools accumulate coordinate point sequences according to a preset sampling frequency (such as about 60 Hz), and shape tools fully respond to movement events, which not only ensures the smoothness of free-drawn trajectories, but also realizes real-time feedback of shape drawing, thus balancing accuracy and performance.

[0103] Cross-terminal normalized display: The coordinate serialization based on the basic scaling reference makes the annotation data independent of the specific device resolution. The receiving terminal reverse-parses according to the same reference, ensuring that the annotation position and scale are completely consistent on screens of different sizes and resolutions.

[0104] Dual transmission guarantee: Annotation messages are transmitted simultaneously through a persistent interface and a real-time broadcast channel, which not only meets the immediacy requirements of real-time synchronization, but also ensures that the data is reliably written to disk. Even if the real-time channel experiences a brief failure, the annotations will not be lost and can still be fully replayed afterward.

[0105] In summary, the presentation synchronization method based on file page identifiers provided in this application fundamentally overcomes the limitations of traditional screen sharing by transforming presentation synchronization from video streaming to data transmission based on file page identifiers. Addressing the issue of coupling between content sharing and terminal operation, the presenting terminal only captures the file ID and page number to generate a lightweight identifier and sends it. Participating terminals, upon receiving this identifier, autonomously retrieve the file from their local machine or server and render it independently, no longer passively receiving video feeds. This frees up the screen, supporting parallel independent operations such as note-taking and browsing, achieving decoupling. Addressing the lack of page-level synchronization control, the identifier precisely locates the displayed content at the file object and page number granularity. The central server encapsulates this into a synchronization command and stores it as an authoritative state. All terminals synchronize precisely based on this, and newly joined terminals can obtain this state at any time to actively follow without waiting for the next page turn, establishing a fine-grained synchronization mechanism at the file page level. This invention ensures the original image quality under extremely low bandwidth, endows terminals with multitasking capabilities, and significantly improves the real-time performance, flexibility, and interactive efficiency of meetings.

[0106] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0107] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A presentation synchronization method based on file page identifiers, applied to a conference system in which a central server and terminals collaborate, wherein the terminals include a presenting terminal and at least one participating terminal, characterized in that, After activating the speech mode, the following is included: The presentation terminal captures the file page identifier of the currently displayed content and sends the file page identifier to the central server through a long-connection communication channel; The central server encapsulates the received file page identifier into a synchronization instruction, uses the synchronization instruction as the authoritative synchronization status of the current presentation, and broadcasts the synchronization instruction to the participating terminals through the long connection communication channel; The participating terminal extracts the file page identifier from the synchronization instruction, obtains the corresponding file content from the local cache or file server based on the file page identifier, and renders and displays the screen corresponding to the currently displayed content locally; The file page identifier includes at least a unique file identifier and page number information.

2. The presentation synchronization method based on file page identifiers according to claim 1, characterized in that, The presentation terminal captures the file page identifier of the currently displayed content and sends the file page identifier to the central server via a long-connection communication channel, including: The presentation terminal monitors the speaker's actions on the currently displayed content, captures the currently displayed content based on the actions, and generates the file page identifier. The file page identifier is reported to the central server through the long-connection communication channel.

3. The presentation synchronization method based on file page identifiers according to claim 1, characterized in that, The central server encapsulates the received file page identifier into a synchronization instruction, uses the synchronization instruction as the authoritative synchronization status of the current presentation, and broadcasts the synchronization instruction to participating terminals through the long-connection communication channel, including: The central server encapsulates the received file page identifier into a synchronization instruction, verifies the file page identifier, and stores it as the authoritative synchronization status of the current presentation. The central server locates the participating terminals based on the conference identifier, performs multi-node decoupling and distribution through message middleware, and pushes the synchronization command to the participating terminals.

4. The presentation synchronization method based on file page identifiers according to claim 1, characterized in that, The participating terminal extracts the file page identifier from the synchronization instruction, retrieves the corresponding file content from the local cache or file server based on the file page identifier, and renders and displays the screen corresponding to the currently displayed content locally, including: The participating terminal parses the file unique identifier and the page number parameter in the synchronization instruction, and searches for the file content corresponding to the file page identifier from the local cache according to the file unique identifier; If the local cache is not found, the file unique identifier is used to request the corresponding file from the file server as needed; Once the file content is obtained, the target page is accurately located based on the page number, and the local rendering is completed in conjunction with the current split-screen layout parameters, and the display is adapted based on the screen area.

5. The presentation synchronization method based on file page identifiers according to claim 4, characterized in that, It also includes a pre-storage operation of the file content, including: During the meeting preparation phase, the file content to which the currently displayed content belongs is pre-downloaded in batches according to the list of files associated with the meeting; If the synchronization instruction is received during the meeting but the file content has not yet been cached, the participating terminal retrieves the file content from the file server in real time and writes it to the local cache. Each time the local cache is read, the integrity of the file content is checked, and an automatic cache refresh is triggered when the version of the file content changes.

6. The presentation synchronization method based on file page identifiers according to claim 1, characterized in that, Before the local rendering displays the screen corresponding to the currently displayed content, the following steps are also included: The original file containing the document is pre-converted into a PDF file using a separate file conversion module. The original file and the PDF file each maintain independent integrity verification information.

7. The presentation synchronization method based on file page identifiers according to claim 6, characterized in that, The original file and the PDF file each maintain independent integrity verification information, including: In split-screen mode, each file independently maintains its file identifier, page number, and layout position, and the rendering process of each file is completely decoupled. When the speaker switches between one of the files, the display of the other files remains unchanged.

8. The presentation synchronization method based on file page identifiers according to claim 1, characterized in that, Also includes: The presentation terminal and the participating terminal are equipped with a rendering module for rendering execution files, and a synchronization module for synchronizing the presentation: The rendering module relies solely on file path and page number parameters to complete the local rendering of the page, while the synchronization module is responsible for receiving the synchronization instructions pushed by the long connection communication channel. The rendering module and the synchronization module transmit data through the shared file page identifier, and are independent of each other in terms of operation logic; In the event of a brief interruption of the long-connection communication channel, the rendering module that is ready will maintain the normal display of the current page.

9. The presentation synchronization method based on file page identifiers according to any one of claims 1 to 8, characterized in that, When the local rendering displays the screen corresponding to the currently displayed content, an annotation synchronization display operation is also performed, including: An independent transparent annotation canvas layer is superimposed on the screen displayed on the participating terminal; Listen for pointer events on the transparent annotation canvas layer, capture user annotation operations, and generate annotation data messages; the annotation data messages include annotation identifier, file identifier, page number, drawing type, color, line width, coordinate trajectory, timestamp, and operator identifier; The annotation data message is sent to the central server through a real-time data channel; The central server broadcasts the annotation data message to other online participating terminals in the current meeting; The other online participating terminals receive and parse the annotation data message, and render the annotation trajectory in the same style at the same coordinate position on the corresponding page of the corresponding file, so as to realize the real-time synchronous display of the annotation.

10. The presentation synchronization method based on file page identifiers according to claim 9, characterized in that, The process of listening to pointer events on the transparent annotation canvas layer, capturing user annotation operations, and generating annotation data messages includes: When the pointer is pressed, the absolute coordinates of the pen stroke are recorded and a corresponding graphic object is created. Based on the currently selected drawing tool type, basic graphic elements of the corresponding type are generated, and a unique client identifier is assigned to each graphic element. During the pointer movement, the geometric parameters of the graphic element are updated in real time; for brush tools, the path coordinate point sequence is continuously accumulated according to a preset sampling frequency; for shape tools, each movement event is fully responded to, the graphic size is dynamically adjusted and rendered in real time. After the pointer lift event is triggered, incremental recognition is performed on the graphical objects generated within a complete operation cycle, and new annotations are determined by comparing the client's unique identifier with the persisted data. The newly added annotation is serialized into a preset data structure, which includes the geometric parameters of the annotation area under the basic scaling reference, the drawing type identifier, the line width and color attributes, wherein the trajectory of the brush tool is encapsulated in the form of an array of coordinate points. The encapsulated annotation data message is transmitted through both a persistent interface and a real-time broadcast channel. The other online participating terminals reverse-parse the annotation data message and restore it into renderable graphic description data based on the same coordinate reference system.

Images