Wireless real-time transmission multi-screen video playing control method and system

Abstract

The invention discloses a wireless real-time transmission multi-screen video playing control method and a wireless real-time transmission multi-screen video playing control system, particularly relates to the technical field of multi-terminal video synchronous control, and is used for solving the problem of overall response delay caused by instruction blocking due to terminal performance difference in existing wireless multi-screen transmission. Marking a screen exceeding a threshold value as a blocked screen by identifying a real-time instruction and detecting the length of an instruction queue of each screen; extracting an unprocessed instruction sequence of a blocked screen, and quantifying time-effect value loss based on an operation type and a playing content association weight; when the loss exceeds a threshold value, generating a cross-screen strategy, binding a real-time instruction with a video stream channel, and transmitting the real-time instruction to a non-blocking screen; analyzing the conflict probability of the non-blocking screen playing progress dispersion and the refreshing phase deviation prediction instruction; when the probability is lower than a threshold value, the non-blocking screen is controlled to execute the instruction through the independent quick response channel, the instruction response efficiency is remarkably improved while the screen-crossing synchronism is guaranteed, and high-reliability and low-delay control under the complex wireless environment is achieved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of multi-terminal video synchronization control, and particularly relates to a wireless real-time transmission multi-screen video playing control method and system. BACKGROUND

[0002] At present, the wireless network is used to synchronously transmit video content to multiple screens in digital exhibition hall, smart classroom and other scenes, and independent channels are usually used to transmit video data and control instructions: the video stream is transmitted through a low-latency channel to ensure real-time performance, and the control instruction is transmitted through a high-reliability channel to ensure accuracy. The prior art relies on a standard network protocol stack to realize dual-channel transmission to meet the real-time control requirements of multi-screen collaborative playing.

[0003] However, in the multi-screen wireless transmission scene, due to the differences in the instruction processing capability and network state of different screens, the transmission delay of the control instruction will cause cross-screen blocking: when the control instruction is accumulated due to network fluctuations in part of the screens, the high-performance screen needs to wait for the instruction queue of the low-performance screen to be emptied before responding to the new control request, and in order to maintain multi-screen synchronization, all screens will be forced to wait for the slowest terminal, causing overall control response delay. SUMMARY

[0004] The present application provides a wireless real-time transmission multi-screen video playing control method and system to solve the technical problems in the prior art.

[0005] The technical solution of the present application to solve the above technical problems is as follows: The present application provides the following technical solution: A wireless real-time transmission multi-screen video playing control method, comprising: S1, identifying the current control instruction type and distinguishing real-time instructions; S2, when the control instruction is a real-time instruction, detecting the instruction queue length of each screen, and marking the screen with an instruction queue length exceeding a preset length threshold as a blocked screen; S3, extracting the unprocessed instruction sequence of the blocked screen, quantifying the time value loss of the blocked screen based on the operation type of the unprocessed instruction sequence and the association weight of the current playing content; S4, when the time value loss is greater than a preset loss threshold, generating a cross-screen instruction execution strategy and binding the real-time instruction to the video stream channel to transmit to a non-blocked screen; S5, based on the collaborative analysis of the playing progress dispersion of each non-blocked screen and the phase deviation of the screen refresh cycle, predicting the conflict probability of the real-time instruction in the non-blocked screen; S6, when the conflict probability is less than a preset probability threshold, controlling the non-blocked screen to execute the real-time instruction through a fast response channel independent of the instruction queue.

[0006] Further, the current control instruction type is identified and the real-time instruction is distinguished, including: extracting the operation instruction code of the control instruction; performing feature matching on the operation instruction code and a predefined real-time instruction feature library; when the operation instruction code matches at least one real-time instruction feature in the predefined real-time instruction feature library, determining that the control instruction is a real-time instruction; when the operation instruction code does not match any real-time instruction feature in the predefined real-time instruction feature library, determining that the control instruction is a non-real-time instruction.

[0007] Further, when the control instruction is a real-time instruction, the instruction queue length of each screen is detected, and a screen whose instruction queue length exceeds a preset length threshold is marked as a blocked screen, including: obtaining the number of unprocessed real-time instructions in the instruction queue of each screen as the instruction queue length; reading the preset length threshold; numerically comparing the instruction queue length of each screen with the preset length threshold; when the instruction queue length of a screen is greater than the preset length threshold, the corresponding screen is added to the blocked screen set; when the instruction queue length of a screen is less than or equal to the preset length threshold, the corresponding screen is not added to the blocked screen set.

[0008] Further, the unprocessed instruction sequence of the blocked screen is extracted, and the time value loss of the blocked screen is quantified based on the association weight of the operation type of the unprocessed instruction sequence and the current playing content, including: extracting all unprocessed control instructions from the instruction queue of the blocked screen to form an unprocessed instruction sequence; identifying the operation type of each control instruction in the unprocessed instruction sequence; obtaining the scene classification label of the current playing content; querying a predefined weight mapping table to obtain the association weight value of the operation type and the scene classification label; accumulating the association weight values of all control instructions in the unprocessed instruction sequence to obtain a total association weight sum; calculating the negative natural logarithm value of the total association weight sum as an instruction value entropy; taking the instruction value entropy as the quantification result of the time value loss.

[0009] Further, the predefined weight mapping table is implemented by the following method: creating a two-dimensional relational database table, with row index as operation type and column index as scene classification label; each cell stores a floating-point association weight value; According to the operation type and the scene classification label, the corresponding cell value is retrieved during the query.

[0010] Further, when the time value loss is greater than the preset loss threshold, a cross-screen instruction execution strategy is generated, and a real-time instruction is bound to a video stream channel and transmitted to a non-blocking screen, including: reading the quantitative result of the time value loss; obtaining the preset loss threshold; numerically comparing the quantitative result of the time value loss with the preset loss threshold; when the quantitative result of the time value loss is greater than the preset loss threshold, constructing a cross-screen instruction data packet containing a real-time instruction; adding a cross-screen instruction data packet identification field in the transmission protocol header of the video stream channel; encapsulating the cross-screen instruction data packet into the payload data area of the video stream channel; transmitting the encapsulated video stream data to all non-blocking screens through the video stream channel.

[0011] Further, based on the collaborative analysis of the playback progress dispersion and the inter-screen refresh cycle phase deviation of each non-blocking screen, the conflict probability of the real-time instruction on the non-blocking screen is predicted, including: obtaining the current playback frame number of each non-blocking screen; calculating the standard deviation of the current playback frame number of all non-blocking screens as the playback progress dispersion; capturing the rising edge timestamp of the vertical synchronization signal of each non-blocking screen; calculating the difference value of the rising edge timestamps of the vertical synchronization signals of any two non-blocking screens; converting the timestamp difference value into a phase angle value to obtain the inter-screen refresh cycle phase deviation; establishing a collaborative evaluation state table of the playback progress dispersion and the inter-screen refresh cycle phase deviation; matching the conflict probability level corresponding to the current playback progress dispersion range and the inter-screen refresh cycle phase deviation range in the collaborative evaluation state table; mapping the conflict probability level to a numerical conflict probability.

[0012] Further, the collaborative evaluation state table is implemented in the following way: constructing a two-dimensional discretization interval matrix, dividing the playback progress dispersion interval on the horizontal axis and the inter-screen refresh cycle phase deviation interval on the vertical axis; presetting the conflict probability level enumeration value in each matrix cell; matching the current dispersion and phase deviation to the matrix cell to obtain the probability level.

[0013] Further, when the conflict probability is less than the preset probability threshold, the non-blocking screen is controlled to execute the real-time instruction through a quick response channel independent of the instruction queue, including: reading the conflict probability of the real-time instruction in the non-blocking screen; obtaining a preset probability threshold; numerically comparing the conflict probability with the preset probability threshold; when the conflict probability is less than the preset probability threshold, analyzing the operation instruction code of the real-time instruction; matching the operation instruction code with a predefined quick response execution protocol; creating a quick response thread independent of the instruction queue processing thread in the non-blocking screen; executing the real-time instruction operation through the quick response thread according to the predefined quick response execution protocol.

