Emergency broadcast decision-making method for dynamically reconstructing broadcast list

Abstract

The invention discloses an emergency broadcast decision-making method for dynamically reconstructing a broadcast list, which is characterized by comprising the following steps of: 1, monitoring running state parameters of a broadcast link in real time, the running state parameters comprising a signal quality parameter, a network link parameter, a server resource parameter and an audio stream content parameter; 2, when it is monitored that the operation state parameters are abnormal, fault diagnosis is carried out based on a preset knowledge base, and the knowledge base stores the mapping relation between fault features and disposal plans; step 3, generating a broadcast list reconstruction strategy according to the diagnosis result and a multi-dimensional characteristic factor of the current broadcast program, wherein the multi-dimensional characteristic factor at least comprises a program type, an importance level and a switching smoothness requirement; and step 4, executing automatic switching of the emergency audio streams according to the playlist reconstruction strategy. According to the invention, the problems of untimely emergency response, inaccurate decision, discontinuous fault handling and the like in a complex broadcast environment can be solved, the broadcast content can be quickly and dynamically reconstructed, and the broadcast continuity and the service quality are ensured.

Description

Technical Field

[0001] The present invention relates to the technical field of radio and television broadcasting, and in particular to an emergency broadcast decision-making method for dynamically reconstructing a playlist. Background Art

[0002] As broadcast and television systems evolve toward cloud-network converged architectures and process automation, the shortcomings of existing emergency response mechanisms in terms of response efficiency and decision-making accuracy are becoming increasingly apparent. Driven by a new round of digital transformation, the broadcast and television industry is undergoing fundamental changes at both the system architecture and operational levels. Traditional physical hardware-based broadcast systems are gradually being replaced by elastic architectures based on cloud computing and network collaboration. This shift not only improves system flexibility and scalability, but also significantly increases the complexity and uncertainty of system operations.

[0003] Specifically, under the cloud-network integrated architecture, system components are highly distributed, spanning multiple cloud nodes and heterogeneous network environments. Any failure in any area can trigger system-wide anomalies, impacting the continuity and service quality of the broadcast link. While process automation improves resource utilization efficiency and operational capabilities, it also leads to increased failure frequency and diverse anomaly patterns. This poses bottlenecks for traditional emergency response mechanisms that rely on fixed rules and manual intervention, such as slow response times, poor judgment accuracy, and weak fault tolerance.

[0004] Existing emergency response mechanisms, primarily based on pre-set processes and empirically informed manual judgment, struggle to rapidly identify and implement closed-loop responses to complex system anomalies. Furthermore, they struggle to ensure high system availability and reliability under the demands of 24 / 7 uninterrupted broadcasting and high-definition, high-quality content delivery. Furthermore, traditional mechanisms generally lack the ability to model and respond to multi-fault coupled scenarios, failing to meet the urgent need for intelligent, adaptive emergency response solutions in modern broadcast systems. Summary of the Invention

[0005] The purpose of this invention is to provide an emergency broadcast decision-making method for dynamically reconstructing playlists. This method can solve problems such as delayed emergency response, inaccurate decision-making, and discontinuous fault handling in complex broadcast environments, enabling rapid dynamic reconstruction of broadcast content to ensure broadcast continuity and service quality.

[0006] The technical solution of the present invention is an emergency broadcast decision-making method for dynamically reconstructing a playlist, comprising the following steps: Step 1: Real-time monitoring of operating status parameters of the broadcast link, wherein the operating status parameters include signal quality parameters, network link parameters, server resource parameters, and audio stream content parameters; Step 2: When an abnormal operating state parameter is detected, fault diagnosis is performed based on a preset knowledge base, which stores a mapping relationship between fault characteristics and handling plans; Step 3: Generate a playlist reconstruction strategy based on the diagnosis results and multi-dimensional characteristic factors of the currently broadcast program, wherein the multi-dimensional characteristic factors include at least program type, importance level, and switching smoothness requirement; Step 4: Automatically switch the emergency audio stream according to the playlist reconstruction strategy.

