阅读说明：本技术 直播推流回源方法及系统 (Live broadcast plug flow source returning method and system ) 是由 孙袁袁 于 2021-08-11 设计创作，主要内容包括：本申请公开了一种直播推流回源方法,包括：实时采集所有边缘计算节点上的流转推状态；根据所述流转推状态使用源站或边缘计算节点的地址加密生成统一资源标识符；将每个CDN与统一资源标识符对应的回源IP地址定时同步给相应CDN；当用户请求所述流的播放地址时,将统一资源标识符加入到播放地址中返回给用户,以使所述CDN在收到用户发起的播放请求时,根据统一资源标识符和回源IP地址确定回源途径。本申请还公开了一种直播推流回源系统、电子装置和计算机可读存储介质。由此,能够使得各家CDN根据所述统一资源标识符对应的解析,去固定的回源IP地址进行拉流,并且边缘计算节点可以不将流转推给源站,避免了源站负载过高或资源浪费。(The application discloses a live broadcast plug flow source returning method, which comprises the following steps: collecting flow pushing states on all edge computing nodes in real time; encrypting and generating a uniform resource identifier by using the address of a source station or an edge computing node according to the flow pushing state; timing and synchronizing a back source IP address corresponding to each CDN and the uniform resource identifier to the corresponding CDN; when a user requests the playing address of the stream, the uniform resource identifier is added into the playing address and returned to the user, so that when the CDN receives the playing request initiated by the user, a source returning path is determined according to the uniform resource identifier and the source returning IP address. The application also discloses a live push streaming back-source system, an electronic device and a computer readable storage medium. Therefore, each CDN can pull the stream to a fixed source IP address according to the resolution corresponding to the uniform resource identifier, and the edge computing node can not push the stream to the source station, so that the source station is prevented from being overloaded or wasting resources.)

1. A live push streaming back-to-source method, the method comprising:

acquiring flow pushing states on all edge computing nodes in real time, wherein when the edge computing nodes receive pushed flows, the edge computing nodes perform pushing to a source station and/or each CDN;

encrypting and generating a uniform resource identifier by using the address of the source station or the edge computing node according to the flow pushing state;

timing and synchronizing a back source IP address corresponding to each CDN and the uniform resource identifier to the corresponding CDN; and

when a user requests the playing address of the stream, the uniform resource identifier is added to the playing address and returned to the user, so that when the CDN receives the playing request initiated by the user, a source returning path is determined according to the uniform resource identifier in the playing address and the synchronous source returning IP address.

2. The live push streaming back method of claim 1, wherein the streaming push state comprises whether to forward to the source station and a CDN address to forward to.

3. The live push streaming back-to-source method of claim 1 or 2, wherein said generating a uniform resource identifier using address encryption of the source station or the edge computing node according to the stream push state comprises:

judging whether the stream is forwarded to a source station or not according to the stream forwarding state;

generating the uniform resource identifier using address encryption of a source station when the stream has been forwarded to the source station;

generating the uniform resource identifier using address encryption of the edge compute node when the flow is not forwarded to a source station.

4. The live push streaming back-to-source method of any of claims 1-3, wherein the generating a uniform resource identifier using address encryption of the source station or the edge computing node according to the stream push state comprises:

exhausting all the CDNs, and respectively allocating corresponding back-source IP addresses to each CDN according to the stream pushing state to obtain an original character string;

and encrypting the original character string to generate a new character string as the uniform resource identifier.

5. The live streaming back-to-source method of claim 4, wherein the respectively allocating a corresponding back-to-source IP address to each CDN according to the streaming push state comprises:

when the CDN receives the forwarding of the stream, taking the CDN self address as the back source IP address corresponding to the CDN;

when the CDN does not receive the forwarding of the stream and the source station receives the forwarding of the stream, preferentially allocating an address of the source station as the back-to-source IP address corresponding to the CDN;

when the CDN does not receive the forwarding of the stream and the source station does not receive the forwarding of the stream, allocating the address of the edge computing node as the back-to-source IP address corresponding to the CDN.

6. The live streaming back-to-source method of any of claims 1-5, wherein the timing synchronization of the back-to-source IP address corresponding to the uniform resource identifier for each CDN to the respective CDN comprises:

adding a mapping relation between the uniform resource identifier and a back-to-source IP address corresponding to the CDN into a back-to-source IP address list of the CDN;