[0014] In another aspect, the application provides a wireless real-time transmission multi-screen video playing control system, including: an instruction recognition module, configured to recognize a current control instruction type and distinguish a real-time instruction; a queue detection module, configured to detect the instruction queue length of each screen when the control instruction is the real-time instruction, and mark a screen with an instruction queue length exceeding a preset length threshold as a blocking screen; a loss quantification module, configured to extract an unprocessed instruction sequence of the blocking screen, and quantize the time value loss of the blocking screen based on the operation type of the unprocessed instruction sequence and the associated weight of the current playing content; a strategy generation module, configured to generate a cross-screen instruction execution strategy and bind the real-time instruction to a video stream channel when the time value loss is greater than a preset loss threshold, and transmit the real-time instruction to a non-blocking screen; a conflict prediction module, configured to predict the conflict probability of the real-time instruction in the non-blocking screen based on the cooperative analysis of the playing progress dispersion of each non-blocking screen and the phase deviation of the screen refresh cycle; a channel execution module, configured to control the non-blocking screen to execute the real-time instruction through a quick response channel independent of the instruction queue when the conflict probability is less than the preset probability threshold.

[0015] The application has the following beneficial effects: 1. Through the dynamic marking mechanism of instruction type identification and blocking screen, the differential processing of instructions is realized in the multi-screen wireless transmission scene. For real-time instructions, the blocking screen with insufficient processing capacity is identified based on the length of the instruction queue, and the unprocessed instruction sequence is extracted for time value loss quantification. Through the cross-screen instruction execution strategy, high-time value instructions are dynamically bound to the video stream channel and transmitted to the non-blocking screen, effectively avoiding the overall response delay caused by single screen blocking. The method breaks through the limitation of traditional multi-screen synchronization system that must wait for the slowest terminal, significantly improves the instruction response efficiency while ensuring cross-screen synchronization, and is especially suitable for video interactive scenes with strict real-time requirements.

[0016] 2. Further through the cooperative analysis of playing progress dispersion and refresh phase deviation, the instruction conflict risk of non-blocking screen is accurately predicted. When the conflict probability is lower than the threshold, real-time instructions are executed in a fast response channel independent of the regular instruction queue, avoiding queue processing delay. This dual protection mechanism not only solves the blocking problem caused by screen performance differences, but also eliminates instruction conflicts caused by different playing states, achieving high reliability and low delay control of multi-screen system in complex wireless environment. Compared with existing dual-channel transmission scheme, the method maintains smooth video transmission while improving control instruction response speed to the level that can support interactive operation. BRIEF DESCRIPTION OF DRAWINGS

[0017] Figure 1 A flowchart of a wireless real-time transmission multi-screen video playing control method according to the present application; Figure 2 A structural schematic diagram of a wireless real-time transmission multi-screen video playing control system according to the present application. DETAILED DESCRIPTION

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

[0019] Embodiment 1: Figure 1 A wireless real-time transmission multi-screen video playing control method according to the present application is given, comprising: S1, identifying the type of current control instructions and distinguishing real-time instructions; S2, when the control instruction is a real-time instruction, detecting the length of the instruction queue of each screen, and marking the screen with an instruction queue length exceeding a preset length threshold as a blocking screen; S3, extract the unprocessed instruction sequence of the blocking screen, and quantify the time value loss of the blocking screen based on the operation type of the unprocessed instruction sequence and the associated weight of the current playing content; S4, when the time value loss is greater than the preset loss threshold, generate a cross-screen instruction execution strategy and bind the real-time instruction to the video stream channel for transmission to the non-blocking screen; S5, based on the cooperative analysis of the playing progress dispersion of each non-blocking screen and the phase deviation of the screen refresh cycle, predict the conflict probability of the real-time instruction on the non-blocking screen; S6, when the conflict probability is less than the preset probability threshold, control the non-blocking screen to execute the real-time instruction through a fast response channel independent of the instruction queue.

[0020] S1, identify the current control instruction type and distinguish the real-time instruction, which is implemented as: After the control instruction is received through the wireless network, the operation instruction code of the control instruction is first extracted. The operation instruction code is a specific field in the instruction data packet, located at the 2nd to 5th bytes of the data packet header. This field uses character encoding to represent the specific operation intention. For example, when the operation instruction code is "PLAY", it represents a play instruction, when it is "PAUSE", it represents a pause instruction, and when it is "SEEK", it represents a jump instruction. The extraction process is implemented by parsing the byte sequence of the data packet, specifically by reading the contents of the continuous 4 bytes from the 2nd to 5th bytes of the data packet header. These byte corresponding characters are combined to form a complete operation instruction code string. This string is stored in a memory buffer for subsequent processing, and the buffer length is fixed at 8 bytes to accommodate the longest instruction code.

[0021] The pre-defined real-time instruction feature library is established in the system initialization stage. This feature library contains three types of core instruction codes: the play instruction code is fixed as the string "PLAY", the pause instruction code is fixed as the string "PAUSE", and the jump instruction code is fixed as the string "SEEK". These three types of strings form a string-type instruction code set, which is stored in the constant area of the device memory in the form of an array. The memory lookup table is implemented through consecutive memory addresses, and each table entry stores the starting address of an instruction code string. The table entries are arranged in alphabetical order. For example, table entry 1 stores the "PAUSE" string address, table entry 2 stores the "PLAY" string address, and table entry 3 stores the "SEEK" string address, forming an ordered lookup table structure.

[0022] Each table entry of the memory lookup table is traversed during feature matching. The traversal process starts from the first address of the lookup table and sequentially accesses the string content pointed by each table entry. The extracted operation code string is compared with the current table entry string for complete match. Complete match requires that the character sequences of the two strings are identical and have the same length. A standard string comparison function is called during the matching process, which compares the character encoding values of the two strings byte by byte, and returns a match success flag when all byte values are identical. For example, when the operation code is "PLAY", it is compared with the second entry "PLAY" of the lookup table, and is determined as a match success because the character sequences are identical.

[0023] When the operation code matches at least one real-time instruction feature in the predefined real-time instruction feature library, the control instruction is determined as a real-time instruction. The determination logic is implemented by conditional branching: if any table entry matches, the real-time flag is set to true value, and the control instruction type is marked as real-time instruction type. For example, when the operation code "SEEK" matches the third entry of the lookup table, the real-time instruction determination is triggered immediately. If multiple table entries are found to match during the matching process, they are still processed as a single match, and the determination is not repeated. The determination result is written into the type identification field of the instruction processing state register, which is encoded in binary, 0 indicating non-real-time instruction and 1 indicating real-time instruction.

[0024] When the operation code does not match any real-time instruction feature in the predefined real-time instruction feature library, the control instruction is determined as a non-real-time instruction. The non-matching state is identified by the traversal completion flag: when all table entries of the lookup table do not return a match success signal, the real-time flag is set to false value. For example, when the operation code is "VOLUME", it fails to match "PAUSE", "PLAY" and "SEEK" in sequence, and is finally determined as a non-real-time instruction. The non-real-time instruction type mark is written into the type identification field of the instruction processing state register.

[0025] The establishment process of the predefined real-time instruction feature library is performed at device startup. First, a fixed-size storage area is allocated in memory, and the storage area capacity is 3 times the maximum length of the instruction code. Then, the character encoding sequence of the play instruction code string "PLAY" is written into the first storage block, the pause instruction code string "PAUSE" is written into the second storage block, and the jump instruction code string "SEEK" is written into the third storage block. The first addresses of each storage block are sequentially stored in a pointer array to form the memory lookup table index. After the feature library initialization is completed, the storage area is locked as read-only attribute to prevent modification during runtime.

