Multi-terminal-oriented rapid live broadcast creation and low-delay distribution method and system

Abstract

The invention relates to a multi-terminal-oriented rapid live broadcast creation and low-delay distribution method and system, and relates to the field of streaming media transmission, and the method comprises the steps: building a pre-connection channel in response to a multi-platform live broadcast creation request and a platform identifier; when it is judged that the abnormal live broadcast platform exists, a specific standby platform is selected; generating an edge node scheduling instruction and a dynamic routing configuration parameter based on the specific standby platform and the real-time service parameter of the specific standby platform; switching the video stream from the pre-connection channel of the abnormal live broadcast platform to the pre-connection channel of the specific standby platform, and synchronously triggering the migration and synchronization of the associated service data; and in response to an edge node scheduling instruction and a dynamic routing configuration parameter, scheduling an edge computing node corresponding to the specific standby platform to take over the distribution of the video stream, and distributing the live broadcast stream to the user terminal along the optimized transmission path, thereby completing low-delay distribution. The method and the device have the effect of improving the consistency of watching experience.

Description

Technical Field

[0001] This invention relates to the field of streaming media transmission, and in particular to a method and system for rapid live streaming creation and low-latency distribution for multiple terminals. Background Technology

[0002] Rapid live streaming creation and low-latency distribution for multiple terminals refers to the technical means to enable rapid preparation and release of live streams in a multi-platform, multi-terminal environment, and to ensure seamless synchronization of video streams and related business data, continuous terminal viewing experience, and controllable latency when switching between platforms.

[0003] Currently, multi-platform live streaming mainly relies on synchronous streaming tools or independent backends for each platform, which can complete basic video stream distribution.

[0004] When a live stream is interrupted due to content moderation, network instability, or service anomalies on a certain platform, it is impossible to quickly and automatically switch to other available platforms, resulting in a gap in the live stream and loss of viewers. In addition, the interruption and reloading of the video stream caused by platform switching will also produce significant viewing delays, reducing the continuity of the viewing experience, which needs to be improved. Summary of the Invention

[0005] To improve the continuity of the viewing experience, this invention provides a method and system for rapid live streaming creation and low-latency distribution across multiple terminals.

[0006] In a first aspect, the present invention provides a method for rapid live streaming creation and low-latency distribution across multiple terminals, employing the following technical solution: A method for rapid live streaming creation and low-latency distribution across multiple terminals includes: Collect live streaming creation requests from multiple platforms and the platform identifiers of multiple target live streaming platforms bound to the user; In response to multi-platform live streaming creation requests and platform identifiers, the system synchronously calls the open interfaces of multiple preset target live streaming platforms, initiates live streaming push requests, and establishes and maintains a pre-connected channel in an inactive state for each platform. Collect link quality signals from each pre-connected channel, live stream status feedback from each platform, and content review status codes; Based on link quality signals, live stream status feedback, and content review status codes, a multi-rule fusion judgment model is used to determine whether there are abnormal live streaming platforms and their abnormal types. When an abnormal live streaming platform is identified, the abnormality type is retrieved, and a specific backup platform is dynamically selected from the target live streaming platform based on the abnormality type, the preset platform switching rules, and the real-time service parameters of each platform. Based on the specific backup platform and its real-time service parameters, generate edge node scheduling instructions and dynamic routing configuration parameters; Control the live streaming engine to switch the video stream from the pre-connection channel of the abnormal live streaming platform to the pre-connection channel of the specific backup platform, and simultaneously trigger the migration and synchronization of related business data; In response to edge node scheduling instructions and dynamic routing configuration parameters, the edge computing node corresponding to the specific backup platform is scheduled to take over the distribution of the video stream and distribute the live stream to the user terminal along the optimized transmission path, thereby completing low-latency distribution.

[0007] By adopting the above technical solution and through real-time fusion analysis of multi-dimensional signals such as link, status, and review, the system can intelligently identify the anomaly types of specific platforms and dynamically select a backup platform based on rules and real-time indicators. During the switchover, the video stream is switched to the pre-connected channel of the backup platform, and related business data is migrated synchronously. By scheduling edge nodes and optimizing transmission paths, the system ensures low latency and high availability in the distribution process, reduces live broadcast interruption time and perceived stuttering on the viewer's end, and improves the robustness of multi-platform live broadcasts and the continuity of the terminal viewing experience.

[0008] Optionally, the specific steps for selecting a backup platform include: The corresponding platform selection preference weight set is determined based on the anomaly type. Collect real-time service parameters from each candidate live streaming platform; Based on the platform selection preference weight set, the real-time service parameters of each candidate platform are weighted and scored to obtain the scenario adaptability score of each platform. The candidate platforms are sorted according to their scenario adaptability scores, and the platform with the highest score is selected as the specific backup platform.

[0009] By adopting the above technical solution, by understanding the anomaly type, a corresponding set of platform selection preference weights is given. Then, by combining the real-time service parameters of each alternative platform, a weighted score is calculated, and the platform with the highest score is selected as the specific backup platform, thereby improving the accuracy of the switching decision.

[0010] Optionally, a smart live stream title generation step is also included: Collect information on trending topics online, product type tags from enterprise product databases, and target customer profile tags; Semantic analysis of trending online information is performed to extract core trending words; Determine product category keywords based on product type tags; Input the core hot keywords and product category keywords into the relevance calculation model to generate hot product relevance scores; Based on the relevance score of popular products and the target customer profile tags, the system selects matching title templates from a pre-set multi-dimensional title template library; The system calls a title template and fills in core trending words and product category keywords as variables to generate candidate live stream titles, which are then pushed to the user's terminal for selection.

[0011] By adopting the above technical solution, semantic parsing and relevance calculation are used to obtain the relevance score of hot products. Then, the target customer profile tags are combined to match the title template. Finally, the core hot words and product category keywords are used as variables to fill in the title template for users to choose from, thereby reducing the time and effort required to write titles.

[0012] Optionally, it also includes steps for configuring marketing interaction strategies: Collect the final live stream title; Generate targeted marketing interaction components and initial parameters based on product category keywords; The final live stream title, product category keywords, target marketing interaction components, and initial parameters are packaged together to generate a live stream strategy package; When responding to a multi-platform live streaming creation request, the live streaming strategy package is parsed, and the title information, product information, and marketing interaction configuration contained therein are synchronously distributed and pre-configured to the respective live streaming room backends of each target live streaming platform through the corresponding management interface.

[0013] By adopting the above technical solution, the final live broadcast title is collected to know the specific title selected by the user. Then, by understanding the product category keywords, the target marketing interaction components and initial parameters are obtained. The final live broadcast title, product category keywords, target marketing interaction components and initial parameters are then encapsulated to obtain the live broadcast strategy package. When responding to live broadcast creation requests from multiple platforms, the live broadcast configuration can be completed quickly by parsing the live broadcast strategy package, thereby improving the speed of live broadcasting.

