Content acquisition method and apparatus

Abstract

Embodiments of the present application provide a content acquisition method and device, computer equipment, computer readable storage medium and computer program product, and belong to the technical field of computers. The content acquisition method comprises: creating a mirror window corresponding to a target window in a process space of a first target application program, the target window being a window in the first target application program; listening to an update operation of the first target application program on the target window; in the case that the target window is updated, acquiring updated content of the target window and synchronously updating the updated content to the mirror window; and acquiring window content from the mirror window and sharing or transferring the window content to a second target application program. The technical solution of the embodiments of the present application can reduce the dependence on the style and state of the captured target window, improve the success rate of content (such as lyrics) acquisition, avoid the adaptation workload of different application programs and different graphical interface versions, and reduce the difficulty of scheme implementation.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a content acquisition method, apparatus, computer device, computer-readable storage medium, and computer program product. Background Technology

[0002] With the development of Internet technology, multi-application collaboration has become an important means to improve user experience. For example, in scenarios such as live streaming and screen recording, it is often necessary to integrate dynamic information output by other applications in the current system (such as media playback progress, lyrics text, notification messages, etc.) into the main screen (such as the live streaming screen) to achieve content enhancement or information synchronization.

[0003] Currently, the following two methods are mainly used to obtain the above dynamic information:

[0004] 1. Window content capture method: This method locates the display window of the application corresponding to the content source through the system interface, captures the displayed content of the window, and extracts the required dynamic information from it. However, this method is highly dependent on the window's display state. When the window is borderless, transparent, or layered, the system interface usually cannot obtain valid window content, resulting in blank or abnormal areas as the capture result.

[0005] 2. Rendering data acquisition method: This method involves accessing the graphics rendering process of the application corresponding to the content source and acquiring the corresponding image frames during the generation of display data to obtain the required dynamic information. However, different applications may use different graphics interfaces or rendering frameworks, requiring adaptation to multiple interface versions, resulting in high development costs. Furthermore, this method is easily identified as abnormal behavior, leading to instability in the application corresponding to the content source or failure of the access process.

[0006] It should be noted that the above content is not necessarily prior art, nor is it intended to limit the scope of patent protection of this application. Summary of the Invention

[0007] This application provides a content acquisition method, apparatus, computer device, computer-readable storage medium, and computer program product to solve or alleviate one or more of the technical problems mentioned above.

[0008] One aspect of this application provides a content acquisition method, the method comprising: A mirror window corresponding to the target window is created within the process space of the first target application, wherein the target window is a window in the first target application; Monitor the update operations of the first target application on the target window; When the target window is updated, the updated content of the target window is obtained, and the updated content is synchronously updated to the mirror window; Obtain the window content from the mirrored window and share or transfer the window content to the second target application.

[0009] Optionally, the window content is image data, and the step of obtaining the window content from the mirrored window and sharing or transferring the window content to the second target application includes: Determine whether the creation of shared textures is supported; If supported, create a shared texture and write the image data into the shared texture; The image data is shared to the second target application via the shared texture.

[0010] Optionally, the method further includes: In cases where shared texture creation is not supported or fails, shared memory is created. The image data is copied to the shared memory so that the second target application can copy the image data from the shared memory for rendering.

[0011] Optionally, before creating a mirror window corresponding to the target window within the process space of the first target application, the method further includes: Create a candidate window list and add windows in the system that meet preset conditions to the candidate window list; The candidate window list is continuously maintained, and invalid windows are removed from the candidate window list; The optimal window is determined from the candidate window list based on several window attributes. The target window is the current optimal window. The window attributes include the window name, the window stacking order, the window visibility status, and the window content update frequency.

[0012] Optionally, the method further includes: If the target window becomes invalid, the target window is removed from the candidate window list to obtain an updated candidate window list; Based on the aforementioned window attributes, a new optimal window is determined from the updated list of candidate windows, and the steps of creating a mirror window corresponding to the target window within the process space of the first target application and subsequent steps are executed.

[0013] Optionally, the method further includes: Check if the creation of shared textures is supported; When shared texture creation is supported, a primary channel and a backup channel are established. The primary channel achieves window content sharing through shared textures, while the backup channel transfers the window content through shared memory.

[0014] Optionally, the method is applied to a content acquisition plugin that is independent of the second target application.

[0015] Optionally, creating a mirror window corresponding to the target window within the process space of the first target application includes: Create a mirror window in the process space of the first target application that is in the same position and size as the target window and is a layered window, and set the target window as the parent window of the mirror window.

[0016] Optionally, the step of monitoring the update operation of the first target application on the target window; and in the case of the target window being updated, obtaining the updated content of the target window and synchronously updating the updated content to the mirror window, includes: Listen for calls to the window rendering function; When the window rendering function is called and the caller is the first target application, the rendering parameters corresponding to the window rendering function are obtained, and the window rendering function is called based on the rendering parameters to update the content of the target window; Replace the window handle in the rendering parameters with the window handle of the mirrored window; The window rendering function is called again based on the replaced rendering parameters to synchronize the updated content of the target window to the mirror window.

[0017] Another aspect of this application provides a content acquisition apparatus, the apparatus comprising: A creation module is used to create a mirror window corresponding to the target window within the process space of the first target application, wherein the target window is a window in the first target application; A listening module is used to listen for update operations of the first target application on the target window; The synchronization module is used to obtain the updated content of the target window when the target window is updated, and to synchronously update the updated content to the mirror window. The processing module is used to obtain window content from the mirrored window and share or transfer the window content to a second target application.

[0018] Another aspect of this application provides a computer device, including: At least one processor; and A memory that is communicatively connected to the at least one processor; Wherein: the memory stores instructions that can be executed by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method as described above.

[0019] Another aspect of this application provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the method described above.

[0020] Another aspect of this application provides a computer program product including a computer program that, when executed by a processor, implements the method described above.