[0026] The predefined real-time instruction feature library is implemented by establishing a set of string type instruction codes, including a play instruction code, a pause instruction code, and a jump instruction code; storing the set of instruction codes as a memory lookup table; and performing string complete matching by traversing the lookup table.

[0027] The string complete matching mechanism is implemented by character level comparison. The comparison process starts from the first character of the string, and the corresponding position characters of the operation instruction code and the table item string are extracted one by one, and then the encoded values are subtracted. If the difference values of all characters are 0 and the string length counter is also 0, it is determined that the complete matching is successful. For example, when "PLAY" is compared with "PLAY", the difference values of the 4 characters are all 0 and the lengths are consistent, and the matching is successful; when "PLAY" is compared with "PLAy", the encoded values of the 4th characters 'Y' and 'y' are different, and the matching is failed.

[0028] The complete flow of operation instruction code extraction and feature library matching forms a closed processing chain: starting from receiving the original data packet from the network interface, parsing the header positioning instruction code field, extracting the string, starting the lookup table traversal, and setting the instruction type flag according to the matching result. The entire processing process is completed in an independent instruction parsing thread, and the processing delay is not more than 2 milliseconds, ensuring the timeliness of real-time determination. All processing links are implemented by direct memory operation, without relying on external storage devices or remote services. The feature library content is loaded at system startup through a configuration file, the configuration file is stored in plaintext text format, each line contains an instruction code string, and the developer can modify the file to adjust the feature library content.

[0029] S2, when the control instruction is a real-time instruction, detecting the instruction queue length of each screen, marking the screen whose instruction queue length exceeds the preset length threshold as a blocked screen, and implementing as: After the control instruction is determined as a real-time instruction by S1, the instruction queue length detection process of each screen is started. The instruction queue length is defined as the number of unprocessed real-time instructions in the instruction queue of each screen, which is obtained by traversing the instruction queue and counting the instruction entries with the real-time flag bit as true. In specific implementation, the instruction queue data structure of each screen is accessed, the data structure uses a first-in-first-out queue to store the to-be-processed instructions, and each instruction entry includes an instruction type identification field, which is written by S1. The traversal process starts from the queue head, checks the instruction type identification field of each entry, and increases the counter by 1 when the field value is the real-time instruction type identification. For example, when there are 3 unprocessed play instructions and 2 jump instructions in the queue of a screen, the counting result is 5. The counting operation is performed in an independent thread to avoid blocking the main control flow, and the priority of the counting thread is set to be higher than that of the ordinary processing thread.

[0030] The preset length threshold is stored in a system configuration file, which is loaded into the memory when the device is started. The threshold is dynamically set according to the screen processing capability, which is determined by the benchmark test data corresponding to the model of the screen processor. The specific setting logic is to query the pre-stored processor performance table to obtain the average processing time of a single real-time instruction, and the unit of time is millisecond; the threshold value is obtained by dividing the preset maximum allowed time delay by the average processing time and rounding. For example, if the average processing time of the processor is 10 milliseconds and the system requires a maximum time delay of 100 milliseconds, the threshold is set to 100 divided by 10, which is equal to 10. The configuration file is stored in a key-value pair format, with the key name being queue_length_threshold and the value being an integer threshold data. The system reads the value into a memory variable during initialization. The memory variable is allocated in the shared memory area and is accessible by all detection threads.

[0031] The length of the instruction queue of each screen is compared with the preset length threshold. The comparison operation is implemented using integer comparison instructions. First, the length count value of the instruction queue of the current screen is read, which is a non-negative integer; then the preset length threshold variable in the memory is read, which is a positive integer; the sign bit of the status register is checked after the subtraction operation. When the result of the length count value of the instruction queue minus the preset length threshold is greater than 0, the greater than condition is triggered; when the result is equal to or less than 0, the less than or equal condition is triggered. The comparison process is applied to all screens in a loop, and each loop processes the data of one screen. The number of loops is equal to the total number of currently active screens. The loop index starts from 0 and increments, ensuring that each screen is processed.

[0032] When the length of the instruction queue of a screen is greater than the preset length threshold, the screen is added to the blocked screen set. The blocked screen set is stored in a dynamic array data structure and is initially empty. The addition operation includes two steps: first, allocate new node space in the memory heap area, which contains a screen identifier field and a pointer field; then write the unique identifier of the current screen into the node and add the node pointer to the end of the array. The screen identifier is obtained by querying the screen registry, which stores the mapping relationship between the MAC address and the logical ID of each screen. For example, when the length count value of the instruction queue of the screen with the identifier display_01 is 12 and the threshold is 10, a new node is created to write display_01 and add it to the set array. The array length counter is updated synchronously.

[0033] When the instruction queue length of a screen is less than or equal to the preset length threshold, the screen is not added to the blocked screen set. The logic is implemented by a conditional branch to skip the addition operation, but the detection result needs to be recorded. The system maintains a screen state table, which allocates a state byte to each screen. The state byte contains a blocking flag bit. When the instruction queue length is less than or equal to the threshold, the blocking flag bit of the state byte is set to 0; when it is greater than the threshold, it is set to 1. For example, when the count value of the screen identifier display_02 is 8 and the threshold is 10, the blocking flag bit of its state byte is 0. The state table is stored continuously in memory, and the screen identifier hash value is used to quickly locate it.

[0034] The instruction queue detection process includes an exception handling mechanism. When a read error occurs while traversing the queue, the current screen counter is reset to a negative value and the exception state is marked, and the screen does not participate in threshold comparison. The preset length threshold validity check is performed when reading: if the configuration value is less than 1 or greater than 1000, the default threshold of 5 is enabled. The blocked screen set implements dynamic expansion, and when the array space is insufficient, it is expanded by 50% of the current capacity and the data is migrated. The screen state table is persisted to flash every 5 seconds, and checksum calculation is performed before persistence to prevent data errors.

[0035] The detection process forms a closed loop with S1 step: the real-time instruction type identifier output by S1 is used as the basis for counting, and the blocked screen set and screen state table output by S2 are used by S3 step. All operations are completed in a real-time operating system task, with a task period of 50 milliseconds to ensure timely response to instruction changes. Memory resource usage is monitored, and when memory usage exceeds 80%, expansion of the set is stopped and a log is generated. The blocked screen determination history data is stored in a ring buffer with a fixed capacity of 100 records, which is used for subsequent performance optimization analysis.

[0036] S3, extract the unprocessed instruction sequence of the blocked screen, and quantify the time value loss of the blocked screen based on the association weight of the operation type of the unprocessed instruction sequence and the current playing content, which is implemented as: Extract all unprocessed control instruction groups from the instruction queue of the blocking screen to form an unprocessed instruction sequence. The blocking screen set is generated by the S2 step, containing a list of screen identifiers marked as blocking state. The extraction process is performed independently for each screen in the set: first locate the corresponding instruction queue memory address according to the screen identifier, which is obtained by querying the screen registry; then traverse all instruction entries in the queue whose state flag field value is unprocessed state. Each instruction entry contains an operation instruction code field and a state flag field, and when the state flag field value is unprocessed state, the instruction is copied in its entirety to a newly allocated memory buffer. For example, for a blocking screen with a screen identifier of display_01, if there are 3 instructions in its queue with a state of unprocessed state, a continuous storage area containing the data of these 3 instructions is created as the unprocessed instruction sequence of the screen. The buffer size is dynamically adjusted according to the number of unprocessed instructions, with an additional 10% redundant space to ensure sufficient capacity.

