Live streaming scheduling method and apparatus

Abstract

Embodiments of the present application provide a live stream scheduling method and device, wherein the live stream scheduling method comprises: obtaining scheduling information corresponding to at least two scheduling types of a target live stream in a stream media server, wherein the scheduling information is generated by a push stream server cluster and / or a client in the stream media server for live stream scheduling; in a case where it is determined according to the scheduling information that the target live stream meets a preset condition, generating a switching instruction of the scheduling type of the target live stream, and sending the switching instruction to the stream media server, so that the stream media server switches the scheduling type of the push stream server cluster and / or the client for scheduling the target live stream based on the switching instruction.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a live stream scheduling method. One or more embodiments of this application also relate to a live stream scheduling device, a live stream scheduling system, a computing device, and a computer-readable storage medium. Background Technology

[0002] With the development of technology, the clarity and smoothness of video services have been continuously improved. Moreover, with the advent of the Internet era, users' demand for high-quality videos will continue to increase. Currently, high-definition video has become the mainstream. While the improvement in resolution and clarity has enhanced the user's viewing experience, it has also led to a sharp increase in data usage.

[0003] Currently, the prevailing video distribution method in the industry deploys video / audio / image resources under a Content Delivery Network (CDN). When users need to download resources, they directly send resource requests to the CDN, enabling downloading, live streaming, and on-demand playback. However, in the current content distribution process, the decentralized nature of the scheduling center often leads to an increase in edge nodes used to process the distribution tasks of the same live stream. This results in a relatively high origin pull rate for live streams from the CDN, which impacts CDN bandwidth utilization, streaming media server resource utilization, and live stream distribution efficiency. Therefore, an effective solution is urgently needed to address this issue. Summary of the Invention

[0004] In view of this, embodiments of this application provide a live stream scheduling method. One or more embodiments of this application also relate to a live stream scheduling device, a live stream scheduling system, a computing device, and a computer-readable storage medium, to solve the technical defects in the prior art where the origin return rate of CDN for live streams is relatively high, affecting the bandwidth utilization of CDN, the bandwidth utilization of streaming media servers, and the efficiency of live stream distribution.

[0005] According to a first aspect of the embodiments of this application, a live stream scheduling method is provided, including:

[0006] Obtain scheduling information corresponding to at least two scheduling types of the target live stream in the streaming media server, wherein the scheduling information is generated by the streaming server cluster and / or the client performing live stream scheduling on the streaming media server;

[0007] If the target live stream meets the preset conditions based on the scheduling information, a switching instruction for the scheduling type of the target live stream is generated.

[0008] The switching instruction is sent to the streaming media server so that the streaming media server switches the scheduling type of the push server cluster and / or the client for scheduling the target live stream based on the switching instruction.

[0009] According to a second aspect of the embodiments of this application, a live stream scheduling device is provided, comprising:

[0010] The acquisition module is configured to acquire scheduling information corresponding to at least two scheduling types of the target live stream in the streaming media server, wherein the scheduling information is generated by the streaming server cluster and / or the client performing live stream scheduling on the streaming media server;

[0011] The generation module is configured to generate a switching instruction for the scheduling type of the target live stream when it is determined from the scheduling information that the target live stream meets preset conditions.

[0012] The sending module is configured to send the switching instruction to the streaming media server, so that the streaming media server switches the scheduling type of the push server cluster and / or the client for scheduling the target live stream based on the switching instruction.

[0013] According to a third aspect of the embodiments of this application, a live stream scheduling system is provided, comprising:

[0014] The system consists of a first client, a second client, a streaming media server, a central server, and at least two streaming server clusters.

[0015] The streaming media server is configured to receive the target live stream pushed by the first client, and to schedule the target live stream to the at least two streaming server clusters and / or the second client according to a preset scheduling type, thereby generating corresponding scheduling information.

[0016] The central server is configured to acquire the scheduling information, and if it is determined from the scheduling information that the target live stream meets preset conditions, generate a switching instruction for the scheduling type of the target live stream and send it to the streaming media server.

[0017] The streaming media server is also configured to switch the scheduling type of the at least two streaming server clusters and / or the second client for scheduling the target live stream based on the switching instruction.

[0018] According to a fourth aspect of the embodiments of this application, a computing device is provided, comprising:

[0019] Memory and processor;

[0020] The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, wherein the processor executes the computer-executable instructions to implement the steps of the live stream scheduling method.

[0021] According to a fifth aspect of the present application, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed by a processor, implement the steps of the live stream scheduling method.

[0022] One embodiment of this application implements a live stream scheduling method and apparatus. The live stream scheduling method includes acquiring scheduling information corresponding to at least two scheduling types of a target live stream in a streaming media server. The scheduling information is generated by a streaming server cluster and / or a client performing live stream scheduling on the streaming media server. When the target live stream is determined to meet preset conditions based on the scheduling information, a switching instruction for the scheduling type of the target live stream is generated, and the switching instruction is sent to the streaming media server so that the streaming media server switches the scheduling type of the target live stream performed by the streaming server cluster and / or the client based on the switching instruction.

[0023] This application embodiment determines, based on the scheduling information corresponding to different scheduling types of each live stream in the streaming media server, whether the push streaming server cluster and / or client use two or more scheduling types simultaneously when scheduling a target live stream to the streaming media server. Specifically, it determines whether the target live stream meets preset conditions based on the scheduling information. If so, it generates a scheduling type switching instruction for the target live stream, enabling the streaming media server to switch the scheduling type used by the push streaming server cluster and / or client to schedule the target live stream. This switching method reduces the number of scheduling types used simultaneously by the push streaming server cluster and / or client when scheduling the target live stream, thereby reducing the number of times the push streaming server cluster requests origin access for the target live stream. This achieves rational utilization of the bandwidth of both the push streaming server cluster and the streaming media server, thus reducing bandwidth usage costs and improving the distribution efficiency of the live stream. Attached Figure Description

[0024] Figure 1 This is an architecture diagram of a live stream scheduling system provided in one embodiment of this application;

[0025] Figure 2 This is a flowchart of a live stream scheduling method provided in one embodiment of this application;

[0026] Figure 3 This is an interactive schematic diagram of a live stream scheduling method provided in one embodiment of this application;

[0027] Figure 4 This is a schematic diagram of the structure of a live stream scheduling device provided in one embodiment of this application;

[0028] Figure 5 This is a structural block diagram of a computing device provided in one embodiment of this application. Detailed Implementation

[0029] Many specific details are set forth in the following description to provide a full understanding of this application. However, this application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this application; therefore, this application is not limited to the specific embodiments disclosed below.

[0030] The terminology used in one or more embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this application. The singular forms “a,” “the,” and “the” used in one or more embodiments of this application and in the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” used in one or more embodiments of this application refers to and includes any or all possible combinations of one or more associated listed items.

