A Cloud-Edge Collaborative Method and System for Broadcast Television Monitoring

Abstract

This application relates to a cloud-edge collaborative broadcast television monitoring method and system, belonging to the field of broadcast television monitoring technology. The monitoring method includes: receiving broadcast television signals through dual antennas of an edge terminal; preprocessing the broadcast television signals at the edge terminal to generate preprocessed data and uploading it to a cloud platform via an access layer network; parsing the preprocessed data into radio frequency indicator data, transport stream data, and audio / video data on the cloud platform; performing radio frequency indicator analysis on the radio frequency indicator data to generate radio frequency alarm information; performing bitstream analysis on the transport stream data to generate bitstream alarm information; performing audio / video anomaly identification on the audio / video data to generate content alarm information; and generating a comprehensive alarm message based on the above alarm information and pushing it to the user monitoring terminal via a real-time protocol. This application can dynamically respond to changes in channel quality, improving the data transmission stability and content integrity assurance capabilities.

Description

Technical Field

[0001] This application relates to the field of broadcast television monitoring technology, and in particular to a broadcast television monitoring method and system based on cloud-edge collaboration. Background Technology

[0002] As broadcasting and television continue to evolve towards digitalization, networking, and intelligence, the quality monitoring of broadcasting and television signals and the security supervision of broadcast content have become crucial links in ensuring the safety of program broadcasts, improving the user viewing experience, and implementing industry compliance requirements. Traditional analog monitoring methods have been gradually replaced by digital systems, while digital television (such as DTMB) and digital broadcasting (such as CDR) in the modern broadcasting system adopt more complex modulation methods and transmission protocols, and the signal content itself also exhibits higher structural complexity and diversity.

[0003] Meanwhile, the nationwide coverage needs of broadcasting services necessitate that broadcast television signal monitoring possess characteristics of high coverage, high density, and high frequency, and be able to simultaneously handle various complex deployment scenarios, including urban environments, rural areas, remote mountainous regions, and mobile terminals in transportation. Therefore, to achieve nationwide end-to-end quality control of broadcast television, the industry has placed higher demands on monitoring systems in terms of intelligence, deployment flexibility, data integrity, and multi-dimensional fault identification capabilities.

[0004] Currently, broadcast television signal quality monitoring systems primarily rely on centrally deployed dedicated equipment for signal acquisition and analysis, with local servers handling signal processing and storage. While this structure offers good performance in certain fixed locations, it struggles to balance coverage breadth and deployment efficiency when facing large-scale, multi-location deployments. Furthermore, because the system architecture is largely static, it lacks real-time adaptability to dynamic channel changes. Consequently, it lacks effective automatic identification and intelligent alarm mechanisms when encountering playback anomalies in audio and video content. Once channel conditions fluctuate or become abnormal, the ability to guarantee data transmission stability and content integrity significantly decreases. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a broadcast television monitoring method and system based on cloud-edge collaboration.

[0006] Firstly, this application provides a broadcast television monitoring method based on cloud-edge collaboration, employing the following technical solution:

[0007] A broadcast television monitoring method based on cloud-edge collaboration, the monitoring method comprising:

[0008] The edge terminal receives broadcast television signals via dual antennas; wherein the dual antennas include a first interface for receiving DTMB signals and a second interface for receiving CDR signals.

[0009] The broadcast television signal is preprocessed at the edge terminal to generate preprocessed data;

[0010] The preprocessed data is uploaded to the cloud platform via the access layer network;

[0011] The preprocessed data is received on the cloud platform and parsed into radio frequency index data, transport stream data, and audio / video data;

[0012] The radio frequency (RF) index data is analyzed to generate RF alarm information.

[0013] Perform bitstream analysis on the transmitted data to generate bitstream alarm information;

[0014] The audio and video data are subjected to audio and video anomaly identification to generate content alarm information;

[0015] Based on the radio frequency alarm information, code stream alarm information, and content alarm information, a comprehensive alarm message is generated;

[0016] The integrated alarm message is pushed to the user's monitoring terminal via a real-time protocol.

[0017] By adopting the above technical solution, and decoupling signal reception and analysis functions, lightweight data acquisition and intelligent preprocessing are achieved at the edge, while multi-level data analysis and alarm determination are centrally completed in the cloud. The entire solution design integrates the data characteristics and standard requirements of the physical layer, transmission layer, and content layer, realizing an end-to-end closed-loop system for broadcast signal monitoring, from signal quality assessment and transmission integrity verification to abnormal content identification. This application not only significantly reduces deployment costs and expansion barriers but also improves monitoring response speed and fault diagnosis accuracy, making it particularly suitable for the current needs of the broadcast television monitoring field evolving towards distributed intelligence.

[0018] Secondly, this application provides a broadcast television monitoring system based on cloud-edge collaboration, which adopts the following technical solution:

[0019] A broadcast television monitoring system based on cloud-edge collaboration, the monitoring system comprising edge terminals, an access layer network, and a cloud platform:

[0020] The edge terminal is used to receive broadcast television signals via dual antennas and perform preprocessing to generate preprocessed data; wherein the dual antennas include a first interface for receiving DTMB signals and a second interface for receiving CDR signals;

[0021] The access layer network is used to upload the preprocessed data to the cloud platform;

[0022] The cloud platform is configured as follows:

[0023] The preprocessed data is received and parsed into radio frequency index data, transport stream data, and audio / video data;

[0024] The radio frequency (RF) index data is analyzed to generate RF alarm information.

[0025] Perform bitstream analysis on the transmitted data to generate bitstream alarm information;

[0026] The audio and video data are subjected to audio and video anomaly identification to generate content alarm information;

[0027] Based on the radio frequency alarm information, code stream alarm information, and content alarm information, a comprehensive alarm message is generated;

[0028] The integrated alarm message is pushed to the user's monitoring terminal via a real-time protocol.

[0029] Thirdly, this application provides a computer device, which adopts the following technical solution:

[0030] A computer device includes a memory, a processor, and a computer program stored in the memory, the processor executing the computer program to perform the steps of the method as described in the first aspect.

[0031] Fourthly, this application provides a computer-readable storage medium, which adopts the following technical solution:

[0032] A computer-readable storage medium storing a computer program that can be loaded by a processor and executed as in any of the methods in the first aspect.

[0033] In summary, this application achieves at least one of the following beneficial technical effects: It realizes a closed-loop monitoring mechanism covering the entire process from signal reception, data preprocessing, intelligent classification and uploading to multi-level analysis and comprehensive alarms. This technical solution fully utilizes the lightweight receiving capabilities of edge terminals and the centralized computing resources of cloud platforms, organically integrating physical layer radio frequency quality monitoring, transmission layer bitstream structure analysis, and content layer audio and video anomaly identification. This not only improves the accuracy and response speed of fault identification but also significantly reduces deployment costs and system expansion difficulty. By pushing comprehensive alarm information through real-time protocols, the system possesses efficient and reliable emergency response capabilities, demonstrating significant practical application value in ensuring broadcast program quality, security supervision, and compliance review. It is particularly suitable for building a nationwide, wide-area, flexibly deployable intelligent broadcast television monitoring network. Attached Figure Description

[0034] Figure 1 This is a first flowchart illustrating a broadcast television monitoring method according to one embodiment of this application.

[0035] Figure 2 This is a second flowchart illustrating a broadcast television monitoring method according to one embodiment of this application.

[0036] Figure 3 This is a schematic diagram of the third process of a broadcast television monitoring method according to one embodiment of this application.

[0037] Figure 4 This is a schematic diagram of the fourth process of a broadcast television monitoring method according to one embodiment of this application.

[0038] Figure 5 This is a schematic diagram of the fifth process of a broadcast television monitoring method according to one embodiment of this application.

[0039] Figure 6 This is a schematic diagram of the sixth process of a broadcast television monitoring method according to one embodiment of this application.

[0040] Figure 7 This is a schematic diagram of the seventh process of a broadcast television monitoring method according to one embodiment of this application.

[0041] Figure 8 This is a schematic diagram of the structure of a broadcast television monitoring system according to one embodiment of this application.

[0042] Figure 9 This is a schematic diagram of a dual-antenna broadcast signal receiving structure according to one embodiment of this application. Detailed Implementation

[0043] To make the purpose, technical solution, and advantages of this application clearer, the following description is provided in conjunction with the appendix. Figure 1 - Appendix Figure 9 The present application will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the application.

[0044] This application discloses a broadcast television monitoring method based on cloud-edge collaboration.

[0045] Reference Figure 1 A broadcast television monitoring method based on cloud-edge collaboration, the monitoring method includes:

[0046] Step S101: Receive broadcast television signals through the dual antennas of the edge terminal;

[0047] The dual antennas include a first interface for receiving DTMB signals and a second interface for receiving CDR signals;