and synchronizing the back source IP address list to the corresponding CDN at regular time.

7. The live push streaming back-to-source method of claim 6, wherein the determining a back-to-source route according to the uniform resource identifier in the play address and the synchronized back-to-source IP address comprises:

the CDN resolves a back-source IP address corresponding to the uniform resource identifier from the back-source IP address list, where the back-source IP address includes an address of the source station, an address of the edge computing node, or an address of the CDN itself, so as to determine whether to perform back-source from the source station or the edge computing node, or not to perform back-source.

8. A live push streaming back-to-source system, the system comprising:

the acquisition module is used for acquiring flow pushing states on all edge computing nodes in real time, wherein when the edge computing nodes receive pushing flows, the edge computing nodes perform pushing on a source station and/or each CDN;

a generation module, configured to encrypt and generate a uniform resource identifier using an address of the source station or the edge computing node according to the flow forwarding state;

the synchronization module is used for synchronizing the back source IP address corresponding to each CDN and the uniform resource identifier to the corresponding CDN at regular time;

and the scheduling module is used for adding the uniform resource identifier into the playing address and returning the uniform resource identifier to the user when the user requests the playing address of the stream, so that when the CDN receives the playing request initiated by the user, a source returning path is determined according to the uniform resource identifier in the playing address and the synchronous source returning IP address.

9. An electronic device, comprising: a memory, a processor, and a live push back source program stored on the memory and executable on the processor, the live push back source program when executed by the processor implementing the live push back source method of any of claims 1 to 7.

10. A computer-readable storage medium having stored thereon a live push stream back source program that, when executed by a processor, implements a live push stream back source method as recited in any of claims 1-7.

Technical Field

The present application relates to the field of live broadcast technologies, and in particular, to a live broadcast stream pushing and source returning method, system, electronic device, and computer-readable storage medium.

Background

In the existing live broadcast architecture, multiple Content Delivery Networks (CDNs) are often selected as service providers, and the CDNs serve as service providers for both main broadcast and push stream and users to watch. The anchor directly pushes the stream to the CDN, and after the CDN receives the stream, all the streams are pushed to a live source station. When the playing request of the user is scheduled, the playing address is allocated by referring to the state of the main push stream CDN. And if the distributed CDN has the stream pushing information of the stream, directly returning the stream pushing information to the user, otherwise returning the stream pushing information to the live broadcast source station. However, the live source station load is high in the above architecture, and it is likely that resources are wasted if all push streams are forwarded to the push source station.

Disclosure of Invention

The present application mainly aims to provide a live streaming back-source method, a live streaming back-source system, an electronic device, and a computer-readable storage medium, and aims to solve the problems of how to reduce the load of a source station and save resources while achieving live streaming back-source.

In order to achieve the above object, an embodiment of the present application provides a live streaming back-to-source method, where the method includes:

acquiring flow pushing states on all edge computing nodes in real time, wherein when the edge computing nodes receive pushed flows, the edge computing nodes perform pushing to a source station and/or each CDN;

encrypting and generating a uniform resource identifier by using the address of the source station or the edge computing node according to the flow pushing state;

timing and synchronizing a back source IP address corresponding to each CDN and the uniform resource identifier to the corresponding CDN; and

when a user requests the playing address of the stream, the uniform resource identifier is added to the playing address and returned to the user, so that when the CDN receives the playing request initiated by the user, a source returning path is determined according to the uniform resource identifier in the playing address and the synchronous source returning IP address.

Optionally, the flow pushing state includes whether to forward to the source station and a CDN address to forward to push.

Optionally, the generating a uniform resource identifier by using address encryption of the source station or the edge computing node according to the flow forwarding state includes:

judging whether the stream is forwarded to a source station or not according to the stream forwarding state;

generating the uniform resource identifier using address encryption of a source station when the stream has been forwarded to the source station;

generating the uniform resource identifier using address encryption of the edge compute node when the flow is not forwarded to a source station.

Optionally, the generating a uniform resource identifier by using address encryption of the source station or the edge computing node according to the flow forwarding state includes:

exhausting all the CDNs, and respectively allocating corresponding back-source IP addresses to each CDN according to the stream pushing state to obtain an original character string;

and encrypting the original character string to generate a new character string as the uniform resource identifier.

Optionally, the respectively allocating a corresponding back-to-source IP address to each CDN according to the stream pushing state includes:

