Ip multicast delay determination method and system, storage medium, and electronic device

Abstract

The application discloses an IP multicast delay determination method and system, a storage medium and an electronic device. The method comprises the following steps: obtaining a first tuple corresponding to a first recombined TS stream of a target program at a current time point sent by a first monitoring point; determining a target tuple same as first feature data in the first tuple from a plurality of second tuples in a preset upstream monitoring chain table buffer, and determining whether a first receiving timestamp in the first tuple and a second receiving timestamp in the target tuple are same; in the case that the first receiving timestamp and the second receiving timestamp are not same, determining an IP multicast delay of the target program between an upstream of a network transmission path and a downstream of the network transmission path according to the first receiving timestamp and the second receiving timestamp. The application solves the technical problem that the network delay determined by the related art Ping test method cannot accurately reflect the IP network multicast delay.

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 a popular method for video transmission. Compared to traditional broadcast and satellite transmission methods, it offers higher reliability and clarity, more channels, and a better user experience. However, because IP multicast requires numerous network devices, including video platforms, core network routers, BAS (Broadband Access Server), OLT (Optical Line Terminal), ONU (Optical Network Unit), and set-top boxes, before being presented to television terminals, multicast latency is unavoidable. Multicast latency is a significant factor that consistently impacts user experience. For example, during the World Cup, multicast latency caused TV users on different operators to see goals at different times, leading to user complaints and loss for operators experiencing higher live broadcast latency. Therefore, accurately measuring IP multicast latency between different network endpoints is crucial for identifying multicast latency bottlenecks and optimizing the network.

[0003] However, current latency measurements for IP networks generally use the Ping test method based on the Internet Control Message Protocol (ICMP). However, this method primarily measures round-trip (two-way) network latency, while IP multicast latency is a one-way measurement. Therefore, the Ping test is clearly unsuitable for IP multicast latency measurement. Furthermore, given that video transmission and distribution based on IP multicast technology involves numerous network devices, including transcoding equipment, IP stream matrices, protocol conversion equipment, streaming media servers, network equipment, and set-top box caches, simply using IP network latency as IP multicast latency does not reflect the actual user experience.

[0004] To address the above-mentioned problems, no effective solutions have been proposed so far. Summary of the Invention

[0005] The embodiments of the present application provide a method and system for determining IP multicast delay, a storage medium, and an electronic device 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 received by the first monitoring point in the first reassembled TS stream and first characteristic 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 including at least 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 reception timestamp in the first binary group is identical to 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 moment 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, 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 reception timestamp and the second reception 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 the first reassembled TS packet in the first reassembled TS stream; using a preset integrity algorithm to process all 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 base, a program identifier for identifying the program to which the PES packet belongs, a program mapping table for identifying the programs contained 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 moments 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 that is 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 that is 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, which 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 the first reassembled TS stream of a target program at the current moment to the server, wherein the first tuple includes: a first receiving timestamp of receiving the 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 multiple programs under a target channel, the first reassembled TS stream is obtained by parsing, identifying and reassembling the IP multicast code streams of multiple channels at the current moment, and at least It includes a target channel; a server, used to determine a target binary group that is identical to 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 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 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 and the second receiving timestamp are different, 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.