[0021] The embodiments of this application employing the above-described technical solution may have the following advantages: By creating a mirror window corresponding to the target window within the process space of the first target application, monitoring the first target application's update operations on the target window, and when the target window is updated, obtaining the updated content of the target window, synchronously updating the mirror window with this updated content, obtaining the window content from the mirror window, and sharing or transferring the window content to the second target application, the dependency on the style and state of the original target window (such as a lyrics window) can be reduced by synchronously updating the content of the mirror window, thus improving the success rate of content (such as lyrics) retrieval. Furthermore, by creating a mirror window within the process space of the first target application to retrieve content, the workload of adapting to different applications and different graphical interface versions can be avoided, making it less susceptible to interference from security software, reducing the difficulty of implementation, and improving the stability of content retrieval. Attached Figure Description

[0022] The accompanying drawings exemplify embodiments and form part of the specification, serving together with the textual description to explain exemplary implementations of the embodiments. The illustrated embodiments are for illustrative purposes only and do not limit the scope of the claims. Throughout the drawings, the same reference numerals refer to similar but not necessarily identical elements.

[0023] Figure 1 This diagram schematically illustrates the operating environment of the content acquisition method according to Embodiment 1 of this application; Figure 2 A flowchart illustrating a content acquisition method according to Embodiment 1 of this application is shown schematically. Figure 3 Schematic illustration Figure 2 Flowchart of the sub-steps in step S206; Figure 4The illustration schematically shows a new flow in the content acquisition method according to Embodiment 1 of this application; Figure 5 This illustration schematically shows another additional process in the content acquisition method according to Embodiment 1 of this application; Figure 6 This illustration schematically shows yet another addition to the content acquisition method according to Embodiment 1 of this application; Figure 7 This illustration schematically shows yet another addition to the content acquisition method according to Embodiment 1 of this application; Figure 8 Schematic illustration Figure 2 Flowcharts of the sub-steps in steps S202 and S204; Figure 9 This illustration shows an example of an application flow diagram of the content acquisition method according to Embodiment 1 of this application; Figure 10 A block diagram of a content acquisition device according to Embodiment 2 of this application is schematically shown; and Figure 11 A schematic diagram of the hardware architecture of a computer device according to Embodiment 3 of this application is shown. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with 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 in this application without inventive effort are within the scope of protection of this application.

[0025] It should be noted that the descriptions involving "first," "second," etc., in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of that feature. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0026] In the description of this application, it should be understood that the numerical labels before the steps do not indicate the order of the steps, but are only used to facilitate the description of this application and to distinguish each step, and therefore should not be construed as a limitation of this application.

[0027] First, a definition of the terminology used in this application is provided: Shared textures: A special type of texture resource created in the memory of a graphics processing unit (GPU) that allows direct access to the same image data between different processes or modules, enabling efficient zero-copy cross-process image transfer.

[0028] Shared memory: A data area in system memory (RAM) that can be accessed by multiple processes simultaneously for inter-process communication (IPC).

[0029] Secondly, to facilitate understanding of the technical solutions provided in the embodiments of this application by those skilled in the art, the relevant technologies are described below: In related technologies, the following methods are mainly used to obtain dynamic information output by other applications within the current system (such as media playback progress, lyrics text, notification messages, etc.): 1. Window-based capture method: Locate the display window of the application corresponding to the content source through the system interface, capture the display content of the window, and extract the required dynamic information from it.

[0030] 2. Rendering data acquisition method: By accessing the graphics rendering process of the application corresponding to the content source, the corresponding image frames are obtained during the generation of display data, thereby obtaining the required dynamic information.

[0031] 3. Optical Character Recognition (OCR) based method: Directly perform optical character recognition on a specified area of ​​the screen.

[0032] In addition, in terms of software architecture, existing content capture functions are usually deeply coupled with the main program of live streaming software as built-in modules.

[0033] However, the first method heavily relies on the style and state of the content window. When the content window is set to borderless, transparent, or layered, it often fails to capture valid window content or captures blank or abnormal areas. Furthermore, window pixel capture involves frequent data copying between CPU memory and GPU memory, which can lead to significant CPU and GPU overhead at high resolutions and high frame rates. The second method requires adaptation to multiple graphics interface versions, which involves a large amount of adaptation work and is easily identified as abnormal behavior, resulting in instability or access failure. The third method is greatly affected by font and background interference, has poor real-time performance, and is not suitable for high-performance live streaming scenarios. Implementing the content capture function as a built-in module means that the function cannot be upgraded independently. Any optimization or update related to content capture requires recompiling or re-releasing the entire live streaming software, which will increase the size and memory usage of the main program.

[0034] In addition, when users open multiple content sources, they usually need to manually specify the capture source or capture one randomly, and cannot intelligently select the optimal and currently active content window; when the preferred capture source fails, there is no automatic degradation or switching mechanism, which makes the function completely unusable.

[0035] Therefore, this application provides a content acquisition technology solution. In this technology solution: 1. By redirecting and listening to the window rendering function, the content of the original content window can be synchronously updated to the mirror window, which can reduce the dependence on the content window style and state and improve the success rate of content capture. 2. Prioritize transferring image data via shared textures to avoid copying between the GPU and CPU, thus reducing CPU overhead; when the GPU environment does not support it or the shared texture creation method fails, automatically switch to shared memory to transfer data, ensuring the availability of core functions in various hardware and software environments.

[0036] 3. Separating the lyrics function from the main program kernel and implementing the corresponding function through an independent plugin can achieve flexibility in content function maintenance and reduce the size and memory usage of the main program.

[0037] 4. By creating a list of content windows, the system automatically determines the best capture target based on multiple window attributes. When the current capture target is closed, it automatically switches to the next capture source in the list, which can intelligently determine the capture source and effectively ensure the availability of the content capture function.

