Multi-device collaborative interaction method and system for digital multimedia

Abstract

The invention provides a multi-device cooperative interaction method and system for digital multimedia, and relates to the technical field of digital multimedia processing, and the method comprises the steps: firstly analyzing the user interaction demands of to-be-processed digital multimedia contents, and disassembling the user interaction demands into presentation, transmission and operation demand dimensions; acquiring capability information of to-be-coordinated equipment to form an equipment capability list; calculating the degree of adaptation according to the demand disassembly result and the equipment capability list, and constructing a collaborative interaction link; issuing an operation instruction according to the collaborative interaction link, and obtaining interaction result data; and adjusting an adaptation degree calculation standard and link node configuration based on the interaction result data to realize dynamic optimization. According to the method, user requirements and equipment capabilities are comprehensively considered, multi-equipment efficient collaboration is realized, and digital multimedia processing experience is improved.

Description

Technical Field

[0001] This application relates to the field of digital multimedia processing technology, and more specifically, to a method and system for multi-device collaborative interaction in digital multimedia. Background Technology

[0002] With the increasing prevalence of digital multimedia applications, users' demands for processing digital multimedia content are becoming more diverse and complex. Traditional digital multimedia processing methods are often limited to single devices. For example, when watching videos, users can only play them through a single device such as a TV or computer, failing to fully utilize the advantages of other devices to enhance the viewing experience. Even in situations where multiple devices work together, there is a lack of scientific and reasonable methods to guide the collaborative work between devices.

[0003] Existing multi-device collaboration solutions typically just distribute digital multimedia content across different devices according to preset rules, without fully considering users' diverse interactive needs for this content. For example, in terms of presentation, different devices may have different display resolutions and color performance capabilities, but existing solutions cannot rationally allocate presentation tasks based on these differences. Regarding transmission, different devices have varying network transmission capabilities and bandwidths, making it difficult for existing solutions to dynamically adjust transmission strategies based on actual transmission conditions. Finally, in terms of operation, different devices have different operating methods and levels of convenience, and existing solutions cannot optimize the operation process based on user habits and device characteristics. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a method and system for multi-device collaborative interaction in digital multimedia.

[0005] According to a first aspect of this application, a multi-device collaborative interaction method for digital multimedia is provided, the method comprising: Analyze the user interaction requirements of the digital multimedia content to be processed, and decompose the user interaction requirements into presentation requirements, transmission requirements, and operation requirements, and generate requirements dimension decomposition results. Collect capability information of multiple devices to be coordinated, and form a device capability list based on the capability information. The capability information includes specific capability items of the devices in terms of presentation, transmission and operation. Based on the breakdown results of the demand dimensions and the equipment capability list, the adaptability of each device to different demand dimensions is calculated, and a digital multimedia multi-device collaborative interaction link is constructed based on the adaptability. According to the multi-device collaborative interaction link, interactive operation instructions are sent to each device to be collaborated with, guiding each device to perform corresponding digital multimedia processing actions and obtaining interactive result data fed back by the device processing actions; Based on the interaction result data, the calculation standard for the adaptability of each device to different demand dimensions is adjusted, as well as the node configuration of the multi-device collaborative interaction link, to achieve dynamic optimization of multi-device collaborative interaction.

[0006] According to a second aspect of this application, a multi-device collaborative interaction system for digital multimedia is provided. The multi-device collaborative interaction system for digital multimedia includes a machine-readable storage medium and a processor. The machine-readable storage medium stores machine-executable instructions. When the processor executes the machine-executable instructions, the multi-device collaborative interaction system for digital multimedia implements the aforementioned multi-device collaborative interaction method for digital multimedia.

[0007] According to a third aspect of this application, a computer-readable storage medium is provided, wherein computer-executable instructions are stored therein, and when the computer-executable instructions are executed, the aforementioned multi-device collaborative interaction method for digital multimedia is implemented.

[0008] Based on any of the above aspects, the technical effect of this application is as follows: By analyzing the user interaction requirements of the digital multimedia content to be processed and breaking them down into presentation, transmission, and operation dimensions, the system collects capability information from multiple devices to be coordinated, forming a device capability list. This details the specific capabilities of each device in presentation, transmission, and operation. Based on the breakdown of requirement dimensions and the device capability list, the system calculates the adaptability of each device to different requirement dimensions and constructs a multi-device collaborative interaction link for digital multimedia. This fully leverages the strengths of each device, optimizes resource allocation, and ensures that digital multimedia content is processed and presented most appropriately on different devices. Interactive operation commands are issued to each device according to the collaborative interaction link, and interaction result data is acquired. Based on this data, the system dynamically adjusts the adaptability calculation standard and the configuration of interaction link nodes. This allows for real-time adjustments to the collaboration strategy based on actual conditions, continuously adapting to changes in device and user needs. This significantly improves the efficiency, quality, and flexibility of multi-device collaborative interaction, providing users with a superior and more efficient digital multimedia processing experience. Attached Figure Description

[0009] Figure 1 A flowchart illustrating a multi-device collaborative interaction method for digital multimedia provided in an embodiment of this application is shown. Figure 2 This illustration shows a schematic diagram of the component structure of a multi-device collaborative interaction system for digital multimedia, provided in an embodiment of this application, for implementing the above-described multi-device collaborative interaction method for digital multimedia. Detailed Implementation

[0010] Figure 1This application provides a flowchart illustrating a multi-device collaborative interaction method and system for digital multimedia, with detailed steps including: Step S110: Analyze the user interaction requirements of the current digital multimedia content to be processed, and decompose the user interaction requirements into presentation requirement dimension, transmission requirement dimension and operation requirement dimension, and generate requirement dimension decomposition results.

[0011] In this embodiment, we take the digital operation scenario of a large offline chain supermarket as an example. The digital multimedia content to be processed in this scenario includes real-time promotional video streams and dynamic product price tag data. This requires the coordinated interaction of multiple devices, such as the entrance LED screen, electronic price tags on each shelf, handheld terminals for sales staff, and self-service inquiry machines for customers, to achieve accurate delivery of promotional information and shopping guidance. The following will provide a detailed explanation of each step in this scenario.

[0012] Step S111: Obtain the content attributes of the digital multimedia content to be processed, wherein the content attributes include content type, content carrier form and content data characteristics.

[0013] In the aforementioned smart supermarket operation scenario, the digital multimedia content to be processed currently includes two core types of data: First, promotional activity video streams, which are dynamic videos stored on the supermarket's local server. Data characteristics include video encoding method, keyframe interval, average bitrate, and audio sampling frequency. Second, dynamic product price tag data, which is a combination of structured text and static images, updated in a structured format as a real-time data stream. Data characteristics include the number of fields, update frequency, data checksum length, and image compression algorithm. Through the content management system interface, the specific parameter values ​​of the above content attributes can be extracted to form a content attribute description document. This document is stored in a markup language format and includes a unique content identifier, attribute category label, parameter name, and corresponding parameter value fields.

[0014] Step S112: Determine the types of interactive behaviors that users may generate based on the content attributes. The types of interactive behaviors include viewing behaviors, editing behaviors, and sharing behaviors.

[0015] Step S1121: Based on the mapping relationship between content type and predefined interaction behavior type, determine the set of basic interaction behavior types corresponding to the content type. The predefined interaction behavior type mapping relationship specifies the basic behavior types of viewing, editing, and sharing associated with video content, audio content, image content, and text content, respectively.

[0016] In the rule configuration section of the store's intelligent management platform, predefined interaction behavior type mapping relationships are stored in a structured table format. The table includes a content type name, a list of basic behavior types, and a behavior trigger condition column. For example, in the table row corresponding to video content, the basic behavior type list field values ​​are "watching behavior" and "sharing behavior," and the behavior trigger condition field values ​​are "video playback duration reaches a certain percentage of the total duration." After obtaining the content type name of the kitchen food preparation progress video stream, the structured table in the rule configuration section is traversed to match the corresponding set of basic behavior types as "watching behavior." This set is stored in a list format, with each list item containing a behavior type name, behavior code, and priority sorting field.

[0017] Step S1122: Based on the content carrier form, activate or deactivate a specific behavior type in the set of basic interactive behavior types. If the content carrier form is mobile terminal storage, activate the offline editing behavior type; if the content carrier form is cloud storage, activate the online sharing behavior type.

[0018] The data from the real-time ordering interface is stored on the store's local server. By querying the data carrier and the behavior activation rule base, the corresponding rule for the local server storage is "Allow activation of offline editing behavior types." This entry in the rule base includes fields such as data carrier name, behavior type operation, target behavior type name, and permission verification level. First, it verifies whether the current user role meets the permission verification level requirements. After successful verification, it calls the behavior type set operation interface to change the status field of the offline editing behavior type in the basic behavior type set list from disabled to enabled, thus activating the behavior type. The data carrier for member marketing activity graphic information is cloud storage, and the corresponding rule in the rule base is "Activate online sharing behavior types." Therefore, an online sharing behavior type entry is added to its basic behavior type set.

[0019] Step S1123: Based on the content data characteristics, adjust the technical implementation requirements of specific behavior types in the set of basic interactive behavior types. If the content data volume exceeds the preset upper limit threshold, it is a high transmission efficiency requirement associated with the sharing behavior type; if the content data volume is lower than the preset lower limit threshold, it is a high operation response speed requirement associated with the editing behavior type.

[0020] The number of UI components in the content data characteristics of the real-time ordering interface exceeds a preset data volume limit (this threshold is stored in the performance parameter node of the system configuration file). According to the mapping rules between content data characteristics and behavioral technical requirements, when the data volume exceeds the upper limit, high transmission efficiency requirements must be associated with the editing behavior type. This includes setting the data transmission protocol to a high-efficiency protocol, enabling data compression, and setting an upper limit for the size of transmitted data packets. These parameters are written into the technical requirement configuration file for the editing behavior type by calling the behavioral technical requirement configuration interface. This file contains fields such as protocol type, compression algorithm, and packet size limit. The data volume of the dynamic product price tag data is below a preset lower limit threshold; therefore, high operation response speed requirements are associated with its viewing behavior type, configuring parameters such as touch response latency limit and data loading progress feedback frequency.

[0021] Step S1124: Integrate the interactive behavior types after adjustment by content type, content carrier form and content data characteristics to form the final set of interactive behavior types that users may generate.

[0022] The interactive behavior types of three categories of digital multimedia content, after content type matching, carrier format activation / deactivation, and data feature adjustment, are summarized and merged. For real-time ordering interface data, the interactive behavior types are viewing, editing, and sharing; the video stream of food preparation progress in the kitchen is a viewing behavior; and the graphic information of member marketing activities is a viewing and sharing behavior. During the merging process, duplicate behavior type entries are removed, and all non-duplicate behavior types are retained, ultimately forming a set of possible user interactive behavior types that includes viewing, editing, and sharing behaviors. This set is stored in a structured format, containing an array of behavior type names, an array of applicable content types for each behavior type, and a technical requirements configuration file path field.

[0023] Step S1125: Perform validity verification on the final set of interactive behavior types to ensure that each behavior type in the set has corresponding technical implementation support. If there is a behavior type that is not supported by the technical implementation, remove the behavior type from the set.

[0024] The technical support verification section connects to the device capability database of the store's digital management platform to query whether there are devices that support the technical implementation requirements for each type of interaction behavior in the set. For example, when verifying editing behaviors, it checks whether there are devices with editing functions and whether their hardware configuration meets the resource requirements for editing operations; when verifying sharing behaviors, it checks whether there are devices with network connectivity modules that support sharing protocols. If a certain behavior type is found to be unsupported by any device, it is removed from the set of interaction behavior types, and the reason for removal is recorded in the verification report.

[0025] Step S113: For each type of interaction behavior, collect the user's expectation information for that type of interaction behavior. The expectation information includes the user's requirements for the effect, efficiency and method of the behavior.

[0026] In the context of digital operations in restaurants, for viewing behaviors, a user experience feedback component is embedded in the smart terminal at the dining table. When customers view menu information, a pop-up window for collecting expected information is triggered. This includes satisfaction with the display of menu images (performance effect requirement), acceptable loading speed of menu information (performance efficiency requirement), and preferred browsing method (performance method requirement). For editing behaviors, the operation logs of waiters' handheld ordering devices are analyzed to extract data such as the distribution of operation time when modifying order information (performance efficiency requirement), suggestions for simplifying operation steps (performance method requirement), and accuracy requirements for order modifications (performance effect requirement). For sharing behaviors, the operation records of customers using the smart terminal at the dining table to share promotional activities are analyzed to collect expected information such as the speed of generating sharing links (performance efficiency requirement), the completeness of shared content (performance effect requirement), and the diversity of sharing channels (performance method requirement). The collected expected information is stored in a structured document format in a user expectation database. The document includes a behavior type identifier, requirement dimension tag, specific description of the requirement, and the time field when the requirement was submitted.

