IPTV (Internet Protocol Television) video encapsulation verification method

Abstract

The invention relates to an IPTV (Internet Protocol Television) video encapsulation verification method. The method comprises the following steps of: directly accessing and analyzing IPTV on-demand program transport stream TS (Transport Stream) data in an online storage system; analyzing a plurality of transmission packets in the TS data in sequence; based on a preset verification rule set, packaging normativity verification is carried out on the parsed field; wherein if a predefined type of packaging error is identified in the analysis process, the subsequent verification process of the current program source is immediately interrupted. The predefined type of packaging error comprises at least one of a synchronous byte error and a secondary error defined according to the ETSI TR101290 standard. According to the method, by introducing an online detection and error interruption mechanism, efficient and automatic verification of massive video files is realized, the packaging problem can be quickly positioned without completely traversing the files, the detection efficiency is effectively improved, the method can be integrated with an existing service system, the program state is automatically managed, and the risk of manual operation is reduced.

Description

Technical Field

[0001] This invention relates to the field of detection technology for video file specifications of IPTV on-demand programs, specifically to an IPTV video encapsulation verification method. Background Technology

[0002] In IPTV on-demand services, program sources generally use the TS (Transport Stream) encapsulation format. However, some source encapsulation formats have non-standard parameters, specifically manifested as encapsulation layer errors such as missing video synchronization bytes and consecutive counting errors. These problems directly affect the broadcast quality of the program, resulting in phenomena such as black screens, still frames, mosaic effects, or audio-video desynchronization.

[0003] Currently, the detection of such TS stream encapsulation errors typically relies on standalone offline detection tools such as easyIce. These tools are designed for users to manually inspect local video files, and their working mode is to perform a complete, end-to-end analysis of a single file. This design pattern dictates that they are standalone offline tools and lack the capability to interface with online business systems.

[0004] The shortcomings of existing technology are:

[0005] 1. Low detection efficiency, unable to meet the needs of large-scale operations: Because existing tools are designed to comprehensively assess file quality, their detection process must traverse the entire file and cannot be immediately interrupted when errors are detected. Given the extremely large amount of programs that the IPTV platform needs to process, this full-scale detection method is too inefficient and not feasible for practical application.

[0006] 2. Outdated operating model, unable to integrate into online business processes: Existing detection tools are limited to manual offline operation and cannot automate the detection of online stored program files in a way that integrates with business flows. This prevents business departments from timely and efficiently identifying problems in incremental programs, affecting the efficiency and quality of content scheduling and product operation.

[0007] 3. Lack of systematic management in the detection process: Existing technical solutions are isolated tools; their detection results cannot be automatically recorded or statistically analyzed, nor can they be linked with the program status management system, posing a risk of problematic programs being uploaded due to human error. The functional positioning of existing tools inherently lacks the ability to integrate with business processes.

[0008] In summary, existing technologies cannot provide a video encapsulation verification solution that can be integrated online, efficiently, and automatically into IPTV service systems.

[0009] The information disclosed in this background section is intended only to enhance the understanding of the general background of the invention and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention

[0010] To address the shortcomings of existing technologies, the present invention aims to provide an IPTV video encapsulation verification method. This method addresses the problem that existing technologies cannot efficiently and automatically encapsulate and verify video files of online-stored IPTV on-demand programs, thereby enabling rapid identification of video file encapsulation errors and effective integration with business systems, and improving the efficiency and automation level of video quality detection.

[0011] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0012] A method for verifying IPTV video encapsulation, the method comprising:

[0013] Directly access and parse IPTV on-demand program transport stream (TS) data in the online storage system;

[0014] The multiple transmission packets in the TS data are parsed sequentially;

[0015] Based on a pre-defined set of validation rules, the parsed fields are encapsulated and validated for compliance.

[0016] If a predefined type of encapsulation error is identified during the parsing process, the subsequent verification process for the current program source is immediately interrupted.

[0017] Based on the above technical solution, the predefined types of encapsulation errors include synchronization byte errors; and

[0018] Before verifying other fields, the method prioritizes verifying the synchronization byte field at the beginning of each transmission packet.

[0019] Based on the above technical solution, the predefined type of encapsulation error includes level 2 errors as defined in accordance with the ETSI TR101290 standard.

[0020] Based on the above technical solution, the secondary errors include program clock reference PCR interval errors and display timestamp (PTS) errors.