[0031] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this application, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this application, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0032] First, the terms and concepts involved in one or more embodiments of this application will be explained.

[0033] Live stream: The transmission of live audio and video data, which can be transmitted to viewers over a network as a stable and continuous stream.

[0034] Live Stream Room: In the live streaming service, each streamer has a unique identifier, which can be used to enter the streamer's live streaming page.

[0035] CDN (Content Delivery Network): A content delivery network built on top of a network.

[0036] The relationship between live streaming rooms and live streaming streams: Generally speaking, one live streaming room corresponds to one live streaming stream. The live streaming stream is relative to the CDN, while the live streaming room is relative to the live streaming platform.

[0037] Edge computing is a distributed computing architecture that moves the computation of applications, data, and services from the central nodes of the network to logically edge nodes.

[0038] Streaming media server: A server that receives user-pushed streams.

[0039] This application provides a live stream scheduling method. One or more embodiments of this application also relate to a live stream scheduling device, a live stream scheduling system, a computing device, and a computer-readable storage medium, which will be described in detail in the following embodiments.

[0040] In the existing live streaming system, the overall live streaming process is as follows:

[0041] 1) The broadcaster pushes the live stream to the streaming media server (edge ​​node). The streaming media server selects whether to push the live stream to the push server cluster, or selects which push server clusters (CDN) to push the live stream to.

[0042] 2) When a user enters the streamer's live room, the client used by the user requests the playback address of the live stream from the scheduling center.

[0043] 3) The client uses the obtained playback address to establish a connection with the corresponding CDN. If the CDN stores the live stream of the live room, the live stream is pushed to the client, and the live viewer can watch the live stream normally.

[0044] 4) If the CDN does not store the live stream of the live room, it is necessary to pull the stream from the origin to the streaming media server and then push the live stream to the client so that the live viewers can watch the live stream normally.

[0045] Alternatively, after obtaining the playback address, users can directly pull the stream from the streaming media server to watch. This type of application scenario is when there are a small number of viewers in a live stream, such as 1-2 users. In this case, it is not necessary to first transfer the live stream from the streaming media server to the CDN, and then have the CDN push the live stream to the client.

[0046] However, the aforementioned process has the following problems:

[0047] 1) Due to the decentralized nature of the scheduling center, the number of edge nodes used to process the same live stream distribution task increases, which in turn leads to a relatively high origin pull rate for CDN to handle live streams.

[0048] 2) Problems inherent to CDN: Due to the aggregation issues of CDN itself, when a CDN schedules a target live stream to a streaming media server, both live stream origin return and live stream push scheduling methods exist simultaneously, resulting in a waste of bandwidth for the streaming media server or CDN.

[0049] 3) HTTP-FLV viewing and live stream forwarding / origin pull coexist. Since HTTP-FLV viewing is typically used in live streams with very few viewers, theoretically, it shouldn't coexist with forwarding / origin pull. However, it's possible that when a live stream has a small number of viewers, an HTTP-FLV playback address might be assigned to them. As the number of viewers increases, the live stream needs to be scheduled via CDN. In this case, it's unnecessary to continue pulling the stream via HTTP-FLV viewing; the connection established between the client and the streaming media server using HTTP-FLV viewing should be disconnected.

[0050] All of the above situations will lead to an increase in the outbound bandwidth of the streaming media server. The purpose of this application embodiment is to reduce the outbound bandwidth of the streaming media server, thereby reducing costs.

[0051] Based on this, the embodiments of this application reduce the CDN scheduling dispersion, monitor the status of each live stream in the streaming media server in real time, and automatically disconnect the connection established between the CDN and the streaming media server through either live stream forwarding or live stream back to the source when it is determined that live stream forwarding and live stream back to the source exist at the same time, and automatically disconnect some connections established between the client and the streaming media server through HTTP-FLV viewing, so as to reduce the outbound bandwidth of the streaming media server.

[0052] See Figure 1 , Figure 1 The diagram illustrates an architecture of a live stream scheduling system according to an embodiment of this application, comprising:

[0053] The system comprises a first client 102, a second client 104, a streaming media server 106, a central server 108, and at least two streaming server clusters 110.

[0054] The streaming media server 106 is configured to receive the target live stream pushed by the first client 102, and to schedule the target live stream to the at least two streaming server clusters 110 and / or the second client 104 according to a preset scheduling type, and generate corresponding scheduling information.

[0055] The central server 108 is configured to acquire the scheduling information, and when it is determined from the scheduling information that the target live stream meets the preset conditions, generate a switching instruction for the scheduling type of the target live stream and send it to the streaming media server 106.

[0056] The streaming media server 106 is also configured to switch the scheduling type of the at least two streaming server clusters 110 and / or the second client 104 for scheduling the target live stream based on the switching instruction.

[0057] Optionally, the streaming media server 106 is further configured to:

[0058] Receive a live stream scheduling request from the second client 104, and determine the time interval between the interruption time of the third scheduling type and the reception time of the live stream scheduling request;

[0059] If the time interval is determined to be less than a preset time threshold, the address information of the target edge server in the target push server cluster 110 is generated and the address information is returned to the second client 104, wherein the target push server cluster 110 is one of the at least two push server clusters 110.

[0060] Optionally, the live stream scheduling system further includes a scheduling center 112, configured as follows:

[0061] Receive a live stream scheduling request from the second client 104, wherein the live stream scheduling request includes the live stream identifier of the target live stream;

[0062] The first streaming server cluster 110 corresponding to the live stream identifier is determined, and the target streaming server cluster 110 is determined based on the bandwidth to be consumed corresponding to the target live stream, the remaining bandwidth of the first streaming server cluster 110 and / or the target type bandwidth of at least one second streaming server cluster 110.

[0063] The address information of the target edge server in the target push server cluster 110 is generated and returned to the second client 104. The address information is used by the second client 104 to schedule the target live stream to the target edge server and obtain the corresponding scheduling result.

[0064] Figure 1In this process, the broadcaster pushes the target live stream to the streaming media server through the first client. The streaming media server pushes the target live stream to the push streaming server cluster, generates the corresponding scheduling information for the live stream scheduling, and the push streaming server cluster sends the target live stream to the second client. Alternatively, the push streaming server cluster actively pulls the target live stream from the streaming media server through the origin server, generates the corresponding scheduling information for the live stream scheduling, and sends the target live stream to the second client. Or, the live stream viewer directly pulls the target live stream from the streaming media server through the second client, generating the corresponding scheduling information for the live stream scheduling.

[0065] The central server can obtain the aforementioned scheduling information, and if it determines that the target live stream meets the preset conditions based on the scheduling information, it generates a switching instruction for the scheduling type of the target live stream and sends it to the streaming media server. The streaming media server then switches the scheduling type of each push server cluster and / or the second client for scheduling the target live stream based on the switching instruction.