[0014] Optionally, it also includes specific steps for controlling the live streaming engine to switch the video stream from the pre-connection channel of the faulty live streaming platform to the pre-connection channel of a specific backup platform: Collect trigger signals and system clock from the unified control interface; The trigger signal is compared with the preset instruction template, and the system clock is compared with the preset timing plan. Determine the trend of feedback parameters based on live stream status feedback; Based on the comparison results, anomaly types, and feedback parameter trends, determine whether any preset switching trigger condition is met; When any switching trigger condition is met, a corresponding switching instruction is generated; In response to switching commands, control the live streaming engine to perform video stream switching operations.

[0015] By adopting the above technical solution, and by understanding the trigger signal, system clock, and live stream status feedback, it is determined whether multiple trigger conditions are met. Once any switching trigger condition is met, a switching command is generated and executed to complete the channel switching. This enhances the flexibility and intelligence of system operation while ensuring the continuity of user experience.

[0016] Optionally, it also includes a step of synchronizing and migrating related business data: Responding to switching commands to collect customer identifier lists, real-time shopping cart data, and real-time order information; The data interface specifications will be determined based on the specific backup platform. The data interface specifications, real-time shopping cart data, and real-time order information are serialized and encapsulated to generate a platform-specific data synchronization package. While controlling the live streaming engine to perform video stream switching operations, call the data synchronization interface of the specific backup platform and submit the platform-specific data synchronization package and customer identification list. In the live streaming instance of the specific backup platform, the submitted data is parsed and loaded to restore the complete shopping and interaction session state of each customer before the switch.

[0017] By adopting the above technical solution, when a switching instruction is received, the real-time interactive state is serialized and encapsulated to obtain a platform-specific data synchronization package. While controlling the live streaming engine to perform video stream switching operations, the platform-specific data synchronization package is called to restore the complete shopping and interactive session state of each customer before the switch, ensuring the continuity of user experience in highly interactive scenarios such as live streaming e-commerce.

[0018] Optionally, it also includes switching audience guidance methods: Collect the live stream access links for specific backup platforms; Based on the switching command and the live stream access link, generate platform switching guidance information; The platform switching guidance information will be pushed to the overlay of the live stream screen of the abnormal live streaming platform for display, and simultaneously pushed to the live stream chat system; The user departure rate after the collection and guidance information is displayed; When the user departure rate is lower than the preset expected threshold, the platform switches the guidance information to generate enhanced guidance instructions and push them a second time.

[0019] By adopting the above technical solution, after a platform switch, guiding information is proactively pushed to the original live stream room through visuals and chat channels, while the audience's migration response rate is monitored in real time. When the guiding effect is found to be unsatisfactory, an enhanced guiding strategy is generated and executed for a second, more precise outreach, improving the success rate and efficiency of audiences following the switch and reducing audience loss caused by the platform switch.

[0020] Optionally, channel health maintenance methods may also be included: Periodically send probe data packets to each pre-connected channel and collect probe response latency and probe packet loss rate; The real-time health score of each channel is calculated based on the detection response latency and the detection packet loss rate, and the historical health baseline value of each channel is collected. The real-time health score of each channel is compared with its historical health baseline value to determine whether the health status has deteriorated. When the health status of any channel is determined to have deteriorated, the channel is deemed to have failed and a reconstruction process is initiated based on its platform identifier.

[0021] By employing the aforementioned technical solution, precise network metrics such as real-time response latency and packet loss rate are obtained through periodic active probing, and a quantified health score is calculated accordingly. The real-time score is compared with historical health baseline values ​​to determine if degradation has occurred. Once degradation is detected, channel failure is identified and a reconstruction process is triggered. This ensures that every channel in the backup channel resource pool is in a reliable state before actual switching demands occur, improving the availability and reliability of the pre-connected channel infrastructure.

[0022] Optionally, steps may also be included before collecting multi-platform live stream creation requests: Collect user selection commands for historical live streaming templates from the unified control interface; In response to the selection command, the corresponding target historical live streaming template is retrieved from the pre-stored template library; Based on the target historical live streaming template, the streaming parameter configuration and screen layout parameters encapsulated therein are derived; The streaming parameter configuration and screen layout parameters are automatically populated into the newly created live streaming session, and a multi-platform live streaming creation request is generated based on the populated live streaming session.

[0023] By adopting the above technical solution, the specific historical template selected by the user is used to obtain the streaming parameter configuration and screen layout parameters encapsulated therein. These parameters are then automatically filled into the newly created live streaming session, thereby quickly generating multi-platform live streaming creation requests and improving the startup speed and ease of operation of live streaming creation.

[0024] Secondly, this application provides a rapid live streaming creation and low-latency distribution system for multiple terminals, employing the following technical solution: A system for rapid live streaming creation and low-latency distribution across multiple terminals, comprising: The data acquisition module is used to collect live streaming creation requests, platform identifiers, link quality signals, live stream status feedback, and content review status codes from multiple platforms. The memory is used to store the program that implements a method for fast live streaming creation and low-latency distribution for multiple terminals; The processor is used to load and execute programs stored in memory.

[0025] In summary, this application includes at least one of the following beneficial technical effects: 1. By integrating and analyzing multi-dimensional signals such as links, status, and auditing in real time, the system can intelligently identify anomaly types on specific platforms and dynamically select a backup platform based on rules and real-time indicators. During the switchover, the video stream is switched to the pre-connected channel of the backup platform, and related business data is migrated synchronously. By scheduling edge nodes and optimizing transmission paths, the system ensures low latency and high availability in the distribution process, reduces live stream interruption time and perceived stuttering on the viewer's end, and improves the robustness of multi-platform live streaming and the continuity of the terminal viewing experience. 2. By semantic parsing and relevance calculation, the relevance score of hot products is obtained. Then, the target customer profile tags are combined to match the title template. Finally, the core hot words and product category keywords are filled into the title template as variables for users to choose from, thereby reducing the time and effort of writing titles. 3. When a switching instruction is received, the platform-specific data synchronization package is obtained by serializing and encapsulating the real-time interactive state. While controlling the live streaming engine to perform the video stream switching operation, the platform-specific data synchronization package is called to restore the complete shopping and interactive session state of each customer before the switch, ensuring the continuity of user experience in highly interactive scenarios such as live streaming e-commerce. Attached Figure Description

[0026] Figure 1 This is a flowchart illustrating a method for rapid live streaming creation and low-latency distribution across multiple terminals. Figure 2 This is a flowchart illustrating the steps involved in generating intelligent live stream titles. Detailed Implementation

[0027] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments.

[0028] Reference Figure 1 This application discloses a method for rapid live streaming creation and low-latency distribution across multiple terminals, comprising the following steps: S10: Collects multi-platform live streaming creation requests and platform identifiers of multiple target live streaming platforms bound by the user.

[0029] A multi-platform live streaming creation request refers to a set of instructions submitted by a user through a unified control interface, aimed at creating live streaming rooms simultaneously or sequentially on multiple live streaming platforms. The specific production steps of a platform live streaming creation request will be explained in detail in subsequent sections S90 to S93, and will not be repeated here.