[0048] Specifically, the system relies on the dual-antenna structure of the edge terminal to receive broadcast television signals. This dual-antenna system includes physical interfaces corresponding to two standards: Digital Terrestrial Multimedia Broadcast (DTMB) and China Digital Radio (CDR).

[0049] It should be noted that DTMB is my country's primary terrestrial digital television standard, primarily using TDS-OFDM modulation, which offers strong resistance to multipath interference and is suitable for terrestrial television transmission environments. CDR, on the other hand, is a national standard for the digitization of radio stations, with a signal structure and modulation / demodulation method better suited for mobile scenarios. By configuring independent RF input interfaces for the two standards, the system ensures complete signal access under different broadcasting systems, meeting the need for simultaneous monitoring of diverse signal sources. This dual-interface design not only achieves decoupling at the physical link level but also provides the prerequisite for signal source differentiation for subsequent data processing modules, thereby supporting concurrent processing of multi-mode signals.

[0050] Step S102: Preprocess the broadcast television signal at the edge terminal to generate preprocessed data;

[0051] The preprocessing step is not simply signal buffering or forwarding, but rather a preliminary structural extraction and format conversion of the received signal.

[0052] Specifically, DTMB / CDR signals are digitized after RF sampling at the RF front end and enter the intermediate frequency demodulation and decoding process. Subsequently, they undergo layer-by-layer stripping to extract, but not limited to, physical layer parameters (such as CNR, BER, MER, and level), transport stream segments (TS stream), and audio / video encapsulation data. This "preprocessing" step possesses strong edge intelligence attributes. On the one hand, it reduces the upload bandwidth load through compression and redundancy removal techniques; on the other hand, it improves the signal-to-noise ratio of the data by initially screening for abnormal features. For example, RF parameters are smoothed using a time-window moving average to suppress misjudgments caused by instantaneous jitter; while the bitstream data may first undergo PID filtering to retain only valid service-related segments, reducing the space occupied by non-service streams.

[0053] Step S103: Upload the preprocessed data to the cloud platform via the access layer network;

[0054] The access layer network can be a 4G or 5G cellular network or a WiFi wireless LAN, chosen based on the network reachability and real-time requirements of the deployment site. Data transmission uses the SRT (Secure Reliable Transport) protocol, which supports packet loss retransmission and latency optimization, offering stronger jitter resistance in high-bandwidth transmissions such as video streaming compared to the traditional TCP protocol. Because this protocol uses UDP as its basic transmission method and application-layer error control, it effectively reduces latency while ensuring reliability, guaranteeing data integrity and high-speed delivery to the cloud.

[0055] Step S104: Receive preprocessed data on the cloud platform and parse it into radio frequency index data, transport stream data, and audio / video data;

[0056] Specifically, the parsing process decodes and identifies the data based on header information, protocol tags, and encapsulation structure, thereby classifying the data into three main categories: radio frequency indicator data, transport stream data, and audio / video data.

[0057] Among them, radio frequency (RF) metrics data are used to reflect the quality of wireless links, transport stream data is structured MPEG-TS or DMB-TS bitstreams, and audio and video data is encapsulated media streams before decoding. This classification not only facilitates the parallel loading of multi-dimensional analysis models, but also provides a data foundation for heterogeneous analysis tasks (physical layer, transport layer, application layer).

[0058] Step S105: Perform radio frequency index analysis on the radio frequency index data and generate radio frequency alarm information;

[0059] In the RF performance analysis phase, the carrier-to-noise ratio (CNR) serves as an example. It reflects the ratio between signal and noise, directly affecting the stability of modulation and demodulation. The system compares the CNR value with a standard lower limit; if it falls below the threshold, a modulation quality problem is identified. Similarly, the bit error rate (BER) is used to assess the incidence of bit-level errors in the channel. A sustained exceedance of the BER may indicate multipath interference or interference source intrusion. The modulation error rate (MER) comprehensively reflects the accuracy of the modulation vector and is a crucial indicator of modulation quality.

[0060] Understandably, the system uses a pattern recognition mechanism to further identify the causes of the drastic fluctuations in the aforementioned parameters within a short period, determining whether it is due to signal obstruction, electromagnetic interference, or a transmitter malfunction. This analysis method, based on multi-indicator collaborative comparison and fault mode recognition, significantly improves the accuracy and classification capability of alarms.

[0061] Step S106: Perform bitstream analysis on the transport stream data and generate bitstream alarm information;

[0062] Specifically, the analysis of transport stream data can be conducted based on digital television industry standards, which define three levels of error categories during the transmission of the bitstream. The system extracts information such as program description, decoding reference clock, and conditional access through PID parsing and PSI / SI entry parsing. Then, a three-level detection mechanism is used: the first layer detects the synchronization stability of the bitstream (e.g., synchronization word loss, entry timeout); the second layer detects coding layer parameters (e.g., PTS / DTS timestamp anomalies, entry update cycle exceeding limits); and the third layer evaluates the decoder buffer behavior and content integrity.

[0063] In addition, the system will set weights based on actual business needs and calculate the health score of the bitstream through a weighted algorithm. This score is not only used to judge the current operating status of the bitstream, but also serves as one of the basic indicators for historical trend analysis.

[0064] Step S107: Perform audio and video anomaly identification on the audio and video data and generate content alarm information;

[0065] Specifically, at the content level, the cloud platform decodes audio and video data in real time and uses image processing and audio analysis technologies to identify audio and video anomalies. For example, black level detection is based on statistical analysis of the Y (luminance) component in the YUV color space, triggering anomalies when the brightness of consecutive frames falls below a set threshold; still frame recognition uses structural similarity algorithms (such as SSIM) to determine differences between image frames, avoiding false alarms due to still images; the audio portion uses PCM energy spectrum analysis to determine loss of sound and assess audio-video synchronization. These algorithms emphasize the integrity assessment of the semantic layer of the content, enabling the discovery of deep-seated playback faults that are difficult to identify using traditional radio frequency or transmission layer methods.

[0066] Step S108: Generate a comprehensive alarm message based on radio frequency alarm information, code stream alarm information, and content alarm information;

[0067] Specifically, radio frequency (RF) alarm information, bitstream alarm information, and content alarm information are aggregated through a rules engine, and a comprehensive alarm message is generated by the alarm fusion module. This process is not merely information overlay, but also enhances the operability of alarms through logical association and priority filtering. For example, if there is an RF anomaly, bitstream loss, and a black screen, it can be determined as a regional signal interruption; if there is only a still frame but the RF and bitstream are normal, it may be a program production failure.

[0068] Step S109: Push the comprehensive alarm message to the user monitoring terminal via a real-time protocol.

[0069] The system will push comprehensive alarm information to the user's monitoring terminal using real-time protocols such as WebSocket, ensuring that alarms are accurately delivered to the front-end user within a delay of less than 5 seconds, thus enabling immediate response.

[0070] In the above embodiments, by decoupling signal reception and analysis functions, lightweight data acquisition and intelligent preprocessing are achieved at the edge, while multi-level data analysis and alarm determination are centrally completed in the cloud. The entire solution design integrates the data characteristics and standard requirements of the physical layer, transmission layer, and content layer, realizing an end-to-end closed-loop system for broadcast signal monitoring, from signal quality assessment and transmission integrity verification to abnormal content identification. This application not only significantly reduces deployment costs and expansion barriers but also improves monitoring response speed and fault diagnosis accuracy, making it particularly suitable for the current needs of the broadcast television monitoring field evolving towards distributed intelligence.

[0071] Reference Figure 2 As one implementation of step S105, the step of performing radio frequency index analysis on the radio frequency index data includes:

[0072] Step S201: Decompress and parse the radio frequency index data to extract the payload data;

[0073] Specifically, RF performance data is uploaded in compressed form via HTTP. To ensure efficient transmission and bandwidth utilization, lightweight compression algorithms such as GZIP and LZ4 are typically used. These algorithms can encode at extremely low latency at the edge and decode at extremely high throughput in the cloud. Upon receiving the data packet on the cloud platform, the system needs to parse its format, restoring the compressed packet to a structured performance data object. This step involves identifying and mapping field tags, timestamps, terminal numbers, frequency point numbers, and core performance fields (such as carrier-to-noise ratio, bit error rate, modulation error rate, and signal level). This process is similar to data packet decapsulation and parameter extraction, ultimately extracting the payload data, which is the set of core performance indicators used for analysis.

[0074] Step S202: Store the payload data into the radio frequency data buffer queue;

[0075] The radio frequency (RF) data is time-series data, with each data packet representing the sampling result of a monitoring terminal on a specified channel at a specific moment. The buffer queue, as a concurrency-safe data structure, possesses First-In-First-Out (FIFO) characteristics, arranging the sampled data in chronological order to facilitate subsequent sliding window processing, statistical aggregation, and real-time comparison. Furthermore, the queue design considers memory usage and timeliness strategies to ensure that the system does not experience data backlog or frame loss when processing high-frequency samples.