[0066] The scheduling type can include three types: the first scheduling type is live stream push, the second scheduling type is live stream return to the source, and the third scheduling type is HTTP-FLV viewing.

[0067] If, based on scheduling information, a streaming server cluster is determined to pull the target live stream from the streaming media server both via live stream forwarding and via live stream origin pull, then the target live stream meets the preset conditions. In this case, a scheduling type switching instruction for the target live stream can be generated to cause the streaming media server to interrupt the process of the streaming server cluster pulling the stream from the streaming media server via live stream origin pull. Alternatively, if it is determined that the target live stream has both the HTTP-FLV viewing scheduling type and either the live stream forwarding or live stream origin pull scheduling types, then the target live stream also meets the preset conditions. In this case, a scheduling type switching instruction for the target live stream can be generated to cause the streaming media server to interrupt the HTTP-FLV viewing process of the target live stream.

[0068] Additionally, after the streaming media server interrupts the HTTP-FLV viewing process of the target live stream, it can also set the target live stream to a 302 response time for a short period of time. For example, if it detects that A CDN is scheduling the target live stream from the streaming media server via origin pull, the HTTP-FLV viewing process of the target live stream is disconnected. At the same time, it is set that if a client sends a live stream scheduling request within 10 minutes, requesting to schedule the target live stream via HTTP-FLV viewing, the address information of the target edge server in ACDN can be generated and returned to the client, so that the client can schedule the target live stream from A CDN using the address information.

[0069] Furthermore, the live stream scheduling system provided in this application embodiment also includes a scheduling center. Live stream viewers can send a live stream scheduling request to the scheduling center through a second client. The scheduling center determines the target push stream server cluster based on the bandwidth to be consumed corresponding to the target live stream, the remaining bandwidth of the push stream server cluster used to process the target live stream distribution task in a pre-determined manner, and / or the target type bandwidth of at least one push stream server cluster to be called. The scheduling center generates the address information of the target edge server in the target push stream server cluster and returns the address information to the client, so that the client can use the address information to schedule the target live stream to the target edge server and obtain the corresponding scheduling result, thereby realizing live stream viewing.

[0070] In practical applications, since the central server needs to obtain scheduling information from the streaming media server, the streaming media server needs to provide an interface for obtaining scheduling information. The scheduling information obtained by the central server through this interface may include:

[0071] 1) stream_name: The name of the live stream, which is a unique identifier for the live stream;

[0072] 2) forward_cdn: By forwarding the live stream, obtain the list of CDN clusters corresponding to the target live stream from the streaming media server. This list may contain the cluster identifiers of the CDN clusters, such as A CDN and B CDN, which means that the streaming media server forwards the target live stream to A CDN and B CDN.

[0073] 3) back_cdn: This is a list of CDN clusters corresponding to the target live stream from the streaming media server by using the live stream back-to-origin method. This list may contain the cluster identifiers of the streaming server clusters, such as B CDN and C CDN, which means that B CDN and C CDN actively obtain the target live stream from the streaming media server by using the back-to-origin method.

[0074] 4) http_flv_nums: The number of times the target live stream is pulled from the streaming media server directly via HTTP-FLV viewing.

[0075] The central server can obtain the scheduling information of the streaming media server through this interface at a preset time period, that is, at fixed time intervals, such as every 1 minute, and determine in real time whether the scheduling type of the target live stream needs to be switched based on the obtained scheduling information.

[0076] In summary, the overall live stream scheduling process of this application embodiment can be summarized as follows:

[0077] 1) The central server periodically collects scheduling information of the target live stream from the streaming media server;

[0078] 2) Based on the scheduling information of the target live stream, determine whether it is necessary to switch the scheduling type of the target live stream.

[0079] Specifically, the intersection of cluster identifiers in forward_cdn and back_cdn can be determined to ascertain whether the same CDN exists in forward_cdn and back_cdn. This indicates whether both origin pull and push methods coexist when the CDN retrieves the target live stream from the streaming media server. If so, a switching command is sent to the streaming media server to disconnect from the push server cluster and retrieve the target live stream via origin pull.

[0080] It can also determine the scheduling type of the target live stream, whether it is either HTTP-FLV viewing or live stream origin pull or live stream push, and if so, it can send a switching command to the streaming media server to interrupt the HTTP-FLV viewing process of the target live stream in order to save bandwidth.

[0081] After the streaming media server interrupts the HTTP-FLV viewing process of the target live stream, it can also set the target live stream to be accessed as 302 for a short period of time. For example, if it detects that A CDN is scheduling the target live stream from the streaming media server via live stream origin pull, the HTTP-FLV viewing process of the target live stream will be disconnected. At the same time, if a client sends a live stream scheduling request within 10 minutes, requesting to schedule the target live stream via HTTP-FLV viewing, the address information of the target edge server in A CDN can be generated and returned to the client, so that the client can schedule the target live stream from A CDN using the address information.

[0082] This application embodiment determines, based on the scheduling information corresponding to different scheduling types of each live stream in the streaming media server, whether the push streaming server cluster and / or client use two or more scheduling types simultaneously when scheduling a target live stream to the streaming media server. Specifically, it determines whether the target live stream meets preset conditions based on the scheduling information. If so, it generates a scheduling type switching instruction for the target live stream, enabling the streaming media server to switch the scheduling type used by the push streaming server cluster and / or client to schedule the target live stream. This switching method reduces the number of scheduling types used simultaneously by the push streaming server cluster and / or client when scheduling the target live stream, thereby reducing the number of times the push streaming server cluster requests origin access for the target live stream. This achieves rational utilization of the bandwidth of both the push streaming server cluster and the streaming media server, thus reducing bandwidth usage costs and improving the distribution efficiency of the live stream.

[0083] See Figure 2 , Figure 2 A flowchart of a live stream scheduling method according to an embodiment of this application is shown, including the following steps:

[0084] Step 202: Obtain scheduling information corresponding to at least two scheduling types of the target live stream in the streaming media server, wherein the scheduling information is generated by the streaming server cluster and / or the client performing live stream scheduling on the streaming media server.

[0085] Specifically, the live stream scheduling method provided in this application embodiment is applied to a central server.

[0086] A live stream is the audio and video data generated during a live broadcast; a target live stream is the live stream generated by the broadcaster that the live viewer wants to watch; a client is the terminal used by the live viewer to watch the live stream; a push stream server cluster refers to a collection of at least two push stream servers (edge ​​nodes or edge servers). In practical applications, this push stream server cluster can be a content delivery network (CDN).

[0087] The streaming media server is used to receive the live stream generated by the broadcaster and push the live stream to the push server cluster. This process can be called live stream forwarding. Alternatively, the push server cluster can actively pull the live stream from the streaming media server and then push the live stream to the client. The pulling process can be called live stream back to the origin. Or, the client can directly pull the live stream from the streaming media server using the live stream playback address. This process is called HTTP-FLV viewing. HTTP-FLV encapsulates audio and video data into FLV and then transmits it to the client via the HTTP protocol.

