IP multicast time delay determination method and system, storage medium and electronic equipment

Abstract

The invention discloses an IP multicast time delay determination method and system, a storage medium and electronic equipment. The method comprises the following steps: acquiring a first two-tuple corresponding to a first recombined TS stream of a target program sent by a first monitoring point at the current moment; determining a target two-tuple which is the same as the first feature data in the first two-tuple from a plurality of second two-tuples in a preset upstream monitoring linked list buffer area, and determining whether a first receiving timestamp in the first two-tuple is the same as a second receiving timestamp in the target two-tuple; and under the condition that the first receiving timestamp is different from the second receiving timestamp, determining the IP multicast delay of the target program between the upstream of the network transmission path and the downstream of the network transmission path according to the first receiving timestamp and the second receiving timestamp. According to the method and the device, the technical problem that the network time delay determined by utilizing a Ping test method cannot accurately reflect the IP network multicast time delay in the related technology is solved.

Description

Technical Field

[0001] The present application relates to the field of network security technology, and in particular to an IP multicast delay determination method and system, a storage medium, and an electronic device. Background Art

[0002] IP multicast technology has become one of the popular video transmission methods. Compared with traditional broadcast, satellite and other transmission methods, this technology has higher reliability and clarity, more channels and better user experience. However, since IP multicast needs to pass through many network devices such as video platform, core network router, BAS (Broadband Access Server), OLT (Optical Line Terminal), ONU (Optical Network Unit), set-top box, etc. before it can be presented on the TV terminal, multicast delay will inevitably occur. Multicast delay is one of the important factors that have always affected user experience. For example, during the World Cup football match, due to multicast delay, TV users of different operators will watch the goal time at different times, which will cause complaints or loss of users of operators with larger live broadcast delay. Therefore, accurately measuring the IP multicast delay between different network endpoints is crucial to discover the bottleneck of multicast delay and optimize the network.

[0003] However, the current delay measurement of IP networks generally uses the Ping test method based on ICMP (Internet Control Message Protocol), but this method is mainly applicable to the round-trip (two-way) delay measurement of the network, while IP multicast delay measurement is a one-way delay measurement, so the Ping test is obviously not applicable to IP multicast delay measurement. In addition, considering that video transmission and distribution based on IP multicast technology will involve many network devices such as encoding and transcoding equipment, IP flow matrix, protocol conversion equipment, streaming media server, network equipment, set-top box cache, etc., directly using IP network delay as IP multicast delay cannot reflect the real user experience.

[0004] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0005] The embodiments of the present application provide a method and system for determining an IP multicast delay, a storage medium, and an electronic device, so as to at least solve the technical problem that the network delay determined by the Ping test method in the related art cannot accurately reflect the IP network multicast delay.

[0006] According to one aspect of an embodiment of the present application, a method for determining an IP multicast delay is provided, comprising: obtaining a first tuple corresponding to a first reassembled TS stream of a target program sent by a first monitoring point at a current moment, wherein the first tuple includes: a first reception timestamp of a first reassembled TS packet in the first reassembled TS stream received by the first monitoring point and first feature data corresponding to the first reassembled TS stream, the first monitoring point being deployed downstream of a network transmission path, the target program being any one of a plurality of programs under a target channel, the first reassembled TS stream being obtained by the first monitoring point through parsing, program identification and reassembly of IP multicast code streams of a plurality of channels at a current moment, the plurality of channels at least including the target channel; and Determine a target binary group that is identical to the first characteristic data in the first binary group from among the multiple second binary groups in the table buffer, and determine whether the first receiving timestamp in the first binary group is identical to the second receiving timestamp in the target binary group, wherein the second binary group includes: a second monitoring point deployed upstream of the network transmission path receives the second receiving timestamp of the second reassembled TS packet in the second reassembled TS stream of the target program at any moment in the current time period and the second characteristic data corresponding to the second reassembled TS stream; when the first receiving timestamp is different from the second receiving timestamp, determine the IP multicast delay of the target program between the upstream of the network transmission path and the downstream of the network transmission path based on the first receiving timestamp and the second receiving timestamp.

[0007] Optionally, obtaining the first tuple corresponding to the first reassembled TS stream of the target program at the current moment sent by the first monitoring point includes: obtaining encrypted data obtained by encrypting the first tuple corresponding to the first reassembled TS stream of the target program at the current moment sent by the first monitoring point.

[0008] Optionally, the first monitoring point obtains the first tuple corresponding to the first reassembled TS stream of the target program at the current moment according to the following method, including: extracting the IP multicast code streams of multiple channels at the current moment through the live signaling protocol; parsing, program identification and reassembly of the IP multicast code stream to obtain the first reassembled TS stream of the target program at the current moment, and determining the first receiving timestamp of receiving the first reassembled TS packet in the first reassembled TS stream; using a preset integrity algorithm to process all the first reassembled TS packets in the first reassembled TS stream to obtain the first characteristic data corresponding to the first reassembled TS stream of the target program at the current moment.

[0009] Optionally, the IP multicast code stream is co-parsed, program identified and reassembled to obtain the first reassembled TS stream of the target program at the current moment, including: parsing the IP multicast code stream to obtain the corresponding first TS stream, wherein the first TS stream includes multiple first TS packets, and the first TS packet includes at least one PES packet with the same time reference, a program identifier for identifying the program to which the PES packet belongs, a program mapping table for identifying the programs included in the first TS stream and program information identifiers corresponding to each program; determining multiple first target TS packets corresponding to the target program information identifier of the target program from the first TS stream; and reassembling the multiple first target TS packets respectively to obtain multiple first reassembled TS packets, and the multiple first reassembled TS packets constitute the first reassembled TS stream of the target program.

[0010] Optionally, multiple first TS packets in the first target TS stream are reassembled to obtain multiple first reassembled TS packets, including: for each first target TS packet, extracting the PES packet in the first target TS packet according to a preset start flag; and reassembling the PES packets in the first target TS packet in sequence according to the sequence of the multiple first target TS packets to obtain multiple first reassembled TS packets.

[0011] Optionally, the construction process of the upstream monitoring linked list buffer includes: obtaining the second tuples corresponding to multiple second reassembled TS streams of the target program sent by the second monitoring point at multiple times in the current time period; aggregating the multiple second tuples from top to bottom in descending order of the second receiving timestamps in the second tuples to obtain the upstream monitoring linked list buffer.