[0037] Identify the operation type of each control instruction in the unprocessed instruction sequence. The operation type identification multiplexes the mechanism of the S1 step: extract the operation instruction code string from the 2nd to 5th byte of the instruction data packet header, which has a fixed length of 4 bytes; perform feature matching of the string with the pre-defined real-time instruction feature library. The matching process is exactly the same as S1, using the string complete matching mechanism: call the standard string comparison function to compare byte by byte, and when all character encoding values are the same and the length is consistent, it is determined to be a match. The identification result is written to the operation type field of the instruction entry, with the field value being an enumeration value (1 represents the play operation type, 2 represents the pause operation type, and 3 represents the jump operation type). For example, when the operation instruction code is "PLAY", set the operation type field value to 1. All instructions in the unprocessed instruction sequence need to complete this identification operation, and the identification process is executed in a dedicated instruction processing thread.

[0038] Obtain the scene classification label of the current playing content. The current playing content refers to the video stream data being displayed by the blocking screen. The scene classification label is generated by analyzing the key frame features of the video: extract a key frame of the video stream every 1000 milliseconds; scale the key frame image to a fixed resolution of 256x256 pixels; input the scaled image data into a pre-trained scene classification model. The model is an image classifier based on a convolutional neural network architecture, and the output layer corresponds to a pre-set set of scene categories (e.g. including "teaching scene", "sports scene", "movie scene"). The model outputs the category with the highest probability as the scene classification label, which is stored in the form of a UTF-8 encoded string. For example, when the key frame shows a blackboard and a desk, the "teaching scene" label is output. The classification model is loaded from flash memory to memory during system initialization, and the model parameters are fixed and cannot be updated online.

[0039] The predefined weight mapping table is a two-dimensional relational database table stored in a SQLite database file. The database table structure includes three fields: an operation type integer field storing enumeration values from 1 to 3; a scene tag text field storing scene classification label strings; and a weight value floating point field storing weight values from 0.1 to 1.0. When querying, the operation type enumeration value and the scene classification label string of the current instruction are used to construct a parameterized SQL query statement "SELECT weight FROM weight_mapping WHERE operation_type=? AND scene_tag=?", where the question mark is a parameter placeholder. After executing the query, the floating point value of the first row in the result set is obtained. For example, when the operation type is 2 (pause operation type) and the scene label is "teaching scene", the query returns the corresponding weight value 0.6. Precompiled statements are used for database operations to prevent SQL injection.

[0040] The total associated weight sum is calculated by accumulating the associated weight values of all control instructions in the unprocessed instruction sequence. For an unprocessed instruction sequence of a single blocking screen, initialize the accumulator variable to 0.0. Traverse each instruction in the sequence: obtain the associated weight value of the instruction by querying the predefined weight mapping table; add the associated weight value to the accumulator variable and update the accumulator. After traversal, the value of the accumulator is the total associated weight sum of the screen. For example, if an unprocessed instruction sequence of a screen contains three instructions, the associated weight values obtained by querying are 0.6, 0.8, and 0.4, respectively, then the calculation process is as follows: 0.0 + 0.6 = 0.6; 0.6 + 0.8 = 1.4; 1.4 + 0.4 = 1.8; the final total associated weight sum is 1.8. The accumulation process uses double-precision floating-point arithmetic, and after each addition, it checks whether it has overflowed. If it exceeds 1e6, it is truncated to 1e6.

[0041] The total associated weight sum is calculated by accumulating the associated weight values of all control instructions in the unprocessed instruction sequence. For an unprocessed instruction sequence of a single blocking screen, initialize the accumulator variable to 0.0. Traverse each instruction in the sequence: obtain the associated weight value of the instruction by querying the predefined weight mapping table; add the associated weight value to the accumulator variable and update the accumulator. After traversal, the value of the accumulator is the total associated weight sum of the screen. For example, if an unprocessed instruction sequence of a screen contains three instructions, the associated weight values obtained by querying are 0.6, 0.8, and 0.4, respectively, then the calculation process is as follows: 0.0 + 0.6 = 0.6; 0.6 + 0.8 = 1.4; 1.4 + 0.4 = 1.8; the final total associated weight sum is 1.8. The accumulation process uses double-precision floating-point arithmetic, and after each addition, it checks whether it has overflowed. If it exceeds 1e6, it is truncated to 1e6.

[0042] The instruction value entropy is taken as the quantization result of the time value loss. The value is directly output as the time value loss indicator of the blocked screen, with a numerical range between negative infinity and 0. The closer the value is to 0, the smaller the time value loss, and the larger the negative value, the more serious the time value loss. For example, an instruction value entropy of -0.5878 indicates moderate time value loss, and -2.302 indicates severe time value loss. The calculation result is written to the time value loss field of the screen state data structure, which is a 4-byte floating-point type, for use by the S4 step. The screen state timestamp is updated after each calculation to ensure data freshness.

[0043] The pre-defined weight mapping table is implemented by creating a two-dimensional relational database table with the operation type as the row index and the scene classification label as the column index. The database table is created during system initialization, first establishing a temporary table structure in memory, and then persisting to the SQLite database file. The database table contains all combinations of operation type enumeration values and scene classification labels: the operation type enumeration values are fixed as 1 (play operation type), 2 (pause operation type), and 3 (jump operation type); the scene classification label set is determined by the output categories supported by the scene classification model (for example, including "teaching scene", "sports scene", and "movie scene" three categories). Each cell stores a floating-point associated weight value, which is preset by the system administrator according to business rules and input through the configuration interface. For example, the weight of the pause operation type in the teaching scene is set to 0.6, and the weight of the jump operation type is set to 0.9. The database table establishes a composite unique index (operation_type+scene_tag) to ensure query efficiency.

[0044] The associated weight value is determined according to specific business scenarios: the jump operation type (such as knowledge point positioning) in the teaching scene is given a higher weight (for example, 0.9), as it directly affects the teaching effect; the play operation type and pause operation type in the movie scene are given a higher weight (for example, 0.8); the pause operation type in the sports live scene is given a lower weight (for example, 0.3). The weight setting is realized through a graphical interface, and the administrator can adjust the value by dragging the slider, with the adjustment range limited to 0.1 to 1.0 and the step value set to 0.05. After each adjustment, an SQL update statement is automatically generated to modify the database record, and it is reloaded into the memory cache. The database file is automatically backed up every 24 hours, retaining the last 7 versions.

[0045] The abnormality processing mechanism includes: using a default weight value of 0.5 when a predefined weight mapping table fails to be queried (e.g., a record does not exist); using a "default scene" label (a weight reference value of 0.5) to query when a scene classification model output is abnormal; checking the validity of an input value before natural logarithm calculation to avoid calculation errors caused by negative values or zero values. All floating-point operations follow the IEEE 754 standard, and overflow protection is added to key calculation steps. The time-value loss result is updated every 200 milliseconds, and the screen state is synchronized and refreshed. The update process records operation logs, including time stamps, screen identifiers, total associated weights, and key parameters such as instruction value entropy.

[0046] S4, when the time-value loss is greater than a preset loss threshold, a cross-screen instruction execution strategy is generated and real-time instructions are bound to a video stream channel and transmitted to a non-blocking screen, which is implemented as: Read the quantization result of the time-value loss. The quantization result of the time-value loss is calculated by the S3 step and stored in the time-value loss field of the screen state data structure, which is a 4-byte floating-point number type. The reading process is achieved by accessing the screen state table: first, locate the corresponding record address in the state table according to the identifier of the blocking screen being processed; then read the floating-point value of the time-value loss field from the record. For example, the time-value loss field value of the screen identifier display_01 is -1.2, which is stored in a temporary variable after reading. The reading operation is completed in an atomic transaction to ensure data consistency in a multi-threaded environment. The timestamp and screen identifier are recorded to the operation log file after each read, and the log file uses a circular buffer for storage.