[0076] Step S203: Load the preset threshold value of the current channel from the configuration library;

[0077] Among them, the preset threshold values ​​include carrier-to-noise ratio tolerance, bit error rate threshold, and level range;

[0078] Specifically, a configuration library is a semi-structured database or set of configuration files that pre-defines multi-dimensional quality tolerance ranges for each channel. Specific parameters include: Carrier-to-Noise Ratio (CNR) Tolerance: This characterizes the lower limit of the signal-to-noise ratio, typically measured in dB. A low CNR indicates strong interference or weak coverage. Bit Error Rate Threshold (BERThreshold): This quantifies the allowable upper limit of the channel's transmission error rate, often expressed exponentially, such as 1e-4. Signal Level Range: This defines a reasonable range for signal strength; too high a range can lead to saturation, while too low a range may result in frame drops; the unit is often dBuV.

[0079] It should be noted that these threshold values ​​are not statically configured, but can be adaptively adjusted through historical data (i.e., dynamic threshold strategy) to improve the system's tolerance and sensitivity to changes in indicators under different environments.

[0080] Step S204: Real-time analysis of radio frequency sampling data in the radio frequency data buffer queue, comparing each radio frequency sampling data with a preset threshold value to obtain the comparison result;

[0081] Specifically, the system continuously reads sampled data from the cache queue using a sliding time window, comparing and analyzing each sample with the threshold values ​​loaded in the current configuration library. Item-by-item comparison refers to performing threshold determination logic on each individual indicator value to obtain the comparison result.

[0082] For example, if the CNR is lower than its tolerance lower limit, it is determined that the modulation environment has deteriorated, and demodulation of the bit stream may fail; if the BER exceeds its threshold upper limit, it indicates a surge in bit transmission error rate and a decrease in reception reliability; if the signal level exceeds the normal upper and lower limits, it may indicate abnormal circuitry in the receiving equipment, increased feeder loss, or increased interference. These comparison logics are usually executed based on Boolean judgment expressions and coupled with historical change trends to avoid misjudgments caused by short-term fluctuations.

[0083] Step S205: Based on the comparison results, trigger an alarm event;

[0084] The classification of alarm events is based on the logical judgment path set according to the specific differences in the triggering conditions. Specifically, it includes: triggering a modulation error alarm when the carrier-to-noise ratio is detected to be lower than the lower limit of the carrier-to-noise ratio tolerance; triggering a bit error rate exceeding the upper limit of the bit error rate threshold when the bit error rate is detected to be higher than the upper limit of the bit error rate threshold; and triggering a level abnormality alarm when the signal level is detected to be outside the level range.

[0085] It should be noted that the alarm triggering logic supports multiple conditions combined for triggering and sorts different alarm levels according to priority.

[0086] Step S206: Perform abnormal pattern recognition on the alarm events to generate classified alarm events;

[0087] After generating the original alarm event, the system further performs abnormal pattern recognition to form alarm information with high-order semantic classification. This step is not just about labeling the alarm event, but about applying pattern recognition algorithms to convert the linked changes of indicators into the fault type of the real scenario.

[0088] For example, if the carrier-to-noise ratio suddenly drops and the bit error rate simultaneously spikes, it indicates a high correlation in time, which may be due to external electromagnetic interference (such as interference from a frequency jammer or lightning).

[0089] If the level continues to deviate from the normal value and the system loses lock, i.e. the frequency is out of sync or cannot be demodulated, it indicates that the antenna feeder may be damaged or the connection is unstable.

[0090] If the CNR, BER, and level all deteriorate gradually at the same time, it indicates that the problem is not at the receiver but at the transmitter system, such as power degradation, modulation module failure, or abnormal transmitter output.

[0091] The above identification process is based on the expert system rule base or machine learning classification model to classify various abnormal behaviors such as single point of failure, multi-point consecutive failure, and trend degradation, providing operation and maintenance personnel with an actionable qualitative reference.

[0092] Step S207: Execute the alarm response mechanism for the classified alarm events and output radio frequency alarm information.

[0093] The alarm response mechanism includes logging, pushing alerts to the app, sending SMS or emails, and can also link with the broadcast system maintenance platform to generate work orders. Alarm output is a structured radio frequency alarm information object, containing information such as fault type, details of indicator changes, timestamp, device number, and geographical location, ensuring that user monitoring terminals can accurately and efficiently receive critical information.

[0094] In the above embodiments, the real-time analysis of physical layer signal quality is constructed into a scalable, automated, and intelligent processing chain. This not only enables rapid response to signal quality changes uploaded by edge terminals but also allows for fault mode identification and cause classification through cross-analysis of indicators. This significantly improves the practicality and accuracy of broadcast television monitoring systems in multi-point distribution, heterogeneous networks, and complex interference environments. Compared to traditional manual monitoring or fixed threshold triggering modes, this application has significant advantages in real-time performance, accuracy, alarm quality, and equipment adaptability, providing technical support for wide-area intelligent monitoring.

[0095] Understandably, in remote intelligent monitoring systems for broadcast television signals, the analysis of radio frequency (RF) indicators is a fundamental step in assessing the physical layer quality of signals. Its core objective is to extract measurable, comparable, and alarm-enabled RF performance indicators from data uploaded by edge terminals, thereby determining network link status, identifying equipment faults or environmental interference, and ensuring the monitoring system possesses real-time and accurate quality assessment capabilities. This analysis process not only relies on basic signal statistical parameter processing but also integrates dynamic threshold discrimination, event triggering mechanisms, and methods for identifying complex anomaly patterns, constructing a complete physical layer health assessment system.

[0096] Reference Figure 3 As one implementation of step S106, the step of performing bitstream analysis on the transport stream data includes:

[0097] Step S301: Perform PID filtering on the transport stream data to extract valid data packets;

[0098] The core mechanism of Transport Stream (TS) is to encapsulate various types of program data (video, audio, subtitles, table information, etc.) in data packets of a uniform length (usually 188 bytes). Each data packet is identified by a Packet Identifier (PID) contained in its first 4 bytes of header field. The use of PIDs allows the receiving end to quickly locate and extract the required type of data through PID filters without having to decode all packets sequentially, thereby improving processing efficiency and reducing interference from irrelevant data.

[0099] In this embodiment, PID filtering is used to remove irrelevant service flows, such as unsubscribed channels, test signals, or encrypted redundant data, retaining only valid packets relevant to the current monitoring task. This operation can be quickly accomplished through hardware acceleration or parallelized software filtering mechanisms, resulting in a well-structured and content-focused effective dataset.

[0100] Step S302: Parse the Program Specific Information (PSI) and Service Information (SI) in the valid data packets to extract the transport stream structure metadata;

[0101] After completing the PID filtering, the system parses the Program Specific Information (PSI) and Service Information (SI) in the valid data packets. PSI includes PAT (Program Association Table) and PMT (Program Map Table), which describe the composition structure of each stream contained in each channel and its corresponding PID, serving as a "navigation map" for correct program decoding. SI, on the other hand, belongs to the DVB (Digital Video Broadcasting) standard extension and includes SDT (Service Description Table) and EIT (Event Information Table), carrying descriptive metadata such as program schedules, languages, and service types.

[0102] Specifically, by parsing these entries and extracting transport stream structure metadata, the TS is essentially restored from the raw bitstream into a logical structure information graph, giving the system the fundamental ability to perform semantic analysis of the stream-level structure. This structure metadata not only supports subsequent error detection but also plays a role in information synchronization, audio-visual matching, and program information display.

[0103] Step S303: Perform first-level error detection on the transport stream structure metadata to obtain the first detection result:

[0104] The first level of error detection includes detecting whether a synchronization byte loss alarm, a program association table update timeout alarm, or a program reference clock deviation alarm is triggered.

[0105] Specifically, after the structural restoration is completed, the system enters the first-level error detection stage, which aims to identify structural faults at the lowest level of the transport stream, mainly including problems such as loss of synchronization bytes, delay in program list update, and clock drift.

[0106] First, the synchronization byte detection focuses on whether the first byte of each 188-byte packet is the synchronization byte 0x47, which is a fundamental guarantee of the correctness of the TS structure. If the synchronization byte of 5 consecutive data packets is incorrect, the system can preliminarily determine that there is a serious loss of synchronization in the channel, that is, the packet boundary is misaligned or the data packet is tampered with during signal transmission, triggering a synchronization loss alarm.

[0107] Secondly, the system continuously tracks the PAT table update cycle. If it is not updated for more than 30 seconds, it will trigger a table update timeout alarm. This phenomenon usually means that the PSI information cannot be maintained, and the receiving end will face the playback abnormality of "program disappearance".