[0012] Optionally, a target binary group identical to the first characteristic data in the first binary group is determined from multiple second binary groups in a preset upstream monitoring linked list buffer, including: starting from the tail of the upstream monitoring linked list buffer, traversing the second characteristic data in each second binary group in the upstream monitoring linked list buffer from bottom to top, and determining the target binary group identical to the first characteristic data in the first binary group.

[0013] According to another aspect of an embodiment of the present application, an IP multicast delay determination system is also provided, the system comprising: a first monitoring point deployed downstream of a network transmission path, a second monitoring point deployed upstream of the network transmission path, and a server, wherein the first monitoring point is used to send to the server a first tuple corresponding to a first reassembled TS stream of a target program at the current moment, wherein the first tuple includes: a first receiving timestamp of a first reassembled TS packet in the first reassembled TS stream and first feature data corresponding to the first reassembled TS stream, the target program is any one of a plurality of programs under a target channel, the first reassembled TS stream is obtained by parsing, identifying and reassembling IP multicast code streams of a plurality of channels at the current moment, and at least It includes a target channel; a server, which is used to determine a target binary group that is the same as the first characteristic data in the first binary group from multiple second binary groups in a preset upstream monitoring linked list buffer, and determine whether the first receiving timestamp in the first binary group is the same as the second receiving timestamp in the target binary group, wherein the second binary group includes: a second receiving timestamp of a second reassembled TS packet in a second reassembled TS stream of a target program received by a second monitoring point at any moment in a current time period and second characteristic data corresponding to the second reassembled TS stream; when the first receiving timestamp and the second receiving timestamp are different, determine the IP multicast delay of the target program between the upstream of the network transmission path and the downstream of the network transmission path based on the first receiving timestamp and the second receiving timestamp.

[0014] Optionally, the first monitoring point is also used to extract the IP multicast code streams of multiple channels at the current moment through the live signaling protocol; parse, identify and reassemble the IP multicast code streams to obtain the first reassembled TS stream of the target program at the current moment, and determine the first receiving timestamp of the first reassembled TS packet in the first reassembled TS stream; use a preset integrity algorithm to process all the first reassembled TS packets in the first reassembled TS stream to obtain the first characteristic data corresponding to the first reassembled TS stream of the target program at the current moment.

[0015] Optionally, the server is also used to obtain second tuples corresponding to multiple second reassembled TS streams of the target program sent by the second monitoring point at multiple times in the current time period; and summarize the multiple second tuples from top to bottom in descending order of the second receiving timestamps in the second tuples to obtain an upstream monitoring linked list buffer.

[0016] According to another aspect of an embodiment of the present application, a non-volatile storage medium is also provided, which includes a stored computer program, wherein the device where the non-volatile storage medium is located executes the above-mentioned IP multicast delay determination method by running the computer program.

[0017] According to another aspect of an embodiment of the present application, an electronic device is further provided, comprising: a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to execute the above-mentioned IP multicast delay determination method through the computer program.

[0018] In the embodiment of the present application, the server collects the TS stream of a specific program through the monitoring node to form a binary group containing the characteristic data of the TS packet receiving timestamp and the complete PES frame. This data structure is concise and contains the key information required for time synchronization and data matching; then, the server receives and stores the binary group data from the upstream monitoring point, forms an upstream monitoring linked list buffer, and compares it with the binary group characteristic data reported by the downstream monitoring point to find the matching characteristic data; once the target binary group matching the characteristic data is found, the binary group reported by the downstream monitoring point is compared with the receiving timestamp in the target binary group. If the receiving timestamps of the same TS packet received by the upstream and downstream monitoring points are different, then the live broadcast delay between the upstream and downstream monitoring points is the difference between the two receiving timestamps. It effectively solves the problem that the traditional delay measurement method (such as Ping test) cannot accurately measure the one-way IP live broadcast delay. It can not only provide real-time delay monitoring results, but also help network operators locate delay bottlenecks and optimize networks, thereby significantly improving the quality of live video services and user satisfaction, and thus solves the technical problem that the network delay determined by the Ping test method in the related technology cannot accurately reflect the IP network multicast delay. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0020] Figure 1 It is a hardware structure block diagram of a computer terminal (or mobile device) according to an optional IP multicast delay determination method of an embodiment of the present application;

[0021] Figure 2 It is a flowchart of an optional method for determining IP multicast delay according to an embodiment of the present application;

[0022] Figure 3 It is a flowchart of another optional method for determining IP multicast delay according to an embodiment of the present application;

[0023] Figure 4 It is a structural diagram of an optional IP multicast delay determination system according to an embodiment of the present application;

[0024] Figure 5 It is a schematic diagram of the structure of an optional electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0025] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0026] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0027] In addition, the relevant information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for display, data for analysis, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. For example, an interface is set up between this system and the relevant user or organization. Before obtaining relevant information, it is necessary to send an acquisition request to the aforementioned user or organization through the interface, and obtain relevant information after receiving the consent information fed back by the aforementioned user or organization.

[0028] In order to better understand the embodiments of the present application, the technical terms involved in the embodiments of the present application are explained as follows:

[0029] IP multicast: is a network communication technology that allows a data packet to be sent to multiple destinations, that is, point-to-multipoint transmission. This technology enables the sender of multicast data (also called "multicast source") to send data to a specific group of receivers (also called "multicast group") without sending data to each receiver individually.

[0030] Channel: refers to a continuous, fixed-frequency broadcast or transmission channel, usually carrying a specific type of program content. In television broadcasting, a channel may be a specific frequency or stream transmitted via radio frequency signals, satellites, cable networks, or IP networks.

[0031] Program: refers to a collection of specific content, which may be broadcast on a specific channel, but can also be broadcast across multiple channels or platforms. Programs usually have a predetermined broadcast schedule, including start and end times, and the content can be TV series, movies, news, sports events, etc.

[0032] MPEG Transport Stream (MPEG-TS): It is part of the MPEG-2 system layer and is designed for transmission over less reliable transmission media such as networks and satellites. It is widely used in digital television broadcasting such as terrestrial, satellite and cable TV systems.

