A method and device for recording screen scene data of an air traffic control automation system

Abstract

The application discloses a kind of air traffic control automation system screen scene data recording method and device, air traffic control automation system is deployed with FFmpeg multimedia processing framework, the method comprises: starting the first auxiliary thread of pre-set and carrying out video memory level screen scene data acquisition;The data collected includes the original screen pixel data of screen;Based on multithread parallel processing mechanism, the original screen pixel data collected is converted into the color coding format data of setting;Based on the second auxiliary thread of pre-set, the data after conversion is encoded into target video format in real time, and the data packet after encoding is persisted storage;Its beneficial effect is: the present application can significantly reduce the processing load of central processing unit, through multithread parallel processing mechanism, improve the overall efficiency of data transcoding and storage, effectively solve the delay problem caused by high code rate screen image processing, can support with high frame rate real-time acquisition and record the screen scene data of controller.

Description

Technical Field

[0001] This invention belongs to the field of air traffic control technology, specifically relating to a method and apparatus for recording screen image data of an air traffic control automation system. Background Technology

[0002] The recording of screen image data in the air traffic control automation system aims to collect and save the entire operation process of controllers on the human-machine interface in real time and accurately, so as to conduct precise review and in-depth analysis of possible abnormal events, operational errors or system problems in subsequent operations, thereby improving the safety and traceability of air traffic control operations.

[0003] In existing technical solutions, the recording of screen view data typically follows the following process:

[0004] According to the system's preset acquisition frame rate (such as several frames per second), each time all the pixel data displayed on the screen is copied from the video memory to the system memory, and then further copied from the kernel mode to the program buffer in the user mode; then, the pixel data of the current frame is compared pixel by pixel with all the pixel data acquired in the previous frame to identify the pixel areas that have changed; finally, the changed data is packaged, a local timestamp is attached, and then written to a file for storage.

[0005] However, the above technical solutions have the following significant drawbacks in actual high-resolution, high-frame-rate empty screen acquisition scenarios:

[0006] 1. Multiple memory copies lead to acquisition efficiency bottlenecks: Screen pixel data needs to go through two copy processes: “video memory → system memory → user-mode program”. When the screen resolution is high (such as 2K / 4K), the amount of data per frame is huge (for example, the RGB data per frame can reach about 48MB at 4K resolution). Frequent data copy operations will significantly increase the burden on the system bus and memory bandwidth, resulting in excessively long acquisition time per frame, making it difficult to meet the real-time acquisition requirements of high frame rates (such as ≥30fps).

[0007] 2. CPU computation bottleneck of pixel-by-pixel comparison: Existing solutions use full inter-frame pixel-by-pixel comparison to determine the screen change area; this operation relies entirely on the CPU to perform serial or limited parallel memory comparison operations; when the screen resolution increases and the number of pixels surges, the CPU needs to complete the comparison calculation of massive amounts of data in each frame cycle (for example, about 8 million pixels / frame at 4K resolution), which will seriously consume CPU resources and become the main delay node in the entire processing pipeline.

[0008] 3. Insufficient frame rate and loss of operation details: Due to the dual bottlenecks mentioned above (memory copy latency and CPU comparison overhead), the system often cannot stably reach the preset high frame rate. The decrease in the actual frame rate will cause some screen operation details of controllers (such as brief cursor movement, rapid clicks and instantaneous window response) to be missed in the recording, which will damage the integrity and coherence of the recorded data. Ultimately, it will not be able to provide accurate and reliable basis for subsequent problem review, operation audit or accident tracing, thereby weakening the practical application value of the screen recording system. Summary of the Invention

[0009] In view of the technical defects mentioned in the background art, the purpose of this invention is to provide a method and apparatus for recording screen scene data of an air traffic control automation system, aiming to at least partially solve one of the technical problems in the related art.

[0010] To achieve the above objectives, in a first aspect, the present invention provides a method for recording screen image data in an air traffic control automation system, wherein the air traffic control automation system is deployed with the FFmpeg multimedia processing framework, and the method includes:

[0011] The preset first auxiliary thread is started to collect screen scene data at the video memory level; the collected data includes the screen's raw pixel data.

[0012] The acquired raw screen pixel data is converted into a set color encoding format data based on a multi-threaded parallel processing mechanism;

[0013] The pre-defined second auxiliary thread encodes the converted data into the target video format in real time and persistently stores the encoded data packets.

[0014] As one specific implementation of this application, the process of acquiring video memory-level screen data specifically involves:

[0015] In the first auxiliary thread, according to the configured target frame rate, the display device input / output data acquisition interface of the FFmpeg multimedia processing framework is called to directly obtain the original screen pixel data from the GPU memory.

[0016] As a specific implementation of this application, during the acquisition process, the screen scene data is stored in the video memory in the form of frame data, and zero-copy transmission is achieved through the GPU and the underlying graphics interface of the operating system to avoid CPU intervention in data handling; at the same time, the second auxiliary thread is enabled.

[0017] As a specific implementation of this application, the step of converting the collected raw screen pixel data into a set color encoding format data based on a multi-threaded parallel processing mechanism is as follows:

[0018] The air traffic control automation system dynamically creates several worker threads in the main thread to form a thread pool;

[0019] Each worker thread calls FFmpeg's pixel format conversion interface in parallel to convert the collected raw screen pixel data into the set color encoding format data;

[0020] After the conversion is complete, the processed frame data is sent to the encoding queue for use by the second auxiliary thread.

[0021] As a specific implementation of this application, the step of encoding the converted data into the target video format in real time based on a preset second auxiliary thread, and persistently storing the encoded data packet, specifically involves:

[0022] The second auxiliary thread retrieves the converted frame data from the encoding queue;

[0023] In the second auxiliary thread, FFmpeg's hardware-accelerated codec interface is called to enable the hardware-accelerated encoder and encode the converted data into data packets of the target video format in real time.

[0024] The encoded data packets are written to disk files or pushed to network streams through FFmpeg's encapsulation interface, thus completing the persistent storage of screen data.

[0025] Secondly, the present invention also provides a recording device for screen image data of an air traffic control automation system, wherein the air traffic control automation system is deployed with the FFmpeg multimedia processing framework, and the device includes:

[0026] The data acquisition module is used to start a preset first auxiliary thread to acquire screen scene data at the video memory level; the acquired data includes the screen's raw pixel data.

[0027] The parallel conversion module is used to convert the acquired raw screen pixel data into a set color encoding format data based on a multi-threaded parallel processing mechanism.

[0028] The encoding and storage module is used to encode the converted data into the target video format in real time based on a preset second auxiliary thread, and to persistently store the encoded data packets.

[0029] The technical solution provided by the embodiments of the present invention has the following advantages:

[0030] 1. GPU-level capture and hardware-accelerated encoding based on FFmpeg: Fully utilize the GPU processing and hardware acceleration capabilities of the FFmpeg multimedia framework to capture screen data directly from video memory and call the hardware encoder for efficient compression; offload the heavy image capture and encoding tasks to the GPU, significantly reduce the processing load of the central processing unit, avoid system resource competition, and ensure the stable operation of air traffic control core services.

[0031] 2. High-efficiency parallel processing architecture based on multi-threading: By introducing a multi-threaded parallel processing mechanism, tasks such as pixel format conversion, video encoding, and data persistence are distributed to different working threads; through pipelined and parallel computing, the overall efficiency of data transcoding and storage is greatly improved, effectively solving the latency problem caused by high bitrate screen image processing;

[0032] 3. Supports high frame rate full-detail recording: Based on the GPU acceleration and multi-threaded architecture mentioned above, it can support real-time acquisition and recording of the controller's screen scene data at a high frame rate; the high frame rate recording capability ensures the complete retention of all operation details such as cursor trajectory, menu pop-up and window switching, avoiding frame skipping or loss of key scenes;

[0033] 4. Provides reliable evidence for safe operation and problem review: Complete, continuous and high-fidelity screen recording data can faithfully reproduce every step of the controller's operation during the human-machine interaction process; this provides accurate, objective and traceable visual evidence for the air traffic control system's event retrospective, operation audit, skills assessment and accident cause analysis, which is of great value to improving air traffic control operation safety and emergency response capabilities. Attached Figure Description