[0027] Step S114: Divide the expected information into presentation requirement dimension, transmission requirement dimension and operation requirement dimension according to the core elements affecting the realization of interaction.

[0028] The process involves classifying and processing requests based on their dimensions. This section incorporates a core element recognition algorithm. The algorithm takes the desired information text and quantifiable metrics as input and extracts keyword feature vectors using natural language processing. These keyword feature vectors are then compared to the core feature word vector libraries of the three request dimensions for similarity calculation. For example, in viewing-related behaviors, the keyword "dishes image display effect" has a high similarity to the core feature word vector of "visual presentation quality" in the presentation request dimension, thus classifying it as a presentation request dimension. Similarly, the keyword "dishes information loading speed" has a high similarity to the core feature word vector of "data transmission efficiency" in the transmission request dimension, classifying it as a transmission request dimension. Finally, the keyword "information browsing method preference" has a high similarity to the core feature word vector of "interactive operation method" in the operation request dimension, classifying it as an operation request dimension. After classification, a request dimension attribution report is generated. This report includes the original ID of each desired piece of information, the name of its corresponding dimension, the matching core feature words, and the similarity calculation result fields.

[0029] Step S115: Refine the presentation requirement dimension and extract the specific requirements under the presentation requirement dimension, including content image clarity requirements, image color reproduction requirements, image smoothness requirements, and image size adaptation requirements.

[0030] Based on the expected information in the presentation requirement dimension attribution report, the requirement item refinement process is invoked. For content image clarity requirements, the clarity requirements for different dish categories are extracted from the "satisfaction with dish image display effect" expectation information. For example, fresh dish images need to meet high-clarity requirements, while staple food images can meet medium-clarity requirements. Image color reproduction requirements are extracted from customer feedback on the difference between dish images and actual colors, including color saturation requirements for red dishes, hue accuracy requirements for green dishes, and brightness uniformity requirements for white dishes. Image smoothness requirements are refined based on smoothness feedback data during dynamic ordering interface transitions, into interface transition frame rate requirements, animation transition smoothness requirements, and scrolling loading smoothness requirements. Image size adaptation requirements are combined with different device screen parameters to extract image scaling ratio requirements, layout adaptive adjustment requirements, and font size adaptation requirements for different devices. Each specific requirement item includes a requirement item name, requirement description text, quantitative indicator range, and priority identifier field.

[0031] Step S116: Refine the transmission requirement dimension and extract the specific requirement items under the transmission requirement dimension, including content data transmission speed requirements, data integrity requirements during transmission, transmission delay control requirements, and transmission synchronization requirements between multiple devices.

[0032] Based on the transmission requirement dimension attribution report, a detailed analysis process for transmission requirements was initiated. Content data transmission speed requirements were extracted from the expected information of "acceptable range for menu information loading speed," including initial loading speed requirements, secondary loading caching speed requirements, and dynamic data update transmission speed requirements. Data integrity requirements during transmission were refined based on order data transmission error feedback cases, into data verification method requirements, error retransmission mechanism requirements, and data backup storage requirements. Transmission latency control requirements were extracted based on real-time feedback from kitchen and front-of-house data interaction, including order submission latency requirements, menu preparation progress update latency requirements, and member information synchronization latency requirements. Multi-device transmission synchronization requirements were refined based on multi-terminal display consistency feedback, into data update timestamp synchronization requirements, cross-device operation status synchronization requirements, and offline data synchronization strategy requirements. Each specific requirement item includes a requirement item code, detailed requirement description, compliance judgment criteria, and non-compliance handling plan fields.

[0033] Step S117: Refine the operation requirement dimension and extract the specific requirement items under the operation requirement dimension, including user operation trigger response speed requirements, operation command synchronization requirements across multiple devices, operation permission division requirements, and operation result feedback method requirements.

[0034] Based on the operational requirement dimension attribution report, the operational requirement item extraction process is executed. User operation trigger response speed requirements are extracted from the operational smoothness feedback in "Information Browsing Method Preferences," including touch operation response latency requirements, button operation response time requirements, and voice operation recognition response speed requirements. Operation command synchronization requirements across multiple devices are refined based on feedback from waiters' multi-terminal collaborative operations, into command synchronization latency requirements, synchronization failure handling requirements, and conflict command resolution strategy requirements. Operation permission division requirements are extracted based on feedback from the operational scope of different user roles, including role permission definition requirements, permission change approval requirements, and unauthorized operation interception requirements. Operation result feedback method requirements are extracted from user feedback on their awareness of the operation results, including visual feedback method requirements, auditory feedback method requirements, and tactile feedback method requirements. Each specific requirement item includes a requirement item name, applicable scenario description, feedback method options, and priority sorting field.

[0035] Step S118: Mark the priority of each specific requirement item under each requirement dimension. The priority is determined by the user's emphasis on the requirement item and the degree of impact of the requirement item on the interactive experience.

[0036] The requirement priority labeling section connects the user feedback database and the interaction experience evaluation model. First, it extracts the user mention frequency and satisfaction rating data for each specific requirement from the user feedback database to calculate a user importance index. Second, it analyzes the impact weight of each requirement on the overall interaction experience using the interaction experience evaluation model. The impact weight is calculated based on changes in user churn rate when a requirement fails to meet its criteria. Combining the user importance index and the impact weight, a weighted summation method is used to calculate the priority score for each requirement. The priority score is calculated as a certain proportion of the user importance index and the impact weight. Based on the priority score, requirements are divided into three priority levels: high, medium, and low. Requirements with higher scores are considered high priority, those in the middle range are medium priority, and those with lower scores are low priority. After labeling, each requirement is appended with a priority level field, a priority score field, and a scoring basis explanation field.

[0037] Step S119: Integrate the presentation requirement dimension, transmission requirement dimension, operation requirement dimension, and their specific requirement items and requirement priorities to form the requirement dimension decomposition result.

[0038] The process of integrating and processing demand dimensions is initiated, categorizing and summarizing the specific demand items for presentation, transmission, and operation dimensions. Each dimension includes a dimension name, dimension description, and a list of specific demand items. Each element in the list of specific demand items includes a demand item name, demand description, quantifiable indicator, priority level, and priority score. During the integration process, duplicate or conflicting demand items are merged and coordinated. For example, screen display-related demand items involved in both the presentation and operation demand dimensions are uniformly merged into the presentation demand dimension. The final demand dimension breakdown results are stored in a standardized document format. The document includes the breakdown result version number, generation time, number of dimensions, total number of demand items, and detailed content chapters for each dimension. This document is stored in the demand management section of the store's digital management platform as the basis for subsequent equipment capability matching and collaborative link construction.

[0039] Step S120: Collect capability information of multiple devices to be coordinated, and form a device capability list based on the capability information. The capability information includes specific capability items of the devices in terms of presentation, transmission and operation.

[0040] In the context of digital operation in catering establishments, the devices requiring collaboration include smart terminals at dining tables, large display screens in the kitchen, handheld ordering devices for waiters, welcome advertising screens at the entrance, and self-service inquiry kiosks for customers. Through the device management section of the store's digital management platform, capability information collection requests are sent to these devices to gather specific capabilities in presentation, transmission, and operation. The collection process uses a polling method, sending requests sequentially according to device addresses. Each device has a set response timeout; if no response is received within the timeout period, a second request is made. If the second request also fails to elicit a response, the device is marked as offline. The collected capability information is then organized into a device capability list, which includes fields for basic device information, a list of presentation capabilities, a list of transmission capabilities, and a list of operational capabilities.

[0041] Step S121: Establish a communication connection with multiple devices to be coordinated, and send a capability information collection request to each device. The request specifies the capability categories to be collected as presentation capability, transmission capability, and operation capability.

[0042] The device communication component of the store's intelligent management platform first initiates a communication connection establishment process with each device to be coordinated, using a network protocol and a preset device communication port number. After a successful connection, the device communication component generates a capability information collection request data packet. This packet includes a request identifier, request timestamp, a list of capability categories (presentation capabilities, transmission capabilities, operational capabilities), data format requirements, and a response deadline field. This data packet is then sent to each device through the established connection, in order of device importance. During the sending process, the sending status is monitored in real time, recording the request sending time, sending result, and failure reason field for each device.

[0043] Step S122: Receive basic capability data from each device based on the capability information collection request. The basic capability data includes device hardware configuration information, software function support information, and historical collaborative interaction performance data.

[0044] Upon receiving a capability information collection request, each device to be collaborated with initiates its local capability information collection program to gather its own basic capability data. Device hardware configuration information includes processor model, memory capacity, storage capacity, display parameters, network interface type, and input / output device type; software function support information includes operating system version, supported application programming interfaces (APIs), pre-installed functional modules, and software update dates; historical collaborative interaction performance data includes average response time, data transmission success rate, operation execution accuracy rate, and device online time percentage over a certain period. The device encapsulates the collected basic capability data according to the format specified in the request, generating a response data packet. This data packet includes a device identifier, response timestamp, basic capability data field, and data verification code field. The device communication section of the store's digital management platform receives the response data packets from each device, records the reception time, data size, and verification code result field, and requests the device to resend data packets that fail verification.

[0045] Step S123: Extract specific capability items related to presentation capabilities from the basic capability data, including the maximum screen resolution supported by the device, the frame rate range that the device can output, the color processing capability range of the device, the screen scaling mode supported by the device, and the screen display response speed of the device.

[0046] The rendering capability extraction algorithm is invoked, which parses the hardware configuration information and software function support information from the basic capability data. It extracts the maximum supported screen resolution from the display parameters; the frame rate range that the device can output from the display driver information; the color processing capability range of the device from the color management module information; the screen scaling modes supported by the device from the graphics processing software function information; and the screen display response speed of the device from the display response time test data. Each rendering capability item includes a capability name, capability value range, unit, and support status fields.

[0047] Step S124: Extract specific capability items related to transmission capabilities from the basic capability data, including the device's maximum data transmission rate, the device's packet loss rate in different network environments, the device's recovery speed after transmission interruption, the types of transmission protocols supported by the device, and the device's ability to transmit multiple data streams simultaneously.

[0048] Initiate the transmission capability extraction process, analyzing network interface information and historical collaborative interaction performance data from the basic capability data. Extract the device's maximum data transmission rate from network interface parameters; statistically analyze the device's packet loss rate under different network environments from historical transmission records; extract the device's recovery speed after transmission interruption from transmission fault recovery logs; extract the types of transmission protocols supported by the device from network protocol stack information; and extract the device's ability to transmit multiple data streams simultaneously from multi-task processing records. Each transmission capability item includes a capability item name, test conditions, capability index value, and stability rating fields.

[0049] Step S125: Extract specific capability items related to operational capabilities from the basic capability data, including the response time of the device after receiving the operation command, the delay of the device synchronizing the operation command to other devices, the types of operation commands supported by the device, the device's ability to set operation permissions, and the method of the device to provide feedback on operation results.

[0050] The operation capability extraction section processes the input / output device information, software function support information, and historical collaborative interaction performance data from the basic capability data. It extracts the device's response time after receiving an operation command from the operation response test data; the latency of synchronizing operation commands to other devices from the multi-device collaboration logs; the types of operation commands supported by the device from the input processing module information; the device's ability to set operation permissions from the permission management module information; and the method of the device providing feedback on operation results from the output feedback module information. Each operation capability item includes a capability name, capability description, supported operation scenarios, and performance indicator fields.

[0051] Step S126: Verify the authenticity of the extracted presentation capability items, transmission capability items, and operation capability items of each device. The verification method is to compare the consistency between the device's historical capability data and the current feedback data, and to verify the matching degree between the device's actual capability and the feedback capability items through test data with a preset amount of data.

[0052] Step S1261: Extract the device's past presentation capability data, transmission capability data, and operation capability data from the device's historical collaborative interaction records to form a device historical capability dataset.

[0053] The historical data query section of the store's intelligent management platform connects to the device's historical database, allowing users to retrieve capability data records for a specific device over a given period based on its identifier. The historical capability data includes daily recorded maximum screen resolution, average frame rate, and color error values; transmission capability data includes daily recorded average transmission rate, packet loss rate, and interruption recovery time; and operational capability data includes daily recorded operation response time, command synchronization latency, and permission setting success rate. The retrieved data is organized by capability category and date to form a device historical capability dataset. This dataset includes fields for capability category, date, capability item name, capability value, and data source.