[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 moments 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.

[0016] According to another aspect of an embodiment of the present application, a non-volatile storage medium is further 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 the memory stores a computer program, and the processor is configured to execute the above-mentioned IP multicast delay determination method through the computer program.

[0018] In an embodiment of the present application, the server collects the TS stream of a specific program through a monitoring node to form a binary data set containing the TS packet reception 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 binary data from the upstream monitoring point, forms an upstream monitoring linked list buffer, and compares it with the binary characteristic data reported by the downstream monitoring point to find matching characteristic data. Once the target binary data matching characteristic data is found, the binary reported by the downstream monitoring point is compared with the receiving timestamp in the target binary data set. 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 traditional delay measurement methods (such as Ping tests) 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 perform network optimization, thereby significantly improving the quality of live video services and user satisfaction, thereby solving 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 This 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 1 is a flow chart of an optional method for determining IP multicast delay according to an embodiment of the present application;

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

[0023] Figure 4 1 is a schematic 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 structural diagram 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 present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this 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 sequential order. 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 a sequence 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 the 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: A network communication technology that allows a single data packet to be sent to multiple destinations, also known as point-to-multipoint transmission. This technology enables a multicast data sender (also called a "multicast source") to send data to a specific group of receivers (also called a "multicast group") without having to send the data to each receiver individually.

[0030] Channel: A continuous, fixed-frequency broadcast or transmission channel that typically carries a specific type of program content. In television broadcasting, a channel may be a specific frequency or stream transmitted via radio frequency signals, satellite, cable networks, or IP networks.

[0031] Program: A collection of specific content that may be broadcast on a specific channel, but can also be broadcast across multiple channels or platforms. Programs typically have a predetermined broadcast schedule, including start and end times, and can include TV series, movies, news, sporting 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): A packetized raw stream frame, a key data structure used in MPEG-2 systems to transmit packetized raw audio and video data streams. It converts raw video and audio data into packets that can be independently decoded and played. By including critical timestamp information and segmentation data, it ensures synchronized transmission and efficient decoding of audio and video 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 match the server's time.

[0036] Example 1

[0037] Currently, the measurement of IP live broadcast latency is typically based on the Ping test using the ICMP protocol. While this method can measure the round-trip network latency, it is not suitable for measuring one-way latency in live broadcast scenarios. Furthermore, because IP live video transmission involves multiple links and devices, such as transcoding equipment, IP stream matrices, protocol conversion equipment, streaming media servers, network equipment, and set-top box caches, directly using traditional network latency measurement methods cannot accurately reflect the actual latency of IP multicast from source to terminal. To this end, the present application provides a relevant solution in the embodiments, which will be described in detail below.

[0038] According to the embodiments of the present application, a method embodiment for IP multicast delay determination 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 the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from here.

[0039] The method embodiment provided by the embodiments of the present application can be executed in a mobile terminal, a computer terminal or similar computing device. Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing the IP multicast delay determination method is shown. As shown in the figure, Figure 1 The computer terminal 10 (or mobile device 10) can include one or more processors 102 (the processor 102 can include but not limited to a microprocessor MCU or a programmable logic device FPGA processing device), a memory 104 for storing data, and a transmission device 106 for communication function. In addition, it can also include a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which can be included as one of the ports in the BUS bus), a network interface, a power supply and / or a camera. Those skilled in the art can understand, Figure 1 The structure shown is only schematic, which does not limit the structure of the above-mentioned electronic device. For example, the computer terminal 10 can also include more or less components than Figure 1 shown, or have a different configuration than Figure 1 shown.

[0040] It should be noted that the one or more processors 102 and / or other data processing circuits described above can be referred to herein as "data processing circuits" in general. The data processing circuit can be embodied in whole or in part as software, hardware, firmware or any other combination. In addition, the data processing circuit can be a single independent processing module, or any one of the other elements combined into the computer terminal 10 (or mobile device) in whole or in part. As referred to in the embodiments of the present application, the data processing circuit as a kind of processor control (for example, the selection of the variable resistance terminal path connected with the interface).

[0041] Memory 104 can be used to store software programs and modules for application software, such as the program instructions / data storage device corresponding to the IP multicast delay determination method in the embodiments of the present application. Processor 102 executes the software programs and modules stored in memory 104 to perform various functional applications and data processing, thereby implementing the IP multicast delay determination method for the aforementioned application. Memory 104 can include high-speed random access memory (RAM) and can also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, memory 104 can further include memory remotely located relative to processor 102, and such remote memory can be connected to computer terminal 10 via a network. Examples of such networks 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 configured to receive or transmit data via a network. A specific example of the aforementioned network may include a wireless network provided by the communications provider of the computer terminal 10. In one embodiment, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, the transmission device 106 may be a radio frequency (RF) module, which is configured 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 FIG. 1 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 includes at least steps S202-S206, wherein:

[0045] Step S202: Obtain a first 2-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 a specific receiver, a first monitoring point (e.g., a monitoring probe) can be deployed downstream of the network transmission path between the source device and the specific receiver (i.e., on the specific receiver side) to collect, parse, and process live video stream data downstream of the network transmission path, wherein the network transmission paths between the multicast source and different receivers are different. It should be noted that the optimal network transmission path between the source device and different receivers can be determined based on a specific routing multicast protocol, and this application does not impose any specific restrictions on the method for determining the network transmission path.

[0047] In addition, since a channel may play different programs at different times, the target program may be a program currently being played on the target channel. The first binary corresponding to the first reassembled TS stream includes: a first reception 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 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 multiple second two-tuples, each of which includes: a second reception timestamp of a second reassembled TS packet (preferably the first second reassembled TS packet) in a second reassembled TS stream of the target program received at any time within the current time period by a second monitoring point (e.g., a monitoring probe) deployed upstream of the network transmission path (i.e., the multicast source), and second feature data corresponding to the second reassembled TS stream. The second reassembled TS stream is obtained by the second monitoring point through parsing, program identification, and reassembly of IP multicast streams from multiple channels at various times within the current time period.

[0050] When using IP multicast technology to transmit live data, it needs to pass through multiple network devices before it can reach a specific receiving end. Therefore, during the transmission process, a network device failure may cause a delay between the multicast source and the playback end. To this end, the server can pre-cache multiple second binary data collected by the multicast source to obtain an upstream monitoring linked list buffer. Then, from the multiple second binary data in the upstream monitoring linked list buffer, it determines the target binary that is identical to the first feature data in the first binary, and determines whether the first reception timestamp in the first binary is identical to the second reception 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 and second reception timestamps are different, this indicates a time difference between the arrival timestamps of the same TS packet at the multicast source and the playback segment. This time difference is the IP multicast delay. Therefore, the server can determine the IP multicast delay of the target program between the upstream and downstream network transmission paths based on the first and second reception timestamps.

[0053] The method for determining the IP multicast delay of this embodiment is further described below.

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

[0055] The first monitoring node may obtain 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:

[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 sides can reach an agreement on the media parameters and transmission methods, which ensures that the IP multicast stream can correctly reach the playing end from the multicast source end. Therefore, the first monitoring node can extract the IP multicast stream of the plurality of channels at the current time through the live signaling protocol (Internet Control Message Protocol ICMP or Internet Group Management Protocol IGMP). The IP multicast stream refers to a continuous multimedia data stream transmitted through IP multicast technology, including a video stream and / or an audio stream. The stream is a continuous form in the data transmission process, and the plurality of data packets in the IP multicast data are components in the stream.

[0058] Step S2, the IP multicast stream is parsed, program identified and recombined to obtain the first recombined TS stream of the target program at the current time, and the first receiving timestamp of receiving the first recombined TS packet in the first recombined TS stream is determined.

[0059] Specifically, the first monitoring point can obtain the first recombined TS stream of the target program at the current time according to the following method, which includes:

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

[0061] That is, the first monitoring point can perform protocol parsing on the IP multicast stream to convert the payloads in the IP multicast data packets transmitted by the IP multicast 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, the packet header of the IP multicast data packet is parsed to determine the source address, destination address and other related parameters of the data packet, and the payloads in the extracted and parsed IP multicast data packets are extracted, wherein the payloads include multimedia data; finally, the multimedia data is encapsulated 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 one frame of data in the original multimedia data is packaged into one PES packet. Therefore, 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). These timestamp information provides a common time stamp for PES to ensure that the multimedia data can be played correctly and synchronously; since the data length corresponding to one frame of data is often greater than the fixed length of the TS packet (usually 188 bytes), a PES packet needs to be allocated to a series of fixed-length TS packets, so that the TS packet includes data segments of one or more PES packets with the same time base. In addition, each TS packet also includes timing information (Program Clock Reference, PCR) and program-specific information (Program Specific Information, PSI). 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). Among them, PAT is used to indicate 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. 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, a program mapping table (i.e., PMT / PAT) for identifying the programs contained in the first TS stream and the program information identifier 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 from 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 based on 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. These first target TS packets include data segments of PES packets such as video and audio of the target program.