when the CDN receives the forwarding of the stream, taking the CDN self address as the back source IP address corresponding to the CDN;

when the CDN does not receive the forwarding of the stream and the source station receives the forwarding of the stream, preferentially allocating an address of the source station as the back-to-source IP address corresponding to the CDN;

when the CDN does not receive the forwarding of the stream and the source station does not receive the forwarding of the stream, allocating the address of the edge computing node as the back-to-source IP address corresponding to the CDN.

Optionally, the timing synchronization of the back-to-source IP address corresponding to the uniform resource identifier for each CDN comprises:

adding a mapping relation between the uniform resource identifier and a back-to-source IP address corresponding to the CDN into a back-to-source IP address list of the CDN;

and synchronizing the back source IP address list to the corresponding CDN at regular time.

Optionally, the determining a source return path according to the uniform resource identifier in the play address and the synchronized source return IP address includes:

the CDN resolves a back-source IP address corresponding to the uniform resource identifier from the back-source IP address list, where the back-source IP address includes an address of the source station, an address of the edge computing node, or an address of the CDN itself, so as to determine whether to perform back-source from the source station or the edge computing node, or not to perform back-source.

In addition, to achieve the above object, an embodiment of the present application further provides a live streaming back-to-source system, where the system includes:

the acquisition module is used for acquiring flow pushing states on all edge computing nodes in real time, wherein when the edge computing nodes receive pushing flows, the edge computing nodes perform pushing on a source station and/or each CDN;

a generation module, configured to encrypt and generate a uniform resource identifier using an address of the source station or the edge computing node according to the flow forwarding state;

the synchronization module is used for synchronizing the back source IP address corresponding to each CDN and the uniform resource identifier to the corresponding CDN at regular time;

and the scheduling module is used for adding the uniform resource identifier into the playing address and returning the uniform resource identifier to the user when the user requests the playing address of the stream, so that when the CDN receives the playing request initiated by the user, a source returning path is determined according to the uniform resource identifier in the playing address and the synchronous source returning IP address.

In order to achieve the above object, an embodiment of the present application further provides an electronic device, including: the system comprises a memory, a processor and a live broadcast stream pushing and back source program which is stored on the memory and can run on the processor, wherein when the live broadcast stream pushing and back source program is executed by the processor, the live broadcast stream pushing and back source method is realized.

In order to achieve the above object, an embodiment of the present application further provides a computer-readable storage medium, where a live streaming back-source program is stored on the computer-readable storage medium, and when executed by a processor, the live streaming back-source program implements the live streaming back-source method as described above.

The live broadcast push flow back-to-source method, the live broadcast push flow back-to-source system, the electronic device and the computer readable storage medium change a mode that a user directly pushes flow to the CDN, the flow is forwarded to each CDN by the edge computing nodes, the scheduling device generates a uniform resource identifier corresponding to a back-to-source IP address during scheduling by referring to flow push states on each edge computing node, and the uniform resource identifier is brought when a playing address is returned to the user, so that each CDN can pull flow by removing a fixed back-to-source IP address according to analysis corresponding to the uniform resource identifier when receiving a playing request. In addition, the edge computing node may not push the flow to the source station, and each CDN may also resolve the address of the edge computing node to return to the source through the foregoing manner, so as to avoid an excessive load on the source station or resource waste.

Drawings

FIG. 1 is a diagram of an application environment architecture in which various embodiments of the present application may be implemented;

fig. 2 is a flowchart of a live streaming back-to-source method according to a first embodiment of the present application;

FIG. 3 is a detailed flowchart of step S202 in FIG. 2;

fig. 4 is a schematic hardware architecture diagram of an electronic device according to a second embodiment of the present application;

fig. 5 is a schematic block diagram of a live push streaming back source system according to a third embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

It should be noted that the descriptions relating to "first", "second", etc. in the embodiments of the present application are only for descriptive purposes and are not to be construed as indicating or implying relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. In addition, technical solutions between various embodiments may be combined with each other, but must be realized by a person skilled in the art, and when the technical solutions are contradictory or cannot be realized, such a combination should not be considered to exist, and is not within the protection scope of the present application.

Referring to fig. 1, fig. 1 is a diagram illustrating an application environment architecture for implementing various embodiments of the present application. The present application is applicable in application environments including, but not limited to, a scheduler 2, an edge computing node 4, a CDN 6, and a source station 8. There may be a plurality of edge computing nodes 4 and CDNs 6.