[0054] Step S1262: Compare the presentation capability items, transmission capability items, and operation capability items extracted from the basic capability data with the corresponding data in the device's historical capability dataset item by item.

[0055] The capability comparison section reads the currently extracted capability data and the device's historical capability dataset, matching them item by item according to capability category and capability name. For numerical capability items, it calculates the absolute difference between the current value and the historical average; for range-based capability items, it checks whether the current range includes the historical range; for enumerated capability items, it checks whether the current set of supported types matches the historical set. During the comparison process, it records the comparison results and descriptions of differences for each capability item.

[0056] Step S1263: Calculate the deviation between the current capability item and the historical capability data. If the deviation is within the preset allowable deviation range, the current capability item is determined to have passed the verification at the historical data comparison level. If the deviation exceeds the preset allowable deviation range, the current capability item is marked as an item to be further verified.

[0057] For numerical capabilities, the deviation is calculated by dividing the difference between the current value and the historical average by the historical average to obtain a percentage deviation. For range-based capabilities, the deviation is calculated as the sum of the differences between the current upper and lower limits and the historical upper and lower limits. For enumeration-based capabilities, the deviation is calculated as the sum of the number of currently missing historical types and the number of currently present types that were present in the past. Preset allowable deviation ranges are stored in the validation rule configuration file. For example, the allowable deviation range for numerical capabilities is a certain percentage interval; for range-based capabilities, the allowable deviation range is that the sum of the differences between the upper and lower limits does not exceed a certain proportion of the historical range; and for enumeration-based capabilities, the allowable deviation range is that the number of difference types is zero. The calculated deviation value is compared with the preset allowable range. If it is within the range, the validation passes; otherwise, it is marked as an item requiring further validation.

[0058] Step S1264: For all capability items, generate test data with a preset data volume. The test data with the preset data volume must cover the core parameter requirements of each capability item. For the maximum screen resolution capability item in the presentation capability item, it includes test images with different resolution specifications; for the maximum data transmission rate capability item in the transmission capability item, it includes test files of different sizes; for the operation response time capability item in the operation capability item, it includes different types of test operation instructions.

[0059] The test data generation section generates test data based on the core parameter requirements of each capability item. For presentation capabilities, test images of different resolutions are generated, including standard color test cards, grayscale gradient patterns, and detailed real-world images. For transmission capabilities, test files of different sizes are generated, containing random binary data and data verification information. For operational capabilities, different types of test operation instructions are generated, including fields for operation type, coordinate location, trigger time, and expected response content. The test data volume is generated according to the standard of at least multiple sets of test data for each capability item, ensuring coverage of the minimum, standard, and maximum requirements for each capability item.

[0060] Step S1265: Send the generated test data of the preset data volume to the corresponding device to be coordinated, and require the corresponding device to perform corresponding actions according to the requirements of the test data of the preset data volume. The corresponding actions to be performed by the corresponding device include displaying test images, transmitting test files, and responding to test operation instructions.

[0061] The test data transmission component sends test data through the established connection with the device to be collaborated with. The transmission order is as follows: first, presentation capability test data; then, transmission capability test data; and finally, operational capability test data. Before sending each type of test data, a test instruction data packet is sent. This instruction data packet contains fields for test type, test data size, test steps, and expected completion time. After receiving the test instruction, the device to be collaborated with prepares to execute the corresponding action: for presentation capability testing, it calls the display driver to display the test image on the screen; for transmission capability testing, it calls the network transmission module to receive the test file and send back confirmation information; for operational capability testing, it simulates receiving test operation instructions and executing the corresponding operation.

[0062] Step S1266: Record the actual performance data of the corresponding device to be coordinated when performing the corresponding action. The actual performance data of the corresponding device to be coordinated includes the actual resolution when displaying the test image, the actual transmission rate when transmitting the test file, and the actual response time when responding to the test operation command.

[0063] The performance recording section collects actual device performance data through multiple methods: For presentation capability testing, test images are captured by an image acquisition device connected to the device, and the actual resolution, color reproduction, and detail clarity of the images are analyzed; for transmission capability testing, the start time, completion time, and received data verification results of the test file transmission are recorded, and the actual transmission rate and transmission success rate are calculated; for operational capability testing, the time of operation command transmission, device response start time, and response completion time are recorded, and the actual response time and operation execution accuracy are calculated. Actual performance data records are organized by test type and test number, and include fields for test type, test number, actual performance value, and whether the standard is met.

[0064] Step S1267: Compare the actual performance data of the corresponding device to be coordinated with the corresponding capability item fed back by the current device. If the actual performance data meets the requirements of the capability item description, the current capability item is determined to have passed the actual test verification. If the actual performance data does not meet the requirements of the capability item description, the current capability item is determined to have failed the verification.

[0065] The performance data comparison section compares the actual performance data with the requirements of each feedback capability item. For example, the maximum screen resolution requirement in the presentation capability item is a specific pixel value; if the actual test image resolution reaches this value and is clearly displayed, the verification passes. The maximum data transmission rate requirement in the transmission capability item is a specific rate value; if the actual transmission rate reaches this value and remains so for a certain period, the verification passes. The operation response time requirement in the operation capability item is less than a specific number of milliseconds; if the actual response time is less than this value, the verification passes. During the comparison process, the comparison results, actual values, required values, and percentage difference fields for each capability item are recorded.

[0066] Step S1268: For items marked for further verification in the historical data comparison, if the verification is successful at the actual testing level, the current capability item is retained; if the verification fails at the actual testing level, the current capability item is removed.

[0067] The verification item processing section checks the actual test results of the items marked for further verification in the historical data comparison. If the actual test verification passes, the current status of the capability item is considered valid, it is retained in the capability item list, and the reason for the verification is recorded; if the actual test verification fails, the current feedback data of the capability item is considered inaccurate, it is removed from the capability item list, the reason for removal is recorded, and equipment maintenance suggestions are generated.

[0068] Step S1269: Summarize the verification results of all capability items to form a device capability item verification report. The device capability item verification report includes a list of capability items that have passed verification and a list of capability items that have failed verification.

[0069] The verification results summary section collects the verification results for all capability items, organizing a list of verified capability items and a list of verified capability items that failed by capability category. The list of verified capability items includes the capability item name, current capability value, and verification success step; the list of verified capability items includes the capability item name, current feedback value, actual performance value, failure step, and failure reason. These lists are then integrated to form a device capability item verification report, which includes the device identifier, verification time, total number of verified items, number of passed items, number of failed items, and pass rate.

[0070] Step S127: Remove the capability items that fail verification and retain the true and valid presentation capability items, transmission capability items, and operation capability items.

[0071] The capability filtering section reads the device capability verification report and removes failed-verified capabilities from the current capability list. For presentation capabilities, if the maximum screen resolution verification fails, the capability is removed, and only other verified presentation capabilities are retained. For transmission capabilities, if the maximum data transmission rate verification fails, the capability is removed, and verified capabilities such as transmission packet loss rate and interruption recovery time are retained. For operation capabilities, if the operation response time verification fails, the capability is removed, and verified capabilities such as operation command type and permission setting capabilities are retained. The filtered capability list contains truly valid presentation, transmission, and operation capabilities, serving as the core content of the device capability list.

[0072] Step S128: Create a unique capability record for each device to be coordinated. The unique capability record contains the device identifier, a list of presentation capabilities, a list of transmission capabilities, and a list of operation capabilities. Integrate the unique capability records of all devices to form a device capability list.

[0073] The device capability record generation section creates a unique capability record for each device to be coordinated. The unique capability record for online devices includes a device identifier, a list of presentation capabilities, a list of transmission capabilities, a list of operational capabilities, capability update time, and verification status fields. The unique capability record for offline devices includes a device identifier, an offline status description, and a list of last known capabilities fields. All device unique capability records are grouped by device type to form a device capability list. The list is stored in a markup language format and includes fields for list version number, generation time, number of device groups, and total number of devices. It also supports searching by device identifier and capability name.

[0074] Step S130: Based on the results of the demand dimension breakdown and the device capability list, calculate the degree of adaptation of each device to different demand dimensions, and construct a digital multimedia multi-device collaborative interaction link based on the degree of adaptation.

[0075] The collaborative link construction part of the store's intelligent management platform first extracts specific requirement items and priorities from the three requirement dimensions from the requirement dimension breakdown results, and extracts the capability item list for each device from the device capability list. Then, for each requirement dimension, the adaptation score for each device is calculated, taking into account the matching degree of requirement items, priority weight, and capability item performance level. The adaptation scores of the three dimensions are integrated into a comprehensive adaptation score, and candidate collaborative devices that meet the comprehensive adaptation score are selected. Next, a primary responsible device is selected for each requirement dimension, the interaction relationship between the primary responsible devices is determined, data transmission paths, interaction sequences, and status feedback mechanisms are set, and backup devices are configured. Finally, the above information is integrated to construct a digital multimedia multi-device collaborative interaction link, which includes fields for primary responsible device nodes, backup device nodes, data transmission paths, interaction rules, and status monitoring mechanisms.

[0076] Step S131: Extract the specific requirements and priority of the presentation requirements dimension from the results of the requirement dimension decomposition, and extract the presentation capability list of each device from the device capability list.

[0077] The requirement extraction section accesses the requirement dimension breakdown result document, locates the presentation requirement dimension section, and extracts the specific requirement items under that dimension and the priority of each requirement item. The device capability extraction section accesses the device capability list and extracts a list of presentation capability items for each device based on the device identifier. The extracted presentation requirement items are then mapped to the device presentation capability items by name, forming a presentation requirement-capability mapping table. This table contains fields for requirement item name, requirement priority, requirement description, and corresponding capability item name.

[0078] Step S132: For each specific requirement item under the presentation requirement dimension, compare the matching status of each device's presentation capability item with that specific requirement item. If the device's presentation capability item meets the requirements of that specific requirement item, it is recorded as a successful match; otherwise, it is recorded as a failed match.

[0079] The presentation requirement matching process iterates through each specific requirement item in the presentation requirement-capability mapping table, comparing the corresponding presentation capability items of each device to ensure they meet the requirements. For content image clarity requirements, the maximum screen resolution capability item of the device is checked. If the device's maximum resolution meets the requirement, the match is successful; otherwise, the match fails. For image color reproduction requirements, the color processing capability range of the device is checked. If it includes the required color gamut, the match is successful; otherwise, the match fails. For image smoothness requirements, the frame rate range capability item of the device is checked. If the device's frame rate range includes the required range, the match is successful; otherwise, the match fails. For image size adaptation requirements, the image scaling mode capability item of the device is checked. If it includes the required scaling mode, the match is successful; otherwise, the match fails. The matching results are recorded as matching status and matching degree fields.

[0080] Step S133: Based on the priority of each specific requirement item under the presentation requirement dimension, set an adaptation weight for each specific requirement item. For specific requirement items whose priority meets the preset priority standard, the adaptation weight is set to meet the preset weight value standard.

[0081] The adaptation weight setting section reads the priority of presentation requirements and queries the preset priority-weight mapping rules. For example, if content clarity is a high priority requirement, the adaptation weight is set to a relatively high value; if color reproduction is a medium priority requirement, the adaptation weight is set to a medium value; if smoothness is a medium priority requirement, the adaptation weight is set to a medium value; and if size adaptation is a low priority requirement, the adaptation weight is set to a relatively low value. After the weights are set, a presentation requirement weight table is generated, which contains the requirement name, requirement priority, and adaptation weight fields, with the total weight set to a specific value.

[0082] Step S134: Based on the matching results and adaptation weights of each specific requirement item under the presentation requirement dimension for each device, calculate the adaptation score of each device for the presentation requirement dimension. The adaptation score is calculated as the sum of the products of the matching results of each specific requirement item and the corresponding adaptation weight.

[0083] The presentation adaptation score calculation section initializes the presentation adaptation score to zero for each device. For each presentation requirement, if the device matches successfully, the adaptation weight value of that requirement is added to the presentation adaptation score; if the match fails, it is not added. After calculation, a device presentation adaptation score table is generated, which contains the device identifier, the matching result of each requirement, and the adaptation score field.

[0084] Step S135: Using the same method, calculate the adaptation score of each device for the transmission requirement dimension and the adaptation score for the operation requirement dimension.

[0085] The calculation process for transmission requirement adaptation scores is similar to that for presentation requirements: extract specific requirement items and priorities from the transmission requirement dimension, and set adaptation weights; compare the matching of transmission capability items with transmission requirement items for each device; calculate the transmission adaptation score. The calculation process for operation requirement adaptation scores is the same: extract specific requirement items and priorities from the operation requirement dimension, set adaptation weights, compare the matching of device operation capability items with operation requirement items, and calculate the operation adaptation score. This ultimately results in a device transmission adaptation score table and a device operation adaptation score table.