[0033] Packet Identifier (PID): During video transmission, each TS data frame has a unique PID, which is used to identify the type and content of the data frame to ensure the correct transmission and reception of data.

[0034] PES (Packetized Elementary Stream): Packetized original stream frames are an important data structure used to transmit the original audio and video data streams after packetization in the MPEG-2 system. It converts the original video and audio data into a packet structure that can be decoded and played independently, and ensures the synchronous transmission and efficient decoding of audio and video data by including key timestamp information and segmentation data.

[0035] Network Time Protocol (NTP): A protocol used to synchronize computer system time. It allows computers to send requests to a time server over the network to obtain the current precise time and adjust the local clock to the same time as the server.

[0036] Example 1

[0037] At present, the measurement of IP live broadcast delay is usually based on the Ping test of ICMP protocol. Although this method can measure the round-trip delay of the network, it is not suitable for one-way delay measurement in live broadcast scenarios. In addition, since IP live video transmission involves multiple links and equipment, such as transcoding equipment, IP flow matrix, protocol conversion equipment, streaming media server, network equipment, set-top box cache, etc., directly using the traditional network delay measurement method cannot accurately reflect the actual delay of IP multicast from the source to the terminal. To this end, the relevant solution is provided in the embodiment of the present application, which will be described in detail below.

[0038] According to an embodiment of the present application, a method embodiment for determining IP multicast delay is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0039] The method embodiments provided in the embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 FIG. 1 shows a hardware structure block diagram of a computer terminal (or mobile device) for implementing a method for determining an IP multicast delay. Figure 1 As shown, the computer terminal 10 (or mobile device 10) may include one or more (102a, 102b, ..., 102n are used to illustrate) processors 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the BUS bus), a network interface, a power supply and / or a camera. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.

[0040] It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuits". The data processing circuits may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuit may be a single independent processing module, or may be incorporated in whole or in part into any of the other components in the computer terminal 10 (or mobile device). As described in the embodiments of the present application, the data processing circuit acts as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0041] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the IP multicast delay determination method in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, the IP multicast delay determination method of the above-mentioned application is realized. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the computer terminal 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0042] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the computer terminal 10. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0043] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the computer terminal 10 (or mobile device).

[0044] In the above operating environment, Figure 2 is a flow chart of an optional method for determining IP multicast delay according to an embodiment of the present application, such as Figure 2 As shown, the method at least includes steps S202-S206, wherein:

[0045] Step S202: obtaining a first tuple corresponding to a first reassembled TS stream of a target program sent by a first monitoring point at a current moment.

[0046] In the technical solution provided in step S202, in order to detect the IP multicast delay between the multicast source and the specific receiving end, a first monitoring point (such as a monitoring probe) can be deployed downstream of the network transmission path between the source device and the specific receiving end (i.e., the specific receiving end side) to collect, parse and process the live video stream data downstream of the network transmission path, wherein the network transmission paths between the multicast source and different receiving ends are different. It should be noted that the optimal network transmission path between the source device and different receiving ends can be determined according to a specific routing multicast protocol, and the present application does not impose specific restrictions on the method for determining the network transmission path.

[0047] In addition, since a channel may broadcast different programs at different times, the target program may be a program currently being broadcast on the target channel. The first tuple corresponding to the first reassembled TS stream includes: a first receiving timestamp of the first reassembled TS packet (preferably the first first reassembled TS packet) received by the first monitoring point in the first reassembled TS stream and first characteristic data corresponding to the first reassembled TS stream, and the first reassembled TS stream is obtained by the first monitoring point parsing, program identification and reassembly of IP multicast code streams (including multimedia data such as video and audio) of multiple channels (including at least the target channel) at the current moment (which is a moment in the current time period) .

[0048] Step S204, determining a target binary group having the same first characteristic data as the first binary group from multiple second binary groups in the preset upstream monitoring linked list buffer, and determining whether the first receiving timestamp in the first binary group is the same as the second receiving timestamp in the target binary group.

[0049] In the technical solution provided in step S204, the upstream monitoring linked list buffer includes a plurality of second tuples, and each second tuple includes: a second receiving timestamp of a second reassembled TS packet (preferably the first second reassembled TS packet) in a second reassembled TS stream of a target program received by a second monitoring point (such as a monitoring probe) deployed upstream of the network transmission path (i.e., the multicast source end) at any time in the current time period, and second feature data corresponding to the second reassembled TS stream. The second reassembled TS stream is obtained by the second monitoring point parsing, program identification, and reassembly of IP multicast code streams of multiple channels at each time in the current time period.

[0050] In the process of transmitting live data using IP multicast technology, it is necessary to pass through multiple network devices from the multicast source to a specific receiving end. Therefore, during the transmission process, there may be a delay in the multicast source and the playback end playing the program due to an abnormality of a certain network device. To this end, the server can first pre-cache multiple second binary data collected by the multicast source to obtain an upstream monitoring linked list buffer, and then determine the target binary that is the same as the first feature data in the first binary from the multiple second binary in the upstream monitoring linked list buffer, and determine whether the first receiving timestamp in the first binary is the same as the second receiving timestamp in the target binary.

[0051] Step S206, when the first receiving timestamp is different from the second receiving timestamp, determine the IP multicast delay of the target program between the upstream and downstream of the network transmission path according to the first receiving timestamp and the second receiving timestamp.

[0052] In the technical solution provided in step S206, if the server determines that the first receiving timestamp is different from the second receiving timestamp, it means that there is a time difference between the arrival timestamps of the same TS packet at the multicast source and the playback segment, and this time difference is the IP multicast delay value. Therefore, the server can determine the IP multicast delay of the target program between the upstream and downstream of the network transmission path based on the first receiving timestamp and the second receiving timestamp.

[0053] The IP multicast delay determination method of this embodiment is further introduced below.

[0054] Specifically, monitoring probes deployed at upstream and downstream nodes of the IP video network transmission path respectively collect data and parse protocols on the IP multicast streams of the upstream and downstream nodes to extract timestamps and feature information of video frames of specific programs.

[0055] The first monitoring node may obtain the first tuple corresponding to the first reassembled TS stream of the target program at the current moment according to the following method, including:

[0056] Step S1, extracting IP multicast streams of multiple channels at the current moment through a live signaling protocol.