[0034] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the accompanying drawings used in the description of the specific embodiments or the prior art will be briefly introduced below.

[0035] Figure 1 This is a flowchart of a method for recording screen scene data in an air traffic control automation system provided in an embodiment of the present invention;

[0036] Figure 2 This is a schematic diagram of a process for acquiring video memory-level screen data provided in an embodiment of the present invention;

[0037] Figure 3 This is a schematic diagram of a multi-threaded parallel processing process provided in an embodiment of the present invention;

[0038] Figure 4 This is a schematic diagram of a real-time encoding process provided in an embodiment of the present invention;

[0039] Figure 5This is a schematic block diagram of a recording device for screen scene data of an air traffic control automation system provided in an embodiment of the present invention. Detailed Implementation

[0040] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0041] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0042] Throughout this specification, references to "an embodiment," "an example," or "an example" mean that a particular feature, structure, or characteristic described in connection with that embodiment or example is included in at least one embodiment of the invention. Therefore, the phrases "in an embodiment," "in an embodiment," "an example," or "an example" appearing in various places throughout the specification do not necessarily refer to the same embodiment or example. Furthermore, specific features, structures, or characteristics can be combined in one or more embodiments or examples in any suitable combination and / or sub-combination.

[0043] It should be noted that, unless otherwise stated, the technical terms used in this embodiment have the common meaning as understood in the relevant technical field.

[0044] Please refer to Figure 1 This invention provides a method for recording screen image data in an air traffic control automation system. The air traffic control automation system is equipped with the FFmpeg multimedia processing framework. The method includes:

[0045] S100, start the preset first auxiliary thread to collect screen scene data at the video memory level; the collected data includes the original screen pixel data of the screen;

[0046] S200, based on a multi-threaded parallel processing mechanism, converts the acquired raw screen pixel data into a set color encoding format data;

[0047] The S300 uses a preset second auxiliary thread to encode the converted data into the target video format in real time and persistently stores the encoded data packets.

[0048] When applying, refer to Figure 2The specific steps for performing screen data acquisition at the video memory level are as follows:

[0049] In the first auxiliary thread, according to the configured target frame rate, the display device input / output data acquisition interface of the FFmpeg multimedia processing framework (such as ddagrab on Windows platform, x11grab on Linux platform, and avfoundation on macOS) is called to directly obtain the original screen pixel data of the screen from the GPU memory.

[0050] During the acquisition process, the screen scene data is stored in the video memory in the form of frame data. The data is referenced through object handles or data pointers, thereby achieving zero-copy transfer and avoiding CPU intervention in data handling.

[0051] At the same time, the second auxiliary thread is activated to prepare the hardware encoder context and wait to receive the data to be encoded;

[0052] This process fully utilizes the GPU and the operating system's underlying graphics interface to achieve "zero-copy" data reading. Screen frames are always kept in video memory, avoiding CPU intervention in repeated memory copying operations, thereby significantly reducing the CPU's processing load.

[0053] When applying, refer to Figure 3 The process of converting the acquired raw screen pixel data into a set color encoding format based on a multi-threaded parallel processing mechanism is as follows:

[0054] The air traffic control automation system dynamically creates several worker threads in the main thread to form a thread pool;

[0055] Each worker thread calls FFmpeg's pixel format conversion interface (such as the sws_scale function in libswscale) in parallel to convert the collected raw screen pixel data into the set color encoding format data; for example, converting the raw RGB / BGR screen data into the specified color encoding format data (such as YUV420P, NV12).

[0056] After the conversion is complete, the processed frame data (AVFrame data) is sent to the encoding queue for use by the second auxiliary thread.

[0057] Since the screen content changes may be scattered, multi-threading can independently convert different macroblocks or frame segments, greatly improving the efficiency of data transcoding and reducing overall processing latency.