[0030] A platform identifier is a set of technical credentials used to uniquely identify and authorize access to a specific live streaming platform at the system level. It typically includes an application key assigned by the platform, a unique identifier for the user account, and a time-limited access token. The platform identifier is pre-authorized and bound by the user and securely stored in the system.

[0031] S11: In response to the multi-platform live streaming creation request and platform identifier, synchronously call the open interfaces of multiple preset target live streaming platforms, initiate live streaming push requests, and establish and maintain a pre-connection channel in an inactive state for each platform.

[0032] Open interfaces refer to application programming interfaces (APIs) provided by various live streaming platform service providers to developers that conform to their technical specifications, such as specific APIs used to create live streaming rooms or obtain streaming addresses.

[0033] A pre-connected channel refers to a pre-established, active network transport layer connection between the channel and the streaming servers of each platform before the actual transmission of audio and video stream data. This channel is maintained by periodically sending keep-alive packets but does not transmit service data streams. Its purpose is to eliminate the latency caused by re-establishing connections during subsequent handovers.

[0034] In response to the multi-platform live streaming creation request and platform identifier, it is necessary to synchronously call the open interfaces of multiple target live streaming platforms bound by the user, initiate live streaming push requests, and establish and maintain a pre-connection channel in an inactive state for each platform for subsequent steps.

[0035] S12: Collect link quality signals of each pre-connected channel, live stream status feedback from each platform, and content review status codes.

[0036] Link quality signals refer to quantitative indicators that reflect the performance of the pre-connected channel network, mainly including network round-trip time, packet loss rate, and transmission jitter.

[0037] Link quality signals are obtained by periodically sending probe data packets of a specific size to each pre-connected channel, calculating the round-trip time of the data packets, counting the number of lost packets, and analyzing the fluctuations in continuous probe delay. The size and sending period of the probe data packets can be preset by those skilled in the art based on the actual network environment, and will not be elaborated here. The specific calculation methods for round-trip delay, packet loss rate, and transmission jitter are common knowledge in the art and will not be elaborated here.

[0038] Live stream status feedback refers to data about the real-time operating status of the live stream room, mainly including video bitrate, audio status, buffer information, and platform confirmation status.

[0039] The live stream status feedback is obtained through a combination of two methods: first, by monitoring the status callback information actively pushed by each live streaming platform through its open interface; and second, by actively querying the platform server or simulating streaming through the system's self-built streaming media monitoring probe to analyze the real-time streaming media quality. The specific methods for parsing and obtaining video bitrate, audio status, buffer information, and platform reception confirmation can be implemented by those skilled in the art based on the selected platform protocol and monitoring scheme, and will not be elaborated here.

[0040] Content moderation status codes are machine-readable codes returned by the live streaming platform's content security system, indicating the current compliance status of the live stream. Examples include success codes representing normal operation and specific error codes indicating interruption due to violations. Content moderation status codes are obtained by listening for HTTP / HTTPS callback notifications sent by the platform server or by polling the platform's live stream status query interface. The specific formats of the callback notifications and query interfaces follow the open API specifications of each platform and are well-known to those skilled in the art, and will not be elaborated upon here.

[0041] S13: Based on link quality signals, live stream status feedback, and content review status codes, a multi-rule fusion judgment model is used to determine whether there are abnormal live streaming platforms and their abnormal types.

[0042] An abnormal live streaming platform refers to a target platform where serious problems occur in any aspect of its streaming process, such as the streaming link, media stream quality, or content compliance, resulting in the platform being unable to conduct live streaming normally or severely impairing the viewing experience.

[0043] Anomaly types are categorized based on the root cause of the problem. In this embodiment, the anomaly types mainly include network connection anomalies caused by link quality degradation, stream transmission quality anomalies caused by substandard stream status feedback, and platform rule anomalies triggered by content moderation status codes.

[0044] A multi-rule fusion judgment model comprehensively analyzes link quality signals, live stream status feedback, and content review status codes to determine whether an abnormal live streaming platform exists and its specific anomaly type. The model evaluates and logically combines various input signals using preset judgment rules and thresholds, and then outputs the judgment result. Specifically, when the link quality signal is consistently below a preset network health threshold, it is judged as a network connection anomaly; when key indicators in the live stream status feedback consistently fail to meet preset stream quality thresholds, it is judged as a stream transmission quality anomaly; when the content review status code matches a preset set of violation or interruption status codes, it is judged as a platform rule anomaly. The specific settings of the judgment rules, various thresholds, and status code sets can be configured by those skilled in the art according to business needs and platform characteristics, and will not be elaborated here. The specific implementation methods of the multi-rule fusion judgment model (such as those based on rule engines or lightweight machine learning models) are well known to those skilled in the art and will not be elaborated here.

[0045] S14: When an abnormal live streaming platform is determined, retrieve the abnormality type and dynamically select a specific backup platform from the target live streaming platform based on the abnormality type, the preset platform switching rules, and the real-time service parameters of each platform.

[0046] Platform switching rules refer to a set of predefined decision rules and parameter configurations associated with different anomaly types. For example, for network anomalies, platforms with high network affinity are prioritized; for rule-related anomalies, platforms with differentiated content strategies are prioritized. Platform switching rules are pre-defined by those skilled in the art and will not be elaborated upon here.

[0047] Real-time service parameters for each platform refer to the performance and status data collected in real time from all alternative platforms at the moment of decision-making, including API response latency, server load rate, estimated network quality, and policy compatibility.

[0048] The specific backup platform refers to the alternative platform that is most suitable for undertaking this live broadcast migration, taking into account the current anomaly type, the activated switching strategy, and the real-time indicators of each platform.

[0049] The specific steps for selecting the backup platform will be explained in detail in subsequent sections S20 to S23, and will not be repeated here.

[0050] When an abnormal live streaming platform is identified, the type of abnormality must be retrieved first, and then a dynamic selection process must be performed to determine the specific backup platform.

[0051] The anomaly type is obtained by retrieving the anomaly classification field from the judgment result output by the multi-rule fusion judgment model. The anomaly classification field is generated and stored in the system's state management module when the model completes the judgment. When a platform switching decision is required, it is directly read and called by the decision logic, which will not be elaborated here.

[0052] S15: Generate edge node scheduling instructions and dynamic routing configuration parameters based on the specific backup platform and its real-time service parameters.

[0053] Edge node scheduling commands are control commands used to control the content distribution network, switching the receiving and distribution nodes of live streams to a specified edge server in the CDN network of a specific backup platform.

[0054] By parsing the platform identifier and network topology data in the real-time service parameters of a specific backup platform, the identification information and access parameters of the target edge server are generated, thereby forming the edge node scheduling instructions. The specific selection criteria for the target edge server (such as based on geographical location, node load, network latency with the broadcaster, etc.) can be set by those skilled in the art according to the actual network architecture and scheduling strategy, and will not be elaborated here.

[0055] Dynamic routing configuration parameters refer to the network configuration information required to plan the optimal transmission path for live stream data packets from the streaming source to the target edge node based on real-time network conditions.

