Unicast and multicast collaborative live broadcast stream processing method and system
By adopting a live stream processing method that cooperates with unicast and multicast in CDN live broadcast, using unicast data to compensate for the problem of slow multicast start-up and smooth splicing processing, the problems of large unicast bandwidth overhead and large multicast delay in the prior art are solved, and the starting speed and user experience of live broadcast are improved.
Patent Information
- Application Number
- CN202311667841.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-12-06
- Publication Date
- 2025-06-06
AI Technical Summary
In the existing CDN live broadcast technology, the overhead of unicast transmission bandwidth is large, and the multicast transmission delays during the onset stage affecting the user experience.
The live stream processing method that cooperates with unicast and multicast is adopted. When the edge CDN node receives user requests, it initiates unicast and multicast requests at the same time. It uses unicast data to compensate for the slow multicast start-up problem, and smoothly splicing the multicast and unicast data when the unicast request stops unicast to ensure the continuity of live broadcast.
Through the collaboration between unicast and multicast, the use of network bandwidth resources is reduced, the starting speed and viewing quality is improved, the continuity of live broadcast is ensured, and the user experience is improved.
Smart Images

Figure CN120111257A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of Internet multimedia technology, and in particular to a live streaming processing method and system for unicast and multicast collaboration. Background Art
[0002] In CDN (Content Delivery Network) live broadcast, unicast and multicast are commonly used data transmission methods. Unicast is a one-to-one communication mode between hosts. The devices in the network select the transmission path according to the destination address contained in the network message, transmit the unicast message to the specified destination, and only forward the received data without copying it; multicast is a one-to-many communication mode between hosts. It is a technology that allows one or more multicast sources to send the same message to multiple receivers.
[0003] Most of the existing CDN live broadcast technologies use unicast to pull CDN source site content through edge nodes. As the demand for video services continues to grow, the overall bandwidth overhead of unicast transmission is much greater than that of multicast transmission. In addition, when there are many users watching the live broadcast, there is a lot of congested traffic, which can easily affect the live broadcast viewing effect.
[0004] Some CDN operators have constructed network infrastructure that supports multicast transmission, which can effectively reduce the use of network bandwidth resources. However, multicast transmission has a large delay at the start of live broadcast, which will result in a long waiting time for the first screen of live broadcast viewing, seriously affecting the user experience. Summary of the invention
[0005] The purpose of the present invention is to solve the above-mentioned deficiencies in the prior art, and to provide a live streaming processing method and system for unicast and multicast collaboration, which utilizes unicast data to compensate for the slow start of multicast live streaming. When the unicast request is stopped, the multicast data and the unicast data are smoothly spliced to ensure the continuity of the live streaming.
[0006] In order to solve the above technical problems, the technical solution of the present invention provides a live streaming processing method for unicast and multicast collaboration, involving a source CDN node and an edge CDN node; comprising:
[0007] Step 1: When the edge CDN node receives a user's request for the target live streaming data, it simultaneously initiates unicast and multicast requests to the source CDN node;
[0008] Step 2: The edge CDN node determines the source of the first live streaming data from the source CDN node: if the source is from multicast, execute step 3; if the source is from unicast, execute step 4;
[0009] Step 3: Disconnect the unicast request, obtain the multicast service data based on the live streaming data from the multicast, and store it in the first cache area of the edge CDN node to directly serve the user;
[0010] Step 4: Based on the live streaming data from unicast, obtain unicast service data and store it in the first cache area of the edge CDN node to directly serve users; based on the live streaming data from multicast, obtain multicast service data and store it in the second cache area of the edge CDN node until the unicast service data in the first cache area overlaps with the multicast service data in the second cache area, and the unicast request is disconnected; all multicast service data in the second cache area are merged into the first cache area, the second cache area is deleted, and subsequent multicast service data is stored in the first cache area, and the multicast service data is used to serve users.
[0011] As an improvement of the above method, step 4 includes:
[0012] Step 4-1: Determine whether the unicast request has been stopped. If it is stopped, discard the live stream data from the unicast. Otherwise, execute step 4-2.
[0013] Step 4-2: parsing the live stream data from the unicast to obtain the live stream audio and video coding information or audio and video data as the unicast service data;
[0014] Step 4-3: Determine whether the live streaming data from the multicast has not been received. If it is determined that the live streaming data has not been received, store the unicast service data in the first buffer area for serving the user; otherwise, execute step 4-4;
[0015] Step 4-4: Store the unicast service data in the first cache area for serving users; parse the live stream data from the multicast, obtain the multicast service data and store it in the second cache area of the edge CDN node; determine whether the timestamp of the current unicast service data is greater than or equal to the smallest timestamp in the second cache area. If it is yes, stop the unicast request, merge all the multicast service data in the second cache area into the first cache area, delete the second cache area, store subsequent multicast service data in the first cache area, and use the multicast service data to serve users. Otherwise, continue to store the unicast service data in the first cache area for serving customers until the timestamp of the unicast service data is greater than or equal to the smallest timestamp in the second cache area.
[0016] As an improvement of the above method, all the multicast service data in the second cache area are merged into the first cache area, specifically including: comparing the multicast service data in the second cache area with the unicast service data in the first cache area one by one, and inserting the multicast service data in the second cache area into the appropriate position of the first cache area according to the sorting of timestamps from small to large; if the timestamp of the multicast service data in the second cache area is equal to that of the unicast service data in the first cache area, discarding the multicast service data.
[0017] As an improvement of the above method, in the first cache area, unicast service data and / or multicast service data as live service data to be sent to users are stored in ascending order of timestamps; in the second cache area, multicast service data are temporarily stored in ascending order of timestamps; and the live service data in the first cache area are continuously dequeued and sent to users.
[0018] As an improvement to the above method, the unicast service data is complete audio data or video data parsed from live streaming data acquired in a unicast manner.
[0019] As an improvement of the above method, the multicast service data is complete audio data or video data obtained by segmenting and reassembling the live streaming data obtained by multicast.
[0020] As an improvement of the above method, the first live streaming data from multicast is: live streaming data containing live streaming audio and video encoding information obtained by the edge CDN node from the CDN multicast transmission network.
[0021] As an improvement of the above method, the first live streaming data from unicast is: the live streaming data containing the live streaming audio and video encoding information in the starting part obtained by the edge CDN node from the source CDN node.
[0022] To achieve another object of the present invention, the present invention further provides a live streaming processing system for unicast and multicast collaboration, comprising: a source CDN node and an edge CDN node; wherein,
[0023] The edge CDN node is used to initiate unicast and multicast requests to the source CDN node when receiving a user's request for target live streaming data;
[0024] The edge CDN node is used to determine the source of the first live streaming data from the source CDN node:
[0025] When the source is from multicast, the edge CDN node is used to disconnect the unicast request, obtain the multicast service data based on the live streaming data from the multicast, and store it in the first buffer area of the edge CDN node to directly serve the user;
[0026] When the source is from unicast, the edge CDN node obtains unicast service data based on the live stream data from unicast and stores it in the first cache area of the edge CDN node to directly serve users; obtains multicast service data based on the live stream data from multicast and stores it in the second cache area of the edge CDN node until the unicast service data in the first cache area overlaps with the multicast service data in the second cache area, and disconnects the unicast request; merges all the multicast service data in the second cache area into the first cache area, deletes the second cache area, stores subsequent multicast service data in the first cache area, and uses the multicast service data to serve users.
[0027] Compared with the prior art, the advantages of the present invention are: through the coordination of unicast and multicast, unicast is used to make up for the problem of long first screen waiting time caused by slow processing of multicast in the start-up stage, and the start-up speed and viewing quality are improved by caching the audio and video encoding information and several video key frame data of the live stream; when the unicast request is disconnected, the unicast and multicast data are smoothly spliced to ensure the continuity of the live broadcast. BRIEF DESCRIPTION OF THE DRAWINGS
[0028] Figure 1 It is a flow chart of a live streaming processing method for unicast and multicast collaboration;
[0029] Figure 2 This is the data distribution process when the source CDN node and the edge CDN node serve the target flow of the present invention;
[0030] Figure 3 This is the processing flow of receiving unicast data by the edge CDN node of the present invention;
[0031] Figure 4 This is the processing flow of receiving multicast data by the edge CDN node of the present invention;
[0032] Figure 5 It is the data unit structure of the live streaming based on HTTPFLV protocol of the present invention;
[0033] Figure 6 This is an example of the process of storing unicast data units received by the edge CDN node of the present invention;
[0034] Figure 7 This is an example of a process in which an edge CDN node of the present invention first receives multicast data unit data and stores it. DETAILED DESCRIPTION
[0035] The technical solution provided by the present invention is further described below in conjunction with embodiments.
[0036] Example 1
[0037] like Figure 1 As shown, this embodiment is a live streaming processing method for unicast and multicast collaboration, involving users, source CDN nodes and edge CDN nodes;
[0038] When the edge CDN node receives a user's request for the target live stream, it simultaneously initiates unicast and multicast requests to the source CDN node;
[0039] The edge CDN node determines the source of the first live data unit received:
[0040] (1) If the request comes from multicast, the unicast request is disconnected, the multicast data unit is stored in the first buffer, and the user is directly served;
[0041] (2) If the data is from unicast, the unicast data unit is stored in the first buffer area to directly serve the user; the received multicast data unit is stored in the second buffer area until the data in the first buffer area overlaps with the data in the second buffer area, the unicast request is disconnected, all the data in the second buffer area is merged into the first buffer area, the second buffer area is deleted, and the subsequent multicast data units are stored in the first buffer area, and the multicast data is used to serve the user.
[0042] Preferably, the first cache area of the edge CDN node stores live data units to be sent to users, and the second cache area temporarily stores multicast live data units; the live data units stored in each cache area are arranged in order from small to large according to the timestamp in the data unit; the live data units in the first cache area are continuously dequeued and sent to users.
[0043] Preferably, the first live data unit, if it originates from unicast, is a live data unit containing audio and video coding information of the live stream in the starting part of the live stream data obtained by the edge CDN node from the source CDN node; if it originates from multicast, it refers to a live data unit or an audio and video live data unit containing audio and video coding information of the live stream obtained by the edge CDN node from the CDN multicast transmission network.
[0044] Preferably, the unicast data unit refers to a complete audio data or video data parsed from a live stream obtained in a unicast manner.
[0045] Preferably, the multicast data unit refers to a complete audio data or video data obtained by reassembling multicast data fragments obtained in a multicast manner.
[0046] Preferably, the data in the first buffer area overlaps with the data in the second buffer area, which means that the maximum timestamp value in the live data unit in the first buffer area is greater than or equal to the minimum timestamp value in the live data unit in the second buffer area.
[0047] Preferably, all the data in the second cache area are merged into the first cache area. Specifically, the data in the second cache area are compared with the data in the first cache area one by one, sorted from small to large according to the timestamp, and the data in the second cache area are inserted into the appropriate position of the first cache area; if the timestamp of the data in the second cache area is equal to that of the data in the first cache area, the data is discarded and not merged into the first cache area.
[0048] Preferably, the edge CDN node saves or updates the audio and video encoding information and several video key frame data of the live stream during the live stream data processing process, and the number of video key frame data can be configured. When receiving a request for the same target stream, the live stream audio and video encoding information and the latest video key frame data within the user-specified time range can be directly sent to the user.
[0049] The technical solution of the present invention will be described in detail below with reference to the accompanying drawings and embodiments.
[0050] like Figure 2 The following figure shows the data distribution process when the source CDN node and the edge CDN node serve the target flow:
[0051] The user watches the live broadcast and initiates a request for the target live stream to the edge CDN node;
[0052] When the HTTP service module of the edge CDN node receives a user's request for the target live stream, it initiates a unicast data request to the source CDN node through the unicast module; at the same time, it initiates a multicast request to the multicast source management of the source CDN node through the multicast edge management module;
[0053] As an improved implementation, if the edge CDN node is serving the target stream, the HTTP service module of the edge CDN node does not send unicast and multicast requests. The edge CDN node directly reads the data in the current first buffer queue, encapsulates it in HTTP format and sends it directly to the user. When sending data to the user for the first time, the live stream audio and video encoding information and the latest video key frame data need to be sent first.
[0054] The source CDN node receives a request for the target live stream and finds that the target stream is not being served. The unicast module aggregates unicast and multicast requests and pulls live data from the source station only once.
[0055] As an improved implementation, if the source CDN node is serving the target stream, the HTTP service module of the source CDN node encapsulates the data in the first buffer queue into HTTP format as unicast response data and sends it directly to the edge CDN node. When sending data to the edge CDN node for the first time, the live stream audio and video encoding information and the latest video key frame data need to be sent first.
[0056] The source CDN node receives and processes unicast data, sends the data to the unicast data module of the edge CDN node through the HTTP service module, and sends the unicast data to the multicast source management module for multicast data distribution. In the process of sending data to the edge CDN node, the HTTP service module of the source CDN node caches the decoding key data of the live stream and several live data units.
[0057] The process of receiving and processing unicast data by the unicast module of the edge CDN node is as follows: Figure 3 shown.
[0058] When unicast data is received, the processing steps are as follows:
[0059] S1: Determine whether the unicast request has been stopped, if so, discard the unicast data, otherwise go to the next step;
[0060] S2: Process the unicast data to obtain a unicast data unit, specifically, parse the unicast data stream to obtain live stream audio and video coding information or audio and video data.
[0061] In this step, the edge CDN node saves or updates the audio and video encoding information of the live stream and several video key frame data, and the number of video key frame data can be configured. When receiving a request for the same target stream, the audio and video encoding information of the live stream and the latest video key frame data within the user-specified time range can be directly sent to the user, so that the user can quickly start the broadcast and the first screen will not be black / distorted / green.
[0062] S3: Determine whether the multicast data unit has not been received, if yes, store the received unicast data unit in the first buffer; otherwise, go to the next step;
[0063] S4 determines whether the timestamp of the current unicast data unit is greater than or equal to the smallest timestamp in the second buffer area. If yes, the unicast request is stopped, all the data in the second buffer area is merged into the first buffer area, and the second buffer area is deleted. Otherwise, the received unicast data unit is stored in the first buffer area.
[0064] The process of receiving and processing multicast data by the multicast module of the edge CDN node is as follows: Figure 4 shown.
[0065] When multicast data is received, the processing steps are as follows:
[0066] S1: Processing multicast data to obtain multicast data units, specifically, reassembling the acquired multicast data fragments to obtain streaming audio and video coding information or audio and video data.
[0067] In this step, the edge CDN node saves or updates the audio and video encoding information of the live stream and several video key frame data, and the number of video key frame data can be configured. When receiving a request for the same target stream, the audio and video encoding information of the live stream and the latest video key frame data within the user-specified time range can be directly sent to the user, so that the user can quickly start the broadcast and the first screen will not be black / distorted / green.
[0068] S2: Determine whether the unicast request has been stopped, if yes, store the multicast data unit into the first buffer area, otherwise, go to the next step;
[0069] S3: Determine whether the unicast data unit has been received, if not, store the multicast data unit in the first buffer area, otherwise, go to the next step;
[0070] S4: Determine whether the largest timestamp in the first cache is greater than or equal to the smallest timestamp in the second cache area. If so, disconnect the unicast request, merge all the data in the second cache area into the first cache area, and delete the second cache area.
[0071] The HTTP service module of the edge CDN node continuously reads the data in the first cache area and sends it to the user.
[0072] Taking HTTP FLV live streaming as an example, the following provides a specific implementation method in the HTTP FLV live streaming data processing process.
[0073] When the edge CDN node initiates a unicast request to the source CDN node, it pulls the FLV stream data through the HTTP FLV protocol.
[0074] When the edge CDN node initiates a multicast request to the source CDN node, the source CDN node aggregates the unicast and multicast requests, obtains the FLV stream data from the unicast module, and then parses it into FLV format data units. If the content of the FLV format data unit plus the transport protocol header exceeds the MTU of the network transmission, the FLV format data unit is sliced and encapsulated in UDP, RTP or a custom format before sending.
[0075] like Figure 5As shown, the data unit in FLV format refers to: FLV header, script Tag (metadata), the first video Tag (including spspps information using h264) and the first audio Tag (including aac_header) information and subsequent audio and video tags. The FLV header, script Tag (metadata), the first video Tag (including spspps information using h264) and the first audio Tag (including aac_header) information are combined into a live data unit, which is a data unit containing the audio and video encoding information of the live stream, and is defined as an FLV key data unit. The subsequent audio and video tags are each a live data unit, wherein the video tag is divided into a normal video (P / B frame) tag and a key frame (I frame) tag. Except for the case where the FLV key data unit may not contain real-time decoding timestamp information, the remaining data units all contain decoding timestamp information.
[0076] The unicast module of the edge CDN node receives the unicast data, that is, the data in the HTTP FLV protocol format, parses the data unit in the FLV format, and submits it to the HTTP service module.
[0077] The multicast module of the edge CDN node receives the fragmented FLV multicast data, performs out-of-order re-arrangement and out-of-packet processing, assembles the data unit in FLV format, and submits it to the HTTP service module.
[0078] The following uses the HTTP service module of the edge CDN node to preferentially receive the first live broadcast data from unicast as a specific implementation method.
[0079] The HTTP service module first receives the FLV key data unit from the unicast, saves or updates the FLV key data unit, and stores it in the first buffer area, ready to serve the user.
[0080] The HTTP service module subsequently receives the multicast FLV data unit and determines whether it is an FLV key data unit. If so, it saves or updates the FLV key data unit; otherwise, it stores it in the second cache area. If it is FLV video key frame data, it stores it in the cache area of video key frame data. If the number of video key frame data exceeds the specified number, the old video key frame data is deleted from the header.
[0081] The HTTP service module subsequently receives the FLV audio or video data unit from the unicast and stores it in the first buffer area; if it is FLV video key frame data, it is stored in the video key frame data buffer area. If the number of video key frame data exceeds the limit, the old video key frame data is deleted from the header.
[0082] If the largest decoding timestamp in the first buffer is greater than or equal to the smallest decoding timestamp in the second buffer, the unicast request is disconnected, all data in the second buffer is merged into the first buffer, the second buffer is deleted, and multicast data is used to serve users in the future.
[0083] For the above situation, an embodiment and Figure 6 , explaining the specific process of data processing.
[0084] When the source CDN node is serving the target stream, the edge CDN node carries the fast start parameter equal to -3000 and requests to pull the target stream, that is, pulls the historical data of 3000 milliseconds before the live data provided by the current source CDN node to respond to the user.
[0085] After the source CDN node receives the unicast request from the edge CDN node, it finds the position of -3000 in the cache area of the video key frame data. For example, if it happens to fall on the live data unit with the timestamp value ts=100, the unicast data received by the edge CDN node is the live data unit starting with the timestamp value ts=100.
[0086] By default, multicast uses the latest data in the current network multicast transmission, such as the live data unit starting with the timestamp value ts=160.
[0087] At T0: the unicast module first collects the live data units with the timestamp value ts=100 and submits them to the HTTP service module, which puts them into the first buffer area.
[0088] The subsequent HTTP service module continues to put the received unicast data into the first buffer area; at the same time, the HTTP service module also continues to read the data in the first buffer area and sends it to the user.
[0089] At time T1, a unicast data unit with a timestamp value of ts=150 is received, but no multicast data unit has been received, so the unicast data unit with ts=150 is inserted into the first buffer.
[0090] At time T2, the received unicast data unit timestamp value ts=151 and the multicast data unit timestamp value ts=160 are inserted into the first buffer area, and the multicast data unit ts=160 is inserted into the second buffer area.
[0091] At time T3, the received unicast data unit timestamp value ts=160 and the multicast data unit timestamp value ts=180. At this time, the unicast request is disconnected, and the data in the second buffer area is merged into the first buffer area.
[0092] For another possible situation, the HTTP service module of the edge CDN node preferentially receives the first live broadcast data from the multicast as a specific implementation method.
[0093] The HTTP service module first receives the FLV key data unit from the multicast, saves or updates the FLV key data unit, stores it in the first buffer area, prepares to serve the user, and disconnects the unicast request.
[0094] The HTTP service module subsequently receives the multicast FLV data unit and stores it in the first buffer area to serve the user. If it is FLV video key frame data, it is stored in the video key frame data buffer area. If the number of video key frame data exceeds the limit, the old video key frame data is deleted from the head.
[0095] The HTTP service module subsequently receives the FLV audio or video data unit from the unicast and directly discards it. The unicast data may come from some residual data received by the unicast module when the unicast is disconnected.
[0096] For the above situation, the following Figure 7 , explaining the specific process of data processing.
[0097] Time T0: The multicast module first collects the live data units with the timestamp value ts=160 and submits them to the HTTP service module, which puts them into the first buffer and disconnects the unicast request.
[0098] At time T1, the residual data units of the received unicast request have timestamp values ts=100 and ts=101, and the multicast data unit has timestamp value ts=166. The unicast data units of ts=100 and ts=101 are directly discarded; the multicast data of ts=166 is inserted into the first buffer area.
[0099] Starting from time T2, only the subsequent multicast data unit timestamp values ts=170, ts=171, ... are received, and then ts=170, ts=171 and subsequent multicast data units are all inserted into the first buffer area.
[0100] Example 2
[0101] This embodiment takes the CDN-based live broadcast scenario as an example, and the entire system includes: users, live broadcast source stations, source CDN nodes, and edge CDN nodes. The source CDN node is composed of a multicast source management module, an HTTP service module, a unicast module, and a multicast module, and the edge CDN node is composed of a multicast edge management module, an HTTP service module, a unicast module, and a multicast module. Among them, the multicast source management module is placed in the source CDN node, which is responsible for the acquisition and distribution of multicast source data, and the multicast edge management module is placed in the edge CDN node, which is responsible for initiating multicast requests to the multicast source management module and maintaining the communication of information between nodes. The HTTP service module is responsible for receiving and processing HTTP live broadcast requests, initiating unicast / multicast requests, and maintaining two cache areas for processing live broadcast data units received from unicast and multicast modules, and continuously reading data from the first cache area and sending it to users. The unicast module is responsible for forwarding unicast requests, receiving and processing unicast data; the multicast module is responsible for receiving and processing multicast data.
[0102] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit the present invention. Although the present invention is described in detail with reference to the embodiments, it should be understood by those skilled in the art that any modification or equivalent replacement of the technical solutions of the present invention does not depart from the spirit and scope of the technical solutions of the present invention and should be included in the scope of the claims of the present invention.
Claims
1. A live streaming processing method for unicast and multicast collaboration, involving a source CDN node and an edge CDN node; include: Step 1: When the edge CDN node receives a user's request for the target live streaming data, it simultaneously initiates unicast and multicast requests to the source CDN node; Step 2: The edge CDN node determines the source of the first live streaming data from the source CDN node: if the source is from multicast, execute step 3; When the source is unicast, go to step 4; Step 3: Disconnect the unicast request, obtain the multicast service data based on the live streaming data from the multicast, and store it in the first cache area of the edge CDN node to directly serve the user; Step 4: Based on the live streaming data from unicast, obtain the unicast service data and store it in the first cache area of the edge CDN node to directly serve users; Based on the live streaming data from the multicast, the multicast service data is obtained and stored in the second cache area of the edge CDN node until the unicast service data in the first cache area overlaps with the multicast service data in the second cache area, and the unicast request is disconnected; All the multicast service data in the second buffer area are merged into the first buffer area, the second buffer area is deleted, subsequent multicast service data is stored in the first buffer area, and the multicast service data is used to serve users.
2. According to the method for processing live streams in collaboration of unicast and multicast according to claim 1, It is characterized in that The step 4 comprises: Step 4-1: Determine whether the unicast request has been stopped. If it is stopped, discard the live stream data from the unicast. Otherwise, execute step 4-2. Step 4-2: parsing the live stream data from the unicast to obtain the live stream audio and video coding information or audio and video data as the unicast service data; Step 4-3: Determine whether the live streaming data from the multicast has not been received. If it is determined that the live streaming data has not been received, store the unicast service data in the first buffer area for serving the user; otherwise, execute step 4-4; Step 4-4: Store the unicast service data in the first cache area for serving users; parse the live stream data from the multicast, obtain the multicast service data and store it in the second cache area of the edge CDN node; determine whether the timestamp of the current unicast service data is greater than or equal to the smallest timestamp in the second cache area. If it is yes, stop the unicast request, merge all the multicast service data in the second cache area into the first cache area, delete the second cache area, store subsequent multicast service data in the first cache area, and use the multicast service data to serve users. Otherwise, continue to store the unicast service data in the first cache area for serving customers until the timestamp of the unicast service data is greater than or equal to the smallest timestamp in the second cache area.
3. The live streaming processing method for unicast and multicast collaboration according to claim 1 or 2, It is characterized in that Merge all the multicast service data in the second cache area into the first cache area, specifically including: comparing the multicast service data in the second cache area with the unicast service data in the first cache area one by one, and inserting the multicast service data in the second cache area into the appropriate position of the first cache area according to the sorting of timestamps from small to large; if the timestamps of the multicast service data in the second cache area are equal to those of the unicast service data in the first cache area, discarding the multicast service data.
4. The method for processing live streams in collaboration of unicast and multicast according to claim 1, It is characterized in that In the first buffer area, unicast service data and / or multicast service data as live service data to be sent to the user are stored in ascending order of timestamps; In the second buffer area, multicast service data is temporarily stored in the order of timestamps from small to large; The live broadcast service data in the first buffer area is continuously dequeued and sent to the user.
5. The method for processing live streams in collaboration of unicast and multicast according to claim 1, It is characterized in that The unicast service data is complete audio data or video data parsed from live streaming data acquired in a unicast manner.
6. The method for processing live streams in collaboration of unicast and multicast according to claim 1, It is characterized in that The multicast service data is complete audio data or video data obtained by segmenting and reassembling the live streaming data obtained by multicast.
7. The method for processing live streams in collaboration of unicast and multicast according to claim 1, It is characterized in that The first live streaming data from multicast is: live streaming data containing live streaming audio and video encoding information obtained by the edge CDN node from the CDN multicast transmission network.
8. The method for processing live streams in collaboration of unicast and multicast according to claim 1, It is characterized in that The first live streaming data from unicast is: the live streaming data containing the live streaming audio and video encoding information in the starting part obtained by the edge CDN node from the source CDN node.
9. A live streaming processing system that combines unicast and multicast. include: Source CDN nodes and edge CDN nodes; among them, The edge CDN node is used to initiate unicast and multicast requests to the source CDN node when receiving a user's request for target live streaming data; The edge CDN node is used to determine the source of the first live streaming data from the source CDN node: When the source is from multicast, the edge CDN node is used to disconnect the unicast request, obtain the multicast service data based on the live streaming data from the multicast, and store it in the first buffer area of the edge CDN node to directly serve the user; When the source is from unicast, the edge CDN node obtains unicast service data based on the live stream data from unicast and stores it in the first cache area of the edge CDN node to directly serve users; obtains multicast service data based on the live stream data from multicast and stores it in the second cache area of the edge CDN node until the unicast service data in the first cache area overlaps with the multicast service data in the second cache area, and disconnects the unicast request; merges all the multicast service data in the second cache area into the first cache area, deletes the second cache area, stores subsequent multicast service data in the first cache area, and uses the multicast service data to serve users.