[0108] Finally, the system will also monitor the PCR (Program Clock Reference) clock offset. The PCR is the time reference for all audio and video synchronization. If the deviation from the system decoding clock exceeds 100 milliseconds, a clock drift alarm will be triggered, indicating that there is a non-linear delay during program transmission, which will affect audio-visual synchronization and buffer scheduling.

[0109] Step S304: In response to the first detection result being a pass, perform a second-level error detection on the transport stream structure metadata to obtain a second detection result.

[0110] The second level of error detection includes detecting whether a video frame timestamp jump anomaly alarm or a conditional access table update anomaly alarm is triggered.

[0111] Specifically, if the first-level error detection does not find any serious problems, the system will perform the second-level error detection and enter the consistency analysis stage of encoding parameters and content.

[0112] At this stage, the system first detects PTS (Presentation Time Stamp) jumps in video frames. PTS is a timestamp in MPEG used to represent the playback time of video frames and should be highly continuous. If a non-linear timestamp jump is detected (e.g., time reversal or a jump exceeding 1 second), it indicates encoder jitter, time base misconfiguration, or bitstream interpolation issues, and the system will trigger a timestamp anomaly alarm. In addition, the system also checks the update cycle of conditional access control tables such as the CAT (Conditional Access Table). If entries have not been updated for a long time, it may indicate service authorization failure or unauthorized streaming, triggering a transmission anomaly alarm. These detections demonstrate the transition from "structural correctness" to "content usability" analysis.

[0113] For example, verify the continuity of the decoding timestamp; if the timestamp of the video frame jumps by more than 1 second, a timestamp anomaly alarm is triggered; monitor the update cycle of the conditional access table; if it has not been updated for more than 30 seconds, a transmission anomaly alarm is triggered.

[0114] Step S305: In response to the second detection result being a pass, perform a third-level error detection on the transport stream structure metadata to obtain a third detection result.

[0115] The third level of error detection includes detecting whether a buffer state abnormality alarm has been triggered;

[0116] Specifically, if the second-level detection also fails to trigger an anomaly, the system enters the third-level error detection stage. This stage predicts behavior and identifies anomalies based on the system's target decoder model. The system's target decoder model is a buffer behavior simulation model based on the DVB-SIM specification. It assumes data enters a buffer with a specific capacity and decoding rate, simulating the data consumption rhythm during real-time playback. By comparing the theoretical buffer curve with the current decoding state, if buffer underflow is detected—meaning the data arrival speed cannot keep up with the decoding rate—the player will stutter or display a black screen, triggering a data loss alarm. These alarms are typically caused by unstable source bitrates, link jitter, or unreasonable stream scheduling; they are hidden anomalies that structural analysis cannot detect.

[0117] Step S306: Calculate the real-time health score based on the first detection result, the second detection result, and the third detection result, using preset weights.

[0118] After completing the three-layer error detection, the system weights and integrates the results of each layer to calculate the real-time health score.

[0119] In this embodiment, the score is out of 100 and uses a hierarchical weighted approach to reflect the severity of the anomaly: Level 1 errors affect the most basic structural stability and are therefore assigned a weight of 60%; Level 2 errors affect content coherence and account for 30%; Level 3 errors, although having no direct impact on the structure, affect the playback experience and account for 10%. This scoring mechanism is not only interpretable but can also be used for threshold comparison, anomaly ranking, and historical trend prediction, giving the system the ability to "perceive health status".

[0120] Step S307: If the real-time health score is lower than the preset score threshold, a channel quality warning is triggered and a video playback instruction is generated, and a bitstream alarm message is output.

[0121] Specifically, when the score falls below a preset threshold (e.g., 80 points), the system immediately triggers a channel quality warning mechanism and generates a video playback instruction. The logic of video playback is to archive the original bitstream or decoded video clips from the abnormal period for subsequent maintenance and evidence collection analysis. This function is of significant value for program compliance review, broadcasting regulatory evidence collection, and accountability tracing. Finally, the system structures the event into a bitstream alarm information object, including multi-dimensional data fields such as channel information, error level, score trend, and alarm type, and pushes it to the platform management terminal, APP client, or broadcasting supervision system.

[0122] The above implementation constructs a full-link bitstream quality analysis mechanism, encompassing transport stream structure decoding, multi-level error detection, health scoring, and early warning response. Through three-stage detection, it effectively covers various abnormal situations ranging from physical synchronization and protocol entries to playback behavior. Furthermore, it introduces a decoder model and scoring mechanism to construct an evaluation closed loop, enabling the system to continuously monitor the transport layer status with structured indicators, proactively identify potential faults, and prevent signal degradation from substantially impacting terminal playback. This mechanism balances protocol compliance, content consistency, and user experience stability, making it particularly suitable for real-time, refined, and intelligent quality assurance in wide-area distributed broadcast television monitoring scenarios.

[0123] Reference Figure 4 As one implementation of step S107, the step of performing audio and video anomaly recognition on the audio and video data includes:

[0124] Step S401: Receive audio and video data;

[0125] The audio and video data includes encoded video streams and audio streams;

[0126] Specifically, in modern digital broadcasting systems, audio and video signals are encoded and transmitted in compressed encapsulation formats (such as MPEG-2 TS, H.264 / AVC, or HEVC / H.265 encapsulation), where video and audio streams exist as data packets with independent PID identifiers. Receiving this type of streaming data typically employs a demultiplexer based on a TS parser to extract the original video and audio bitstreams, providing a data foundation for subsequent decoding and analysis.

[0127] Step S402: Decode the video stream and convert it to the YUV color space, then extract the luminance component data;

[0128] Video encoding typically employs the YUV color model, where Y represents luminance and U / V represents chrominance. The Y component is a primary source of information influencing image structure and visual perception; therefore, its extraction and analysis in anomaly detection have significant diagnostic value. This process involves the video decoder parsing compressed frames (such as I-frames, P-frames, and B-frames), reconstructing motion vectors, and managing frame buffers, outputting a frame-by-frame sequence of YUV images.

[0129] Step S403: Perform black field detection on the luminance component data. When the average luminance is lower than the set luminance threshold and continues for more than the preset duration, generate a black field abnormal event.

[0130] Specifically, a black screen typically refers to a state where there is absolutely no image content, only a completely black screen or background. This detection method calculates the average of the luminance components across N consecutive frames. If this average value consistently falls below a set threshold L (e.g., 10-20) for more than a threshold T seconds (e.g., 3-10 seconds), it is considered a valid black screen event. The average luminance value is a robust image brightness assessment metric that can filter out false positives caused by short-term black frame transitions or camera angle changes. Furthermore, the threshold range is designed to differentiate between dark scenes and true black screens; for example, the brightness of nighttime shots in some programs may be extremely low, but not consistently low. Therefore, the duration of the black screen is used to increase reliability.

[0131] Step S404: Calculate the structural similarity value for consecutive video frames. When the structural similarity value is continuously higher than the set similarity threshold for a predetermined number of frames, generate a still frame abnormal event.

[0132] Specifically, a still frame refers to a frozen image, where adjacent video frames are almost identical, often caused by encoder failure, source interruption, or playback stuttering. The system uses a structural similarity algorithm (SSIM) to process consecutive frames in blocks using a sliding window, calculating the similarity of three components: luminance, contrast, and structure, and then obtaining the overall SSIM value through a weighted average. When the SSIM of consecutive frames consistently exceeds a set similarity threshold (e.g., 0.95) and reaches a predetermined number of frames (e.g., more than 10 frames), it is identified as a still frame anomaly. This algorithm is superior to pixel difference algorithms (e.g., MSE) in that it has stronger resistance to interference from minor image changes and is a classic model in video content duplication detection.

[0133] Step S405: Perform pulse code modulation energy detection on the audio stream. When the energy across the entire frequency band is continuously lower than the set energy threshold, generate an audio loss event.

[0134] In the audio dimension, the system performs pulse code modulation energy detection on the audio stream. This process aims to determine whether audio is lost or the signal strength is insufficient. Pulse code modulation (PCM) is the basic digital representation of audio signals, and its presence can be assessed by detecting the average energy value across the entire frequency band (usually measured in dBFS). The system is based on the short-time Fourier transform (STFT) within a sliding time window. If the energy across all frequency bands remains below a set threshold (e.g., -50 dBFS), an audio loss event is triggered. This method has high sensitivity, effectively identifying recording faults, audio channel disconnections, and other problems, and can filter out natural silence in non-speech segments.

[0135] Step S406: Convert the video stream from RGB color space to HSV color space, perform color bar template matching, and generate a test signal event when the matching degree exceeds the set threshold.

