Shared data processing method and system

Abstract

The invention provides a shared data processing method and system. The method is applied to a shared data processing system, the shared data processing system comprises a device side and a user side, and the device side comprises an scrcpy process; the method comprises the following steps: an scrcpy process sends code stream information to a user side based on acquired instruction information; wherein the code stream information is used for indicating a shared page displayed by the equipment side; in the embodiment of the invention, the user side processes the code stream information to generate the page display information, and displays the shared page corresponding to the page display information through the browser, so that the page sharing efficiency can be improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method and system for processing shared data. Background Technology

[0002] In related technologies, a sharing application needs to be downloaded on both the user's mobile phone and computer before the page can be shared from the user's mobile phone to the computer, resulting in low page sharing efficiency. Summary of the Invention

[0003] This application provides a method and system for processing shared data, which can improve the efficiency of page sharing.

[0004] The technical solution of this application embodiment is implemented as follows:

[0005] This application provides a method for processing shared data, which is applied to a shared data processing system. The shared data processing system includes a device end and a user end, and the device end includes a scrcpy process. The method includes:

[0006] The scrcpy process sends bitstream information to the user terminal based on the acquired instruction information; wherein, the bitstream information is used to indicate the shared page displayed on the device terminal;

[0007] The user terminal processes the bitstream information, generates page display information, and displays the shared page corresponding to the page display information through a browser.

[0008] This application provides a shared data processing system. The system includes a device end and a user end, and the device end includes a scrcpy process.

[0009] The scrcpy process is used to send bitstream information to the user terminal based on the acquired instruction information; wherein the bitstream information is used to indicate the shared page displayed on the device terminal.

[0010] The user terminal is used to process the bitstream information, generate page display information, and display the shared page corresponding to the page display information through a browser.

[0011] In some embodiments, the system further includes a server;

[0012] The scrcpy process is used to send bitstream information to the server.

[0013] The server is used to forward the bitstream information to the user terminal.

[0014] In some embodiments, when the server establishes a long connection with the user, it controls the device to start the scrcpy process and sends the instruction information to the scrcpy process; wherein, the instruction information is used to instruct at least one of the following: the scrcpy process runs in background mode, encodes the shared page, or sends the bitstream information to the user.

[0015] The scrcpy process is used to generate page sharing information based on the shared page; and to encode the page sharing information based on the instruction information to generate bitstream information.

[0016] In some embodiments, the user terminal is configured to send a connection request to the server in response to a connection event;

[0017] The server is configured to respond to the connection request by sending a connection response to the user terminal and determining to establish the long connection with the user terminal; wherein the long connection includes a WebSocket communication connection, a WSS communication connection, or a QUIC communication connection.

[0018] In some embodiments, the client is used to run a browser, the browser including at least one tab; the client includes an event listener, a browser main thread, and a processing thread;

[0019] The event listener is used to listen for the bitstream information sent by the server and send the bitstream information to the processing thread.

[0020] The user terminal is used to process the bitstream information, generate page display information, and display the page corresponding to the page display information through a browser, including:

[0021] The processing thread is used to process the bitstream information and generate page display information; and to send the page display information to the browser main thread through a cross-origin communication method.

[0022] The browser's main thread is used to add the page display information to the display canvas when the current tab includes a shared tab; wherein the shared tab is used to indicate that the shared page on the device should be displayed.

[0023] In some embodiments, the processing thread, upon triggering a pause event, performs at least one of the following:

[0024] Stop generating page display information;

[0025] Stop sending the page display information to the browser's main thread;

[0026] Send a stop forwarding message to the server; the server, in response to the stop forwarding message, stops forwarding the bitstream information to the user terminal.

[0027] In some embodiments, the processing thread is configured to trigger the pause event when the current tab does not include the shared tab; and to trigger the pause event when the first duration is greater than or equal to a first duration threshold; wherein the first duration is the duration during which the current tab does not include the shared tab;

[0028] The browser's main thread is configured to send a tab pause message to the processing thread in response to a pause operation on the shared tab; the processing thread is configured to trigger the pause event in response to the tab pause message.

[0029] In some embodiments, the user terminal and the server establish a long-lived connection;

[0030] The processing thread is used to disconnect the long connection established between the user and the server in response to a close event.

[0031] The server is configured to control the device to shut down the scrcpy process in response to the disconnection of the long connection established with the user.

[0032] In some embodiments, the processing thread is configured to trigger the close event if a first duration is greater than or equal to a second duration threshold; wherein the first duration is the duration of the current tab excluding the shared tab;

[0033] The browser's main thread is used to send a tab close message to the processing thread in response to the closing operation of the shared tab; the processing thread is used to trigger the close event in response to the tab close message.

[0034] The technical solutions provided by the embodiments of this application may include the following beneficial effects:

[0035] The bitstream information is obtained by encoding the shared interface on the device side. The scrcpy process can continuously send bitstream information to the user end in real time. The user end decodes the bitstream information and renders the decoded page display information, so that the rendered image can be displayed through the browser, that is, the shared interface is displayed through the browser. Thus, the user end does not need to install clients, software, plugins, applications, etc. to decode the received bitstream information and then display the shared interface through the browser, making page sharing convenient and cross-platform, with the characteristics of "zero client", improving the efficiency of page sharing. Moreover, the above method is simple to implement, has high real-time performance, and the technical solution is common, with the characteristics of being lightweight and easy to deploy. Furthermore, the user end has high integration, and it is very easy to design a functional module to process the bitstream information and display the corresponding shared page through the browser. This functional module can be seamlessly integrated into the corresponding module of the current web application.

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

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

[0038] Figure 1 This is a flowchart illustrating a method for processing shared data according to an exemplary embodiment.

[0039] Figure 2 This is a schematic diagram illustrating an interaction according to an exemplary embodiment.

[0040] Figure 3 This is a schematic diagram illustrating the structure of a shared data processing system according to an exemplary embodiment. Detailed Implementation

[0041] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0042] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0043] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0044] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0045] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0046] 1) Mobile devices: refers to portable computing devices such as smartphones and tablets. In this article, it specifically refers to devices running the Android or iOS operating system.

[0047] 2) scrcpy: An open-source application that can display the screen content of an Android device on a desktop computer via USB or TCP / IP connection and provide remote control functionality.