[0047] Get the preset loss threshold. The preset loss threshold is stored in the system configuration database, which uses a key-value storage mode. The specific acquisition process is as follows: after establishing a database connection, execute the parameterized query statement "SELECT loss_threshold FROM config_table WHERE module=?", where the question mark is replaced with the module identifier's4', and the returned result is a single-precision floating-point number. The threshold value is determined based on system performance test data: measure the instruction processing delay under different time-value loss values through stress testing, and select the loss value corresponding to the sudden increase point of the delay as the threshold value. For example, if the delay exceeds 200 milliseconds when the display time-value loss is less than -1.0, set the threshold value to -1.0. The configuration database synchronizes the memory cache every hour to ensure that the threshold value is updated in time.

[0048] The quantification result of the aging value loss is compared with the preset loss threshold. The comparison operation uses a floating-point comparison instruction: the read aging value loss (denoted as Vloss) is subtracted from the preset loss threshold (denoted as Tloss), and the size relationship is judged according to the operation result. When Vloss > Tloss (for example, Vloss = -0.8 and Tloss = -1.0), the greater-than condition is triggered; otherwise, it is not triggered. The comparison process adds a precision tolerance process, and the tolerance value is set to 0.001 to avoid misjudgment caused by floating-point errors. The comparison result is written to the state register for use in subsequent step condition judgment.

[0049] When the quantification result of the aging value loss is greater than the preset loss threshold, a cross-screen instruction data packet containing real-time instructions is constructed. The data packet construction process includes three sub-steps: first, allocate a fixed-size memory space as a data packet buffer, and the buffer size is preset to 512 bytes; then write the packet header at the head of the buffer, the packet header includes instruction type identifier field, screen identifier length field, instruction data length field and other metadata; finally, copy the complete data of the real-time instruction to the load area of the buffer. For example, for the play instruction, the instruction code field "PLAY" and the start time parameter field are copied to the load area. A 4-byte CRC32 check code is appended to the tail of the data packet, and the check range covers the entire data packet.

[0050] A cross-screen instruction data packet identification field is added to the transmission protocol header of the video stream channel. The video stream channel uses a standard video transmission protocol, and a 2-byte identification field is added to the extended header: the 0th bit is the instruction identification bit (set to 1 to indicate that it contains instruction data), the 1st-3rd bits are the instruction type code, and the 4th-15th bits are reserved. The addition operation is performed before video frame packaging: when cross-screen instructions need to be transmitted, set the instruction identification bit of the current video frame header to 1; at the same time, set the instruction type code according to the instruction type. For example, set the instruction type code to 000 when transmitting the play instruction. The identification field is inserted at a specific byte position in the video frame header, and the original data is shifted backward.

[0051] The cross-screen instruction data packet is encapsulated into the load data area of the video stream channel. The encapsulation process is divided into two stages: first, the cross-screen instruction data packet is divided into fixed-size blocks, and the insufficient part is filled with zeros; then each data block is inserted as an independent load unit into the video frame. The specific operation is as follows: a dedicated instruction data area is reserved in the load area of the video frame, which is located after the video data; the instruction data blocks are written in order in this area; and the load length field in the video frame header is updated. For example, when the original length of the video frame load area is 1200 bytes, after adding 512 bytes of instruction data, the load length is updated to 1712 bytes, and the header length field is adjusted accordingly. After encapsulation, the complete transmission frame data structure is generated.

[0052] The encapsulated video stream data is transmitted to all non-blocking screens through the video stream channel. The non-blocking screen set is maintained by the S2 step and stored in a dynamic array structure. The transmission process traverses the array: for each non-blocking screen, three operations are performed: querying the network address of the screen through the screen registry; establishing a transmission connection; sending encapsulated video frame data. For example, when the non-blocking screen includes display_02 and display_03, data packets are sent to these two addresses respectively. The transmission parameters are set to a fixed port number, the transmission protocol uses the standard real-time transmission protocol, and the size of the sending buffer is dynamically adjusted according to the network conditions.

[0053] The video stream channel multiplexing mechanism is implemented through frame type identification. Every 10 video frames, a specific frame is designated as an instruction transmission frame, and the frame load area contains complete cross-screen instruction data. The receiving end identifies the instruction data by detecting the frame header identification field, extracts it, and then clears the load area to restore the original video data. The transmission bandwidth allocation follows the preset proportion principle: when the video code rate is 8 Mbps, a fixed proportion of bandwidth is allocated to the instruction channel. The transmission process implements end-to-end verification: the sending end calculates the check code, the receiving end verifies the check code, and if it fails, the retransmission mechanism is triggered.

[0054] The exception handling mechanism includes: when there is not enough memory when building a data packet, enabling data compression algorithm to reduce the size of instruction data; when the video stream channel is congested, starting the instruction data priority transmission mode; the receiving end feedback mechanism runs regularly, statistics transmission quality indicators and dynamically adjusts the transmission strategy. All transmission operations record detailed logs, including timestamp, target screen identifier, data packet size, transmission status, etc. The log file is archived regularly. The transmission thread sets a separate watchdog timer, which triggers the exception recovery process when it times out.

[0055] S5, based on the cooperative analysis of the dispersion of the playback progress of each non-blocking screen and the phase deviation of the screen refresh period, the conflict probability of real-time instructions in non-blocking screens is predicted, which is implemented as: The current playback frame number of each non-blocking screen is obtained. The non-blocking screen set is generated by the S2 step and maintained in a dynamic array structure. The frame number acquisition process is implemented through the screen state monitoring interface: for each non-blocking screen in the set, a frame number query instruction is sent to the corresponding display device; the device returns the current playback frame number value through the standard video control channel, which is a 32-bit unsigned integer. For example, the screen identifier display_02 returns the frame number value 12543. The query instruction is transmitted using a preset communication protocol, and the data format is 4 bytes of big-endian frame number. The acquisition operation is completed within a 10 millisecond time window, and if it times out, a retry mechanism is started, with a maximum of 3 retries. All frame number values are stored in a memory array, the array index corresponds to the screen identifier order, and the array length is equal to the number of non-blocking screens.

[0056] The standard deviation of the current frame number of all non-blocking screens is calculated as the playback progress dispersion. The calculation process is divided into three steps: first, calculate the average value of the frame number: accumulate the frame number values of all non-blocking screens and divide by the number of screens, and the result is kept as a double-precision floating-point number. Then calculate the variance: square the difference between the frame number of each screen and the average value, accumulate all squared values and divide by the number of screens. Finally, take the square root of the variance value to get the standard deviation. For example, the frame numbers of 3 non-blocking screens are 100, 102, and 98: the average value is (100+102+98) / 3=100; the variance is ((100-100)²+(102-100)²+(98-100)²) / 3≈2.67; the standard deviation is approximately 1.63 frames. The calculation uses double-precision floating-point operations, and the result is kept to 2 decimal places.

[0057] The rising edge timestamp of the vertical synchronization signal of each non-blocking screen is captured. The vertical synchronization signal is monitored through a dedicated hardware interface, and each non-blocking screen is assigned an independent monitoring channel. The capture process: configure a high-precision timer to trigger an interrupt at the rising edge of the signal; the interrupt service program reads the 64-bit nanosecond-level timer current value as the timestamp; the timestamp is stored in the memory buffer. For example, the rising edge timestamp of screen display_03 is 1638294578123456 nanoseconds. The monitoring accuracy is controlled within ±100 nanoseconds, and the timer clock source uses a temperature-compensated crystal oscillator. The timestamp array is stored in the same sequence as the frame number array to ensure data consistency.