[0056] By invoking the path calculation engine and combining real-time network probing data (such as link latency, packet loss rate, and bandwidth utilization) with the global network topology, the optimal or alternative transmission path from the streaming endpoint to the target edge node is calculated, and corresponding routing policies, next-hop addresses, or tunnel encapsulation parameters are generated to form dynamic routing configuration parameters. The specific algorithms of the path calculation engine (such as those based on shortest path, minimum cost, or congestion avoidance) and parameter generation rules can be determined by those skilled in the art based on network technology selection, and will not be elaborated here.

[0057] S16: Control the live streaming engine to switch the video stream from the pre-connection channel of the abnormal live streaming platform to the pre-connection channel of the specific backup platform, and simultaneously trigger the migration and synchronization of related business data.

[0058] A live streaming engine is the core software responsible for performing audio and video acquisition, encoding, packaging, and network delivery according to streaming media protocols.

[0059] The migration and synchronization of related business data refers to the atomic migration of the complete business context state of the current live stream to the new platform while switching video streams. This state includes user session data, transaction context data, and marketing campaign progress data. The specific steps for migrating and synchronizing related business data will be explained in detail in subsequent sections S60 to S64, and will not be repeated here.

[0060] The control system switches the video stream from the pre-connection channel of the faulty live streaming platform to the pre-connection channel of the specific backup platform, and simultaneously triggers the migration and synchronization of related business data. This ensures the continuity of the live streaming room's business status while switching the live stream transmission path, preventing user interaction interruptions, shopping cart clearing, or marketing activity interruptions due to platform switching. The triggering mechanism and atomicity guarantee logic for switching control and data synchronization can be implemented by those skilled in the art based on the system architecture design, and will not be elaborated here.

[0061] The specific switching steps for the pre-connected channel will be explained in detail in subsequent S50 to S55, and will not be repeated here.

[0062] S17: In response to edge node scheduling instructions and dynamic routing configuration parameters, schedule the edge computing node corresponding to the specific backup platform to take over the distribution of the video stream, and distribute the live stream to the user terminal along the optimized transmission path, thereby completing low-latency distribution.

[0063] Achieving low-latency distribution means that by performing the above-mentioned node scheduling and routing optimization, the end-to-end playback latency increment of the live stream viewed by the end user is controlled within an extremely low range when a platform switching event occurs, and the video picture is smooth without any stuttering or jumps, achieving a smooth transition effect.

[0064] Upon receiving the edge node scheduling instruction and dynamic routing configuration parameters, the edge computing node corresponding to the specific backup platform needs to be scheduled to take over the distribution of the video stream and distribute the live stream to the user terminal along the optimized transmission path, thereby completing low-latency distribution.

[0065] The specific steps for selecting a backup platform include: S20: Respond to the anomaly type to determine the corresponding platform selection preference weight set.

[0066] The platform selection preference weight set refers to the set of parameters used to quantitatively evaluate the importance of each real-time service parameter. For example, for "network connection anomalies," the weight set may assign a higher weight to "estimated network quality"; for "platform rule anomalies," the weight set may assign a higher weight to "policy compatibility." The specific values ​​of the weight set are predetermined by those skilled in the art based on historical data and business strategies, and will not be elaborated here.

[0067] S21: Collect real-time service parameters of each candidate live streaming platform.

[0068] The real-time service parameters of each candidate live streaming platform refer to the data set that the system obtains through the monitoring interface at the moment of decision-making, which reflects the real-time service capabilities and status of each platform. This includes API response latency, server load rate, estimated end-to-end network quality (such as latency and packet loss rate), and the platform's policy compatibility status with the current live streaming content / activity.

[0069] The real-time service parameters of each candidate live streaming platform are obtained by synchronously calling the system status query interface, network quality detection service, and policy analysis engine of each platform at the decision-making time. Specifically: API response latency and server load rate are obtained by sending requests to public or internal status monitoring endpoints of each platform and measuring their response times and parsing the load information in the returned data.

[0070] End-to-end network quality is estimated by sending probe packets to the service address of the target platform or querying real-time network quality data provided by the CDN service provider cooperating with the platform, to obtain estimated indicators such as latency and packet loss rate under the current network conditions.

[0071] The policy compatibility status is determined by comparing and analyzing key information of the current live stream (such as title keywords and product categories) with compliance strategy models extracted in advance from the public rules or historical data of various platforms, and then deriving a compatibility score or status label.

[0072] The collection frequency, interface calling method, and data parsing rules of the above indicators can be designed by those skilled in the art based on the actual monitoring architecture and platform interface specifications, and will not be elaborated here.

[0073] S22: Based on the platform selection preference weight set, the real-time service parameters of each candidate platform are weighted and scored to obtain the scenario adaptability score of each platform.

[0074] The scenario suitability score is a comprehensive score obtained by standardizing the real-time service parameters of a candidate platform and then weighting and summing them with the corresponding weights from the platform selection preference weight set. This score quantifies the suitability of the platform as a backup platform under a specific abnormal scenario. The specific formula and standardization method for calculating the weighted score are well known to those skilled in the art and will not be elaborated here.

[0075] S23: Sort the candidate platforms according to their scenario adaptability scores, and select the platform with the highest score as the specific backup platform.

[0076] The scenario adaptability scores of all candidate platforms are sorted from high to low, and the platform with the highest score is selected as the specific backup platform for this switchover.

[0077] Reference Figure 2 It also includes the intelligent live stream title generation step: S30: Collect information on trending topics online, product type tags in the enterprise's product database, and target customer profile tags.

[0078] Trending topics on the internet refer to sets of keywords or event themes that have high attention and widespread dissemination, obtained in real time from the trending lists of social media, news websites, or various live streaming platforms using web crawling technology. The specific sources and collection frequency of trending topics can be set by those skilled in the art according to business needs, and will not be elaborated here.

[0079] Product type tags are standardized identifiers extracted from a company's product management system and used to categorize products featured in a live stream, such as "Beauty - Lipstick" or "Home Appliances - Washing Machine." These tags are generated based on the company's own product category system and will not be elaborated upon here.

[0080] Target customer profile tags refer to a set of tags extracted from an enterprise's customer relationship management system to describe the characteristics of the target audience, such as "age range 20-30 years old," "interest preference is outdoor sports," and "moderate spending power." Target customer profile tags are generated based on the analysis of historical transaction and user behavior data, which is common knowledge in the field and will not be elaborated upon here.

[0081] S31: Perform semantic analysis on trending online information to extract core trending words.

[0082] Core hot keywords refer to one or more keywords that represent the core semantics of trending online information, obtained through natural language processing. The specific algorithms and models used for semantic parsing can be selected and implemented by those skilled in the art, and will not be elaborated here.

[0083] S32: Determine product category keywords based on product type tags.

[0084] Product category keywords refer to specific product description words used to generate titles, which correspond to the product type tag. For example, when the product type tag is "beauty - lipstick", its product category keywords may include "lipstick", "lip gloss", "shade", etc.