[0048] 3) WebSocket: A computer network protocol that enables full-duplex communication over a single TCP connection, allowing low-latency, high-efficiency bidirectional data transmission between servers and clients (such as web browsers).

[0049] 4) H.264: Also known as Advanced Video Coding (AVC), it is a widely used video compression standard that can provide high-quality video at lower bit rates.

[0050] 5) Node.js: A JavaScript runtime environment based on the Chrome V8 engine, used to easily build fast, scalable web applications.

[0051] 6) CanvasAPI: An HTML5 application programming interface (API) that allows dynamic drawing of graphics, animations and other visual content on web pages using JavaScript.

[0052] 7) JavaScript decoder: refers to a video decoding library implemented entirely in JavaScript in the client browser, such as Broadway.js or TinyH264, which can decode H.264 video streams into renderable image frames without native browser support or external plugins.

[0053] 8) Android Debug Bridge (ADB): A versatile command-line tool used for communicating with and debugging Android devices.

[0054] In one related technology, a native desktop screen mirroring application is an application currently installed on the sharing device used to share a page. For example, in the standard usage of the open-source project scrcpy, the user downloads and runs the scrcpy client program on a personal computer (operating system Windows, macOS, or Linux); this program establishes a connection with an Android device (such as a mobile phone) via ADB; the sharing device includes an Android device, on which a server program runs, responsible for capturing screen content and encoding it into an H.264 video stream; the Android device transmits the H.264 video stream back to the personal computer via the ADB channel, where the scrcpy client program decodes it using libraries such as FFmpeg and renders it in a native desktop window using Simple Direct Media Layer (SDL).

[0055] However, the above-mentioned technologies have the following problems: 1) Dependence on specific clients: Users must first install the scrcpy client program and its dependent environment (such as ADB) on their personal computers, which has a high operating threshold; and a server program also needs to be installed on the Android device to achieve screen sharing, which does not have the convenience of "out-of-the-box use".

[0056] Weak cross-platform capability: It cannot run directly in common environments such as web browsers, which limits its integration and use in B / S architecture applications, making it impossible for users to access the device screen through a simple web page link;

[0057] Inconvenient distribution and sharing: To achieve screen sharing, the other party's device also needs to complete the same complex environment configuration, which is not suitable for quick, temporary remote collaboration or demonstration scenarios.

[0058] In another related technology, commercial cloud testing platforms or mobile device platforms maintain a large number of real mobile devices in their data centers and provide them to remote users via web pages. Users can view the devices' live screens in a browser.

[0059] However, the technical solutions of these platforms are usually proprietary and generally involve transcoding the video stream on the server side (e.g., transcoding from H.264 to MJPEG or other web-friendly formats) or using specific streaming media protocols (such as WebRTC) for transmission; that is, the solutions are cumbersome and expensive: such solutions are part of large commercial services, have complex system architectures, usually require paid subscriptions, and are not suitable for individual developers or small teams that need lightweight, privately deployable solutions.

[0060] It may introduce additional latency: The video transcoding process on the server side consumes computing resources and inevitably introduces additional video processing latency, affecting the smoothness of real-time operation;

[0061] Lack of technical transparency: Its underlying implementation is a technical black box, making it impossible for users to customize or optimize it, and difficult to integrate it into their own business systems.

[0062] This disclosure provides a method and system for processing shared data. The system allows the scrcpy process on the device to process the shared page in real time, generating and outputting bitstream information. The user terminal processes the bitstream information, generating and displaying page information. This means the user terminal does not need to install applications or configure an environment. Through interaction between the device and user terminal, the page displayed on the device is shared to the user terminal. This B / S architecture improves the convenience of screen sharing and enhances cross-platform capabilities, achieving "click and use." Furthermore, the solution is simple, the technologies are transparent, and it is suitable for lightweight environments.

[0063] The following describes a method and system for processing shared data.

[0064] Figure 1 This is a flowchart illustrating a shared data processing method according to an exemplary embodiment. The method is applied to a shared data processing system, which includes a device and a user. The device includes a scrcpy process. The method includes:

[0065] Step 101: The scrcpy process sends stream information to the user terminal based on the acquired instruction information; the stream information is used to indicate the shared page displayed on the device.

[0066] In this embodiment of the disclosure, the user end includes, but is not limited to, mobile phones, tablets, desktop computers, laptops, wearable devices, etc., and the user end includes a display; the device end includes, but is not limited to, mobile phones, tablets, desktop computers, laptops, wearable devices, projection devices, etc., and the device end includes a display.

[0067] The instruction information includes at least one of the following: a window startup prohibition command, bitrate, resolution, video codec standard, and user device identifier. The window startup prohibition command instructs the device not to launch an additional window. Video codec standards include video encoding standards, which are technical specifications for compressing and reconstructing video data using mathematical algorithms to reduce data transmission while maintaining visual quality. Examples of video encoding standards include, but are not limited to, H.264, H.265, and H.266. Bitrate represents the amount of data transmitted per unit of time; for example, bitrates include 8 Mbps. Resolution is a key parameter describing image sharpness and can include the maximum video resolution, such as 360P, 720P, and 1080P. The user device identifier refers to the identifier of the device viewing the shared page; for example, the user device identifier includes the user's serial number.

[0068] The page displayed on the device can be the entire page on the device or a specific page on the device. For example, the screen size of the device may include, but is not limited to, 11.7 cm * 6.5 cm, 12.7 cm * 7.1 cm, etc. Assuming that the screen size of the device is 11.7 cm * 6.5 cm, the size of the shared page indicated by the bitstream information is less than or equal to 11.7 cm * 6.5 cm.

[0069] Bitstream information can refer to the bitstream obtained after processing a shared page on a device. For example, a shared page on a device can be treated as an image and encoded using a video codec standard to obtain a bitstream that conforms to the video codec standard.

[0070] For example, if the video encoding standard is H.264, the scrcpy process can use the H.264 video encoding standard to encode the shared page on the device as an image, obtaining H.264 data blocks. That is, the bitstream information refers to the raw stream obtained after encoding the shared page through the video encoding standard. The bitstream information includes H.264 data blocks. Thus, the scrcpy process can continuously encode the shared page on the device and output the encoded bitstream information to the user terminal. The scrcpy process can transmit the bitstream information through the server.