In various embodiments of the present application, the anchor pushes a stream to one edge compute node 4. The edge compute node 4, upon receiving the push flow, makes a push to each home CDN 6 and source site 8 (possibly to the source site 8 or not). If the source station 8 receives the push flow information of all flows, the load is high, and the source station 8 is generally a three-line machine room, which is high in cost, and the cost is higher if the load is larger. In addition, since the number of people viewing the partial stream is small, one CDN 6 can fully carry the access amount, and it is not necessary to consider forwarding the source station 8 for backing up data, which may cause resource waste. Thus, the edge computing node 4 in the various embodiments of the present application does not forward all pushed flows to the source station 8.

The scheduling device 2 collects flow push states of all the edge computing nodes 4 in real time, and encrypts and generates uniform resource identifiers by using the addresses of the source station 8 or the edge computing nodes 4 according to the flow push states. When the user requests the play address of the stream from the scheduling device 2, the scheduling device 2 adds the uniform resource identifier to the play address and returns the uniform resource identifier to the user. Each CDN 6 synchronizes the real home IP address list corresponding to the uniform resource identifier to the scheduling apparatus 2 at regular time.

And then the user initiates a playing request to a certain CDN 6 according to the playing address. If the CDN 6 has received the forwarding of the stream, the user may view the stream by directly agreeing to establish a link. If the CDN 6 does not receive the stream forwarding, querying a corresponding IP address according to the uniform resource identifier in the broadcast address, and determining to return to the source from the source station 8 or the edge computing node 4. After returning to the source, the link is established and the user can view the link.

Example one

Fig. 2 is a flowchart of a live streaming back-to-source method according to a first embodiment of the present application. It is to be understood that the flow charts in the embodiments of the present method are not intended to limit the order in which the steps are performed. Some steps in the flowchart may be added or deleted as desired. The method will be described below with the scheduling apparatus 2 as the execution subject.

The method comprises the following steps:

and S200, collecting flow pushing states on all edge computing nodes in real time.

When an anchor (or other user) pushes a stream to an edge computing node, the edge computing node performs a forward push (possibly to the source station or not) to each CDN and the source station after receiving the stream. For example, assume that the anchor pushes stream X to edge compute node a, which forwards the stream X to CDN a and the origin. The scheduling device collects the flow pushing state (whether to push the source station and the CND address of the flow pushing) on all the edge computing nodes in real time, so as to provide reference for subsequently allocating back source IP addresses.

S202, according to the flow pushing state, using the address encryption of the source station or the edge computing node to generate a uniform resource identifier.

Theoretically, the back-source IP address can be directly placed in the playing address, and the CDN directly performs back-source on the corresponding back-source IP address after obtaining the playing address. However, the method directly exposes the IP address to the user, which may face the risk of being illegally attacked by hackers, and cannot guarantee the security.

In this embodiment, the uniform resource identifier is updated by monitoring the forwarding state in real time, and the resolving conditions of the CDN of different homes corresponding to the same uniform resource identifier are different. That is, although the obtained uniform resource identifiers are the same for different CDNs, the obtained resolution lists corresponding to the uniform resource identifiers are not consistent. For example xxxx is a uniform resource identifier, the resolution for CDN a is 12.12.12.12 and the resolution for CDN B is 8.8.8.8. The processing mode has the advantages that the overhead of maintaining the uniform resource identifiers by the scheduling device is reduced, and the playing addresses of all the CDNs are different only in domain name and the other CDNs are the same for the same stream, so that the maintenance cost is reduced.

Specifically, further refer to fig. 3, which is a schematic view of the detailed flow of step S202. It is to be understood that the flow chart is not intended to limit the order in which the steps are performed. Some steps in the flowchart may be added or deleted as desired. In this embodiment, the step S202 specifically includes:

and S2020, judging whether the stream is forwarded to a source station according to the stream forwarding state. When the stream has been forwarded to the source station, step S2022 is performed. When the stream is not forwarded to the source station, step S2024 is performed.

S2022, generating the uniform resource identifier by encrypting the address of the source station.

S2024, generating the uniform resource identifier by using the address encryption of the edge computing node.