[0021] Based on the above technical solution, the step of sequentially parsing multiple transmission packets in TS data includes identifying empty packets;

[0022] When a transport packet with packet identifier PID of 0x1FFF is detected, the verification of that transport packet is skipped.

[0023] Based on the above technical solution, the method further includes the step of parsing the Program Association Table (PAT).

[0024] The steps for parsing the Program Association Table (PAT) include: directly obtaining the packet identifier Program_map_PID of the Program Mapping Table from the PAT payload.

[0025] Based on the above technical solution, the method adopts a layered verification process, including:

[0026] First, verify the synchronization bytes of each transmission packet;

[0027] If the synchronization bytes are correct, then the program association table PAT and the program mapping table PMT are parsed and verified.

[0028] If PAT and PMT are parsed correctly, then at least one parameter that affects the timing of audio and video playback is checked.

[0029] Based on the above technical solution, the parameters affecting the timing of audio and video playback include the Program Clock Reference PCR interval or the Display Timestamp (PTS).

[0030] Based on the above technical solution, the method further includes:

[0031] The verification results are associated with and recorded in relation to the program source status;

[0032] Based on the verification results, the availability status of the program source is automatically set.

[0033] Based on the above technical solution, the method skips the verification of the continuity counter when the adaptation_field_control field is 0x00 or 0x10 during the parsing of the transmission packet.

[0034] The IPTV video encapsulation verification method described in this invention is used to perform encapsulation specification verification on the TS transport stream of online stored IPTV on-demand programs. By parsing key fields in the TS packet header and payload, and combining error judgment rules based on the ETSITR101290 standard and optimized for on-demand services, it achieves rapid identification of encapsulation errors and interruption control in the detection process, effectively improving verification efficiency and automation. It has the following beneficial effects:

[0035] 1. It enables direct automated detection of online stored programs, eliminating the need to download video files to the local machine for verification. It can automatically detect incremental programs, overcoming the limitations of existing offline tools that require manual operation and cannot be integrated into business processes.

[0036] This achievement is built upon a fundamental innovation in the methodological architecture. The core technical principle lies in bringing the detection process forward and deeply coupling it with the business system. Specifically, the method eliminates the time-consuming and resource-intensive step of downloading massive amounts of data locally by directly accessing and parsing program source files in the online storage system. More importantly, the method embeds automated interface logic between the detection results and the program status management system. Once verification is complete, the system automatically associates the result (such as "pass" or "specific error type") with the corresponding program metadata and drives the business system to update the program's availability status (such as setting it to "banned"). This process achieves full automation from "detection" to "handling," forming a closed-loop quality control system, thereby freeing human resources from tedious manual operations.

[0037] 2. It adopts a selective verification and error interruption mechanism, which eliminates the need for complete inspection of program files. Once an encapsulation error is detected, the verification process of the current file can be terminated, which significantly reduces unnecessary consumption of computing resources. It is particularly suitable for the scenario of rapid quality screening of massive programs on IPTV platforms.

[0038] The core principle behind this effect lies in introducing a "fail-fast" mechanism and implementing a "precision strike" strategy to minimize unnecessary computation. The "fail-fast" mechanism is manifested in the fact that the verification process is designed to immediately terminate all subsequent operations on the current file once a critical error is identified in any data packet. This avoids continuing to invest computational resources in files with known problems, significantly shortening the time required to determine problematic files.

[0039] The aforementioned "precision strike" strategy is reflected on multiple levels:

[0040] Precise targeting: The method does not verify all errors in the standard, but focuses on the core subset of errors (such as synchronization bytes, PCR interval, PTS, etc.) that are most likely to affect the playback experience, based on the characteristics of the on-demand service and the performance of the terminal.

[0041] Precise targeting: The method intelligently identifies and skips empty packets that do not carry media information, reducing the total number of data packets to be processed.

[0042] Logically precise: The method follows the transport stream protocol specification. When specific adaptation field control characters are parsed, the validation of fields such as continuity counters is conditionally skipped, avoiding unnecessary calculations when the specification allows.

[0043] These three factors combined ensure that computing resources are used efficiently where problems are most likely to be discovered.

[0044] 3. It can be seamlessly integrated with existing business systems to achieve automated recording, statistics and status management of video encapsulation verification results, providing decision-making basis for program scheduling and release, and effectively reducing the risk of problematic programs being launched due to human error.

