Distributed LED display screen collaborative management system and method

Abstract

The invention discloses a distributed LED display screen collaborative management system and method, and relates to the technical field of LED display screen control. According to the system, video stream data and equipment log data are monitored, a difference area and a static area are extracted, a high-dynamic display area is identified, a data packet is compressed, an equipment log is analyzed by using a long and short-term memory network, and a fault data packet is output. Different manufacturer device protocol header fields and parameter sets in the compressed data packet and the fault data packet are mapped into a unified standard operation code, a synchronization instruction set with a timestamp is generated, and a device node weight matrix is dynamically adjusted. And in combination with the synchronous instruction set and the node weight matrix, by taking the screen resolution, the node load and the task priority as state spaces, generating a task allocation matrix, reasonably allocating rendering node IDs, transmission paths and energy consumption constraint values, and outputting a delay tolerance threshold and a resource preemption rule. And the resource utilization rate, the fault response capability and the cooperative work efficiency of the LED display screen are improved.

Description

Technical Field

[0001] The present invention relates to the technical field of LED display screen control, and in particular to a distributed LED display screen collaborative management system and method. Background Art

[0002] With the rapid development of modern cities and business environments, LED displays, as an important carrier of information dissemination, are widely used in advertising, public services, traffic information and other fields. With their high brightness, long life and energy-saving advantages, they have become the preferred equipment for information display. Especially in large outdoor advertisements, car displays, and intelligent transportation systems, the application of LED displays is becoming more and more extensive. With the increasing diversification of display needs and the improvement of display quality requirements, how to improve the collaborative management efficiency of LED displays and ensure their efficient and stable operation has become an important issue that needs to be solved urgently.

[0003] Although there are many LED display management systems available, they have shortcomings in achieving data transmission and display content updates. Traditional display content updates and fault monitoring mechanisms often rely on centralized control, which makes it difficult to cope with the challenges of inconsistent protocols of different brands of equipment in a distributed environment, resulting in difficulties in coordination between devices. Existing resource scheduling methods mostly rely on static rules and cannot flexibly respond to real-time changes in equipment load and priority adjustments, resulting in low resource utilization and high latency. Existing systems have problems with bandwidth waste and large delays in the compression and transmission of video data, especially in the processing of highly dynamic display content, and cannot effectively respond to the requirements of efficient compression and high-quality display of video streams. Therefore, how to achieve efficient coordination, dynamic resource scheduling, and real-time fault detection among multiple devices remains a major challenge in LED display management systems. Summary of the invention

[0004] In view of the deficiencies in the prior art, the present invention provides a distributed LED display collaborative management system and method, which solves the problems of the above-mentioned background technology.

[0005] To achieve the above objectives, the present invention is implemented through the following technical solutions: a distributed LED display collaborative management system, comprising the following modules: an edge intelligent preprocessing module, a distributed protocol collaborative module, and a dynamic resource scheduling module; the edge intelligent preprocessing module is used to monitor the input video stream data and device log data of the LED display in real time, extract the difference area coordinate set and the static area identification code in the video stream through the dynamic area segmentation algorithm, identify the high dynamic display area, and compress the difference area to generate a data packet, and analyze the device log data through the long short-term memory network to output the fault data packet; the distributed protocol collaborative module maps the protocol header fields and parameter sets of devices from different manufacturers into standardized operation codes of a unified intermediate instruction set according to the compressed data packet and the fault data packet, generates a synchronization instruction set with timestamp sharding, and dynamically adjusts the node weight matrix of the associated device; the dynamic resource scheduling module is used to combine the synchronization instruction set and the node weight matrix, and use the screen resolution, node load and task priority as the state space to generate a task allocation matrix of rendering node ID, transmission path topology and energy consumption constraint value, and output real-time delay tolerance threshold and resource preemption rules.

[0006] Furthermore, the specific process of real-time monitoring of the input video stream data and device log data of the LED display screen is as follows: through the video acquisition interface deployed on the LED control terminal, the original video stream data is captured at a set rate and parsed into a frame sequence in a standard format; the device log data including temperature sensor data, power supply voltage fluctuation data and network communication packet loss rate data are synchronously collected and stored in the local cache queue after timestamp alignment.

[0007] Furthermore, the dynamic area segmentation algorithm is used to extract the difference area coordinate set and the static area identification code in the video stream, identify the high dynamic display area, and compress the difference area to generate a data packet. The specific process is as follows: through a comprehensive algorithm that combines the inter-frame difference method and the optical flow method, the pixel change amplitude between consecutive video frames is calculated, and the area with a change rate greater than the set threshold is marked as the difference area coordinate set; a hash code is generated for the static area as the static area identification code, which is only retransmitted when the full amount is updated; the difference area is encoded and adjusted with dynamic quantization parameters to generate a compressed data packet including the area ID, timestamp, and compression bit rate.

[0008] Furthermore, the device log data is analyzed by the long short-term memory network, and the specific process of outputting the fault data packet is as follows: the temperature sensor data, power supply voltage fluctuation data and network communication packet loss rate data are divided into time series segments according to the set time window, and input into the pre-trained long short-term memory network model; the fault data packet is output, which is the fault probability value and the list of associated device IDs, and it is judged whether the current device status is abnormal. When the fault probability value exceeds the set standard value, a fault data packet containing the device ID and fault type is generated.

[0009] Furthermore, according to the compressed data packet and the fault data packet, the specific process of mapping the protocol header fields and parameter sets of devices from different manufacturers into standardized operation codes of a unified intermediate instruction set is as follows: after receiving the compressed data packet and the fault data packet, the protocol header fields and parameter sets of protocols from different manufacturers are parsed; the protocol header fields include instruction type and length check code, and the parameter sets include brightness, contrast, and refresh rate; the preset mapping rules are matched through the protocol conversion smart contract library, and converted into standardized intermediate instructions containing operation codes, parameter values, and target device IDs, and the mapped operation codes are stored according to the protocol standardization requirements to form an instruction set.