[0057] Generally, the live signaling protocol allows the client and the server to establish a connection and negotiate so that both parties can reach an agreement on media parameters and transmission methods, which is necessary to ensure that the IP multicast code stream can correctly reach the playback end from the multicast source. Therefore, the first monitoring node can extract the IP multicast code streams of multiple channels at the current moment through the live signaling protocol (Internet Control Message Protocol ICMP or Internet Group Management Protocol IGMP). Among them, the IP multicast code stream refers to a continuous multimedia data stream transmitted through IP multicast technology, including video streams and / or audio streams. The code stream is a continuous form of expression in the data transmission process, and the multiple data packets in the IP multicast data are components of the code stream.

[0058] Step S2, parse, identify and reassemble the IP multicast code stream to obtain the first reassembled TS stream of the target program at the current moment, and determine the first receiving timestamp of the first reassembled TS packet in the first reassembled TS stream.

[0059] Specifically, the first monitoring point can obtain the first reassembled TS stream of the target program at the current moment according to the following method, including:

[0060] Step S21, parse the IP multicast code stream to obtain the corresponding first TS stream.

[0061] That is, the first monitoring point can perform protocol analysis on the IP multicast code stream to convert the effective load in the IP multicast data packet transmitted by the IP multicast code stream into a data stream in TS (Transport Stream) format to obtain the corresponding first TS stream.

[0062] Specifically, the first monitoring point first identifies and filters the IP multicast data packets; then, for each IP multicast data packet, parses the packet header of the IP multicast data packet to determine the source address, destination address and other related parameters of the data packet, and at the same time, extracts the effective load in the parsed IP multicast data packet, wherein these effective loads include multimedia data; finally, encapsulates these multimedia data according to the encapsulation format of the TS stream to obtain the first TS stream.

[0063] The encapsulation process usually includes: packaging the original multimedia data (i.e., ES stream) into a PES (Packetized Elementary Stream) stream, wherein a frame of data in the original multimedia data is packaged into a PES packet, so the PES stream includes multiple PES packets, wherein the header of each PES packet also includes timestamp information such as PTS (Presentation Timestamp) and DTS (Decoding Timestamp), and these timestamp information provide a common time stamp for PES to ensure that the multimedia data can be played correctly and synchronously; since the data length corresponding to a frame of data is often greater than the fixed length of a TS packet (usually 188 bytes), a PES packet needs to be allocated to a series of TS packets of fixed length, so the TS packet includes data segments of one or more PES packets with the same time reference. In addition, each TS packet also includes timing information (Program Clock Reference, PCR) and program specific information (Program Specific Information, PSI), where the timing information provides a system clock reference for the first TS stream to ensure that all PES packets are based on this common time reference; and the program specific information includes PAT (Program Association Table) and PMT (Program Map Table), where PAT is used to represent the PIDs of different programs and their corresponding PMTs, that is, it records which programs exist in the first TS stream and how to find the PMT table of each program, and the PMT table is used to describe all element streams (such as video, audio, subtitles, etc.) contained in a specific program and their corresponding PIDs.

[0064] Therefore, the first TS stream obtained in the above step S21 includes multiple first TS packets, and each first TS packet includes a PES packet with the same time base, a program identifier (i.e., PID) for identifying the program to which the PES packet belongs, and a program mapping table (i.e., PMT / PAT) for identifying the programs contained in the first TS stream and the program information identifiers corresponding to each program.

[0065] Step S22: determining a plurality of first target TS packets corresponding to the target program information identifier of the target program in the first TS stream.

[0066] That is to say, the first monitoring point can filter out the first target TS packets corresponding to the target program identifier of the target program from the multiple first TS packets in the first TS stream according to the corresponding PID information of the program detailed information of each program provided in the program mapping table (PMT / PAT) in the first TS stream, and these first target TS packets include data segments of PES packets such as video and audio of the target program.

[0067] Step S23, reorganize the multiple first TS packets in the first target TS stream to obtain multiple first reorganized TS packets, and form a first reorganized TS stream of the target program from the multiple first reorganized TS packets.

[0068] Since each first target TS packet corresponding to the target program may include data fragments of PES packets such as video and audio of the target program, the first monitoring point can reassemble multiple first target TS packets corresponding to the target program to restore the complete PES data packet, obtain multiple first reassembled TS packets, and reassemble the first reassembled TS stream of the target program from the multiple first reassembled TS packets.

[0069] Optionally, the first monitoring point can obtain multiple first reassembled TS packets according to the following method, including: for each first target TS packet, extracting the PES packet in the first target TS packet according to a preset start flag; reassembling the PES packets in the first target TS packet in sequence according to the sequence of the multiple first target TS packets to obtain multiple first reassembled TS packets.

[0070] That is to say, for each first reassembled TS packet, check whether its payload contains the data segment of the PES packet, and identify the start of the PES packet according to the start flag of the PES packet (usually a specific code prefix, such as 0x000001), and extract the PES packet header information (including PTS and DTS); reassemble the continuous first target TS packet payload data into a complete PES packet in sequence. It should be noted that the TS packet header contains a continuity counter for tracking the sequence of the PES packet data segments. If the continuity counter shows discontinuity, it may mean that the data packet is lost or the sequence is wrong. In this case, it may be necessary to discard the incomplete PES packet and restart the packet assembly.

[0071] After the first monitoring point obtains the first reassembled TS stream of the target program at the current moment through the above steps S21-S23, the first monitoring point can record the first receiving timestamp of each first reassembled TS packet in the first reassembled TS stream. In order to reduce the data stream recorded by the first monitoring point, the first monitoring point can preferably record the first receiving timestamp of the first first reassembled TS packet in the first reassembled TS stream.

[0072] Step S3, using a preset integrity algorithm to process all first reassembled TS packets in the first reassembled TS stream to obtain first characteristic data corresponding to the first reassembled TS stream of the target program at the current moment.

[0073] Specifically, the first monitoring point can use the MD5 algorithm to calculate the multimedia data in the PES packet information in all the first reassembled TS packets in the first reassembled TS stream to generate a hash value of a fixed length. This hash value is the first characteristic data of the complete PES packet in the target program.

[0074] Furthermore, the first monitoring point can send the tuple of the first receiving timestamp (Tm) of the first reassembled TS packet determined in the above step S2 and the first characteristic data (CHm) corresponding to the first reassembled TS stream to the comparison calculation server in json array text format or other transmittable format.