[0045] The principle behind this effect lies in elevating the verification method from an independent "tool" to an integrated "service." The method no longer outputs an isolated report requiring manual interpretation, but rather structured status instructions that can be directly consumed by business systems. By seamlessly embedding the verification process into the pre-program launch workflow and automatically executing the series of actions—"verification-recording-decision-status setting"—the manual intervention between technical judgment and business operations is completely eliminated. This system-level automated linkage fundamentally eliminates quality risks caused by human negligence, delays, or misjudgments, achieving a hard constraint of technical assurance on the business process.

[0046] 4. By prioritizing the detection of basic fields such as synchronization bytes and optimizing the verification process for critical secondary errors such as PCR interval errors and PTS errors, this method can achieve a high detection rate of encapsulation problems with low computational resource overhead, balancing detection accuracy and system performance.

[0047] This effect relies on a layered, progressive intelligent filtering strategy, which prioritizes low-overhead checks to eliminate problems while ensuring a high detection rate.

[0048] First layer: Basic integrity check: The method first verifies the synchronization byte at the beginning of each transmission packet with extremely low computational cost. The synchronization byte is the cornerstone of correct data stream parsing. This step can quickly detect serious file corruption caused by data loss or misalignment, filtering out a large number of problematic files at minimal cost.

[0049] Layer 2: Efficient Metadata Parsing: When parsing key metadata such as the Program Association Table (PAT) and Program Map Table (PMT), the method employs an optimized parsing algorithm. For example, by directly locating and obtaining key identifiers (program_map_PID, elementary_PID), instead of fully parsing and traversing all entries, the complexity of protocol parsing is significantly reduced.

[0050] The third layer: Core business logic verification: Ultimately, the method concentrates resources on verifying parameters that have the most direct and sensitive impact on the end-user experience, such as the PCR interval and PTS to ensure playback sequence. This focus ensures that limited computing power is invested in the key points that best guarantee broadcast quality.

[0051] Through this process design that progresses from simple to complex and from basic to core, the method ensures that most common errors can be captured with a high probability in the early stages of detection, thus achieving a balance between low resource consumption and high problem detection rate in a systematic way. Attached Figure Description

[0052] The present invention includes the following figures:

[0053] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein:

[0054] Figure 1 A flowchart illustrating the IPTV video encapsulation verification method described in this invention.

[0055] Figure 2 Error rating standards defined by ETSI TR101290. Detailed Implementation

[0056] The present invention will be further described in detail below with reference to the accompanying drawings. This detailed description is an illustration in conjunction with exemplary embodiments of the invention, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0057] The ETSI TR101290 mentioned in this invention is a test specification for transport streams (TS) of digital video broadcasting (DVB) systems published by the European Telecommunications Standards Institute (ETSI). Its full name is "ETSI TR 101 290 - Digital Video Broadcasting (DVB); Measurement guidelines for DVB systems".

[0058] The ETSI TR101290 monitors three levels of errors. Based on the requirements of IPTV operators' set-top box players and the characteristics of on-demand programs, Level 1 errors do not require PID error verification (no verification needed). Level 2 errors only require checking PCR interval errors and PTS errors; detection can be interrupted whenever an error is encountered, reducing unnecessary work and improving verification efficiency. Level 3 errors have no impact on broadcast quality, and are not verified in this invention.

[0059] The ISO / IEC 13818-1:2000 (E) mentioned in this invention is the legal specification for IPTV TS stream encapsulation. All verification logic in this invention (from TS packet structure and field parsing to error classification) is based solely on this standard.

[0060] The implementation of the method of this invention is based on two pillars:

[0061] First, the TS packaging requirements defined by the international standard ISO / IEC 13818-1:2000(E);

[0062] Secondly, the industry-recognized error rating standard defined by ETSI TR101290, such as... Figure 2 As shown.

[0063] This invention is achieved through Figure 1 The optimized detection process shown combines the two pillars to achieve efficient verification of online TS streams.

[0064] This invention comprises three interconnected core concepts. They follow a clear technological logic sequence and together constitute the complete solution of this invention. Specifically:

[0065] Core Concept 1: Change the basic testing model – from “offline manual” to “online automation”.

[0066] This is the premise and foundation of all improvements. The fundamental limitation of existing technology lies in its operating mode: it is a manual, offline, and standalone tool. The primary core concept of this invention is to completely change this mode, upgrading the detection function from a "tool" to a "service." This means that the method is designed to directly access and parse video files on online storage systems, thus inherently possessing the ability to integrate with business processes. Without this step, all subsequent efficiency improvements are meaningless.