[0007] In the above-mentioned emergency broadcast decision-making method for dynamically reconstructing a playlist, the step of performing fault diagnosis based on a preset knowledge base includes: Extract abnormal sound patterns from audio streams as fault features through voiceprint analysis; Matching the fault characteristics with characteristic nodes in a knowledge base to determine the fault type; An emergency response plan including switching instructions and backup flow information is generated based on the matching results.

[0008] The aforementioned emergency broadcast decision-making method for dynamically reconstructing a playlist further includes: Identify early signs of cascading failures by analyzing the combined patterns of operating status parameters; When early signs are identified, emergency resource pre-scheduling is triggered, including starting the hot standby state of the backup server and pre-loading the emergency audio material.

[0009] In the aforementioned emergency broadcast decision-making method for dynamically reconstructing a playlist, the step of generating a playlist reconstruction strategy includes: Real-time analysis of program types, importance levels, and switching smoothness requirements; The switching timing and replacement materials are selected based on the results of characteristic factor analysis. News programs switch at sentence pauses, and music programs switch between tracks.

[0010] In the aforementioned emergency broadcast decision-making method for dynamically reconstructing a playlist, the steps of selecting a switching time and replacing materials specifically include: When the importance level is national news, use content-neutral transition materials to achieve seamless switching within 50ms; When the importance level is regular content, differentiated emergency materials are allowed to be switched within 200ms.

[0011] In the aforementioned emergency broadcast decision method for dynamically reconstructing a playlist, the step of automatically switching the emergency audio stream includes: The injection delay of emergency audio materials is controlled within the 50 millisecond threshold through millisecond synchronization control; After the switch is completed, the original mainstream ID is automatically replaced and the TS / PTS continuity is maintained.

[0012] In the aforementioned emergency broadcast decision-making method for dynamically reconstructing a playlist, the knowledge base is implemented using a lightweight database, and the stored fault features include: Single abnormal parameter characteristics, including independent indicators such as bandwidth below the threshold and CPU usage exceeding the limit; Composite fault signature, including the associated combined features of voiceprint anomalies and server resource anomalies.

[0013] In the aforementioned emergency broadcast decision-making method for dynamically reconstructing a playlist, the step of real-time monitoring of operating status parameters includes: Continuously collect SCTE-35 breakpoints, audio and video frame loss indicators, and black field duration data; When the packet loss rate exceeds 0.5% or the black field lasts for more than 2 seconds, a fault alarm is immediately triggered.

[0014] In the aforementioned emergency broadcast decision-making method for dynamically reconstructing a playlist, the step of generating a playlist reconstruction strategy further includes: Retrieve candidate materials from the emergency broadcast library through AI algorithm models; Perform sound and picture synchronization, loudness equalization processing on the material and check the timing with the arrangement table; Generate an execution plan containing switching instructions and backup flow URLs, with a single error of no more than ±1 second.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. The present invention uses a closed-loop control logic of real-time detection, intelligent diagnosis, automatic replacement, and playlist reconstruction, combined with algorithm model recommendation and emergency resource preloading mechanism, to control the entire process from monitoring to abnormality to completion of seamless switching within 1.2 seconds. The injection delay of the emergency audio stream is controlled within 50 milliseconds, achieving a response in seconds, solving the problem of untimely emergency response of traditional mechanisms.

[0016] 2. This invention incorporates a pre-defined knowledge base that stores the mapping between fault characteristics and response plans. This not only identifies single anomaly parameters, but also matches complex fault signatures formed by combinations of multiple parameters. Combined with audio anomaly patterns extracted through real-time voiceprint analysis, this technology can accurately pinpoint the fault type, cause, and impact. Furthermore, the decision-making module generates playlist reconstruction strategies based on multi-dimensional characteristic factors such as program type and importance level, avoiding the subjectivity of traditional empirical manual judgment and significantly improving decision-making accuracy.

[0017] 3. This invention uses intelligent switching technology to smoothly switch emergency audio streams, maintaining TS / PTS continuity during the switch, making the switching process virtually imperceptible to the listener. This effectively avoids the pauses, freezes, and crackling that can occur with traditional switching. Furthermore, this invention utilizes dynamic playlist reconstruction to adjust content without interrupting broadcasts. Combined with proactive prevention mechanisms (preemptively identifying potential risks and pre-scheduling resources), this ensures the continuity and stability of broadcast services. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 It is a schematic flow diagram of the present invention.