[0085] Product category keywords are obtained by querying a pre-defined category keyword mapping table. This table records a set of commonly used or professional product description keywords corresponding to different product type tags. This mapping table is pre-entered and maintained by those skilled in the art based on industry-standard terminology, product characteristics, and merchant operational habits, and will not be elaborated upon here.

[0086] S33: Input the core hot keywords and product category keywords into the relevance calculation model to generate hot product relevance scores.

[0087] The hot-spot product relevance score is a numerical value calculated using a relevance calculation model to quantify the semantic relevance between core hot-spot keywords and product category keywords. The relevance calculation model is a pre-trained model (e.g., based on word vector similarity or text matching), and its specific architecture and training methods are well-known to those skilled in the art and will not be elaborated upon here. The specific range and threshold of the score can be set by those skilled in the art according to the application scenario, and will not be elaborated upon here either.

[0088] S34: Select matching title templates from a pre-set multi-dimensional title template library based on the relevance score of popular products and the target customer profile tags.

[0089] A title template refers to a predefined framework for live-streaming titles, containing a fixed sentence structure and several variable placeholders. The templates in the multi-dimensional title template library come with pre-configured applicable conditions, such as the required minimum relevance score range and suitable customer profile tags. During screening, the calculated relevance scores of popular products and target customer profile tags are matched with the applicable conditions of each template, selecting the title templates that meet the criteria. The construction of the template library and the setting of the applicable conditions are performed by those skilled in the art and will not be elaborated upon here.

[0090] S35: Call the title template and fill in the core hot words and product category keywords as variables to generate candidate live broadcast titles, and push the candidate live broadcast titles to the user terminal for the user to choose.

[0091] Candidate live stream titles refer to the live stream title options that are automatically generated by the system according to the above steps and can be finally selected by the broadcaster or operations personnel.

[0092] By filling the corresponding variable placeholders in the selected title template with core trending keywords and product category keywords, a complete title string is generated. Several candidate live stream titles are then presented to the user through a front-end component of a unified control interface, which receives the user's selection confirmation. The specific variable filling, rendering, and front-end interaction logic can be implemented by those skilled in the art and will not be elaborated upon here.

[0093] It also includes the steps for configuring marketing interaction strategies: S40: Collect the final live stream title.

[0094] The final live stream title refers to the title text that will be used in this live stream, generated through the intelligent live stream title generation process and selected and confirmed by the user from the candidate live stream titles.

[0095] The final live stream title is collected and determined by listening to the user's selection of candidate live stream titles on the unified control interface.

[0096] S41: Generate target marketing interaction components and initial parameters based on product category keywords.

[0097] Targeted marketing interactive components refer to interactive functional modules that are suitable for the product types and marketing objectives of this live stream.

[0098] Initial parameters refer to the basic operating parameters configured for the target marketing interaction components that take effect when the activity starts. For example, for the "Flash Sale" component, the flash sale price, flash sale inventory, and duration; for the "Coupon Issuance" component, the coupon amount, usage conditions, and total issuance amount, etc.

[0099] The target marketing interactive components and initial parameters are generated by querying a pre-defined category strategy comparison table. This table records the different target marketing interactive component types and initial parameter calculation rules corresponding to different product category keywords. The comparison content in the table is formed by those skilled in the art after summarizing and generalizing the different commonly used marketing strategies and parameter models corresponding to different product categories, and will not be elaborated here.

[0100] S42: Encapsulate the final live stream title, product category keywords, target marketing interaction components, and initial parameters to generate a live stream strategy package.

[0101] A live streaming strategy package is a structured data object that encapsulates the final live stream title, product category keywords, one or more target marketing interaction components, and their corresponding initial parameters. This package is used to synchronously distribute a unified live stream configuration to various live streaming platforms upon launch. The specific data format (such as JSON or XML) can be defined by those skilled in the art based on inter-system communication protocols, and will not be elaborated upon here.

[0102] S43: When responding to a multi-platform live streaming creation request, parse the live streaming strategy package and simultaneously distribute and pre-configure the title information, product information, and marketing interaction configuration contained therein to the respective live streaming backends of each target live streaming platform through the corresponding management interface.

[0103] Before responding to multi-platform live stream creation requests and initiating the actual streaming, the system parses the live stream strategy package, extracting title information, product information, and marketing interaction configurations (i.e., target marketing interaction components and initial parameters). Subsequently, by calling the live stream management interfaces provided by each target live stream platform (e.g., APIs for setting live stream titles, uploading product lists, and creating marketing campaigns), this configuration information is synchronously and batch-sent to the live stream backends of each platform, completing automated pre-configuration before the live stream begins. The specific calling methods and parameter formats of each platform's management interfaces follow the open API specifications of the respective platforms and are known to those skilled in the art, and will not be elaborated upon here.

[0104] It also includes the specific steps for controlling the live streaming engine to switch the video stream from the pre-connection channel of the abnormal live streaming platform to the pre-connection channel of a specific backup platform: S50: Collects trigger signals and system clock from the unified control interface.

[0105] A unified control interface refers to a unified interactive interface used by users to initiate multi-platform live streaming creation requests and perform various live streaming operations.

[0106] A trigger signal is a command signal initiated by the user through a preset switching control on the unified control interface, used to indicate the execution of a platform switching operation. Trigger signals are collected by monitoring user interaction events with the switching control and converting these events into control commands recognizable by the system.

[0107] The system clock refers to the system time source that provides the current standard time. The system clock is obtained by calling the time service interface provided by the operating system.

[0108] S51: Compare the trigger signal with the preset instruction template and compare the system clock with the preset timing plan.

[0109] Instruction templates refer to predefined signal formats used to verify and parse the validity of trigger signals. Scheduled plans refer to pre-defined calendar configurations that include planned switching times.

[0110] The instruction templates and timing schedules are set in advance by those skilled in the art and will not be elaborated here.

[0111] The trigger signal is compared with the instruction template, and the system clock is compared with the timing plan to verify the legality of the trigger signal (i.e. whether it conforms to the predetermined format) and to determine whether the current time has reached the preset planned switching time point.

[0112] S52: Determine the trend of feedback parameters based on the status feedback of the live stream.

[0113] Feedback parameter trends refer to the predictive judgment of the direction and rate of change of key performance indicators (such as video frame rate and network latency) obtained by performing time-series analysis on continuously collected live stream status feedback. Specific methods for trend analysis (such as moving average and linear regression) can be selected and implemented by those skilled in the art, and will not be elaborated here.

[0114] S53: Based on the comparison results, anomaly type, and feedback parameter trends, determine whether any preset switching trigger condition is met.

[0115] Any switching trigger condition refers to a pre-set set of logical criteria that can initiate the platform switching process. It includes at least: manual trigger conditions based on successful comparison of trigger signal and instruction template, timed trigger conditions based on the system clock reaching the time point in the timing plan, exception-driven trigger conditions based on exception type (such as platform rule exception or network connection exception), and predictive trigger conditions based on feedback parameter trend prediction that the flow quality will be severely degraded.