[0067] Core Concept Two: Optimize the detection process – from “full traversal” to “rapid screening”.

[0068] After achieving online automation, the next challenge is "how to execute it efficiently." Existing technologies perform indiscriminate, complete scanning of files. The second core concept of this invention is to introduce an intelligent filtering and interruption mechanism, which is implemented on two levels:

[0069] 1. Layered filtering: such as Figure 1As shown, the verification process is designed with a layered structure, progressing from shallow to deep. First, the lowest-cost checks (such as synchronization bytes) quickly filter out most severely corrupted files. Only those that pass are subjected to more complex and costly parsing (such as PAT / PMT). Finally, core business parameters (such as PCR / PTS) are verified. This ensures that computing resources are used effectively.

[0070] 2. Rapid Interruption: At any level in the process, once a predefined critical error is detected, all subsequent checks are immediately terminated. This avoids wasting any additional computing resources on known "bad files".

[0071] Core Concept Three: Achieving Closed-Loop Management of Test Results – From “Isolated Reports” to “State-Driven”.

[0072] This is crucial for realizing the ultimate business value. If the test results are merely isolated reports, requiring manual searching, interpretation, and operation of the business system, neither efficiency nor accuracy can be guaranteed. The third core concept of this invention is to automate the status linkage between technical test results and the business management system. This method automatically binds the verification result (pass / error type) to the status of the program source and drives the business system to automatically update that status (e.g., setting it to "banned"). This forms an automated closed loop from "detection" to "handling," completely eliminating human error and truly allowing the business department to "focus on content arrangement and product operation."

[0073] These three core concepts form a complete logical chain: first, changing "where to do it" (online); then, solving "how to do it efficiently" (layered interruption); and finally, achieving "what is the use of doing it" (business closed loop). They progress step by step, jointly ensuring the realization of the technical effects and commercial value of this invention.

[0074] like Figure 1 As shown, the IPTV video encapsulation verification method of the present invention includes:

[0075] 1. Basic analysis basis: Transmission packet syntax structure

[0076] This method strictly adheres to the ISO / IEC 13818-1 standard in parsing all transmission packets and their fields. For example... Figure 1 As shown, each TS transport packet is 188 bytes long and consists of a header and a payload. Parsing is the foundation of the entire verification process, and its core lies in accurately extracting the values ​​of specific fields from the binary stream according to the standard syntax diagram and related instructions.

[0077] According to ISO / IEC 13818-1:2000(E), each data packet in a TS file is 188 bytes long (transportStream packets are 188 bytes in length.), and each data packet has an independent header. Syntax analysis can be performed based on the detailed structure of each data packet to parse out the values ​​of the required fields. Figure 1 As can be seen from the given syntax structure table, the 188-word data packet is divided into a header and a payload. The focus of this invention is parsing the header. Specifically, it includes:

[0078] Packet parsing and load locating.

[0079] After reading a 188-byte transmission packet, the system needs to parse it to locate the valid payload data, which is the basis for subsequent encapsulation and verification.

[0080] First, the first four bytes of the transmitted packet constitute the packet header. During the parsing process of this invention, a buffer is defined, whose initial content is the remaining portion of the transmitted packet after removing the first four bytes of the header.

[0081] The exact location of the load data needs to be dynamically determined based on the following two fields:

[0082] 1. Payload start indicator: When the transport packet type is PSI (Program Specific Information), if the value of Payload_unit_start_indicator is 1, it means that the starting position of the payload needs to be offset by one byte from the buff; if its value is 0, the buff remains unchanged.

[0083] 2. Adaptation Field Control: This field determines the data structure following the header, and its processing rules are as follows:

[0084] If the value of adaptation_field_control is 0x00, it means that this package is reserved for future use by the ISO / IEC standard and will not be parsed.

[0085] If its value is 0x01, it means that the packet only contains the payload and has no adaptation field, so the buff remains unchanged.

[0086] If its value is 0x10, it means that the packet only contains adaptation fields and has no payload, so the payload of the packet is not parsed.

[0087] If its value is 0x11, it means that the adaptation field is immediately followed by the payload. In this case, the value of `adaptation_field_length` needs to be read from the current buff, and then the buff needs to be shifted backward by the length specified by `[adaptation_field_length]` to skip the adaptation field and locate the beginning of the payload. It should be noted that the `adaptation_field_control` field itself occupies one byte in the packet.