[0075] Considering that when data is transmitted over the network, the transmitted data may pass through multiple network nodes and links, and there is a risk of being monitored, intercepted, and tampered with. In order to ensure the security and integrity of the first binary data sent by the first monitoring point, the first monitoring point can encrypt the first binary corresponding to the first reorganized TS stream of the target program at the current moment according to the encryption key pre-negotiated with the server, obtain the encrypted data, and send the encrypted data to the server via Http encrypted transmission; the server can decrypt the encrypted data according to the decryption key pre-negotiated with the first monitoring point to obtain the first binary corresponding to the first reorganized TS stream. In addition, after the first monitoring point sends the first binary to the server, it will clear the relevant data in the buffer area and restart the collection at the next moment.

[0076] Similarly, the second monitoring point can refer to the above method to obtain the second tuple corresponding to the multiple second reassembled TS streams of the target program at multiple moments in the current time period, wherein the second tuple includes: the second receiving timestamp (Ts) of the second reassembled TS packet received by the second monitoring point in the second reassembled TS stream, the second characteristic data (CHs) corresponding to the second reassembled TS stream, and sends it to the comparison calculation server in json array text format or other transmittable format. Alternatively, the second monitoring point encrypts the second tuple corresponding to the second reassembled TS stream of the target program at multiple moments in the current time period according to the encryption key pre-negotiated with the server to obtain the encrypted data; and the server can decrypt the encrypted data according to the decryption key pre-negotiated with the second monitoring point to obtain the second tuple corresponding to the second reassembled TS stream of the target program at multiple moments in the current time period.

[0077] Among them, since the acquisition method of the second monitoring point to obtain the second two-tuple is the same as the acquisition method of the first monitoring point to obtain the first two-tuple, it will not be repeated here. In addition, after the second monitoring point sends the second two-tuple of a moment to the server each time, it will clear the relevant data in the buffer area and restart the collection at the next moment.

[0078] Furthermore, after receiving the second tuple corresponding to the multiple second reassembled TS streams of the target program at multiple moments in the current time period sent by the second monitoring point, the server can aggregate the multiple second tuples from top to bottom in descending order of the second receiving timestamps in the second tuple to obtain the upstream monitoring linked list buffer, ensuring that the latest data is always at the head of the linked list.

[0079] For example, after the second monitoring point completes the collection of 1 second of IP multicast data, it can send the second tuple obtained by parsing, identifying and reassembling the IP multicast data to the server; and the server can first initialize the buffer, and set a linked list length that can accommodate 20 seconds of data (i.e., 20 groups of tuple data), set the head and tail pointers of the linked list, and manage the insertion of new data and the deletion of old data to obtain the upstream monitoring linked list buffer. Whenever the server receives a new group of second tuples sent by the second monitoring point, it can enter this new group of second tuples into the head of the upstream monitoring linked list buffer, that is, starting from the tail of the buffer, the second tuple at the tail is collected first, and the data at the head of the linked list is the latest. It should be noted that when the upstream monitoring linked list buffer is full of 20 groups of tuple data, the "first in, first out" (FIFO) strategy is implemented to delete the second tuple with the smallest tail Ts in the upstream monitoring linked list buffer, and update the tail pointer at the same time to make room for new data.

[0080] Furthermore, the server may start from the tail of the upstream monitoring linked list buffer, traverse the second characteristic data in each second binary group in the upstream monitoring linked list buffer from bottom to top, determine the target binary group that is the same as the first characteristic data in the first binary group, and determine whether the first receiving timestamp in the first binary group is the same as the second receiving timestamp in the target binary group, wherein:

[0081] When the first receiving timestamp is the same as the second receiving timestamp, it indicates that there is no multicast delay in the network transmission process of the target program.

[0082] When the first receiving timestamp is different from the second receiving timestamp, it indicates that there is a multicast delay in the target program during the network transmission process. Therefore, the server can determine the IP multicast delay of the target program between the upstream and downstream of the network transmission path based on the first receiving timestamp and the second receiving timestamp.

[0083] The server can troubleshoot the network equipment on the network transmission path of the target program through the IP multicast delay between the upstream and downstream of the network transmission path, so as to compare and analyze the multicast delay of each network segment, thereby finding the bottleneck causing end-to-end multicast delay.

[0084] For example, Figure 3 FIG. 1 is a flow chart of another optional method for determining IP multicast delay according to an embodiment of the present application, such as Figure 3 As shown. The comparison calculation server can be an NTP (Network Time Protocol) server, which receives synchronization request instructions from upstream and downstream monitoring probes to achieve clock synchronization of upstream and downstream monitoring probes; and the upstream monitoring node and the downstream monitoring node collect live data at intervals of 1 second respectively. The comparison calculation server can determine the IP multicast delay according to the following steps:

[0085] Step 1: The initial synchronization flag Sync=-1, which is a default asynchronous state, indicating that the comparison calculation server has not yet found a matching point of the video frame feature values ​​between the upstream and downstream monitoring points, that is, the synchronization point has not yet been determined.

[0086] Step 2: The comparison calculation server receives the first tuple (Tm, CHm) corresponding to the first reassembled TS stream of the target program at the current moment sent by the downstream monitoring point;

[0087] Step 3: Determine whether the synchronization flag Sync is equal to -1. If so, execute steps 4 to 6; otherwise, execute steps 7 to 9;

[0088] Step 4: The comparison calculation server starts from the tail of the upstream monitoring point linked list buffer (BUFs) and searches for CHs equal to the current CHm in sequence;

[0089] Step 5: If a CHs equal to the current CHm is found, the synchronization flag is set to the position of CHs in BUFs, that is, Sync=POSn, and the multicast delay Latency is calculated = the current time Tm of the downstream monitoring point - Ts corresponding to the POSn position in the buffer of the upstream monitoring point (that is, Ts corresponding to the CHs equal to the current CHm), and Latency is cached;

[0090] Step 6: If no CHs equal to the current CHm is found, the comparison calculation server continues to receive the first tuple (Tm, CHm) corresponding to the first reassembled TS stream of the target program at the next moment sent by the downstream monitoring point;