[0010] Furthermore, the specific process of generating a synchronization instruction set with timestamp sharding and dynamically adjusting the node weight matrix of associated devices is as follows: based on a unified intermediate instruction set, each instruction is sharded by timestamp through the PBFT consensus algorithm, and a unique timestamp and hash check value are assigned to each shard to generate a timestamp shard synchronization instruction set; according to the list of associated device IDs in the fault data packet, based on the network topology and the coordination relationship between devices, the node weight matrix of each device is dynamically adjusted; according to the list of associated device IDs in the fault data packet, for devices whose fault probability value is greater than the set standard value, their voting weight in the consensus process is reduced to form a node weight matrix of device ID and corresponding voting weight.

[0011] Furthermore, in combination with the synchronization instruction set and the node weight matrix, the specific process of generating a task allocation matrix of rendering node ID, transmission path topology and energy consumption constraint value with screen resolution, node load and task priority as the state space is as follows: obtain the rendering node information in the synchronization instruction set and the weight of each device in the node weight matrix, take the screen resolution, node load and task priority as state space variables, build a multidimensional state space model, determine the task processing capability of each rendering node, and evaluate the load situation and priority of each rendering node; calculate the resource demand and load balancing status of each rendering node according to the node load information and task priority, build a network topology map, and determine the data flow and task transmission path; based on the node weight matrix, analyze the device energy efficiency, network bandwidth and delay between nodes, and allocate the task ID and transmission path topology of each rendering node in combination with the task type and priority; calculate the task allocation matrix in combination with the current network topology map and device energy efficiency data, generate the task ID, transmission path topology and energy consumption constraint value of each rendering node, ensure that each node will not exceed its energy consumption limit when allocating tasks, and thus generate the task allocation matrix of rendering node ID, transmission path topology and energy consumption constraint value.

[0012] Furthermore, the specific process of outputting real-time delay tolerance threshold and resource preemption rules is as follows: based on the rendering node ID, transmission path topology and energy consumption constraint value in the task allocation matrix, the delay tolerance threshold of each rendering node is determined by calculating the delay of each node during task execution; the delay tolerance threshold represents the maximum task execution delay time that the node can accept while ensuring display quality and user experience; the load status and task priority of each rendering node are analyzed, and the resource preemption rules of the node are determined in combination with the network bandwidth and node resource usage. The resource preemption rules include: dynamic adjustment according to the node's task priority and network transmission load. When the load of a node reaches a certain threshold, other nodes are allowed to preempt part of the node's resources to ensure that high-priority tasks are given priority.

[0013] A method for collaborative management of LED display screens based on distributed systems comprises the following steps: S1. real-time monitoring of input video stream data and device log data of LED display screens, extracting a set of coordinates of different regions and static region identification codes in the video stream through a dynamic region segmentation algorithm, identifying a high dynamic display region, compressing the different regions to generate data packets, and analyzing the device log data through a long short-term memory network to output a fault data packet; S2. compressing data packets and fault data packets, mapping protocol header fields and parameter sets of devices from different manufacturers into standardized operation codes of a unified intermediate instruction set, generating a synchronization instruction set with timestamp sharding, and dynamically adjusting a node weight matrix of associated devices; S3. combining the synchronization instruction set and the node weight matrix, taking screen resolution, node load and task priority as the state space, generating a task allocation matrix of rendering node ID, transmission path topology and energy consumption constraint value, and outputting a real-time delay tolerance threshold and resource preemption rules.

[0014] The present invention has the following beneficial effects: (1) A distributed LED display collaborative management system. The present invention uses an edge intelligent preprocessing module to monitor the input video stream data and device log data of the LED display in real time, and uses a dynamic region segmentation algorithm to extract the difference region coordinate set and static region identification code in the video stream, so as to effectively identify the high dynamic display area. Through the compression processing of the difference region, the burden of data transmission and processing is reduced, and the data transmission efficiency is improved. In addition, combined with the analysis of the device log data by the long short-term memory network, the fault data packet can be identified and output in time, and the real-time fault monitoring and early warning of the LED display can be realized, thereby improving the reliability and maintainability of the system. Through the distributed protocol collaboration module, the protocol header fields and parameter sets of devices from different manufacturers can be mapped to the standardized operation codes of the unified intermediate instruction set, which solves the problem of protocol incompatibility between devices from multiple manufacturers and realizes efficient collaboration and unified management of the system. At the same time, a synchronization instruction set with timestamp sharding is generated, and the node weight matrix of the associated devices is dynamically adjusted to ensure the synchronization and collaborative working ability between devices, and effectively avoid the display content inconsistency or delay caused by node failure or overload.

[0015] (2) A distributed LED display collaborative management method, combining synchronization instruction set and node weight matrix, uses information such as screen resolution, node load and task priority to intelligently allocate tasks and optimize the ID of rendering nodes, transmission path topology and energy consumption constraint value, thereby improving the resource utilization efficiency of the system, reducing energy consumption, and effectively avoiding delay problems in task scheduling. In addition, by outputting real-time delay tolerance thresholds and resource preemption rules, the system's adaptability and robustness are further enhanced, ensuring that the system can still maintain stable operation under high load conditions.

[0016] Of course, any product implementing the present invention does not necessarily need to achieve all of the advantages described above at the same time. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is a flow chart of a distributed LED display collaborative management system according to the present invention.

[0018] Figure 2 This is a flow chart of a distributed LED display screen collaborative management method according to the present invention. DETAILED DESCRIPTION

[0019] The embodiment of the present application solves the problems of poor interoperability of devices from different manufacturers, unbalanced system load, low task scheduling efficiency, and inaccurate energy consumption control through a distributed LED display collaborative management system and method. The efficient monitoring and compression processing of video stream data and device log data is realized through the edge intelligent preprocessing module, and the standardized protocol mapping and timestamp synchronization instruction set generation of the distributed protocol collaborative module are combined. Finally, the task allocation is optimized through the dynamic resource scheduling module to ensure load balancing of each rendering node, reasonable task priority, and accurate energy consumption control, thereby improving the display effect and system performance of the LED display, and enhancing its stability and reliability.

[0020] The overall idea of ​​the solution in the embodiments of this application is as follows: The input video stream data and device log data of the LED display are monitored in real time. The coordinate set of the difference area and the static area identification code in the video stream are extracted through the dynamic area segmentation algorithm, the high dynamic display area is identified, and the difference area is compressed to generate a data packet. At the same time, the device log data is analyzed through the long short-term memory network to output the fault data packet.