[0088] After successfully locating the payload data, the system parses the key fields in the transmission packet according to the ISO / IEC 13818-1 standard syntax, as follows:

[0089] (1) Synchronous byte parsing

[0090] The synchronization byte is located at the beginning of the packet header, occupying the first byte (i.e., 8 bits starting from the first bit). During parsing, the value of this byte is directly read and verified. This is the starting point for correct parsing of the packet, and its verification has the highest priority.

[0091] (2) Packet identifier resolution

[0092] A packet identifier is used to uniquely identify the type of stream carried by a transport packet. (See reference...) Figure 1 The syntax structure shown indicates that the PID is composed of the lower 5 bits of the second byte and the third byte of the packet header. Therefore, PID parsing is achieved through the following bitwise operations:

[0093] PID = (buff[1] & 0x1F) << 8 | buff[2]

[0094] The & 0x1F operation is used to obtain the last 5 bits of the second byte, and the << 8 operation is used to shift it left to the high byte, and then perform an OR operation with the third byte buff[2] to finally combine them into a complete 13-bit PID value. This is the key to identifying empty packets, PAT packets, PMT packets and audio / video packets.

[0095] (3) Adaptation field control and continuous counter parsing

[0096] The Adaptation Field Control and the Continuity Counter are core fields for determining the payload status of the transmission packet and controlling the counting logic. They are both located in the 4th byte of the transmission packet header. The specific parsing method is as follows:

[0097] The parsing method for the adaptation field control is: adaptation_field_control = buff[3] >> 4 &0x03.

[0098] Among them, the buff[3] >> 4 operation shifts the 4th byte 4 bits to the right, moving its high 4 bits to the low 4 bits;

[0099] Subsequently, the & 0x03 operation (0011 in binary) is used to extract the lowest two bits of the above result, thereby obtaining a 2-bit value for the adaptation_field_control field. This field determines the data structure after the packet header (i.e., whether there is an adaptation field and / or payload), and is the basis for the judgment in the aforementioned "load location" step.

[0100] The parsing method for the continuity counter is: continuity_counter = buff[3] & 0x0F.

[0101] The & 0x0F operation (00001111 in binary) is used to directly obtain the lowest 4 bits of the 4th byte, thus obtaining a 4-bit value for the continuity_counter field. This field is used to detect whether there are packet losses or packet reordering errors in the sequence of transport packets with the same PID.

[0102] (4) Program clock reference analysis

[0103] The program clock reference is used for system time clock recovery in the decoder and is crucial for ensuring audio and video synchronization. The PCR field is located in the adaptation field of the transport packet payload and exists when PCR_flag is 1.

[0104] PCR consists of a 33-bit main value PCR_base and a 9-bit extension value PCR_extension, which need to be parsed step by step and then combined for calculation.

[0105] The PCR_base parsing method is as follows:

[0106] $PCR_base = intval(bin2hex(substr($buff,6,4)),16) << 1 | intval(intval(bin2hex($buff

[10] ),16) & 0x80,16) >> 7;

[0107] Where $buff is the transport stream data packet buffer, which stores the original data of the entire 188-byte TS packet; substr($buff,6,4) is the 4 bytes continuously extracted starting from the 6th byte of the buffer; $buff

[10] is the 10th byte in the buffer; & 0x80 is the bitwise AND operation, used to extract the highest bit of a byte; << 1 is left shift by 1 bit; >> 7 is right shift by 7 bits; | is the bitwise OR operation, used to concatenate the 32-bit value after left shift and the 1-bit value extracted from the 10th byte together to form a complete 33-bit PCR_base; the formula concatenates the 32-bit data from 4 bytes and the 1-bit data from 5 bytes into a complete 33-bit PCR_base value.

[0108] The method for parsing PCR_extension is as follows:

[0109] $PCR_extension = intval(intval(bin2hex($buff

[10] ),16) & 0x01,16) << 8| intval(bin2hex($buff

[11] ),16);

[0110] Where $buff is the transport stream data packet buffer, which stores the original data of the entire 188-byte TS packet; $buff

[10] is the 10th byte in the buffer, which contains the highest bit of PCR_base and the highest bit of PCR_extension; & 0x01 is a bitwise AND operation, used to extract the lowest bit of a byte; $buff