[0116] By combining the comparison results, the anomaly type, and the trend of the feedback parameters, it is determined whether any of the above switching trigger conditions are met.

[0117] S54: When any switching trigger condition is met, a corresponding switching instruction is generated.

[0118] A switching instruction is a control command used to instruct a live streaming engine to perform a video stream channel switching operation. It includes at least the identifier of the target switching platform (i.e., the specific backup platform) and the type of switching action.

[0119] The switching command is generated by querying a preset trigger command mapping table. This table records different command generation templates and the sources of necessary parameters corresponding to different trigger condition types (such as manual triggering, timed triggering, exception-driven triggering, and predictive triggering). The contents of this mapping table are summarized by those skilled in the art based on the different command generation requirements corresponding to different trigger conditions, and will not be elaborated here.

[0120] When any switching trigger condition is met, the corresponding switching instruction must be generated first for subsequent steps.

[0121] S55: In response to switching commands, controls the live streaming engine to perform video stream switching operations.

[0122] In response to the generated switching command, the control of the live streaming engine to interrupt the data transmission to the pre-connected channel of the abnormal live streaming platform, and immediately begin to send video stream data through the pre-connected channel of the specific backup platform, thereby completing the switching operation.

[0123] It also includes the synchronization and migration steps for related business data: S60: Responds to switching commands to collect a list of customer identifiers, real-time shopping cart data, and real-time order information.

[0124] The customer identifier list refers to the anonymized and unique set of identifiers for all customers active in a live stream room on an abnormal live streaming platform. This list is generated by anonymizing the real-time online user list in the live stream room (e.g., using hash mapping), ensuring that customer identities can be linked without exposing their real privacy information during cross-platform migration. Specific anonymization algorithms and identifier generation rules can be set by those skilled in the art and will not be elaborated upon here.

[0125] Real-time shopping cart data refers to the detailed list of items added but not yet checked out by each customer in the live stream up to the time of the switchover. This includes information such as the product's unique code, quantity, selected product specifications, and real-time unit price. This data is obtained by querying the live stream's real-time shopping cart status database.

[0126] Real-time order information refers to the details of each customer's orders submitted but not yet paid for or confirmed by the merchant within the live stream up to the switching time. This includes information such as order number, order status, product list, amount due, and order creation time. This data is obtained by querying the live stream's real-time order processing system.

[0127] S61: Determine the data interface specification based on the specific backup platform.

[0128] A data interface specification refers to the specific data formats, field definitions, transmission protocols, and authentication methods required by the application programming interfaces (APIs) of a particular backup platform for receiving and processing external business data (such as shopping carts and orders). This specification is obtained by querying a pre-defined platform interface specification table, which records different data interface specifications for different live streaming platforms. These specifications are compiled in advance by those skilled in the art based on the open API documentation of each platform and will not be elaborated upon here.

[0129] S62: Serialize and encapsulate the data interface specifications, real-time shopping cart data, and real-time order information to generate a platform-specific data synchronization package.

[0130] A platform-specific data synchronization package refers to a data block specifically designed for submission to a particular backup platform. This package is formed by structuring, encoding (e.g., converting to JSON, XML, or Protobuf format), and packaging real-time shopping cart data and real-time order information according to the data interface specifications. The specific serialization and encapsulation processes are implemented by those skilled in the art according to the data interface specifications and will not be elaborated here.

[0131] S63: While controlling the live streaming engine to perform video stream switching operations, call the data synchronization interface of the specific backup platform and submit the platform-specific data synchronization package and customer identification list.

[0132] During the same period when the live streaming engine begins pushing video streams to specific backup platforms, the system calls the data synchronization interface provided by the platform and submits the platform-specific data synchronization package and the associated customer identification list together to request the platform to receive and process the migrated business data.

[0133] S64: In the live streaming instance of the specific backup platform, parse and load the submitted data to restore the complete shopping and interaction session state of each customer before the switch.

[0134] On the specific backup platform side, the live streaming backend service receives and parses the platform-specific data synchronization package. Based on the customer identifier list in the package, it loads the corresponding real-time shopping cart data and real-time order information into the session context of each customer in the new live streaming room. This allows each customer to immediately see their original shopping cart content and order progress after switching platforms, achieving seamless continuity of business status.

[0135] This also includes switching audience guidance methods: S70: Collects access links to live streams on specific backup platforms.

[0136] A live stream access link is a Uniform Resource Locator (URL) that provides direct access to a newly created or specified live stream on a specific backup platform. This link is obtained by calling the open API of the specific backup platform.

[0137] S71: Generate platform switching guidance information based on the switching command and the live room access link.

[0138] Platform switching guidance information refers to the prompting content used to inform viewers that the live stream has switched platforms and guide them to the new live stream room to continue watching. The guidance information combines the switching reason (such as the type of error) carried in the switching instruction or a custom script template with the live stream room access link to generate a composite information body containing a jump link, explanatory text, and visual elements. Specific content generation rules can be set by those skilled in the art based on user experience design, and will not be elaborated here.

[0139] S72: Push the platform switching guidance information to the overlay of the live stream screen of the abnormal live streaming platform for display, and simultaneously push it to the live stream chat system.

[0140] The generated platform switching guidance information is rendered onto the live video screen as a semi-transparent overlay, banner, or badge through the live video overlay interface provided by the abnormal live streaming platform. Simultaneously, a simplified text version of this guidance information is sent to the live stream chat system as a system message or announcement via the chat room interface of the abnormal live streaming platform or by simulating a user account. The specific push and rendering techniques depend on the functional interfaces provided by each platform and are known to those skilled in the art, and will not be elaborated upon here.

[0141] S73: User departure rate after the collection and guidance information display.

[0142] User churn rate refers to the average rate (e.g., the number of users decreasing per second) of the real-time online user count on an abnormal live streaming platform within a preset statistical time window after the initial display of the introductory information. This rate is obtained by continuously monitoring the real-time online user count interface provided by the abnormal live streaming platform and calculating the difference in user count changes per unit time. The specific length of the statistical time window can be set by those skilled in the art and will not be elaborated here.

[0143] S74: When the user departure rate is lower than the preset expected threshold, generate an enhanced guidance instruction based on the platform switching guidance information and push it a second time.

[0144] The expected threshold refers to a pre-set critical value for the user churn rate used to determine whether the current guidance effect has met the target. This threshold is set by those skilled in the art based on historical data or business objectives (such as the expectation of completing the migration of most viewers within a specific time), and will not be elaborated here.

[0145] Enhanced guidance commands are control instructions generated by the system to strengthen guidance strategies when the user exit rate falls below a desired threshold. These commands enhance guidance information based on platform switching, according to preset enhancement rules (such as enlarging visual elements, adjusting text emphasis, adding flashing effects, or shortening push intervals). This generates optimized guidance content and push strategies, triggering a secondary push. The specific content of the enhancement rules is predetermined by those skilled in the art based on the guidance effect optimization goals and will not be elaborated upon here.