[0019] Figure 2 This is a schematic diagram of the principle of emergency content switching. DETAILED DESCRIPTION

[0020] The present invention will be further described below with reference to the accompanying drawings and examples, but they are not intended to limit the present invention.

[0021] Example: An emergency broadcast decision method for dynamically reconstructing a playlist, such as Figure 1 As shown, the following steps are included: Step 1: Real-time monitoring of operating status parameters of the broadcast link, wherein the operating status parameters include signal quality parameters, network link parameters, server resource parameters, and audio stream content parameters; In this step, the monitoring module monitors operational status parameters. Its core responsibility is to serve as the system's "perception layer," providing 24 / 7 real-time monitoring of the health of the entire broadcast link. This includes continuously collecting SCTE-35 breakpoints, audio and video frame loss indicators, and blackout duration data. A fault alarm is triggered when the packet loss rate exceeds 0.5% or a blackout lasts for more than two seconds. This module can collect and analyze various operational status parameters, including but not limited to signal quality (such as signal-to-noise ratio and bit error rate), network link parameters (such as bandwidth, latency, and packet loss rate), server resource parameters (such as CPU utilization, memory usage, and disk I / O), and audio stream content parameters.

[0022] Step 2: When an abnormal operating state parameter is detected, fault diagnosis is performed based on a preset knowledge base, which stores a mapping relationship between fault characteristics and handling plans; This step is performed by the diagnostic module, which is connected to the monitoring module. When the monitoring module reports an abnormal operating status parameter, the diagnostic module is activated. Its core function is to quickly and accurately locate and diagnose faults based on a pre-set knowledge base. The knowledge base is a structured data repository that can be implemented using a lightweight database (such as SQLite) or other data structures (such as key-value stores or document databases). The knowledge base stores a large number of "fault signature-response plan" mappings. A "fault signature" can be a single abnormal parameter (such as "bandwidth below a threshold") or a complex fault signature formed by combining multiple parameters (such as the simultaneous occurrence of "continuous noise detected by voiceprint analysis" and "CPU utilization of a server exceeding 95%"). The "response plan" defines the recommended action for the fault, such as "switch to backup server B" or "enable backup network link C." After receiving the abnormal data, the diagnostic module performs pattern matching within the knowledge base to quickly identify the specific fault type, possible cause, and impact range, and then outputs the diagnostic results to the decision module.

[0023] Step 3: Generate a playlist reconstruction strategy based on the diagnosis results and the multi-dimensional characteristic factors of the currently broadcast program, where the multi-dimensional characteristic factors include at least program type, importance level, and switching smoothness requirements. This step is operated by a decision module. The decision module, as the "decision-making brain" of the system, is the key to achieving refined switching in the present invention. Its decision logic is not based on fixed rules, but introduces real-time comprehensive analysis of the multi-dimensional characteristic factors of the currently broadcast program.

[0024] refer to Figure 2 , which shows a schematic diagram of the decision module's working logic. As shown in the figure, the decision module comprehensively considers the following characteristic factors when generating a playlist reconstruction strategy: 1. Program type: Such as virtual anchor reports, real-time traffic conditions, breaking news, music programs, etc. Different types of programs have different requirements for switching continuity and content relevance.

[0025] Importance level: Distinguishes important national news from regular content. The importance level determines the level of resources the system needs to schedule and the degree of conservatism of the switching strategy.

[0026] Switching smoothness requirements: For example, news broadcasts require extremely high switching consistency, while music program switching is relatively flexible.

[0027] Estimated remaining duration: Comprehensively determine how long the current program will take to be broadcast in order to select emergency materials of appropriate length.

[0028] The following table shows an example of multi-dimensional feature factors for a playlist reconstruction decision:

[0029] Through real-time comprehensive analysis of these complex factors, the decision-making module can generate the optimal switching strategy. For example, when it determines that the current broadcast is important news and the switching smoothness requirement is extremely high, the system will choose to execute the switch at the pause point between two sentences in the news broadcast and select a piece of neutral emergency music as a transition, thereby achieving "content-aware" intelligent and refined switching, and maximizing the logical integrity of the broadcast content and the listening experience. Ultimately, the decision-making module generates a playlist reconstruction strategy that includes specific emergency materials, switching timing, and target resources, and sends it to the execution module. For example, news programs switch at sentence pauses, and music programs switch between tracks.

[0030] The steps of selecting the switching timing and replacing the material specifically include: When the importance level is national news, use content-neutral transition materials to achieve seamless switching within 50ms; When the importance level is regular content, differentiated emergency materials are allowed to be switched within 200ms.

[0031] Step 4: Automatically switch the emergency audio stream according to the playlist reconstruction strategy.

[0032] This step is performed by the execution module, which is responsible for precisely implementing the playlist reconstruction strategy generated by the decision module. This module controls the underlying audio stream processing unit and network switching equipment to automatically switch the emergency audio stream. To achieve a high standard of seamless switching, the execution module uses audio stream injection technology to strictly control the delay of emergency material injection to within a threshold of 50 milliseconds. This technical indicator fundamentally eliminates the audio interruptions, freezes, or silences common in traditional switching solutions.

[0033] In a preferred embodiment, the monitoring module integrates real-time voiceprint analysis technology, enabling it to continuously monitor specific content features in the audio stream, such as abnormal sound patterns like silence, pops, noise, and distortion, and quantify these features into fault signature data. Voiceprint analysis extracts abnormal sound patterns from the audio stream as fault signatures; these fault signatures are matched with feature nodes in a knowledge base to determine the fault type; and based on the matching results, an emergency response plan is generated, including switching instructions and backup stream information.

[0034] In a preferred embodiment, the present invention also has an early warning module, which has a fault chain early warning model. Unlike the diagnostic module that directly responds to the fault that has occurred, the early warning module is designed to eliminate the risk in the bud. It continuously analyzes the various system indicators collected by the monitoring module to identify those that have not yet reached the single fault threshold, but whose combination pattern indicates that a chain reaction or major failure may be triggered in a very short time in the future (for example, within 30 seconds). When the early signs are identified, emergency resource pre-scheduling is triggered, including starting the hot standby state of the backup server and preloading of emergency audio materials. For example, the I / O delay of a server continues to rise slightly, and the network packet loss rate fluctuates slightly, which may indicate that the storage system is about to crash. Once the early warning is triggered, the early warning module does not wait passively, but immediately sends a warning instruction to the execution module to start the preparation procedure for automatic switching of the intelligent audio stream. This includes automatically optimizing and scheduling the backup server resource pool, ensuring that the highest-performing backup server enters a "hot standby" state, preloading relevant emergency audio materials, and controlling the injection delay of emergency audio materials within a 50-millisecond threshold through millisecond-level synchronization control. After the switch is complete, the original mainstream ID is automatically replaced while maintaining TS / PTS continuity. This proactive resource preparation shifts the timeline of emergency response from "afterward" to "beforeward," laying the foundation for a truly seamless switchover.

[0035] In a preferred embodiment, the step of generating a playlist reconstruction strategy also includes: retrieving candidate materials from the emergency broadcast library through an AI algorithm model; performing audio and video synchronization and loudness equalization processing on the materials and performing time verification with the schedule; generating an execution plan containing switching instructions and backup stream URLs, with a single error not exceeding ±1 second.

[0036] Furthermore, the present invention uses a provincial radio station's live broadcast of a comprehensive program that includes "national news broadcast," "regular music program," and "local weather warning" as an example, and employs the present invention's dynamic playlist reconstruction emergency broadcast decision-making method to ensure broadcast security. The present invention's method monitors link status in real time and automatically completes playlist reconstruction and audio stream switching in the event of a sudden failure. The implementation steps are detailed as follows: Step 1: Real-time monitoring of the broadcast link operation status; The following operating status parameters are collected through the monitoring module 24 hours a day, 7 days a week: Signal quality parameters: SCTE-35 breakpoints (used to mark program switching points), number of audio and video frame drops, and black frame duration; Network link parameters: real-time bandwidth (currently stable at 10 Mbps), packet loss rate (initial 0.1%), network latency (20 ms); Server resource parameters: main server CPU usage (30%), memory usage (45%); Audio stream content parameters: Monitor audio clarity (no noise or pops) through voiceprint analysis.