[0038] Please see the following text for the specific plan.

[0039] Finally, for ease of understanding, an exemplary operating environment is provided below.

[0040] Figure 1 The illustration shows an environmental application diagram according to an embodiment of this application.

[0041] The environmental diagram may include a service platform 2, broadcaster terminals (4A, 4B, ..., 4M), and viewer terminals (6A, 6B, ..., 6N). In a live broadcast scenario, the broadcaster terminals (4A, 4B, ..., 4M) log in to the service platform 2 and push live broadcast data to the viewer terminals (6A, 6B, ..., 6N) in real time through the service platform 2.

[0042] Service platform 2 can provide live streaming services, which can be a single server, a server cluster, or a cloud computing service center.

[0043] The broadcast terminals (4A, 4B, ..., 4M) are used to generate live streaming data in real time and to push the live streaming data. The live streaming data may include audio data or video data. The broadcast terminals can be electronic devices such as smartphones or tablets. Alternatively, the broadcast terminals can be virtual computing instances within service platform 2.

[0044] Viewer terminals (6A, 6B, ..., 6N) can be configured to receive live data from the broadcaster terminal in real time. Viewer terminals (6A, 6B, ..., 6N) can be any type of computing device, such as smartphones, tablets, laptops, smart TVs, in-vehicle terminals, etc. Viewer terminals (6A, 6B, ..., 6N) can have a built-in browser or dedicated program to receive the live data and output content to the user. The content may include video, audio, comments, text data, and / or the like.

[0045] The audience terminals (6A, 6B, ..., 6N) may include a player. The player outputs (e.g., displays, presents) content to the user. This content may include video, audio, comments, text data, and / or the like. The audience terminals (6A, 6B, ..., 6N) may include an interface that may include an input element (touchscreen). For example, the input element may be configured to receive user instructions that cause the audience terminals (6A, 6B, ..., 6N) to perform various operations, such as sending bullet comments, entering comments, sending gifts, etc.

[0046] The broadcast terminals (4A, 4B, ..., 4M), viewer terminals (6A, 6B, ..., 6N), and service platform 2 can be connected via a network. The network may include various network devices, such as routers, switches, multiplexers, hubs, modems, bridges, repeaters, firewalls, and / or proxy devices. The network may include physical links, such as coaxial cable links, twisted-pair cable links, fiber optic links, and combinations thereof and / or the like. The network may include wireless links, such as cellular links, satellite links, Wi-Fi links, and / or the like.

[0047] It should be noted that the number of broadcast terminals and viewer terminals shown in the diagram is merely illustrative and is not intended to limit the scope of patent protection of this application. In practice, any number of broadcast terminals and viewer terminals may be used.

[0048] The technical solutions of this application are described below through several embodiments. It should be understood that these embodiments can be implemented in many different forms and should not be construed as being limited to the embodiments set forth herein.

[0049] Example 1 Figure 2A flowchart illustrating a content acquisition method according to Embodiment 1 of this application is shown.

[0050] like Figure 2 As shown, the content acquisition method may include steps S200~S206, wherein: Step S200: Create a mirror window corresponding to the target window in the process space of the first target application. The target window is a window in the first target application.

[0051] Step S202: Listen for update operations of the first target application on the target window.

[0052] Step S204: If the target window is updated, obtain the updated content of the target window and synchronize the updated content to the mirror window.

[0053] Step S206: Obtain the window content from the mirrored window and share or transfer the window content to the second target application.

[0054] The content acquisition method provided in this embodiment creates a mirror window corresponding to the target window within the process space of the first target application, listens for update operations of the first target application on the target window, acquires the updated content of the target window when the target window is updated, synchronously updates the mirror window with the updated content, acquires the window content from the mirror window, and shares or transmits the window content to the second target application. By synchronously updating the content of the original target window (such as a lyrics window) to the mirror window, the dependence on the style and state of the original target window can be reduced, improving the success rate of content (such as lyrics) acquisition. At the same time, by acquiring content by creating a mirror window within the process space of the first target application, the workload of adapting to different applications and different graphical interface versions can be avoided, it is not easily interfered with by security software, the difficulty of implementation can be reduced, and the stability of content acquisition can be improved.

[0055] The following combination Figure 2 The steps in steps S200 to S206, as well as other optional steps, are described in detail.

[0056] Step S200 A mirror window corresponding to the target window is created within the process space of the first target application. The target window is a window in the first target application.

[0057] The primary target application is the content acquisition source. In scenarios where lyrics need to be captured, the primary target application is a music-related application, from which lyrics are captured.

[0058] Specifically, the relevant window attributes of the target window can be obtained from an external source through a cross-process window access interface. Then, a module for creating a mirrored window is loaded into the process memory space of the first target application using techniques such as remote thread creation or DLL injection. This module then calls the window creation API within the first target application's process space to create a mirrored window corresponding to the target window based on the previously obtained window attributes. Here, the target window is the window corresponding to the content acquisition; in a scenario where lyrics need to be captured, the target window could be a lyrics window.

[0059] In an optional embodiment, step S200 may further include: Create a mirror window in the process space of the first target application, with the same position and size as the target window and a layered window type, and set the target window as the parent window of the mirror window.

[0060] Specifically, remote thread injection or DLL injection techniques can be used to load the module used to create the mirrored window into the process space of the first target application. This module then calls the system window management API to obtain the target window's window handle, coordinates (e.g., top-left corner coordinates), width, height, window style, and other window attributes. Next, a creation parameter structure for the mirrored window can be defined, assigning the target window's coordinates, width, height, and other parameters to this structure. The system window creation API is then called, passing in the structure with initialized parameters, configuring the window's extended style to a layered window style, and setting the window's parent handle to the target window's handle, thus establishing a parent-child relationship between the target and mirrored windows. Optionally, the window attribute setting API can be called to disable the mirrored window's taskbar icon display, focus acquisition, user input response, and other functions, preventing the mirrored window from interfering with the original interactive logic of the first target application.