[0021] Compress data packets and fault data packets, map protocol header fields and parameter sets of devices from different manufacturers into standardized operation codes of a unified intermediate instruction set, generate a synchronization instruction set with timestamp sharding, and dynamically adjust the node weight matrix of associated devices.

[0022] Combining the synchronization instruction set and the node weight matrix, the screen resolution, node load and task priority are used as the state space to generate a task allocation matrix of rendering node ID, transmission path topology and energy consumption constraint value, and output real-time delay tolerance threshold and resource preemption rules.

[0023] See also Figure 1The embodiment of the present invention provides a technical solution: a distributed LED display collaborative management system, comprising the following modules: an edge intelligent preprocessing module, a distributed protocol collaborative module, and a dynamic resource scheduling module; the edge intelligent preprocessing module is used to monitor the input video stream data and device log data of the LED display in real time, extract the difference area coordinate set and the static area identification code in the video stream through the dynamic area segmentation algorithm, identify the high dynamic display area, and compress the difference area to generate a data packet, and analyze the device log data through the long short-term memory network to output the fault data packet; the distributed protocol collaborative module maps the protocol header fields and parameter sets of devices from different manufacturers to the standardized operation code of the unified intermediate instruction set according to the compressed data packet and the fault data packet, generates a synchronization instruction set with timestamp sharding, and dynamically adjusts the node weight matrix of the associated device; the dynamic resource scheduling module is used to combine the synchronization instruction set and the node weight matrix, and use the screen resolution, node load and task priority as the state space to generate a task allocation matrix of rendering node ID, transmission path topology and energy consumption constraint value, and output the real-time delay tolerance threshold and resource preemption rule.

[0024] In this implementation, the edge intelligent preprocessing module: The main task of this module is to monitor the input data of the LED display in real time, including video stream data and device log data. The specific workflow is as follows: Video stream data monitoring and processing: Dynamic region segmentation algorithm: This algorithm is used to analyze dynamically changing areas in video streams. Specifically, there will be different areas in the video stream, some of which may display content that changes frequently (for example, advertising areas), while some areas remain static (for example, backgrounds). The dynamic region segmentation algorithm can extract the coordinate sets of these difference areas to identify high-dynamic display areas. In this way, those areas with large changes can be processed efficiently without having to process every part of the entire screen indiscriminately. Static region identification code: This identification code is used to mark the static part of the video stream to avoid unnecessary data transmission and processing of areas that do not need to be updated, thereby saving bandwidth and computing resources. Differential region data compression: For dynamically changing areas, the edge intelligent preprocessing module will perform data compression processing on them, reduce the data volume, and generate data packets for efficient transmission. This can reduce the demand for bandwidth and latency. Device log data monitoring and processing: Long short-term memory network (LSTM): LSTM is a variant of recurrent neural network (RNN) that is good at processing sequence data, especially for time series prediction and anomaly detection. This network is used to analyze device log data, identify the operating status of the device, and predict potential failures. By training the LSTM model, it is possible to detect possible equipment failures and output fault data packets when an abnormality is found for subsequent processing. This module not only optimizes data transmission and processing efficiency by accurately monitoring video streams and device status data, but also monitors device status in real time, identifies potential failures in advance, and ensures the stability and reliability of the system. Distributed protocol collaboration module: The core function of this module is to coordinate the protocols of devices from different manufacturers to ensure that different hardware can work in a unified and collaborative manner. Its specific operation process includes: Protocol header field and parameter mapping: Due to the existence of devices from different manufacturers on the market, the communication protocols of these devices may not be exactly the same. This module maps the protocol header field and parameter set of each device into a unified intermediate instruction set. Through this standardized operation, the system can achieve seamless docking across manufacturers and device platforms. Timestamp slicing synchronization instruction set generation: Timestamp slicing: The content of the display screen is usually dynamically changing. In order to ensure content consistency and real-time performance, the system divides the content into small time segments (usually 10ms) according to the timeline, and each time segment has a unique timestamp. In this way, the instruction set can accurately synchronize the content display on different nodes to avoid inconsistent display content due to delays or synchronization problems. Node weight matrix adjustment: In a distributed system, different device nodes may have different performances (such as processing power, bandwidth, load, etc.), so it is necessary to dynamically adjust the weights of each device node to ensure that tasks can be assigned to the most appropriate device. This module adjusts the node weight matrix so that the system can adaptively respond to different device performance changes.Function: This module realizes the protocol compatibility of cross-manufacturer devices, ensures the efficient cooperation of various devices, and ensures the synchronization and stability of data and tasks through timestamp and weight adjustment. Dynamic resource scheduling module: This module is responsible for dynamically scheduling computing and transmission tasks according to the actual operation status of the system to ensure the stable operation of the system under different load conditions. Its specific operation process is as follows: Multidimensional state space: Screen resolution, node load and task priority: These factors together constitute the state space of the system. The screen resolution determines the fineness of the displayed content, the node load reflects the processing power of the device, and the task priority determines the urgency of task processing. Combining these factors to construct a multidimensional state space model helps to determine the task allocation and resource utilization of each node. Task allocation of rendering node ID, transmission path topology and energy consumption constraint value: Task allocation matrix: According to the state space model, the system can optimize the allocation of tasks according to the computing power, network bandwidth and other resources of each node. The task allocation matrix specifies the ID, data transmission path and energy consumption constraint of each rendering node to ensure the rationality of task allocation and avoid the system from being overloaded or consuming too much energy. This module optimizes the system's resource scheduling and task allocation, avoiding delays or energy efficiency issues caused by excessive task concentration or uneven resource allocation, thereby improving the efficiency and stability of the system.

[0025] Specifically, the specific process of real-time monitoring of the input video stream data and device log data of the LED display screen is as follows: through the video acquisition interface deployed on the LED control terminal, the original video stream data is captured at a set rate and parsed into a frame sequence in a standard format; the device log data including temperature sensor data, power supply voltage fluctuation data and network communication packet loss rate data are synchronously collected, and stored in the local cache queue after timestamp alignment.

