Live broadcast streaming media UDP transmission control system and method based on PCDN

Abstract

The invention discloses a PCDN-based live streaming media UDP transmission control system and method, the system comprises a client, an edge PCDN node, a core CDN node and a central server, the client is started to request an edge PCDN node list and standby CDN node information from the central server, the most suitable PCDN node is selected according to the priority, and connection is established to request content. And the edge PCDN node determines a content transmission path according to the network condition and the priority, and obtains the content from the CDN node for standby application. And the central server monitors node states in real time, adjusts priorities or replaces node information. According to the hybrid architecture collaborative optimization, dynamic network adaptation can be realized, and congestion can be accurately controlled.

Description

Technical Field

[0001] The present application relates to the field of CDN technology, and in particular to a live streaming media UDP transmission control system and method based on PCDN. Background Art

[0002] As cloud computing and AI become increasingly mature, users have greater and greater demands on the Internet. Therefore, in terms of network infrastructure services, CDN technology is used as the basis for transmission and distribution.

[0003] In existing CND technology, core nodes are deployed in IDC computer rooms and provide content distribution through dedicated bandwidth.

[0004] For live streaming, the principle is that the host pushes the stream to a CDN node, and viewers pull the stream directly from the CDN. However, existing CDN technologies are limited by their high cost, requiring dedicated bandwidth and expensive server maintenance. Furthermore, they have poor scalability, requiring manual capacity expansion to handle traffic spikes, and exhibit slow response times.

[0005] PCDN, based on CDN, uses home devices (such as set-top boxes and routers) as edge PCDN nodes to distribute content via P2P. Viewers prioritize streaming from PCDN nodes, and if that fails, they fall back to the CDN. The main technical drawbacks of PCDN are node instability, large fluctuations in home device online times, complex network NAT types, and PCDN's shared bandwidth, which leads to fluctuations in available bandwidth and can easily cause packet loss and latency. Summary of the Invention

[0006] To solve the technical problems existing in the prior art, this application provides a PCDN-based live streaming UDP transmission control system, including a client, edge PCDN nodes, core CDN nodes, and a central server, wherein:

[0007] The client starts up and requests a list of edge PCDN nodes and backup CDN node information from the central server. It selects the most appropriate PCDN node based on priority and establishes a connection to request content.

[0008] Edge PCDN nodes determine the content transmission path based on network conditions and priorities, and obtain content from CDN nodes as a backup.

[0009] The central server monitors the node status in real time, adjusts the priority or replaces the node information.

[0010] Furthermore, the client transmission control method is: using dual queues to process data packets, wherein:

[0011] One queue is an ordered queue: it stores normally received data packets sorted by sequence number to ensure continuous video playback;

[0012] The other queue is the out-of-order queue: it stores packets that arrive out of order. When the estimated round-trip time (SRTT) of a packet exceeds the time limit, the decoder is triggered to repair or request retransmission.

[0013] Furthermore, when the client detects a freeze, the processing method includes:

[0014] The client sends a control packet to the server every SRTT;

[0015] In an SRTT, if a decoder returns an error, it is considered a freeze event, and the freeze flag is turned on in the control packet sent to the server;

[0016] If a freeze event occurs but FEC is not enabled, the client turns on the FEC flag in the control packet sent to the server;

[0017] If a freeze event occurs and FEC is enabled, and FEC has been enabled for more than 3 SRTTs, the client will enable the key frame redundancy flag in the control packet sent to the server;

[0018] If lag occurs more than two times in a row after enabling keyframe redundancy (3 SRTT), close the connection, remove the node from the node list, and restart the stream.

[0019] If three consecutive nodes are judged to have line degradation, it is considered that the user's own network has degraded, and the video stream with a lower bit rate is pulled again.

[0020] Furthermore, when the client's continuous freeze is resolved, redundancy is turned off and high bitrate is restored.

[0021] Furthermore, it also includes adding FEC flag and freeze feedback field based on RTP / RTCP.

[0022] Furthermore, the method for controlling the number of concurrent processing of edge PCDN nodes includes:

[0023] The control packet sent by the client in each cycle includes feedback on whether there is a jam. If so, the jam statistics for the flow are increased by 1.

[0024] Count the number of traffic jams that occur in this traffic flow at intervals of N seconds.

[0025] The preset number of streams that can cause lag and the total number of streams are related to the number of streams;

[0026] If the allowed number of jams is exceeded, the bandwidth limit is considered reached, the number of concurrent connections will no longer be increased, and new stream pull requests will be rejected.