[0058] The difference value of the rising edge timestamp of the vertical synchronization signal of any two non-blocking screens is calculated. The combination traversal algorithm is used: let the number of non-blocking screens be N, then calculate C(N,2) difference values. Traverse all screen pair combinations: for the ith and jth screens (0≤i<j<N), calculate the absolute difference |Ti-Tj| of timestamps Ti and Tj. For example, the timestamp of screen display_02 is 1638294578123456 nanoseconds, and the timestamp of screen display_03 is 1638294578156789 nanoseconds, then the difference value is 33333 nanoseconds. The difference value is stored in a two-dimensional matrix, and the row and column indices of the matrix correspond to the screen index number. The calculation uses 64-bit integer operations, with overflow check protection added.

[0059] Convert the timestamp difference to a phase angle value to derive the screen-to-screen refresh period phase deviation. The conversion process: first, get the standard refresh period value, which is read from the screen EDID data; then calculate the phase angle according to the formula: phase angle = (timestamp difference / refresh period) x 360°. For example, timestamp difference 33333 nanoseconds, refresh period 16666666 nanoseconds (60Hz): phase angle = (33333 ÷ 16666666) x 360 ≈ 0.72°. The calculation result is a floating-point angle value, ranging from 0° to 180° (when the calculated value > 180°, subtract the value by 360°). The conversion operation processes all the difference matrix elements of the screen pair in a loop.

[0060] Establish a collaborative evaluation state table of the playback progress dispersion and the screen-to-screen refresh period phase deviation. The state table is a two-dimensional discrete interval matrix: the horizontal axis of the playback progress dispersion is divided into 3 intervals (interval 1: 0 ≤ dispersion < 1 frame; interval 2: 1 ≤ dispersion < 2 frames; interval 3: dispersion ≥ 2 frames); the vertical axis of the phase deviation is divided into 4 intervals (interval 1: 0° ≤ deviation < 30°; interval 2: 30° ≤ deviation < 60°; interval 3: 60° ≤ deviation < 90°; interval 4: deviation ≥ 90°). The matrix cells are pre-set with conflict probability level enumeration values: low probability level (L), medium probability level (M), high probability level (H). For example, dispersion 1.5 frames (interval 2), phase deviation 45° (interval 2) correspond to a cell set to medium probability level M. The matrix is stored as a memory constant array, which is loaded from the configuration file when the system starts.

[0061] Match the conflict probability level corresponding to the current playback progress dispersion range and screen-to-screen refresh period phase deviation range in the collaborative evaluation state table. The matching process: first, determine the horizontal axis interval index of the dispersion: if the dispersion < 1 frame, the index = 0; if < 2 frames, the index = 1; otherwise, the index = 2. Then determine the vertical axis interval index of the phase deviation: if the deviation < 30°, the index = 0; if < 60°, the index = 1; if < 90°, the index = 2; otherwise, the index = 3. Finally, access the matrix [horizontal index] [vertical index] cell to get the probability level. For example, the current dispersion is 1.8 frames → horizontal index 1, the average phase deviation is 75° → vertical index 2, access the matrix [1] [2] cell to get the probability level. The matching result is written to the state register.

[0062] Map the conflict probability level to a numerical conflict probability. Mapping rules: low probability level (L) corresponds to 0.3, medium probability level (M) corresponds to 0.6, and high probability level (H) corresponds to 0.9. For example, when the matching result is medium probability level M, the conflict probability is set to 0.6. The mapping process is implemented through a constant array: a floating-point number array of [0.3, 0.6, 0.9] is stored in memory, index 0 corresponds to L, 1 corresponds to M, and 2 corresponds to H. The result is stored as a single-precision floating-point number, which is used in step S6.

[0063] The cooperative evaluation state table is implemented by constructing a two-dimensional discretization interval matrix, with the horizontal axis dividing the playback progress discretization interval and the vertical axis dividing the screen refresh cycle phase deviation interval. The matrix construction is based on laboratory test data: the actual instruction conflict frequency under different discretization and deviation combinations is counted in 1000 groups of measured data, and the frequency range is divided into levels. For example, when the discretization is ≥ 2 frames and the deviation is ≥ 90°, the conflict frequency > 80% is set as the high probability level H; when the discretization is < 1 frame and the deviation is < 30°, the conflict frequency < 20% is set as the low probability level L. The matrix data is fixed in the configuration file, which is loaded into the memory during system initialization.

[0064] Each matrix element is preset with a conflict probability level enumeration value. The enumeration type is defined as an integer constant: 0 represents the low probability level (L), 1 represents the medium probability level (M), and 2 represents the high probability level (H). The assignment process is completed during system deployment: based on historical running data analysis reports, the administrator confirms and writes into the configuration file. The enumeration value cannot be modified at runtime to ensure the stability of the evaluation. The matrix data is backed up regularly, retaining the last 10 versions.

[0065] When matching, the current discretization and phase deviation are located to the matrix element to obtain the probability level. The positioning algorithm: for the discretization value, perform interval boundary check: if less than 1, then the horizontal axis index = 0; if less than 2, then the index = 1; otherwise, the index = 2. For the phase deviation value: if less than 30, then the vertical axis index = 0; if less than 60, then the index = 1; if less than 90, then the index = 2; otherwise, the index = 3. For example, discretization 0.5 frames → index 0, phase deviation 100° → index 3, access matrix [0][3] element. Element address = matrix base address + (horizontal axis index × 4 + vertical axis index) × 4 bytes. The positioning process adds input validity check: reject negative input, and out-of-range values are rounded to the nearest boundary interval.

[0066] Data update mechanism: automatically collect running data every 24 hours, when the actual conflict probability of a certain element is more than ± 15% different from the preset level for 5 consecutive days, trigger an alarm and generate an update suggestion. The administrator reviews and updates the matrix enumeration value through the configuration tool, and the update process records audit logs. Matching operation implementation result review: perform double-channel calculation comparison for critical tasks, and enable the backup evaluation strategy when the difference exceeds the limit. All operation records detailed logs, including timestamp, input parameter, matrix coordinate, output level, etc. fields, and the log retention period is 30 days.

[0067] S6, when the conflict probability is less than the preset probability threshold, control the non-blocking screen to execute real-time instructions through a fast response channel independent of the instruction queue, which is implemented as: Read the conflict probability of the non-blocking screen. The conflict probability is calculated by S5 step and stored in the single-precision floating-point number field of the memory shared data area. The read process is implemented through direct memory access: first, according to the non-blocking screen identifier, get the floating-point value at the corresponding index position of the conflict probability array. For example, the conflict probability field value of the screen identifier display_02 is 0.45. The read operation is completed in an atomic transaction to ensure data consistency in a multi-threaded environment, and boundary checks are added when reading: if the value is less than 0, it is considered 0, and if it is greater than 1, it is considered 1. Record the timestamp and probability value to the monitoring log file after each read. The log file uses a circular buffer for storage, with a fixed capacity of 1000 records.

[0068] Get the preset probability threshold. The preset probability threshold is stored in the distributed configuration center and obtained through remote procedure call. The specific process is as follows: establish a connection to the configuration center, and the IP address and port number in the connection parameters are fixed in the system constant; send a query request "GET / config / s6_threshold"; receive the response message and parse the JSON format data, and extract the floating-point value of the threshold field. The threshold setting is based on the results of system stability testing: in the simulation environment, the success rate of instruction execution under different conflict probabilities is counted, and the probability value corresponding to the success rate drop point is selected as the threshold. For example, when the conflict probability exceeds 0.5, the success rate is less than 90%, and the threshold is set to 0.5. The configuration center synchronizes the local cache every 5 minutes, and the local default value 0.4 is used when the network fails.

[0069] Compare the conflict probability with the preset probability threshold. The comparison operation uses the floating-point comparison instruction: subtract the conflict probability value (denoted as Pconflict) from the preset probability threshold (denoted as Tprob), and judge the size relationship according to the operation result. When Pconflict < Tprob (for example, Pconflict = 0.45, Tprob = 0.5), the less than condition is triggered; otherwise, it is not triggered. Set the tolerance parameter 0.001 to avoid floating-point rounding errors that cause misjudgment. The comparison result is written to the condition flag bit of the state register, which is 1 indicating that the condition is established. Check the validity of the probability value before comparison: reject negative input, and truncate the out-of-limit value to 0.0 or 1.0.