[0088] Among them, live stream forwarding is the first scheduling type, live stream back to the source is the second scheduling type, and HTTP-FLV viewing is the third scheduling type.

[0089] In practical applications, when a streaming server cluster or client schedules live streams on a streaming media server according to different scheduling types, the streaming media server can generate corresponding scheduling information. This scheduling information can exist in the form of a list, with the number of lists corresponding to each live stream equal to the number of scheduling types. For example, if there are the three scheduling types mentioned above, then each live stream will have three lists corresponding to the three scheduling types, for a total of three lists. The lists corresponding to the first and second scheduling types can contain the cluster identifier of the streaming server cluster. In the case of a CDN, the streaming server cluster identifier is the CDN identifier, such as A CDN, B CDN, C CDN, etc. The list corresponding to the third scheduling type can contain information such as the number of scheduling attempts. If the list corresponding to the first scheduling type contains A CDN and B CDN, it means that both A CDN and B CDN pull the target live stream from the streaming media server via live stream forwarding. If the list corresponding to the second scheduling type contains B CDN and C CDN, it means that both B CDN and C CDN pull the target live stream from the streaming media server via live stream origin pull.

[0090] In specific implementation, the scheduling information corresponding to at least two scheduling types of the target live stream in the streaming media server is obtained, including:

[0091] Obtain first scheduling information corresponding to the first scheduling type of the target live stream in the streaming media server, and second scheduling information corresponding to the second scheduling type of the target live stream, wherein the first scheduling type has a higher priority than the second scheduling type;

[0092] Accordingly, the method further includes:

[0093] Determine whether the first scheduling information and the second scheduling information contain the same push server cluster identifier;

[0094] If so, then the target live stream is determined to meet the first preset condition.

[0095] Specifically, the first preset condition is that the first scheduling information and the second scheduling information contain the same push server cluster identifier.

[0096] As mentioned earlier, when the scheduling types include live stream push, live stream back to origin, and HTTP-FLV viewing, the first scheduling type is live stream push, and the second scheduling type is live stream back to origin. The priority of live stream push is higher than that of live stream back to origin. This means that if a streaming server cluster pulls the target live stream from the streaming media server through both live stream push and live stream back to origin, the former will be selected first. That is, the streaming will be pulled through live stream push, and the process of the streaming server cluster pulling the stream from the streaming media server through live stream back to origin will be interrupted.

[0097] Therefore, this application embodiment can obtain the first scheduling information corresponding to the first scheduling type of the target live stream in the streaming media server, and the second scheduling information corresponding to the second scheduling type of the target live stream. By determining whether the first scheduling information and the second scheduling information contain the same push server cluster identifier, it can determine whether there is a certain push server cluster that pulls the target live stream from the streaming media server both through live stream forwarding and through live stream back-to-origin. This allows it to determine whether it is necessary to switch the scheduling type of the push server cluster for the target live stream.

[0098] In practical applications, if the first scheduling information and the second scheduling information contain the same push server cluster identifier, it is determined that the target live stream meets the first preset condition.

[0099] Determining whether the first scheduling information and the second scheduling information contain the same push server cluster identifier includes:

[0100] Determine the intersection between at least one push stream server cluster identifier contained in the first scheduling information and at least one push stream server cluster identifier contained in the second scheduling information;

[0101] Determine whether the intersection is a non-empty set.

[0102] Specifically, since both the first and second scheduling information contain streaming server cluster identifiers, determining whether the first and second scheduling information contain the same streaming server cluster identifier can be done by determining the intersection between at least one streaming server cluster identifier in the first scheduling information and at least one streaming server cluster identifier in the second scheduling information, and then determining whether the intersection is empty. If the intersection is not empty, it indicates that the first and second scheduling information contain the same streaming server cluster identifier, further indicating that there exists a streaming server cluster that is used for live streaming. If the target live stream is pulled from the streaming media server via push and also pulled from the streaming media server via live stream origin pull, then the scheduling type for the push server cluster to schedule the target live stream needs to be switched. If the intersection is empty, it means that the first and second scheduling information do not contain the same push server cluster identifier, and further indicates that there is no push server cluster that pulls the target live stream from the streaming media server via both push and origin pull. In this case, the scheduling type for the push server cluster to schedule the target live stream does not need to be switched.

[0103] In specific implementation, the scheduling information corresponding to at least two scheduling types of the target live stream in the streaming media server is obtained, including:

[0104] Obtain the third scheduling information corresponding to the third scheduling type of the target live stream in the streaming media server, wherein the second scheduling type has a higher priority than the third scheduling type;

[0105] Accordingly, the method further includes:

[0106] Determine whether the third scheduling information is empty;

[0107] If not, then the target live stream is determined to meet the second preset condition.

[0108] Specifically, the second preset condition, namely the third scheduling information, is not empty, indicating that there is a client using the HTTP-FLV viewing method to schedule the target live stream to the streaming media server.

[0109] As mentioned earlier, in addition to the first scheduling type (live stream push) and the second scheduling type (live stream return to origin), the scheduling type can also include a third scheduling type, namely HTTP-FLV viewing.

[0110] In practical applications, except when it is determined that a certain streaming server cluster pulls the target live stream from the streaming media server both through live stream forwarding and through live stream origin pulling, in which case the scheduling type of the streaming server cluster for the target live stream needs to be switched, if it is determined that the target live stream has both HTTP-FLV viewing and either live stream forwarding or live stream origin pulling, then the scheduling type of the target live stream also needs to be switched, i.e., the HTTP-FLV viewing process of the target live stream needs to be interrupted.

[0111] Based on this, after obtaining the scheduling information corresponding to the three scheduling types of the target live stream in the streaming media server, it is also possible to determine whether the third scheduling information is empty. If it is empty, it means that the target live stream has both the HTTP-FLV viewing scheduling type and the live stream push and live stream origin return scheduling types. In this case, it is necessary to switch the scheduling type of the target live stream. If it is not empty, it means that the target live stream has both the HTTP-FLV viewing scheduling type and either the live stream push or the live stream origin return scheduling type. In this case, it is necessary to switch the scheduling type of the target live stream.

[0112] In addition, if the third scheduling information is not empty, it can also be determined whether the first scheduling information and / or the second scheduling information is empty. If both the first and second scheduling information are empty, it means that the target live stream only has the HTTP-FLV viewing scheduling method. Therefore, there is no need to switch the scheduling type of the target live stream. However, if either the first or second scheduling information is not empty, the scheduling type of the target live stream needs to be switched.

[0113] If the third scheduling information is not empty, then the target live stream is determined to meet the second preset condition.