[0067] Step S23: reassemble the multiple first TS packets in the first target TS stream to obtain multiple first reassembled TS packets, and form a first reassembled TS stream of the target program from the multiple first reassembled 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 based on 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 continuous counter for tracking the sequence of the PES packet data segments. If the continuous 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 start the packet assembly again.

[0071] After the first monitoring point obtains the first reassembled TS stream of the target program at the current moment through steps S21-S23, the first monitoring point may record the first reception timestamp of each first reassembled TS packet in the first reassembled TS stream. To reduce the data volume recorded by the first monitoring point, the first monitoring point may preferably record the first reception 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 reorganized TS packets in the first reorganized TS stream to obtain first characteristic data corresponding to the first reorganized TS stream of the target program at the current time.

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

[0074] Further, the first monitoring point can send the pair of the first reception timestamp (Tm) of the first reorganized TS packet and the first characteristic data (CHm) corresponding to the first reorganized TS stream in the above step S2 to the comparison calculation server in the json array text format or other transmissible format.

[0075] Considering that when transmitting data over a 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 pair of data sent by the first monitoring point, the first monitoring point can encrypt the first pair of data corresponding to the first reorganized TS stream of the target program at the current time according to the encryption key previously negotiated with the server, obtain encrypted data, and send the encrypted data to the server through the Http encrypted transmission method; and the server can decrypt the encrypted data according to the decryption key previously negotiated with the first monitoring point to obtain the first pair of data corresponding to the first reorganized TS stream. In addition, after the first monitoring point sends the first pair of data to the server, it will clear the relevant data in the buffer area and start collecting at the next time.

[0076] Similarly, the second monitoring point can refer to the above method to obtain a second pair of data corresponding to a plurality of second reorganized TS streams of the target program at a plurality of time periods in the current time period, wherein the second pair of data includes: a second reception timestamp (Ts) of the second monitoring point receiving a second reorganized TS packet in the second reorganized TS stream, second characteristic data (CHs) corresponding to the second reorganized TS stream, and is sent to the comparison calculation server in the json array text format or other transmissible format. Alternatively, the second monitoring point can encrypt the second pair of data corresponding to the second reorganized TS stream of the target program at a plurality of time periods in the current time period according to the encryption key previously negotiated with the server to obtain encrypted data; and the server can decrypt the encrypted data according to the decryption key previously negotiated with the second monitoring point to obtain the second pair of data corresponding to the second reorganized TS stream of the target program at a plurality of time periods in the current time period.

[0077] Since the second monitoring point obtains the second two-tuple in the same manner as the first monitoring point obtains the first two-tuple, we will not elaborate on this further. Furthermore, each time the second monitoring point sends the second two-tuple at a given moment to the server, it clears the relevant data in the cache and restarts the data collection at the next moment.

[0078] Furthermore, after the server receives the second tuples corresponding to multiple second reassembled TS streams of the target program at multiple moments in the current time period sent by the second monitoring point, it can aggregate 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, ensuring that the latest data is always at the head of the linked list.

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