[0026] In this embodiment, the video stream data is an image sequence collected and transmitted in real time by the LED display control terminal. In order to monitor and process the display effect of the LED display in real time, the original video stream data must be captured from the control terminal at a set rate. Here, "set rate" refers to the acquisition frequency of the video frame, that is, how many frames of data are captured by the control terminal per second. The video acquisition interface usually adopts an efficient video transmission protocol, such as RTSP, HLS, etc., to ensure efficient data transmission. Video frame parsing: The captured original video stream data is a sequence of multiple video frames (i.e., images). The original data format is usually a compressed format (H.264, H.265), so it needs to be decoded into a standard format (YUV format or RGB format) before further processing. This decoding process can be performed by a video decoder. After parsing into a frame sequence in a standard format, the video data can be further processed and analyzed, such as extracting and compressing the difference area in the video through a dynamic area segmentation algorithm. This standard format frame sequence facilitates subsequent data analysis and processing. Synchronous acquisition and storage of device log data: The device log data includes a variety of sensor data and status information, which reflects the operating environment and status of the LED display. Common device log data include: Temperature sensor data: monitor the working environment temperature of the LED display screen to avoid equipment failure due to overheating. Power supply voltage fluctuation data: used to monitor the stability of the power supply voltage. Voltage fluctuation may cause unstable operation or damage to the device. Network communication packet loss rate data: reflects the packet loss of the device during network communication. Too high a packet loss rate may affect the real-time and accuracy of the displayed content. These device log data are usually collected by sensors or monitoring modules to reflect the operating status of the device in real time. Timestamp alignment and storage: Since the video stream data and device log data come from different sensors and modules, their acquisition time may be different, so they need to be aligned through timestamps. Timestamp is a time mark for data recording, which can ensure that data from different data sources are consistent at the same time point, which is convenient for subsequent analysis. The specific alignment process is as follows: A precise timestamp is attached to each video frame and device log data. A synchronization mechanism is used to match the video stream data and device log data according to the timestamp, that is, to ensure that the device log data corresponding to each video frame is at the same time. The data aligned by timestamp will be stored in the local cache queue, which is used to temporarily store these data for further analysis by the subsequent processing module. The local cache queue is a circular buffer that ensures fast access to data when real-time data flows in. The cache queue usually has a fixed size, and when the amount of data reaches a certain threshold, the oldest data will be automatically overwritten to ensure efficient use of memory resources.

[0027] Specifically, the dynamic area segmentation algorithm is used to extract the difference area coordinate set and the static area identification code in the video stream, identify the high dynamic display area, and compress the difference area to generate a data packet. The specific process is as follows: through a comprehensive algorithm that combines the inter-frame difference method and the optical flow method, the pixel change amplitude between consecutive video frames is calculated, and the area with a change rate greater than the set threshold is marked as the difference area coordinate set; a hash code is generated for the static area as the static area identification code, which is only retransmitted when the full amount is updated; the difference area is encoded and adjusted with dynamic quantization parameters to generate a compressed data packet including the area ID, timestamp, and compression bit rate.

[0028] In this implementation scheme, the inter-frame difference method and the optical flow method are integrated: Inter-frame difference method: This method calculates the difference of each pixel by comparing two consecutive frames of video images, and the area with larger changes is marked as the difference area. Optical flow method: This method determines the motion information of the image based on the motion vector of each pixel (that is, the moving direction and speed of the pixel). For moving objects, the optical flow method can better capture its motion pattern, thereby more accurately marking the dynamic area. The core idea of ​​the comprehensive algorithm that combines these two methods is to calculate the change amplitude of each pixel between two consecutive frames. Calculate the motion vector of each pixel, and combine the change amplitude to determine which areas have changed significantly and mark them as dynamic areas. Generation of difference area coordinate set: For the difference area between consecutive video frames, the part whose change rate is greater than the set threshold will be marked as the difference area coordinate set. ,in Indicates the pixel coordinates within the difference area. The specific judgment formula is as follows: ;in: It's time Moment Image In coordinates The pixel value of is the change threshold; Indicates that the pixel is at time If Greater than threshold , then the pixel is marked as a difference area. Generation of static area identification code: Static areas refer to areas with very small changes in multiple video frames. These areas can be identified by hash coding. In the processing of static areas, data needs to be retransmitted only when the screen is fully updated. A hash algorithm is used to generate a hash code for each static area. , the formula is as follows: ;in: It is an image block or region of a static area; It is a static region identification code generated by a hash algorithm. For the compression of the difference region data, dynamic quantization parameter adjustment is used to reduce the amount of data transmitted. The compression process is adjusted according to the change range of the region and the preset quantization parameter.

[0029] Specifically, the device log data is analyzed by the long short-term memory network at the same time, and the specific process of outputting the fault data packet is as follows: the temperature sensor data, power supply voltage fluctuation data and network communication packet loss rate data are divided into time series segments according to the set time window, and input into the pre-trained long short-term memory network model; the fault data packet is output, which is the fault probability value and the list of associated device IDs, and it is judged whether the current device status is abnormal. When the fault probability value exceeds the set standard value, a fault data packet containing the device ID and fault type is generated.

[0030] In this implementation scheme, data segmentation and input: The device log data contains three aspects of information: temperature sensor data, power supply voltage fluctuation data, and network communication packet loss rate data. These data need to be segmented according to the set time window, and the log data in each time window is input into the LSTM model as a time series segment. The input data of each time series segment, each of which includes: temperature sensor data at time. Power supply voltage fluctuation data at time. : Network communication packet loss rate data at time. These data are used as input to LSTM, and the LSTM network will analyze the long-term dependencies in these time series data through its internal memory mechanism. The formula for the fault probability value is: is the time step The input data set is , , Represent the numerical characteristics of temperature, voltage fluctuation and packet loss rate respectively. The output of the LSTM network is a hidden state , and the failure probability value is based on the hidden state of the current time step The formula is as follows: ; Parameter explanation: :Time step The LSTM hidden state represents the model’s memory of the device status at the current time point. :Time step The hidden state represents the influence of historical information (device status at the last moment) on the current judgment. :Current time Device data input includes temperature, voltage fluctuation, and packet loss rate characteristics. : Weight matrix, representing the current hidden state Contribution to the probability of failure. : Weight matrix, representing the hidden state at the previous moment Contribution to the probability of failure. : Weight matrix, representing input features (Equipment log data) contribution to the probability of failure. : Bias term, used to adjust the output value. : Sigmoid activation function, used to convert the linear combination result into a probability value, ranging from [0,1]. In addition to generating a fault data packet, the system also outputs a list of device IDs related to the fault, indicating other devices related to the current device fault. These devices can be devices in the network that are directly associated with the faulty device. The generation of the associated device list depends on the communication relationship between the devices and the type of fault.