[0114] Alternatively, obtain scheduling information corresponding to at least two scheduling types of the target live stream in the streaming media server, including:

[0115] Obtain the third scheduling information corresponding to the third scheduling type of the target live stream in the streaming media server, wherein the second scheduling type has a higher priority than the third scheduling type;

[0116] Accordingly, the method further includes:

[0117] Determine whether the third scheduling information is empty;

[0118] If not, then if the number of times the client performs target live stream scheduling on the streaming media server according to the third scheduling type is greater than a preset threshold, based on the third scheduling information, the target live stream is determined to meet the third preset condition.

[0119] Specifically, as mentioned above, the third scheduling information may include information such as the number of scheduling attempts, indicating the number of times the client directly schedules the target live stream to the streaming media server via HTTP-FLV viewing.

[0120] In practical applications, the outbound bandwidth (downlink bandwidth) of streaming media servers is limited. If the number of times a client directly schedules the target live stream to the streaming media server via HTTP-FLV viewing exceeds a preset threshold, this live stream scheduling process will consume a large amount of the streaming media server's outbound bandwidth, affecting the live stream scheduling process between the streaming media server and other push stream server clusters. Therefore, this application embodiment needs to determine, based on the third scheduling information, whether the number of times the client schedules the target live stream to the streaming media server via HTTP-FLV viewing exceeds a preset threshold. If it does, the target live stream is determined to meet the third preset condition, and in this case, the scheduling type of the target live stream needs to be switched; if it does not exceed the threshold, there is no need to switch the scheduling type of the target live stream.

[0121] Step 204: If the target live stream meets the preset conditions based on the scheduling information, a switching instruction for the scheduling type of the target live stream is generated.

[0122] Specifically, if the target live stream meets the preset conditions based on the scheduling information, the scheduling type of the target live stream needs to be switched. In this case, a switching instruction for the scheduling type of the target live stream needs to be generated, so that the streaming media server can be instructed to switch the scheduling type of the target live stream based on the switching instruction.

[0123] In specific implementation, the method for generating a switching instruction for the scheduling type of the target live stream includes:

[0124] An interrupt instruction of the second scheduling type corresponding to the target live stream is generated, wherein the interrupt instruction is used by the streaming media server to interrupt the second scheduling type of the push streaming server cluster performing target live stream scheduling on the streaming media server, and the push streaming server cluster corresponds to the push streaming server cluster identifier.

[0125] Specifically, as mentioned earlier, the priority of live stream forwarding is higher than the priority of live stream back to the source. If a push streaming server cluster pulls the target live stream from the streaming media server both through live stream forwarding and through live stream back to the source, then the live stream forwarding method will be selected first, and the process of the push streaming server cluster pulling the stream from the streaming media server through live stream back to the source will be interrupted.

[0126] Therefore, if the first scheduling information and the second scheduling information contain the same push server cluster identifier, it is necessary to generate an interrupt instruction of the second scheduling type corresponding to the target live stream, so that the streaming media server interrupts the second scheduling type of the push server cluster in the streaming media server to schedule the target live stream. The push server cluster is the push server cluster corresponding to the push server cluster identifier.

[0127] Alternatively, generate a switching instruction for the scheduling type of the target live stream, including:

[0128] An interrupt instruction of the third scheduling type corresponding to the target live stream is generated, wherein the interrupt instruction is used by the streaming media server to interrupt the client's third scheduling type of target live stream scheduling on the streaming media server.

[0129] Specifically, as mentioned above, if it is determined that the target live stream has both the HTTP-FLV viewing scheduling type and either the live stream push or the live stream origin return scheduling type, or if it is determined that the number of times the client schedules the target live stream on the streaming media server in the HTTP-FLV viewing mode exceeds a preset threshold, then the scheduling type of the target live stream needs to be switched, that is, the HTTP-FLV viewing process of the target live stream needs to be interrupted.

[0130] Therefore, if it is determined that the third scheduling information is not empty, or if it is determined that the third scheduling information is not empty and the number of times the client performs target live stream scheduling on the streaming media server according to the third scheduling type is greater than a preset threshold, then an interrupt instruction corresponding to the third scheduling type of the target live stream needs to be generated so that the streaming media server can interrupt the client's third scheduling type of target live stream scheduling on the streaming media server.

[0131] In this embodiment, the purpose of interrupting the third scheduling type of the target live stream is to reduce scheduling dispersion. That is, when the number of viewers in the live room does not exceed a preset threshold, the target live stream is scheduled to the streaming media server only through the single HTTP-FLV viewing scheduling type. When the number of viewers in the live room exceeds the preset threshold, the target live stream is distributed through CDN, and the process of scheduling the target live stream through HTTP-FLV viewing is disconnected. This reduces scheduling dispersion, thereby reducing the number of times the push streaming server cluster goes back to the origin for the target live stream, realizing the rational utilization of the bandwidth of the push streaming server cluster and the streaming media server, and improving the distribution efficiency of the live stream.

[0132] Step 206: Send the switching instruction to the streaming media server so that the streaming media server switches the scheduling type of the push server cluster and / or the client for scheduling the target live stream based on the switching instruction.

[0133] Specifically, after the central server generates a switching instruction, it can send the switching instruction to the streaming media server so that the streaming media server can switch the scheduling type of the push streaming server cluster and / or client for scheduling the target live stream based on the switching instruction.

[0134] In addition, the streaming media server receives the live stream scheduling request from the client and determines the time interval between the interruption time of the third scheduling type and the reception time of the live stream scheduling request.

[0135] If the time interval is determined to be less than a preset time threshold, the address information of the target edge server in the streaming server cluster is generated and the address information is returned to the client, wherein the streaming server cluster corresponds to the streaming server cluster identifier.

[0136] Specifically, after the streaming media server interrupts the HTTP-FLV viewing process of the target live stream, it can also set the target live stream to be accessed as 302 for a short period of time. For example, if it detects that A CDN is scheduling the target live stream from the streaming media server via live stream origin pull, then while disconnecting the HTTP-FLV viewing process of the target live stream, it can be set that if a client sends a live stream scheduling request within 10 minutes, requesting to schedule the target live stream via HTTP-FLV viewing, the address information of the target edge server in A CDN can be generated and returned to the client, so that the client can schedule the target live stream from A CDN through the address information.

[0137] In addition, the scheduling center receives a live stream scheduling request from the client, wherein the live stream scheduling request includes the live stream identifier of the target live stream;

[0138] Determine the bandwidth to be consumed corresponding to the target live stream, and determine the target push stream server cluster based on the bandwidth to be consumed, the remaining bandwidth of the push stream server cluster, and / or the target type bandwidth of at least one push stream server cluster to be invoked;