When the source station also needs the flow, the edge compute node pushes the flow to the source station. At this time, when the scheduling apparatus generates the uniform resource identifier (that is, provides a back source address to the CDN), the back source address of the source station is preferentially allocated, and the uniform resource identifier is generated by encrypting the address of the source station. The reason for the above processing mode is that the source station is a three-wire computer room (i.e. supporting three operators of telecommunications, and mobile), has better quality and better network transmission link, and has better quality than the edge computing node operated by a single operator. If the stream is not forwarded to the source station, the address of the edge computing node is allocated, and the uniform resource identifier is generated by using the address encryption of the edge computing node.

In this embodiment, to generate the same uniform resource identifier, but the parsing results for the CDNs are different, all CDN (assuming that A, B, C three CDN service providers) lists need to be exhausted. In order to explain the process of generating the uniform resource identifier more thoroughly, specific embodiments are described as examples below.

In the first case:

(1) assume that the anchor pushes stream X to edge compute node a (IP address 7.7.7.7), which in turn forwards stream X to CDN a and the source site (IP: 6.6.6.6).

Then the original character string can be obtained according to the stream pushing state, wherein the original character string is a: 6.6.6.6+ C: 6.6.6.6. a represents that the back source address corresponding to the CDN A is equal to itself, which shows that the CDN has received the stream X and does not need to back source; b: 6.6.6.6 and C: 6.6.6.6 shows that the back-to-source addresses corresponding to CDN B and CDN C are both 6.6.6.6 (source site address is preferentially allocated for back-to-source).

(2) The original string is encrypted to generate a new string (assumed to be aaaa) as the uniform resource identifier.

In this embodiment, the encryption may employ MD5 message digest algorithm. In other embodiments, the encryption may also use other feasible algorithms, which are not described in detail herein.

In the second case:

(1) assume that the anchor pushes stream Y to edge compute node a (IP address 7.7.7.7), which in turn forwards stream X to CDN a, but not to the source station.

Then the original character string can be obtained according to the stream pushing state, wherein the original character string is a: 7.7.7.7+ C: 7.7.7.7. a represents that the back source address corresponding to the CDN A is equal to itself, which shows that the CDN has received the stream Y and does not need to back source; b: 7.7.7.7 and C: 7.7.7.7 shows that the back-to-source addresses for CDN B and CDN C are both 7.7.7.7 (the address of the edge computing node A is assigned when not forwarded to the source site).

(2) Encrypting the original string to generate a new string (assumed to be bbbb) as the uniform resource identifier.

In this embodiment, the encryption may employ MD5 message digest algorithm. In other embodiments, the encryption may also use other feasible algorithms, which are not described in detail herein.

Returning to fig. 2, in step S204, the back-source IP address corresponding to the uniform resource identifier of each CDN is synchronized to the corresponding CDN at regular time.

After the uniform resource identifier is generated, the scheduling device adds, for each CDN, a mapping relationship between the uniform resource identifier and a source-returning IP address corresponding to the CDN to a source-returning IP address list of the CDN. That is, each CDN has a corresponding back-to-source IP address list, and the back-to-source IP addresses of the CDN corresponding to the respective uniform resource identifiers are periodically updated and synchronized in the list. Each CDN synchronizes the back source IP address list to the scheduling device at regular time.

For example, in the specific example of the previous step, the uniform resource identifier corresponding to the flow X is aaaa. The scheduling device adds the mapping relationship between the uniform resource identifier aaaa and the source-returning IP address corresponding to each CDN to the source-returning IP address list of each CDN, that is: for CDN a, the back-to-source IP address corresponding to aaaa is not allowed back-to-source (self address); for CDN B, the back-source IP address corresponding to aaaa is 6.6.6.6 (source site address); for CDN C, the back-source IP address corresponding to aaaa is also 6.6.6.6 (source site address). That is, the mapping relationship between aaaa and the CDN a self address (return to source is not allowed) is added to the return to source IP address list of CDN a; adding the mapping relation of aaaa and the source station address 6.6.6.6 into a back source IP address list of the CDN B; the mapping of aaaa to source site address 6.6.6.6 is added to the back-to-source IP address list for CDN C. The uniform resource identifier corresponding to flow Y is bbbb. The scheduling device also adds the mapping relationship between the uniform resource identifier bbbb and the source-returning IP addresses corresponding to the home CDNs to the source-returning IP address lists of the home CDNs, that is: for the CDN a, the back-source IP address corresponding to the bbbb is an unallowable back-source (self-address); for CDN B, the back-source IP address corresponding to bbbb is 7.7.7.7 (edge computing node address); for CDN C, the back-source IP address corresponding to bbbb is also 7.7.7.7 (edge computing node address).