[0146] When the user departure rate is lower than the expected threshold, an enhanced guidance instruction needs to be generated and a second push needs to be made.

[0147] It also includes methods for maintaining channel health: S80: Periodically sends probe data packets to each pre-connected channel and collects probe response latency and probe packet loss rate.

[0148] Probe packets are network data packets with a specific format and a small size (tens to hundreds of bytes) constructed to actively test the connectivity and basic transmission performance of a pre-connected channel. The specific construction method and protocol type of the probe packet (such as ICMP, TCP empty payload packet, or custom protocol packet) can be set by those skilled in the art according to the network environment, and will not be elaborated here.

[0149] Probe response latency refers to the time interval from when the system sends a probe data packet to the remote server of the pre-connected channel until the system receives the corresponding response data packet from that server, usually measured in milliseconds. The specific timing methods and timestamp processing logic are common knowledge in this field and will not be elaborated here.

[0150] The probe packet loss rate refers to the proportion of packets that do not receive any response out of the total number of packets sent in a batch of consecutive probe packets (e.g., N packets sent within a probe cycle). It is usually expressed as a percentage and is used to assess the data transmission reliability of the channel within the current time period. The statistical period and judgment criteria for the packet loss rate are predetermined by those skilled in the art and will not be elaborated here.

[0151] S81: Calculate the real-time health score of each channel based on the detection response latency and detection packet loss rate, and collect the historical health baseline value of each channel.

[0152] The real-time health score is a comprehensive score used to quantitatively characterize the overall health status of the pre-connected channel at the current moment.

[0153] The real-time health score is calculated by inputting the probe response latency and probe packet loss rate into a preset health scoring model. This model defines the mapping relationship between latency and packet loss rate to the health score, for example, through a piecewise function or a weighted formula. The specific scoring algorithm is set by those skilled in the art based on network quality tolerance standards, and will not be elaborated here.

[0154] Historical health baseline values ​​refer to the statistical characteristics (such as rolling average, moving median, or 95th percentile) of the health score of each pre-connected channel during a historical period considered "normal" or "healthy" of operation. This baseline value represents the typical health level of the channel under normal conditions and serves as a reference for subsequently determining whether the current state has deteriorated. The length of the historical time window and the statistical algorithm used for calculating the baseline value are predetermined by those skilled in the art and will not be elaborated upon here.

[0155] S82: Compare the real-time health score of each channel with its historical health baseline value to determine whether the health status has deteriorated.

[0156] The real-time health score of each channel is compared with its corresponding historical health baseline value. If the real-time score of a channel remains below its baseline value, and the difference exceeds a preset degradation judgment threshold and reaches a preset duration, the health status of that channel is determined to have deteriorated. The specific comparison rules, degradation judgment threshold, and duration are preset by those skilled in the art and will not be elaborated here.

[0157] S83: When the health status of any channel is determined to be deteriorated, the channel is deemed to be faulty and a reconstruction process is initiated based on its platform identifier.

[0158] When the health status of any pre-connected channel deteriorates, the system determines that the channel is unreliable or has failed and is no longer suitable for ensuring subsequent rapid switching requirements. The system then generates a channel reconstruction task instruction based on the platform identifier bound to the failed channel and triggers the channel reconstruction process.

[0159] The channel reconstruction process is as follows: First, in response to the channel reconstruction task instruction, the network connection with the failed channel is interrupted and related resources are released. Next, based on the platform identifier, the corresponding live streaming platform's open interface is invoked again to initiate a connection request, establishing a new pre-connected channel in an inactive state. Then, the network identifier and configuration information of the newly established pre-connected channel are registered to the system's available channel resource pool, replacing the original failed channel's record. Finally, a channel update notification is sent to the multi-rule fusion judgment model, enabling it to include the newly established channel in its subsequent monitoring scope. The specific implementation methods of each step in the reconstruction process depend on the system architecture and platform interfaces, which are understood by those skilled in the art and will not be elaborated upon here.

[0160] This also includes steps prior to collecting multi-platform live stream creation requests: S90: Collects user selection commands for historical live streaming templates on the unified control interface.

[0161] Selection commands refer to interactive commands triggered by users through template selection components provided on the unified control interface (such as drop-down menus or clicking on template lists), used to specify a historical live stream configuration that the user wishes to reuse. These commands are collected by the front-end interface listening for user interaction events and converting them into template identifiers recognizable by the back-end. The specific event listening and identifier generation logic can be implemented by those skilled in the art using front-end technology, and will not be elaborated upon here.

[0162] S91: In response to the selection command, retrieve the corresponding target historical live streaming template from the pre-stored template library.

[0163] The target historical live stream template refers to a structured data packet pre-stored in the system template library. This data packet encapsulates a snapshot of the key configurations of a successful historical live stream, including at least the streaming parameter configuration, screen layout parameters, and associated product list. The structure of the template library and the storage format of the template data are designed in advance by those skilled in the art and will not be elaborated here. The system retrieves and fully reads the corresponding data packet from the template library based on the template identifier carried in the selection instruction, thereby obtaining the target historical live stream template.

[0164] S92: Based on the target historical live streaming template, derive the streaming parameter configuration and screen layout parameters encapsulated therein.

[0165] Streaming parameter configuration refers to the set of key technical parameters recorded in the target historical live streaming template that are used to control the encoding and pushing of the live stream, including video encoding format, bitrate, resolution, frame rate, audio sampling rate, keyframe interval, and streaming protocol type.