[0086] Step S136: Normalize the adaptation scores of each device in the three demand dimensions, and sum the normalized adaptation scores of the three dimensions according to a preset ratio to obtain the comprehensive adaptation score of each device.

[0087] The normalization process first normalizes the adaptation scores across the three dimensions, mapping the scores to specific intervals. The normalization method employs min-max standardization, with the formula calculating the normalized score based on the relationship between the original score, minimum value, and maximum value. After normalization, the scores are weighted and summed according to a preset ratio to calculate the overall adaptation score. A device overall adaptation score table is then generated, containing the device identifier, the normalized scores for the three dimensions, and the overall adaptation score field.

[0088] Step S137: Based on the comprehensive adaptation score of each device, select devices whose comprehensive adaptation score reaches the preset adaptation score threshold as candidate collaborative devices.

[0089] The candidate device screening section compares the overall adaptation score in the device comprehensive adaptation score table with a preset adaptation score threshold, selecting devices with scores greater than or equal to the threshold as candidate collaborative devices. The preset adaptation score threshold is set based on historical collaborative performance data and current scenario requirements, and is stored under the collaborative parameter node in the system configuration file. The screening results generate a candidate collaborative device list, including device identifier, overall adaptation score, normalized scores for each dimension, and device online status field.

[0090] Step S138: For each requirement dimension in the requirement dimension breakdown results, select the device with the highest adaptation score for that dimension from the candidate collaborative devices as the main responsible device for that requirement dimension.

[0091] The primary responsible device selection process sequentially addresses three requirement dimensions: presentation, transmission, and operation. For the presentation requirement dimension, the device with the highest presentation adaptation score is retrieved from the candidate collaborative device list and selected as the primary responsible device for this dimension. For the transmission requirement dimension, the device with the highest transmission adaptation score is selected as the primary responsible device. For the operation requirement dimension, the device with the highest operation adaptation score is selected as the primary responsible device. If devices with the same adaptation score exist, their historical collaborative performance data (such as average response time and operation success rate) is further compared, and the device with the better performance is selected as the primary responsible device. The selected primary responsible device record includes the following fields: device identifier, responsible dimension, adaptation score, and historical performance rating.

[0092] Step S139: Determine the interaction relationship between the main responsible devices for each demand dimension. The main responsible device for the presentation demand dimension needs to provide content presentation parameters to the main responsible device for the transmission demand dimension. The main responsible device for the transmission demand dimension needs to provide content transmission status to the main responsible device for the operation demand dimension. The main responsible device for the operation demand dimension needs to provide operation instructions to the main responsible device for the presentation demand dimension.

[0093] The interaction relationship determination section defines the information interaction direction and content between the primary responsible devices based on the business logic connections across the three demand dimensions. Before initiating content presentation, the primary responsible device for the presentation demand dimension must provide content presentation parameters to the primary responsible device for the transmission demand dimension so that the transmission device can adjust its transmission strategy. During transmission, the primary responsible device for the transmission demand dimension must push the content transmission status to the primary responsible device for the operation demand dimension in real time so that the operation device can monitor the transmission progress. Upon receiving a user operation command, the primary responsible device for the operation demand dimension must immediately provide feedback to the primary responsible device for the presentation demand dimension so that the presentation device can adjust the presentation content accordingly. The interaction relationship record includes fields for interaction direction (source device - target device), interaction content type, interaction frequency, and data format.

[0094] Step S1310: Based on the interaction relationship between each main responsible device, set the data transmission path, interaction order of operation commands, and status feedback mechanism between devices.

[0095] Step S13101: Determine the types of content presentation parameters that the main responsible device for the presentation requirement dimension needs to provide to the main responsible device for the transmission requirement dimension, and determine the transmission format and transmission frequency of the content presentation parameters. The types of content presentation parameters include target presentation resolution, target presentation frame rate, color space standard and screen scaling ratio.

[0096] The parameter type determination section analyzes the specific requirements of the presentation dimension, extracting key presentation parameters that affect data transmission. For example, the target presentation resolution determines the amount of data transmitted, the target presentation frame rate affects real-time transmission requirements, color space standards relate to data encoding methods, and the screen scaling ratio involves preprocessing operations before transmission. The transmission format is determined to be a structured format, including parameter name, parameter value, unit, and effective timestamp fields. Two transmission frequency modes are set: initial parameters are transmitted all at once, and dynamically adjusted parameters are transmitted in real time.

[0097] Step S13102: Based on the transmission format and transmission frequency of the content presentation parameters, and combined with the transmission protocol type in the transmission capability items of the main responsible device in the presentation requirement dimension and the main responsible device in the transmission requirement dimension, select a suitable transmission channel and set a one-way data transmission path from the main responsible device in the presentation requirement dimension to the main responsible device in the transmission requirement dimension.

[0098] The transmission channel selection section compares the types of transmission protocols supported by the primary transmission device, prioritizing protocols that support high bandwidth and low latency. Based on transmission frequency requirements, a reliable transmission protocol is selected for initial parameters of a one-time transmission, while a real-time transmission protocol is selected for dynamic parameters of real-time transmission. The transmission path setting section marks the physical connection nodes (such as switch ports and router interfaces) between the source and target devices in the network topology diagram, and configures the network parameters of the nodes (such as IP address, subnet mask, and gateway) to ensure data transmission along the preset path. After path setting is completed, a connectivity test is performed to verify that data can be successfully transmitted from the source device to the target device.

[0099] Step S13103: Determine the content transmission status type that the main responsible device for the transmission demand dimension needs to provide to the main responsible device for the operation demand dimension, and determine the feedback cycle and feedback format of the content transmission status information. The content transmission status type includes the current transmission rate, the amount of data transmitted, the transmission packet loss situation, and the transmission delay.

[0100] The status type determination section extracts key status indicators from specific requirements within the transmission demand dimension. The current transmission rate reflects transmission efficiency, the amount of data transmitted indicates progress, packet loss reflects data integrity, and transmission delay affects real-time interaction. The feedback cycle is set according to transmission delay control requirements, and its length ensures that the operating equipment can promptly grasp changes in transmission status. The feedback format uses a structured format, including fields for status type, value, unit, collection timestamp, and status level (normal / warning / abnormal).

[0101] Step S13104: Based on the feedback cycle and feedback format of the content transmission status information, and combined with the transmission delay control capabilities in the transmission capability items of the main responsible device in the transmission demand dimension and the main responsible device in the operation demand dimension, set a one-way data transmission path from the main responsible device in the transmission demand dimension to the main responsible device in the operation demand dimension, so that the content transmission status information is delivered within the feedback cycle.

[0102] The transmission delay assessment section calculates the feasibility of delivering status information within the feedback period based on the transmission delay control capabilities of the main equipment responsible for transmission and operation (such as historical average transmission delay and maximum allowable delay). If the historical average transmission delay is less than half of the feedback period, the path is deemed feasible; otherwise, the feedback period is adjusted or the transmission path is optimized (e.g., by selecting a shorter physical link). The transmission path setting process is similar to step S13102, configuring network parameters and performing connectivity and delay tests to ensure that status information is delivered within the specified time.

[0103] Step S13105: Determine the types of operation instructions that the main responsible device for the operation requirement dimension needs to feed back to the main responsible device for the presentation requirement dimension. The operation instruction types include screen switching instructions, volume adjustment instructions, playback progress adjustment instructions, and screen effect adjustment instructions, and determine the encoding format and priority of the operation instructions.

[0104] The instruction type determination section identifies specific requirements within the operational needs dimension, defining instruction types based on common user interaction scenarios. The encoding format uses binary encoding, including an instruction type identifier (occupying a specific number of bits), instruction parameters (occupying a specific number of bits), and a checksum (occupying a specific number of bits) to reduce the amount of data transmitted. Priority is divided into three levels: emergency instructions (e.g., emergency stop playback), high-priority instructions (e.g., video switching), and normal-priority instructions (e.g., volume adjustment). The priority field occupies a specific number of bits and is used for priority scheduling during transmission.

[0105] Step S13106: Based on the encoding format and priority of the operation instructions, and combined with the operation response speed in the operation capability items of the main responsible device in the operation requirement dimension and the main responsible device in the presentation requirement dimension, set a one-way interactive operation instruction transmission path from the main responsible device in the operation requirement dimension to the main responsible device in the presentation requirement dimension. Operation instructions whose priority meets the preset priority standard shall use the priority transmission channel.

[0106] The transmission path configuration section selects a low-latency transmission protocol based on the operation response speed requirements (such as the command sending delay of the operating device and the command processing delay of the presentation device). Independent transmission channels are allocated to operation commands of different priorities, with priority transmission channels configured with higher bandwidth guarantees and shorter routing paths. For example, emergency commands use a dedicated high-speed channel, while ordinary commands use a shared channel. After configuration, command transmission tests are performed to verify whether the transmission latency of commands of different priorities meets the operation response speed requirements.

[0107] Step S13107: Determine the interaction order of the interactive operation instructions. The device responsible for the operation requirement dimension must first receive the user's operation instructions and then feed them back to the device responsible for the presentation requirement dimension. At the same time, the device responsible for the transmission requirement dimension must provide real-time feedback on the content transmission status to the device responsible for the operation requirement dimension. The device responsible for the presentation requirement dimension must adjust the content presentation parameters according to the user's operation instructions and then send the new content presentation parameters to the device responsible for the transmission requirement dimension.

[0108] The interaction sequence definition section draws a timing flowchart, clearly defining the operation steps and their temporal order for each device. The user operation command interaction flow is: user operation—operating device receives command—operating device verifies permissions—operating device sends command—presentation device receives command—presentation device executes command—presentation device provides feedback result. The content transmission status interaction flow is: transmission device acquires status—transmission device encodes status information—transmission device sends periodically—operating device receives and parses. The content presentation parameter adjustment interaction flow is: presentation device adjusts parameters—presentation device encodes new parameters—presentation device sends parameters—transmission device receives and applies. The timing flowchart includes nodes (devices), arrows (data flow direction), and time markers (step intervals).

[0109] Step S13108: Set up the abnormal feedback process in the status feedback mechanism. If the main device responsible for the transmission demand dimension detects that the transmission packet loss rate exceeds the preset allowable range, it must immediately send a transmission abnormality notification to the main device responsible for the operation demand dimension. After receiving the transmission abnormality notification, the main device responsible for the operation demand dimension will stop issuing new interactive operation commands to the main device responsible for the presentation demand dimension and provide feedback on the transmission abnormality information to the user.

[0110] The anomaly type definition section categorizes packet loss rates exceeding a preset range as severe transmission anomalies, which may lead to content stuttering or errors. The anomaly detection section uses the network monitoring module of the transmission equipment to monitor the packet loss rate in real time. The sampling period is a specific duration; if the rate exceeds a threshold for multiple consecutive periods, an anomaly is triggered. The anomaly notification format includes fields for anomaly type, current value, threshold, occurrence time, and suggested handling measures. Upon receiving the notification, the operating device invokes the instruction queue management module to suspend the issuance of new instructions and displays transmission anomaly information (such as text prompts and flashing icons) through the user interface.

[0111] Step S13109: Set up the normal feedback process in the status feedback mechanism. Each main responsible device must send a status normal confirmation message to the associated device according to the preset feedback cycle.

[0112] A normal state is defined as equipment operating parameters being within the normal range and no abnormal events occurring. The feedback cycle is set according to the importance of the equipment, with a shorter cycle for the primary responsible equipment and a longer cycle for backup equipment. The confirmation message format includes the equipment identifier, responsible dimension, current status code (normal / busy / idle), resource utilization rate, and the next feedback time field. After receiving the confirmation message, the associated equipment updates its equipment status table. If no confirmation message is received within the preset cycle, the equipment is considered disconnected, triggering the fault handling process.

[0113] Step S131010: Organize the set data transmission path, interactive operation command interaction sequence and status feedback mechanism into a link interaction specification. The link interaction specification is a component of the multi-device collaborative interaction link, so that each main responsible device can perform interactive operations according to the link interaction specification.

[0114] The standardization section integrates network parameter configurations for data transmission paths, timing flowcharts for interactive operation command sequences, and rules and regulations for status feedback mechanisms into a unified link interaction specification document. The document includes a version number, effective date, list of applicable devices, detailed specification sections (transmission specification, interaction specification, feedback specification), and appendices (terminology definitions, exception code table). This document is distributed to the local storage of each responsible device; the device loads the specification document upon startup and executes interactive operations accordingly.

[0115] Step S1311: Configure at least one alternative device for each primary responsible device. The selection criteria for alternative devices are the candidate collaborative devices with the second highest matching score for this requirement dimension.