It should be noted that, in the above steps, on the basis that the scheduling device collects the flow forwarding states on all edge computing nodes in real time, the generated uniform resource identifier may be updated according to a rule of periodic triggering or event triggering. Synchronizing the back source IP address list at regular time when each CDN

And then, synchronizing to the back source IP address corresponding to the updated uniform resource identifier. For example, assume initial

When only one edge computing node A receives the flow Z, the unification can be generated according to the flow pushing state at the moment

Resource identifier Z1, and the back-to-source IP address for each CDN corresponding to the uniform resource identifier Z1 would be identical

And step to the corresponding CDN. Then after a certain time, the edge computing node A forwards the stream Z to CDN A and the source

The station may generate a uniform resource identifier Z2 again according to the stream pushing status at this time (that is, the uniform resource identifier corresponding to the stream Z is updated to Z2), and synchronize the back-source IP addresses corresponding to the uniform resource identifier Z2 for all CDNs respectively.

S206, when a user requests the playing address of the stream, the uniform resource identifier is added into the playing address and returned to the user, so that when the CDN receives the playing request initiated by the user, a source returning path is determined according to the uniform resource identifier in the playing address and the synchronous source returning IP address.

When a user requests the playing address of a certain stream, the scheduling device adds the latest uniform resource identifier corresponding to the stream into the playing address and returns the latest uniform resource identifier to the user. For example, for the above stream Z, when there is only the uniform resource identifier Z1, the scheduling apparatus adds the uniform resource identifier Z1 to the playing address of the stream Z and returns the stream Z to the user; when updated to uniform resource identifier Z2, the scheduler needs to add uniform resource identifier Z2 to the play address of stream Z and return it to the user. And the user sends a playing request aiming at the stream to a CDN according to the playing address.

When receiving the play request initiated by the user, the CDN may resolve, from the back-to-source IP address list, a back-to-source IP address (which may be an address of a source station, an address of an edge computing node, or an address of the CDN itself, that is, a back-to-source is not allowed) corresponding to the uniform resource identifier, so as to determine whether to perform back-to-source from the source station or the edge computing node, or not to perform back-to-source.

And when the CDN which does not receive the stream receives the playing request initiated by the user, determining to return the source from the source station or the edge computing node according to the uniform resource identifier in the playing address and the source returning IP address list. After returning to the source, the link is established and the user can view the link. If the CDN that receives the play request initiated by the user has received the forwarding of the stream, the CDN directly agrees to establish a link and the stream can be viewed.

For example, assuming that the user initiates a play request of stream X to CDN a, since CDN a has received the forwarding of stream X, the user can view it by directly agreeing to establish a link. If the user initiates a play request of the stream X to the CDN C, because the CDN C does not receive the forwarding of the stream X, the CDN C queries a back-source IP address corresponding to the uniform resource identifier from a back-source IP address list obtained in synchronization, and determines whether to return from the source station or return from the edge computing node. After returning to the source, the link is established and the user can view the link.

The live broadcast push flow back-to-source method provided by this embodiment changes a mode in which a user directly pushes a flow to a CDN, and forwards the flow to each home CDN through an edge computing node, where a scheduling device refers to a flow push state on each edge computing node to generate a uniform resource identifier corresponding to a back-to-source IP address during scheduling, and brings the uniform resource identifier when returning a play address to the user, so that each home CDN can pull the flow according to an analysis corresponding to the uniform resource identifier when receiving a play request. In addition, the edge computing node may not push the flow to the source station, and each CDN may also resolve the address of the edge computing node to return to the source through the foregoing manner, so as to avoid an excessive load on the source station or resource waste.

Example two

Fig. 4 is a schematic diagram of a hardware architecture of an electronic device 20 according to a second embodiment of the present application. In the present embodiment, the electronic device 20 may include, but is not limited to, a memory 21, a processor 22, and a network interface 23, which are communicatively connected to each other through a system bus. It is noted that fig. 4 only shows the electronic device 20 with components 21-23, but it is to be understood that not all of the shown components are required to be implemented, and that more or fewer components may be implemented instead. In this embodiment, the electronic device 20 may be the scheduling device 2.