[0139] The address information of the target edge server in the target push server cluster is generated and returned to the client. The address information is used by the client to schedule the target live stream to the target edge server and obtain the corresponding scheduling result.

[0140] Specifically, a live stream identifier is used to uniquely identify a live stream. This identifier can be the name or ID of the streamer's live room, and it represents the correspondence between the live room and the live stream.

[0141] In practical applications, when a user wants to watch a live stream from a particular broadcaster, they can send a live stream scheduling request to the scheduling center through their client (the client's player). This request can carry the identifier of the live stream to be scheduled. Upon receiving the scheduling request, the scheduling center can determine the streaming server cluster for the user and return the address information of the target edge server in the streaming server cluster. The user can then use this address information to schedule the live stream with the target edge server, obtain the corresponding scheduling result, and thus enable live streaming viewing.

[0142] In addition, after receiving a live stream scheduling request, the scheduling center can determine the push server cluster for live stream viewers. Different push server clusters, i.e., different CDNs, provide different downlink bandwidths. Therefore, to ensure the efficiency of live stream scheduling and reduce backflow, after receiving the live stream scheduling request submitted by the client for the target live stream, the scheduling center can first determine the push server clusters that have scheduled the target live stream from the streaming media server through live stream origin return or live stream forwarding. Other push server clusters that have not scheduled the target live stream from the streaming media server through live stream origin return or live stream forwarding are the push server clusters to be called. Then, the target live stream can be pushed to the client through the push server cluster.

[0143] However, in practical applications, there may be situations where the remaining downlink bandwidth of the streaming server cluster is insufficient to meet the bandwidth required for streaming. Therefore, after determining the streaming server cluster, the target streaming server cluster for processing the streaming task of the target live stream can be determined based on the bandwidth to be consumed corresponding to the target live stream, the remaining bandwidth of the streaming server cluster, and / or the target type bandwidth of at least one streaming server cluster to be invoked. The target streaming server cluster can be either the streaming server cluster or the streaming server cluster to be invoked.

[0144] The purpose of identifying the target streaming server cluster is to determine whether the remaining bandwidth of the streaming server cluster meets the requirements, that is, to determine whether it is necessary to replace the streaming server cluster used to push the target live stream to the client in order to ensure the efficiency of live stream streaming.

[0145] Once the target streaming server cluster is determined, the address information of the target edge server in the target streaming server cluster can be generated and returned to the client. The client can then use this address information to schedule the target live stream to the target edge server and obtain the corresponding scheduling result.

[0146] One embodiment of this application implements a live stream scheduling method, wherein the live stream scheduling method includes obtaining scheduling information corresponding to at least two scheduling types of a target live stream in a streaming media server, wherein the scheduling information is generated by a streaming server cluster and / or a client performing live stream scheduling on the streaming media server; when it is determined that the target live stream meets preset conditions based on the scheduling information, a switching instruction for the scheduling type of the target live stream is generated, and the switching instruction is sent to the streaming media server, so that the streaming media server switches the scheduling type of the target live stream performed by the streaming server cluster and / or the client based on the switching instruction.

[0147] This application embodiment determines, based on the scheduling information corresponding to different scheduling types of each live stream in the streaming media server, whether the push streaming server cluster and / or client use two or more scheduling types simultaneously when scheduling a target live stream to the streaming media server. Specifically, it determines whether the target live stream meets preset conditions based on the scheduling information. If so, it generates a scheduling type switching instruction for the target live stream, enabling the streaming media server to switch the scheduling type used by the push streaming server cluster and / or client to schedule the target live stream. This switching method reduces the number of scheduling types used simultaneously by the push streaming server cluster and / or client when scheduling the target live stream, thereby reducing the number of times the push streaming server cluster requests origin access for the target live stream. This achieves rational utilization of the bandwidth of both the push streaming server cluster and the streaming media server, thus reducing bandwidth usage costs and improving the distribution efficiency of the live stream.

[0148] See Figure 3 Taking the application of the live stream scheduling method provided in this application embodiment in the field of live streaming as an example, the live stream scheduling method will be further explained. Among them, Figure 3 This illustration shows an interactive diagram of a live stream scheduling method according to an embodiment of this application, which specifically includes the following steps:

[0149] Step 302: The broadcaster pushes the live stream to the streaming media server through the first client.

[0150] Step 304: The streaming media server schedules the target live stream to at least two streaming server clusters according to the preset scheduling type, and generates corresponding scheduling information.

[0151] Step 306: The streaming media server schedules the target live stream to the second client according to the preset scheduling type and generates corresponding scheduling information.

[0152] Step 308: The central server obtains scheduling information.

[0153] Step 310: If the central server determines that the target live stream meets the preset conditions based on the scheduling information, it generates a switching instruction for the scheduling type of the target live stream and sends it to the streaming media server.

[0154] Step 312: Based on the switching instruction, the streaming media server switches the scheduling type for scheduling the target live stream by at least two streaming server clusters and / or the second client.

[0155] Step 314: The second client sends a live stream scheduling request to the streaming media server according to the third scheduling type. The live stream scheduling request includes the live stream identifier of the target live stream.

[0156] Step 316: The streaming media server determines the time interval between the interruption time of the third scheduling type and the reception time of the live stream scheduling request.

[0157] Step 318: If the time interval is less than a preset time threshold, generate the address information of the target edge server in the target streaming server cluster and return the address information to the second client. The target streaming server cluster is one of at least two streaming server clusters.

[0158] Step 320: The second client schedules the live stream to the target edge server based on the address information and obtains the corresponding scheduling result.

[0159] Step 322: The second client plays the live stream from the scheduling results through the playback interface.

[0160] This application embodiment determines, based on the scheduling information corresponding to different scheduling types of each live stream in the streaming media server, whether the push streaming server cluster and / or client use two or more scheduling types simultaneously when scheduling a target live stream to the streaming media server. Specifically, it determines whether the target live stream meets preset conditions based on the scheduling information. If so, it generates a scheduling type switching instruction for the target live stream, enabling the streaming media server to switch the scheduling type used by the push streaming server cluster and / or client to schedule the target live stream. This switching method reduces the number of scheduling types used simultaneously by the push streaming server cluster and / or client when scheduling the target live stream, thereby reducing the number of times the push streaming server cluster requests origin access for the target live stream. This achieves rational utilization of the bandwidth of both the push streaming server cluster and the streaming media server, thus reducing bandwidth usage costs and improving the distribution efficiency of the live stream.

[0161] Corresponding to the above method embodiments, this application also provides embodiments of a live stream scheduling device. Figure 4 A schematic diagram of a live stream scheduling device according to an embodiment of this application is shown. Figure 4 As shown, the device includes:

[0162] The acquisition module 402 is configured to acquire scheduling information corresponding to at least two scheduling types of the target live stream in the streaming media server, wherein the scheduling information is generated by the streaming server cluster and / or the client performing live stream scheduling on the streaming media server;

[0163] The generation module 404 is configured to generate a switching instruction for the scheduling type of the target live stream when it is determined from the scheduling information that the target live stream meets preset conditions.

[0164] The sending module 406 is configured to send the switching instruction to the streaming media server so that the streaming media server switches the scheduling type of the push server cluster and / or the client for scheduling the target live stream based on the switching instruction.

[0165] Optionally, the acquisition module 402 is further configured to:

[0166] Obtain first scheduling information corresponding to the first scheduling type of the target live stream in the streaming media server, and second scheduling information corresponding to the second scheduling type of the target live stream, wherein the first scheduling type has a higher priority than the second scheduling type;

[0167] Accordingly, the device further includes a determining module configured to:

[0168] Determine whether the first scheduling information and the second scheduling information contain the same push server cluster identifier;

[0169] If so, then the target live stream is determined to meet the first preset condition.

[0170] Optionally, the generation module 404 is further configured to:

[0171] An interrupt instruction of the second scheduling type corresponding to the target live stream is generated, wherein the interrupt instruction is used by the streaming media server to interrupt the second scheduling type of the push streaming server cluster performing target live stream scheduling on the streaming media server, and the push streaming server cluster corresponds to the push streaming server cluster identifier.

[0172] Optionally, the determining module is configured to:

[0173] Determine the intersection between at least one push stream server cluster identifier contained in the first scheduling information and at least one push stream server cluster identifier contained in the second scheduling information;

[0174] Determine whether the intersection is a non-empty set.

[0175] Optionally, the acquisition module 402 is further configured to:

[0176] Obtain the third scheduling information corresponding to the third scheduling type of the target live stream in the streaming media server, wherein the second scheduling type has a higher priority than the third scheduling type;

[0177] Accordingly, the device further includes a first determination module, configured to:

[0178] Determine whether the third scheduling information is empty;

[0179] If not, then the target live stream is determined to meet the second preset condition.

[0180] Optionally, the acquisition module 402 is further configured to:

[0181] Obtain the third scheduling information corresponding to the third scheduling type of the target live stream in the streaming media server, wherein the second scheduling type has a higher priority than the third scheduling type;

[0182] Accordingly, the device further includes a second determination module, configured to:

[0183] Determine whether the third scheduling information is empty;

[0184] If not, then if the number of times the client performs target live stream scheduling on the streaming media server according to the third scheduling type is greater than a preset threshold, based on the third scheduling information, the target live stream is determined to meet the third preset condition.

[0185] Optionally, the generation module 404 is further configured to:

[0186] An interrupt instruction of the third scheduling type corresponding to the target live stream is generated, wherein the interrupt instruction is used by the streaming media server to interrupt the client's third scheduling type of target live stream scheduling on the streaming media server.

[0187] Optionally, the live stream scheduling device further includes a first processing module, configured as follows:

[0188] The streaming media server receives the live stream scheduling request from the client and determines the time interval between the interruption time of the third scheduling type and the reception time of the live stream scheduling request.

[0189] If the time interval is determined to be less than a preset time threshold, the address information of the target edge server in the streaming server cluster is generated and the address information is returned to the client, wherein the streaming server cluster corresponds to the streaming server cluster identifier.

[0190] Optionally, the live stream scheduling device further includes a second processing module, configured as follows:

[0191] Receive a live stream scheduling request from a client, wherein the live stream scheduling request includes the live stream identifier of the target live stream;

[0192] Determine the bandwidth to be consumed corresponding to the target live stream, and determine the target push stream server cluster based on the bandwidth to be consumed, the remaining bandwidth of the push stream server cluster, and / or the target type bandwidth of at least one push stream server cluster to be invoked;

[0193] The address information of the target edge server in the target push server cluster is generated and returned to the client. The address information is used by the client to schedule the target live stream to the target edge server and obtain the corresponding scheduling result.

[0194] The above is an illustrative scheme of a live stream scheduling device according to this embodiment. It should be noted that the technical solution of this live stream scheduling device and the technical solution of the live stream scheduling method described above belong to the same concept. For details not described in detail in the technical solution of the live stream scheduling device, please refer to the description of the technical solution of the live stream scheduling method described above.

[0195] Figure 5 A structural block diagram of a computing device 500 according to an embodiment of this application is shown. The components of the computing device 500 include, but are not limited to, a memory 510 and a processor 520. The processor 520 is connected to the memory 510 via a bus 530, and a database 550 is used to store data.

[0196] The computing device 500 also includes an access device 540, which enables the computing device 500 to communicate via one or more networks 560. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 540 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Wi-MAX interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0197] In one embodiment of this application, the aforementioned components of the computing device 500 and Figure 5 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 5 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this application. Those skilled in the art can add or replace other components as needed.