[0116] For each primary responsible device, the alternative device configuration section queries the candidate collaborative device list for the device with the second-highest adaptation score under the same requirement dimension. If the difference between the adaptation score of the second-highest scoring device and that of the primary responsible device is within a preset allowable range (e.g., not exceeding a specific percentage), it is selected as the alternative device; otherwise, the next higher-scoring device is queried. The number of alternative devices configured for each primary responsible device is determined based on the importance of the requirement: two alternative devices are configured for the presentation and transmission dimensions, and one alternative device is configured for the operation dimension. The alternative device record includes the primary responsible device identifier, alternative device identifier, adaptation score, and switchover trigger condition fields.

[0117] Step S1312: Integrate the main responsible device, alternative devices, inter-device interaction relationships, data transmission paths, interactive operation command interaction sequence, and status feedback mechanism to construct a digital multimedia multi-device collaborative interaction link.

[0118] The link integration section integrates the elements identified in the previous steps, such as the primary responsible device, alternative devices, interaction relationships, transmission paths, interaction sequences, and feedback mechanisms, using a directed graph data structure to form a multi-device collaborative interaction link. Nodes in the directed graph represent devices (primary / alternate), edges represent data transmission paths, and edge attributes include interaction content type, transmission protocol, priority, and status feedback rules. After the link is constructed, simulation tests are conducted to simulate the collaborative effects under different scenarios (normal operation, device failure, network fluctuations) to verify the link's stability and reliability. After successful testing, the link configuration data is stored in the collaborative link configuration file as the basis for subsequent interaction operations.

[0119] Step S140: According to the multi-device collaborative interaction link, send interactive operation instructions to each device to be collaborated, guide each device to perform corresponding digital multimedia processing actions, and obtain the interactive result data fed back by the device processing actions.

[0120] The collaborative instruction issuance section reads information such as the primary responsible device, interaction sequence, and instruction format from the collaborative link configuration file to generate interactive operation instructions. The instruction content is determined based on specific requirement items from the requirement breakdown and capability items from the device capability list, including instruction identifier, target device identifier, action type (presentation / transmission / operation), action parameters, and execution time requirements. Instructions are issued to each primary responsible device according to the interaction sequence through the data transmission path in the multi-device collaborative interaction link. During device action execution, the execution status is monitored in real time, and processing progress and result data are received from the devices. After all device actions are completed, the processing results are summarized to form interactive result data, including instruction execution logs, device performance data, and user feedback information.

[0121] Step S141: Analyze the main responsible device identifier, alternative device identifier, and the corresponding responsibilities of each device in the multi-device collaborative interaction link, and determine the type of digital multimedia processing action that each device needs to perform. The types of digital multimedia processing actions include content decoding action, content rendering action, content transmission action, operation instruction receiving action, and operation result feedback action.

[0122] The link resolution section reads the directed graph data from the collaborative link configuration file and extracts the identifier and responsibility description of each node (device). Based on the responsibility description, it determines the processing action type of the device: the presentation requirement dimension is primarily responsible for the device performing content decoding and rendering actions; the transmission requirement dimension is primarily responsible for the device performing content transmission actions; and the operation requirement dimension is primarily responsible for the device performing operation command reception and operation result feedback actions. The mapping relationship between action types and devices is recorded in the device action allocation table, which includes the device identifier, responsibility description, action type list, and dependent device identifier field (e.g., rendering actions depend on decoding actions).

[0123] Step S142: Based on the requirements of each specific requirement item in the demand dimension breakdown results, determine the specific parameters for each device to perform the corresponding digital multimedia processing action. The specific parameters for the content rendering action include rendering resolution, rendering frame rate and rendering color parameters. The specific parameters for the content transmission action include the upper limit of transmission rate, transmission data verification method and transmission delay control target.

[0124] The action parameter determination section converts the specific requirements from the demand dimension breakdown into action parameters that the device can execute. For example, the content clarity requirement of the presentation demand dimension is converted into rendering resolution parameters, the smoothness requirement into rendering frame rate parameters, and the color reproduction requirement into rendering color parameters (such as color gamut and color temperature). The transmission demand dimension's transmission speed requirement is converted into transmission rate limit parameters, data integrity requirements into transmission data verification methods (such as CRC checksum and MD5 checksum), and transmission latency control requirements into transmission latency control target parameters. The parameter values ​​must simultaneously meet the demand requirements and the device's capability limitations. If the demand parameters exceed the device's capability, they are set according to the device's maximum capability value, and the parameter adjustment instructions are recorded.

[0125] Step S143: Generate interactive operation instructions for each device according to the interaction order of the interactive operation instructions in the multi-device collaborative interaction link. Each interactive operation instruction for each device includes the device identifier, the type of digital multimedia processing action, the specific parameters of the digital multimedia processing action, and the execution time requirements.

[0126] The instruction generation section determines the instruction sequence based on the device action allocation table and action parameters, following the interaction order of the operation instructions. Each instruction contains fixed fields (instruction header) and variable fields (instruction body). The instruction header includes the instruction version, instruction type, target device identifier, instruction length, and checksum fields; the instruction body includes the digital multimedia processing action type, a list of specific parameters (parameter name-parameter value pairs), execution start time, and execution timeout fields. The execution time requirement is set according to the time nodes in the interaction sequence flowchart to ensure that the device executes actions in the correct order. After instruction generation, syntax and semantic checks are performed to ensure that the instruction format is correct and the parameters are valid.

[0127] Step S144: Based on the data transmission path in the multi-device collaborative interaction link, establish a direct communication channel between each device. The setting of the direct communication channel must meet the transmission protocol type requirements in the device transmission capability item.

[0128] The communication channel establishment process establishes direct communication connections between devices based on the network parameters (IP address, port number, protocol type) recorded in the data transmission path. For TCP, a three-way handshake is performed; for UDP, port listening and packet format are configured. During channel establishment, the protocol support in the device's transmission capabilities is verified. If the device does not support the protocol specified in the path, the process reverts to the link construction step to reselect the protocol and path. After successful communication channel establishment, bandwidth and latency tests are performed, and channel performance parameters (bandwidth, latency, jitter) are recorded as a basis for evaluating the quality of subsequent command transmissions.

[0129] Step S145: In accordance with the interaction order of the interactive operation instructions, send the corresponding interactive operation instructions of each device to the target device through the corresponding direct communication channel.

[0130] The command issuance section sends interactive operation commands to each target device sequentially according to the order shown in the interactive operation command sequence flowchart. Before sending, the communication channel status of the target device is checked, and commands are only sent if the channel is normal. A confirmation mechanism is used during the sending process; the sender waits for the receiver to return a command reception confirmation message. If no confirmation is received within the timeout period, the command is resent, with the number of resentments not exceeding a preset limit. The command issuance record includes the fields for command identifier, target device identifier, sending time, sending result, and confirmation reception time.

[0131] Step S146: During the process of issuing interactive operation commands, monitor the transmission status of the direct communication channel in real time, and record the time of issuing the interactive operation command, the time of receiving the interactive operation command, and the data packet loss during the transmission process.

[0132] The transmission status monitoring section collects transmission status parameters in real time through the communication channel's status monitoring interface: the time of issuing the interactive operation command is the timestamp of the command leaving the sending buffer; the time of receiving the interactive operation command is the timestamp of the receiver's acknowledgment; and data packet loss is statistically analyzed using a sequence number check method (the difference between the sending sequence number and the receiving acknowledgment sequence number). Monitoring data is stored in the transmission status log in chronological order, including timestamp, channel identifier, command identifier, issuance time, receiving time, number of lost packets, and packet loss rate fields. When the packet loss rate exceeds a preset threshold, a channel quality alarm is triggered.

[0133] Step S147: If any device fails to receive the interactive operation instruction within the specified time, or if the received interactive operation instruction has missing data, the backup device mechanism in the multi-device collaborative interaction link is activated, the interactive operation instruction is sent to the corresponding backup device, and the data transmission path is updated.

[0134] For example, step S1471: preset the timeout for receiving interactive operation instructions. The timeout is set based on the transmission delay control requirements in the device transmission capability item and the time node requirements in the interactive operation instruction interaction sequence.

[0135] The timeout setting considers two factors: the transmission delay control requirements in the device's transmission capacity section (such as a specific multiple of the average transmission delay), ensuring that the timeout is greater than the time required for normal transmission; and the time node requirements in the interactive operation command sequence (such as the start time of the next command), ensuring that timeout processing does not affect the overall interaction sequence. The timeout is set according to the command type; commands with high real-time requirements (such as operation commands) have shorter timeouts, while commands with large data volumes (such as parameter presentation commands) have longer timeouts. The timeout is stored under the timeout parameter node in the command configuration file.

[0136] Step S1472: After sending the interactive operation command to the main responsible device, start the timer and monitor in real time whether the current main responsible device returns the interactive operation command reception confirmation information within the reception timeout period.

[0137] The timing monitoring unit starts a timer immediately after the command is issued, with the timer duration set to the receive timeout period. Simultaneously, it listens for receive acknowledgment messages on the communication channel, parses the command identifier in the acknowledgment message, and matches it against the currently issued command. If a matching receive acknowledgment message is received before the timer expires, the timing stops, and the acknowledgment time is recorded; if no acknowledgment message is received before the timer expires, a timeout event is triggered.

[0138] Step S1473: If no confirmation message for receiving the interactive operation instruction is received from the currently responsible device after the timeout period ends, it is determined that the currently responsible device did not receive the interactive operation instruction within the specified time.

[0139] When the timeout determination section expires, it checks the received acknowledgment information buffer. If no acknowledgment information matching the current instruction identifier is found, a "not received on time" determination result is generated. Simultaneously, it queries the transmission status log to obtain information such as the instruction's issuance time, channel status, and packet loss status, as supplementary explanations for the determination.

[0140] Step S1474: If an interactive operation instruction reception confirmation message is received from the currently responsible device, but the interactive operation instruction reception confirmation message contains a prompt that the interactive operation instruction data is missing, it is determined that the interactive operation instruction received by the currently responsible device has missing data.

[0141] The data missing determination section parses the status field in the received confirmation message. If the status field value is "data missing," or contains a specific list of missing fields, it is determined to be "data missing." Data missing may be caused by transmission packet loss, verification errors, parsing failures, etc. The confirmation message contains a missing reason code for subsequent analysis.

[0142] Step S1475: When an interactive operation instruction is not received on time or when there is a data gap in the interactive operation instruction, query the alternative device identifier and capability information of the current main responsible device from the multi-device collaborative interaction link.

[0143] The alternative device query section accesses the alternative device configuration table in the collaborative link configuration file and retrieves the corresponding alternative device identifier list based on the currently responsible device identifier. Then, it extracts the capability information (presentation, transmission, and operation capabilities) of the alternative devices from the device capability list, focusing on the capability items related to the current interactive operation command (such as the hardware configuration and software modules required for command processing).

[0144] Step S1476: Verify whether the candidate device is currently in an idle state. The verification method is to send a status query request to the candidate device and receive the current task load status from the candidate device. If the current task load is lower than the preset task load threshold, the candidate device is determined to be in an idle state.

[0145] The idle state verification component sends a status query request command to the backup device. This command includes a query identifier, a query timestamp, and load metric types (CPU utilization, memory usage, task queue length). Upon receiving the request, the backup device collects current task load data and returns a response in the requested format, including a device identifier, a response timestamp, and the current value of each load metric. Each load metric is compared to a preset task load threshold. If all metrics are below the threshold, the device is determined to be in an idle state; otherwise, it is in a busy state.

[0146] Step S1477: If the alternative device is in an idle state, adjust the specific parameters of the digital multimedia processing action based on the interactive operation instructions of the original primary device and the capability information of the alternative device, so that the specific parameters of the digital multimedia processing action are within the capability range of the alternative device.

[0147] The parameter adjustment section compares the specific parameters of the digital multimedia processing actions in the original instruction with the upper limits of the capabilities of the candidate device. If a parameter value exceeds the upper limit, it is adjusted according to the upper limit. For example, if the original instruction's rendering resolution is a specific pixel value, and the candidate device's maximum resolution is a lower pixel value, the rendering resolution is adjusted to the candidate device's maximum resolution; if the original instruction's transmission rate upper limit is higher than the maximum rate supported by the candidate device, it is adjusted to the candidate device's maximum rate. The parameter adjustment record includes the original parameter value, the adjusted parameter value, the reason for adjustment (capability limitation), and the adjustment time field.

[0148] Step S1478: Generate interactive operation instructions for the candidate device. The interactive operation instructions for the candidate device include the core information of the original interactive operation instructions and the specific parameters of the adjusted digital multimedia processing actions.