[0080] Furthermore, the server may start from the tail of the upstream monitoring linked list buffer, and traverse the second feature data in each second tuple in the upstream monitoring linked list buffer from bottom to top, determine the target tuple that is the same as the first feature data in the first tuple, and determine whether the first reception timestamp in the first tuple is the same as the second reception timestamp in the target tuple, 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 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 analyze the IP multicast delay between the upstream and downstream of the target program's network transmission path to troubleshoot network devices along the target program's network transmission path, thereby comparing and analyzing the multicast delay of each network segment and identifying 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; the upstream monitoring node and the downstream monitoring node respectively collect live data at intervals of 1 second. 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 end of the upstream monitoring point linked list buffer (BUFs) and searches for CHs that are 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 as follows: the current time Tm of the downstream monitoring point - the Ts corresponding to the POSn position in the upstream monitoring point buffer (that is, the Ts corresponding to the CHs equal to the current CHm), and the Latency is cached.

[0090] Step 6: If no CHs is found that is equal to the current CHm, 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 - Ts of the POSn+1 position in the upstream monitoring point buffer, and cache the Latency;

[0093] Step 9: If there is no match, clear the Sync flag in the upstream monitoring point buffer, 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 10-second sampling interval and output it as the IP live broadcast latency sampling value.

[0095] Based on the scheme defined in steps S202 to S206 above, it can be seen that in an embodiment, the server deploys monitoring nodes respectively upstream and downstream of the network transmission path, and uses the monitoring nodes to collect the TS stream of a specific program, forming a binary data set containing the TS packet reception 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. The server then receives and stores the binary data from the upstream monitoring point, forms an upstream monitoring linked list buffer, and compares it with the binary characteristic data reported by the downstream monitoring point to find matching characteristic data. Once a target binary data matching characteristic data is found, the binary data reported by the downstream monitoring point is compared with the reception timestamp in the target binary data set. If the reception 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 reception timestamps. This effectively solves the problem that traditional delay measurement methods (such as Ping tests) cannot accurately measure the delay of one-way IP live broadcast. It not only provides real-time latency monitoring results, but also helps network operators locate latency bottlenecks and optimize networks, thereby significantly improving the quality of live video services and user satisfaction. This solves the technical problem that the network latency determined by related technologies using the Ping test method 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 structural diagram 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 for 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, 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 stream 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 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 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 received by the second monitoring point 12 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 and the second receiving timestamp are different, 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.

[0101] Specifically, the server 13 can construct the upstream monitoring linked list buffer according to the following method, including: obtaining the second tuple corresponding to the multiple second reassembled TS streams of the target program sent by the second monitoring point 13 at multiple moments 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 the 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. 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 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 the multiple programs under the target channel, the first reassembled TS stream is obtained by the first monitoring point parsing, program identification and reassembly of the IP multicast code streams of multiple channels at the current moment, and the multiple channels include at least the target channel; from the 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 reception timestamp in the first binary group is identical to 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 moment 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, 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 reception timestamp and the second reception timestamp.

[0106] According to an embodiment of the present application, a computer program product is further 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 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 the multiple programs under the target channel, the first reassembled TS stream is obtained by the first monitoring point parsing, program identification and reassembly of the IP multicast code streams of multiple channels at the current moment, and the multiple channels include at least the target channel; multiple channels in the preset upstream monitoring chain list buffer are received. Determine a target binary group that is identical to the first characteristic data in the first binary group in a second binary group, 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 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.

[0108] According to an embodiment of the present application, a processor is further 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 the multiple programs under the target channel, the first reassembled TS stream is obtained by the first monitoring point parsing, program identification and reassembly of the IP multicast code streams of multiple channels at the current moment, and the multiple channels include at least the target channel; multiple channels in the preset upstream monitoring chain list buffer are received. Determine a target binary group that is identical to the first characteristic data in the first binary group in a second binary group, 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 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.

