Multimodal input sports event data management and intelligent broadcasting device
By employing a multi-process software architecture and shared memory design, the high cost and latency issues of sports broadcasting systems have been resolved, enabling low-cost, low-latency multi-screen synchronous broadcasting. It supports real-time playback and picture-in-picture effects, enhancing the richness of event information presentation and production efficiency. In particular, it has achieved automated processing in coach gesture recognition.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING UNION UNIVERSITY
- Filing Date
- 2026-01-14
- Publication Date
- 2026-05-29
AI Technical Summary
Existing sports broadcasting systems are expensive, complex to operate, have high latency and poor flexibility. They cannot effectively integrate multiple information sources and achieve real-time playback and picture-in-picture effects, especially lacking automated processing in the recognition of coach gestures.
It adopts a multi-process software architecture and shared memory design, and coordinates multiple independent processes through a central event control module, including frame reading, display rendering and automated action execution modules, to achieve real-time response and synchronous display of multimodal input. It uses a circular frame buffer to ensure real-time playback and picture-in-picture effect, and completes background tasks through automated action execution modules.
It enables low-cost, low-latency, and highly flexible multi-screen simultaneous broadcasting, improving the richness of information presentation and production efficiency, and supporting automated processing of multimodal inputs such as coach gesture recognition.
Smart Images
Figure CN122120474A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of digital media processing technology, and in particular to a multimodal input sports event data management and intelligent broadcasting device. Background Technology
[0002] In the modern sports industry, high-quality broadcasting is the core bridge connecting events and viewers. A successful broadcast not only requires a clear and smooth presentation of the game, but also needs to enhance the viewing experience and convey in-depth information through rich visual elements such as real-time replays, picture-in-picture, data statistics, and highlight reels. Traditionally, achieving these complex broadcasting effects has relied heavily on expensive and complex professional hardware equipment, such as video switchers, special effects generators, and slow-motion replay servers. Operating this equipment requires experienced professional broadcasting teams to perform real-time, manual switching and compositing during the game. This model has many limitations: First, the high cost of hardware makes it unaffordable for small and medium-sized events or grassroots training; second, manual operation has high latency, making it impossible to respond quickly to instantaneous changes on the field and prone to operational errors; third, the system integration and flexibility are poor, and connecting to new data sources, such as real-time event signals from artificial intelligence analysis systems, often requires complex secondary development, making it difficult to achieve deep automated linkage.
[0003] With the improvement of computer performance and the development of software technology, it has become possible to realize professional broadcasting functions using general-purpose computing platforms. However, existing software solutions also face challenges. Single-threaded or traditional software architectures are prone to performance bottlenecks when simultaneously processing the decoding, rendering, compositing, and responding to external commands of multiple high-definition video streams, leading to problems such as screen stuttering and audio-visual desynchronization. How to design a low-cost and efficient software system architecture that can ensure the real-time and synchronous output of multiple video streams, flexibly respond to various external events, and automatically complete a series of background data processing tasks is a technical problem that urgently needs to be solved in this field. Especially in scenarios that require the dynamic and real-time fusion and presentation of various information such as match footage, data footage, and AI analysis results, existing technical solutions cannot provide a satisfactory, integrated solution.
[0004] Against this backdrop, existing technologies generally overlook a crucial information source on the field: coaches. In formal competitions like Jiu-Jitsu, coaches are not only issuers of tactical instructions, but their specific gestures towards the referee or technical table—such as raising their hands to indicate a point, an advantage, or a foul—are themselves authoritative key events in the competition. These instructive gestures are often highly correlated with official rulings and are important turning points signifying changes in the game's momentum. Compared to the chaotic and complex grappling movements of the two athletes on the field, the coach's behavior within a designated area, especially their standardized instructive gestures, is highly identifiable. Therefore, building a system that automatically "reads" the coach's behavioral language and uses it as an anchor point to index and segment video footage would open up a new, more efficient, and robust technological path for sports video analysis.
[0005] However, putting this concept into practice faces numerous challenges. While existing general object detection (such as the YOLO series), pose estimation (such as the YOLO-Pose series), and gesture recognition (such as MediaPipe) technologies are mature, how to organically, deeply, and specifically integrate them to form an end-to-end automated process from coach detection, pose understanding, intent judgment to video clip production remains an unresolved technical challenge. Specifically, how to ensure the recall and accuracy of coach detection in complex competition environments, how to accurately identify the coach's skeleton among multiple potential targets, how to accurately capture specific gestures with instructional intent at low computational cost while effectively filtering out everyday, meaningless body movements, and finally, how to seamlessly transform these recognition results into structured video clips with rich contextual information for analysis, are the technical barriers that urgently need to be overcome in this field.
[0006] Chinese patent application CN12012399A discloses a method for multimodal data fusion and analysis of sports events based on AI real-time feedback. This method acquires real-time multimodal data from multiple data sources, including video capture devices and audio sensors. After preprocessing, the data is input into a fusion analysis model to generate a fusion feature vector. A dynamic weight allocation algorithm is then used to obtain the target feature vector, which is input into a real-time feedback model to generate real-time analysis results. Finally, a classification model is used for label mapping. The drawbacks of this method are that it ignores the hardware integration and real-time rendering requirements in actual deployments, leading to computational bottlenecks and latency issues in complex event environments. Furthermore, it lacks a specific management mechanism for video frames, making it unable to achieve professional broadcast effects such as instant playback or picture-in-picture. It is suitable for data analysis rather than live streaming scenarios, and it does not consider a multi-process architecture to decouple I / O operations and rendering tasks, resulting in insufficient overall flexibility and robustness. Summary of the Invention
[0007] To address the aforementioned technical problems, this invention proposes a multimodal input sports event data management and intelligent broadcasting device. This device is based on a general-purpose computer platform and employs a multi-process software architecture. The invention aims to achieve professional-grade, automated, multi-screen, multi-content simultaneous broadcasting effects through innovative system design.
[0008] The purpose of this invention is to provide a multimodal input sports event data management and intelligent broadcasting device, including an intelligent control unit, an external input interface, and an external output interface.
[0009] The intelligent control unit is configured with: a central event control module, an automated action execution module, shared memory, at least one frame reading process, and at least two display rendering processes;
[0010] The central event control module is configured to receive event trigger signals from an external input interface;
[0011] The frame reading process is configured to continuously acquire raw video frames from the video input source, preprocess the raw video frames, and write the processed frame data into the shared memory.
[0012] The display rendering process is configured to respond to the frame synchronization signal issued by the central event control module, asynchronously read the specified version of frame data from the shared memory, and render the frame data to the corresponding external output interface using the graphics rendering engine; each display rendering process ensures synchronization across output screens through frame sequence numbers or timestamps.
[0013] Preferably, the external input interface is used to access at least one of the following inputs: manual scoring input, event signals from an external artificial intelligence analysis system, and event signals from an external optical character recognition system.
[0014] In any of the above schemes, it is preferred that the display rendering process includes at least one original image display process and one playback display process.
[0015] In any of the above schemes, it is preferred that when the central event control module receives the event trigger signal, it controls the behavior of the playback display process by modifying N status flag bits set in the shared memory, so that it switches from displaying the current real-time frame to displaying the historical frame sequence before the time when the trigger signal occurred, where N is a natural number.
[0016] In any of the above solutions, preferably, the automated action execution module is configured to perform at least one task, including:
[0017] Encode and save the historical frame sequence as a separate video file;
[0018] Upload the event data associated with the event trigger signal to a remote server;
[0019] This operation involves recording event data to a local data file.
[0020] In any of the above schemes, it is preferred that the shared memory also includes a frame status flag bit, which is set by the frame reading process after writing a new frame, and cleared by the display rendering process after reading the frame.
[0021] In any of the above schemes, it is preferred that the frame reading process is configured to generate a scaled-down version of the original video frame while writing the original video frame data, and also write the scaled-down version of the frame data into the shared memory area.
[0022] In any of the above solutions, preferably, the display rendering process further includes a picture-in-picture display process, wherein the picture-in-picture display process is configured as follows:
[0023] Display the original video frames when not triggered;
[0024] Upon receiving an event trigger signal, the scaled-down frame data and the historical frame sequence are simultaneously read from shared memory.
[0025] The scaled-down frame data is rendered in a preset corner of the screen, while the historical frame sequence is rendered in the main area of the screen.
[0026] In any of the above schemes, it is preferred that the shared memory further includes a circular frame buffer, and the frame reading process continuously stores historical frames within the most recent preset time window into the circular frame buffer;
[0027] The historical frame sequences to be displayed by the playback display process and the picture-in-picture display process are read directly from the circular frame buffer, rather than from local storage files.
[0028] In any of the above schemes, the playback display process is preferably configured to, after completing the playback of a historical frame sequence, respond to a control command and repeatedly play the most recently triggered historical frame sequence.
[0029] In any of the above schemes, it is preferred that the event trigger signal can be associated with a configurable playback duration parameter, and the central event control module calculates the starting point and length of the historical frame sequence to be played back in the circular frame buffer based on the duration parameter.
[0030] In any of the above solutions, it is preferred that the display rendering process uses the Pygame graphics rendering engine to render the screen and project it in full screen.
[0031] In any of the above schemes, it is preferred that the event data associated with the event trigger signal includes the live room ID, number of rounds, information of the two opposing teams, score details, and timestamps accurate to the second; and that the local data file saved by the automated action execution module is in CSV format.
[0032] This invention proposes a multimodal input sports event data management and intelligent broadcasting device. Through software definition, it achieves low-cost, low-latency, and highly flexible broadcasting effects for complex events, greatly improving the richness of information presentation and production efficiency. Attached Figure Description
[0033] Figure 1 This is a schematic diagram of the system architecture of a preferred embodiment of the multimodal input sports event data management and intelligent broadcasting device according to the present invention.
[0034] Figure 2 This is a schematic diagram of the logical structure of a shared memory region of a multimodal input sports event data management and intelligent broadcasting device according to the present invention.
[0035] Figure 3 This is a complete workflow diagram of one embodiment of the automated operation of a multimodal input sports event data management and intelligent broadcasting device according to the present invention. Detailed Implementation
[0036] The present invention will be further described below with reference to the accompanying drawings and specific embodiments.
[0037] Example 1
[0038] A multimodal input sports event data management and intelligent broadcasting device includes an intelligent control unit, an external input interface, and an external output interface.
[0039] The intelligent control unit is configured with: a central event control module, an automated action execution module, shared memory, at least one frame reading process, and at least two display rendering processes.
[0040] The central event control module is configured to receive event trigger signals from an external input interface.
[0041] When the central event control module receives the event trigger signal, it controls the behavior of the playback display process by modifying N status flags set in the shared memory, so that it switches from displaying the current real-time frame to displaying the historical frame sequence before the trigger signal occurred, where N is a natural number.
[0042] The automated action execution module is configured to perform at least one task, including:
[0043] Encode and save the historical frame sequence as a separate video file;
[0044] Upload the event data associated with the event trigger signal to a remote server;
[0045] This operation involves recording event data to a local data file.
[0046] The shared memory also includes a frame status flag. The frame reading process sets the flag after writing a new frame, and the display rendering process clears the flag after reading the frame.
[0047] The shared memory also includes a circular frame buffer, and the frame reading process continuously stores historical frames within the most recent preset time window into the circular frame buffer;
[0048] The playback display process is further configured to, after completing the playback of a historical frame sequence, respond to a control command and repeatedly play the most recently triggered historical frame sequence.
[0049] The frame reading process is configured to continuously acquire raw video frames from the video input source, preprocess the raw video frames, and write the processed frame data into the shared memory.
[0050] The frame reading process is configured to generate a scaled-down version of the original video frame while writing the original video frame data, and also write the scaled-down version of the frame data into the shared memory area.
[0051] The display rendering process is configured to respond to the frame synchronization signal issued by the central event control module, asynchronously read the specified version of frame data from the shared memory, and render the frame data to the corresponding external output interface using the graphics rendering engine; each display rendering process ensures synchronization across output screens through frame sequence numbers or timestamps.
[0052] The display rendering process includes at least one original image display process and one playback display process.
[0053] The display rendering process also includes a picture-in-picture display process, which is configured as follows:
[0054] Display the original video frames when not triggered;
[0055] Upon receiving an event trigger signal, the scaled-down frame data and the historical frame sequence are simultaneously read from shared memory.
[0056] The scaled-down frame data is rendered in a preset corner of the screen, while the historical frame sequence is rendered in the main area of the screen.
[0057] The historical frame sequences to be displayed by the playback display process and the picture-in-picture display process are read directly from the circular frame buffer, rather than from local storage files.
[0058] The event trigger signal can be associated with a configurable playback duration parameter. The central event control module calculates the starting point and length of the historical frame sequence to be played back in the circular frame buffer based on the duration parameter.
[0059] The display rendering process uses the Pygame graphics rendering engine to render the screen and project it in full screen.
[0060] The event data associated with the event trigger signal includes the live stream ID, round number, information of both sides, score details, and timestamps accurate to the second; the local data file saved by the automated action execution module is in CSV format.
[0061] The external input interface is used to access at least one of the following inputs: manual scoring input, event signals from an external artificial intelligence analysis system, and event signals from an external optical character recognition system.
[0062] The multimodal input sports event data management and intelligent broadcasting device provided by this invention adopts an integrated software and hardware design based on a general-purpose computer platform. Through a central event control module, automated action execution module, shared memory, and multiple processes (such as frame reading and display rendering) in the intelligent control unit, it achieves efficient video frame acquisition, preprocessing, asynchronous rendering, and output. It supports real-time response to multimodal inputs such as manual scoring, external AI analysis systems, and OCR event signals. For example, when receiving an event signal, it quickly switches to historical frame sequence playback by modifying the status flag in shared memory, rather than relying on pure algorithm fusion. This device also innovatively introduces a circular frame buffer to store the most recent historical frames, ensuring latency-free playback and replayability. Simultaneously, it automatically executes background tasks such as video encoding and saving, data uploading, and local CSV recording, enabling multi-screen synchronous broadcasting such as original picture, playback, and picture-in-picture modes, greatly improving the efficiency and viewing experience of event production. Furthermore, this invention emphasizes low-cost, low-latency general-purpose platform implementation, compatible with coach gesture recognition in specific sports such as Jiu-Jitsu.
[0063] Example 2
[0064] The purpose of this invention is to overcome the shortcomings of existing sports broadcasting systems, such as high cost, complex operation, low automation, and poor flexibility, and to provide a multimodal input sports data management and intelligent broadcasting device based on a general-purpose computer platform and implemented using a multi-process software architecture. This invention aims to achieve professional-grade, automatically responsive, multi-screen, multi-content simultaneous broadcasting effects through innovative system design.
[0065] The core of the technical solution proposed in this invention is a decoupled, multi-process collaborative architecture based on shared memory communication. This device decomposes complex broadcasting tasks into multiple independent processes with single responsibilities, thus avoiding performance bottlenecks caused by a single process being overloaded. Specifically, the device includes a core frame-reading process whose sole responsibility is to efficiently read raw video frames from the video source (on-site camera or local video file) and perform necessary preprocessing to generate a scaled-down image for the picture-in-picture window. The processed frame data is written in real-time to a pre-allocated shared memory accessible to all relevant processes. This design isolates the most I / O-intensive frame-reading operation, ensuring a stable acquisition of the data source.
[0066] The device also includes a set of parallel display rendering processes, each responsible for the output of one physical screen. These processes include original display, playback display, and picture-in-picture display processes, all characterized by reading data only from shared memory without performing any time-consuming I / O or complex calculations. A high-performance graphics engine (Pygame) renders the read frame data onto the screen. Through a sophisticated synchronization mechanism, setting a "frame ready" status flag in shared memory ensures that all display processes are rendering video content at the same timestamp, thus achieving strict synchronization of content across multiple screens.
[0067] The most innovative part of this device is its event response and automated processing mechanism. The device features a central event control module, acting as a command center responsible for listening for "event trigger signals" from various external sources. These signal sources can be manual scoring inputs from operators or standardized event messages sent by connected external intelligent analysis systems (such as a standalone AI coach recognition system or an OCR scoreboard recognition system). When the control module receives a trigger signal, it does not directly process the video; instead, it modifies a set of status flags in shared memory to "command" other processes to change their behavior. The central event control module sets a "enter playback mode" flag and writes the start frame information required for playback.
[0068] The playback and picture-in-picture processes continuously monitor these status flags. Once the "Enter Playback Mode" flag is activated, the display of live frames immediately stops, and a sequence of historical frames prior to the triggering event is read and played from a circular history frame buffer in shared memory. Since the historical frames are already stored in memory by the frame-reading process, this playback is instantaneous, requiring no file read latency, achieving true "instant playback." The picture-in-picture process performs a more complex compositing: a scaled-down version of the original image is rendered in a corner, while the playback image is rendered in the main area.
[0069] Simultaneously with triggering multi-screen display changes, the central event control module also activates a separate automated action execution module. This module is responsible for executing all non-real-time background tasks. Based on the detailed match data (live room ID, round, team, player, score, score type, time) accompanying the trigger signal, it extracts the corresponding replay video clip from the historical frame buffer, encodes it, and saves it as an MP4 file. Simultaneously, it uploads this match data to a designated remote server via a network API and appends it to a local CSV log file, achieving multiple backups and recording of the data. Separating these time-consuming I / O operations to an independent background module ensures the smooth operation of the foreground display process, unaffected by any disruptions.
[0070] The beneficial effects of this invention are as follows: Through an innovative multi-process and shared memory architecture, complex broadcasting tasks are highly decoupled, achieving high-performance, low-latency multi-channel video processing on general-purpose computers; through a standardized event triggering and state machine control mechanism, flexible access and automated response to multimodal inputs, including AI systems, are achieved; professional-grade broadcasting effects, including picture-in-picture, instant playback, and multi-screen synchronization, are achieved without the need for expensive dedicated hardware; and the video content production (playback segment saving) and data management (uploading and local recording) processes are fully automated, greatly improving the efficiency and accuracy of event production and analysis.
[0071] Example 3
[0072] like Figure 1 As shown, the core of the device of this invention consists of multiple independent processes that cooperate efficiently through shared memory. These processes mainly include: a frame reading process (P1), an original image display process (P2), a playback display process (P3), a picture-in-picture display process (P4), a central event control module (M1), and an automated action execution module (M2). All these processes share one or more pre-planned memory regions, namely shared memory (SM).
[0073] like Figure 2As shown, the logical structure of shared memory (SM) is the key to achieving high-performance data exchange in this invention. The shared memory is divided into several functional areas: the real-time frame data area (SM-A), which stores the latest frame of raw image data written by the frame reading process P1, as well as a corresponding scaled-down image data; the circular history frame buffer (SM-B), a first-in-first-out (FIFO) queue that continuously stores all video frames within the last 15 seconds, providing a data source for instant playback; the system status and control flag area (SM-C), containing a series of Boolean or integer variables, such as is_replaying, replay_start_index, replay_duration_secs, new_frame_ready, etc., used for inter-process status synchronization and control; and the event data area (SM-D), which temporarily stores detailed information related to triggering events received by the central event control module M1, { "live_room_id": "live_room_id_123", "round": "Round 2", "team": "Red Team", "player_a": "Player A", "player_b": "Player B", "scorer": "Coach's Score", "score": "2 points", "timestamp": "2025-6-1 16:30:45"}.
[0074] In the operation of this device, the frame reading process (P1) acts as the source of data acquisition, and it performs the following tasks in a loop: It reads a raw image frame from a camera or video file through the video capture interface (OpenCV's cv2.VideoCapture). The raw image undergoes two preprocessing steps: first, it is directly used as real-time frame data; second, a scaled-down version is generated, and its size is reduced to 1 / 4 of the original using cv2.resize for display in a picture-in-picture window. Then, P1 pushes both versions of the frame data, along with the current raw frame, into the tail of the circular history frame buffer (SM-B) (if the queue is full, the oldest frame at the head of the queue is pushed out). After all data is written, P1 sets the new_frame_ready flag to True and then enters a brief sleep or wait state to control the frame reading rate.
[0075] The original frame rate display process (P2), the replay frame rate display process (P3), and the picture-in-picture frame rate display process (P4) are parallel consumers. Each runs in an independent loop and initializes a full-screen display window using the Pygame engine. At the beginning of each loop, the `new_frame_ready` flag is checked. When the flag is True, new data is read. The original frame rate display process (P2) only reads the latest real-time frame data from SM-A and renders it to its own screen. The behavior of P3 and P4 is determined by status flags in SM-C. In the default state (`is_replaying` is False), P3 and P4 may behave the same as P2, or display a standby screen.
[0076] like Figure 3 This diagram illustrates the complete workflow of the present invention, from receiving an event trigger to completing all automated actions. The central event control module (M1) is a continuously listening entity, which can be a socket server waiting for messages on a specific network port, a daemon monitoring changes to a specific file, or an event handler responding to button clicks in a graphical user interface. When an event is triggered, such as an operator clicking the "Blue team scores 2 points" button (manual scoring) through a simple interface, or an independent AI analysis process sending a JSON-formatted event notification via socket, M1 immediately parses the event. The event information is: {"source": "manual", "team": "blue", "score": 2}, along with a playback duration selection, such as 8 seconds. M1 performs the following operations: First, it writes the complete event data to the SM-D area of shared memory. Then, based on the current frame rate and the selected 8-second playback duration, it calculates the index position in the circular history frame buffer SM-B from which playback should begin. For example, if the frame rate is 30fps, it rewinds 8*30=240 frames from 8 seconds ago. Write the calculated starting index to `replay_start_index` and the 8 seconds to `replay_duration_secs`. Finally, set the `is_replaying` flag to `True`.
[0077] The change in the `is_replaying` flag is immediately detected by the looping playback display process (P3) and picture-in-picture display process (P4). P3 immediately changes its data source, no longer reading the real-time frames of SM-A, but instead sequentially reading the frame sequence from the circular history frame buffer SM-B, starting 8 seconds before the trigger and ending 2 seconds after the trigger (a total of 10 seconds), based on `replay_start_index` and `replay_duration_secs`. These frames are then continuously rendered onto the screen, achieving a complete, normal-speed real-time playback. After a playback cycle, P3 can, depending on its settings, either stay on the last frame, automatically reset `is_replaying` to `False`, or wait for a new instruction to repeat the playback.
[0078] The picture-in-picture display process (P4) is more complex. When `is_replaying` is detected as True, the playback parameters are retrieved. A compositing operation is performed within the rendering loop: First, a scaled-down version of the real-time frame data is read from SM-A and drawn to the lower right corner of the screen using Pygame's `blit` method. Then, similar to P3, the playback frame sequence is read from SM-B, and each playback frame is blitted to the main area of the screen. Because all of this is done within the same rendering loop, the two display layers are perfectly synchronized, resulting in a professional-grade picture-in-picture playback effect.
[0079] While setting the status flags in M1, the automated action execution module (M2) is also activated. M2 can be a newly created child process to avoid blocking M1's response to new events. M2's task is to handle all time-consuming background tasks. First, it reads detailed event data from SM-D and copies all frame data required for this playback from SM-B. Then, it starts a video encoding process (using FFmpeg's Python bindings or command-line calls) to encode this frame data into an MP4 video file; the filename can be automatically generated based on the event information. Next, it constructs an HTTP POST request to send the event data (JSON format) to a preset remote server API address. Finally, it opens a local CSV file in append mode, formats the event data into a single line, and writes it to the file. After this series of operations is completed, the M2 process can safely exit.
[0080] Through this ingenious process decomposition and data flow design, the device of this invention completely separates the highly real-time video rendering task from the time-consuming and potentially blocking I / O task. By utilizing shared memory as a highly efficient "data transfer station," it achieves low-latency, high-bandwidth communication between the highly real-time video rendering task and the time-consuming and potentially blocking I / O task. The entire system can not only flexibly accept various inputs such as AI and manual input, but also automatically and in parallel complete the dual tasks of presenting complex multi-screen images and persisting background data. Thus, it reproduces and surpasses the intelligent broadcasting functions that traditionally require expensive hardware on general-purpose computing devices in a purely software-based manner.
[0081] To better understand this invention, specific embodiments have been described in detail above, but these are not intended to limit the invention. Any simple modifications made to the above embodiments based on the technical essence of this invention still fall within the scope of this invention. Each embodiment in this specification focuses on its differences from other embodiments; similar or identical parts between embodiments can be referred to mutually. For system embodiments, since they basically correspond to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.
Claims
1. A multimodal input sports event data management and intelligent broadcasting device, comprising an intelligent control unit, an external input interface, and an external output interface, characterized in that, The intelligent control unit is configured with: a central event control module, an automated action execution module, shared memory, at least one frame reading process, and at least two display rendering processes; The central event control module is configured to receive event trigger signals from an external input interface; The frame reading process is configured to continuously acquire raw video frames from the video input source, preprocess the raw video frames, and write the processed frame data into the shared memory. The display rendering process is configured to respond to the frame synchronization signal issued by the central event control module, asynchronously read the specified version of frame data from the shared memory, and render the frame data to the corresponding external output interface using the graphics rendering engine; each display rendering process ensures synchronization across output screens through frame sequence numbers or timestamps.
2. The multimodal input sports event data management and intelligent broadcasting device as described in claim 1, characterized in that, The external input interface is used to access at least one of the following inputs: manual scoring input, event signals from an external artificial intelligence analysis system, and event signals from an external optical character recognition system.
3. The multimodal input sports event data management and intelligent broadcasting device as described in claim 2, characterized in that, The display rendering process includes at least one original image display process and one playback display process.
4. The multimodal input sports event data management and intelligent broadcasting device as described in claim 3, characterized in that, When the central event control module receives the event trigger signal, it controls the behavior of the playback display process by modifying N status flags set in the shared memory, so that it switches from displaying the current real-time frame to displaying the historical frame sequence before the trigger signal occurred, where N is a natural number.
5. The multimodal input sports event data management and intelligent broadcasting device as described in claim 4, characterized in that, The automated action execution module is configured to perform at least one task, including: Encode and save the historical frame sequence as a separate video file; Upload the event data associated with the event trigger signal to a remote server; This operation involves recording event data to a local data file.
6. The multimodal input sports event data management and intelligent broadcasting device as described in claim 5, characterized in that, The shared memory also includes a frame status flag. The frame reading process sets the flag after writing a new frame, and the display rendering process clears the flag after reading the frame.
7. The multimodal input sports event data management and intelligent broadcasting device as described in claim 6, characterized in that, The frame reading process is configured to generate a scaled-down version of the original video frame while writing the original video frame data, and also write the scaled-down version of the frame data into the shared memory area.
8. The multimodal input sports event data management and intelligent broadcasting device as described in claim 7, characterized in that, The display rendering process also includes a picture-in-picture display process, which is configured as follows: Display the original video frames when not triggered; Upon receiving an event trigger signal, the scaled-down frame data and the historical frame sequence are simultaneously read from shared memory. The scaled-down frame data is rendered in a preset corner of the screen, while the historical frame sequence is rendered in the main area of the screen.
9. The multimodal input sports event data management and intelligent broadcasting device as described in claim 8, characterized in that, The shared memory also includes a circular frame buffer, and the frame reading process continuously stores historical frames within the most recent preset time window into the circular frame buffer; The historical frame sequences to be displayed by the playback display process and the picture-in-picture display process are read directly from the circular frame buffer, rather than from local storage files.
10. The multimodal input sports event data management and intelligent broadcasting device as described in claim 9, characterized in that, The playback display process is configured such that, after completing the playback of a historical frame sequence, it responds to a control command and repeatedly plays the most recently triggered historical frame sequence.