[0149] The alternative instruction generation section copies the core information of the original interactive operation instruction (instruction identifier, action type, execution time requirement), replaces it with the adjusted specific parameters of the digital multimedia processing action, and adds a alternative device identifier field and a switching reason field (failure to receive on time / data missing). The instruction format remains consistent with the original instruction to ensure that the alternative device can parse it correctly. After generation, parameter verification is performed to ensure that the adjusted parameters are within the capabilities of the alternative device.

[0150] Step S1479: Query all data transmission paths corresponding to the original primary responsible device in the multi-device collaborative interaction link, determine the path nodes that need to be updated, and replace the nodes of the original primary responsible device with the nodes of the alternative devices.

[0151] The path update process traverses the directed graph data structure of the multi-device collaborative interaction links to find all edges (data transmission paths) with the original primary responsible device as the target or source node. For paths with the original primary responsible device as the target node (e.g., operation device—original presentation device), the target node is replaced with a candidate device; for paths with the original primary responsible device as the source node (e.g., original presentation device—transmission device), the source node is replaced with a candidate device. The updated path node record includes the original node identifier, new node identifier, path type, and update time fields.

[0152] Step S14710: Adjust the transmission protocol configuration of the data transmission path according to the transmission protocol type in the transmission capability item of the candidate device, so that the new data transmission path meets the transmission requirements of the candidate device.

[0153] The protocol configuration adjustment section reads the supported transmission protocol types and parameters (such as port number, encryption method, and compression algorithm) from the transmission capability section of the alternative devices and compares them with the transmission protocol configuration of the original path. If the protocol types are different, the protocol type field of the path is modified; if the protocol parameters are different (e.g., the original path uses a specific port, while the alternative device only supports another port), the corresponding parameters are updated. After the configuration adjustment, the connectivity and transmission performance of the new path are tested to ensure that it meets the transmission requirements of the interactive operation commands.

[0154] Step S14711: Send the interactive operation command for the alternative device to the alternative device through the updated data transmission path.

[0155] The alternative command issuance section uses the updated data transmission path and follows the same issuance process as the original command (establishing a channel, sending the command, and waiting for confirmation) to issue interactive operation commands to the alternative device. During the issuance process, transmission latency and packet loss rate are closely monitored to ensure that the alternative device can receive and process the command within the remaining execution time.

[0156] Step S14712: Send a device replacement notification to other devices associated with the original device. The device replacement notification contains the new alternative device identifier and the updated data transmission path information, so that the other devices associated with the original device can subsequently interact with the alternative device.

[0157] The associated device notification section identifies the associated devices of the original primary device (devices that exchange data with it) and sends a device replacement notification command to them. The notification command includes the original device identifier, the new device identifier (alternate device), the updated data transmission path (IP address, port, protocol), and the effective time field. Upon receiving the command, the associated device updates its local device mapping table and path configuration, and subsequently sends the data to the alternative device during interactive operations.

[0158] Step S14713: Monitor the status of the alternative device receiving the interactive operation command for the alternative device. If the alternative device successfully receives the interactive operation command for the alternative device and returns an interactive operation command reception confirmation message, the startup of the alternative device mechanism and the update of the data transmission path are completed. If the alternative device still fails to successfully receive the interactive operation command for the alternative device, repeat the above steps to select the next alternative device until the interactive operation command for the alternative device is successfully sent.

[0159] After issuing instructions to the backup device, the backup device monitoring section initiates the same receiving and monitoring process as the primary responsible device. If the instruction is successfully received, a successful replacement log is recorded, and the current primary responsible device in the collaborative link configuration file is updated to the backup device. If the instruction is not successfully received, the next backup device is selected from the backup device list, and steps S1475 to S14712 are repeated. If all backup devices fail to receive the instruction, a high-level alarm is triggered, notifying the system administrator for manual intervention.

[0160] Step S148: After receiving the interactive operation command, each device executes the digital multimedia processing action according to the type and specific parameters of the digital multimedia processing action in the interactive operation command. During the execution of the digital multimedia processing action, the processing progress, processing resource usage, and abnormal information during the processing are recorded in real time.

[0161] The device execution unit parses the received interactive operation commands and calls the corresponding processing module according to the type of digital multimedia processing action: content decoding calls the decoder module, content rendering calls the rendering engine, content transmission calls the transmission module, operation command receiving calls the input processing module, and operation result feedback calls the output feedback module. During processing, the device collects and stores in real time the processing progress (such as decoding completion percentage, rendering frame count, and number of bytes transmitted), processing resource usage (CPU / memory / network usage), and exception information (error code, error description, and occurrence time) in the local processing log.

[0162] Step S149: After the device completes the digital multimedia processing action, a processing result report is generated. The processing result report includes the completion time of the digital multimedia processing action, a description of the digital multimedia processing result, and a record of the digital multimedia processing process.

[0163] The results report generation section collects data from the local processing log and generates a processing results report after the digital multimedia processing action is completed (processing progress reaches 100% or a stop command is received). The completion time of the digital multimedia processing action is the timestamp of the end of the last processing step; the digital multimedia processing result is described as a summary of the processed output data (such as the resolution of the rendered image, the total number of bytes of data transmitted, and the execution status of the operation command); the digital multimedia processing process record includes timestamps and statuses of key processing nodes (such as decoding start / end time, rendering frame rate changes, and the number of successful / failed transmissions). The report format adopts a structured format, including a report identifier, device identifier, command identifier, completion time, result description, and process record fields.

[0164] Step S1410: The processing result report is fed back to the control terminal that initiated the interactive operation command through the direct communication channel. The control terminal that initiated the interactive operation command collects the processing result reports, interactive operation command transmission records and device processing records of all devices, and integrates the processing result reports, interactive operation command transmission records and device processing records of all devices to form interactive result data.

[0165] The result feedback section sends the processing result report to the control terminal (store intelligent management platform) via a direct communication channel (the same as the instruction issuance channel). The control terminal's result collection section monitors the feedback channels of each device, receiving and storing the processing result report, interactive operation instruction transmission records (issuance records in step S145), and device processing records (processing logs in step S148). During integration, result data from different devices are associated according to instruction identifiers, forming interactive result data based on instructions. The interactive result data includes instruction identifiers, a list of participating devices, processing result reports from each device, a summary of transmission records, a summary of processing records, and an overall execution status field (success / partial success / failure).

[0166] Step S150: Based on the interaction result data, adjust the calculation standard for the adaptability of each device to different demand dimensions, and the node configuration of the multi-device collaborative interaction link to achieve dynamic optimization of multi-device collaborative interaction.

[0167] The dynamic optimization section analyzes the interaction results data to evaluate the accuracy of the current adaptation calculation standard (consistency between actual device performance and adaptation score) and the rationality of the collaborative link configuration (device load, transmission efficiency, fault tolerance). For the adaptation calculation standard, if the actual device performance deviates significantly from the adaptation score, the weights of the requirement items or the matching judgment rules are adjusted. For the collaborative link configuration, if the primary responsible device experiences frequent failures or resource overload, the primary responsible device is replaced or alternative devices are added. The optimized standard and configuration are applied to the next collaborative interaction process, achieving dynamic optimization through continuous iteration.

[0168] Step S151: Analyze the processing result report in the interaction result data, extract the completion quality information of each device's processing action, and present whether the image clarity and smoothness of the main responsible device in the demand dimension meet the requirements, and whether the transmission speed and packet loss rate are within the control range in the processing result of the main responsible device in the transmission demand dimension.

[0169] The quality analysis section extracts key quality indicators from the processing results report: image clarity (ratio of actual resolution to required resolution) and image smoothness (ratio of actual frame rate to required frame rate, number of stutters) of the presenting device; transmission speed (ratio of actual average rate to required rate) and packet loss rate (ratio of actual packet loss rate to control threshold) of the transmission device; response time of the operating device (ratio of actual response time to required response time) and command synchronization success rate. These indicators are compared with the required standards to assess whether the completed quality meets the standards (a ratio greater than or equal to 1 indicates compliance, otherwise, it indicates non-compliance). The analysis results are recorded in the completion quality assessment table, including fields for device identification, responsible dimension, quality indicator, actual value, required value, and compliance status.

[0170] Step S152: Based on the processing completion quality information, determine whether the actual adaptation performance of each device in the corresponding requirement dimension is consistent with the previously calculated adaptation score. If the actual completion quality does not meet the requirement and the adaptation score exceeds the preset adaptation score threshold, then mark that there is a deviation in the adaptation calculation standard of the corresponding requirement dimension of the device.

[0171] The compatibility consistency assessment compares the device's completion quality compliance status with its compatibility score: If the device's compatibility score is higher than the preset compatibility score threshold (indicating good compatibility), but the completion quality is substandard (poor actual performance), then the compatibility calculation standard is considered to be biased; if the compatibility score is lower than the threshold and the completion quality is substandard, or if the compatibility score is higher than the threshold and the completion quality is compliant, then compatibility is considered. Deviation markers include the device identifier, requirement dimension, compatibility score, completion quality compliance status, and deviation severity (minor / serious) fields. The deviation severity is calculated based on the difference between the actual value and the required value (the larger the difference, the more severe the deviation).

[0172] Step S153: Based on the standard deviation of the adaptation calculation of the marker, re-evaluate the adaptation weight of each specific requirement item under the requirement dimension. If, according to the interaction result data, it is determined that the actual processing quality deviation of any specific requirement item exceeds the preset deviation allowable range, and the adaptation weight value of the specific requirement item was previously lower than the preset low adaptation weight threshold, then increase the adaptation weight value of the specific requirement item to meet the preset weight value standard.

[0173] The weight adjustment section addresses the requirement dimension with marked deviations, analyzing the actual processing quality deviation (the difference between the actual value and the required value) of each specific requirement item within that dimension. If the deviation of a requirement item exceeds the preset allowable deviation range (e.g., the difference is greater than a specific percentage), and its current adaptation weight is lower than the preset low adaptation weight threshold (e.g., lower than a specific proportion of the average weight of the same dimension), then the weight of that requirement item is determined to be too low, failing to fully reflect its impact on the user experience. The adjustment method involves increasing the weight to the preset weight value standard (the average weight of high-priority requirement items in the same dimension), while proportionally reducing the weights of other requirement items with smaller deviations, ensuring that the total weight within the dimension remains unchanged. The adjustment record includes fields for requirement dimension, requirement item name, original weight, new weight, reason for adjustment, and adjustment time.

[0174] Step S154: Redefine the matching criteria between specific requirements and equipment capabilities. If a previous match was successful but the actual processing quality did not meet the requirements, refine the matching criteria and add specific parameter requirements for the capability items.

[0175] The matching criteria optimization section analyzes the matching details between device capabilities and requirements for specific needs that were previously matched successfully but did not meet actual processing quality standards. For example, the original matching criterion for content image clarity requirements was "maximum resolution ≥ required resolution," but during actual rendering, insufficient device memory caused the resolution to decrease. In this case, the matching judgment condition is refined to "maximum resolution ≥ required resolution and memory capacity ≥ memory requirement corresponding to the resolution." The added specific parameters require selecting hardware / software parameters (such as memory, processor performance, and software version) related to the requirement from the device capabilities. The redefined matching criteria are stored in the requirement-capability matching rule file, replacing the original rules.

[0176] Step S155: Based on the adjusted adaptation weights and matching criteria, recalculate the adaptation scores and overall adaptation scores of each device for different requirement dimensions.

[0177] The adaptation score recalculation process uses the adjusted adaptation weights (step S153) and matching criteria (step S154) to repeat the calculation process from steps S131 to S136, re-obtaining the adaptation scores for each device in the presentation, transmission, and operation dimensions, as well as the overall adaptation score. The recalculated results are compared with the original scores to evaluate the adjustment effect (whether the scores of deviation devices have decreased, and whether the scores of compliant devices have remained or increased). If the adjustment effect is not as expected (the scores of deviation devices are still higher than the threshold), the process returns to step S153 to readjust the weights or to step S154 to further refine the matching criteria.

[0178] Step S156: Analyze the device processing process records in the interaction result data, and extract two types of information during the device processing process: peak resource usage and processing delay. If any main responsible device exceeds the preset resource usage limit or the processing delay exceeds the preset processing delay limit during the processing process, it is determined that the device is not suitable to continue to be the main responsible device.