The memory 21 includes at least one type of readable storage medium including a flash memory, a hard disk, a multimedia card, a card type memory (e.g., SD or DX memory, etc.), a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a Read Only Memory (ROM), an Electrically Erasable Programmable Read Only Memory (EEPROM), a Programmable Read Only Memory (PROM), a magnetic memory, a magnetic disk, an optical disk, etc. In some embodiments, the storage 21 may be an internal storage unit of the electronic device 20, such as a hard disk or a memory of the electronic device 20. In other embodiments, the memory 21 may also be an external storage device of the electronic apparatus 20, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), or the like, provided on the electronic apparatus 20. Of course, the memory 21 may also include both an internal storage unit and an external storage device of the electronic apparatus 20. In this embodiment, the memory 21 is generally used for storing an operating system and various application software installed in the electronic device 20, such as program codes of the live push streaming back to the source system 60. Further, the memory 21 may also be used to temporarily store various types of data that have been output or are to be output.

The processor 22 may be a CPU, controller, microcontroller, microprocessor, or other data processing chip in some embodiments. The processor 22 is generally used to control the overall operation of the electronic device 20. In this embodiment, the processor 22 is configured to execute the program code stored in the memory 21 or process data, for example, execute the live push stream back to the source system 60.

The network interface 23 may include a wireless network interface or a wired network interface, and the network interface 23 is generally used for establishing a communication connection between the electronic apparatus 20 and other electronic devices.

EXAMPLE III

Fig. 5 is a block diagram of a live streaming back source system 60 according to a third embodiment of the present invention. The live push stream back to the source system 60 can be partitioned into one or more program modules, which are stored in a storage medium and executed by one or more processors to implement embodiments of the present application. The program modules referred to in the embodiments of the present application refer to a series of computer program instruction segments capable of performing specific functions, and the following description will specifically describe the functions of each program module in the embodiments.

In this embodiment, the live push streaming back to the source system 60 includes:

the collection module 600 is configured to collect flow forwarding states of all edge computing nodes in real time.

When an anchor (or other user) pushes a stream to an edge computing node, the edge computing node performs a forward push (possibly to the source station or not) to each CDN and the source station after receiving the stream. For example, assume that the anchor pushes stream X to edge compute node a, which forwards the stream X to CDN a and the origin. The collection module 600 collects the flow push status (whether to forward to the source station and the forwarded CND address) on all edge compute nodes in real time, so as to provide a reference for subsequent assignment of a back-to-source IP address.

A generating module 602, configured to generate a uniform resource identifier according to the stream forwarding state by using address encryption of the source station or the edge computing node.

Theoretically, the back-source IP address can be directly placed in the playing address, and the CDN directly performs back-source on the corresponding back-source IP address after obtaining the playing address. However, the method directly exposes the IP address to the user, which may face the risk of being illegally attacked by hackers, and cannot guarantee the security.

In this embodiment, the uniform resource identifier is updated by monitoring the forwarding state in real time, and the resolving conditions of the CDN of different homes corresponding to the same uniform resource identifier are different. That is, although the obtained uniform resource identifiers are the same for different CDNs, the obtained resolution lists corresponding to the uniform resource identifiers are not consistent. For example xxxx is a uniform resource identifier, the resolution for CDN a is 12.12.12.12 and the resolution for CDN B is 8.8.8.8. The processing mode has the advantages that the overhead of maintaining the uniform resource identifiers by the scheduling device is reduced, and the playing addresses of all the CDNs are different only in domain name and the other CDNs are the same for the same stream, so that the maintenance cost is reduced.

The process of generating the uniform resource identifier by the generating module 602 specifically includes:

(1) and judging whether the stream is forwarded to a source station according to the stream forwarding state.

(2) When the stream has been forwarded to a source station, the uniform resource identifier is generated using address encryption of the source station.

(3) Generating the uniform resource identifier using address encryption of the edge compute node when the flow is not forwarded to a source station.

When the source station also needs the flow, the edge compute node pushes the flow to the source station. At this time, when the generation module 602 generates the uniform resource identifier (i.e., provides a back source address to the CDN), it preferentially allocates a back source address of the source station, and encrypts the source station address to generate the uniform resource identifier. The reason for the above processing mode is that the source station is a three-wire computer room (i.e. supporting three operators of telecommunications, and mobile), has better quality and better network transmission link, and has better quality than the edge computing node operated by a single operator. If the stream is not forwarded to the source station, the address of the edge computing node is allocated, and the uniform resource identifier is generated by using the address encryption of the edge computing node.