[0061] Traditional window capture methods lose transparency information, resulting in black borders or background blocks in the captured content. However, in this embodiment, layered windows can directly receive image data with transparency attributes and ignore user input events, without obscuring or interfering with the normal operation of the target window. By creating a mirror window at the same position and size as the target window, the mirror window can completely overlap with the target window, ensuring that subsequent synchronous updates can be accurately mapped to the mirror window without secondary processing such as scaling, cropping, or coordinate transformation of the captured content. At the same time, setting the target window as the parent window of the mirror window allows the mirror window to automatically follow the target window's movement, scaling, showing, or hiding states, eliminating the need for additional window position monitoring and calibration logic and simplifying the technical implementation.

[0062] Step S202 Listen for updates made by the first target application to the target window.

[0063] Specifically, the module injected via remote thread or DLL injection techniques can obtain the module handle of the system dynamic link library User32.dll using the GetModuleHandle function. Then, based on the function name "UpdateLayeredWindow", the GetProcAddress function locates the memory address of the window rendering function (UpdateLayeredWindow) in the current process's virtual memory space. After obtaining this memory address, the module uses function entry point rewriting techniques to modify the entry point instruction of the window rendering function, redirecting its execution flow to a custom proxy function. Window handle filtering logic is set in the custom proxy function; when the first target application calls the window rendering function, the execution flow is transferred to this custom proxy function. The custom proxy function checks the passed window handle parameter; if the current window handle matches the target window handle, it is determined to be an update operation of the target window, thus enabling monitoring of the target window's update operations. Optionally, the modified original instruction can be saved while modifying the window rendering function's entry point instruction, ensuring that the original function can be correctly called within the custom proxy function.

[0064] Step S204 When the target window is updated, the updated content of the target window is obtained and the updated content is synchronously updated to the mirror window.

[0065] In cases where the operation is determined to be an update operation of the target window, the rendering parameters corresponding to the window rendering function can be extracted. To ensure the functional integrity of the first target application, the custom proxy function first calls the window rendering function using the extracted rendering function to ensure that the target window (such as a lyrics window) can display the latest content normally according to its original logic. Then, the custom proxy function replaces the window handle in the rendering parameters with the window handle of the mirror window, leaving the other rendering parameters unchanged, and calls the window rendering function again, so that the updated content of the target window is synchronously updated to the mirror window.

[0066] Step S206 It retrieves window content from the mirrored window and shares or transfers the window content to a second target application.

[0067] After acquiring the window content from the mirrored window, a shared memory block can be created in system memory. The window content of the mirrored window is written into the shared memory, and the name and metadata of the shared memory are sent to the second target application via inter-process communication. The second target application then retrieves the window content based on the name and metadata of the shared memory. In this context, the second target application is the content acquirer. In the lyrics capture scenario, the second target application can be a live streaming software, screen recording tool, or video conferencing application that needs to overlay lyrics.

[0068] In an optional embodiment, the window content is image data. In step S206, the window content is obtained from the mirrored window, and the window content is shared or transferred to the second target application, such as... Figure 3 As shown, it may further include: Step S300: Determine whether the creation of shared textures is supported.

[0069] Step S302: If supported, create a shared texture and write the image data into the shared texture.

[0070] Step S304: Share the image data to the second target application by sharing the texture.

[0071] After extracting the image data from the mirrored window, the system graphics interface can be called to detect the current operating environment. By querying the GPU device's function identifier, driver version, and system graphics library support, it can be determined whether the creation of shared textures and cross-process access are supported. If the detection result indicates that the creation of shared textures is supported, the DirectX and other graphics APIs within the first target application process are called to create a shared texture resource that matches the resolution and color format of the mirrored window image. Cross-process access permissions can be configured. Subsequently, the image data extracted from the mirrored window is written to the video memory buffer of the shared texture. After the image data is written, the unique handle of the shared texture and necessary access parameters (such as texture size, format, GPU device identifier, etc.) can be sent to the second target application through a preset inter-process communication link. After receiving these parameters, the second target application can directly bind to and access the shared texture data in the GPU video memory based on these parameters, without needing to copy data between CPU memory and GPU video memory, and can then use the image data for rendering or subsequent processing.

[0072] In this embodiment, by determining whether the creation of a shared texture is supported, if supported, a shared texture is created, image data is written into the shared texture, and the image data is shared to the second target application through the shared texture. This avoids the huge CPU usage and memory bandwidth consumption caused by the "GPU→CPU→GPU" path in the traditional method, significantly improving performance and adapting to the needs of high-resolution, high-frame-rate live streaming scenarios. At the same time, the shared texture can completely preserve the visual attributes of the target window, realizing lossless transmission of the target window content (such as lyrics) and improving the stability of data transmission.

[0073] In optional embodiments, such as Figure 4 As shown, the content acquisition method in this application embodiment may further include: Step S400: In the case where the creation of a shared texture is not supported or the creation of a shared texture fails, create shared memory.

[0074] Step S402: Copy the image data to shared memory so that the second target application can copy the image data from the shared memory for rendering.

[0075] Specifically, if the system environment detection determines that the current hardware does not support the creation of shared textures, or if the creation of shared textures fails due to an anomaly during initialization or data writing, a degradation mechanism can be triggered. This mechanism creates a named shared memory region with global access permissions in the system memory. Subsequently, the image data obtained from the mirror window is completely copied to this shared memory region, and metadata such as data length, data format, and storage start address can be recorded. After the data copy is completed, the name, metadata, and access permission parameters of the shared memory region can be sent to the second target application through a preset inter-process communication link. The second target application can open the corresponding shared memory region according to the received parameters, read the image data from the shared memory region, convert it into a format supported by its own rendering engine, and then complete the rendering of the image data.