[0179] The equipment performance evaluation section extracts peak resource usage (maximum CPU / memory / network usage) and processing latency (total time from action start to completion) from the equipment processing records. The peak resource usage is compared to a preset resource usage limit (set according to equipment hardware configuration and stability requirements), and the processing latency is compared to a preset processing latency limit (set according to execution efficiency requirements). If either indicator exceeds the limit, the equipment is deemed to have insufficient resources or performance, and is unsuitable to continue serving as the primary responsible equipment. The evaluation results are recorded in the equipment performance evaluation table, including the equipment identifier, peak resource usage, resource limit, processing latency, latency limit, and whether the equipment is suitable to continue serving as the primary responsible equipment.

[0180] Step S157: Select the device with the second highest matching score for this requirement dimension from the candidate collaborative devices, whose peak processing resource consumption is lower than the preset resource consumption limit and whose processing latency is lower than the preset processing latency lower limit, and replace the original main responsible device.

[0181] For the replacement of the primary responsible device, the candidate collaborative device list is filtered by adaptability score from highest to lowest based on the demand dimension: First, the device with the second highest score is selected, and its peak processing resource consumption is checked to see if it is lower than the preset resource consumption limit (the upper limit value in step S156) and its processing latency is lower than the preset processing latency lower limit standard (a specific percentage of the upper limit of the demand processing latency). If the conditions are met, it is selected as the new primary responsible device; if not, the next device with a higher score is checked. The replacement record includes the original device identifier, the new device identifier, the reason for replacement (resource overload / latency exceeding the limit), and the replacement time field.

[0182] Step S158: Check whether the alternative devices in the multi-device collaborative interaction link respond effectively when needed. If the response delay of the alternative device exceeds the preset response delay limit, or the processing quality does not meet the preset processing quality standard, then re-select the alternative devices corresponding to the main responsible device and update the alternative device configuration.

[0183] The evaluation of the effectiveness of alternative devices analyzes the response performance of alternative devices in the interaction result data: whether the response latency (the time from starting the alternative mechanism to the alternative device returning a confirmation of receipt) exceeds the preset response latency limit (set according to the real-time requirements of the interaction); and whether the processing quality (the quality index according to step S151) meets the preset processing quality standard (a specific proportion of the required value). If any indicator fails to meet the standard, the alternative device is determined to be invalid, and devices with higher adaptation scores and meeting the response latency and processing quality requirements are re-selected from the candidate collaborative device list, and the alternative device configuration is updated (step S1311).

[0184] Step S159: Based on the recalculated device adaptation score, the replaced primary responsible device, and the updated alternative devices, adjust the device nodes, data transmission paths, and interaction order of interactive operation commands in the multi-device collaborative interaction link.

[0185] The link adjustment section uses the recalculated device adaptation score (step S155), the replaced primary responsible device (step S157), and the updated alternative devices (step S158), repeating the link construction process from steps S139 to S1312. This involves adjusting device nodes (replacing the original primary responsible device node), data transmission paths (updating the path pointing to the new primary responsible device), and the interaction sequence of interactive operation commands (adjusting execution time requirements if the new device has a different processing speed). The adjusted link is then subjected to simulation testing to verify the optimization effect.

[0186] Step S1510: Apply the adjusted adaptation calculation standard and the optimized multi-device collaborative interaction link to the next digital multimedia multi-device collaborative interaction process.

[0187] The optimized application section updates the system runtime environment with the adjusted adaptation weights, matching criteria (adaptation degree calculation standards), and optimized collaborative link configuration files. The new standards and configurations will be automatically loaded the next time collaborative interaction starts, requiring no manual intervention. The application record includes the optimization version number, updated adaptation standards, updated link configurations, and the application time field.

[0188] Step S1511: In the next collaborative interaction process, repeat the steps of demand dimension decomposition, device capability collection, interaction link construction, interaction operation command issuance and interaction result analysis to continuously discover optimization space for adaptation computing standards and link configuration, and continuously adjust and improve to achieve dynamic optimization of multi-device collaborative interaction.

[0189] The continuous optimization mechanism establishes an iterative optimization process. After each collaborative interaction, steps S151 to S1510 of the analysis and optimization process are executed. Through multiple iterations, the deviation between the actual performance of the device and the adaptation score is gradually reduced, improving the stability and efficiency of the collaborative link. All optimization records, interaction result data, adaptation standards, and link configuration versions during the iteration process are stored in the optimization history database for trend analysis and problem tracing.

[0190] Figure 2 This application illustrates a multi-device collaborative interaction system 100 for digital multimedia, including a processor 1001, a memory 1003, and program code stored in the memory 1003. The processor 1001 executes the program code to implement the steps of a multi-device collaborative interaction method for digital multimedia. The processor 1001 and the memory 1003 are connected, for example, via a bus 1002. Optionally, the multi-device collaborative interaction system 100 may further include a transceiver 1004, which can be used for data interaction between this multi-device collaborative interaction system and other multi-device collaborative interaction systems for digital multimedia, such as sending and / or receiving data. It should be noted that in actual scheduling, the transceiver 1004 is not limited to one, and the structure of this multi-device collaborative interaction system 100 for digital multimedia does not constitute a limitation on the embodiments of this application.

[0191] The memory 1003 is used to store program code for executing the embodiments of this application, and its execution is controlled by the processor 1001. The processor 1001 is used to execute the program code stored in the memory 1003 to implement the steps shown in the foregoing method embodiments.

[0192] The above description is only an optional implementation method for some implementation scenarios of this application. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this application, without departing from the technical concept of this application, also fall within the protection scope of the embodiments of this application.

Claims

1. A multi-device collaborative interaction method for digital multimedia, characterized in that, The method includes: Analyze the user interaction requirements of the digital multimedia content to be processed, and decompose the user interaction requirements into presentation requirements, transmission requirements, and operation requirements, and generate requirements dimension decomposition results. Collect capability information of multiple devices to be coordinated, and form a device capability list based on the capability information. The capability information includes specific capability items of the devices in terms of presentation, transmission and operation. Based on the breakdown results of the demand dimensions and the equipment capability list, the adaptability of each device to different demand dimensions is calculated, and a digital multimedia multi-device collaborative interaction link is constructed based on the adaptability. According to the multi-device collaborative interaction link, interactive operation instructions are sent to each device to be collaborated with, guiding each device to perform corresponding digital multimedia processing actions and obtaining interactive result data fed back by the device processing actions; Based on the interaction result data, the calculation standard for the adaptability of each device to different demand dimensions is adjusted, as well as the node configuration of the multi-device collaborative interaction link, to achieve dynamic optimization of multi-device collaborative interaction.

2. The multi-device collaborative interaction method for digital multimedia according to claim 1, characterized in that, The analysis of user interaction requirements for the current digital multimedia content to be processed involves breaking down these requirements into presentation, transmission, and operation dimensions, generating a requirement dimension breakdown result, including: Obtain the content attributes of the digital multimedia content to be processed, wherein the content attributes include content type, content carrier format and content data characteristics; Based on the content attributes, the types of user interaction behaviors that may occur are determined. These types of interaction behaviors include viewing behaviors, editing behaviors, and sharing behaviors. For each type of interaction behavior, user expectations for that type of interaction behavior are collected. These expectations include user demands for the effectiveness, efficiency, and method of the behavior. The desired information is divided into presentation requirement dimension, transmission requirement dimension and operation requirement dimension according to the core elements affecting the realization of interaction; The presentation requirements are further refined, and specific requirements under each presentation requirement are extracted, including requirements for content clarity, color reproduction, smoothness, and size adaptation. The transmission requirement dimension is refined, and specific requirement items under this transmission requirement dimension are extracted, including content data transmission speed requirements, data integrity requirements during transmission, transmission delay control requirements, and transmission synchronization requirements between multiple devices. The operational requirements dimension is refined, and specific requirements under this operational requirements dimension are extracted, including user operation trigger response speed requirements, operation command synchronization requirements across multiple devices, operation permission division requirements, and operation result feedback method requirements. For each requirement dimension, specific requirement items are marked with requirement priority. The priority is determined based on the user's emphasis on the requirement item and the degree of impact of the requirement item on the interactive experience. The presentation of the demand dimension, transmission demand dimension, operation demand dimension, and their specific demand items and demand priorities are integrated to form the demand dimension decomposition result.

3. The multi-device collaborative interaction method for digital multimedia according to claim 1, characterized in that, The process involves collecting capability information from multiple devices to be coordinated, and forming a device capability list based on this information, including: Establish communication connections with multiple devices to be coordinated, and send a capability information collection request to each device. The request specifies the capability categories to be collected as presentation capability, transmission capability, and operation capability. Receive basic capability data from each device based on capability information collection requests. The basic capability data includes device hardware configuration information, software function support information, and historical collaborative interaction performance data. Extract specific capability items related to presentation capabilities from the basic capability data, including the maximum screen resolution supported by the device, the frame rate range that the device can output, the color processing capability range of the device, the screen scaling modes supported by the device, and the screen display response speed of the device. Specific capability items related to transmission capabilities are extracted from the basic capability data, including the device's maximum data transmission rate, the device's packet loss rate in different network environments, the device's recovery speed after transmission interruption, the types of transmission protocols supported by the device, and the device's ability to transmit multiple data streams simultaneously. Extract specific capability items related to operational capabilities from the basic capability data, including the response time of the device after receiving the operation command, the delay of the device synchronizing the operation command to other devices, the types of operation commands supported by the device, the device's ability to set operation permissions, and the way the device provides feedback on operation results. The authenticity of the extracted presentation capability items, transmission capability items, and operation capability items of each device is verified by comparing the consistency between the device's historical capability data and the current feedback data, and by verifying the matching degree between the device's actual capability and the feedback capability items through test data with a preset amount of data. Remove the capabilities that fail verification, and retain the true and valid presentation capabilities, transmission capabilities, and operational capabilities; Create a unique capability record for each device to be coordinated. The unique capability record contains a device identifier, a list of presentation capabilities, a list of transmission capabilities, and a list of operation capabilities. Integrate the unique capability records of all devices to form a device capability list.

4. The multi-device collaborative interaction method for digital multimedia according to claim 1, characterized in that, The step of calculating the adaptability of each device to different demand dimensions based on the demand dimension breakdown results and the device capability list, and constructing a digital multimedia multi-device collaborative interaction link based on the adaptability, includes: Extract the specific requirements and priorities of the presentation requirements dimension from the results of the demand dimension breakdown, and extract the presentation capability list of each device from the device capability list; For each specific requirement item under the presentation requirement dimension, compare the presentation capability items of each device with the specific requirement item. If the device's presentation capability item meets the requirements of the specific requirement item, it is recorded as a successful match; otherwise, it is recorded as a failed match. Based on the priority of each specific requirement under the presenting requirement dimension, an adaptation weight is set for each specific requirement. For specific requirements whose priority meets the preset priority standard, the adaptation weight is set to meet the preset weight value standard. Based on the matching results and adaptation weights of each specific requirement item under the presentation requirement dimension for each device, the adaptation score of each device for the presentation requirement dimension is calculated. The adaptation score is calculated as the sum of the products of the matching results of each specific requirement item and the corresponding adaptation weight. Using the same method, the adaptation scores of each device for the transmission requirement dimension and the operation requirement dimension were calculated respectively. The adaptation scores of each device in the three demand dimensions are normalized respectively. The normalized adaptation scores of the three dimensions are then weighted and summed according to a preset ratio to obtain the comprehensive adaptation score of each device. Based on the comprehensive compatibility score of each device, devices whose comprehensive compatibility score reaches the preset compatibility score threshold are selected as candidate collaborative devices; For each requirement dimension in the requirement dimension breakdown results, select the device with the highest adaptation score for that dimension from the candidate collaborative devices as the main responsible device for that requirement dimension; Determine the interaction relationship between the main responsible devices for each demand dimension. The main responsible device for the presentation demand dimension needs to provide content presentation parameters to the main responsible device for the transmission demand dimension. The main responsible device for the transmission demand dimension needs to provide content transmission status to the main responsible device for the operation demand dimension. The main responsible device for the operation demand dimension needs to provide operation instructions to the main responsible device for the presentation demand dimension. Based on the interaction relationship between the main responsible devices, set the data transmission path, interaction sequence of operation commands and status feedback mechanism between the devices; Configure at least one alternative device for each primary responsible device. The selection criteria for alternative devices are the candidate collaborative devices with the second highest matching score for this requirement dimension. By integrating the primary responsible equipment, alternative equipment, inter-device interaction relationships, data transmission paths, interactive operation command sequence, and status feedback mechanisms, a digital multimedia multi-device collaborative interaction link is constructed.