[0031] Specifically, according to the compressed data packet and the fault data packet, the specific process of mapping the protocol header fields and parameter sets of devices from different manufacturers into standardized operation codes of a unified intermediate instruction set is as follows: after receiving the compressed data packet and the fault data packet, the protocol header fields and parameter sets of protocols from different manufacturers are parsed; the protocol header field includes the instruction type and the length check code, and the parameter set includes brightness, contrast, and refresh rate; the preset mapping rules are matched through the protocol conversion smart contract library, and converted into standardized intermediate instructions containing operation codes, parameter values, and target device IDs, and the mapped operation codes are stored according to the protocol standardization requirements to form an instruction set.

[0032] In this implementation scheme, receiving data packets: after the system receives compressed data packets and fault data packets, the data must first be parsed. The compressed data packet contains the difference area of ​​the image data, while the fault data packet contains the fault information of the device. Both carry the protocol header fields and parameter sets of devices from different manufacturers. Parsing protocol header fields and parameter sets: Protocol header fields: The protocol header is the control information used to define the data format in the instruction transmission, including: Instruction type: Indicates the operation type of the current data packet, such as image data update, device status check, etc. Length check code: Used to verify whether the transmitted data is complete and valid to ensure the reliability of data transmission. Parameter set: The parameter set contains specific device control information, such as: Brightness: Indicates the brightness control parameters of the LED display. Contrast: Controls the contrast of the display. Refresh rate: The frequency at which the display updates the image. Protocol conversion smart contract library: In order to ensure that devices from different manufacturers can communicate with each other, the protocol fields of different manufacturers must be uniformly converted. This process is achieved through the protocol conversion smart contract library. The smart contract library stores the mapping rules of device protocols from different manufacturers. The main purpose is to convert the manufacturer-specific protocol header fields and parameter sets into standardized operation instructions. Convert to standardized opcodes: Using the mapping rules in the protocol conversion smart contract library, the protocol fields of each manufacturer's device (such as instruction type, brightness, contrast, etc.) can be converted into unified standardized intermediate instructions. These standardized instructions include: Opcode: This is the core part of the instruction, which defines the specific operation to be performed. For example, adjust the brightness, update the refresh rate, etc. Parameter value: The specific parameter value corresponding to the opcode, such as the brightness value, the contrast ratio, etc. Target device ID: Determine which device needs to perform this operation. Store the instruction set: The mapped opcode, parameter value and target device ID are stored according to the protocol standardization requirements to form the final instruction set. This instruction set is a standardized command that can be understood and executed by devices from various manufacturers, ensuring that all devices in the system can work together without being affected by differences between manufacturers.

[0033] Specifically, the specific process of generating a synchronization instruction set with timestamp sharding and dynamically adjusting the node weight matrix of associated devices is as follows: based on a unified intermediate instruction set, each instruction is sharded by timestamp through the PBFT consensus algorithm, and a unique timestamp and hash check value are assigned to each shard to generate a timestamp shard synchronization instruction set; according to the list of associated device IDs in the fault data packet, based on the network topology and the coordination relationship between devices, the node weight matrix of each device is dynamically adjusted; according to the list of associated device IDs in the fault data packet, for devices whose fault probability value is greater than the set standard value, their voting weight in the consensus process is reduced to form a node weight matrix of device ID and corresponding voting weight.

[0034] In this implementation scheme, the node weight matrix of associated devices is dynamically adjusted: Based on the list of associated device IDs in the fault data packet, the system will dynamically adjust the node weight matrix of the device according to the network topology and the coordination relationship between the devices. The node weight matrix defines the voting weight of each node (i.e., device) in the consensus process. The purpose of adjusting the weight matrix is ​​to ensure that the faulty device does not affect the normal operation of the system during the consensus process. Specific steps: Device ID list: Extract the ID list of the faulty device from the fault data packet. Network topology and coordination relationship: The system evaluates the importance of the device based on the network topology and coordination relationship between the devices. Factors such as the connection quality, latency, and bandwidth between devices may affect the weight of the device in the consensus process. Dynamically adjust the weight: For devices whose failure probability values ​​exceed the set standard value, reduce their voting weight in the consensus process. Specifically, the voting weight of the faulty device will be adjusted according to the difference between its failure probability and the set standard value. The higher the failure probability value, the lower the voting weight. Formula representation: Device The failure probability is The fault standard value is set to ,equipment The initial voting weight is , then the adjusted voting weight It can be expressed as: in: Yes Equipment Initial voting weight; Yes Equipment The failure probability value; is the set fault standard value; It is the influence factor of the failure probability on the weight adjustment, which controls the influence of the failure probability on the weight; is the adjusted device voting weight. Generate node weight matrix: Through the above adjustment, the final node weight matrix W is a matrix composed of the device IDs of all devices and the corresponding adjusted voting weights. Assuming there are N devices, the node weight matrix can be expressed as: ;in: represents the ith device ID, Indicates the device The adjusted voting weight.

[0035] Specifically, the specific process of generating a task allocation matrix of rendering node ID, transmission path topology and energy consumption constraint value by combining the synchronization instruction set and the node weight matrix and taking the screen resolution, node load and task priority as the state space is as follows: obtaining the rendering node information in the synchronization instruction set and the weight of each device in the node weight matrix, taking the screen resolution, node load and task priority as state space variables, constructing a multidimensional state space model, determining the task processing capability of each rendering node, and evaluating the load situation and priority of each rendering node; calculating the resource demand and load balancing status of each rendering node according to the node load information and task priority, constructing a network topology diagram, and determining the data flow and task transmission path; analyzing the device energy efficiency, network bandwidth and delay between nodes based on the node weight matrix, and assigning the task ID and transmission path topology of each rendering node in combination with the task type and priority; calculating the task allocation matrix in combination with the current network topology diagram and the device energy efficiency data, generating the task ID, transmission path topology and energy consumption constraint value of each rendering node, ensuring that each node does not exceed its energy consumption limit when assigning tasks, thereby generating a task allocation matrix of rendering node ID, transmission path topology and energy consumption constraint value.