[11] is the 11th byte in the buffer, which contains the lower 8 bits of PCR_extension; << 8 is a left shift of 8 bits, which will promote the 1 bit value extracted in the previous step to the highest bit of the 9-bit value; | is a bitwise OR operation, which is used to concatenate the left-shifted 1 bit value and the 8 bits extracted from the 11th byte together to form a complete 9-bit PCR_extension value; the lowest 1 bit data from the 10th byte and the 8 bits data from the 11th byte are concatenated into a complete 9-bit PCR_extension value through this formula.

[0111] The final PCR value is calculated using the formula PCR = intval($PCR_base * 300) + intval($PCR_extension). Here, $PCR_base is the 33-bit program clock reference base value obtained through the "PCR_base parsing method," with units of 90kHz clock cycles. * 300 is a multiplication operation, where the multiplier 300 is a unit conversion factor used to convert the PCR_base value based on a 90kHz clock cycle to a value based on a 27MHz clock cycle, since 27MHz / 90kHz = 300. $PCR_extension is the 9-bit program clock reference extension value obtained through the "PCR_extension parsing method," with units directly in 27MHz clock cycles. + is an addition operation used to add the unit-converted base timestamp to the high-precision extended timestamp, resulting in a complete final PCR value in 27MHz clock cycles. This final PCR value serves as the decoder's synchronization time base for synchronized audio and video playback.

[0112] (5) Display timestamp parsing

[0113] Display timestamps are used to determine the precise decoding and display time of video or audio frames. PTS is located in the header of the PES packet payload.

[0114] When the PTS_DTS_flags in the PES header indicates the presence of a PTS (a value of 10 or 11), the PTS can be parsed. PTS parsing is achieved through the following bitwise operations:

[0115] PTS = (PTS1 & 0x0E) << 29 | (PTS2 & 0xFFFE) << 14 | (PTS3 & 0xFFFE) >> 1;

[0116] PTS1, PTS2, and PTS3 are three bytes read consecutively from the PES header.

[0117] (PTS1 & 0x0E) << 29: The 0x0E (binary 00001110) mask is used to extract the 2nd to 4th bits (3 bits in total) from the high-order bits of the PTS1 byte, and then shift it left by 29 bits to obtain the highest 3 bits of the 33-bit PTS value.

[0118] The (PTS2 & 0xFFFE) << 14: The 0xFFFE (binary 1111111111111110) mask is used to extract 15 bits (excluding the least significant bit) from the PTS2 word (2 bytes) and shift it left by 14 bits to obtain the middle part of the PTS value.

[0119] (PTS3 & 0xFFFE) >> 1: The 0xFFFE mask is also used to extract 15 bits from the PTS3 word excluding the least significant bit, and then shift it right by 1 bit to obtain the least significant part of the PTS value.

[0120] Finally, these three parts are combined into a complete 33-bit PTS value through an OR operation.

[0121] (6) Analysis of program association table and program mapping table

[0122] The program association table and program mapping table provide global navigation information for programs and are the basis for locating audio and video streams.

[0123] PAT parsing: When the PID of a transport packet is 0x0000, the packet carries a PAT. To improve parsing efficiency, this method does not completely parse `section_length` and traverse the entire table; instead, it directly locates the first program item and obtains the `program_map_PID`. Specifically:

[0124] program_map_PID = (buff

[10] & 0x1F) << 8 | buff

[11] ;

[0125] (buff

[10] & 0x1F) << 8: Take the lower 5 bits (0x1F mask) of the 11th byte in the PAT table payload, and shift it left by 8 bits to get the high byte.

[0126] | buff

[11] : Perform an OR operation with the 12th byte and use it as the low byte.

[0127] This operation directly retrieves the transport packet PID value mapped to the program mapping table.

[0128] PMT parsing: Locate the PMT table based on the program_map_PID obtained from PAT. The following fields need to be parsed sequentially to traverse all basic flows:

[0129] section_length = (buff[1] & 0x0F) << 8 | buff[2]; / / Get the length of the PMT segment, and take the lower 4 bits of the second byte of the 0x0F mask.

[0130] program_info_length = (buff

[10] & 0x0F) << 8 | buff

[11] ; / / Get the length of the program description information.

[0131] Set the initial position pos = 12 + program_info_length, skip the basic description information, and locate the beginning of the first basic flow loop.

[0132] For each basic stream, perform loop parsing:

[0133] elementary_PID = (buff[pos+1] & 0x1F) << 8 | buff[pos+2]; / / Get the PID of the elementary stream.

[0134] ES_info_length = (buff[pos+3] & 0x0F) << 8 | buff[pos+4]; / / Get the length of the basic stream description information.

[0135] pos += 5 + ES_info_length; / / Move the position pointer, skip the information in the current stream, and prepare to parse the next elementary stream.

[0136] This loop will yield a list of PIDs for all audio and video elementary streams contained in the program.

[0137] 2. Complete verification workflow

[0138] After completing the construction of parsing capabilities for all the aforementioned key fields, this method follows... Figure 1 The flowchart shown demonstrates efficient and automated encapsulation and verification of online transport streams.

[0139] It should be noted that this method does not verify all errors in the ETSI TR101290 standard, but rather selects errors specifically based on the characteristics of IPTV on-demand services and the actual fault tolerance capabilities of set-top box players. Figure 2 As shown, the error level table in the standard:

[0140] In the first-level error, the check for PID errors was excluded because on-demand program sources usually do not have PID conflict or incorrect mapping issues.

[0141] Among the level 2 errors, the focus is on verifying PCR interval errors and PTS errors, which have the most direct impact on the user experience of on-demand services, to ensure audio and video synchronization and smooth playback.

[0142] Based on this optimization strategy, the complete workflow of this method is as follows:

[0143] (1) Access the online data source and initialize it.

[0144] The system receives the program source identifier to be verified, directly accesses the online storage system, opens the corresponding transport stream file, and initializes the verification status. This step is fundamental to achieving "online automated" detection.

[0145] (2) Read the transmission packet and verify the synchronization byte (first layer of filtering).

[0146] Read a 188-byte transport packet sequentially from the stream. First, parse and verify its synchronization bytes.

[0147] Judgment and Action: If the synchronization byte value is incorrect, it is immediately judged as "synchronization loss error", interrupting all subsequent checks on the current program source and jumping to step (8) for result processing.

[0148] This step, as the first layer of layered verification, can quickly detect serious streaming errors caused by data loss with minimal computational cost, achieving fast failure.

[0149] (3) Parse the PID and identify empty packets.

[0150] Parse the packet identifier (PID) of the transport packet.

[0151] Judgment and Action: If the parsed PID == 0x1FFF, then the packet is determined to be empty. The system will skip all subsequent checks on this packet and directly return to step (2) to read the next transmission packet.

[0152] By identifying and skipping empty packets that do not carry media information, the total amount of data to be processed is reduced, thus improving the overall verification efficiency.

[0153] (4) Parse program mapping information (PAT and PMT).

[0154] This step aims to obtain the overall structure information of the program, laying the foundation for subsequent verification of audio and video streams.

[0155] Judgment and Action: If the PID of the current packet is 0x0000, the PAT parsing method is called to quickly obtain the program_map_PID. The system then listens for this program_map_PID, and when the corresponding transmission packet is received, the PMT parsing method is called to parse out the list of elementary_PIDs for all audio and video elementary streams in the program.

[0156] By optimizing the parsing strategy (such as directly locating program_map_PID in PAT parsing), the program stream mapping relationship was quickly established, avoiding unnecessary full table traversal.

[0157] (5) Verify critical secondary errors (second layer filtering).

[0158] This step performs a deep check on the transport packets carrying the audio and video basic streams (i.e., their PIDs are obtained in the elementary_PID list in step (4)).

[0159] PCR interval verification: If the PCR_flag in the adaptation field is found to be 1, then the PCR value is parsed. The system calculates the interval between the current PCR value and the previous PCR value.

[0160] Judgment and Action: If the interval exceeds the preset threshold (e.g., 100 milliseconds), it is judged as "PCR interval error", the detection is immediately interrupted and the process jumps to step (8).

[0161] PTS verification: In the PES packet layer, if PTS_DTS_flags indicates the existence of a PTS, the PTS value is parsed. The system verifies the continuity and reasonableness of the PTS value.

[0162] Judgment and Action: If the current PTS value is not monotonically increasing or there is an abnormal jump, it is judged as "PTS error", the detection is immediately interrupted and the process jumps to step (8).

[0163] Focusing on the core parameters that have the most direct impact on the end-user experience (audio-video synchronization and playback smoothness), it achieves accurate and efficient deep verification, and immediately stops once a problem is detected to avoid invalid calculations.