[0058] Furthermore, the second auxiliary thread, based on a preset parameter, encodes the converted data into the target video format in real time and persistently stores the encoded data packets, referring to... Figure 4 Specifically:

[0059] The second auxiliary thread retrieves the converted frame data from the encoding queue;

[0060] In the second auxiliary thread, FFmpeg's hardware-accelerated codec interface is called to enable hardware-accelerated encoders (such as NVIDIA NVENC, Intel QSV, AMD AMF, or macOS VideoToolbox) to encode the converted data into data packets of the target video format in real time; that is, FFmpeg's hardware-accelerated codec interface (such as h264_nvenc, h264_qsv, etc.) is called to compress video frames into AVPacket data packets of the target format (H.264 / H.265 / AV1) using GPU-dedicated encoding circuits.

[0061] The encoded data packets are written to disk files or pushed to network streams through FFmpeg's encapsulation interface (libavformat); persistent storage of screen data is completed; the hardware encoder offloads the heavy compression calculations to the GPU's dedicated circuitry, further reducing CPU usage and meeting the real-time requirements of high-resolution (2K / 4K) and high frame rate (≥30fps) recording.

[0062] In a specific implementation, an example is given using x11grab on a Linux platform with YUV420P as the conversion target format.

[0063] Screen image data acquisition

[0064] The air traffic control automation system starts its first auxiliary thread. In this thread, the FFmpeg device input context is first initialized, specifying the use of the x11grab device (the standard implementation of X11 screen capture in FFmpeg). The specific pseudocode is as follows:

[0065] Register all multimedia devices;

[0066] The search input format is "x11grab" (X11 screen capture);