[0166] The screen layout parameters refer to the set of parameters recorded in the target historical live streaming template, which are used to define the position, size, hierarchy, and style attributes of various visual elements (such as the anchor's camera view, product display window, text tiles, and background images) in the live video screen.

[0167] The streaming parameter configuration and screen layout parameters are obtained by parsing the target historical live stream template data packet and extracting the corresponding configuration fields stored within it. The specific structure and parsing method of the data packet are determined by those skilled in the art based on the storage design, and will not be elaborated here.

[0168] S93: Automatically populate the streaming parameter configuration and screen layout parameters into the newly created live streaming creation session, and generate a multi-platform live streaming creation request based on the populated live streaming creation session.

[0169] The parsed streaming parameter configuration and screen layout parameters are automatically assigned to the corresponding configuration items according to the data structure requirements of a newly created live stream session. Subsequently, based on this live stream session with fully initialized parameters, the system automatically assembles and generates structured instruction data conforming to the multi-platform live stream creation request format. This instruction data serves as the input for the subsequent S10 step. The logic for automatic parameter filling and session generation is implemented by those skilled in the art and will not be elaborated upon here.

[0170] Based on the same inventive concept, embodiments of the present invention provide a system for rapid live streaming creation and low-latency distribution across multiple terminals, comprising: The data acquisition module is used to collect data on multi-platform live streaming creation requests, platform identifiers, link quality signals, live stream status feedback, content review status codes, real-time service parameters, network hotspot information, product type tags, target customer profile tags, final live stream title, trigger signals, system clock, customer identifier list, real-time shopping cart data, real-time order information, live stream access links, user departure rate, historical health baseline value, detection response latency, detection packet loss rate, and selection instructions. The memory is used to store the program that implements a method for fast live streaming creation and low-latency distribution for multiple terminals; The processor is used to load and execute programs stored in memory.

[0171] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0172] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A method for rapid live streaming creation and low-latency distribution across multiple terminals, characterized in that, include: Collect live streaming creation requests from multiple platforms and the platform identifiers of multiple target live streaming platforms bound to the user; In response to multi-platform live streaming creation requests and platform identifiers, the system synchronously calls the open interfaces of multiple preset target live streaming platforms, initiates live streaming push requests, and establishes and maintains a pre-connected channel in an inactive state for each platform. Collect link quality signals from each pre-connected channel, live stream status feedback from each platform, and content review status codes; Based on link quality signals, live stream status feedback, and content review status codes, a multi-rule fusion judgment model is used to determine whether there are abnormal live streaming platforms and their abnormal types. When an abnormal live streaming platform is identified, the abnormality type is retrieved, and a specific backup platform is dynamically selected from the target live streaming platform based on the abnormality type, the preset platform switching rules, and the real-time service parameters of each platform. Based on the specific backup platform and its real-time service parameters, generate edge node scheduling instructions and dynamic routing configuration parameters; Control the live streaming engine to switch the video stream from the pre-connection channel of the abnormal live streaming platform to the pre-connection channel of the specific backup platform, and simultaneously trigger the migration and synchronization of related business data; In response to edge node scheduling instructions and dynamic routing configuration parameters, the edge computing node corresponding to the specific backup platform is scheduled to take over the distribution of the video stream and distribute the live stream to the user terminal along the optimized transmission path, thereby completing low-latency distribution.

2. The method for rapid live streaming creation and low-latency distribution for multiple terminals according to claim 1, characterized in that, The specific steps for selecting a backup platform include: The corresponding platform selection preference weight set is determined based on the anomaly type. Collect real-time service parameters from each candidate live streaming platform; Based on the platform selection preference weight set, the real-time service parameters of each candidate platform are weighted and scored to obtain the scenario adaptability score of each platform. The candidate platforms are sorted according to their scenario adaptability scores, and the platform with the highest score is selected as the specific backup platform.

3. The method for rapid live streaming creation and low-latency distribution for multiple terminals according to claim 1, characterized in that, It also includes the intelligent live stream title generation step: Collect information on trending topics online, product type tags from enterprise product databases, and target customer profile tags; Semantic analysis of trending online information is performed to extract core trending words; Determine product category keywords based on product type tags; Input the core hot keywords and product category keywords into the relevance calculation model to generate hot product relevance scores; Based on the relevance score of popular products and the target customer profile tags, the system selects matching title templates from a pre-set multi-dimensional title template library; The system calls a title template and fills in core trending words and product category keywords as variables to generate candidate live stream titles, which are then pushed to the user's terminal for selection.

4. The method for rapid live streaming creation and low-latency distribution for multiple terminals according to claim 3, characterized in that, It also includes the steps for configuring marketing interaction strategies: Collect the final live stream title; Generate targeted marketing interaction components and initial parameters based on product category keywords; The final live stream title, product category keywords, target marketing interaction components, and initial parameters are packaged together to generate a live stream strategy package; When responding to a multi-platform live streaming creation request, the live streaming strategy package is parsed, and the title information, product information, and marketing interaction configuration contained therein are synchronously distributed and pre-configured to the respective live streaming room backends of each target live streaming platform through the corresponding management interface.

5. The method for rapid live streaming creation and low-latency distribution for multiple terminals according to claim 1, characterized in that, It also includes the specific steps for controlling the live streaming engine to switch the video stream from the pre-connection channel of the abnormal live streaming platform to the pre-connection channel of a specific backup platform: Collect trigger signals and system clock from the unified control interface; The trigger signal is compared with the preset instruction template, and the system clock is compared with the preset timing plan. Determine the trend of feedback parameters based on live stream status feedback; Based on the comparison results, anomaly types, and feedback parameter trends, determine whether any preset switching trigger condition is met; When any switching trigger condition is met, a corresponding switching instruction is generated; In response to switching commands, control the live streaming engine to perform video stream switching operations.

6. The method for rapid live streaming creation and low-latency distribution for multiple terminals according to claim 5, characterized in that, It also includes the synchronization and migration steps for related business data: Responding to switching commands to collect customer identifier lists, real-time shopping cart data, and real-time order information; The data interface specifications will be determined based on the specific backup platform. The data interface specifications, real-time shopping cart data, and real-time order information are serialized and encapsulated to generate a platform-specific data synchronization package. While controlling the live streaming engine to perform video stream switching operations, call the data synchronization interface of the specific backup platform and submit the platform-specific data synchronization package and customer identification list. In the live streaming instance of the specific backup platform, the submitted data is parsed and loaded to restore the complete shopping and interaction session state of each customer before the switch.

7. The method for rapid live streaming creation and low-latency distribution for multiple terminals according to claim 5, characterized in that, This also includes switching audience guidance methods: Collect the live stream access links for specific backup platforms; Based on the switching command and the live stream access link, generate platform switching guidance information; The platform switching guidance information will be pushed to the overlay of the live stream screen of the abnormal live streaming platform for display, and simultaneously pushed to the live stream chat system; The user departure rate after the collection and guidance information is displayed; When the user departure rate is lower than the preset expected threshold, the platform switches the guidance information to generate enhanced guidance instructions and push them a second time.

8. The method for rapid live streaming creation and low-latency distribution for multiple terminals according to claim 1, characterized in that, It also includes methods for maintaining channel health: Periodically send probe data packets to each pre-connected channel and collect probe response latency and probe packet loss rate; The real-time health score of each channel is calculated based on the detection response latency and the detection packet loss rate, and the historical health baseline value of each channel is collected. The real-time health score of each channel is compared with its historical health baseline value to determine whether the health status has deteriorated. When the health status of any channel is determined to have deteriorated, the channel is deemed to have failed and a reconstruction process is initiated based on its platform identifier.

9. The method for rapid live streaming creation and low-latency distribution for multiple terminals according to claim 1, characterized in that, This also includes steps prior to collecting multi-platform live stream creation requests: Collect user selection commands for historical live streaming templates from the unified control interface; In response to the selection command, the corresponding target historical live streaming template is retrieved from the pre-stored template library; Based on the target historical live streaming template, the streaming parameter configuration and screen layout parameters encapsulated therein are derived; The streaming parameter configuration and screen layout parameters are automatically populated into the newly created live streaming session, and a multi-platform live streaming creation request is generated based on the populated live streaming session.

10. A system for rapid live streaming creation and low-latency distribution across multiple terminals, characterized in that: include: The data acquisition module is used to collect live streaming creation requests, platform identifiers, link quality signals, live stream status feedback, and content review status codes from multiple platforms. A memory for storing a program that implements a method for rapid live streaming creation and low-latency distribution for multiple terminals as described in any one of claims 1 to 9; The processor is used to load and execute programs stored in memory.

Images