5. The multi-device collaborative interaction method for digital multimedia according to claim 1, characterized in that, The step of issuing interactive operation commands to each device to be coordinated according to the multi-device collaborative interaction link, guiding each device to execute corresponding digital multimedia processing actions, and obtaining interactive result data fed back by the device processing actions includes: The main responsible device identifier, alternative device identifier, and corresponding responsibilities of each device in the multi-device collaborative interaction link are analyzed to determine the types of digital multimedia processing actions that each device needs to perform. The types of digital multimedia processing actions include content decoding actions, content rendering actions, content transmission actions, operation instruction receiving actions, and operation result feedback actions. Based on the requirements of each specific requirement item in the demand dimension breakdown results, determine the specific parameters for each device to perform the corresponding digital multimedia processing action. The specific parameters for content rendering action include rendering resolution, rendering frame rate and rendering color parameters. The specific parameters for content transmission action include transmission rate limit, transmission data verification method and transmission delay control target. According to the interaction sequence of the interaction operation instructions in the multi-device collaborative interaction link, generate the corresponding interaction operation instructions for each device. Each corresponding interaction operation instruction for each device includes the device identifier, the type of digital multimedia processing action, the specific parameters of the digital multimedia processing action, and the execution time requirements. Based on the data transmission path in the multi-device collaborative interaction link, establish a direct communication channel between each device. The setting of the direct communication channel must meet the transmission protocol type requirements in the device transmission capability item. According to the interaction order of the interactive operation instructions, the corresponding interactive operation instructions of each device are sent to the target device through the corresponding direct communication channel in sequence. During the issuance of interactive operation commands, the transmission status of the direct communication channel is monitored in real time, and the issuance time of the interactive operation command, the reception time of the interactive operation command, and the data packet loss during the transmission process are recorded. If any device fails to receive the interactive operation command within the specified time, or if the received interactive operation command has missing data, the backup device mechanism in the multi-device collaborative interaction link is activated, the interactive operation command is sent to the corresponding backup device, and the data transmission path is updated. After receiving the interactive operation command, each device executes the digital multimedia processing action according to the type and specific parameters of the digital multimedia processing action in the interactive operation command. During the execution of the digital multimedia processing action, the processing progress, processing resource usage and abnormal information during the processing are recorded in real time. After the device completes the digital multimedia processing action, it generates a processing result report, which includes the completion time of the digital multimedia processing action, a description of the digital multimedia processing result, and a record of the digital multimedia processing process. The processing result report is fed back to the control terminal that initiated the interactive operation command through a direct communication channel. The control terminal that initiated the interactive operation command collects the processing result reports, interactive operation command transmission records and device processing records of all devices, and integrates the processing result reports, interactive operation command transmission records and device processing records of all devices to form interactive result data.

6. The multi-device collaborative interaction method for digital multimedia according to claim 1, characterized in that, The process of adjusting the calculation standard for the adaptability of each device to different demand dimensions based on the interaction result data, and the node configuration of the multi-device collaborative interaction link, to achieve dynamic optimization of multi-device collaborative interaction, includes: Analyze the processing result reports in the interaction result data, extract the completion quality information of each device's processing action, and present whether the image clarity and smoothness of the main responsible device in the demand dimension meet the requirements and whether the transmission speed and packet loss rate are within the control range in the processing result of the main responsible device in the transmission demand dimension. Based on the quality information of the completed processing, it is determined whether the actual adaptation performance of each device in the corresponding requirement dimension is consistent with the previously calculated adaptation score. If the actual completion quality does not meet the requirements and the adaptation score exceeds the preset adaptation score threshold, the adaptation calculation standard of the corresponding requirement dimension of the device is marked as having a deviation. Based on the standard deviation of the adaptation calculation of the tag, the adaptation weight of each specific requirement item under the requirement dimension is re-evaluated. If the actual processing quality deviation of any specific requirement item exceeds the preset deviation allowable range according to the interaction result data, and the adaptation weight value of the specific requirement item was previously lower than the preset low adaptation weight threshold, then the adaptation weight value of the specific requirement item is increased to meet the preset weight value standard. Redefine the matching criteria between specific requirements and equipment capabilities. If a previous match was deemed successful but the actual processing quality did not meet the requirements, refine the matching criteria and add specific parameter requirements for the capability items. Based on the adjusted adaptation weights and matching criteria, the adaptation scores and overall adaptation scores of each device for different demand dimensions are recalculated. Analyze the device processing records in the interaction result data, and extract two types of information during the device processing: peak resource usage and processing delay. If any main responsible device exceeds the preset resource usage limit or the processing delay exceeds the preset processing delay limit during the processing process, it is determined that the device is not suitable to continue to be the main responsible device. Select the device with the second-highest matching score for this requirement dimension from the candidate collaborative devices, whose peak processing resource consumption is lower than the preset resource consumption limit and whose processing latency is lower than the preset processing latency lower limit, and replace the original main responsible device; Check whether the alternative devices in the multi-device collaborative interaction link respond effectively when needed. If the response delay of the alternative device exceeds the preset response delay limit, or the processing quality does not meet the preset processing quality standard, then re-select the alternative devices corresponding to the main responsible device and update the alternative device configuration. Based on the recalculated device compatibility score, the replaced primary responsible device, and the updated alternative devices, adjust the device nodes, data transmission paths, and interaction order of interactive operation commands in the multi-device collaborative interaction link. The adjusted adaptation calculation standard and the optimized multi-device collaborative interaction link will be applied to the next digital multimedia multi-device collaborative interaction process. In the next collaborative interaction, the steps of demand dimension decomposition, device capability collection, interaction link construction, interaction operation command issuance and interaction result analysis are repeated to continuously discover optimization space for adaptation computing standards and link configuration, and continuously adjust and improve to achieve dynamic optimization of multi-device collaborative interaction.

7. The multi-device collaborative interaction method for digital multimedia according to claim 2, characterized in that, The process of determining the types of user interaction behaviors based on the content attributes includes: Based on the mapping relationship between content type and predefined interaction behavior type, a set of basic interaction behavior types corresponding to the content type is determined. The predefined interaction behavior type mapping relationship specifies the basic behavior types of viewing, editing, and sharing associated with video content, audio content, image content, and text content, respectively. Based on the content carrier format, specific behavior types are activated or deactivated from the set of basic interactive behavior types. If the content carrier format is mobile terminal storage, the offline editing behavior type is activated; if the content carrier format is cloud storage, the online sharing behavior type is activated. Based on the characteristics of the content data, the technical implementation requirements of specific behavior types in the set of basic interactive behavior types are adjusted. If the amount of content data exceeds the preset upper limit threshold, a transmission efficiency requirement is set for the sharing behavior type; if the amount of content data is lower than the preset lower limit threshold, an operation response speed requirement is set for the editing behavior type. Integrate the set of basic interactive behavior types that have been activated or deactivated by the content carrier form and adjusted by the content data characteristics to form the set of interactive behavior types corresponding to the digital multimedia content to be processed.

8. The multi-device collaborative interaction method for digital multimedia according to claim 3, characterized in that, The authenticity of the extracted presentation capability items, transmission capability items, and operational capability items of each device is verified by comparing the consistency between the device's historical capability data and the current feedback data, and by verifying the matching degree between the device's actual capabilities and the feedback capability items through test data of a preset amount of data, including: Extract the device's past presentation capability data, transmission capability data, and operation capability data from the device's historical collaborative interaction records to form a historical capability dataset for the device. The presentation capability items, transmission capability items, and operation capability items extracted from the basic capability data are compared item by item with the corresponding data in the device's historical capability dataset. Calculate the deviation between the current capability item and historical capability data. If the deviation is within the preset allowable deviation range, the current capability item is deemed to have passed the historical data comparison verification. If the deviation exceeds the preset allowable deviation range, the current capability item is marked as an item to be further verified. For all capability items, generate test data with a preset data volume. The test data with the preset data volume must cover the core parameter requirements of each capability item. For the maximum screen resolution capability item in the presentation capability item, it includes test images with different resolution specifications; for the maximum data transmission rate capability item in the transmission capability item, it includes test files of different sizes; for the operation response time capability item in the operation capability item, it includes different types of test operation commands. The generated test data of a preset amount is sent to the corresponding device to be coordinated, and the corresponding device to be coordinated is required to perform corresponding actions according to the requirements of the test data of the preset amount. The corresponding actions to be coordinated by the device include displaying test images, transmitting test files, and responding to test operation commands. Record the actual performance data of the corresponding device to be coordinated when performing the corresponding action. The actual performance data of the corresponding device to be coordinated includes the actual resolution when displaying the test image, the actual transmission rate when transmitting the test file, and the actual response time when responding to the test operation command. The actual performance data of the corresponding device to be coordinated is compared with the corresponding capability item reported by the current device. If the actual performance data meets the requirements of the capability item description, the current capability item is determined to have passed the actual test. If the actual performance data does not meet the requirements of the capability item description, the current capability item is determined to have failed the verification. For items marked as requiring further verification in historical data comparison, if they pass verification at the actual testing level, the current capability item will be retained; if they also fail verification at the actual testing level, the current capability item will be removed. Summarize the verification results of all capabilities to form an equipment capability verification report, which includes a list of capabilities that have passed verification and a list of capabilities that have failed verification.

9. The multi-device collaborative interaction method for digital multimedia according to claim 4, characterized in that, The step of setting up data transmission paths, interactive operation command sequence, and status feedback mechanisms between devices based on the interaction relationships of each main responsible device includes: Determine the types of content presentation parameters that the device responsible for the presentation requirements dimension needs to provide to the device responsible for the transmission requirements dimension. Determine the transmission format and transmission frequency of the content presentation parameters. The types of content presentation parameters include target presentation resolution, target presentation frame rate, color space standard, and screen scaling ratio. Based on the transmission format and frequency of the content presentation parameters, and combined with the transmission protocol type in the transmission capability items of the main device responsible for the presentation requirements dimension and the main device responsible for the transmission requirements dimension, a suitable transmission channel is selected, and a one-way data transmission path is set from the main device responsible for the presentation requirements dimension to the main device responsible for the transmission requirements dimension. Determine the content transmission status type that the device responsible for the transmission demand dimension needs to provide to the device responsible for the operation demand dimension, and determine the feedback cycle and feedback format of the content transmission status information. The content transmission status type includes the current transmission rate, the amount of data transmitted, the transmission packet loss situation, and the transmission delay. Based on the feedback cycle and format of the content transmission status information, and combined with the transmission delay control capabilities in the transmission capability items of the main responsible devices in the transmission demand dimension and the operation demand dimension, a one-way data transmission path is set from the main responsible device in the transmission demand dimension to the main responsible device in the operation demand dimension, so that the content transmission status information is delivered within the feedback cycle. The types of operation instructions that the main responsible device for the operation requirement dimension needs to feed back to the main responsible device for the presentation requirement dimension are determined. The operation instruction types include screen switching instructions, volume adjustment instructions, playback progress adjustment instructions, and screen effect adjustment instructions. The encoding format and priority of the operation instructions are also determined. Based on the encoding format and priority of the operation instructions, and combined with the operation response speed of the operation capability items of the main responsible device in the operation requirement dimension and the main responsible device in the presentation requirement dimension, a one-way interactive operation instruction transmission path is set from the main responsible device in the operation requirement dimension to the main responsible device in the presentation requirement dimension. Operation instructions whose priority meets the preset priority standard adopt the priority transmission channel. The order of interactive operation instructions is determined. The device responsible for the operation requirement dimension must first receive the user's operation instruction and then feed the user's operation instruction back to the device responsible for the presentation requirement dimension. At the same time, the device responsible for the transmission requirement dimension must feed back the content transmission status to the device responsible for the operation requirement dimension in real time. The device responsible for the presentation requirement dimension must adjust the content presentation parameters according to the user's operation instruction and then send the new content presentation parameters to the device responsible for the transmission requirement dimension. In the status feedback mechanism, if the device responsible for the transmission demand dimension detects that the transmission packet loss rate exceeds the preset allowable range, it must immediately send a transmission anomaly notification to the device responsible for the operation demand dimension. After receiving the transmission anomaly notification, the device responsible for the operation demand dimension will stop issuing new interactive operation commands to the device responsible for the presentation demand dimension and provide feedback on the transmission anomaly information to the user. In the status feedback mechanism, the normal feedback process is set up so that each main responsible device must send a normal status confirmation message to the associated device according to the preset feedback cycle. The data transmission path, interactive operation command sequence, and status feedback mechanism are organized into a link interaction specification. The link interaction specification is a component of the multi-device collaborative interaction link, so that each main responsible device can perform interactive operations in accordance with the link interaction specification.

10. A multi-device collaborative interaction system for digital multimedia, characterized in that, The method includes a processor and a computer-readable storage medium storing machine-executable instructions that, when executed by the processor, implement the multi-device collaborative interaction method for digital multimedia as described in any one of claims 1-9.

Images