[0136] Test color bars (such as SMPTE color bars) are commonly used for signal debugging or transitions before program switching, exhibiting stable color distribution and distinct regions. The system converts video frames from RGB to HSV color space, where hue and saturation have stronger color differentiation capabilities. Subsequently, the HSV histogram of the frame image is extracted and its matching degree with a pre-stored standard color bar template is calculated. When the matching degree exceeds a set threshold (e.g., 0.9), it is determined to be a test signal event. This method can resist the color shift effects caused by resolution scaling and encoding compression.

[0137] Step S407: Compare the difference between the video frame display timestamp and the audio frame timestamp. When the difference exceeds the preset tolerance range, generate an audio-visual synchronization abnormality event.

[0138] Specifically, in digital broadcasting systems, the Presentation Time Stamp (PTS) is the core timing benchmark for audio and video frame synchronization. The system records the PTS of the currently playing audio and video, calculates the time difference between them, and determines whether it exceeds a set tolerance (e.g., 500ms). If the deviation persists, it indicates a decoding buffer anomaly, transmission lag, or time base drift, and an audio-visual desynchronization alarm can be generated. This comparison not only reflects problems with the audio-visual synchronization mechanism itself but also indirectly reflects the quality of the transmission network or the stability of the player's rendering mechanism.

[0139] Step S408 aggregates black screen abnormal events, still frame abnormal events, audio loss events, test signal events, and audio-visual synchronization abnormal events, and outputs alarm information.

[0140] The content alarm information includes fields such as event type, detection location (timestamp), severity level, image frame sample, and audio waveform capture, and can be pushed to the operation and maintenance platform or mobile terminal in real time via protocols such as WebSocket and MQTT. This multi-dimensional anomaly aggregation mechanism enables content layer monitoring to shift from "indicator-based" to "semantic," improving the identifiability, interpretability, and traceability of anomalies.

[0141] The above embodiments systematically cover mainstream playback anomaly types, including black screens, still frames, silence, color bars, and audio-visual asynchrony, from visual structure analysis, audio energy perception, color space matching to temporal consistency verification. Compared with traditional equipment that can only rely on radio frequency and bitstream parameters, this application significantly improves the perception capability in identifying the actual playback status of programs. It can help broadcast regulatory agencies, media platforms, and operators obtain content playback quality in real time, avoid broadcast accidents, improve user experience, and provide a detailed and accurate chain of evidence for anomalies, providing technical support for fault tracing and responsibility allocation.

[0142] Reference Figure 5 As a further implementation of the broadcast television monitoring method, after the step of receiving broadcast television signals via dual antennas of the edge terminal, the method further includes:

[0143] Step S501: Obtain the geographical parameters of the deployment location of the edge terminal;

[0144] The geographic parameters include longitude, latitude, and altitude data;

[0145] Specifically, this geographic information is typically provided by a GPS module or can be obtained through external network location services. This parameter is used not only for device identification and data positioning but also provides a three-dimensional coordinate basis for subsequent spatial modeling and spectrum matching. In particular, the altitude parameter is of significant value for radio frequency propagation modeling because terrain differences directly affect key physical phenomena such as multipath reflection, signal blockage, and reception strength.

[0146] Step S502: Construct a three-dimensional grid coordinate model based on geographic parameters, and spatially match the three-dimensional grid coordinate model with the spectrum map database pre-stored on the cloud platform to extract the expected frequency point set of the target area.

[0147] The 3D grid coordinate model can be expressed using a regular grid or a voxel grid, forming a discrete spatial representation of the device. Each grid cell contains geographic location information, allowing the device's receiving point to be mapped to a pre-established spectrum map database on the cloud platform. A spectrum map is a data structure that binds historically collected radio frequency signal parameters (such as frequency occupancy, signal strength, interference density, etc.) within a specific area to spatial locations, typically managed based on a raster geographic information system (GIS). During spatial matching, the expected set of frequencies for the corresponding area is extracted through coordinate similarity calculations (such as Euclidean distance measurement), representing all possible broadcast frequencies within that area.

[0148] Step S503: Traverse the expected frequency point set using an adaptive frequency point scanning algorithm and calculate the comprehensive quality score for each frequency point in real time;

[0149] The adaptive frequency scanning algorithm, based on the frequency distribution density and known channel structure, performs energy detection and parameter analysis on candidate frequency points one by one within a set scanning period. To improve processing efficiency, this embodiment employs a frequency hopping + weighted prediction mechanism, prioritizing the scanning of historically active frequency points and calculating a comprehensive quality score for each frequency point based on real-time measurements. The scoring formula is:

[0150] ;

[0151] In the above formula, the signal strength P RSSI The signal strength is represented by RF power; CNR (Carrier-to-Noise Ratio) reflects signal quality; and BER (Bit Error Rate) reflects the probability of transmission errors. By calculating the weighted sum of these three factors, the system can select the optimal frequency point while balancing signal strength, modulation quality, and data reliability. Furthermore, the weighting of 6:3:1 is based on the empirical rule that signal strength variations have the most significant impact on reception success rate in actual broadcast environments.

[0152] Step S504: Select the frequency point with the highest overall quality score as the target frequency point;

[0153] Once the scoring is complete, the system will lock the frequency with the highest overall quality score as the target frequency and use it as the core parameter to perform dynamic configuration of dual-antenna receiving parameters.

[0154] Step S505: Dynamically configure the receiving parameters of the dual antennas according to the physical characteristics of the target frequency.

[0155] The dynamic configuration involves adaptively optimizing the receiving hardware path of the two antenna interfaces. The receiving parameters include the gain parameters and bandpass filter coefficients of the first interface and the anti-interference filter threshold of the second interface.

[0156] Specifically, the first interface (such as the DTMB receiving path) can adjust the gain parameters of the low-noise amplifier (LNA) to adapt to the signal strength at different receiving distances, while loading specific bandpass filter (BPF) coefficients to retain only the required frequency signals and effectively shield adjacent channel interference; the second interface (such as the CDR receiving path) is configured with an anti-interference filtering threshold to set a dynamic threshold in areas with strong interference (such as urban high-density broadcasting environments) to achieve adaptive attenuation of interference signals.

[0157] Step S506: Real-time acquisition of signal reception quality parameters of the dual antennas after configuration;

[0158] After configuration, the system enters the real-time acquisition phase, collecting current reception quality parameters from both antennas, primarily including signal strength, carrier-to-noise ratio, and bit error rate. This parameter acquisition is based on the front-end RF sampling module and the embedded performance statistics engine, using algorithms such as sampling averaging and sliding window filtering to eliminate occasional deviations and ensure data stability.

[0159] Step S507: Compare the signal reception quality parameters with the historical spectrum data corresponding to the coordinates in the spectrum map in a time and space, and calculate the frequency offset index;

[0160] Specifically, in order to determine whether the current reception status is abnormal, the system performs a spatiotemporal comparison analysis of the current signal reception quality parameters with historical spectrum data in the spectrum map to identify whether there is frequency drift or abnormal fluctuation.

[0161] It should be noted that this comparison is not limited to numerical differences, but is also based on the consistency of both location coordinates and timestamp dimensions. To quantify this difference, the system introduces a frequency offset index, the mathematical expression of which is: This formula is the normalized mean square error, which can measure the "spectral deviation" between the current state and historical states.

[0162] Step S508: When the frequency offset index exceeds the preset frequency offset threshold, the dual-antenna self-calibration process is triggered, the calibrated frequency point parameters are output and the spectrum map database is updated.

[0163] Specifically, when the calculated frequency offset index exceeds a preset threshold, the system considers the current reception state to have deviated from normal statistical patterns and triggers a dual-antenna self-calibration process. This process consists of two stages:

[0164] First-level calibration: The system invokes the spectral fingerprint database, which stores optimal filter parameter combinations for different signal environments based on historical experience. By matching the current abnormal state with patterns in the fingerprint database, the filter parameters corresponding to the fingerprint with the highest similarity are loaded, completing the initial optimization.

[0165] Second-level calibration: If instability still exists after the first-level calibration, the system further enters the dual-antenna cross-verification mode. By analyzing the phase difference and signal difference between the two antennas, phase consistency analysis (such as cross-correlation function) is used to identify whether there is physical path damage or antenna component hardware abnormality, and to accurately locate the source of the fault (such as failure of a certain LNA or poor connection).

[0166] Finally, the latest frequency parameters generated after calibration will be recorded and used to update the spectrum map database, forming a closed-loop learning mechanism. This enables the system to have the evolutionary characteristics of spectrum cognition ability during long-term operation, adapting to the complex and ever-changing broadcast signal environment.