[0091] Step 7: The comparison calculation server determines whether the feature data CHs in the next position POSn+1 in BUFs matches the current Chm:

[0092] Step 8: If they match, set the synchronization flag to the position of CHs in BUFs, i.e., Sync=POSn+1, and calculate the multicast delay Latency=the current time Tm of the downstream monitoring point-the Ts of the POSn+1 position in the buffer of the upstream monitoring point, and cache Latency;

[0093] Step 9: If there is no match, clear the Sync mark in the buffer of the upstream monitoring point, that is, Sync=-1, and continue to receive the first tuple (Tm, CHm) corresponding to the first reassembled TS stream of the target program at the next moment sent by the downstream monitoring point;

[0094] Step 10: Calculate the cached latency average value at a sampling interval of 10 seconds and output it as the IP live broadcast latency sampling value.

[0095] Based on the scheme defined by the above steps S202 to S206, it can be known that in the embodiment, the server deploys monitoring nodes respectively at the upstream and downstream of the network transmission path, collects the TS stream of a specific program through the monitoring nodes, and forms a tuple containing the TS packet receiving timestamp and the characteristic data of the complete PES frame. This data structure is concise and contains the key information required for time synchronization and data matching; then, the server receives and stores the tuple data from the upstream monitoring point, forms an upstream monitoring linked list buffer, and compares it with the tuple characteristic data reported by the downstream monitoring point to find matching characteristic data; once the target tuple matching the characteristic data is found, the tuple reported by the downstream monitoring point is compared with the receiving timestamp in the target tuple. If the receiving timestamps of the same TS packet received by the upstream and downstream monitoring points are different, then the live broadcast delay between the upstream and downstream monitoring points is the difference between the two receiving timestamps. This effectively solves the problem that the traditional delay measurement method (such as Ping test) cannot accurately measure the one-way IP live broadcast delay. It can not only provide real-time latency monitoring results, but also help network operators locate latency bottlenecks and optimize networks, thereby significantly improving the quality of live video services and user satisfaction, and solving the technical problem that the network latency determined by the Ping test method in related technologies cannot accurately reflect the IP network multicast latency.

[0096] Example 2

[0097] Based on Example 1 of the present application, an embodiment of an IP multicast delay determination system is also provided. When the system is running, the above-mentioned IP multicast delay determination method of the above-mentioned embodiment is executed. Figure 4 is a schematic diagram of the structure of an optional IP multicast delay determination system according to an embodiment of the present application, such as Figure 4 The system 10 includes: a first monitoring point 11 deployed downstream of the network transmission path, a second monitoring point 12 deployed upstream of the network transmission path, and a server 13, wherein:

[0098] The first monitoring point 11 is used to send a first tuple corresponding to the first reassembled TS stream of the target program at the current moment to the server 13, wherein the first tuple includes: a first receiving timestamp of receiving the first reassembled TS packet in the first reassembled TS stream and first characteristic data corresponding to the first reassembled TS stream, the target program is any one of the multiple programs under the target channel, the first reassembled TS stream is obtained by parsing, program identifying and reassembling the IP multicast code streams of multiple channels at the current moment, and the multiple channels include at least the target channel.

[0099] Specifically, the first monitoring point 11 can obtain the first tuple corresponding to the first reassembled TS stream of the target program at the current moment according to the following method, including: extracting the IP multicast code streams of multiple channels at the current moment through the live signaling protocol; parsing, program identification and reassembly of the IP multicast code stream to obtain the first reassembled TS stream of the target program at the current moment, and determining the first receiving timestamp of the first reassembled TS packet in the first reassembled TS stream; using a preset integrity algorithm to process all the first reassembled TS packets in the first reassembled TS stream to obtain the first characteristic data corresponding to the first reassembled TS stream of the target program at the current moment.

[0100] The server 13 is used to determine a target binary group that is identical to the first characteristic data in the first binary group from a plurality of second binary groups in a preset upstream monitoring linked list buffer, and determine whether the first receiving timestamp in the first binary group is identical to the second receiving timestamp in the target binary group, wherein the second binary group includes: a second receiving timestamp of a second reassembled TS packet in a second reassembled TS stream received by the second monitoring point 12 at any moment in the current time period and second characteristic data corresponding to the second reassembled TS stream; and when the first receiving timestamp is different from the second receiving timestamp, determining the IP multicast delay of the target program between the upstream of the network transmission path and the downstream of the network transmission path based on the first receiving timestamp and the second receiving timestamp.

[0101] Specifically, the server 13 can construct an upstream monitoring linked list buffer according to the following method, including: obtaining a second tuple corresponding to multiple second reassembled TS streams of the target program sent by the second monitoring point 13 at multiple times in the current time period; aggregating the multiple second tuples from top to bottom in descending order of the second receiving timestamps in the second tuple to obtain an upstream monitoring linked list buffer.

[0102] It should be noted that the various modules in the above-mentioned IP multicast delay determination system can be program modules (for example, a set of program instructions that implement a certain specific function) or hardware modules. For the latter, it can be expressed in the following forms, but is not limited to this: the expression form of each of the above-mentioned modules is a processor, or the functions of each of the above-mentioned modules are implemented by a processor.

[0103] Example 3

[0104] According to an embodiment of the present application, a non-volatile storage medium is further provided, in which a program is stored, wherein when the program is running, the device where the non-volatile storage medium is located is controlled to execute the IP multicast delay determination method in Example 1.

[0105] Optionally, the device where the non-volatile storage medium is located implements the following steps by running the program: obtaining a first tuple corresponding to the first reassembled TS stream of the target program sent by the first monitoring point at the current moment, wherein the first tuple includes: a first receiving timestamp of the first reassembled TS packet in the first reassembled TS stream received by the first monitoring point and first feature data corresponding to the first reassembled TS stream, the first monitoring point is deployed downstream of the network transmission path, the target program is any one of multiple programs under the target channel, the first reassembled TS stream is obtained by the first monitoring point through parsing, program identification and reassembly of IP multicast code streams of multiple channels at the current moment, and the multiple channels at least include the target channel; from a preset upstream monitoring chain Determine a target binary group that is identical to the first characteristic data in the first binary group from among the multiple second binary groups in the table buffer, and determine whether the first receiving timestamp in the first binary group is identical to the second receiving timestamp in the target binary group, wherein the second binary group includes: a second monitoring point deployed upstream of the network transmission path receives the second receiving timestamp of the second reassembled TS packet in the second reassembled TS stream of the target program at any moment in the current time period and the second characteristic data corresponding to the second reassembled TS stream; when the first receiving timestamp is different from the second receiving timestamp, determine the IP multicast delay of the target program between the upstream of the network transmission path and the downstream of the network transmission path based on the first receiving timestamp and the second receiving timestamp.