[0071] Step 103: The user terminal processes the bitstream information, generates page display information, and displays the shared page corresponding to the page display information through the browser.

[0072] In this embodiment, the user terminal processes the bitstream information, which may include: decoding the bitstream information, generating page display information, and then displaying the shared page indicated by the page display information. The user terminal does not need to install any sharing applications, mini-programs, plugins, etc., for viewing the shared page; it can view the shared page on the device through a browser.

[0073] The user client can run a browser, and the page display information conforms to the browser's image or video playback format. For example, the browser supports video formats including but not limited to MP4, AVI, MOV, etc. The user client can process the bitstream information in real time, thereby decoding the page display information of multiple images, and displaying multiple images as video frames in the form of video on the device. The resulting multiple page display information conforms to the video format supported by the browser, and thus the shared page on the device can be displayed through the browser.

[0074] This disclosure provides a method for processing shared data. The bitstream information is information obtained by encoding the shared interface on the device side. The scrcpy process can continuously send the bitstream information to the user terminal in real time. The user terminal decodes the bitstream information and renders the decoded page display information so that the rendered image can be displayed through a browser, that is, the shared interface is displayed through a browser. Thus, the user terminal does not need to install clients, software, plugins, applications, etc. to decode the received bitstream information and then display the shared interface through a browser, making page sharing convenient and cross-platform, with the characteristics of "zero client", improving the efficiency of page sharing. Moreover, the above method is simple to implement, has high real-time performance, and the technical solution is common. It is lightweight and easy to deploy. Furthermore, the user terminal has high integration, and a functional module can be easily designed to implement the above step 103. This functional module can be seamlessly integrated into the corresponding module of the current web application.

[0075] In some embodiments, step 101 includes steps 1011 to 1012, wherein:

[0076] Step 1011: The scrcpy process sends the bitstream information to the server.

[0077] Step 1012: The server forwards the bitstream information to the user.

[0078] In this embodiment of the disclosure, the server includes, but is not limited to, a server, a desktop computer, a laptop computer, etc.; the server, the device, and the user are all connected; the server is used to forward the bitstream information and does not need to decode the bitstream information, thereby reducing the power consumption of the server; and the server is used to output the bitstream information, rather than outputting the decoded bitstream information, thereby reducing the amount of data output.

[0079] In some embodiments, before step 101, the server sends instruction information to the scrcpy process, which then processes the shared page; the method further includes steps 1001 to 1003, wherein:

[0080] Step 1001: When the server establishes a long connection with the user, the control device starts the scrcpy process and sends instruction information to the scrcpy process; wherein, the instruction information is used to instruct at least one of the following: to run in background mode, to encode the shared page, or to send it to the user.

[0081] In this embodiment of the disclosure, the server can establish a long connection with the user. A long connection means that the user and the server establish a connection once and transmit data through this long connection, thereby eliminating the need to establish a connection or send a request before each data transmission, thus reducing the number of times a connection is established or a request is sent.

[0082] After establishing a long connection with the user, the server can determine that the user's purpose is to view the page currently displayed on the device, and then control the device to start the scrcpy process without having to install or start any application or program for screen sharing. This reduces the complexity of setting up the environment and makes screen sharing simpler.

[0083] After establishing a persistent connection with a new client, the server can recognize it as a new streaming session. The server can then invoke a process management module, which will control the device to start a scrcpy process as a child process. For example, the server and device can establish an ADB connection, and the server can send ADB commands to control the device to enable developer options and start the scrcpy process. Alternatively, the user can manually start the scrcpy process on the device, and the server can wake up the scrcpy process via ADB commands after establishing a persistent connection with the client.

[0084] For example, the server includes a process management module, which is a process runner (ProcessRunner.ts) used to manage and run external processes. ProcessRunner.ts starts a native scrcpy process as a child process. After the scrcpy process starts, the server sends instruction information to the scrcpy process, and the scrcpy process can respond to the instruction information and execute step 101 above. The instruction information may include at least one of the following: no-display, bit-rate, max-size, and serial.<device_id> .

[0085] `no-display` disables the `scrcpy` process from launching its built-in SDL display window. This means that the `scrcpy` process typically starts with its own SDL display window; `no-display` prevents the SDL display window from being displayed in the foreground while the `scrcpy` process runs in the background. `bit-rate` specifies the video stream bitrate, which is the rate at which the bitstream information is transmitted to the server as a video stream. `max-size` specifies the upper limit of the video resolution; `bit-rate` and `max-size` determine the upper limit of the bitrate and video resolution for encoding the shared page.<device_id> This indicates the serial number of the user device, i.e., via serial number.<device_id> It can be used as an identifier for the user terminal to receive bitstream information, and can prevent the bitstream information from being sent incorrectly.

[0086] Step 1002: The scrcpy process generates page sharing information based on the shared page.

[0087] In this embodiment of the disclosure, the scrcpy process can treat the shared page as a shared image frame and obtain page sharing information based on each pixel in the shared image. That is, the page sharing information is a pixel matrix composed of each pixel in the shared page.

[0088] Page sharing information and page display information can be the same or different. For example, when performing lossless processing on a shared page, the page sharing information and page display information can be the same. Lossy processing includes, but is not limited to, at least one of the following: resolution adjustment, lossy compression configuration, color space conversion, frame cropping / filling, filtering, etc.

[0089] Alternatively, the shared image can be preprocessed, and the page sharing information can be obtained from the individual pixels in the preprocessed shared image. That is, the page sharing information is obtained after preprocessing the shared page, and the preprocessing includes, but is not limited to, at least one of the following: color space conversion and resolution adjustment. For example, if the resolution of the shared page is 1080P, but the resolution included in the instruction information is 720P, then the pixel matrix corresponding to the shared image needs to be scaled, and the scaled pixel matrix is ​​the page sharing information.

[0090] Step 1003: The scrcpy process encodes the page-shared information based on the instruction information to generate the bitstream information.

[0091] In this embodiment, the scrcpy process runs in the backend and encodes the shared page information to generate a bitstream, thereby reducing the amount of data transmitted. Encoding the shared page information includes at least one of the following: preprocessing the shared page information, pixel-level encoding of the shared page information, and encapsulation of the encoded data. Pixel-level encoding includes, but is not limited to, intra-frame prediction, inter-frame prediction, Discrete Cosine Transform (DCT), quantization, and entropy coding.