[0167] In the above embodiments, based on the linkage between the spectrum map and the three-dimensional geographic model, the system realizes coupled analysis of space and signal. Through frequency offset index and two-level calibration process, the system has the ability to respond quickly and self-repair to environmental changes and hardware anomalies. The technical solution of this application not only significantly improves the reception stability of edge terminals in non-ideal deployment environments, but also provides theoretical support and practical path for the reliable deployment of broadcast television monitoring systems in large-scale, distributed, and complex scenarios.

[0168] Reference Figure 6 As a further implementation of the broadcast television monitoring method, before uploading the preprocessed data to the cloud platform via the access layer network, the method further includes:

[0169] Step S601: Parse the preprocessed data to generate transport stream data;

[0170] In this process, the TS stream containing broadcast service information is extracted from the mixed signal, providing the original basis for subsequent statistical calculations based on the TS structure.

[0171] Step S602: Real-time acquisition of program clock reference timestamp sequence in transmission stream data, calculation of standard deviation of N consecutive timestamps, and generation of PCR jitter value;

[0172] The timestamp sequence is the reference clock used for audio-visual synchronization in the MPEG transport layer. It is periodically inserted into the PMT (Program Map Table) or TS packet of each program by the encoding end. The PCR should increment at a fixed rhythm (usually once every 40ms). Therefore, by sampling N consecutive PCR timestamps and calculating their standard deviation, clock drift or jitter can be quantified. A high PCR jitter value indicates the accumulation of clock errors in the transmission link, which may be caused by transmission link jitter, buffer jitter, or synchronization errors, and will directly affect the audio-visual synchronization effect at the terminal.

[0173] Step S603: Monitor the continuity counter difference in the data packet header of the transport stream, calculate the ratio of the number of lost packets to the total number of packets, and generate the TS packet loss rate;

[0174] The system also monitors the difference in the "Continuity Counter" field in the TS packet header. This field maintains a 4-bit rolling counter for each PID, incrementing by 1 (modulo 16) for each valid packet transmitted. The receiver can determine whether packet loss or retransmission has occurred by checking the difference in the consecutive packet counters. By comparing the difference between the counters of the current packet and the previous packet, the number of lost packets is counted, and then the ratio to the total number of packets is used to calculate the TS packet loss rate. This metric reflects whether there is frame-level data loss or sudden network interruption in the channel and is a key parameter for evaluating transmission stability.

[0175] Step S604: Sample the carrier-to-noise ratio (CNR) sequence and bit error rate (BER) of the radio frequency signal at fixed time intervals, perform linear regression analysis on the CNR sequence, output the slope of the CNR drift curve, and calculate the rate of change of BER between adjacent sampling points.

[0176] The system samples the carrier-to-noise ratio (CNR) and bit error rate (BER) sequences acquired by the radio frequency front-end at fixed time intervals to determine the short-term fluctuation trend of channel quality. CNR reflects the strength of the signal relative to background noise and directly affects link transmission capability; BER reflects the probability of bit errors occurring per unit time and is mainly affected by interference and fading. After acquiring the sampled sequences, the system performs linear regression analysis on the CNR, and the slope of the regression result represents the CNR drift trend. A negative slope indicates a decrease in channel quality, while a positive slope indicates an improvement in quality.

[0177] On the other hand, by calculating the rate of change of bit error rate (ΔBER) between adjacent sampling points, the severity of bit error fluctuations can be quantified, which is of great significance for determining whether an interference source is being activated or whether the signal is deteriorating rapidly.

[0178] Step S605: Construct an evaluation matrix based on PCR jitter value, TS packet loss rate, carrier-to-noise ratio drift curve slope, and bit error rate change rate.

[0179] The multi-dimensional evaluation matrix is ​​a set of feature vectors containing PCR jitter value, TS packet loss rate, CNR drift slope, and bit error rate change rate, indicating the current channel environment of the terminal. Each indicator in the matrix is ​​compared with preset threshold values ​​either issued from the cloud or configured locally. These thresholds are empirical quality limits, representing the system's classification boundaries for different risk levels, such as "normal transmission," "tolerable fluctuations," "retransmission guarantee required," and "high-risk packet loss."

[0180] Step S606: Dynamically select the data transmission mode based on the comparison results of each evaluation index in the evaluation matrix with the preset index threshold.

[0181] Based on the comparison results, the system dynamically selects the data transmission mode. This dynamic control mechanism significantly enhances the data availability of the edge terminal, avoiding real-time data loss due to signal fluctuations and preventing bandwidth resource waste caused by excessive transmission redundancy. It embodies the integrated intelligent communication concept of "perception-judgment-control".

[0182] The above implementation improves the data transmission security, fault tolerance, and environmental adaptability of the edge broadcast television monitoring terminal. The system not only dynamically senses the stability of the transmission link based on structured indicators, but also has the ability to select the optimal transmission strategy for different abnormal scenarios, thereby achieving "upload behavior with quality judgment," which is particularly crucial in low-power, weak-coverage, and frequently fluctuating mobile edge environments.

[0183] Reference Figure 7As one implementation of step S606, dynamically selecting the data transmission mode based on the comparison results of each evaluation index in the evaluation matrix with the preset index threshold includes:

[0184] Step S701: Determine whether all evaluation indicators are below the first threshold. If yes, proceed to step S702; otherwise, proceed to step S703.

[0185] Step S702: Transmit the complete preprocessed data stream to the cloud platform using the SRT protocol;

[0186] After the edge terminal completes the collection and matrix construction of key indicators such as PCR jitter value, TS packet loss rate, CNR drift slope, and BER change rate, the system first compares each indicator with a first threshold preset by the platform (i.e., the "acceptable fluctuation limit"). If all indicators are lower than the first threshold, it indicates that the current channel state is extremely stable and meets the conditions for high-efficiency, non-redundant, and low-latency data upload. On this basis, the system initiates a complete data upload mechanism based on the SRT (Secure Reliable Transport) protocol.

[0187] Specifically, the SRT protocol is a transport protocol based on UDP, designed specifically for high-throughput, low-latency scenarios such as audio and video transmission. Compared to the traditional TCP protocol, SRT not only inherits the low overhead and real-time performance of UDP, but also ensures high-quality, end-to-end, low-latency streaming media data transmission even in unstable networks through built-in retransmission mechanisms, packet loss repair, flow control, and jitter buffering. In the embodiments of this application, the introduction of SRT enables edge terminals to continuously upload pre-processed data (including RF parameters, TS streams, audio and video streams, etc.) to the cloud in a complete streaming manner, significantly improving the real-time performance and content integrity of alarm responses, making it particularly suitable for all-weather broadcast signal monitoring tasks in urban areas with stable coverage.

[0188] Step S703: Determine whether any evaluation index exceeds the second threshold. If yes, proceed to step S704; otherwise, proceed to step S705.

[0189] Step S704: The preprocessed data is divided into timestamped data blocks and stored in the local cache. At the same time, a breakpoint resume request containing the cache index and verification code is sent to the cloud platform.

[0190] Specifically, in more severe cases, if any indicator in the evaluation matrix exceeds the second threshold, the system determines that the current channel is in a failed or extremely unstable state, and continuing to upload may lead to large-scale data loss or mistransmission. At this point, to ensure data integrity and content traceability, the system enters a disaster recovery-level breakpoint resume preparation state.

[0191] First, the preprocessed data is segmented into data blocks, that is, the continuous preprocessing stream is divided into multiple data blocks with timestamps, type identifiers, and sequence numbers. Each data block will have: a timestamp (precisely marking the start time of data acquisition for this segment), type information (identifying whether the segment is RF, TS, or AV type data); a checksum (used for subsequent transmission to verify data integrity, such as CRC32, SHA1, etc.); and a cache index (used to identify the location of the data block in local storage).

[0192] After data is segmented, all data blocks are temporarily stored in the edge terminal's local cache (such as SSD, eMMC, or memory cache). The terminal then sends a Resume Request to the cloud, including the current cache index, the hash digest of the completed verification blocks, and a suggested future upload window. Once the link is restored, channel quality improves, or a confirmation response is received from the cloud, the system uploads data block by block and verifies data consistency, thus resuming data transmission from the point of link interruption.

[0193] Step S705: Determine whether there is any evaluation index that is higher than the first threshold but lower than the second threshold. If so, proceed to step S706.

[0194] Step S706: Extract the program association table version number, buffer status flag, and abnormal event counter from the transport stream data, generate feature summary data, and upload it to the cloud platform.

[0195] If any indicator in the evaluation matrix exceeds the first threshold, but the overall level remains below the second threshold (which is typically the "fault edge limit"), it indicates that the current channel quality has begun to fluctuate significantly or show an unstable trend, but is not yet completely unusable. In this case, the system should no longer use the full-stream data upload strategy, as bandwidth resources may not be able to support continuous and reliable transmission of all data, potentially causing data congestion or false alarms. Therefore, the system switches to a feature digest upload strategy.