[0067] Set the dictionary of acquisition parameters: {

[0068] Frame rate = "60";

[0069] Video size = "1920x1080";

[0070] Display capture area border = "0";

[0071] Enable shared memory extension (use_shm = "1" / / Used to improve capture efficiency

[0072] };

[0073] Open the input device (display device identifier: 0.0", input format, acquisition parameters) -> obtain the input context;

[0074] During the acquisition process, x11grab obtains screen pixel data from the X11 display server. With the `use_shm` option enabled, FFmpeg accesses screen data through X11's MIT-SHM (Mutual Memory Extension), avoiding the memory copying overhead from the X server to the client in the traditional `XGetImage()` method, thus achieving a certain degree of memory reuse. The frame format returned by x11grab is AV_PIX_FMT_BGR0 (i.e., 32-bit BGR format, 4 bytes per pixel, alpha channel 0), and the data resides in system memory. Example of a loop for receiving frames:

[0075] Allocate a frame buffer object;

[0076] Execute in a loop while (running status flag is true):

[0077] Read data packets from the input context;

[0078] If the read fails, exit the loop;

[0079] If the data packet size is greater than 0 and contains valid data:

[0080] Send the data packet to the decoder / unpacker;

[0081] Receive and process the unpacked raw frames (format BGR0);

[0082] Release the current data packet resources;

[0083] Simultaneously, a second auxiliary thread (encoding thread) is started, and the hardware encoder context is initialized. The specific implementation details are described in the subsequent section on hardware-accelerated encoding and persistence.

[0084] Parallel pixel format conversion

[0085] The air traffic control automation system uses Qt's QtConcurrent to create several worker threads in the main thread. It is recommended that the number of threads be equal to the number of CPU cores minus 1 (to reserve cores for data acquisition and encoding).

[0086] Each worker thread loops through the queue of frames to be converted; when an auxiliary thread acquires a frame, it places a reference to that frame into a thread-safe queue; the worker threads retrieve frames from the queue and call FFmpeg's sws_scale for format conversion. The raw frame format acquired by x11grab is BGR0 (32-bit BGR), which needs to be converted to YUV420P format to meet the requirements of most hardware encoders (such as NVENC). The conversion pseudocode is as follows:

[0087] Create a format conversion context (source format=BGR0, target format=YUV420P, scaling algorithm=bilinear interpolation);

[0088] Execute in a loop while (running status flag is true):

[0089] Retrieve raw frames (BGR0 format) from the thread-safe queue to be converted;

[0090] Allocate a memory buffer (format=YUV420P) for the target frame;

[0091] Call the format conversion interface (source frame data, target frame data) -> complete the conversion from BGR0 to YUV420P;

[0092] Push the converted target frame into the "converted frame queue";

[0093] Release the source frame reference;

[0094] Destroy the transition context;

[0095] After conversion, the processed dst_frame (YUV420P format) is sent to the encoding queue (also a thread-safe queue) for use by the second auxiliary thread; at the same time, the reference to the original frame is released (via av_frame_unref), and for sws_ctx that is no longer needed, sws_freeContext is called to release resources when the program exits.

[0096] Hardware-accelerated coding and persistence

[0097] The second auxiliary thread retrieves converted video frames (AVFrame, YUV420P format, located in system memory) from the encoding queue. First, it initializes the hardware encoder context. The following example uses NVIDIA NVENC:

[0098] Find the hardware encoder by name ("h264_nvenc");

[0099] If the hardware encoder is not found:

[0100] Backtrack to find the software encoder ("libx264");

[0101] Allocate encoder context;

[0102] Configure encoder basic parameters: {

[0103] Width and height = 1920 x 1080;

[0104] Pixel format = YUV420P;

[0105] Time base = 1 / 60;

[0106] Frame rate = 60;

[0107] GOP size = 12;

[0108] Maximum number of B frames = 2;

[0109] Mass parameter (qmin / qmax) = 23; / / Constant mass mode

[0110] };

[0111] Set encoder private parameters: {

[0112] Preset = "p4";

[0113] Tuning = "ll" (low latency);

[0114] };

[0115] Turn on the encoder;

[0116] The second auxiliary thread retrieves YUV420P format frames from the encoding queue and calls the encoding API for hardware-accelerated encoding:

[0117] Allocate data packet objects;

[0118] Execute in a loop while (running status flag is true):

[0119] Retrieve YUV420P format frames from the encoding queue;

[0120] Send the frame to the encoder;

[0121] The loop attempts to receive data packets from the encoder:

[0122] If the loop returns a "more data needed" or "end" status, then exit the inner loop.

[0123] If an error occurs, perform error handling and exit the program.

[0124] Set the stream index of the data packets;

[0125] Write the data packet to the wrapper (multiplexed write interface);

[0126] Release the current data packet resources;

[0127] The encoded data packets are written to a file using FFmpeg's wrapper interface (libavformat). First, an output context is created, a video stream is added, and a file header is written. Then, in the aforementioned hardware-accelerated encoding step using the encoding API, `av_interleaved_write_frame` is called repeatedly to write each data packet to the file. Finally, the file end is written.

[0128] Create an output context (file format="mp4", file name="screen_record.mp4");

[0129] Add a video stream and copy the encoder parameters to that video stream;

[0130] Open the output file handle (write-only mode);

[0131] Write file header information;

[0132] / / Note: This corresponds to the loop write operation in the previous steps.

[0133] Write end-of-file information;

[0134] Close the output file handle and release the output context.

[0135] The entire solution is based on the screen recording method of the FFmpeg multimedia processing framework, and efficiently completes the acquisition, format conversion and encoding storage of screen scene data through a multi-threaded parallel architecture.

[0136] The advantages of implementing the above plan are as follows:

[0137] 1. GPU-level capture and hardware-accelerated encoding based on FFmpeg: Fully utilize the GPU processing and hardware acceleration capabilities of the FFmpeg multimedia framework to capture screen data directly from video memory and call the hardware encoder for efficient compression; offload the heavy image capture and encoding tasks to the GPU, significantly reduce the processing load of the central processing unit, avoid system resource competition, and ensure the stable operation of air traffic control core services.

[0138] 2. High-efficiency parallel processing architecture based on multi-threading: By introducing a multi-threaded parallel processing mechanism, tasks such as pixel format conversion, video encoding, and data persistence are distributed to different working threads; through pipelined and parallel computing, the overall efficiency of data transcoding and storage is greatly improved, effectively solving the latency problem caused by high bitrate screen image processing;

[0139] 3. Supports high frame rate full-detail recording: Based on the GPU acceleration and multi-threaded architecture mentioned above, it can support real-time acquisition and recording of the controller's screen scene data at a high frame rate; the high frame rate recording capability ensures the complete retention of all operation details such as cursor trajectory, menu pop-up and window switching, avoiding frame skipping or loss of key scenes;

[0140] 4. Provides reliable evidence for safe operation and problem review: Complete, continuous and high-fidelity screen recording data can faithfully reproduce every step of the controller's operation during the human-machine interaction process; this provides accurate, objective and traceable visual evidence for the air traffic control system's event retrospective, operation audit, skills assessment and accident cause analysis, which is of great value to improving air traffic control operation safety and emergency response capabilities.

[0141] Reference Figure 5 This invention also provides a recording device for screen image data of an air traffic control automation system. The air traffic control automation system is equipped with the FFmpeg multimedia processing framework, and the device includes:

[0142] The data acquisition module is used to start a preset first auxiliary thread to acquire screen scene data at the video memory level; the acquired data includes the screen's raw pixel data.

[0143] The parallel conversion module is used to convert the acquired raw screen pixel data into a set color encoding format data based on a multi-threaded parallel processing mechanism.

[0144] The encoding and storage module is used to encode the converted data into the target video format in real time based on a preset second auxiliary thread, and to persistently store the encoded data packets.

[0145] Furthermore, the specific steps for performing screen data acquisition at the video memory level are as follows:

[0146] In the first auxiliary thread, according to the configured target frame rate, the display device input / output data acquisition interface of the FFmpeg multimedia processing framework is called to directly obtain the original screen pixel data of the screen from the GPU memory.

[0147] During the acquisition process, the screen scene data is stored in the video memory in the form of frame data, and zero-copy transfer is achieved through the GPU and the underlying graphics interface of the operating system to avoid CPU intervention in data handling; at the same time, the second auxiliary thread is enabled.

[0148] It should be noted that for a more detailed description of the working process of the device embodiments, please refer to the foregoing method embodiments section, which will not be repeated here.

[0149] The entire solution offloads the heavy image acquisition and encoding tasks to the GPU, significantly reducing the processing load on the central processing unit (CPU), avoiding system resource contention, and ensuring the stable operation of core air traffic control services. By introducing a multi-threaded parallel processing mechanism, it greatly improves the overall efficiency of data transcoding and storage, effectively solving the latency problem caused by high bitrate screen image processing. Based on GPU acceleration and multi-threaded architecture, it can support real-time acquisition and recording of controllers' screen image data at high frame rates (such as 30 frames per second and above), avoiding frame skipping or loss of critical images. This provides accurate, objective, and traceable visual evidence for event retrospective, operation auditing, skills assessment, and accident cause analysis in the air traffic control system.

[0150] In the embodiments provided in this application, it should be understood that the disclosed methods and apparatus can also be implemented in other ways. The method embodiments described above are merely illustrative. It should also be noted that in some alternative implementations, the functions marked in the boxes may occur in a different order than those marked in the drawings. In addition, the functional modules in the various embodiments of the present invention can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part. When each module is used, it collects and stores information only with the full authorization of the relevant user or organization and in compliance with relevant laws and regulations, and protects the security and privacy of the data, strictly prohibiting unauthorized access; the processing of data will be carried out within the scope of the law and will not exceed the authorized purpose and scope; at the same time, the authorizing party has the right to access, correct, delete, restrict processing, refuse, etc. of its personal data; and strictly abides by applicable laws and regulations and conducts compliance review.

[0151] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0152] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for recording screen view data in an air traffic control automation system, characterized in that, The air traffic control automation system deploys the FFmpeg multimedia processing framework, and the method includes: The preset first auxiliary thread is started to collect screen scene data at the video memory level; the collected data includes the screen's raw pixel data. The acquired raw screen pixel data is converted into a set color encoding format data based on a multi-threaded parallel processing mechanism; The pre-defined second auxiliary thread encodes the converted data into the target video format in real time and persistently stores the encoded data packets.

2. The method for recording screen scene data of an air traffic control automation system as described in claim 1, characterized in that, The specific steps for collecting screen image data at the video memory level are as follows: In the first auxiliary thread, according to the configured target frame rate, the display device input / output data acquisition interface of the FFmpeg multimedia processing framework is called to directly obtain the original screen pixel data from the GPU memory.

3. The method for recording screen scene data of an air traffic control automation system as described in claim 2, characterized in that, During the acquisition process, the screen scene data is stored in the video memory in the form of frame data, and zero-copy transfer is achieved through the GPU and the underlying graphics interface of the operating system to avoid CPU intervention in data handling; at the same time, the second auxiliary thread is enabled.

4. The method for recording screen scene data of an air traffic control automation system as described in claim 1, characterized in that, The process of converting the acquired raw screen pixel data into a set color encoding format based on a multi-threaded parallel processing mechanism is as follows: The air traffic control automation system dynamically creates several worker threads in the main thread to form a thread pool; Each worker thread calls FFmpeg's pixel format conversion interface in parallel to convert the collected raw screen pixel data into the set color encoding format data; After the conversion is complete, the processed frame data is sent to the encoding queue for use by the second auxiliary thread.

5. The method for recording screen scene data of an air traffic control automation system as described in claim 4, characterized in that, The second auxiliary thread, based on a preset parameter, encodes the converted data into the target video format in real time and persistently stores the encoded data packets. Specifically: The second auxiliary thread retrieves the converted frame data from the encoding queue; In the second auxiliary thread, FFmpeg's hardware-accelerated codec interface is called to enable the hardware-accelerated encoder and encode the converted data into data packets of the target video format in real time. The encoded data packets are written to disk files or pushed to network streams through FFmpeg's encapsulation interface, thus completing the persistent storage of screen data.

6. A recording device for screen image data in an air traffic control automation system, characterized in that, The air traffic control automation system is equipped with the FFmpeg multimedia processing framework, and the device includes: The data acquisition module is used to start a preset first auxiliary thread to acquire screen scene data at the video memory level; the acquired data includes the screen's raw pixel data. The parallel conversion module is used to convert the acquired raw screen pixel data into a set color encoding format data based on a multi-threaded parallel processing mechanism. The encoding and storage module is used to encode the converted data into the target video format in real time based on a preset second auxiliary thread, and to persistently store the encoded data packets.

7. The recording device for screen image data of an air traffic control automation system as described in claim 6, characterized in that, The specific steps for collecting screen image data at the video memory level are as follows: In the first auxiliary thread, according to the configured target frame rate, the display device input / output data acquisition interface of the FFmpeg multimedia processing framework is called to directly obtain the original screen pixel data of the screen from the GPU memory. During the acquisition process, the screen scene data is stored in the video memory in the form of frame data, and zero-copy transfer is achieved through the GPU and the underlying graphics interface of the operating system to avoid CPU intervention in data handling; at the same time, the second auxiliary thread is enabled.

8. The recording device for screen image data of an air traffic control automation system as described in claim 6, characterized in that, The process of converting the acquired raw screen pixel data into a set color encoding format based on a multi-threaded parallel processing mechanism is as follows: The air traffic control automation system dynamically creates several worker threads in the main thread to form a thread pool; Each worker thread calls FFmpeg's pixel format conversion interface in parallel to convert the collected raw screen pixel data into the set color encoding format data; After the conversion is complete, the processed frame data is sent to the encoding queue for use by the second auxiliary thread.

9. The recording device for screen image data of an air traffic control automation system as described in claim 8, characterized in that, The second auxiliary thread, based on a preset parameter, encodes the converted data into the target video format in real time and persistently stores the encoded data packets. Specifically: The second auxiliary thread retrieves the converted frame data from the encoding queue; In the second auxiliary thread, FFmpeg's hardware-accelerated codec interface is called to enable the hardware-accelerated encoder and encode the converted data into data packets of the target video format in real time. The encoded data packets are written to disk files or pushed to network streams through FFmpeg's encapsulation interface, thus completing the persistent storage of screen data.

Images