[0106] According to an embodiment of the present application, a computer program product is also provided, which includes a stored computer program, wherein when the computer program is executed by a processor, the IP multicast delay determination method in Example 1 is implemented.

[0107] Optionally, the computer program executes the following steps: obtaining a first tuple corresponding to a first reassembled TS stream of a target program sent by a first monitoring point at a current moment, wherein the first tuple includes: a first reception timestamp of a first reassembled TS packet in the first reassembled TS stream received by the first monitoring point and first feature data corresponding to the first reassembled TS stream, the first monitoring point is deployed downstream of a network transmission path, the target program is any one of a plurality of programs under a target channel, the first reassembled TS stream is obtained by the first monitoring point through parsing, program identification and reassembly of IP multicast code streams of a plurality of channels at a current moment, and the plurality of channels at least include a target channel; and selecting a first reassembled TS stream from a plurality of channels in a preset upstream monitoring linked list buffer. A target binary group identical to the first characteristic data in the first binary group is determined in a second binary group, and whether the first reception timestamp in the first binary group is the same as the second reception timestamp in the target binary group, wherein the second binary group includes: a second monitoring point deployed upstream of the network transmission path receives the second reception timestamp of the second reassembled TS packet in the second reassembled TS stream of the target program at any time in the current time period and the second characteristic data corresponding to the second reassembled TS stream; when the first reception timestamp and the second reception timestamp are different, the IP multicast delay of the target program between the upstream of the network transmission path and the downstream of the network transmission path is determined based on the first reception timestamp and the second reception timestamp.

[0108] According to an embodiment of the present application, a processor is also provided, which is used to run a program, wherein the IP multicast delay determination method in Example 1 is executed when the program is running.

[0109] Optionally, when the program is running, the following steps are executed: obtaining a first tuple corresponding to the first reassembled TS stream of the target program sent by the first monitoring point at the current moment, wherein the first tuple includes: a first reception timestamp of the first reassembled TS packet in the first reassembled TS stream received by the first monitoring point and first characteristic data corresponding to the first reassembled TS stream, the first monitoring point is deployed downstream of the network transmission path, the target program is any one of multiple programs under the target channel, the first reassembled TS stream is obtained by the first monitoring point through parsing, program identification and reassembly of IP multicast code streams of multiple channels at the current moment, and the multiple channels at least include the target channel; multiple reassembled TS streams in the preset upstream monitoring linked list buffer are obtained by the first monitoring point through parsing, program identification and reassembly. A target binary group identical to the first characteristic data in the first binary group is determined in a second binary group, and whether the first reception timestamp in the first binary group is the same as the second reception timestamp in the target binary group, wherein the second binary group includes: a second monitoring point deployed upstream of the network transmission path receives the second reception timestamp of the second reassembled TS packet in the second reassembled TS stream of the target program at any time in the current time period and the second characteristic data corresponding to the second reassembled TS stream; when the first reception timestamp and the second reception timestamp are different, the IP multicast delay of the target program between the upstream of the network transmission path and the downstream of the network transmission path is determined based on the first reception timestamp and the second reception timestamp.

[0110] According to an embodiment of the present application, an electronic device is also provided, wherein: Figure 5 is a schematic diagram of the structure of an optional electronic device according to an embodiment of the present application, such as Figure 5 As shown, the electronic device includes one or more processors; a memory for storing one or more programs, and when the one or more programs are executed by the one or more processors, the one or more processors are implemented to run the programs, wherein the programs are configured to execute the IP multicast delay determination method in the above-mentioned embodiment 1 when running.

[0111] Optionally, the processor is configured to execute the following steps through a computer program: obtaining a first tuple corresponding to a first reassembled TS stream of a target program sent by a first monitoring point at a current moment, wherein the first tuple includes: a first receiving timestamp of a first reassembled TS packet in the first reassembled TS stream received by the first monitoring point and first characteristic data corresponding to the first reassembled TS stream, the first monitoring point is deployed downstream of a network transmission path, the target program is any one of a plurality of programs under a target channel, the first reassembled TS stream is obtained by the first monitoring point through parsing, program identification and reassembly of IP multicast code streams of a plurality of channels at a current moment, and the plurality of channels at least include a target channel; buffering a first reassembled TS stream from a preset upstream monitoring chain list A target binary group identical to the first characteristic data in the first binary group is determined from among multiple second binary groups in the zone, and it is determined whether the first receiving timestamp in the first binary group is identical to the second receiving timestamp in the target binary group, wherein the second binary group includes: a second monitoring point deployed upstream of the network transmission path receives the second receiving timestamp of the second reassembled TS packet in the second reassembled TS stream of the target program at any moment in the current time period and the second characteristic data corresponding to the second reassembled TS stream; when the first receiving timestamp is different from the second receiving timestamp, the IP multicast delay of the target program between the upstream of the network transmission path and the downstream of the network transmission path is determined based on the first receiving timestamp and the second receiving timestamp.

[0112] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0113] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0114] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0115] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0116] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0117] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the relevant technology or all or part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, RandomAccess Memory), mobile hard disk, disk or optical disk, etc. Various media that can store program codes.

[0118] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for determining IP multicast delay, characterized in that: include: Obtain a first tuple corresponding to a first reassembled transmission TS stream of a target program sent by a first monitoring point at a current moment, wherein the first tuple includes: a first receiving timestamp of a first reassembled TS packet in the first reassembled TS stream received by the first monitoring point and first characteristic data corresponding to the first reassembled TS stream, the first monitoring point is deployed downstream of a network transmission path, the target program is any one of a plurality of programs under a target channel, the first reassembled TS stream is obtained by the first monitoring point through parsing, program identification and reassembly of network protocol address IP multicast code streams of a plurality of channels at a current moment, and the plurality of channels at least include the target channel; Determine a target binary group that is identical to the first characteristic data in the first binary group from a plurality of second binary groups in a preset upstream monitoring linked list buffer, and determine whether a first receiving timestamp in the first binary group is identical to a second receiving timestamp in the target binary group, wherein the second binary group includes: a second receiving timestamp of a second reassembled TS packet in a second reassembled TS stream of the target program received at any time in the current time period by a second monitoring point deployed upstream of the network transmission path and second characteristic data corresponding to the second reassembled TS stream; In the case that the first receiving timestamp is different from the second receiving timestamp, the IP multicast delay of the target program between the upstream of the network transmission path and the downstream of the network transmission path is determined according to the first receiving timestamp and the second receiving timestamp.