[0092] Alternatively, in some embodiments, the scrcpy process can also obtain the initial information of the shared page, and then process the initial information based on the instruction information to obtain the bitstream information. The initial information refers to the initial bitstream of the shared page. For example, the entire page on the device is used as the shared page. The device runs a video application and obtains the initial information from the video application server. Then, a process on the device is used to decode the initial information and display the decoded video. The scrcpy process adjusts the bitrate and resolution of the initial information through the instruction information and uses the adjusted initial information as the bitstream information, thereby reducing the power consumption of the scrcpy process.

[0093] In some embodiments, prior to step 1001, the server and the client establish a long-lived connection. The method further includes steps 201 to 202, wherein:

[0094] Step 201: In response to the connection event, the client sends a connection request to the server.

[0095] Step 202: In response to the connection request, the server sends a connection response to the client and establishes a long connection with the client; the long connection includes a WebSocket communication connection, a WSS communication connection, or a QUIC communication connection.

[0096] In this embodiment of the disclosure, the user terminal can receive a shared link, which is used to display a shared page from the device on the user terminal. The user can click the shared link, and the user terminal can respond to the user's click by launching a browser and sending a connection request to the server through the browser. Alternatively, the user can manually open the browser and manually enter the shared link into the browser.

[0097] To avoid the client and server sending requests to each other before each data transmission, a long-lived connection is established between the server and the client. This allows the client and server to send data to each other proactively at any time without repeated requests.

[0098] WebSocket communication refers to establishing a WebSocket connection on top of an existing TCP connection between the user and server. While TCP provides reliable data transmission, WebSocket defines how data is transmitted. WSS, or WebSocket Secure, adds an encryption layer to WebSocket, thus improving data transmission security. QUIC (Quick UDP Internet Connections) is based on the User Datagram Protocol (UDP) and supports full-duplex transmission, providing reliable UDP transmission and full-duplex communication.

[0099] After a long connection is established between the user and the server, the server can use the established long connection as a data transmission channel to continuously send bitstream information to the user.

[0100] Similarly, the server and the device will also establish a persistent connection. This persistent connection includes, but is not limited to, WebSocket, WSS, or QUIC communication connections. The device can then continuously send stream information to the server through this persistent connection. The connection request can also include the device's identifier, allowing the server to respond to the device identifier included in the connection request and establish a connection with the device indicated by that identifier.

[0101] In some embodiments, the client is used to run a browser, which includes at least one tab; the client includes an event listener, a browser main thread, and a processing thread.

[0102] The method also includes: an event listener listens for the bitstream information sent by the server and sends the bitstream information to the processing thread.

[0103] In this embodiment of the disclosure, the event listener includes an onmessage event listener. For example, the client may run JavaScript code that specifies that the onmessage event listener of the WebSocket object can receive binary data from the server.

[0104] Step 103 includes steps 1031 to 1033, wherein:

[0105] Step 1031: The processing thread processes the bitstream information and generates page display information;

[0106] Step 1032: The processing thread sends the page display information to the browser's main thread via cross-origin communication.

[0107] Step 1033: If the current tab includes a shared tab, the browser's main thread adds the page display information to the display canvas; wherein, the shared tab is used to indicate that the shared page on the device should be displayed.

[0108] In this embodiment of the disclosure, the user terminal can run any type of browser. For example, some browsers can only open one tab, while some browsers can support opening multiple tabs, and multiple tabs can be in the same window or different windows according to the user's needs.

[0109] A browser can open at least one tab. The browser corresponds to the main browser thread, which performs operations related to browser display. For example, the main browser thread controls the display of content related to the user-selected tab; when the user selects a shared tab, the shared page on the device is displayed.

[0110] A decoder runs on the processing thread. The decoder can decode the bitstream information and generate page display information. For example, the bitstream information includes H.264 data blocks. The decoder decodes each H.264 data block to obtain the page display information. Thus, the server does not process the bitstream information. Through the "pass-through" forwarding mechanism, the user end decodes the bitstream information, which can minimize the processing overhead and latency on the server side. In addition, in order not to affect the browser's main thread, an additional processing thread for decoding the bitstream information is added, which speeds up the display of shared pages.

[0111] Cross-origin communication methods include the `postMessage` method, which is a secure mechanism for enabling cross-origin communication between different window objects. Since the browser's main thread and processing thread share the same origin—the processing thread decodes the bitstream information, while the browser's main thread controls the display to show the decoded page information—the two threads can transmit page display information via the `postMessage` method.

[0112] When the current tab includes a shared tab, the shared tab may be in a non-minimized state, or the shared tab may be in a triggered state, or the page displayed on the user's device may include a shared tab.

[0113] For example, if a browser is running on a user's device, and the first tab of the browser is a shared tab and the second tab is a game tab, when the corresponding page of the browser is not minimized, even if the user is interacting with the game tab, it is considered that the current tab includes the shared tab; the shared tab being in a triggered state indicates that the user is interacting with the shared tab, or that the user's last interaction on the user's device was on the shared tab.

[0114] Alternatively, when multiple browsers are running on the user's client, the first browser includes a shared tab, the second browser includes a game tab, and the user's displayed page includes the pages corresponding to the shared tab and the game tab side-by-side. If the user interacts with the page corresponding to the game tab, because the user's displayed page includes the page corresponding to the shared tab, it is also considered that the current tab includes the shared tab. However, when the user sets the game tab to cover the shared tab, the user's displayed page does not include the page corresponding to the shared tab, and the current tab does not include the shared tab. An image recognition model can be run on the user's client to determine in real time whether the page displayed on the user's client includes the shared tab.

[0115] When the browser's main thread needs to control the display of the page corresponding to the displayed information, including shared tabs, it can call the Canvas Application Programming Interface (API) method `putImageData` to add the page display information to the front end. <canvas>On the element. Of course, other interfaces can also be called to make the user's monitor display the page corresponding to the page display information. Here, we will not limit how the page corresponding to the page display information is displayed.

[0116] For example, the client can run an onmessage event listener to receive bitstream information from the server. In order not to block the browser's main thread and avoid page lag, the decoder can run on a separate processing thread. The decoder includes TinyH264, and the bitstream information includes H.264 data blocks. The H.264 data blocks received by the onmessage event listener are passed to the processing thread.