[0037] Monitoring trigger conditions: When the packet loss rate exceeds 0.5% or the black field lasts for more than 2 seconds, a fault alarm is immediately triggered.

[0038] Step 2: Fault diagnosis and early warning (taking "master server abnormality and network fluctuation" as an example); Anomaly trigger: During the live broadcast of the "National News Broadcast" segment, the monitoring module detected: the network packet loss rate suddenly increased to 1.2% (exceeding the 0.5% threshold); the main server CPU utilization rate soared from 30% to 90% within 10 seconds (exceeding the limit); and a continuous "electrical noise" appeared in the audio stream (identified as an abnormal sound pattern by voiceprint analysis).

[0039] Fault diagnosis: The diagnosis module calls the preset knowledge base (which stores the mapping between fault characteristics and response plans) and extracts "current noise, excessive CPU usage, and high packet loss rate" as composite fault characteristics. Matching with the characteristic node "Server overload causing audio distortion and network link congestion" in the knowledge base, the fault type is determined to be "chain failure caused by insufficient computing power of the main server."

[0040] Early warning and pre-scheduling: The system identifies early signs of cascading failures, such as a continuous increase in CPU usage and fluctuations in packet loss rates, and triggers pre-scheduling of emergency resources. The backup server immediately enters "hot standby status" (activates computing power in advance); preloads "neutral transition audio (such as a 3-second silent pad)" and "national news backup materials."

[0041] Step 3: Generate playlist reconstruction strategy (based on multi-dimensional feature factors); The decision-making module combines the fault diagnosis results with the current program characteristics (national news), analyzes multi-dimensional factors and generates strategies: Multidimensional characteristic factors Current program parameters Strategy Output Program Type National News (Live) Prioritize content continuity to avoid information interruption Importance level Highest level (national level) Adopt seamless switching, switching delay ≤ 50ms Switching smoothness requirements Very high (not noticeable to the audience) Choose pause points in sentences and use neutral transition materials Specific strategy: At the pause point at the end of the current news sentence (identified through audio rhythm analysis), the main audio stream is switched to the pre-loaded news material on the backup server, and a 3-second neutral transition audio (no noise, balanced volume) is inserted during the switch.

[0042] Step 4: Automatically switch the emergency audio stream. The execution module performs the following operations according to the playlist reconstruction strategy: Millisecond-level synchronization control: When a pause in a news sentence is identified, the backup audio stream is injected into the broadcast link with a delay of less than 50ms (the actual execution delay is 38ms, which is below the threshold).

[0043] Link continuity guarantee: After the switch is completed, the original mainstream ID is automatically replaced and the TS (transport stream) / PTS (presentation timestamp) synchronization is maintained to avoid audience perception of lag or frame skipping.

[0044] Switching result verification, the system automatically detects the audio stream after switching: Signal quality: no noise, black field duration 0 seconds; Network parameters: Packet loss rate restored to 0.1%, bandwidth stable; Server status: The CPU usage of the standby server is 35% (normal range).

[0045] Implementation effect: The response speed from detecting anomalies to completing the switching was 0.8 seconds (lower than the target of 1.2 seconds), meeting the real-time requirements of national news; in terms of switching smoothness, the audience was unaware of the switching process, and there were no problems such as pauses and sudden sounds; in terms of continuity assurance, through pre-scheduling resources and dynamic reconstruction of playlists, the live broadcast was ensured to be uninterrupted, and the subsequent "regular music program" was broadcast as originally planned.

[0046] Extended scenario (general content switching example): If the fault occurs in the "regular music program" segment (low importance level), the system strategy is adjusted as follows: the switching timing is selected at the end of the current song (not a mandatory sentence pause point); the switching delay is allowed to be completed within 200ms (actual execution is 150ms); differentiated emergency materials can be used as replacement materials (such as similar tracks in the backup music library).