[0076] In this embodiment, in the event that the creation of shared textures is not supported or fails, shared memory is created, and image data is copied to the shared memory so that the second target application can copy image data from the shared memory for rendering. This can automatically switch to the shared memory channel when shared textures are not supported or fail to be created, avoiding interruption of content capture function due to the failure of a single technical path and improving the robustness of content acquisition. Since shared memory is implemented based on the system memory mechanism and does not rely on the special function support of the GPU, it can be adapted to various terminal devices.

[0077] In optional embodiments, such as Figure 5As shown, before step S200, that is, before creating a mirror window corresponding to the target window in the process space of the first target application, the content acquisition method of this application embodiment may further include: Step S500: Create a candidate window list by adding windows in the system that meet preset conditions to the candidate window list.

[0078] Step S502: Continuously maintain the candidate window list and remove invalid windows from the candidate window list.

[0079] Step S504: Determine the optimal window from the candidate window list based on several window attributes. The target window is the current optimal window. The window attributes include the window name, the window stacking order, the window visibility status, and the window content update frequency.

[0080] Specifically, a candidate window list that supports dynamic addition and deletion can be created through the second target application, and the window admission rules for the candidate window list can be configured. Then, the system window enumeration interface can be called to traverse all windows in the current runtime environment, adding windows that meet preset conditions to the candidate window list. These preset conditions can be set according to actual needs, such as the window title containing specific keywords (e.g., "lyrics"), or the window being in a non-minimized visible state. When maintaining the candidate window list, a full status check can be performed on all windows in the list at preset time intervals, monitoring the window's process liveness, handle validity, display level, and visibility in real time. If a window is detected to have failed due to process exit, manual closure, or being minimized, it is removed from the candidate window list. When determining the target window, the optimal window can be filtered from the candidate window list based on multiple window attributes. The target window is the currently selected optimal window. Filtering window attributes can include name matching degree, window stacking order, real-time window visibility, and window content update frequency. A preset weighted algorithm is used to comprehensively score each candidate window, and the window with the highest score is determined as the target window for this capture.

[0081] In this embodiment, by creating and continuously maintaining a candidate window list, the target window is determined from the candidate window list based on several window attributes. The most active and optimal window that best meets the requirements can be determined based on window attributes of multiple dimensions. Compared with the traditional method of manually specifying or randomly selecting, no user intervention is required, which improves the automation and accuracy of window capture. In addition, by setting preset conditions, only relevant windows can be included in the candidate window list, avoiding indiscriminate and high-frequency polling of all windows in the system and reducing the additional consumption of system operation.

[0082] In optional embodiments, such as Figure 6As shown, the content acquisition method in this application embodiment may further include: In step S600, if the target window fails, the target window is removed from the candidate window list to obtain an updated candidate window list.

[0083] Step S602: Determine a new optimal window from the updated candidate window list based on several window attributes, and execute the following steps: create a mirror window corresponding to the target window in the process space of the first target application.

[0084] Specifically, when a target window is detected to be invalid, it is removed from the candidate window list, resulting in an updated candidate window list. Then, based on multiple window attributes, each candidate window in the updated list is comprehensively scored using a preset weighted algorithm, and the window with the highest score is determined as the new optimal window. After determining the new optimal window, the process executes the steps of creating a mirror window corresponding to the target window within the process space of the first target application, thereby capturing content from the latest target window and sharing or transferring the captured content to the second target application. The first target application is the application corresponding to the latest target window. Optionally, while removing the original target window from the candidate window list, all system resources associated with the original target window can be cleaned up, including but not limited to: removing injected modules, destroying the created mirror window, and releasing shared textures or shared memory.

[0085] In this embodiment, when the target window fails, it is removed from the candidate window list to obtain an updated candidate window list. A new optimal window is determined from the updated candidate window list based on several window attributes. Then, the steps of creating a mirror window corresponding to the target window in the process space of the first target application and subsequent steps are executed. This allows for automatic switching to a new target window without the user's awareness when the original target window fails, avoiding the cumbersome operation of reconfiguring the capture source required by traditional solutions. This achieves uninterrupted operation of content capture and ensures the continuity and stability of content overlay in scenarios such as live streaming.

[0086] In optional embodiments, such as Figure 7 As shown, the content acquisition method in this application embodiment may further include: Step S700: Check if the creation of shared textures is supported.

[0087] In step S702, if the creation of shared textures is supported, a primary channel and a backup channel are established. The primary channel realizes the sharing of window content through shared textures, and the backup channel transfers window content through shared memory.

[0088] Specifically, by calling the relevant APIs of the system graphics interface, it can be determined whether the GPU of the device running the process of the first target application supports shared texture technology. The detection can include GPU hardware characteristics, driver version compatibility, and the support status of graphics libraries such as DirectX / OpenGL for shared textures. If the GPU supports shared textures, the shared texture channel is set as the primary channel, and the shared memory channel is initialized as a backup channel, completing the parameter configuration and resource pre-allocation of the two channels. If the GPU does not support shared textures, the shared memory channel can be directly used as the default transmission channel, and the resource initialization operations related to shared textures can be skipped.

[0089] In this embodiment, by checking whether the creation of shared textures is supported, if the creation of shared textures is supported, a primary channel and a backup channel are established. The primary channel realizes the sharing of window content through shared textures, while the backup channel transmits window content through shared memory. Data transmission can be prioritized through shared textures, which greatly reduces the consumption of CPU and memory bandwidth. At the same time, through the dual-channel mechanism of "shared texture as primary and shared memory as secondary", the system can seamlessly switch to the shared memory channel when the creation of shared textures fails, avoiding functional interruption caused by the failure of a single transmission path and ensuring the continuous availability of the window capture function.