[0027] Furthermore, the control of the central server includes single-channel flow packet rate control and concurrent number control, where:

[0028] The packet rate control of the single-channel flow method is:

[0029] Maintain token bucket capacity and rate, and control data packet sending rate

[0030] Adjust the token bucket generation rate based on real-time SRTT;

[0031] Methods for controlling the number of concurrent connections include:

[0032] Count the number of stuck flows within the set statistical period (such as every second);

[0033] If the number of stuck flows exceeds the preset threshold, the concurrency limit is dynamically adjusted: the number of allowed stuck flows increases to a certain level.

[0034] The present application also provides a PCDN-based live streaming media UDP transmission control method, which is applied to the PCDN-based live streaming media UDP transmission control system, comprising the following steps:

[0035] The client starts up and requests a list of edge PCDN nodes and backup CDN node information from the central server. It selects the most appropriate PCDN node based on priority and establishes a connection to request content.

[0036] Edge PCDN nodes determine the content transmission path based on network conditions and priorities, and obtain content from CDN nodes as a backup.

[0037] The central server monitors the node status in real time, adjusts the priority or replaces the node information.

[0038] The present invention also provides a storage medium on which a computer program is stored. When the computer program is run by a processor, the live streaming media UDP transmission control method based on PCDN is executed.

[0039] The present invention also provides an electronic device, comprising: a processor, a storage medium and a bus, wherein the storage medium stores machine-readable instructions executable by the processor. When the electronic device is running, the processor and the storage medium communicate via the bus, and the processor executes the machine-readable instructions to perform the PCDN-based live streaming media UDP transmission control method as described.

[0040] In actual applications, the modules described in the system and method disclosed in this application can be deployed in multiple modules on one target server, or each module can be independently deployed on a different target server. In particular, as needed, in order to provide more powerful computing processing capabilities, the modules can also be deployed on cluster target servers as needed.

[0041] It can be seen that the technical effects achieved by the technology adopted in this application are:

[0042] 1. Dynamic network adaptation: The packet rate is adjusted in real time based on SRTT and lag feedback to adapt to fluctuations in PCDN node bandwidth.

[0043] 2. Accurately control congestion: Combine packet loss rate and jam statistics to avoid misjudgment based on traditional single-dimensional metrics.

[0044] 3. Intelligent redundancy strategy: Enable FEC and key frame redundancy on demand to reduce retransmission costs while ensuring image quality.

[0045] 4. Hybrid architecture collaborative optimization: The core network uses CDN to ensure stability, and PCDN is prioritized at the edge to reduce costs.

[0046] In order to have a clearer and more comprehensive understanding of the present application, the specific implementation methods of the present application are described in detail below with reference to the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] To more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of the present application. Those skilled in the art can also derive other drawings based on these drawings without inventive effort.

[0048] Figure 1 This is a structural diagram of a PCDN-based live streaming UDP transmission control method according to an embodiment of the present application.

[0049] Figure 2 This is a flow chart of a method for controlling UDP transmission of live streaming media based on PCDN according to an embodiment of the present application. DETAILED DESCRIPTION

[0050] The technical solution of the present application is a live streaming UDP transmission control method based on PCDN. It uses a hybrid CDN and PCDN architecture, combining the core CND and edge PCDN to optimize content distribution and network stability. The client obtains a list of PCDN nodes (including priority) of the same operator and region from the central server. If the edge PCDN node is unavailable or has a low priority, the client will select a backup CDN node, which can effectively reduce latency and improve user experience.

[0051] The specific technical solution of this application is: a PCDN-based live streaming UDP transmission control system, including a client, edge PCDN nodes, core CDN nodes and a central server, wherein:

[0052] The client starts up and requests a list of edge PCDN nodes and backup CDN node information from the central server. It selects the most appropriate PCDN node based on priority and establishes a connection to request content.

[0053] Edge PCDN nodes determine the content transmission path based on network conditions and priorities. When necessary, they can also obtain content from CDN nodes as a backup.

[0054] The central server monitors the node status in real time, adjusts the priority or replaces the node information.

[0055] Core CDN nodes (i.e. core network nodes) include but are not limited to the following functions:

[0056] 1. Backup / core content distribution nodes

[0057] 2. Located in the backbone network, providing high stability and capacity

[0058] 3. Connect to the central server and receive content synchronization

[0059] The core CDN nodes serve as backup nodes, supporting content transmission of the entire system and ensuring the stability of the backbone network.

[0060] The technical solution of the present application is described in detail below with reference to various specific embodiments.

[0061] The client (user device) includes but is not limited to the following functions:

[0062] 1. Actual content request (PC, mobile phone, smart device);

[0063] 2. Establish a connection with the local PCDN node or CDN node;

[0064] 3. Obtain neighboring node information from the central server;

[0065] The client transmission control method is to use dual queues to process data packets, where:

[0066] One queue is an ordered queue: it stores normally received data packets sorted by sequence number to ensure continuous video playback;

[0067] The other queue is the out-of-order queue: it stores packets that arrive out of order. When the SRTT (estimated round-trip time) of a packet exceeds the timeout, the decoder is triggered to repair or request retransmission.

[0068] A freeze generally refers to when the player has to pause to wait for more data to arrive because there is not enough data to continue playing. In the embodiment of the present application, an error that the decoder cannot handle is also regarded as a freeze, and other technical features are combined to solve the technical problems of the present application.

[0069] As a preferred embodiment, if a jam, especially a continuous jam, is detected during the transmission process, it will seriously affect the transmission experience. The processing method includes:

[0070] The client sends a control packet to the server every SRTT;

[0071] In an SRTT, if a decoder returns an error, it is considered a freeze event, and the freeze flag is turned on in the control packet sent to the server;

[0072] If a freeze event occurs but FEC is not enabled, the client turns on the FEC flag in the control packet sent to the server;

[0073] If a freeze event occurs and FEC is enabled, and FEC has been enabled for more than 3 SRTTs, the client will enable the key frame redundancy flag in the control packet sent to the server;

[0074] If lag occurs more than two times in a row after enabling keyframe redundancy (3 SRTT), close the connection, remove the node from the node list, and restart the stream.

[0075] If three consecutive nodes are judged to have line degradation, it is considered that the user's own network has degraded, and the video stream with a lower bit rate is pulled again.

[0076] In addition, it is also necessary to consider using network recovery methods, that is, after the client's continuous lag is resolved, turn off redundancy and restore high bitrate.

[0077] Based on the above solution, this application also includes adding protocol extensions, namely control packet fields, and adding FEC flags and jamming feedback fields on the basis of RTP / RTCP. As a specific implementation method, it includes:

[0078] When data packets (RTP) are sent:

[0079] New control fields (FEC flag, redundancy information, etc.) are added to the extended portion of the RTP header, and corresponding flags are set based on network status and redundancy policies. This allows the receiver to know whether each packet carries redundancy and whether it is key frame redundancy, facilitating decoding and repair.

[0080] Receiver:

[0081] Parse RTP extension fields to identify whether FEC and key frame redundancy are enabled;

[0082] Perform corresponding processing (such as repair, request retransmission) based on the control information.

[0083] Feedback mechanism:

[0084] The client continuously reports information such as freezes, jitters, and packet losses to the sender through RTCP, which can help the client adjust its strategy based on the feedback (enabling FEC, adjusting the bit rate, switching nodes, etc.).

[0085] The protocol extension solution enables clients and servers to collaborate more intelligently and dynamically to respond to network changes, improving the stability and experience of streaming media.

[0086] Edge PCDN nodes include but are not limited to the following functions:

[0087] 1. Edge distribution nodes, storing and transmitting content;

[0088] 2. Connect to the user's home network;

[0089] 3. Connect to the central server to obtain node information;

[0090] 4. Coordinate distribution with neighboring PCDN nodes (optional).

[0091] Edge PCDN nodes, consisting of home devices, set-top boxes, routers, etc., undertake the main content distribution tasks. Being close to users, they can quickly respond to content requests and reduce the pressure on the core network.

[0092] The technical solution for overall concurrent control of edge PCDN nodes in this application is as follows:

[0093] The network environment and device performance of different nodes vary greatly. Some nodes have poor network conditions, low bandwidth, or poor performance, and can only handle a single digit of stream pull requests concurrently. On the other hand, other nodes have high bandwidth and advanced configurations, and can handle dozens or even hundreds of stream pull requests concurrently.

[0094] Because PCDN network bandwidth is shared and available bandwidth is not fixed, concurrency control is a challenge: how should the number of concurrent requests be controlled? How can we determine whether the bandwidth limit has been reached and new stream pull requests cannot be responded to?

[0095] Traditional CDN nodes have fixed bandwidth, and this problem can be determined based solely on current bandwidth usage. However, PCDN nodes cannot use this method. Previously, the industry's common practice was to determine the overall packet loss rate. The specific calculation logic is as follows:

[0096] 1. Take 5 to 10 seconds as a statistical period;

[0097] 2. Count the number of packets sent and lost for each flow;