[0198] The computing device 500 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or PCs. The computing device 500 can also be a mobile or stationary server.

[0199] The processor 520 is configured to execute the following computer-executable instructions, wherein the processor executes the computer-executable instructions to implement the steps of the live stream scheduling method.

[0200] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the live stream scheduling method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the live stream scheduling method described above.

[0201] An embodiment of this application also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the live stream scheduling method.

[0202] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the live stream scheduling method described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the live stream scheduling method described above.

[0203] The foregoing has described specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0204] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added to or subtracted according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0205] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments of this application.

[0206] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0207] The preferred embodiments disclosed above are merely illustrative of this application. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments of this application. These embodiments are selected and specifically described in this application to better explain the principles and practical applications of the embodiments of this application, thereby enabling those skilled in the art to better understand and utilize this application. This application is limited only by the claims and their full scope and equivalents.

Claims

1. A live stream scheduling method, characterized in that, include: Obtain scheduling information corresponding to at least two scheduling types of the target live stream in the streaming media server, wherein the scheduling information is generated by the streaming server cluster and / or the client performing live stream scheduling on the streaming media server; If the target live stream meets preset conditions based on the scheduling information, a switching instruction for the scheduling type of the target live stream is generated and sent to the streaming media server. This allows the streaming media server to switch the scheduling type of the push stream server cluster and / or the client for the target live stream based on the switching instruction. Specifically, if the push stream server cluster pulls the target live stream from the streaming media server both via live stream forwarding and via live stream origin pull, the process of the push stream server cluster pulling the stream from the streaming media server via live stream origin pull is interrupted. Alternatively, if it is determined that the target live stream has both the HTTP-FLV viewing scheduling type and either the live stream forwarding or live stream origin pull scheduling types, the HTTP-FLV viewing process of the target live stream is interrupted. The scheduling types include: live stream push, live stream return to source, and HTTP-FLV viewing.