[0117] TinyH264 in the processing thread is responsible for parsing H.264 data blocks, identifying shared pages, treating them as video frames (NAL units), and decoding them into raw image data that the browser can render, such as pixel matrices in YUV or RGB format. Thus, the decoder running on the processing thread performs real-time decoding of the raw stream without affecting the browser's main thread.

[0118] Each time TinyH264 in the processing thread decodes a complete frame of a shared page, it obtains the page display information of that shared page. The page display information includes the information required for the shared page to be displayed on the user's browser. The page display information may include the pixel data of the shared page, such as a Uint8Array containing RGB values. The processing thread can send the page display information to the browser's main thread frame by frame through the postMessage method.

[0119] After receiving the page display information, the browser's main thread calls the Canvas API's putImageData method to draw the page display information onto the front end. <canvas>By using two independent threads on the user's local machine, the raw stream can be decoded without affecting the browser's main thread, thus speeding up the display of shared pages.

[0120] Page display information can include information required for displaying one or more shared pages. The above example uses one shared page. Of course, page display information can also include information required for displaying multiple shared pages, thereby reducing the number of times the processing thread sends page display information to the browser's main thread.

[0121] Steps 1031 to 1033 continuously generate video streams, resulting in smooth and real-time video playback in the user's browser when the processing thread and the browser's main thread decode and render at extremely high frequencies. For example, the processing thread and the browser's main thread repeatedly execute steps 1031 to 1033 30 to 60 times per second.

[0122] In some embodiments, if the processing thread triggers a pause event, the method further includes at least one of the following:

[0123] Step 301: Stop generating page display information;

[0124] Step 302: Stop sending page display information to the browser's main thread;

[0125] Step 303: Send a stop forwarding message to the server; The server responds to the stop forwarding message and stops forwarding the bitstream information to the user.

[0126] In this embodiment of the disclosure, in order to reduce unnecessary resource consumption, the processing thread may stop decoding the bitstream information when a pause event is triggered.

[0127] For example, if the current time is the first time point, and the current tab does not include the shared tab, the processing thread can store the bitstream information within the first time period without decoding it. At this time, no page display information will be generated, nor can the page display information be sent to the browser's main thread. Suppose the current time is the second time point, which is later than the first time point, and the current tab includes the shared tab. In this case, the processing thread can decode the bitstream information within the first time period and obtain the bitstream information. Thus, when the user switches the current tab from a non-shared tab back to a shared tab, the user can view the shared page on the device without having to wait for a long time.

[0128] To reduce unnecessary resource consumption and to allow users to view the shared page on the backup device without waiting when switching back to the shared tab, the processing thread can stop sending page display information to the browser's main thread.

[0129] For example, if the current time is the first time point, and the current tab does not include shared tabs, the processing thread decodes the bitstream information in real time, generates and stores page display information for the second time period or a preset number of times, but does not send the page display information to the browser's main thread. However, if the current time is the second time point, and the current tab includes shared tabs, the processing thread can immediately send the decoded page display information to the browser's main thread. This is because the transmission rate of page display information between the browser's main thread and the processing thread is fast, and the browser's main thread can immediately render the page display information. <canvas>In terms of elements, this allows users to immediately view the shared page on their device when they switch from a non-shared tab back to a shared tab.

[0130] To significantly reduce unnecessary resource consumption, the processing thread can send a stop forwarding message to the server.

[0131] For example, if the current tab does not include a shared tab, the server can receive a stop forwarding message and stop sending the bitstream information to the user. This reduces unnecessary data forwarding on the server and the amount of data forwarded, and the user's processing thread does not need to perform decoding operations.

[0132] In some embodiments, the client further includes a statistics thread; the method also includes at least one of the following:

[0133] Step 401: If the processing thread does not include a shared tab in the current tab, it triggers a pause event.

[0134] In this embodiment of the disclosure, the browser can provide a background processing function. When the background processing function is closed and the currently selected tab is not a shared tab, the browser's main thread sends a tab not selected message to the processing thread. The processing thread responds to the tab not selected message and triggers a pause event.

[0135] For example, browsers can provide background processing functionality. When background processing is enabled, the processing thread can process the bitstream information in real time if the user has not selected a shared tab or if the current tab does not include a shared tab. When background processing is disabled, the processing thread will not process the bitstream information if the user has not selected a shared tab or if the current tab does not include a shared tab.

[0136] The browser includes two tabs: a game tab and a shared tab. Currently, the user is interacting with the page corresponding to the game tab; that is, the user has selected the game tab. The browser's main thread, based on the fact that the currently selected tab is the game tab and background processing is disabled, sends a "tab not selected" message to the processing thread. The processing thread, based on this message, knows that the user is currently interacting with another tab, application, or mini-program, and triggers a pause event. Consequently, the page corresponding to the shared tab automatically stops displaying the shared page.

[0137] Step 402: If the processing thread triggers a pause event when the first duration is greater than or equal to the first duration threshold, the first duration is the duration of the current tab excluding the shared tab.

[0138] In this embodiment of the disclosure, based on step 401, the duration of the current tab excluding the shared tab is counted to obtain a first duration. For example, if the current tab includes the shared tab, it means that the tab selected by the user is the shared tab. The duration of the user not selecting the shared tab is counted. When the duration of not selecting the shared tab is too long, a pause event can be automatically triggered.

[0139] The processing thread can count the first duration, or the user end can include a statistics thread. The statistics thread is used to count the first duration. If the first duration is greater than or equal to the first duration threshold, it sends a first timeout message to the processing thread. The processing thread can respond to the first timeout message and automatically trigger a pause event.

[0140] In step 403, the browser's main thread responds to the pause operation for the shared tab by sending a tab pause message to the processing thread; the processing thread responds to the tab pause message by triggering a pause event.

[0141] In this embodiment of the disclosure, the viewing page corresponding to the shared tab includes a pause control, which allows the user to actively control whether to pause the display of the shared page by clicking the pause control.

[0142] Steps 401 to 403 above illustrate three scenarios for triggering a pause event. The processing thread can actively or passively trigger a pause event based on user actions, thereby flexibly determining whether to pause the display of the shared page and reducing energy consumption.