[0098] 3. Add up the number of packets sent and the number of packets lost for all flows to calculate the overall packet loss rate. The calculation formula is: Total packet loss rate = total number of packets lost / total number of packets sent * 100;

[0099] 4. If the total packet loss rate reaches a certain threshold, such as 2%, it is considered that the bandwidth limit has been reached, the number of concurrent connections will no longer be increased, and new stream pull requests will be rejected.

[0100] However, the above method has its shortcomings. As technology advances, decoders are becoming more tolerant of packet loss, and different video streams have different tolerance requirements for packet loss. Simply using packet loss rate to determine whether the upper limit has been reached is no longer sufficient, and additional criteria are needed.

[0101] The present application provides a more preferred implementation method, which introduces jamming as a new evaluation method. An error that the decoder cannot handle is also considered a jam.

[0102] The specific calculation logic is as follows:

[0103] The control packet sent by the client in each cycle includes feedback on whether there is a jam. If so, the jam statistics for the flow are increased by 1.

[0104] Count the number of traffic jams in the traffic flow with an interval of N seconds, for example, 5 to 10 seconds.

[0105] The number of streams that are allowed to be stuck and the total number of streams are preset. For example, if the total number is <= 3, 3 streams are allowed; if the total number is <= 10, 5 streams are allowed; if the total number is > 10, 50% of the streams are allowed; and if the total number is > 20, 30% of the streams are allowed.

[0106] If the allowed number of jams is exceeded, the bandwidth limit is considered reached, the number of concurrent connections will no longer be increased, and new stream pull requests will be rejected.

[0107] In addition, edge PCDN nodes report their current status to the central server via the API every minute. When the central server assigns a node list to a client, it excludes nodes with full bandwidth.

[0108] In this application, the central server (Control Server) includes but is not limited to the following functions:

[0109] 1. Responsible for managing node information (PCDN and CDN node lists);

[0110] 2. Process client requests and provide node priority information;

[0111] 3. Monitor node status and dynamically adjust priority.

[0112] In the embodiment of the present application, the control of the central server includes single-channel flow packet rate control and concurrent number control, wherein:

[0113] The packet rate control of the single-channel flow method is:

[0114] Maintain the token bucket capacity and rate, and control the data packet sending rate.

[0115] Adjust the token bucket generation rate according to the real-time SRTT, such as reducing the rate when the network condition deteriorates.

[0116] An example: 1080p video (8Mbps) → payload 1452 bytes / packet → approximately 0.7ms / packet interval. The specific implementation method is:

[0117] Baseline rate: Based on the original video bit rate (such as 8Mbps).

[0118] Adjust the target rate: Set the target rate to 1.5-2 times the original bit rate (for example, 12-16Mbps) to ensure there is redundant buffer space.

[0119] Packet size: 1452 bytes (payload) corresponds to a packet interval of approximately 0.7 ms (calculated based on the bit rate).

[0120] The single-stream method combines the client's SRTT to estimate the delay and video bit rate to calculate the target transmission rate, which can avoid overload.

[0121] SRTT, or smoothed RTT, is the round-trip time (RTT) calculated using the Exponential Weighted Moving Average (EWMA) method.

[0122] Methods for controlling the number of concurrent connections include:

[0123] Count the number of stuck flows within the set statistical period (such as every second);

[0124] If the number of stuck flows exceeds the preset threshold, the concurrency limit is dynamically adjusted: the number of allowed stuck flows is increased by 30% (that is, the total limit is increased to 1.3 times the preset value), maintaining a certain degree of flexibility.

[0125] Concurrency control maintains overall system stability and avoids a decline in overall service quality due to sudden freezes.

[0126] Based on the above embodiment, a method for controlling UDP transmission of live streaming media based on PCDN in an embodiment of the present application includes the following steps:

[0127] The client starts up and requests a list of edge PCDN nodes and backup CDN node information from the central server. It selects the most appropriate PCDN node based on priority and establishes a connection to request content.

[0128] Edge PCDN nodes determine the content transmission path based on network conditions and priorities, and obtain content from CDN nodes as a backup.

[0129] The central server monitors the node status in real time, adjusts the priority or replaces the node information.

[0130] An embodiment of the present application further provides a storage medium having a computer program stored thereon. When the computer program is executed by a processor, the live streaming media UDP transmission control method based on PCDN is executed.

[0131] An embodiment of the present application also provides an electronic device, comprising: a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor. When the electronic device is running, the processor and the storage medium communicate via the bus, and the processor executes the machine-readable instructions to perform any of the PCDN-based live streaming media UDP transmission control methods described above.