[0090] In an optional embodiment, steps S202 and S204 involve monitoring the first target application's update operation on the target window, obtaining the updated content of the target window when the target window is updated, and synchronously updating the mirror window with the updated content. Figure 8 As shown, it may further include: Step S800: Listen for calls to the window rendering function.

[0091] In step S802, when the window rendering function is called and the caller is the first target application, the rendering parameters corresponding to the window rendering function are obtained, and the window rendering function is called based on the rendering parameters to update the content of the target window.

[0092] Step S804: Replace the window handle in the rendering parameters with the window handle of the mirrored window.

[0093] In step S806, the window rendering function is called again based on the replaced rendering parameters to synchronize the updated content of the target window to the mirror window.

[0094] The window rendering function can be UpdateLayeredWindow. It can be injected via remote thread or DLL injection techniques. The module handle is obtained using the GetModuleHandle function, which retrieves the module handle of the system dynamic link library User32.dll. Then, the memory address is located using the GetProcAddress function, based on the function name "UpdateLayeredWindow," to pinpoint the memory address of the window rendering function in the current process's virtual memory space. After obtaining the corresponding memory address, the injected module uses function entry point rewriting techniques to modify the window rendering entry point instruction, redirecting the execution flow of the window rendering function to a custom proxy function, thus completing the window rendering function redirection.

[0095] After redirecting the window rendering function, you can listen to the window rendering function through a custom delegate function. When the window rendering function is called, determine whether the caller is the first target application. If it is the first target application, obtain the rendering parameters of the window rendering function, including but not limited to bitmap data, window position coordinates, opacity blending, and window handle, and call the window rendering function, passing in these rendering parameters to ensure that the window content of the target window can be updated and displayed normally.

[0096] Next, the window handle in the rendering parameters is replaced with the window handle of the mirror window. Based on the rendering parameters remaining unchanged, the replaced rendering parameters are obtained. Then, the window rendering function is called again according to the replaced rendering parameters. This time, the updated content of the target window will be fully and synchronously rendered to the mirror window, so that the mirror window and the target window maintain pixel-level content consistency.

[0097] In this embodiment, by listening to the calls to the window rendering function, when the window rendering function is called and the caller is the first target application, the rendering parameters corresponding to the window rendering function are obtained. Based on the rendering parameters, the window rendering function is called to update the content of the target window. The window handle in the rendering parameters is replaced with the window handle of the mirror window. Based on the replaced rendering parameters, the window rendering function is called again to synchronize the updated content of the target window to the mirror window. This can completely replicate the bitmap data of the target window without affecting the display of the original window, solving the problem that traditional pixel capture methods cannot capture transparent windows and achieving pixel-level content synchronization.

[0098] In an optional embodiment, the content acquisition method of this application is applied to a content acquisition plugin, which is independent of the second target application.

[0099] In other words, the solutions in all the above embodiments can be implemented using content acquisition plugins. These plugins can be compiled into independent dynamic link library files and exist as separate installation packages, not embedded within the main installation package of the second target application. After startup, the second target application can load the content acquisition plugin on demand through a standard plugin interface. Once loaded, the plugin has its own independent process space or thread, and its operations such as window scanning, process injection, mirror window creation, redirection, and data transfer are all isolated from the core business logic of the second target application. Even if the content acquisition plugin malfunctions, it will not cause the second target application to crash. Functional optimization and version updates of the content acquisition plugin do not depend on the overall upgrade of the second target application; developers can release independent update packages for the content acquisition plugin. The content acquisition plugin can adopt a modular design internally; for example, the creation and maintenance of the candidate window list can be handled by the window management engine module within the content acquisition plugin.

[0100] In this embodiment, by applying the content acquisition method to a content acquisition plugin that is independent of the second target application, the rigid architecture problem caused by the traditional method of implementation through built-in modules can be overcome, the impact of functional module anomalies on the main program can be greatly reduced, the technical iteration cycle of the content acquisition plugin can be greatly shortened, the optimization of the content acquisition plugin can be more easily achieved, and the maintenance cost of the main program can be reduced.

[0101] To make this application easier to understand, the following is combined with... Figure 9 An example application is provided.

[0102] Figure 9 This is an example flowchart of the content acquisition method according to an embodiment of this application. The scenario in the figure is a scene of capturing lyrics, which, as shown, may generally include the following: 1. The main process of the second target application calls the lyrics capture and rendering plugin (i.e., content acquisition plugin) through the standard plugin interface. 2. The lyrics capture and rendering plugin establishes and maintains a dynamic list of candidate lyrics windows through the lyrics window intelligent management engine; 3. The lyrics window intelligent management engine selects the optimal window as the target window TargetLyricWnd based on the window's title, whether it is pinned to the top, desktop display, and other attributes, and determines the target window's process TargetProcess; the system API checks the GPU's support for shared textures and presets the primary channel (shared texture channel) and the backup channel (shared memory channel). 4. Load the window content capture module HookModule.dll into the address space of the target process through remote thread or DLL injection techniques; 5. The initialization code of the window content capture module creates a layered window InProcOverlayWnd (i.e., a mirror window) in the target process, which is in the same position and has the same size as the target window, and sets the target window as the parent window of the mirror window. 6. The window content capture module locates the function address of the window rendering function UpdateLayeredWindow in User32.dll, modifies the function entry instruction, and redirects it to the delegate function MyUpdateLayeredWindow; 7. The proxy function listens to the window rendering function and determines whether the caller's window handle is the target window. If so, it calls the original window rendering function to ensure that the original lyrics window is displayed correctly. Then, it uses the same bitmap data, position, and blending parameters, while replacing the target window handle with the handle of the mirrored window, so that the lyrics image is "mirrored" onto the mirrored window in the process. If not, it directly calls the original function without affecting the functionality of other parts of the system. 8. When shared textures are supported and created successfully, the window content capture module can use the DirectX device of the target process to create and update a shared texture, fill in the bitmap data, and then pass the handle of the shared texture back to the plugin in the main process via IPC (such as window messages, named events); if the creation of the shared texture fails or is not supported, a shared memory is allocated, the bitmap data is copied into it, and the name and pointer of the shared memory are passed back to the plugin in the main process. 9. After the main process plugin obtains the handle or pointer, it renders directly using a shared texture, depending on the channel type, or reads data from shared memory and converts it into a texture for rendering; 10. The lyrics window's intelligent engine continuously monitors the process. If the current target window becomes invalid, it automatically cleans up redirects and resources within the process, selects a new target window from the list, and repeats the above process to achieve seamless switching.