[0110] According to an embodiment of the present application, an electronic device is further provided, wherein: Figure 5 is a schematic structural diagram 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, which, when executed by one or more processors, enables the one or more processors 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 implement the following steps by computer program execution: obtaining a first pair from the first monitoring point, the first pair corresponding to the first reorganized TS stream of the target program in the current time, wherein the first pair includes: the first receiving time stamp of the first monitoring point receiving the first reorganized TS package in the first reorganized TS stream and the first feature data corresponding to the first reorganized TS stream, the first monitoring point is arranged downstream of the network transmission path, the target program is any one of the plurality of programs of the target channel, the first reorganized TS stream is obtained by the first monitoring point analyzing, program identifying and reorganizing the IP multicast stream of the plurality of channels in the current time, and the plurality of channels at least includes the target channel; determining a target pair from the plurality of second pairs in the preset upstream monitoring chain buffer, the second pair including: the second receiving time stamp of the second monitoring point arranged upstream of the network transmission path receiving the second reorganized TS package in the second reorganized TS stream of the target program in the current time period at any time and the second feature data corresponding to the second reorganized TS stream, and determining whether the first receiving time stamp in the first pair is same as the second receiving time stamp in the target pair; in the case that the first receiving time stamp is not same as the second receiving time stamp, determining the IP multicast delay between the upstream of the network transmission path and the downstream of the network transmission path according to the first receiving time stamp and the second receiving time stamp.

[0112] The above sequence numbers of the embodiments of the present application are only for description, and do not represent the advantages and disadvantages of the embodiments.

[0113] In the above embodiments of the present application, the description of each embodiment has its own emphasis, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0114] In the several embodiments of the present application, it should be understood that the disclosed technology can be implemented in other ways. Of course, the unit embodiment described above is only schematic. For example, the division of the units can be a logical function division, and there can be another division manner in actual implementation, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interface, and can be electrical or other forms.

[0115] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, that is, they can be located in one place, or can be distributed on a plurality of units. According to actual needs, part or all of the units can be selected to achieve the purpose of the embodiment scheme.

[0116] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or 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 is essentially 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, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0118] The above is only a preferred embodiment 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 2-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 2-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 network protocol address IP multicast streams of a plurality of channels at a current moment, the plurality of channels including at least 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 reception timestamp in the first binary group is identical to a second reception timestamp in the target binary group, wherein the second binary group includes: a second reception timestamp of a second reassembled TS packet in a second reassembled TS stream of the target program received at any moment in a current time period by a second monitoring point deployed upstream of a network transmission path, and second characteristic data corresponding to the second reassembled TS stream; In a case where 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 a 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 two-tuple corresponding to the first recombined 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 a 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 stream to obtain a first reassembled TS stream of the target program at the current moment, and determining a first receiving timestamp of 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 stream to obtain a first reassembled TS stream of the target program at the current moment includes: Parsing the IP multicast stream to obtain a corresponding first TS stream, wherein the first TS stream includes a plurality of first TS packets, and the first TS packets include at least one packetized elementary stream (PES) packet having a same time base, a program identifier for identifying a program to which the PES packet belongs, and a program map 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 form a first reassembled TS stream of the target program.

5. The method according to claim 4, characterized in that Recombining the plurality of first target TS packets respectively to obtain a plurality of first recombined 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: Obtaining second 2-tuples corresponding to multiple second reassembled TS streams of the target program at multiple 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 table buffer includes: Starting from the tail of the upstream monitoring linked list buffer, the second feature data in each second binary group in the upstream monitoring linked list buffer is traversed sequentially from bottom to top to determine a target binary group that is identical to the first feature 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 the network transmission path, a second monitoring point deployed upstream of the network transmission path, and a server, wherein: The first monitoring point is configured to send a first 2-tuple corresponding to a first reassembled TS stream of a target program at a current moment to the server, wherein the first 2-tuple includes: a first reception 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 streams of a plurality of channels at a current moment; 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 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 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, 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.

9. The system according to claim 8, characterized in that The first monitoring point is further configured to extract the IP multicast streams of the multiple channels at the current moment through a live signaling protocol; parse, identify, and reassemble the IP multicast streams to obtain a first reassembled TS stream of the target program at the current moment; and determine 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.

10. The system according to claim 8, wherein: 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 moments 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 configured to run a program stored in the memory, wherein the program, when running, executes the IP multicast delay determination method according to any one of claims 1 to 7.

Images