[0036] In this implementation scheme, the data in the synchronization instruction set and the node weight matrix are obtained: the system needs to extract the relevant information of the rendering node from the synchronization instruction set, including the identification (such as ID) of each rendering node and its corresponding node weight. At the same time, the weight of each device is obtained from the node weight matrix, and these weights reflect the importance or influence of the device in the task execution. Construct a multidimensional state space model: the system uses screen resolution, node load, and task priority as state space variables to construct a multidimensional state space model. This model can describe the state of different nodes under different conditions. The task processing capacity, load status, and priority of each rendering node under different conditions will affect its state, thereby affecting the allocation of tasks. The screen resolution indicates the complexity of the rendering task. The higher the resolution, the greater the rendering calculation amount and the heavier the node load. The node load indicates the number of tasks and computing pressure that the current node is undertaking. The task priority indicates the importance and urgency of the task. The higher the priority, the task needs to be processed as soon as possible. Compute the resource requirements and load balancing status of the node: based on the node load information and task priority, the system calculates the resource requirements of each rendering node. This includes factors such as the number of tasks currently carried by each node, computing resource requirements, network bandwidth, and the priority of the task. The greater the node load, the higher the resource consumption of the node, and the ability to process tasks may be limited. High-priority tasks should be assigned to nodes with more sufficient resources. Build a network topology map: The system builds a network topology map and analyzes the connection relationship, bandwidth and latency between rendering nodes. By analyzing the transmission path between devices, the system can optimize the route of data flow and task allocation to avoid bottlenecks. Analyze device energy efficiency, network bandwidth and inter-node latency: Based on the node weight matrix, the system analyzes the energy efficiency, network bandwidth and inter-node latency of each device. Devices with high energy efficiency are suitable for high-load tasks, while devices with low latency are more suitable for tasks that require fast response. Task allocation and transmission path planning: The system allocates task IDs and transmission path topologies to rendering nodes based on task type, priority and node resource requirements. For each task, the system calculates the best task allocation plan based on the current network topology map and device energy efficiency data. Calculate the task allocation matrix and energy consumption constraint value: While allocating tasks, the system needs to calculate the energy consumption constraint value of each rendering node to ensure that task allocation does not cause the node's energy consumption to exceed the limit. The task allocation of each node is optimized based on its energy efficiency, bandwidth and latency to maximize the efficiency of the entire system. Formula: Representation of the task allocation matrix: The task allocation matrix A determines whether task e is assigned to node q. If task e is assigned to node q, then ,otherwise Load balancing constraints ensure that the load of each node will not be overloaded, that is, the total amount of tasks processed by each node cannot exceed its load capacity. For each node q, the load constraint is: ;in: Represents the processing power required for task e is the maximum load capacity of node q. The energy efficiency constraint ensures that the energy consumption of each node does not exceed its energy efficiency limit. For each node q, the energy efficiency constraint is: ;in: represents the energy efficiency requirement of task e; is the energy efficiency constraint value of node q. Bandwidth and delay constraints ensure that the performance of task transmission is not limited by network bandwidth or delay. There are two specific constraints: bandwidth constraint requires that the transmission bandwidth requirement of each task cannot exceed the network bandwidth. For each task e, the bandwidth constraint is: ;in: is the bandwidth between node q and node e; is the bandwidth requirement of task e. The delay constraint ensures that the transmission delay of the task does not exceed the maximum tolerable delay. For each task e, the delay constraint is: ;in: is the delay between node q and node e; is the maximum tolerance of task e for delay.

[0037] Specifically, the specific process of outputting real-time delay tolerance threshold and resource preemption rules is as follows: based on the rendering node ID, transmission path topology and energy consumption constraint value in the task allocation matrix, the delay tolerance threshold of each rendering node is determined by calculating the delay of each node during task execution; the delay tolerance threshold represents the maximum task execution delay time that the node can accept while ensuring display quality and user experience; the load status and task priority of each rendering node are analyzed, and the resource preemption rules of the node are determined in combination with the network bandwidth and node resource usage. The resource preemption rules include: dynamic adjustment according to the node's task priority and network transmission load. When the load of a node reaches a certain threshold, other nodes are allowed to preempt part of the node's resources to ensure that high-priority tasks are given priority.

[0038] In this implementation scheme, the delay tolerance threshold is calculated: the delay tolerance threshold refers to the maximum task execution delay that the node can accept while ensuring display quality and user experience. The delay tolerance threshold of each rendering node is closely related to the delay in its task execution. Excessive delay will affect the display effect and user experience, so each node needs to have an acceptable delay tolerance range. The delay incurred by each node in the process of executing the task can be calculated through the rendering node information, transmission path topology and energy consumption constraint value in the task allocation matrix. When calculating specifically, the factors considered include: Task size: the computational complexity and data volume of the task. Transmission path delay: the time it takes for data to be transmitted in the network. Node processing delay: the processing power of the node itself and the delay during task execution. Calculation of the task allocation matrix: in: : represents the total delay of rendering node a, : Task processing delay of node a, : The processing delay of task b on node a, : The transmission delay of task b on node a and the calculation of delay tolerance threshold are: ;in: : The delay tolerance threshold of node a, : The maximum delay that the node can withstand, : Maximum tolerable delay of the task and It is the adjustment factor. Determination of resource preemption rules: The resource preemption rules are to ensure that the system can dynamically adjust the resource allocation of each rendering node when a high-priority task occurs, so as to ensure that the high-priority task is processed in time. The rules take into account the node's load status, task priority, network bandwidth and node resource usage. The core idea of ​​the resource preemption rule is that when the load of a node reaches a certain threshold, other nodes are allowed to preempt part of the node's resources in order to process higher-priority tasks. Specific steps: Node load status analysis: The system monitors the load of each rendering node in real time. If the load of a node reaches the set threshold, it means that the resources of the node are close to saturation and may not be able to effectively process new tasks. Task priority consideration: High-priority tasks need to be allocated resources first. If a node is executing a low-priority task and its load is too high, the system can consider suspending the low-priority task or transferring part of its resources to the high-priority task. Network bandwidth analysis: Network bandwidth also affects the execution efficiency of tasks. If the bandwidth is too tight, it may cause increased delays. The system needs to dynamically adjust resource allocation according to the bandwidth situation to ensure that data can be transmitted quickly. Resource preemption rules: When a node is overloaded and a high-priority task needs to be executed, the system can allow other nodes to preempt part of the node's resources to execute the high-priority task. The preemption rules can be implemented in the following ways: Calculation of resource preemption rules: When a node The load reaches the threshold And the task Priority Above threshold When Seize Node The formula is: ;in: : The amount of resources preempted by node a. : The amount of resources currently owned by node a. : The current load of node a. : The node load threshold. : The priority of task b. : Threshold for high priority tasks. : The coefficient that controls the amount of resources seized.