[0070] When the conflict probability is less than the preset probability threshold, the operation instruction code of the real-time instruction is parsed. The parsing process reuses the mechanism of S1 step: 4-byte ASCII strings are extracted from the 2nd byte to the 5th byte of the instruction data packet header. For example, for the operation instruction code "PLAY", the string "PLAY" is extracted. The parsing result is stored in the instruction context structure, which includes an operation instruction code buffer, a parameter list pointer and other fields. The parsing process is executed in the protected memory area, and a buffer length check is added: if the instruction code length is less than 4 bytes, it is filled with spaces, and if it exceeds, it is truncated. After parsing, an instruction fingerprint hash value is generated for subsequent matching.

[0071] The operation instruction code is matched with the predefined fast response execution protocol. The predefined protocol is stored in a protocol library, which is a hash table structure: the key is the operation instruction code string (such as "PLAY"), and the value is the protocol structure pointer. The matching process: calculate the hash value of the operation instruction code string (using FNV-1a algorithm); traverse the linked list in the corresponding slot of the hash table, and find the protocol entry by complete string matching. For example, the "PLAY" instruction code matches the fast response execution protocol with protocol ID 101. The protocol structure includes instruction execution function pointer, timeout parameter, retry strategy and other fields. The hash table uses the chain address method to solve the conflict, and the slot number is fixed at 256.

[0072] A fast response thread independent of the instruction queue processing thread is created in a non-blocking screen. The creation process includes: calling the operating system thread creation function; setting the thread attribute to real-time scheduling strategy; allocating dedicated stack space (default 128KB); binding to an independent CPU core (through CPU affinity setting). For example, in the screen display_02, a fast response thread with thread ID 0x3A5F is created. The thread is completely isolated from the instruction queue processing thread: it does not share heap memory, uses an independent file descriptor table, and separates the signal processing space. The thread priority is set to 98 (the highest is 99), which is higher than the priority 50 of the instruction queue thread. If the creation fails, it will be retried at most 2 times with an interval of 10 milliseconds.

[0073] The operation of the real-time instruction is executed by the fast response thread according to the predefined fast response execution protocol. The execution process consists of three steps: first, load the operation function defined by the protocol, and pass in the instruction parameter structure; then directly call the display device driver interface to execute the operation; finally, send the execution result to the instruction state center. For example, for the play instruction, the driver interface player_execute("PLAY", start_time=0) is called. The execution process skips the instruction queue and directly operates the device register: for the play instruction, write to the GPU command register 0x1F00; for the jump instruction, write to the frame address register 0x2C04. The execution timeout is set to 50 milliseconds, and if it exceeds, the thread is terminated and an error code is recorded.

[0074] The predefined rapid response execution protocol is implemented by creating a protocol description file, stored in binary format. The file header contains the protocol ID (4 bytes), instruction code length (1 byte), and parameter template length (2 bytes). The main body includes the instruction code string, parameter parsing rules, and a driver function mapping table. For example, protocol 101 corresponds to the "PLAY" instruction: the parameter template defines two fields (start time 4 bytes, rate 1 byte); the driver mapping points to the function address 0x45B2. At system startup, all protocol files are loaded into an in-memory hash table. File changes are monitored by the file system to trigger a hot update. File checksums are verified during loading, and if failure occurs, the system rolls back to the previous version.

[0075] Execution assurance mechanisms include: a thread watchdog timer (restarting the thread if no response is detected within 30 milliseconds); driver status readback verification (reading the device status register after execution to verify the result); and a retry policy (up to two retries, with an interval of 10 milliseconds). Resource release policy: threads are automatically destroyed upon completion of execution, immediately returning stack memory; network connections are closed immediately after use. Audit logs are maintained throughout the execution process, including fields such as thread ID, screen identifier, instruction code, execution timestamp, and result code. Logs are uploaded to the analysis server in real time. Log files are stored in a rolling manner, retaining the last seven days of data.

[0076] The exception handling system covers: When protocol matching fails, it falls back to standard command queue processing mode; when thread creation fails, allocated resources are released and an alarm event is triggered; and when driver execution errors occur, the device error register value is recorded. Bounds checks are added to all key operations: length and checksum verification is performed when the protocol file is loaded; parameter ranges are verified before driver calls; and safe functions are used in memory operations to prevent overflows. Execution performance monitoring: Command response latency (the time difference between reception and execution completion) is calculated, and performance optimization processes are triggered when it exceeds 100 milliseconds. Monitoring data is sampled every 5 seconds and stored in a time series database.

[0077] Example 2: Figure 2 The present invention provides a structural diagram of a wireless real-time transmission multi-screen video playback control system, which includes: Instruction recognition module, used to identify the current control instruction type and distinguish real-time instructions; A queue detection module is used to detect the length of the instruction queue of each screen when the control instruction is a real-time instruction, and mark the screen whose instruction queue length exceeds a preset length threshold as a blocked screen; A loss quantification module is used to extract the unprocessed instruction sequence that blocks the screen and quantify the time-value loss of the blocked screen based on the association weight between the operation type of the unprocessed instruction sequence and the currently playing content; The policy generation module is configured to generate a cross-screen instruction execution policy and bind the real-time instruction to a video stream channel when the time value loss is greater than the preset loss threshold, and transmit the real-time instruction to the non-blocking screen. The conflict prediction module is configured to predict a conflict probability of the real-time instruction on the non-blocking screen based on a cooperative analysis of the playback progress dispersion of each non-blocking screen and the phase deviation of the screen refresh cycle. The channel execution module is configured to control the non-blocking screen to execute the real-time instruction through a quick response channel independent of the instruction queue when the conflict probability is less than a preset probability threshold.

[0078] In the embodiments, all calculations are dimensionless numerical calculations, and preset parameters and threshold values in the calculations are set by a person skilled in the art according to actual conditions.

[0079] It should be noted that the application can be deployed on a device itself to realize embedded applications, or run on a PC terminal or other terminal with a user interface, thereby meeting various hardware environments and use requirements.

[0080] The above embodiments can be realized by software, hardware, firmware or any combination thereof, in whole or in part. When realized by software, the above embodiments can be realized in the form of a computer program product in whole or in part. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, the processes or functions described in the embodiments of the application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another, for example, the computer instructions can be transferred from one website, computer, server or data center to another through wireless or wired transmission, for example, the wired transmission includes optical fiber, twisted pair, coaxial cable, etc.; the wireless transmission includes infrared, microwave, etc. The computer-readable storage medium can be any available medium accessible by a computer or a data storage device such as a server, data center, etc. containing one or more available medium collections. The available medium can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium. The semiconductor medium can be a solid-state disk.

[0081] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the above-described system, device and module can refer to the corresponding processes in the foregoing method embodiments, which will not be described here.

[0082] In several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented in other manners. For example, the division of the above-described device embodiment is merely an example, and there can be other division manners. For example, the modules or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections can be indirect couplings or communication connections through some interfaces, devices or modules, and can be in electrical, mechanical or other forms.

[0083] The modules illustrated as separated components can or can not be physically separated, and the components illustrated as modules can or can not be physical modules, and can be located in one place, or can be distributed on multiple network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the embodiment.

[0084] In addition, the functional modules in each embodiment of the present application can be integrated in one processing module, or each module can be physically present alone, or two or more modules can be integrated in one module.

[0085] If the functions are realized in the form of software function modules and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application essentially or the part of the prior art that contributes to the technical solutions or the part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various program codes that can be stored in the medium.