[0196] Specifically, the feature summary data is not a simple sampling, but rather a highly condensed core business field extracted from the TS bitstream and control fields based on the broadcast protocol structure and decoder behavior model. For example: the program association table version number (PAT / PMT version) is used to determine whether the program table has changed, which helps to identify whether it is a channel switching anomaly or content switching; the buffer status flag, derived from the target decoder simulation module, indicates whether the playback system's buffer is on the verge of underflow or overflow; the abnormal event counter, a counter field built based on the identification results of still frames, black screens, audio drops, color bars, etc. in the edge detection logic, is used to reflect the frequency and distribution characteristics of anomalies.

[0197] These fields are aggregated in a structured manner to form an event summary packet, which is transmitted to the cloud with a smaller data volume, achieving data compression (up to 1-5% of the original volume) while retaining sufficient business judgment and alarm capabilities. This mode is suitable for use in weak signal environments, temporarily obstructed areas, or mobile scenarios, ensuring anomaly identification with minimal data overhead.

[0198] In the above implementation, a three-layer dynamic data transmission strategy is introduced based on channel quality assessment to construct an intelligent and adaptive data control mechanism. This control mechanism empowers edge terminals with the ability to adjust in a coordinated manner according to "channel-content-strategy," achieving optimal data accessibility under different channel environments and improving the stability, adaptability, and disaster recovery capabilities of the broadcast television monitoring system. Especially in scenarios with large-scale deployment, complex terrain, and frequent network fluctuations, the three progressive strategies of "SRT direct transmission - digest compression - breakpoint resumption" constitute a complete transmission closed loop from normal monitoring to fault-tolerant recovery, providing crucial technical support for the broadcast television monitoring system to move towards intelligent edge and reliable transmission.

[0199] This application also discloses a broadcast television monitoring system based on cloud-edge collaboration.

[0200] Reference Figure 8 A broadcast television monitoring system based on cloud-edge collaboration, comprising edge terminals, access layer networks, and a cloud platform:

[0201] An edge terminal is used to receive broadcast television signals via dual antennas and perform preprocessing to generate preprocessed data; wherein the dual antennas include a first interface for receiving DTMB signals and a second interface for receiving CDR signals;

[0202] Specifically, the edge terminal is the front-end sensing and primary processing node in this system architecture. It is mainly deployed at monitoring points within the broadcast television signal coverage area to complete the tasks of receiving and preprocessing broadcast signals. Its core feature is the integration of a dual-antenna module, with a first interface and a second interface, dedicated to receiving Terrestrial Digital Multimedia Broadcasting (DTMB) and China Digital Broadcasting (CDR) signals, thereby achieving full coverage reception capability for mainstream broadcasting standards. This dual-interface design not only improves the system's compatibility with heterogeneous broadcasting standards but also ensures the independence and processing stability of multiple signal sources through physical isolation and parallel sampling mechanisms. After signal reception, the edge terminal performs real-time preprocessing of the received broadcast signals through its embedded intermediate frequency demodulation module, signal extractor, and data layering processing unit, generating structured preprocessed data.

[0203] Reference Figure 9 This diagram illustrates a dual-antenna broadcast signal receiving structure based on a USB interface. Connected to the host system via a USB Type-A connector, the internally integrated USB hub splits the signal, connecting two DTMB receiver chips and one CDR receiver chip to achieve parallel reception of terrestrial digital multimedia broadcasting (DTMB) and China Digital Radio (CDR) signals. The two DTMB receiver chips handle the primary and secondary signal channels respectively, optimizing frequency selection and interference suppression through cascaded pre- and post-stage tuners before connecting to a shared antenna for unified signal reception and front-end RF selection. This structure ensures multi-standard signal reception capabilities while improving channel isolation and reception sensitivity, making it suitable for lightweight terminal deployments in multi-mode broadcast monitoring scenarios.

[0204] Access layer network, used to upload pre-processed data to the cloud platform;

[0205] The access layer network, serving as the data transmission channel connecting edge terminals and the cloud platform, acts as a bridge for end-to-end system communication. Its design must balance three key dimensions: network heterogeneity, real-time transmission, and data reliability. Therefore, it supports multiple communication methods, including 4G / 5G cellular networks, WiFi wireless LAN, and wired Ethernet access in some scenarios. To meet the high requirements of real-time performance and data integrity for broadcast monitoring, the system preferentially uses the SRT (Secure Reliable Transport) protocol for data transmission.

[0206] The cloud platform is configured as follows:

[0207] Receive preprocessed data and parse it into radio frequency index data, transport stream data, and audio / video data;

[0208] Perform radio frequency (RF) index analysis on the RF index data to generate RF alarm information;

[0209] Perform bitstream analysis on the transport stream data and generate bitstream alarm information;

[0210] Perform audio and video anomaly identification on audio and video data and generate content alarm information;

[0211] A comprehensive alarm message is generated based on radio frequency alarm information, code stream alarm information, and content alarm information;

[0212] Comprehensive alarm messages are pushed to the user's monitoring terminal via a real-time protocol.

[0213] The cloud platform serves as the centralized analysis and response decision-making core of this system, undertaking the full-process data processing functions of receiving, parsing, analyzing, integrating, and pushing data. Furthermore, the cloud platform integrates equipment management, data visualization, historical data review, and model self-learning functions, forming a smart broadcasting monitoring and control center with long-term evolution capabilities.

[0214] The broadcast television monitoring system of this application embodiment can implement any of the above-described broadcast television monitoring methods, and the specific working process of each module in the broadcast television monitoring system can be referred to the corresponding process in the above-described method embodiments.

[0215] In the several embodiments provided in this application, it should be understood that the provided methods and systems can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for example, the division of a certain module is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed.

[0216] This application also discloses a computer device.

[0217] A computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a broadcast television monitoring method based on cloud-edge collaboration as described above.

[0218] This application also discloses a computer-readable storage medium.

[0219] A computer-readable storage medium storing a computer program that can be loaded by a processor and executed as described above in any of the cloud-edge collaborative broadcast television monitoring methods.

[0220] The computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in connection with an instruction execution system, apparatus, or device; the program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0221] It should be noted that the computer device and storage medium in the embodiments of this application are respectively electronic devices and storage media for applying the above-described broadcast television monitoring method. Therefore, all embodiments of the above-described broadcast television monitoring method are applicable to the computer device and storage medium, and can achieve the same or similar beneficial effects. For the computer device / storage medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple; relevant details can be found in the descriptions of the method embodiments.

[0222] In this invention, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0223] Although the invention has been described herein in conjunction with various embodiments, those skilled in the art will understand and implement other variations of the disclosed embodiments by reviewing the accompanying drawings, disclosure, and appended claims in carrying out the claimed invention. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude a plurality. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0224] The above are all preferred embodiments of this application and are not intended to limit the scope of protection of this application. Any feature disclosed in this specification (including the abstract and drawings) may be replaced by other equivalent or similar features unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is only one example of a series of equivalent or similar features.

Claims

1. A broadcast television monitoring method based on cloud-edge collaboration, characterized in that, The monitoring method includes: The edge terminal receives broadcast television signals via dual antennas; wherein the dual antennas include a first interface for receiving DTMB signals and a second interface for receiving CDR signals. The broadcast television signal is preprocessed at the edge terminal, generating preprocessed data and uploading it to the cloud platform through the access layer network; The system receives pre-processed data on a cloud platform and parses it into radio frequency index data, transport stream data, and audio / video data. Perform radio frequency (RF) index analysis on the RF index data to generate RF alarm information; Perform bitstream analysis on the transport stream data and generate bitstream alarm information; Perform audio and video anomaly identification on audio and video data and generate content alarm information; A comprehensive alarm message is generated based on radio frequency alarm information, code stream alarm information, and content alarm information; The integrated alarm messages are pushed to the user's monitoring terminal via a real-time protocol; The steps for analyzing radio frequency (RF) metrics data and generating RF alarm information include: The radio frequency (RF) index data is decompressed and format parsed to extract the payload data and store it in the RF data cache queue. Load the preset threshold values ​​for the current channel from the configuration library, including carrier-to-noise ratio tolerance, bit error rate threshold, and level range; The radio frequency sampling data in the radio frequency data buffer queue is analyzed in real time, and each item of radio frequency sampling data is compared with the preset threshold value to obtain the comparison result; Based on the comparison results, an alarm event is triggered. The alarm event is subjected to abnormal pattern recognition, the alarm event is classified, and the alarm response mechanism is executed to output radio frequency alarm information. The steps for performing bitstream analysis on transport stream data and generating bitstream alarm information include: PID filtering is performed on the transport stream data to extract valid data packets; Parse the Program Specific Information (PSI) and Service Information (SI) in valid data packets to extract transport stream structure metadata; Perform first-level error detection on the transport stream structure metadata to obtain the first detection result, including whether the alarm for continuous loss of synchronization bytes, program association table update timeout, or program reference clock deviation is triggered. In response to the first detection result being a pass, a second-level error detection is performed on the transport stream structure metadata to obtain a second detection result, including whether a video frame timestamp jump anomaly alarm or a conditional access table update anomaly alarm has been triggered. In response to the second detection result being a pass, a third-level error detection is performed on the transport stream structure metadata to obtain a third detection result, including whether a buffer state abnormality alarm is triggered. Based on the first, second, and third test results, a real-time health score is calculated using preset weights. If the real-time health score is lower than the preset score threshold, a channel quality warning will be triggered and a video playback instruction will be generated, and a bitstream alarm message will be output. The steps for identifying audio and video anomalies in audio and video data and generating content alarm information include: Receive audio and video data, including encoded video and audio streams; The video stream is decoded and converted to the YUV color space to extract luminance component data; Perform black field detection on the luminance component data. When the average luminance value is lower than the set luminance threshold and continues for more than the preset duration, a black field abnormal event is generated. Calculate the structural similarity value for consecutive video frames. When the structural similarity value is continuously higher than the set similarity threshold for a predetermined number of frames, a still frame abnormal event is generated. Pulse code modulation energy detection is performed on the audio stream. When the energy across the entire frequency band remains below a set energy threshold, an audio loss event is generated. The video stream is converted from the RGB color space to the HSV color space, and color bar template matching is performed. When the matching degree exceeds the set threshold, a test signal event is generated. Compare the difference between the display timestamp of the video frame and the timestamp of the audio frame. When the difference exceeds the preset tolerance range, an audio-visual synchronization abnormality event is generated. It aggregates black screen anomaly events, still frame anomaly events, audio loss events, test signal events, and audio-visual synchronization anomaly events, and outputs alarm information.