[0039] A method for collaborative management of LED display screens based on distributed systems comprises the following steps: S1. real-time monitoring of input video stream data and device log data of LED display screens, extracting a set of coordinates of different regions and static region identification codes in the video stream through a dynamic region segmentation algorithm, identifying a high dynamic display region, compressing the different regions to generate data packets, and analyzing the device log data through a long short-term memory network to output a fault data packet; S2. compressing data packets and fault data packets, mapping protocol header fields and parameter sets of devices from different manufacturers into standardized operation codes of a unified intermediate instruction set, generating a synchronization instruction set with timestamp sharding, and dynamically adjusting a node weight matrix of associated devices; S3. combining the synchronization instruction set and the node weight matrix, taking screen resolution, node load and task priority as the state space, generating a task allocation matrix of rendering node ID, transmission path topology and energy consumption constraint value, and outputting a real-time delay tolerance threshold and resource preemption rules.

[0040] In this implementation scheme, S1. collects the data of the input video stream and the device log data through real-time monitoring of the LED display screen to provide raw data for subsequent fault detection and optimization. The video stream data is extracted by the dynamic region segmentation algorithm to identify the dynamic change area in the display process, which is crucial for optimizing the video content display and reducing unnecessary data processing. The device log data is analyzed by the long short-term memory network (LSTM), and the fault data packet is output to predict and discover possible faults in advance, thereby enhancing the maintenance capability of the system. The dynamic region segmentation algorithm can accurately extract the change area in the video stream, so that the system only compresses and processes the difference area, avoiding the waste of invalid data. The long short-term memory network (LSTM) is used to analyze the device log data, which can more accurately predict faults and improve the intelligence and accuracy of fault detection. S2. By mapping the protocol header fields and parameter sets of devices from different manufacturers to a unified intermediate instruction set, the protocol differences between manufacturers can be eliminated, so that the system can work more flexibly and efficiently between devices. Generate a synchronous instruction set with timestamp shards to ensure the time sequence and consistency of instruction execution when multiple devices work together. Dynamically adjusting the node weight matrix adjusts the weight of each device in task processing according to its status and capabilities, ensuring reasonable resource allocation and avoiding system overload. The unified intermediate instruction set and standardized operation code enable devices from different manufacturers to work seamlessly together, improving the compatibility and interoperability of the system. Dynamically adjusting the node weight matrix adjusts task allocation in real time according to device status (such as load, failure probability, etc.), improving the flexibility and stability of the system. S3. According to the synchronization instruction set and the node weight matrix, the system uses screen resolution, node load and task priority as the state space to allocate tasks. In the task allocation process, the resource usage of the node (such as load, energy efficiency, etc.) and the network transmission capacity are considered to construct a reasonable task allocation matrix. In addition, the system will output delay tolerance thresholds and resource preemption rules according to real-time conditions to ensure that high-priority tasks can be given priority when resources are tight, ensuring the efficient operation of the system. By considering screen resolution, node load and task priority, the system can allocate tasks more intelligently and optimize resource utilization. The introduction of real-time delay tolerance thresholds and resource preemption rules enables the system to dynamically adjust task priorities under high load conditions, avoid resource conflicts, and improve system reliability and performance.

[0041] In summary, this application has at least the following effects: A distributed LED display collaborative management system and method can timely identify high-dynamic display areas and device faults through real-time monitoring and analysis of video streams and device logs through dynamic area segmentation and long short-term memory networks, ensuring that the system can quickly respond and repair or adjust when an abnormality occurs. Using a multi-dimensional state space model and a node weight matrix, the system can intelligently allocate tasks according to constraints such as device load, task priority, bandwidth, and delay, ensuring that the load and energy consumption of each rendering node are reasonably controlled, thereby improving the overall efficiency of the system and reducing energy consumption. By uniformly converting the protocol header fields and parameter sets of devices from different manufacturers into standardized operation codes, the problem of protocol incompatibility between multiple devices is solved, and the collaborative work between devices is simplified. By dynamically adjusting the node weight matrix and combining the real-time delay tolerance threshold and resource preemption rules, the system can ensure the execution of high-priority tasks under high load conditions, avoid resource conflicts and performance bottlenecks, and ensure the smooth operation of the entire system. The distributed architecture of the method can support the collaborative management of multiple LED displays, and has flexible scalability, which is suitable for large-scale, multi-device collaborative control systems.

[0042] It will be appreciated by those skilled in the art that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Furthermore, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0043] The present invention is described with reference to flowcharts and / or block diagrams of systems, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0044] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0045] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0046] Although the preferred embodiments of the present invention have been described, those skilled in the art may make other changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

[0047] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.

Claims

1. A distributed LED display collaborative management system, characterized in that: It includes the following modules: edge intelligent preprocessing module, distributed protocol collaboration module, and dynamic resource scheduling module; The edge intelligent preprocessing module is used to monitor the input video stream data and device log data of the LED display screen in real time, extract the difference area coordinate set and static area identification code in the video stream through the dynamic area segmentation algorithm, identify the high dynamic display area, and compress the difference area to generate a data packet. At the same time, the device log data is analyzed through the long short-term memory network to output the fault data packet; The distributed protocol collaboration module maps the protocol header fields and parameter sets of devices from different manufacturers into standardized operation codes of a unified intermediate instruction set based on compressed data packets and fault data packets, generates a synchronization instruction set with timestamp sharding, and dynamically adjusts the node weight matrix of associated devices; The dynamic resource scheduling module is used to combine the synchronization instruction set and the node weight matrix, use the screen resolution, node load and task priority as the state space, generate a task allocation matrix of rendering node ID, transmission path topology and energy consumption constraint value, and output real-time delay tolerance threshold and resource preemption rules.