2. The method according to claim 1, characterized in that Obtaining the first 2-tuple corresponding to the first reassembled TS stream of the target program sent by the first monitoring point at the current moment, including: The encrypted data obtained by encrypting the first binary group corresponding to the first reassembled TS stream of the target program at the current moment and sent by the first monitoring point is obtained.

3. The method according to claim 1 or 2, characterized in that: The first monitoring point obtains the first 2-tuple corresponding to the first reassembled TS stream of the target program at the current moment according to the following method, including: Extracting the IP multicast streams of the multiple channels at the current moment through a live signaling protocol; Parsing, program identification and reassembling the IP multicast code stream to obtain a first reassembled TS stream of the target program at the current moment, and determining a first receiving timestamp for receiving a first reassembled TS packet in the first reassembled TS stream; All first reassembled TS packets in the first reassembled TS stream are processed using a preset integrity algorithm to obtain first characteristic data corresponding to the first reassembled TS stream of the target program at the current moment.

4. The method according to claim 3, characterized in that Co-analyzing, program identification and reassembling the IP multicast code stream to obtain the first reassembled TS stream of the target program at the current moment, including: Parsing the IP multicast code stream to obtain a corresponding first TS stream, wherein the first TS stream includes a plurality of first TS packets, and the first TS packet includes at least one packaged elementary code stream PES packet with the same time reference, a program identifier for identifying a program to which the PES packet belongs, and a program mapping table for identifying programs included in the first TS stream and program information identifiers corresponding to each of the programs; Determine a plurality of first target TS packets corresponding to the target program information identifier of the target program from the first TS stream; The multiple first target TS packets are reassembled respectively to obtain multiple first reassembled TS packets, and the multiple first reassembled TS packets constitute a first reassembled TS stream of the target program.

5. The method according to claim 4, characterized in that Reassembling a plurality of first TS packets in the first target TS stream to obtain a plurality of first reassembled TS packets, comprising: For each of the first target TS packets, extracting the PES packet in the first target TS packet according to a preset start flag; The PES packets in the first target TS packets are reassembled in sequence according to the sequence of the multiple first target TS packets to obtain the multiple first reassembled TS packets.

6. The method according to claim 1, characterized in that The construction process of the upstream monitoring linked list buffer includes: Acquire a second tuple corresponding to a plurality of second reassembled TS streams of the target program at a plurality of time points in the current time period sent by the second monitoring point; According to the descending order of the second receiving timestamps in the second two-tuples, a plurality of the second two-tuples are aggregated from top to bottom to obtain the upstream monitoring linked list buffer.

7. The method according to claim 6, characterized in that Determining a target binary group having the same first characteristic data as the first binary group from a plurality of second binary groups in a preset upstream monitoring chain list buffer includes: Starting from the tail of the upstream monitoring linked list buffer, the second characteristic data in each second binary group in the upstream monitoring linked list buffer is traversed from bottom to top to determine the target binary group that is the same as the first characteristic data in the first binary group.

8. A system for determining IP multicast delay, characterized in that: The system includes: a first monitoring point deployed downstream of a network transmission path, a second monitoring point deployed upstream of the network transmission path, and a server, wherein: The first monitoring point is used to send a first tuple corresponding to a first reassembled TS stream of a target program at a current moment to the server, wherein the first tuple includes: a first receiving timestamp of a first reassembled TS packet in the first reassembled TS stream and first feature data corresponding to the first reassembled TS stream, the target program is any one of a plurality of programs under a target channel, the first reassembled TS stream is obtained by parsing, program identifying and reassembling IP multicast code streams of a plurality of channels at a current moment, and the plurality of channels at least includes the target channel; The server is used to determine a target binary group that is identical to the first characteristic data in the first binary group from a plurality of second binary groups in a preset upstream monitoring linked list buffer, and determine whether the first receiving timestamp in the first binary group is identical to the second receiving timestamp in the target binary group, wherein the second binary group includes: the second receiving timestamp of the second reassembled TS packet in the second reassembled TS stream of the target program received by the second monitoring point at any moment in the current time period and the second characteristic data corresponding to the second reassembled TS stream; when the first receiving timestamp is different from the second receiving timestamp, determining the IP multicast delay of the target program between the upstream of the network transmission path and the downstream of the network transmission path based on the first receiving timestamp and the second receiving timestamp.

9. The system according to claim 8, characterized in that The first monitoring point is further used to extract the IP multicast code streams of the multiple channels at the current moment through the live signaling protocol; parse, identify and reassemble the IP multicast code streams to obtain the first reassembled TS stream of the target program at the current moment, and determine the first receiving timestamp of receiving the first reassembled TS packet in the first reassembled TS stream; All first reassembled TS packets in the first reassembled TS stream are processed using a preset integrity algorithm to obtain first characteristic data corresponding to the first reassembled TS stream of the target program at the current moment.

10. The system according to claim 8, characterized in that The server is also used to obtain the second tuples corresponding to the multiple second reassembled TS streams of the target program sent by the second monitoring point at multiple times in the current time period; and summarize the multiple second tuples from top to bottom in descending order of the second receiving timestamps in the second tuples to obtain the upstream monitoring linked list buffer.

11. A non-volatile storage medium, characterized in that: The non-volatile storage medium stores a computer program, wherein the device where the non-volatile storage medium is located executes the IP multicast delay determination method according to any one of claims 1 to 7 by running the computer program.

12. An electronic device, characterized in that: include: A memory and a processor, wherein the processor is used to run a program stored in the memory, wherein the program executes the IP multicast delay determination method according to any one of claims 1 to 7 when running.

Images