[0086] The above description is merely a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, and all should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

[0087] Finally: the above only for the preferred embodiments of the present application, and not for limiting the present application, any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application, should be included in the scope of protection of the present application.

Claims

1. A wireless real-time transmission multi-screen video playback control method, characterized in that: include: S1. Identify the current control instruction type and distinguish real-time instructions; S2. When the control instruction is a real-time instruction, the instruction queue length of each screen is detected, and the screen whose instruction queue length exceeds a preset length threshold is marked as a blocked screen; S3, extracting the unprocessed instruction sequence that blocks the screen, and quantifying the time value loss of the blocked screen based on the association weight between the operation type of the unprocessed instruction sequence and the currently played content; S4. When the loss of the time-effectiveness value is greater than a preset loss threshold, a cross-screen instruction execution strategy is generated and the real-time instruction is bound to the video stream channel and transmitted to the non-blocking screen; S5. Predicting the probability of conflict between real-time instructions on non-blocking screens based on a collaborative analysis of the discreteness of the playback progress of each non-blocking screen and the phase deviation of the refresh cycles between screens; S6. When the conflict probability is less than a preset probability threshold, the non-blocking screen is controlled to execute the real-time instruction through a fast response channel independent of the instruction queue.

2. A wireless real-time transmission multi-screen video playback control method according to claim 1, characterized in that: Identify the current control instruction type and distinguish real-time instructions, including: Extracting an operation instruction code of a control instruction; Perform feature matching between the operation instruction code and a predefined real-time instruction feature library; When the operation instruction code matches at least one real-time instruction feature in the predefined real-time instruction feature library, determining that the control instruction is a real-time instruction; When the operation instruction code does not match any real-time instruction feature in the predefined real-time instruction feature library, the control instruction is determined to be a non-real-time instruction.

3. The method for controlling wireless real-time transmission of multi-screen video playback according to claim 1, wherein: When the control instruction is a real-time instruction, the instruction queue length of each screen is detected, and the screen whose instruction queue length exceeds the preset length threshold is marked as a blocked screen, including: Obtain the number of unprocessed real-time instructions in the instruction queue of each screen as the instruction queue length; Read the preset length threshold; Compare the length of the command queue of each screen with a preset length threshold; When the instruction queue length of a screen is greater than a preset length threshold, the corresponding screen is added to the blocked screen set; When the instruction queue length of a screen is less than or equal to a preset length threshold, the corresponding screen is not added to the blocked screen set.

4. The method for controlling wireless real-time transmission of multi-screen video playback according to claim 1, wherein: Extract the unprocessed instruction sequence that blocks the screen, and quantify the time-value loss of the blocked screen based on the association weight between the operation type of the unprocessed instruction sequence and the currently playing content, including: Extract all unprocessed control instructions from the instruction queue blocking the screen to form an unprocessed instruction sequence; identifying an operation type of each control instruction in the unprocessed instruction sequence; Get the scene classification label of the currently playing content; Query the predefined weight mapping table to obtain the associated weight value of the operation type and the scene classification label; Accumulating the association weight values ​​of all control instructions in the unprocessed instruction sequence to obtain the total association weight sum; Calculate the negative natural logarithm of the total associated weights as the instruction value entropy; The instruction value entropy is used as the quantitative result of time value loss.

5. A wireless real-time transmission multi-screen video playback control method according to claim 4, characterized in that: The predefined weight mapping table is implemented in the following way: Create a two-dimensional relational database table with the row index being the operation type and the column index being the scene classification label; Each cell stores a floating-point associated weight value; When querying, the corresponding cell value is retrieved based on the operation type and scene classification label.

6. The method for controlling wireless real-time transmission of multi-screen video playback according to claim 1, characterized in that: When the loss of timeliness value exceeds the preset loss threshold, a cross-screen instruction execution strategy is generated and the real-time instruction is bound to the video stream channel and transmitted to the non-blocking screen, including: Read the quantitative results of time-based value loss; Get the preset loss threshold; Compare the quantified result of the time-value loss with the preset loss threshold; When the quantified result of the timeliness value loss is greater than a preset loss threshold, a cross-screen instruction data packet containing real-time instructions is constructed; Add a cross-screen instruction data packet identification field to the transmission protocol header of the video stream channel; Encapsulate the cross-screen instruction data packet into the payload data area of ​​the video stream channel; Transmit the encapsulated video stream data to all non-blocking screens through the video stream channel.

7. The method for controlling wireless real-time transmission of multi-screen video playback according to claim 1, characterized in that: Based on the collaborative analysis of the discreteness of the playback progress of each non-blocking screen and the phase deviation of the refresh cycle between screens, the conflict probability of real-time instructions on non-blocking screens is predicted, including: Get the current playback frame number of each non-blocking screen; Calculate the standard deviation of the current playback frame numbers of all non-blocking screens as the playback progress dispersion; Capture the rising edge timestamp of the vertical synchronization signal of each non-blocking screen; Calculate the difference in timestamps of the rising edges of the vertical synchronization signals of any two non-blocking screens; Convert the timestamp difference into a phase angle value to obtain the phase deviation of the refresh cycle between screens; Establish a collaborative evaluation state table of the playback progress discreteness and the refresh cycle phase deviation between screens; Match the conflict probability level corresponding to the current playback progress discrete range and the inter-screen refresh cycle phase deviation range in the collaborative evaluation state table; Map the conflict probability level to a numerical conflict probability.

8. The method for controlling wireless real-time transmission of multi-screen video playback according to claim 7, characterized in that: The collaborative evaluation status table is implemented in the following ways: Construct a two-dimensional discretization interval matrix, with the horizontal axis dividing the playback progress discreteness interval and the vertical axis dividing the refresh cycle phase deviation interval between screens; Each matrix unit is preset with an enumeration value of the conflict probability level; During matching, the current discreteness and phase deviation are located in the matrix unit to obtain the probability level.

9. The method for controlling wireless real-time transmission of multi-screen video playback according to claim 1, wherein: When the conflict probability is less than the preset probability threshold, the non-blocking screen is controlled to execute real-time instructions through a fast response channel independent of the instruction queue, including: Read the conflict probability of real-time instructions on the non-blocking screen; obtain the preset probability threshold; Numerically comparing the probability of conflict with a preset probability threshold; When the conflict probability is less than a preset probability threshold, parsing the operation instruction code of the real-time instruction; Matching predefined quick response execution protocols according to operation instruction codes; Create a fast response thread independent of the instruction queue processing thread in the non-blocking screen; Execute real-time instruction operations through the fast response thread according to the predefined fast response execution protocol.

10. A wireless real-time transmission multi-screen video playback control system, used to implement the wireless real-time transmission multi-screen video playback control method according to any one of claims 1 to 9, characterized in that: include: Instruction recognition module, used to identify the current control instruction type and distinguish real-time instructions; A queue detection module is used to detect the length of the instruction queue of each screen when the control instruction is a real-time instruction, and mark the screen whose instruction queue length exceeds a preset length threshold as a blocked screen; A loss quantification module is used to extract the unprocessed instruction sequence that blocks the screen and quantify the time-value loss of the blocked screen based on the association weight between the operation type of the unprocessed instruction sequence and the currently playing content; A strategy generation module is used to generate a cross-screen instruction execution strategy and bind the real-time instruction to the video stream channel and transmit it to the non-blocking screen when the time value loss is greater than a preset loss threshold; The conflict prediction module is used to predict the probability of conflict between real-time instructions on non-blocking screens based on the collaborative analysis of the discreteness of the playback progress of each non-blocking screen and the phase deviation of the refresh cycle between screens; The channel execution module is used to control the non-blocking screen to execute real-time instructions through a fast response channel independent of the instruction queue when the conflict probability is less than a preset probability threshold.

Images