2. The live stream scheduling method according to claim 1, characterized in that, The acquisition of scheduling information corresponding to at least two scheduling types of the target live stream in the streaming media server includes: Obtain first scheduling information corresponding to the first scheduling type of the target live stream in the streaming media server, and second scheduling information corresponding to the second scheduling type of the target live stream, wherein the first scheduling type has a higher priority than the second scheduling type; Accordingly, the method further includes: determining whether the first scheduling information and the second scheduling information contain the same push server cluster identifier; If so, then the target live stream is determined to meet the first preset condition; The first scheduling type is live stream push, and the second scheduling type is live stream return to source.

3. The live stream scheduling method according to claim 2, characterized in that, The instruction for switching the scheduling type of the target live stream includes: An interrupt instruction of the second scheduling type corresponding to the target live stream is generated, wherein the interrupt instruction is used by the streaming media server to interrupt the second scheduling type of the push streaming server cluster performing target live stream scheduling on the streaming media server, and the push streaming server cluster corresponds to the push streaming server cluster identifier.

4. The live stream scheduling method according to claim 2, characterized in that, Determining whether the first scheduling information and the second scheduling information contain the same push server cluster identifier includes: Determine the intersection between at least one push stream server cluster identifier contained in the first scheduling information and at least one push stream server cluster identifier contained in the second scheduling information; Determine whether the intersection is a non-empty set.

5. The live stream scheduling method according to claim 2, characterized in that, The acquisition of scheduling information corresponding to at least two scheduling types of the target live stream in the streaming media server includes: Obtain the third scheduling information corresponding to the third scheduling type of the target live stream in the streaming media server, wherein the second scheduling type has a higher priority than the third scheduling type; Accordingly, the method further includes: Determine whether the third scheduling information is empty; If not, then the target live stream is determined to meet the second preset condition; The third scheduling type is HTTP-FLV viewing.

6. The live stream scheduling method according to claim 2, characterized in that, The acquisition of scheduling information corresponding to at least two scheduling types of the target live stream in the streaming media server includes: Obtain the third scheduling information corresponding to the third scheduling type of the target live stream in the streaming media server, wherein the second scheduling type has a higher priority than the third scheduling type; Accordingly, the method further includes: Determine whether the third scheduling information is empty; If not, then if the number of times the client performs target live stream scheduling on the streaming media server according to the third scheduling type is greater than a preset threshold, based on the third scheduling information, the target live stream is determined to meet the third preset condition. The third scheduling type is HTTP-FLV viewing.

7. The live stream scheduling method according to claim 5 or 6, characterized in that, The instruction for switching the scheduling type of the target live stream includes: An interrupt instruction of the third scheduling type corresponding to the target live stream is generated, wherein the interrupt instruction is used by the streaming media server to interrupt the client's third scheduling type of target live stream scheduling on the streaming media server.

8. The live stream scheduling method according to claim 7, characterized in that, Also includes: The streaming media server receives the live stream scheduling request from the client and determines the time interval between the interruption time of the third scheduling type and the reception time of the live stream scheduling request. If the time interval is determined to be less than a preset time threshold, the address information of the target edge server in the streaming server cluster is generated and the address information is returned to the client, wherein the streaming server cluster corresponds to the streaming server cluster identifier.

9. The live stream scheduling method according to claim 3, characterized in that, Also includes: The scheduling center receives a live stream scheduling request from the client, wherein the live stream scheduling request includes the live stream identifier of the target live stream; Determine the bandwidth to be consumed corresponding to the target live stream, and determine the target push stream server cluster based on the bandwidth to be consumed, the remaining bandwidth of the push stream server cluster, and / or the target type bandwidth of at least one push stream server cluster to be invoked; The address information of the target edge server in the target push server cluster is generated and returned to the client. The address information is used by the client to schedule the target live stream to the target edge server and obtain the corresponding scheduling result.

10. A live stream scheduling device, characterized in that, include: The acquisition module is configured to acquire scheduling information corresponding to at least two scheduling types of the target live stream in the streaming media server, wherein the scheduling information is generated by the streaming server cluster and / or the client performing live stream scheduling on the streaming media server; The generation module is configured to generate a switching instruction for the scheduling type of the target live stream when it is determined from the scheduling information that the target live stream meets preset conditions. The sending module is configured to send the switching instruction to the streaming media server, so that the streaming media server switches the scheduling type of the push stream server cluster and / or the client for scheduling the target live stream based on the switching instruction; Specifically, when the target live stream meets preset conditions based on the scheduling information, a switching instruction for the scheduling type of the target live stream is generated and sent to the streaming media server. This allows the streaming media server to switch the scheduling type of the push stream server cluster and / or the client for scheduling the target live stream based on the switching instruction. Specifically, if the push stream server cluster pulls the target live stream from the streaming media server both via live stream forwarding and via live stream origin pull, the process of the push stream server cluster pulling the stream from the streaming media server via live stream origin pull is interrupted. Alternatively, if it is determined that the target live stream has both the HTTP-FLV viewing scheduling type and either the live stream forwarding or live stream origin pull scheduling types, the HTTP-FLV viewing process of the target live stream is interrupted. The scheduling types include: live stream push, live stream return to source, and HTTP-FLV viewing.

11. A live stream scheduling system, characterized in that, include: The system consists of a first client, a second client, a streaming media server, a central server, and at least two streaming server clusters. The streaming media server is configured to receive the target live stream pushed by the first client, and to schedule the target live stream to the at least two streaming server clusters and / or the second client according to a preset scheduling type, thereby generating corresponding scheduling information. The central server is configured to acquire the scheduling information, and if it is determined from the scheduling information that the target live stream meets preset conditions, generate a switching instruction for the scheduling type of the target live stream and send it to the streaming media server. The streaming media server is also configured to switch the scheduling type of the at least two streaming server clusters and / or the second client for scheduling the target live stream based on the switching instruction; Specifically, when the target live stream meets preset conditions based on the scheduling information, a switching instruction for the scheduling type of the target live stream is generated and sent to the streaming media server. This allows the streaming media server to switch the scheduling type of the push stream server cluster and / or the client for scheduling the target live stream based on the switching instruction. Specifically, if the push stream server cluster pulls the target live stream from the streaming media server both via live stream forwarding and via live stream origin pull, the process of the push stream server cluster pulling the stream from the streaming media server via live stream origin pull is interrupted. Alternatively, if it is determined that the target live stream has both the HTTP-FLV viewing scheduling type and either the live stream forwarding or live stream origin pull scheduling types, the HTTP-FLV viewing process of the target live stream is interrupted. The scheduling types include: live stream push, live stream return to source, and HTTP-FLV viewing.

12. A computing device, characterized in that, include: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, wherein when the processor executes the computer-executable instructions, it implements the steps of the live stream scheduling method according to any one of claims 1-9.

13. A computer-readable storage medium, characterized in that, It stores computer instructions that, when executed by a processor, implement the steps of the live stream scheduling method according to any one of claims 1-9.

Images