2. The broadcast television monitoring method based on cloud-edge collaboration according to claim 1, characterized in that, Following the step of receiving broadcast television signals via dual antennas at the edge terminal, the following is also included: Obtain the geographic parameters of the deployment location of the edge terminal; wherein, the geographic parameters include longitude, latitude and altitude data; A three-dimensional grid coordinate model is constructed based on the geographic parameters. The three-dimensional grid coordinate model is then spatially matched with the spectrum map database pre-stored on the cloud platform to extract the expected frequency point set of the target area. The expected frequency point set is traversed by an adaptive frequency point scanning algorithm, and the comprehensive quality score of each frequency point is calculated in real time. The frequency point with the highest overall quality score is identified as the target frequency point. The receiving parameters of the dual antennas are dynamically configured according to the physical characteristics of the target frequency. Real-time acquisition of signal reception quality parameters of the dual antennas after configuration; The signal reception quality parameters are compared spatiotemporally with the historical spectrum data corresponding to the coordinates in the spectrum map to calculate the frequency offset index. When the frequency offset index exceeds the preset frequency offset threshold, the dual-antenna self-calibration process is triggered, the calibrated frequency point parameters are output, and the spectrum map database is updated.

3. The broadcast television monitoring method based on cloud-edge collaboration according to claim 1, characterized in that, Before uploading the preprocessed data to the cloud platform via the access layer network, the process also includes: The preprocessed data is parsed to generate transport stream data; The program clock reference timestamp sequence in the transport stream data is collected in real time, the standard deviation of N consecutive timestamps is calculated, and the PCR jitter value is generated. Monitor the continuity counter difference in the data packet header of the transport stream, calculate the ratio of the number of lost packets to the total number of packets, and generate the TS packet loss rate; The carrier-to-noise ratio (CNR) sequence and bit error rate (BER) of the radio frequency signal are sampled at fixed time intervals. Linear regression analysis is performed on the CNR sequence to output the slope of the CNR drift curve. At the same time, the rate of change of BER between adjacent sampling points is calculated. An evaluation matrix is ​​constructed based on the PCR jitter value, TS packet loss rate, carrier-to-noise ratio drift curve slope, and bit error rate change rate. Based on the comparison results between each evaluation index in the evaluation matrix and the preset index threshold, the data transmission mode is dynamically selected.

4. The broadcast television monitoring method based on cloud-edge collaboration according to claim 3, characterized in that, Based on the comparison results between each evaluation index in the evaluation matrix and the preset index threshold, the data transmission mode is dynamically selected, including: When all evaluation metrics are below the first threshold, the complete preprocessed data stream is transmitted to the cloud platform using the SRT protocol. When any evaluation metric is higher than the first threshold but lower than the second threshold, the program association table version number, buffer status flag and abnormal event counter in the transport stream data are extracted, feature summary data is generated and uploaded to the cloud platform. When any evaluation metric exceeds the second threshold, the preprocessed data is split into timestamped data blocks and stored in the local cache. At the same time, a breakpoint resume request containing the cache index and verification code is sent to the cloud platform.

5. A broadcast television monitoring system based on cloud-edge collaboration, characterized in that, The monitoring system includes edge terminals, an access layer network, and a cloud platform. The edge terminal is used to receive broadcast television signals via dual antennas and perform preprocessing to generate preprocessed data; wherein the dual antennas include a first interface for receiving DTMB signals and a second interface for receiving CDR signals; The access layer network is used to upload the preprocessed data to the cloud platform; The cloud platform is configured as follows: Receive preprocessed data and parse it into radio frequency index data, transport stream data, and audio / video data; Perform radio frequency (RF) index analysis on the RF index data to generate RF alarm information; Perform bitstream analysis on the transport stream data and generate bitstream alarm information; Perform audio and video anomaly identification on audio and video data and generate content alarm information; A comprehensive alarm message is generated based on radio frequency alarm information, code stream alarm information, and content alarm information; The integrated alarm messages are pushed to the user's monitoring terminal via a real-time protocol; The steps for analyzing radio frequency (RF) metrics data and generating RF alarm information include: The radio frequency (RF) index data is decompressed and format parsed to extract the payload data and store it in the RF data cache queue. Load the preset threshold values ​​for the current channel from the configuration library, including carrier-to-noise ratio tolerance, bit error rate threshold, and level range; The radio frequency sampling data in the radio frequency data buffer queue is analyzed in real time, and each item of radio frequency sampling data is compared with the preset threshold value to obtain the comparison result; Based on the comparison results, an alarm event is triggered. The alarm event is subjected to abnormal pattern recognition, the alarm event is classified, and the alarm response mechanism is executed to output radio frequency alarm information. The steps for performing bitstream analysis on transport stream data and generating bitstream alarm information include: PID filtering is performed on the transport stream data to extract valid data packets; Parse the Program Specific Information (PSI) and Service Information (SI) in valid data packets to extract transport stream structure metadata; Perform first-level error detection on the transport stream structure metadata to obtain the first detection result, including whether the alarm for continuous loss of synchronization bytes, program association table update timeout, or program reference clock deviation is triggered. In response to the first detection result being a pass, a second-level error detection is performed on the transport stream structure metadata to obtain a second detection result, including whether a video frame timestamp jump anomaly alarm or a conditional access table update anomaly alarm has been triggered. In response to the second detection result being a pass, a third-level error detection is performed on the transport stream structure metadata to obtain a third detection result, including whether a buffer state abnormality alarm is triggered. Based on the first, second, and third test results, a real-time health score is calculated using preset weights. If the real-time health score is lower than the preset score threshold, a channel quality warning will be triggered and a video playback instruction will be generated, and a bitstream alarm message will be output. The steps for identifying audio and video anomalies in audio and video data and generating content alarm information include: Receive audio and video data, including encoded video and audio streams; The video stream is decoded and converted to the YUV color space to extract luminance component data; Perform black field detection on the luminance component data. When the average luminance value is lower than the set luminance threshold and continues for more than the preset duration, a black field abnormal event is generated. Calculate the structural similarity value for consecutive video frames. When the structural similarity value is continuously higher than the set similarity threshold for a predetermined number of frames, a still frame abnormal event is generated. Pulse code modulation energy detection is performed on the audio stream. When the energy across the entire frequency band remains below a set energy threshold, an audio loss event is generated. The video stream is converted from the RGB color space to the HSV color space, and color bar template matching is performed. When the matching degree exceeds the set threshold, a test signal event is generated. Compare the difference between the display timestamp of the video frame and the timestamp of the audio frame. When the difference exceeds the preset tolerance range, an audio-visual synchronization abnormality event is generated. It aggregates black screen anomaly events, still frame anomaly events, audio loss events, test signal events, and audio-visual synchronization anomaly events, and outputs alarm information.

6. A computer device, characterized in that: It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method as described in any one of claims 1 to 4.

7. A computer-readable storage medium, characterized in that: The computer program is stored that can be loaded by a processor and executed as described in any one of claims 1 to 4.

Images