[0164] (6) Verify the continuity counter.

[0165] For all valid non-empty packets, parse their adaptation_field_control and continuity_counter fields.

[0166] Judgment and Action: Based on the standard specifications and the state of the discontinuity_indicator, determine whether the continuity counter is correct. If discontinuity is found, it is judged as "continuity counting error".

[0167] Action: Immediately interrupt the detection and jump to step (8).

[0168] Ensure the integrity of the transmission process and detect any packet loss.

[0169] (7) Loop and termination judgment.

[0170] Judgment and Action: If the process is not interrupted by an error, determine whether the end of the file has been reached. If the end has not been reached, return to step (2) to continue processing the next packet; if the end has been reached and no error is found, generate a "verification passed" result.

[0171] It ensures complete traversal of error-free files and cyclical control of the entire verification process.

[0172] (8) Integrate the generated results with business operations (closed-loop management).

[0173] This step is the final step in realizing the business value of the technical solution, completing the automated closed-loop management of the test results.

[0174] Result generation: Regardless of whether the process is interrupted by an error or ends normally, the system will generate a structured verification result, which includes at least the program identifier, the final conclusion (pass / fail), and the specific error type.

[0175] Business integration: The system automatically associates the verification result with the metadata of the program source and records it. Based on this result, the business system automatically updates the availability status of the program source (for example, setting programs with errors to "banned" and programs that pass verification to "available").

[0176] This has created a fully automated closed loop from "technical testing" to "business processing," completely eliminating the risks of delays, omissions, or misoperations that may be caused by manual intervention, allowing business departments to focus on content arrangement and operation.

[0177] The contents not described in detail in this specification are existing technologies known to those skilled in the art.

[0178] The above description is only a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. Any equivalent modifications or changes made by those skilled in the art based on the content disclosed in the present invention should be included in the scope of protection set forth in the claims.

Claims

1. A method for verifying IPTV video encapsulation, characterized in that, The method includes: Directly access and parse IPTV on-demand program transport stream (TS) data in the online storage system; The multiple transmission packets in the TS data are parsed sequentially; Based on a pre-defined set of validation rules, the parsed fields are encapsulated and validated for compliance. If a predefined type of encapsulation error is identified during the parsing process, the subsequent verification process for the current program source is immediately interrupted.

2. The IPTV video encapsulation verification method as described in claim 1, characterized in that, The predefined types of encapsulation errors include synchronization byte errors; and Before verifying other fields, the method prioritizes verifying the synchronization byte field at the beginning of each transmission packet.

3. The IPTV video encapsulation verification method as described in claim 1, characterized in that, The predefined types of encapsulation errors include Level 2 errors as defined in accordance with the ETSI TR101290 standard.

4. The IPTV video encapsulation verification method as described in claim 3, characterized in that, The level 2 errors include program clock reference PCR interval errors and display timestamp (PTS) errors.

5. The IPTV video encapsulation verification method as described in claim 1, characterized in that, The step of sequentially parsing multiple transmission packets in TS data includes identifying empty packets; When a transport packet with packet identifier PID of 0x1FFF is detected, the verification of that transport packet is skipped.

6. The IPTV video encapsulation verification method as described in claim 1, characterized in that, The method also includes the step of parsing the Program Association Table (PAT); The steps of parsing the Program Association Table (PAT) include: directly obtaining the packet identifier Program_map_PID of the Program Mapping Table from the PAT payload.

7. The IPTV video encapsulation verification method as described in claim 1, characterized in that, The method employs a layered verification process, including: First, verify the synchronization bytes of each transmission packet; If the synchronization bytes are correct, then the program association table PAT and the program mapping table PMT are parsed and verified. If PAT and PMT are parsed correctly, then at least one parameter that affects the timing of audio and video playback is checked.

8. The IPTV video encapsulation verification method as described in claim 7, characterized in that, The parameters affecting the timing of audio and video playback include the Program Clock Reference PCR Interval or the Display Timestamp (PTS).

9. The IPTV video encapsulation verification method as described in claim 1, characterized in that, The method further includes: The verification results are associated with and recorded in relation to the program source status; Based on the verification results, the availability status of the program source is automatically set.

10. The IPTV video encapsulation verification method as described in claim 1, characterized in that, During the parsing of the transmission packet, the method skips the verification of the continuity counter when the adaptation_field_control field has a value of 0x00 or 0x10.

Images