[0103] In this exemplary application, 1. By redirecting and listening to the window rendering function, the content of the original lyrics window is synchronously updated to the mirror window, which can reduce the dependence on the style and state of the lyrics window and improve the success rate of lyrics capture; 2. Prioritize transferring image data via shared textures to avoid copying between the GPU and CPU, thus reducing CPU overhead; when the GPU environment does not support it or the shared texture creation method fails, automatically switch to shared memory to transfer data, ensuring the availability of core functions in various hardware and software environments.

[0104] 3. Separating the lyrics function from the main program kernel and implementing the corresponding function through an independent plugin can improve the flexibility of lyrics function maintenance and reduce the size and memory usage of the main program.

[0105] 4. By creating a list of lyrics windows, the best capture target is automatically determined based on the properties of multiple windows. When the current capture target is closed, it automatically switches to the next capture source in the list. This can intelligently determine the capture source and effectively ensure the availability of the lyrics capture function.

[0106] Example 2 Figure 10 The diagram schematically illustrates a content acquisition device according to Embodiment 2 of this application. This device can be divided into one or more program modules. One or more program modules are stored in a storage medium and executed by one or more processors to complete the embodiment of this application. The program module referred to in this embodiment is a series of computer program instruction segments capable of performing a specific function. The following description will specifically introduce the function of each program module in this embodiment. For example... Figure 10 As shown, the device 900 may include: a creation module 910, a listening module 920, a synchronization module 930, and a processing module 940, wherein: The creation module 910 is used to create a mirror window corresponding to the target window within the process space of the first target application, wherein the target window is a window in the first target application; The listening module 920 is used to listen for update operations of the first target application on the target window; The synchronization module 930 is used to obtain the updated content of the target window when the target window is updated, and to synchronously update the updated content to the mirror window. The processing module 940 is used to obtain window content from the mirrored window and share or transfer the window content to a second target application.

[0107] In an optional embodiment, In an optional embodiment, the window content is image data, and the processing module 940 is further configured to: Determine whether the creation of shared textures is supported; If supported, create a shared texture and write the image data into the shared texture; The image data is shared to the second target application via the shared texture.

[0108] In an optional embodiment, the device 900 is further used for: In cases where shared texture creation is not supported or fails, shared memory is created. The image data is copied to the shared memory so that the second target application can copy the image data from the shared memory for rendering.

[0109] In an optional embodiment, the device 900 is further used for: Create a candidate window list and add windows in the system that meet preset conditions to the candidate window list; The candidate window list is continuously maintained, and invalid windows are removed from the candidate window list; The optimal window is determined from the candidate window list based on several window attributes. The target window is the current optimal window. The window attributes include the window name, the window stacking order, the window visibility status, and the window content update frequency.

[0110] In an optional embodiment, the device 900 is further used for: If the target window becomes invalid, the target window is removed from the candidate window list to obtain an updated candidate window list; Based on the aforementioned window attributes, a new optimal window is determined from the updated list of candidate windows, and the steps of creating a mirror window corresponding to the target window within the process space of the first target application and subsequent steps are executed.

[0111] In an optional embodiment, the device 900 is further used for: Check if the creation of shared textures is supported; When shared texture creation is supported, a primary channel and a backup channel are established. The primary channel achieves window content sharing through shared textures, while the backup channel transfers the window content through shared memory.

[0112] In an optional embodiment, the device 900 is applied to a content acquisition plugin that is independent of the second target application.

[0113] In an optional embodiment, the creation module 910 is further configured to: Create a mirror window in the process space of the first target application that is in the same position and size as the target window and is a layered window, and set the target window as the parent window of the mirror window.

[0114] In an optional embodiment, the device 900 is further used for: Listen for calls to the window rendering function; When the window rendering function is called and the caller is the first target application, the rendering parameters corresponding to the window rendering function are obtained, and the window rendering function is called based on the rendering parameters to update the content of the target window; Replace the window handle in the rendering parameters with the window handle of the mirrored window; The window rendering function is called again based on the replaced rendering parameters to synchronize the updated content of the target window to the mirror window.

[0115] Example 3 Figure 11 This illustration schematically depicts the hardware architecture of a computer device 10000 suitable for implementing a content acquisition method according to Embodiment 3 of this application. In some embodiments, the computer device 10000 may be a terminal device such as a smartphone, wearable device, tablet computer, personal computer, in-vehicle terminal, game console, virtual device, workbench, digital assistant, set-top box, or robot. In other embodiments, the computer device 10000 may be a rack server, blade server, tower server, or cabinet server (including standalone servers or server clusters composed of multiple servers), etc. Figure 11 As shown, the computer device 10000 includes, but is not limited to: a memory 10010, a processor 10020, and a network interface 10030 that can communicate and be linked with each other via a system bus. Wherein: The memory 10010 includes at least one type of computer-readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 10010 may be an internal storage module of a computer device 10000, such as the hard disk or memory of the computer device 10000. In other embodiments, the memory 10010 may also be an external storage device of the computer device 10000, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 10000. Of course, the memory 10010 may also include both the internal storage module and the external storage device of the computer device 10000. In this embodiment, the memory 10010 is typically used to store the operating system and various application software installed on the computer device 10000, such as program code for content acquisition methods. Furthermore, the memory 10010 can also be used to temporarily store various types of data that have been output or will be output.