[0143] In some embodiments, the browser's main thread can respond to user actions by setting the page corresponding to the shared tab, such as in step 403 above, by pausing or resuming playback of the shared page on the device in response to user actions. The browser's main thread also has the function of setting the size of the viewing page corresponding to the shared tab. The method further includes: the browser's main thread adjusting the size of the viewing page in response to an adjustment operation on the viewing page.

[0144] In this embodiment of the disclosure, the size of the user's monitor includes, but is not limited to, 41 cm * 25 cm, 52 cm * 29 cm, etc., that is, the size of the viewed page is less than or equal to the size of the user's monitor. The browser may have functions such as page maximization, full screen, and window resizing, so that the user can freely adjust the size of the viewed page; the browser's main thread can respond to the user's operation and adjust the size of the viewed page.

[0145] For example, if the user's monitor is 52 cm x 29 cm and the page size is 10 cm x 29 cm, the user can adjust the length of the page to 52 cm. The browser's main thread can then respond to the user's action and adjust the page size to 52 cm x 29 cm.

[0146] In some embodiments, the browser also provides the function of setting instruction information. In response to the obtained instruction information, the browser's main thread sends the instruction information to the server.

[0147] In this embodiment of the disclosure, the viewing page may include an instruction information control, through which the user can set instruction information. For example, the instruction information control includes, but is not limited to, a bitrate control, a resolution control, a video codec standard control, a device identification control, etc., so that the user can flexibly set parameters such as bitrate, resolution, and video codec standard through the above controls.

[0148] In some embodiments, a long-lived connection has been established between the user and the server. The method further includes steps 501 to 502, wherein:

[0149] Step 501: The processing thread responds to the close event and disconnects the long connection established between the client and the server.

[0150] In step 502, in response to the disconnection of the long connection established with the user, the server controls the device to shut down the scrcpy process.

[0151] In this embodiment of the disclosure, the close event is used to indicate that the shared tab is closed. That is, when the shared tab is closed, the user terminal and the server disconnect the long connection, the server sends a termination signal to the scrcpy process, so that the device can safely close the scrcpy process. In turn, the device will release the resources occupied by the scrcpy process, so that the cleanup operation can be completed in a timely manner when the shared page is no longer needed.

[0152] In some embodiments, the method further includes at least one of the following:

[0153] Step 601: If the processing thread triggers a close event when the first duration is greater than or equal to the second duration threshold, the first duration is the duration of the current tab excluding the shared tab.

[0154] In step 602, the browser's main thread responds to the closing operation of the shared tab by sending a tab close message to the processing thread; the processing thread responds to the tab close message by triggering a close event.

[0155] In this embodiment of the disclosure, in step 601, referring to step 402 above, if the second duration threshold is greater than the first duration threshold, that is, if the duration of the current tab excluding the shared tab is too long, the long connection between the current tab and the server can be automatically closed to avoid the waste of resources caused by the user forgetting to close the shared tab, thereby releasing the resources occupied by the server and the device in a timely manner.

[0156] In step 602, referring to step 403 above, the viewing page corresponding to the shared tab includes a close control, and the user can actively control whether to close the shared tab by clicking the close control.

[0157] Steps 601 to 602 above illustrate two scenarios for triggering the shutdown event. The processing thread can actively or passively trigger the shutdown event based on user actions, thereby flexibly determining whether to continue displaying the shared page and reducing energy consumption.

[0158] In some embodiments, the method further includes: the server counting a second duration of the scrcpy process; wherein the second duration includes the duration during which the scrcpy process exists; and the server controlling the device to close the scrcpy process based on the second duration being greater than or equal to a third duration threshold.

[0159] In this embodiment of the disclosure, the third duration threshold may be related to the device identifier of the user terminal. For example, different device identifiers correspond to different third duration thresholds. The server can determine the third duration threshold through the device identifier of the user terminal, and then control the shared duration through the third duration threshold.

[0160] Figure 2 This is a schematic diagram illustrating an interaction according to an exemplary embodiment, such as... Figure 2 As shown, the user end refers to the device used by the user, which may be running a web browser; the server end may include a WebSocket proxy server; and the device end includes the scrcpy process. To view and stop viewing the shared page on the device end, the user can follow these steps:

[0161] Step 21: The client responds to the connection operation input by the user and establishes a long connection with the server.

[0162] Step 22: In response to the long connection established with the user, the server controls the device to start the scrcpy process;

[0163] Step 23: The scrcpy process encodes the page displayed on the device as a video stream, generates an H.264 video stream, and sends the H.264 video stream to the server.

[0164] Step 24: The server sends the H.264 video stream to the client; the client decodes the H.264 video stream to obtain the page display information and displays the video corresponding to the page display information.

[0165] Step 25: The client responds to the user's closed operation and disconnects the long connection from the server.

[0166] In step 26, the server responds to the disconnection of the long connection with the user by controlling the device to shut down the scrcpy process.

[0167] In this embodiment of the disclosure, the user terminal is used to interact with the user through a web browser; present a user interface (UI); decode an H.264 video stream; and in <canvas>The server renders the screen. It manages client connections, controls the lifecycle of the scrcpy process, and forwards data bidirectionally. The device side captures the page displayed on the device, encodes it as an H.264 video stream, and executes control commands.

[0168] In step 21, the user can click a shared page link on their client device to establish a persistent connection between the client and the server. The shared page link allows the user to view a page shared by the device, and includes, but is not limited to, the device's identifier. Control commands may include a connection request. In response to the user's click on the shared page link, the client can generate and send a connection request to the server. The persistent connection includes a WebSocket communication connection. The server will then send a connection response to the client based on the connection request. The client can respond to the connection response to establish a WebSocket communication connection with the server, thereby establishing a persistent connection between the client and the server.

[0169] In step 22, in response to the newly established WebSocket communication connection, the server, based on the Node.js runtime environment, treats the newly established WebSocket communication connection as a new streaming session. The server immediately calls its internal process management module ProcessRunner.ts to control the device to start a scrcpy native process as a child process.

[0170] The server also sends instruction parameters to the scrcpy process, which instruct the native scrcpy process to run in a specific background mode. These instruction parameters include no-display, bit-rate, max-size, and serial.<device_id> This allows the device to determine the conditions that the output raw video stream must meet, so that the scrcpy process can encode the captured shared pages based on the instruction parameters and output the encoded H.264 video stream as the standard output stream (stdout) to the server.