A synchronization module 604, configured to synchronize the back-source IP address corresponding to the uniform resource identifier of each CDN to the corresponding CDN at regular time.

After generating the uniform resource identifier, the synchronization module 604 adds, for each CDN, a mapping relationship between the uniform resource identifier and a source IP address corresponding to the CDN to a source IP address list of the CDN. That is, each CDN has a corresponding back-to-source IP address list, and the back-to-source IP addresses of the CDN corresponding to the respective uniform resource identifiers are periodically updated and synchronized in the list. Each home CDN will synchronize the back source IP address list to the synchronization module 604 at regular times.

It should be noted that, in the above steps, on the basis that the scheduling device collects the flow forwarding states on all edge computing nodes in real time, the generated uniform resource identifier may be updated according to a rule of periodic triggering or event triggering. And when each CDN synchronizes the back-to-source IP address list regularly, synchronizing the back-to-source IP address corresponding to the updated uniform resource identifier.

A scheduling module 606, configured to add the uniform resource identifier to the play address and return the uniform resource identifier to the user when the user requests the play address of the stream, so that when the CDN receives a play request initiated by the user, a source return path is determined according to the uniform resource identifier in the play address and the source return IP address list.

When a user requests the playing address of a certain stream, the scheduling device adds the latest uniform resource identifier corresponding to the stream into the playing address and returns the latest uniform resource identifier to the user. And the user sends a playing request aiming at the stream to a CDN according to the playing address. When receiving the play request initiated by the user, the CDN may resolve, from the back-to-source IP address list, a back-to-source IP address (which may be an address of a source station, an address of an edge computing node, or an address of the CDN itself, that is, a back-to-source is not allowed) corresponding to the uniform resource identifier, so as to determine whether to perform back-to-source from the source station or the edge computing node, or not to perform back-to-source.

And when the CDN which does not receive the stream receives the playing request initiated by the user, determining to return the source from the source station or the edge computing node according to the uniform resource identifier in the playing address and the source returning IP address list. After returning to the source, the link is established and the user can view the link. If the CDN that receives the play request initiated by the user has received the forwarding of the stream, the CDN directly agrees to establish a link and the stream can be viewed.

For example, assuming that the user initiates a play request of stream X to CDN a, since CDN a has received the forwarding of stream X, the user can view it by directly agreeing to establish a link. If the user initiates a play request of the stream X to the CDN C, because the CDN C does not receive the forwarding of the stream X, the CDN C queries a back-source IP address corresponding to the uniform resource identifier from a back-source IP address list obtained in synchronization, and determines whether to return from the source station or return from the edge computing node. After returning to the source, the link is established and the user can view the link.

The live broadcast stream pushing and returning system provided by this embodiment changes a mode in which a user directly pushes a stream to a CDN, and forwards the stream to each home CDN through an edge computing node, where the system generates a uniform resource identifier corresponding to a source returning IP address during scheduling with reference to a stream pushing state on each edge computing node, and takes the uniform resource identifier when returning a play address to the user, so that each home CDN can pull the stream according to an analysis corresponding to the uniform resource identifier when receiving a play request. In addition, the edge computing node may not push the flow to the source station, and each CDN may also resolve the address of the edge computing node to return to the source through the foregoing manner, so as to avoid an excessive load on the source station or resource waste.

Example four

The present application further provides another embodiment, which is to provide a computer-readable storage medium storing a live streaming back-source program, which is executable by at least one processor to cause the at least one processor to perform the steps of the live streaming back-source method as described above.

It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The above-mentioned serial numbers of the embodiments of the present application are merely for description and do not represent the merits of the embodiments.

It will be apparent to those skilled in the art that the modules or steps of the embodiments of the present application described above may be implemented by a general purpose computing device, they may be centralized on a single computing device or distributed across a network of multiple computing devices, and alternatively, they may be implemented by program code executable by a computing device, such that they may be stored in a storage device and executed by a computing device, and in some cases, the steps shown or described may be performed in an order different from that described herein, or they may be separately fabricated into individual integrated circuit modules, or multiple ones of them may be fabricated into a single integrated circuit module. Thus, embodiments of the present application are not limited to any specific combination of hardware and software.

The above description is only a preferred embodiment of the present application, and not intended to limit the scope of the present application, and all modifications that can be made by the use of the equivalent structures or equivalent processes in the specification and drawings of the present application or that can be directly or indirectly applied to other related technologies are also included in the scope of the present application.