2. According to claim 1, a distributed LED display collaborative management system is characterized in that: The specific process of real-time monitoring of the input video stream data and device log data of the LED display is as follows: Through the video acquisition interface deployed on the LED control terminal, the original video stream data is captured at a set rate and parsed into a frame sequence in a standard format; The synchronously collected device log data includes temperature sensor data, power supply voltage fluctuation data, and network communication packet loss rate data, which are stored in the local cache queue after being aligned by timestamp.

3. According to claim 2, a distributed LED display collaborative management system is characterized in that: The specific process of extracting the coordinate set of the difference area and the static area identification code in the video stream through the dynamic area segmentation algorithm, identifying the high dynamic display area, and compressing the difference area to generate a data packet is as follows: Through a comprehensive algorithm that combines the inter-frame difference method with the optical flow method, the pixel change amplitude between consecutive video frames is calculated, and the area with a change rate greater than a set threshold is marked as a difference area coordinate set; Generate a hash code for the static area as the static area identification code, and retransmit it only when the whole area is updated; The difference area is encoded and dynamically quantized to generate a compressed data packet, including the area ID, timestamp, and compression bit rate.

4. According to claim 3, a distributed LED display collaborative management system is characterized in that: At the same time, the device log data is analyzed through the long short-term memory network, and the specific process of outputting the fault data packet is as follows: The temperature sensor data, power supply voltage fluctuation data and network communication packet loss rate data are divided into time series segments according to the set time window, and input into the pre-trained long short-term memory network model; The fault data packet is output, which includes the fault probability value and the list of associated device IDs, and determines whether the current device status is abnormal. When the fault probability value exceeds the set standard value, a fault data packet containing the device ID and fault type is generated.

5. A distributed LED display collaborative management system according to claim 4, characterized in that: The specific process of mapping the protocol header fields and parameter sets of devices from different manufacturers into standardized operation codes of a unified intermediate instruction set based on compressed data packets and fault data packets is as follows: After receiving the compressed data packet and the fault data packet, parse the protocol header fields and parameter sets of different vendor protocols; The protocol header field includes the instruction type and length check code, and the parameter set includes brightness, contrast, and refresh rate; The protocol conversion smart contract library matches the preset mapping rules and converts them into standardized intermediate instructions containing operation codes, parameter values, and target device IDs. The mapped operation codes are stored according to the protocol standardization requirements to form an instruction set.

6. A distributed LED display collaborative management system according to claim 5, characterized in that: The specific process of generating a synchronization instruction set with timestamp sharding and dynamically adjusting the node weight matrix of associated devices is as follows: Based on a unified intermediate instruction set, each instruction is sharded by timestamp through the PBFT consensus algorithm, and a unique timestamp and hash check value are assigned to each shard to generate a timestamp shard synchronization instruction set; According to the list of associated device IDs in the fault data packet, the node weight matrix of each device is dynamically adjusted based on the network topology and the coordination relationship between devices; According to the list of associated device IDs in the fault data packet, for devices whose fault probability values ​​are greater than the set standard values, their voting weights in the consensus process are reduced to form a node weight matrix of device IDs and corresponding voting weights.

7. A distributed LED display collaborative management system according to claim 6, characterized in that: Combining the synchronization instruction set and the node weight matrix, the specific process of generating the task allocation matrix of rendering node ID, transmission path topology and energy consumption constraint value with screen resolution, node load and task priority as the state space is as follows: Obtain the rendering node information in the synchronization instruction set and the weight of each device in the node weight matrix, use the screen resolution, node load and task priority as state space variables, build a multi-dimensional state space model, determine the task processing capacity of each rendering node, and evaluate the load and priority of each rendering node; According to the node load information and task priority, calculate the resource requirements and load balancing status of each rendering node, build the network topology diagram, and determine the data flow and task transmission path; Based on the node weight matrix, analyze the device energy efficiency, network bandwidth and delay between nodes, and assign the task ID and transmission path topology to each rendering node based on the task type and priority; Combined with the current network topology and equipment energy efficiency data, the task allocation matrix is ​​calculated to generate the task ID, transmission path topology and energy consumption constraint value of each rendering node, ensuring that each node does not exceed its energy consumption limit when assigning tasks, thereby generating a task allocation matrix of rendering node ID, transmission path topology and energy consumption constraint value.

8. A distributed LED display collaborative management system according to claim 7, characterized in that: The specific process of outputting real-time delay tolerance threshold and resource preemption rules is as follows: Based on the rendering node ID, transmission path topology and energy consumption constraint value in the task allocation matrix, the delay tolerance threshold of each rendering node is determined by calculating the delay of each node during task execution. The delay tolerance threshold represents the maximum task execution delay time that the node can accept while ensuring display quality and user experience. Analyze the load status and task priority of each rendering node, and determine the resource preemption rules of the node based on the network bandwidth and node resource usage. The resource preemption rules include: Dynamically adjust according to the node's task priority and network transmission load. When the load of a node reaches a certain threshold, other nodes are allowed to preempt part of the node's resources to ensure that high-priority tasks are processed first.

9. A distributed LED display collaborative management method, applied to a distributed LED display collaborative management system according to any one of claims 1 to 8, characterized in that: The following steps are involved: S1. Real-time monitoring of the input video stream data and device log data of the LED display screen, extracting the difference area coordinate set and static area identification code in the video stream through the dynamic area segmentation algorithm, identifying the high dynamic display area, and compressing the difference area to generate a data packet. At the same time, the device log data is analyzed through the long short-term memory network to output the fault data packet; S2. Compress data packets and fault data packets, map protocol header fields and parameter sets of devices from different manufacturers into standardized operation codes of a unified intermediate instruction set, generate a synchronization instruction set with timestamp sharding, and dynamically adjust the node weight matrix of associated devices; S3. Combine the synchronization instruction set and the node weight matrix, use the screen resolution, node load and task priority as the state space, generate the task allocation matrix of rendering node ID, transmission path topology and energy consumption constraint value, and output the real-time delay tolerance threshold and resource preemption rules.

Images