[0171] A WebSocket communication connection is also established between the device and the server, and the bitstream information includes an H.264 video stream. In step 23, through the WebSocket communication connection established between the device and the server, the device can continuously send H.264 video streams to the server. The H.264 video stream in steps 23 and 24 refers to the bitstream obtained by encoding the shared page on the device as an image using H.264. The H.264 video stream includes H.264 data blocks (buffers). At this time, the server can capture the output H.264 data blocks in real time by listening to the stdout event of the scrcpy process.

[0172] In step 24, whenever a new data block is generated on the standard output stream stdout, the server does not parse the H.264 video stream. Instead, it outputs the H.264 data block directly to the user as a binary message (Binary Frame) of the WebSocket. This "pass-through" forwarding mechanism minimizes the processing overhead and latency on the server side.

[0173] The client-side includes an `onmessage` event listener. When triggered, this listener receives binary messages, specifically H.264 data blocks, from the server. The client-side also includes a processing thread and the browser's main thread. The processing thread includes an H.264 decoder; for example, to avoid page lag and improve browser performance, the processing thread can be a separate Web Worker thread. The H.264 decoder uses TinyH264. The H.264 decoder decodes the H.264 video stream to obtain the page display information for each shared page. This page display information is raw image data that the browser can render, such as a pixel matrix in YUV or RGB format. The processing thread then sends this page display information to the browser's main thread using the `postMessage` method. Each shared page corresponds to one set of page display information, allowing the processing thread to smoothly and continuously send page display information to the browser's main thread, thus ensuring the client's monitor continuously displays the shared page.

[0174] The browser's main thread uses the Canvas API's putImageData method to render the decoded page display information onto the page. <canvas>By repeatedly executing steps 23 and 24 above, the scrcpy process can continuously generate video streams, thus creating a smooth and real-time video playback effect in the user's browser.

[0175] In step 25, when a user needs to close the browser's shared tab, a close operation can be performed. Alternatively, when a user has not viewed the JavaScript code for an extended period, the shared tab can be actively closed by running the corresponding JavaScript code. The user client can send a control command to disconnect the persistent connection between the client and the server. In this case, the control command includes a close message, allowing the client to proactively send a close message to the server to disconnect the persistent connection between the client and the server.

[0176] In step 26, after the server hears the close message, it immediately sends a termination signal to the scrcpy process, causing the scrcpy process to respond to the termination signal and stop running. This releases the system resources on the device, thus completing the cleanup of the entire session.

[0177] The architecture described above comprises three key components: a client, a server, and the native scrcpy process. Adjacent components interact via WebSocket and the process's standard input / output streams. The standard output (stdout) of the native scrcpy application is used as the video source. Through a WebSocket connection, the server forwards the device-generated bitstream information to the user in real-time and transparently. The user-side decoder decodes the bitstream information, and the browser's main thread renders the resulting page. By utilizing the scrcpy process running in the backend on the device, the server-side Node.js subprocess management and streaming I / O capture, the user-side WebSocket binary stream transmission, the user-side's in-thread decoder, and the user-side canvas for real-time rendering, end-to-end data transmission is achieved, providing a low-latency screen mirroring solution based on the browser.

[0178] The above steps offer unparalleled convenience and cross-platform capability: users do not need to install software, applications, drivers, or browser plugins. By clicking the corresponding link, users can view the shared page on their device through a browser. It features "zero installation" and "click and play," greatly reducing the barrier to entry for users.

[0179] It also features low latency and high performance: via WebSocket communication, the raw H.264 stream is directly pushed to the browser and decoded on the client side, avoiding the extra latency and resource consumption caused by server-side transcoding, and ensuring a real-time interactive experience close to that of native applications.

[0180] It is also lightweight and easy to deploy: the entire backend service only depends on Node.js and scrcpy, consumes few resources, and can be easily deployed on personal computers or private servers, providing a flexible and economical remote real device access solution.

[0181] It also features high integration: as a pure Web technology solution, a functional module can be easily designed to implement the above steps. This module can be seamlessly integrated into the corresponding modules of existing Web applications, such as those for online education, mobile application development, remote customer support, and automated testing platforms. Furthermore, when these applications are running on the device, users do not need to install any additional applications and can view the shared interface on the device through a browser, thus reducing the number of applications on the user's device and minimizing unnecessary storage space usage.

[0182] Figure 3 This is a schematic diagram illustrating the structure of a shared data processing system according to an exemplary embodiment, such as... Figure 3 As shown, the system 31 includes a device side 311 and a user side 313. The device side 311 includes a scrcpy process 3111.

[0183] The scrcpy process 3111 is used to send bitstream information to the user terminal 313 based on the acquired instruction information; the bitstream information is used to indicate the shared page displayed on the device.

[0184] Client 313 is used to process the bitstream information, generate page display information, and display the shared page corresponding to the page display information through a browser.

[0185] In some embodiments, the system further includes a server 312;

[0186] The scrcpy process 3111 is used to send bitstream information to the server.

[0187] Server 312 is used to forward the bitstream information to the user terminal.

[0188] In some embodiments, server 312 is configured to, when a long connection is established with the user terminal, control the device terminal to start the scrcpy process and send the instruction information to the scrcpy process; wherein the instruction information is used to instruct at least one of the following: to run in background mode, to encode the shared page, or to send it to the user terminal;

[0189] The scrcpy process 3111 is used to generate shared page information based on shared pages; and to encode the shared page information based on instruction information to generate bitstream information.

[0190] In some embodiments, the user terminal 313 is configured to send a connection request to the server 312 in response to a connection event;

[0191] Server 312 is used to respond to connection requests by sending a connection response to client 313 and confirming the establishment of a long connection with client 313; wherein, the long connection includes WebSocket communication connection, WSS communication connection or QUIC communication connection.

[0192] In some embodiments, client 313 is used to run a browser, the browser including at least one tab; the client includes an event listener 3131, a browser main thread 3132 and a processing thread 3133;

[0193] Event listener 3131 is used to listen for the bitstream information sent by the server and send the bitstream information to the processing thread 3133;

[0194] Processing thread 3133 is used to process the bitstream information and generate page display information; the page display information is sent to the browser main thread 3132 through cross-origin communication method;

[0195] Browser main thread 3132 is used to add page display information to the display canvas when the current tab includes a shared tab; where shared tabs are used to indicate that shared pages on the device should be displayed.