[0047] By differentiating the importance levels of programs, the system optimizes resource usage in non-critical links while ensuring core content, thereby improving overall operational efficiency.

[0048] In summary, the present invention can solve the problems of untimely emergency response, inaccurate decision-making and discontinuous fault handling in complex broadcast environments, achieve rapid dynamic reconstruction of broadcast content, and ensure broadcast continuity and service quality.

Claims

1. An emergency broadcast decision method for dynamically reconstructing a playlist, characterized in that: The following steps are involved: Step 1: Real-time monitoring of operating status parameters of the broadcast link, wherein the operating status parameters include signal quality parameters, network link parameters, server resource parameters, and audio stream content parameters; Step 2: When an abnormal operating state parameter is detected, fault diagnosis is performed based on a preset knowledge base, which stores a mapping relationship between fault characteristics and handling plans; Step 3: Generate a playlist reconstruction strategy based on the diagnosis results and multi-dimensional characteristic factors of the currently broadcast program, wherein the multi-dimensional characteristic factors include at least program type, importance level, and switching smoothness requirement; Step 4: Automatically switch the emergency audio stream according to the playlist reconstruction strategy.

2. The emergency broadcast decision method for dynamically reconstructing a playlist according to claim 1 is characterized in that: The step of performing fault diagnosis based on a preset knowledge base includes: Extract abnormal sound patterns from audio streams as fault features through voiceprint analysis; Matching the fault characteristics with characteristic nodes in a knowledge base to determine the fault type; An emergency response plan including switching instructions and backup flow information is generated based on the matching results.

3. The emergency broadcast decision method for dynamically reconstructing a playlist according to claim 2, characterized in that: Also includes: Identify early signs of cascading failures by analyzing the combined patterns of operating status parameters; When early signs are identified, emergency resource pre-scheduling is triggered, including starting the hot standby state of the backup server and pre-loading the emergency audio material.

4. The emergency broadcast decision method for dynamically reconstructing a playlist according to claim 1, characterized in that: The step of generating a playlist reconstruction strategy includes: Real-time analysis of program types, importance levels, and switching smoothness requirements; Select the switching timing and replacement materials based on the factor analysis results of multi-dimensional characteristic factors.

5. The emergency broadcast decision method for dynamically reconstructing a playlist according to claim 4 is characterized in that: The steps of selecting the switching timing and replacing the material specifically include: When the importance level is national news, use content-neutral transition materials to achieve seamless switching within 50ms; When the importance level is regular content, differentiated emergency materials are allowed to be switched within 200ms.

6. The emergency broadcast decision method for dynamically reconstructing a playlist according to claim 1, characterized in that: The step of automatically switching the emergency audio stream includes: The injection delay of emergency audio materials is controlled within the 50 millisecond threshold through millisecond synchronization control; After the switch is completed, the original mainstream ID is automatically replaced and the TS / PTS continuity is maintained.

7. The emergency broadcast decision method for dynamically reconstructing a playlist according to claim 1, characterized in that: The knowledge base is implemented using a lightweight database, and the stored fault features include: Single abnormal parameter characteristics, including independent indicators such as bandwidth below the threshold and CPU usage exceeding the limit; Composite fault signature, including the associated combined features of voiceprint anomalies and server resource anomalies.

8. The emergency broadcast decision method for dynamically reconstructing a playlist according to claim 1, characterized in that: The step of real-time monitoring of the operating status parameters of the broadcast link includes: Continuously collect SCTE-35 breakpoints, audio and video frame loss indicators, and black field duration data; When the packet loss rate exceeds 0.5% or the black field lasts for more than 2 seconds, a fault alarm is immediately triggered.

9. The emergency broadcast decision method for dynamically reconstructing a playlist according to claim 1, characterized in that: The step of generating a playlist reconstruction strategy further includes: Retrieve candidate materials from the emergency broadcast library through AI algorithm models; Perform sound and picture synchronization, loudness equalization processing on the material and check the timing with the arrangement table; Generate an execution plan containing switching instructions and backup flow URLs, with a single error of no more than ±1 second.

Images