[0116] In some embodiments, processor 10020 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other chip. Processor 10020 is typically used to control the overall operation of computer device 10000, such as performing control and processing related to data interaction or communication with computer device 10000. In this embodiment, processor 10020 is used to run program code stored in memory 10010 or process data.

[0117] Network interface 10030 may include a wireless network interface or a wired network interface, which is typically used to establish a communication link between computer device 10000 and other computer devices. For example, network interface 10030 is used to connect computer device 10000 to an external terminal via a network, establishing a data transmission channel and communication link between computer device 10000 and the external terminal. The network may be an intranet, the Internet, Global System for Mobile Communication (GSM), Wideband Code Division Multiple Access (WCDMA), 4G network, 5G network, Bluetooth, Wi-Fi, or other wireless or wired networks.

[0118] It should be pointed out that, Figure 11 Only computer devices with components 10010-10030 are shown; however, it should be understood that it is not required to implement all of the shown components, and more or fewer components may be implemented instead.

[0119] In this embodiment, the content retrieval method stored in memory 10010 can also be divided into one or more program modules and executed by one or more processors (such as processor 10020) to complete the embodiment of this application.

[0120] Example 4 This application also provides a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the steps of the content acquisition method in the embodiments.

[0121] In this embodiment, the computer-readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the computer-readable storage medium can be an internal storage unit of a computer device, such as the hard disk or memory of the computer device. In other embodiments, the computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device. Of course, the computer-readable storage medium can also include both the internal storage unit and the external storage device of the computer device. In this embodiment, the computer-readable storage medium is typically used to store the operating system and various application software installed on the computer device, such as the program code of the content acquisition method in the embodiment. In addition, the computer-readable storage medium can also be used to temporarily store various types of data that have been output or will be output.

[0122] Example 5 This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods described in the above embodiments.

[0123] Obviously, those skilled in the art should understand that the modules or steps of the embodiments of this application described above can be implemented using general-purpose computer devices. They can be centralized on a single computer device or distributed across a network of multiple computer devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computer device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the embodiments of this application are not limited to any particular combination of hardware and software.

[0124] It should be noted that the above are merely preferred embodiments of this application and do not limit the scope of patent protection of this application. Any equivalent structural or procedural changes made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of this application.

Claims

1. A content acquisition method, characterized in that, The method includes: A mirror window corresponding to the target window is created within the process space of the first target application, wherein the target window is a window in the first target application; Monitor the update operations of the first target application on the target window; When the target window is updated, the updated content of the target window is obtained, and the updated content is synchronously updated to the mirror window; Obtain the window content from the mirrored window and share or transfer the window content to the second target application.

2. The method according to claim 1, characterized in that, The window content is image data. The step of obtaining the window content from the mirrored window and sharing or transferring the window content to the second target application includes: Determine whether the creation of shared textures is supported; If supported, create a shared texture and write the image data into the shared texture; The image data is shared to the second target application via the shared texture.

3. The method according to claim 2, characterized in that, The method further includes: In cases where shared texture creation is not supported or fails, shared memory is created. The image data is copied to the shared memory so that the second target application can copy the image data from the shared memory for rendering.

4. The method according to claim 1, characterized in that, Before creating a mirror window corresponding to the target window within the process space of the first target application, the method further includes: Create a candidate window list and add windows in the system that meet preset conditions to the candidate window list; The candidate window list is continuously maintained, and invalid windows are removed from the candidate window list; The optimal window is determined from the candidate window list based on several window attributes. The target window is the current optimal window. The window attributes include the window name, the window stacking order, the window visibility status, and the window content update frequency.

5. The method according to claim 4, characterized in that, The method further includes: If the target window becomes invalid, the target window is removed from the candidate window list to obtain an updated candidate window list; Based on the aforementioned window attributes, a new optimal window is determined from the updated list of candidate windows, and the steps of creating a mirror window corresponding to the target window within the process space of the first target application and subsequent steps are executed.

6. The method according to claim 4, characterized in that, The method further includes: Check if the creation of shared textures is supported; When shared texture creation is supported, a primary channel and a backup channel are established. The primary channel achieves window content sharing through shared textures, while the backup channel transfers the window content through shared memory.

7. The method according to claim 1, characterized in that, Creating a mirror window corresponding to the target window within the process space of the first target application includes: Create a mirror window in the process space of the first target application that is in the same position and size as the target window and is a layered window, and set the target window as the parent window of the mirror window.

8. The method according to claim 7, characterized in that, The step of monitoring the first target application's update operations on the target window; and, when the target window is updated, acquiring the updated content of the target window and synchronously updating the mirror window with the updated content, includes: Listen for calls to the window rendering function; When the window rendering function is called and the caller is the first target application, the rendering parameters corresponding to the window rendering function are obtained, and the window rendering function is called based on the rendering parameters to update the content of the target window; Replace the window handle in the rendering parameters with the window handle of the mirrored window; The window rendering function is called again based on the replaced rendering parameters to synchronize the updated content of the target window to the mirror window.

9. The method according to claim 1, characterized in that, The method is applied to a content retrieval plugin, which is independent of the second target application.

10. A content acquisition device, characterized in that, The device includes: A creation module is used to create a mirror window corresponding to the target window within the process space of the first target application, wherein the target window is a window in the first target application; A listening module is used to listen for update operations of the first target application on the target window; The synchronization module is used to obtain the updated content of the target window when the target window is updated, and to synchronously update the updated content to the mirror window. The processing module is used to obtain window content from the mirrored window and share or transfer the window content to a second target application.

11. A computer device, characterized in that, include: At least one processor; and A memory communicatively connected to the at least one processor; wherein: The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 9.

13. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the method according to any one of claims 1 to 9.

Images