[0196] In some embodiments, processing thread 3133 is configured to perform at least one of the following upon triggering a pause event:

[0197] Stop generating page display information;

[0198] Stop sending page display information to the browser's main thread 3132;

[0199] Send a stop forwarding message to server 312; server 312 responds to the stop forwarding message and stops forwarding the bitstream information to client 313.

[0200] In some embodiments, processing thread 3133 is configured to trigger a pause event if the current tab does not include a shared tab.

[0201] Processing thread 3133 is used to trigger a pause event when the first duration is greater than or equal to a first duration threshold; where the first duration is the duration of the current tab excluding shared tabs.

[0202] The browser's main thread 3132 is used to send a tab pause message to the processing thread 3133 in response to a pause operation on a shared tab; the processing thread 3133 is used to trigger a pause event in response to the tab pause message.

[0203] In some embodiments, a persistent connection is established between the user terminal 313 and the server terminal 312.

[0204] Processing thread 3133 is used to disconnect the long connection established between client 313 and server 312 in response to a close event;

[0205] Server 312 is used to control the device to close the scrcpy process 3111 in response to the disconnection of the long connection established with the user 313.

[0206] In some embodiments, processing thread 3133 is configured to trigger a close event if the first duration is greater than or equal to a second duration threshold; wherein the first duration is the duration of the current tab excluding shared tabs;

[0207] The browser's main thread 3132 is used to send a tab close message to the processing thread 3133 in response to a closed operation of a shared tab; the processing thread 3133 responds to the tab close message and triggers a close event.

[0208] The above-described methods for processing shared data have already described various embodiments, and will not be repeated here.

[0209] This disclosure provides a shared data processing system. The bitstream information is information obtained by encoding the shared interface on the device side. The scrcpy process can continuously send the bitstream information to the user end in real time. The user end decodes the bitstream information and renders the decoded page display information so that the rendered image can be displayed through a browser, that is, the shared interface is displayed through a browser. Thus, the user end does not need to install clients, software, plugins, applications, etc. to decode the received bitstream information and then display the shared interface through a browser, making page sharing convenient and cross-platform, with the characteristics of "zero client", improving the efficiency of page sharing. Moreover, the above method is simple to implement, has high real-time performance, and the technical solution is common. It is lightweight and easy to deploy. Furthermore, the user end has high integration, and a functional module can be easily designed to implement the above step 103. This functional module can be seamlessly integrated into the corresponding module of the current web application.

[0210] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.< / canvas> < / canvas> < / canvas> < / canvas> < / canvas>

Claims

1. A method for processing shared data, characterized in that, The method is applied to a shared data processing system, which includes a device end and a user end, wherein the device end includes a scrcpy process; the method includes: The scrcpy process sends bitstream information to the user terminal based on the acquired instruction information; wherein, the bitstream information is used to indicate the shared page displayed on the device terminal; The user terminal processes the bitstream information, generates page display information, and displays the shared page corresponding to the page display information through a browser.

2. The method according to claim 1, characterized in that, The system also includes a server; the scrcpy process sends bitstream information to the user terminal; including: The scrcpy process sends the bitstream information to the server; The server forwards the bitstream information to the user terminal.

3. The method according to claim 2, characterized in that, The method further includes: When the server establishes a long connection with the user, it controls the device to start the scrcpy process and sends the instruction information to the scrcpy process; wherein, the instruction information is used to instruct at least one of the following: the scrcpy process to run in background mode, to encode the shared page, or to send the bitstream information to the user. The scrcpy process generates page sharing information based on the shared page; The scrcpy process encodes the page-shared information based on the instruction information to generate a bitstream.

4. The method according to claim 3, characterized in that, The method further includes: In response to a connection event, the user terminal sends a connection request to the server. In response to the connection request, the server sends a connection response to the user and determines that a long connection is established with the user; wherein the long connection includes a WebSocket communication connection, a WSS communication connection, or a QUIC communication connection.

5. The method according to claim 2, characterized in that, The client is used to run a browser, the browser including at least one tab; the client includes an event listener, a browser main thread, and a processing thread; the method further includes: The event listener listens for the bitstream information sent by the server and sends the bitstream information to the processing thread; The user terminal processes the bitstream information, generates page display information, and displays the shared page corresponding to the page display information through a browser, including: The processing thread processes the bitstream information to generate page display information; The processing thread sends the page display information to the browser's main thread via a cross-origin communication method; When the current tab includes a shared tab, the browser's main thread adds the page display information to the display canvas; wherein, the shared tab is used to indicate that the shared page on the device should be displayed.

6. The method according to claim 5, characterized in that, The method further includes: Upon triggering a pause event, the processing thread executes at least one of the following: Stop generating page display information; Stop sending the page display information to the browser's main thread; A stop forwarding message is sent to the server; in response to the stop forwarding message, the server stops forwarding the bitstream information to the user terminal.

7. The method according to claim 6, characterized in that, The method further includes at least one of the following: The processing thread triggers the pause event if the current tab does not include a shared tab. The processing thread triggers the pause event when the first duration is greater than or equal to a first duration threshold; wherein, the first duration is the duration of the current tab excluding the shared tab; In response to a pause operation on the shared tab, the browser's main thread sends a tab pause message to the processing thread; the processing thread, in response to the tab pause message, triggers the pause event.

8. The method according to claim 5, characterized in that, The user terminal and the server terminal establish a long-lived connection; the method further includes: In response to a close event, the processing thread disconnects the long connection established between the user and the server. In response to the disconnection of the long connection established with the user, the server controls the device to shut down the scrcpy process.

9. The method according to claim 8, characterized in that, The method further includes at least one of the following: The processing thread triggers the close event when the first duration is greater than or equal to the second duration threshold; wherein, the first duration is the duration of the current tab excluding the shared tab; In response to the closing operation of the shared tab, the browser's main thread sends a tab closing message to the processing thread; in response to the tab closing message, the processing thread triggers the closing event.

10. A shared data processing system, characterized in that, The system includes a device side and a user side, and the device side includes the scrcpy process; The scrcpy process is used to send bitstream information to the user terminal based on the acquired instruction information; wherein the bitstream information is used to indicate the shared page displayed on the device terminal. The user terminal is used to process the bitstream information, generate page display information, and display the shared page corresponding to the page display information through a browser.

Images