[0132] It should be noted that, those skilled in the art can understand that all or part of the split steps in the various methods of the above embodiments can be completed by instructing related hardware through a computer program, and the computer program can be stored in a computer-readable storage medium, and the storage medium can include but is not limited to: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0133] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present application. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application is not limited to the embodiments shown herein, but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A live streaming media UDP transmission control system based on PCDN, characterized by: It includes clients, edge PCDN nodes, core CDN nodes, and central servers, including: The client starts up and requests a list of edge PCDN nodes and backup CDN node information from the central server. It selects the most appropriate PCDN node based on priority and establishes a connection to request content. Edge PCDN nodes determine the content transmission path based on network conditions and priorities, and obtain content from CDN nodes as a backup. The central server monitors the node status in real time, adjusts the priority or replaces the node information.

2. The PCDN-based live streaming UDP transmission control system according to claim 1, wherein: The client transmission control method is to use dual queues to process data packets, where: One queue is an ordered queue: it stores normally received data packets sorted by sequence number to ensure continuous video playback; The other queue is the out-of-order queue: it stores packets that arrive out of order. When the estimated round-trip time (SRTT) of a packet exceeds the time limit, the decoder is triggered to repair or request retransmission.

3. The PCDN-based live streaming UDP transmission control system according to claim 1 or 2, wherein: When the client detects a freeze, it handles it in the following ways: The client sends a control packet to the server every SRTT; In an SRTT, if a decoder returns an error, it is considered a freeze event, and the freeze flag is turned on in the control packet sent to the server; If a freeze event occurs but FEC is not enabled, the client turns on the FEC flag in the control packet sent to the server; If a freeze event occurs and FEC is enabled, and FEC has been enabled for more than a certain number of SRTTs, the client will enable the key frame redundancy flag in the control packet sent to the server; If lag occurs more than two times in a row after enabling keyframe redundancy for several SRTTs, close the connection, remove the node from the node list, and restart the stream. If three consecutive nodes are judged to have line degradation, it is considered that the user's own network has degraded, and the video stream with a lower bit rate is pulled again.

4. The PCDN-based live streaming UDP transmission control system according to claim 3, wherein: When the client's continuous freezing is resolved, disable redundancy and restore high bitrate.

5. The PCDN-based live streaming media UDP transmission control system according to claim 1, wherein: It also includes adding FEC flag and freeze feedback field based on RTP / RTCP.

6. The PCDN-based live streaming UDP transmission control system according to claim 1, wherein: Methods for controlling the number of concurrent processing operations of edge PCDN nodes include: The control packet sent by the client in each cycle includes feedback on whether there is a jam. If so, the jam statistics for the flow are increased by 1. Count the number of traffic jams that occur in this traffic flow at intervals of N seconds. The preset number of streams that can cause lag and the total number of streams are related to the number of streams; If the allowed number of jams is exceeded, the bandwidth limit is considered reached, the number of concurrent connections will no longer be increased, and new stream pull requests will be rejected.

7. The PCDN-based live streaming UDP transmission control system according to claim 1, wherein: The central server controls include single-channel packet rate control and concurrent number control, where: The packet rate control of the single-channel flow method is: Maintain token bucket capacity and rate, and control data packet sending rate Adjust the token bucket generation rate based on real-time SRTT; Methods for controlling the number of concurrent connections include: Count the number of stuck flows within the set statistical period (such as every second); If the number of stuck flows exceeds the preset threshold, the concurrency limit is dynamically adjusted: the number of allowed stuck flows increases to a certain level.

8. A method for controlling UDP transmission of live streaming media based on PCDN, applied to the UDP transmission control system of live streaming media based on PCDN according to any one of claims 1 to 7, characterized in that: The steps include: The client starts up and requests a list of edge PCDN nodes and backup CDN node information from the central server. It selects the most appropriate PCDN node based on priority and establishes a connection to request content. Edge PCDN nodes determine the content transmission path based on network conditions and priorities, and obtain content from CDN nodes as a backup. The central server monitors the node status in real time, adjusts the priority or replaces the node information.

9. A storage medium having a computer program stored thereon, wherein the computer program is executed by a processor to execute the PCDN-based live streaming media UDP transmission control method.

10. An electronic device, characterized in that: include: A processor, a storage medium and a bus, wherein the storage medium stores machine-readable instructions executable by the processor. When the electronic device is running, the processor and the storage medium communicate via the bus, and the processor executes the machine-readable instructions to perform the PCDN-based live streaming UDP transmission control method as described in claim 9.

Images