Live broadcast stream parallel processing method and device, equipment and medium

Abstract

The invention relates to the field of network live broadcast, and discloses a live broadcast stream parallel processing method and device, equipment and medium, and the method comprises the steps: continuously pulling a graphic user interface of a current shared node from a peer-to-peer network to play a needed live broadcast stream of a current live broadcast room, transmitting the live broadcast stream to other sharing nodes participating in the live broadcast stream sharing task corresponding to the current live broadcast room; continuously detecting surplus bandwidth resources and network service conditions of the current shared node in real time; when the network service condition exceeds a preset condition width interval, executing a live broadcast stream sharing task corresponding to the external live broadcast room by using the surplus bandwidth resource, continuously pulling the live broadcast stream of the external live broadcast room from the peer-to-peer network, and transmitting the live broadcast stream to a sharing node participating in the corresponding live broadcast stream sharing task; and when the network service condition is lower than the condition breadth interval or the surplus bandwidth resource is exhausted, limiting the pull transmission of the live broadcast stream of the external live broadcast room. Therefore, the terminal equipment serving as the sharing node can provide parallel sharing service of a plurality of live streams.

Description

Technical Field

[0001] The present application relates to network live broadcast technology, and in particular to a method for parallel processing of live streams and its device, equipment, and medium. Background Art

[0002] With the development of Internet technology and the growth of user demand, the transmission technology of live streaming in the field of online live broadcast has become a key research field. The real-time nature and high bandwidth requirements of live streaming pose challenges to network transmission, especially in high-concurrency scenarios. How to efficiently and stably transmit live streaming has become the focus of technology development. In order to meet this challenge, P2P (Peer-to-Peer) technology has been introduced into the transmission of live streaming, aiming to share the distribution pressure of the server by utilizing the uplink bandwidth of the terminal device and improve the transmission efficiency of the live streaming.

[0003] Although P2P technology has been widely used, it mainly focuses on sharing existing live streams, that is, the terminal device only acts as a shared node to share the live stream of the live room that the local device needs to play and display. Although this method reduces the burden on the server to a certain extent, it does not fully utilize the network resources of the terminal device. Specifically, the terminal devices in the prior art still have limitations in the transmission of live streams. They cannot provide sharing services for other live streams on the network platform. In other words, each terminal device only participates in the transmission of the live stream related to its own viewing, without realizing the parallel transmission and resource sharing of multiple live streams.

[0004] This limitation leads to multiple problems: First, network resources are not used efficiently because the uplink bandwidth is only used when the terminal device is watching the live broadcast, and is idle when not watching. Second, due to the lack of a coordination mechanism for the parallel transmission of multiple live streams, the redundant bandwidth of the network is not fully utilized, limiting the scalability and flexibility of live stream transmission. In addition, from the perspective of the entire platform, when faced with network fluctuations and changes, there is a lack of an effective adaptive adjustment mechanism, and it is impossible to use each shared node to dynamically adjust the transmission strategy of multiple live streams according to the real-time network conditions. This is particularly evident when the network conditions are unstable or the bandwidth is limited. Summary of the invention

[0005] The purpose of the present application is to solve the above-mentioned problems and to provide a live stream parallel processing method and its corresponding device, equipment, and non-volatile readable storage medium.

[0006] According to one aspect of the present application, a method for parallel processing of live streams is provided, comprising the following steps: continuously pulling the live stream of the current live room required for playing the graphical user interface of the current shared node from a peer-to-peer network, and transmitting the live stream to other shared nodes participating in the live stream sharing task corresponding to the current live room; continuously detecting the surplus bandwidth resources and network service conditions of the current shared node in real time; when the network service conditions exceed a preset conditional grace interval, using the surplus bandwidth resources to execute the live stream sharing task corresponding to the external live room, continuously pulling the live stream of the external live room from the peer-to-peer network and transmitting it to the shared nodes participating in the corresponding live stream sharing task; when the network service conditions are lower than the conditional grace interval or the surplus bandwidth resources are exhausted, limiting the pulling and transmission of the live stream of the external live room.

[0007] According to another aspect of the present application, a live stream parallel processing device is provided, comprising: an internal demand service module, configured to continuously pull the live stream of the current live room required for playing the graphical user interface of the current shared node from a peer-to-peer network, and transmit the live stream to other shared nodes participating in the live stream sharing task corresponding to the current live room; an environment monitoring module, configured to continuously detect the surplus bandwidth resources and network service conditions of the current shared node in real time; an external demand service module, configured to, when the network service conditions exceed a preset conditional grace interval, use the surplus bandwidth resources to execute the live stream sharing task corresponding to the external live room, and continuously pull the live stream of the external live room from the peer-to-peer network and transmit it to the shared nodes participating in the corresponding live stream sharing task; an external demand restriction module, configured to restrict the pulling and transmission of the live stream of the external live room when the network service conditions are lower than the conditional grace interval or the surplus bandwidth resources are exhausted.

[0008] According to another aspect of the present application, a live stream parallel processing device is provided, comprising a central processing unit and a memory, wherein the central processing unit is used to call and run a computer program stored in the memory to execute the steps of the live stream parallel processing method described in the present application.

[0009] According to another aspect of the present application, a non-volatile readable storage medium is provided, which stores a computer program implemented according to the live stream parallel processing method in the form of computer-readable instructions, and when the computer program is called and executed by a computer, the steps included in the method are executed.

[0010] This application aims at the technical problems existing in the field of live broadcasting on the Internet, improves the business logic of pulling and transmitting live streams on the user side of the live broadcasting platform, effectively improves the utilization efficiency of network resources at the full platform level and enhances the scalability and flexibility of live stream transmission. By real-time monitoring of the surplus bandwidth resources and network service conditions of the terminal device as the current shared node, the pulling and transmission strategy of the live stream can be dynamically adjusted, so that when the network conditions are good, the surplus bandwidth resources of the terminal device can be fully utilized to perform the live stream sharing tasks of the external live broadcast room, reduce the pressure of server distribution, and improve the transmission efficiency and stability of the network platform. At the same time, by processing multiple live streams in parallel, the dynamic adjustment of resource sharing and transmission strategies is realized, the user experience is improved, and the stable transmission of live streams is ensured when the network conditions are unstable or the bandwidth is limited. In addition, the adaptability and robustness of live stream transmission are enhanced. By continuously monitoring the network service conditions and dynamically adjusting the transmission tasks according to the changes in conditions, the live stream transmission is made more flexible, and the network fluctuations and changes can be quickly responded to, and the continuity and quality of the live stream are guaranteed. These technical advantages not only optimize the transmission efficiency of the live stream, but also improve the user's experience of watching live broadcasts, showing the innovation and practicality of this application in the field of live broadcasting technology on the Internet. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Figure 1 is an exemplary network architecture suitable for applying the live stream parallel processing method of the present application;

[0012] Figure 2 A flowchart of an embodiment of a method for parallel processing of live streams of the present application;

[0013] Figure 3 This is a principle block diagram of the live stream parallel processing device of the present application;

[0014] Figure 4 This is a structural diagram of a live stream parallel processing device used in this application. DETAILED DESCRIPTION

[0015] Before describing the specific embodiments of the technical solution of the present application in detail, the network architecture and application scenarios suitable for supporting the implementation of the technical solution of the present application are first disclosed. The technical solution of the present application is applicable to a typical network live broadcast platform, such as Figure 1 As shown, the platform is composed of a live broadcast server 83, a media server 85, a peer-to-peer network, and terminal devices 90 and 92 that serve as shared nodes in the peer-to-peer network.

[0016] The live broadcast server is responsible for managing the creation of the live broadcast room, the reception and distribution of the live stream. The media server is responsible for processing the encoding, transcoding and storage of the live stream, ensuring that the live stream can be transmitted to the audience in an appropriate format and quality. A peer-to-peer network (P2P network) is a distributed network composed of multiple terminal devices. These terminal devices act as shared nodes in the peer-to-peer network and act as both clients and servers during the transmission of the live stream, assisting in the distribution of the live stream by sharing their respective uplink bandwidth.

[0017] A shared node in a peer-to-peer network refers to a terminal device that participates in the live stream sharing task. Each shared node not only requests the live stream for playback, but also acts as a transmission node to provide live streams to other shared nodes if there is sufficient bandwidth resources and network service conditions are met. The live server can also act as a management server for the peer-to-peer network in this architecture, responsible for coordinating and managing the connection and data transmission between shared nodes, including the distribution of live streams and the allocation of sharing tasks.

[0018] The media server can send the processed live stream to the source node dedicated to storage. The source node can also be regarded as a shared node in the peer-to-peer network that is mainly responsible for providing downlink transmission of the live stream. The media server sends the storage address of the live stream stored in the source node to the live server, which is then distributed to each shared node directly or through the management server of the peer-to-peer network. The source nodes that store the live stream refer to those nodes that have the original data of the live stream and are responsible for providing the initial source of the live stream.

[0019] The peer-to-peer network manages each shared node through a management server. With the help of the management server, each shared node can establish a connection by using specific algorithms and protocols. The peer-to-peer network can create a corresponding live stream sharing task for each shared node corresponding to each live stream, and construct all shared nodes based on the same live stream into the same circle, maintain a corresponding live stream sharing list for it, and record the shared node information participating in the live stream sharing task, including their network address, bandwidth and connection status. When a new shared node joins the network, the management server will match it with the existing shared node according to the network service conditions and surplus bandwidth resources of the shared node, and assist in establishing a connection. In this way, the shared nodes can directly exchange live stream data without having to rely entirely on a centralized server, thereby reducing the load on the server and improving the efficiency and stability of live stream transmission. In this way, the peer-to-peer network realizes the effective distribution of live streams, while optimizing the use of network resources, making the shared service of live streams more efficient and reliable. In some embodiments, the live server and the management server can be integrated and implemented in the same server.

[0020] In such a network architecture, the terminal device runs a live broadcast application, and the user can watch the live content through the application. The live broadcast application not only provides the live broadcast stream playback function, but also integrates the computer program product implemented according to the live broadcast stream parallel transmission method of the present application. When the user starts the live broadcast application and selects a live broadcast room to watch, the application will first obtain the live broadcast stream from the live broadcast server and play it on the user's device. At the same time, according to the technical solution of the present application, the application will also evaluate the network service conditions and surplus bandwidth resources of the device to determine whether it can participate in the sharing task of other live broadcast streams.

[0021] If the network service conditions of the current shared node exceed the preset condition tolerance range and there are surplus bandwidth resources, the live broadcast application will use these resources to pull the live stream of the external live broadcast room from the peer-to-peer network and transmit it to other shared nodes that need these live streams. This process not only improves the utilization efficiency of network resources, but also enhances the robustness and flexibility of live stream transmission.

[0022] The live broadcast room in this application can be a video live broadcast room, whose live broadcast stream is generally video data, or a voice live broadcast room, whose live broadcast stream is generally pure audio data. The audio data in the voice live broadcast room has relatively low requirements for system overhead, and when combined with the technical solution of this application and applied to terminal devices such as smart phones, it has more efficiency advantages.

[0023] Implementing the live streaming parallel transmission method of the present application as a computer program product means integrating the relevant algorithms and logic into the live streaming application. In this way, the live streaming application can not only provide the traditional live viewing experience, but also dynamically participate in the parallel transmission of the live streaming according to the network conditions, and open the parallel sharing service of the live streaming of the external live studio. This integration makes each terminal device running the live streaming application a flexible shared node, which can not only play the live streaming, but also intelligently participate in the distribution process of the live streaming according to the network conditions and resource conditions.

[0024] In this way, the technical solution of the present application can maximize the use of network resources while maintaining the efficiency and stability of live streaming transmission, providing users with a smoother and higher-quality live experience. This combination of network architecture and application scenarios provides a practical and effective implementation environment for the technical solution of the present application.

[0025] See also Figure 2 According to a live stream parallel processing method provided by the present application, it can be implemented as a computer program product, installed and run in a terminal device, so that the terminal device becomes a shared node in a peer-to-peer network. In some embodiments of the method, the following steps are included:

[0026] Step S3100: continuously pull the live stream of the current live room required for playing the graphical user interface of the current sharing node from the peer-to-peer network, and transmit the live stream to other sharing nodes participating in the live stream sharing task corresponding to the current live room;

[0027] The current shared node refers to the terminal device that is running the live broadcast application and participating in the live stream sharing task. The graphical user interface is the interface for the user to interact with the application implemented by the terminal device, which can be used to display the live content of the current live broadcast room. When the user starts the live broadcast application, the live streams of one or more live broadcast rooms may be called for preview display in the public page therein, or when the user enters the live broadcast room of a certain anchor user, the corresponding live stream will also be loaded and displayed on the page of the current live broadcast room entered by the user. This live stream called by the current shared node to output to the graphical user interface can be regarded as the live stream of the current live broadcast room.

[0028] In order to realize the processing of the live stream of the current live broadcast room on the current shared node, when the user access triggers the loading of the corresponding live stream, the current shared node first sends a request to the peer network to obtain the live stream sharing list corresponding to the current live broadcast room. The list contains the network addresses of other shared nodes participating in the live stream sharing task of the current live broadcast room. The corresponding network address information is the key to establishing a connection and transmitting data. They can be network identifiers such as IP addresses and port numbers.

[0029] After obtaining the live stream sharing list, the current sharing node establishes a network connection with other sharing nodes participating in the live stream sharing task of the current live room according to the network address in the list. These connections can be TCP connections, UDP connections, or other connection protocols suitable for P2P networks. After the connection is established, the current sharing node can continuously pull the live stream data of the current live room from the peer-to-peer network, specifically from the source nodes in the circle corresponding to the live stream of the current live room or from external sharing nodes. The pulled live stream data will be stored in the local cache of the current sharing node for subsequent transmission and playback.

[0030] At the same time, the current shared node also needs to transmit the pulled live stream to other shared nodes participating in the live stream sharing task of the current live broadcast room, so that multiple external shared nodes can share the live stream transmission task and improve the transmission efficiency and stability of the live stream. During the transmission process, the current shared node can dynamically adjust the transmission strategy according to the network status and request priority of other shared nodes, such as adjusting the transmission rate, selecting the transmission path, etc., to ensure the efficient transmission of the live stream.

[0031] For example, suppose the current live broadcast room has three shared nodes A, B, and C, where node A is the current shared node, and nodes B and C are other nodes participating in the live broadcast sharing task of the current live broadcast room. Node A first pulls the live stream of the current live broadcast room from the peer-to-peer network and stores it in the local cache. Then, node A establishes a connection with nodes B and C based on their network address information, and transmits the live stream data in the cache to nodes B and C. In this process, node A can dynamically adjust the transmission rate and data packet size based on indicators such as network bandwidth and latency of nodes B and C to optimize the transmission effect.

[0032] Step S3200: continuously and in real time detect the surplus bandwidth resources and network service conditions of the current shared node;

[0033] Continuous real-time detection of the surplus bandwidth resources and network service conditions of the current shared nodes is the basis for achieving parallel transmission of multiple live streams and resource optimization. The current shared node refers to the terminal device that is running the live application and participating in the live stream sharing task. Its surplus bandwidth resources refer to the uplink and downlink bandwidth that are not fully utilized during the current live stream transmission process. The network service conditions can be comprehensively characterized by the network response indicators of the live stream of the current live broadcast room, the current shared node network configuration indicators and the system overhead indicators, so as to comprehensively refer to a variety of network performance indicators including network delay, packet loss rate, connection stability, etc. to quantify the network service conditions.

[0034] In order to accurately detect surplus bandwidth resources, the current shared node can monitor the usage of its upstream and downstream bandwidths in real time, respectively, and determine the corresponding surplus bandwidth resources for the upstream and downstream. Specifically, the shared node can calculate the current bandwidth occupancy by analyzing the data transmission rate and traffic statistics of the network interface. For example, if the upstream bandwidth of the shared node is 10Mbps, and the upload rate of the current live stream and other bandwidth-occupying resources (which may include the live stream of the external live broadcast room that this application is already processing) is 3Mbps, then the remaining 7Mbps is the surplus bandwidth resource. Similarly, for the downstream bandwidth, the shared node will also calculate the portion occupied by the download of the bandwidth-occupying resources not included in the current live stream.

[0035] In terms of detecting network service conditions, shared nodes need to consider multiple factors. For example, network latency is a measure of the time it takes for a data packet to be sent and received, which can be obtained by sending a test packet and measuring its round-trip time. The packet loss rate indicates the proportion of data packets lost during network transmission to the total number of data packets sent, which is calculated by counting the number of data packets sent and received within a certain period of time. Connection stability reflects the reliability of the network connection and can be evaluated by monitoring the frequency and duration of connection interruptions. In addition, shared nodes can also refer to other network performance indicators, such as jitter, bandwidth fluctuations, etc., to fully understand the current network service conditions.

[0036] In another embodiment, the network service condition is comprehensively determined based on the network response index of the live stream of the current live room, the network configuration index of the current shared node, and the system overhead index, wherein the network response index is a floating score quantitatively determined based on the packet loss rate and network delay of the live stream of the current live room, the network configuration index includes a fixed score determined based on the NAT type of the current shared node, and the system overhead index includes a floating score quantitatively determined based on the CPU margin, GPU margin, and memory margin of the current shared node. By applying a preset weight distribution to weightedly fuse each score, the network service condition can be obtained.

[0037] Specifically, in order to convert various network performance indicators corresponding to network service conditions, such as network response indicators, network configuration indicators, system overhead indicators, etc., into data that is easy to process and compare, the current shared node can quantify them independently into the total value of indicators. For example, for the network response indicator, the network delay can be converted into milliseconds, and the packet loss rate can be expressed as a percentage for weighted fusion to obtain a total value of indicators; for the network configuration indicator, the connection stability is used to measure, and the corresponding score can be set as the total value of the indicator according to the different NAT types. The higher the score, the more stable the connection; for the system overhead indicator, the use margin of local computing resources such as CPU, GPU, and memory can be used to weight and unify them into the same total value of indicators. These total values ​​of indicators can be further weighted and fused to obtain a comprehensive network service score. In the weighted fusion process, weights can be assigned according to the degree of influence of each specific indicator and the total value of each indicator on the quality of live streaming transmission. For example, network delay has a greater impact on live streaming with high real-time requirements, so it can be given a higher weight; while the packet loss rate has a more direct impact on video quality, and can also be given a higher weight. In this way, the current sharing node can obtain a score that comprehensively reflects the current network service conditions, providing a basis for subsequent live stream sharing task decisions.

[0038] In actual applications, the current sharing node can determine whether the current network service conditions meet the requirements for executing the external live stream sharing task according to the preset conditional grace interval. The conditional grace interval is a range consisting of an upper limit and a lower limit. Only when the network service score of the sharing node exceeds the upper limit of this range, the network service conditions are considered to be good enough and the surplus bandwidth resources can be used to execute the external live stream sharing task. For example, if the upper limit of the conditional grace interval is set to 80 points, and the network service score of the sharing node is 85 points, the conditions for executing the external live stream sharing task are met. On the contrary, if the network service score is lower than the lower limit of the conditional grace interval, for example, when the lower limit is set to 0, the network service score is negative, which means that the network service conditions are poor and not suitable for executing the external live stream sharing task. The sharing node should give priority to ensuring the live stream transmission quality of the current live room. In this way, the sharing node can dynamically adjust its role and behavior in the live stream sharing task according to the surplus bandwidth resources and network service conditions detected in real time, so as to achieve reasonable allocation and optimal utilization of resources.

[0039] Step S3300: When the network service condition exceeds a preset conditional grace interval, the surplus bandwidth resources are used to execute the live stream sharing task corresponding to the external live broadcast room, and the live stream of the external live broadcast room is continuously pulled from the peer network and transmitted to the sharing nodes participating in the corresponding live stream sharing task;

[0040] When the network service conditions of a shared node exceed the preset conditional grace interval, the node will use its surplus bandwidth resources to perform the live stream sharing task corresponding to the external live room. Based on this, the live stream of the external live room is continuously pulled from the peer-to-peer network and transmitted to the shared nodes participating in the corresponding live stream sharing task. Specifically, the shared node will determine whether it has the conditions to perform the external live stream sharing task based on the current network service score. The network service score is calculated by comprehensively considering multiple factors, and it can fully reflect the network performance and resource status of the shared node.

[0041] When the network service score of a shared node exceeds the upper limit of the conditional grace interval, it indicates that the network service conditions of the node are good and it has sufficient bandwidth resources and network stability to perform external live stream sharing tasks. At this time, the shared node will obtain information related to the external live stream sharing task from the peer-to-peer network, including the source node address of the live stream (it can also be other shared nodes that can provide sharing services), the network address of the target shared node, and the data format of the live stream. After obtaining this information, the shared node will establish a network connection with the source node and start pulling the live stream data of the external live room. The pulled data will be stored in the local cache of the current shared node so that the cached live stream of the external live room can be subsequently transmitted to the target shared node.

[0042] During the transmission process, the shared node will dynamically adjust the transmission strategy according to the network status and request priority of the target shared node. For example, if the network bandwidth of the target shared node is wide and the latency is low, the shared node can increase the transmission rate and quickly transmit the live streaming data to the target node; conversely, if the network status of the target shared node is poor, the shared node can reduce the transmission rate to avoid data loss and transmission failure. In addition, the shared node can also flexibly adjust parameters such as the transmission path and data packet size according to the changes in network service conditions monitored in real time to ensure efficient transmission and stable playback of the live stream.

[0043] For example, in a specific embodiment, it is assumed that the network service score of the current shared node is 90 points, which exceeds the upper limit of the preset conditional grace interval of 80 points. At this time, the shared node receives a live stream sharing task request from an external live broadcast room, and the task requires the live stream data to be transmitted to multiple target shared nodes located in different geographical locations. The shared node first obtains the source node address of the live stream and the network address of the target node from the peer-to-peer network, then establishes a UDP connection with the source node, and starts to pull the live stream data. During the transmission process, the shared node dynamically adjusts the transmission rate and data packet size according to the network bandwidth and delay of the target node. For target nodes with better network conditions, the shared node adopts a higher transmission rate and a larger data packet; for target nodes with poor network conditions, the transmission rate and data packet size are reduced to ensure the stable transmission of the live stream. In this way, the shared node can make full use of its surplus bandwidth resources to provide efficient and stable services for the live stream sharing tasks of the external live broadcast room, thereby realizing parallel processing and transmission optimization of multiple live streams.

[0044] Step S3400: When the network service condition is lower than the condition tolerance interval or the surplus bandwidth resources are exhausted, the pull transmission of the live stream of the external live broadcast room is restricted.

[0045] When the network service conditions of the shared node are lower than the preset condition tolerance range or its surplus bandwidth resources are exhausted, measures need to be taken to limit the pull transmission of the live stream of the external live broadcast room. This measure is to ensure that the live stream transmission quality of the current live broadcast room is not affected and to reasonably allocate network resources.

[0046] Network service conditions that are lower than the conditional grace interval mean that the network performance of the shared node may not meet the requirements for high-quality transmission of external live streams. For example, the network delay may be too high, causing the live stream of the current live broadcast room to freeze; or the packet loss rate may increase, affecting the clarity and continuity of the live stream of the current live broadcast room; insufficient CPU margin or memory margin may cause delays in the processing of the live stream of the current live broadcast room. In these cases, the shared node should give priority to ensuring the transmission of the live stream of the current live broadcast room to avoid occupying too much bandwidth resources due to the transmission of external live streams, which may reduce the user experience of the current live stream.

[0047] Exhaustion of surplus bandwidth resources means that the uplink and / or downlink bandwidth of the shared node has been fully utilized by the current live stream and other network activities, and there is no additional bandwidth available for pulling and transmitting external live streams. At this point, if you continue to try to pull external live streams, the transmission rate of the current live stream may be reduced, or even data loss and transmission failure may occur.

[0048] In order to implement restrictions on live streaming pull transmission, the shared node will take corresponding measures based on the real-time monitored network service conditions and bandwidth resource conditions. Specifically, the shared node can terminate the current ongoing external live streaming pull transmission process. For example, if the shared node is pulling the live streaming data of an external live broadcast room from the source node and transmitting it to the target shared node, when it detects that the network service conditions are lower than the conditional grace interval or the bandwidth resources are exhausted, the shared node can actively disconnect from the source node and stop pulling the live streaming data. At the same time, the shared node will also stop transmitting the cached external live streaming data to the target shared node to release bandwidth resources and ensure that the live streaming transmission of the current live broadcast room is not affected.

[0049] In some embodiments, a shared node may need to restrict multiple external live streams. In this case, the shared node can selectively terminate the pull transmission of live streams of some external live rooms, or selectively terminate the transmission service of the related shared nodes of the live streams of one or more external live rooms, according to the priority of each live stream and the network status of the target shared node. For example, for external live streams with lower priority, or live streams with poor network status of the target shared node, the shared node can give priority to terminating their pull transmission, or reduce the transmission service to one or more related shared nodes, while retaining the transmission of live streams with higher priority or better network status of the target shared node.

[0050] In addition, in some embodiments, the shared node can also limit the pull transmission of the external live stream by adjusting the transmission strategy. For example, reduce the transmission rate, reduce the frequency and size of data packets, or select other transmission paths to reduce the impact on the current live stream transmission. Through these measures, the shared node can reasonably allocate network resources when the network service conditions are poor or the bandwidth resources are tight, ensure the live stream transmission quality of the current live broadcast room, and meet the needs of the external live stream sharing task as much as possible.

[0051] It should be pointed out that no matter how the live stream of the external live broadcast room is scheduled in the above process, it should never affect the live stream pulling demand of the current live broadcast room. However, in extreme cases, such as after disconnecting the pull transmission service of the live stream of all external live broadcast rooms, when the network service conditions still do not meet the minimum conditions, such as the lower limit of the conditional grace interval, the transmission service of the live stream of the current live broadcast room can also be restricted at this time. Specifically, the connection of the relevant shared node that is pulling the live stream of the current live broadcast room from the current shared node can be disconnected, and the transmission service for it can be terminated.

[0052] This application effectively solves a series of technical problems existing in traditional technologies through its technical solutions, and achieves remarkable technical effects, showing its technical advantages, including but not limited to:

[0053] First, the present application effectively improves the utilization efficiency of network resources by detecting in real time the surplus bandwidth resources and network service conditions of the terminal devices that access the network as shared nodes, and dynamically adjusting the pull and transmission of the live stream of the external live broadcast room that is processed in parallel with the live stream of the current live broadcast room according to these conditions. In the prior art, the surplus bandwidth resources of the terminal device will be idle when watching the live broadcast, while the present application maximizes the utilization of network resources by using these surplus bandwidth resources to perform the live stream sharing task of the external live broadcast room. This not only reduces the distribution pressure of the server, but also improves the transmission efficiency and stability of the entire network platform.

[0054] Secondly, the present application enhances the scalability and flexibility of live stream transmission by processing multiple live streams in parallel. In the prior art, the terminal device only participates in the transmission of the live stream related to its own viewing, and lacks a coordination mechanism for the parallel transmission of multiple live streams. The present application uses surplus bandwidth resources to pull and transmit the live stream of the external live room while pulling and transmitting the live stream related to its own viewing, so that the terminal device can provide sharing services for other live streams of the network platform, thereby realizing the parallel transmission and resource sharing of multiple live streams. According to the spirit of the protocol of the peer-to-peer network, the more live stream data contributed by the current shared node, the more advantages it has in giving priority to pulling the live stream required by itself, which not only improves the user experience, but also, from the perspective of the entire platform, in the case of unstable network conditions or limited bandwidth, not only the surplus bandwidth resources of the entire platform are mobilized, but also the transmission strategy of multiple live streams can be dynamically adjusted according to the real-time network conditions to ensure the stable transmission of the live stream.

[0055] In addition, this application also improves the adaptability and robustness of live streaming transmission. In the face of network fluctuations and changes, this application effectively responds to changes in network conditions by continuously monitoring network service conditions, executing external live streaming sharing tasks when conditions permit, and limiting the pull transmission of live streaming when conditions are insufficient. This dynamic adjustment mechanism makes live streaming transmission more flexible and can respond quickly according to real-time network conditions, thereby ensuring the continuity and quality of live streaming when network conditions are unstable.

[0056] On the basis of any embodiment of the method of the present application, continuously pulling the live stream of the current live room required for playing the graphical user interface of the current sharing node from the peer-to-peer network, and transmitting the live stream to other sharing nodes participating in the live stream sharing task corresponding to the current live room, including:

[0057] Step S3110: acquiring a live stream sharing list of the current live stream room from a peer-to-peer network according to the graphical user interface of the current sharing node in the current live stream room being accessed, wherein the live stream sharing list includes network addresses of multiple sharing nodes participating in the live stream sharing task of the corresponding live stream room;

[0058] When a user starts a live broadcast application and visits a live broadcast room, the current sharing node will send a request to the peer-to-peer network based on the live broadcast room information accessed by the graphical user interface to obtain the live broadcast stream sharing list corresponding to the live broadcast room.

[0059] The live stream sharing list contains the network addresses of multiple sharing nodes participating in the live stream sharing task of the current live broadcast room. It can also contain the network address of the source node to facilitate the current network node to pull the stream from the source node. These network address information are the key to establishing connections and transmitting data.

[0060] In actual operation, the current sharing node can obtain the live stream sharing list in a variety of ways. One way is to communicate with the live server and request to obtain the live stream sharing list of the current live room. As the management server of the peer-to-peer network, the live server maintains the sharing node information of each live room and can provide an accurate live stream sharing list. Another way is to communicate with other sharing nodes in the peer-to-peer network and request to obtain the live stream sharing list. For example, the current sharing node can send a request to a known sharing node, and the node will return the live stream sharing list of the current live room to the current sharing node based on the sharing node information it stores.

[0061] After obtaining the live stream sharing list, the current sharing node will identify other sharing nodes participating in the live stream sharing task of the current live room based on the network address information in the list. These sharing nodes may be other terminal devices that are also running live applications and participating in the live stream sharing task of the current live room. By obtaining the live stream sharing list, the current sharing node can understand the distribution of sharing nodes in the current live room, laying the foundation for subsequent network connection establishment and live stream transmission.

[0062] Step S3120: establishing a connection to a sharing node participating in the corresponding live stream sharing task based on the network address, and continuously pulling the live stream of the current live broadcast room through the connected sharing node for local caching;

[0063] After obtaining the live stream sharing list, the current sharing node will establish a stable network connection with these sharing nodes based on the network addresses provided in the list. These network addresses usually include information such as IP addresses and port numbers, which are the basis of network communication and are used to uniquely identify devices and communication endpoints in the network.

[0064] The process of establishing a connection can use a variety of network protocols. In this embodiment, UDP (User Datagram Protocol) is preferred. The UDP protocol has low latency and high transmission efficiency, and is suitable for live streaming transmission with high real-time requirements. When using the UDP protocol, the current shared node can directly send a data packet to the target shared node without the need for a complex connection establishment process.

[0065] Once the connection is established, the current shared node can continuously pull the live streaming data of the current live broadcast room from the peer-to-peer network. The pulled data will be stored in the local cache of the current shared node. The local cache can store the live streaming data in transit so that it can be quickly read and processed during the transmission process. The size of the cache can be dynamically adjusted according to the storage capacity of the shared node and the network conditions to ensure efficient transmission and stable playback of the live streaming data.

[0066] In actual applications, the current shared node will dynamically adjust the pull strategy according to the network conditions and the transmission requirements of the live stream. For example, when the network bandwidth is sufficient and stable, the shared node can increase the amount and frequency of pulled data to improve the transmission efficiency of the live stream; when the network conditions are poor, the shared node can reduce the amount of pulled data, or adjust the size and sending interval of the data packet to reduce transmission delay and packet loss rate. In addition, the shared node can also appropriately process and optimize the pulled data according to the encoding format and quality requirements of the live stream to ensure the clarity and smoothness of the live stream.

[0067] Step S3130, responding to a stream pulling transmission event of any sharing node participating in the corresponding live stream sharing task, and transmitting the cached live stream corresponding to the current live broadcast room to it.

[0068] When any sharing node participating in the corresponding live stream sharing task initiates a stream pull transmission event, the current sharing node will respond to this event and transmit the cached live stream corresponding to the current live room to the sharing node, so as to ensure that the live stream of the current live room can be efficiently distributed to multiple sharing nodes in the peer-to-peer network.

[0069] A stream pull event is a signal from a shared node requesting to obtain live stream data from the current shared node. When other shared nodes need to obtain the live stream of the current live broadcast room, they will send a stream pull request to the current shared node. This request may contain data such as the network address of the other shared node, identification information of the required live stream, and the priority of the request. For example, a shared node can send a request containing its IP address and port number to instruct the current shared node to send the live stream data to that address.

[0070] After receiving the pull stream transmission event, the current shared node will extract the corresponding live stream data from the local cache according to the information in the request. The local cache stores the live stream data that was previously pulled and saved from the peer-to-peer network. This data has been preliminarily processed and optimized to ensure its quality and transmission efficiency. For example, the current shared node may have compressed the live stream data to reduce the amount of transmitted data; or the data may have been fragmented for efficient transmission in the network.

[0071] After extracting the live streaming data, the current shared node will transmit the data to the requested shared node through the established network connection. The transmission process can adopt a variety of network protocols and transmission strategies. For example, TCP or UDP, etc., preferably UDP protocol, using its low latency and high transmission efficiency to quickly send data to the shared node, suitable for live streaming transmission scenarios with high real-time requirements.

[0072] During the entire transmission process, the current shared node will monitor the transmission status and network conditions in real time to ensure efficient transmission and stable playback of the live streaming data in the current live broadcast room. If network fluctuations or other abnormal conditions occur during the transmission process, the current shared node can take timely measures, such as retransmitting lost data packets, adjusting the transmission path, etc., to ensure the continuity and quality of the live streaming. In this way, the current shared node can provide reliable live streaming data to other shared nodes, realize parallel processing and sharing of live streaming, and improve the transmission efficiency and stability of the entire peer-to-peer network.

[0073] This embodiment can significantly improve the transmission efficiency and stability of the live stream by extracting and transmitting the optimized live stream data from the local cache after the shared node receives the pull stream transmission event. Compared with other embodiments, this embodiment uses the live stream data that has been compressed and fragmented in the local cache, reduces the computational burden of real-time data processing, and makes data transmission faster and more efficient. At the same time, the UDP protocol is used for data transmission, which makes full use of its low latency and high transmission efficiency, and is particularly suitable for live stream transmission scenarios with high real-time requirements. In addition, this embodiment can also dynamically adjust the transmission strategy according to the network status and request priority of the shared node, further optimize the transmission effect, reduce the probability of data loss and transmission errors, and ensure the clarity and smoothness of the live stream. Through these technical advantages, this embodiment realizes the efficient distribution and sharing of the live stream called by the current live broadcast room in the peer-to-peer network, improves the user experience, and enhances the transmission performance of the entire network.

[0074] On the basis of any embodiment of the method of the present application, continuously pulling the live stream of the external live broadcast room from the peer-to-peer network and transmitting it to the sharing node participating in the corresponding live stream sharing task includes:

[0075] Step S3310: Acquire a live stream sharing task that matches the network service condition from the peer network, and obtain a live stream sharing list of the corresponding external live broadcast room, wherein the live stream sharing list includes network addresses of multiple sharing nodes participating in the live stream sharing task of the corresponding live broadcast room;

[0076] Network service conditions refer to the network performance indicators of the current shared node, including bandwidth capacity, latency, packet loss rate, etc. These indicators determine the type and number of live streaming transmission tasks that the shared node can support. Live streaming sharing tasks refer to live streaming transmission tasks that are jointly participated in and completed by multiple shared nodes in a peer-to-peer network. Each task corresponds to the live stream of a live broadcast room.

[0077] In order to obtain a live stream sharing task that matches the network service conditions, the current sharing node first needs to send a request to the peer network. The peer network can be the distributed network architecture of the entire live broadcast platform or a specific subnetwork. The request will contain the network service condition information of the current sharing node, including the network service score corresponding to the network service condition and the original data of its various specific indicators, so that the peer network can match the corresponding live stream sharing task based on this information. For example, the network service score corresponding to the network service condition or the fixed score of the network configuration indicator corresponding to the NAT type characterizing the current sharing node can be submitted to the peer network so that the peer network knows that the current sharing node has high-quality bandwidth resources and penetration capabilities. In this case, the peer network can give priority to recommending live stream sharing tasks that require high bandwidth resources and high penetration capabilities to the current sharing node.

[0078] After receiving the request, the peer-to-peer network will filter out matching tasks from the live stream sharing task list it maintains based on the network service conditions of the current sharing node. This list contains live stream sharing tasks of multiple external live broadcast rooms, and each task has the corresponding shared node network address information. The screening process can be based on preset matching rules, such as network service score requirements, bandwidth requirements, delay tolerance, packet loss rate tolerance, penetration capability requirements, etc. For example, if a live stream sharing task of an external live broadcast room requires at least 3Mbps uplink bandwidth and less than 100ms latency, and the network service condition information of the current sharing node meets these requirements, the task will be matched and returned to the current sharing node.

[0079] After obtaining the matching live stream sharing task, the current sharing node will obtain the live stream sharing list of the corresponding external live broadcast room. This list lists in detail the network addresses of all sharing nodes participating in the live stream sharing task, including the source node and other sharing nodes.

[0080] In actual operation, the current sharing node can obtain the live stream sharing list in a variety of ways. One way is to communicate with the management server of the peer-to-peer network and request to obtain the matching live stream sharing tasks and the corresponding live stream sharing list. As the coordinator of the peer-to-peer network, the management server maintains the global live stream sharing task information and sharing node information, and can provide accurate matching results. Another way is to communicate with other sharing nodes in the peer-to-peer network and request to obtain the live stream sharing list. For example, the current sharing node can send a request to a known sharing node, and the node will return the matching live stream sharing list to the current sharing node based on the shared node information and live stream sharing task information stored by it.

[0081] Step S3320: establishing a connection to a sharing node participating in the corresponding live stream sharing task based on the network address, and continuously pulling the live stream of the corresponding external live broadcast room through the connected sharing node for local caching;

[0082] After obtaining the external live streaming sharing list that matches the network service conditions, the current sharing node will establish a stable network connection with the sharing node participating in the corresponding live streaming sharing task based on the network address provided in the list. Similar to step S3120, the process of establishing the connection can adopt a variety of network protocols such as UDP protocol.

[0083] After the connection is established, the current shared node can continuously pull the live streaming data of the corresponding external live broadcast room from the peer-to-peer network. The pulled data will be stored in the local cache of the current shared node. The local cache can store the live streaming data in transit so that it can be quickly read and processed during the transmission process. The size of the cache can be dynamically adjusted according to the storage capacity of the shared node and the network conditions to ensure efficient transmission and stable playback of the live streaming data.

[0084] In actual applications, the current shared node will dynamically adjust the pull strategy according to the network conditions and the transmission requirements of the live stream. For example, when the network bandwidth is sufficient and stable, the shared node can increase the amount and frequency of data pulled to improve the transmission efficiency of the live stream; when the network conditions are poor, the shared node can reduce the amount of data pulled, or adjust the size and sending interval of the data packet to reduce the transmission delay and packet loss rate. In addition, the shared node can also properly process and optimize the pulled data according to the encoding format and quality requirements of the live stream to ensure the clarity and smoothness of the live stream. Through these measures, the current shared node can effectively obtain the live stream data of the external live room from the peer-to-peer network and prepare for subsequent transmission and sharing.

[0085] Step S3330, respond to the stream pulling transmission event of any sharing node participating in the corresponding live stream sharing task, and transmit the cached live stream corresponding to the corresponding external live broadcast room to it.

[0086] The execution of this step is similar to step S3130. When any sharing node participating in the corresponding live stream sharing task initiates a stream pulling transmission event, the current sharing node will respond to this event and transmit the cached live stream corresponding to the corresponding external live broadcast room to the sharing node.

[0087] A stream pull event is a signal from a shared node requesting to obtain live stream data from the current shared node. When other shared nodes need to obtain live streams from external live broadcast rooms, they send a stream pull request to the current shared node. This request may contain data such as the network address of other shared nodes, identification information of the required live stream, and the priority of the request. For example, a shared node may send a request containing its IP address and port number to instruct the current shared node to send live stream data to that address.

[0088] After receiving the pull stream transmission event, the current shared node will extract the corresponding live stream data from the local cache according to the information in the request. The local cache stores the live stream data that was previously pulled and saved from the peer network. This data has been preliminarily processed and optimized to ensure its quality and transmission efficiency. After extracting the live stream data, the current shared node will transmit the data to the requesting shared node through the established network connection.

[0089] In order to improve transmission efficiency and stability, the current shared node can also dynamically adjust the transmission strategy according to the network status and request priority of the shared node. For example, if the network bandwidth of the shared node is wide and the delay is low, the current shared node can increase the transmission rate and quickly transmit the live streaming data of the external live broadcast room to the shared node; if the network status of the shared node is poor, the current shared node can reduce the transmission rate, or adjust the size and sending interval of the data packet to reduce data loss and transmission errors. In addition, the current shared node can also appropriately process and optimize the transmitted data according to the encoding format and quality requirements of the live stream, such as adjusting the resolution and frame rate of the video to meet the playback requirements of the shared node.

[0090] During the entire transmission process, the current shared node will monitor the transmission status and network conditions in real time to ensure efficient transmission and stable playback of live streaming data in the external live broadcast room. If network fluctuations or other abnormal conditions occur during the transmission process, the current shared node can take timely measures, such as retransmitting lost data packets, adjusting the transmission path, etc., to ensure the continuity and quality of the live streaming. In this way, the current shared node can provide reliable live streaming data to other shared nodes, realize parallel processing and sharing of live streaming, and improve the transmission efficiency and stability of the entire peer-to-peer network.

[0091] This embodiment can significantly improve the transmission efficiency and resource utilization of live streams by acquiring live stream sharing tasks of external live broadcast rooms that match the network service conditions from the peer-to-peer network, and transmitting the live streams of the corresponding external live broadcast rooms to the sharing nodes participating in the corresponding live stream sharing tasks. Compared with other embodiments, this embodiment can more accurately match the appropriate live stream sharing tasks according to the network performance indicators (such as bandwidth capacity, delay, packet loss rate, etc.) of the current sharing nodes, ensuring that the sharing nodes will not cause transmission quality degradation or task failure due to insufficient network conditions when performing tasks. At the same time, by continuously pulling the live streams of the external live broadcast rooms and caching them locally, and then responding to the pull stream transmission events of other sharing nodes for transmission, efficient distribution and sharing of live stream data is achieved, reducing dependence on the central server and reducing the load pressure of the server. In addition, this embodiment can also dynamically adjust the pulling and transmission strategies according to the real-time monitored network conditions and the transmission requirements of the live streams, further optimize the transmission effect, ensure the clarity and fluency of the live streams, and provide users with a better viewing experience. Through these technical advantages, this embodiment realizes efficient parallel processing and transmission of live streaming in a peer-to-peer network, improving the performance and stability of the entire network.

[0092] In this application, in order to optimize network resource allocation and improve user experience, the priority of the live stream of each external live broadcast room can be dynamically set in the current shared node so as to dynamically schedule the live stream of each external live broadcast room according to the priority, such as individually limiting the pull transmission of the live stream or its shared users. The current shared node may participate in the live stream sharing tasks of multiple live broadcast rooms at the same time, which requires reasonable allocation of limited network bandwidth resources to ensure the transmission quality and user experience of the live stream. To this end, based on any embodiment of the method of this application, this method also includes:

[0093] Step S5100: Determine the degree of utilization of surplus bandwidth resources by each live stream according to the real-time transmission bit rate of the live stream of the external live broadcast room and the total number of sharing nodes participating in the live sharing task of the live stream and connected to the current sharing node;

[0094] The degree of utilization of surplus bandwidth resources by each live stream reflects the effective utilization of surplus bandwidth resources of the current shared node, which can be determined based on the real-time transmission bit rate of the live stream of the corresponding external live room and the total number of shared nodes that participate in the live sharing task of the live stream and are connected to the current shared node. Specifically, the real-time transmission bit rate refers to the rate of network transmission generated by the live stream of the corresponding external live room in the current shared node, usually measured in bits per second (bps). This rate reflects the immediate demand for bandwidth of the live stream of the external live room. The total number of connected shared nodes determines the network range that needs to be served by the live stream of the corresponding external live room cached in the current shared node, that is, how many other shared nodes are receiving or requesting live stream data.

[0095] In order to determine the utilization degree of the surplus bandwidth resources by the live stream, in one embodiment, under the condition of ignoring the bandwidth occupied by other applications of the current shared node, the surplus bandwidth resources of the current shared node can be determined in real time by using an algorithm for dynamically calculating the remaining bandwidth. In the algorithm, the total bandwidth capacity BandwidthTotal of the current shared node is first determined, and then the bandwidth occupied by the current live stream is subtracted, that is, CodeRateStreamA*ShareUserA, where CodeRateStreamA represents the transmission bit rate of the live stream (StreamA) of the current live room, and ShareUserA represents the number of connected shared nodes for obtaining the live stream of the current live room. Similarly, for other live streams StreamB, StreamC, etc., CodeRateStreamB*ShareUserB, CodeRateStreamC*ShareUserC, etc. need to be calculated. The remaining bandwidth BandwitchLeft is obtained by subtracting the sum of the occupied bandwidths of all live streams (including the current live room and all external live rooms) from the total bandwidth capacity BandwitchLeft. When BandwitchLeft is less than zero, it means that the surplus bandwidth resources have been exhausted, and it is necessary to reduce the transmission of some live streams or disconnect some shared nodes.

[0096] Based on this, it can be understood that the utilization degree of the live stream of the external live broadcast room for the surplus bandwidth resources can be obtained by multiplying the real-time transmission code rate of each live stream by the total number of connected shared nodes it is serving. Specifically, for the live stream of each external live broadcast room, its transmission code rate (CodeRateStreamX, where X represents the specific live stream identifier) ​​directly reflects the data transmission volume of the live stream per unit time, and the total number of connected shared nodes (ShareUserX) indicates how many shared nodes are currently receiving or requesting data for the live stream. By multiplying these two values, that is, CodeRateStreamX*ShareUserX, a quantitative indicator can be obtained, which represents the total occupation of the surplus bandwidth resources by the live stream of a specific external live broadcast room at the current moment, that is, its utilization degree. This utilization degree not only reflects the bandwidth demand of a single live stream, but also takes into account its service demand for multiple shared nodes, thereby providing a comprehensive metric for evaluating the utilization degree of the surplus bandwidth resources of the live stream. In this way, it is possible to accurately identify which live streams are occupying more bandwidth resources, and optimize the allocation and adjustment of network resources accordingly.

[0097] Step S5200: On the basis of maintaining the live stream of the current live broadcast room as the highest priority, the priority of the corresponding live stream is set according to the utilization level of the live stream of each external live broadcast room;

[0098] The purpose of dynamically setting the priority of live streams is to reasonably allocate bandwidth under limited network resources, ensure the transmission quality of key live streams, and improve user experience. On the basis of maintaining the current live stream in the live broadcast room as the highest priority, the live streams of each external live broadcast room are given a corresponding priority according to their utilization of surplus bandwidth resources.

[0099] Specifically, the live streams of each external live broadcast room are sorted from high to low according to their utilization, and the priority of each live stream in the sorting is also given from high to low. Live streams with higher utilization mean that they occupy more bandwidth resources, so they can be given a higher priority to ensure their transmission quality. On the contrary, if the real-time transmission bit rate of the live stream of an external live broadcast room is low, or the number of connected shared nodes is small, resulting in a relatively low utilization, which means that its demand for bandwidth is small, so it can be given a lower priority. When network resources are tight, these low-priority live streams can be restricted first, such as reducing the transmission bit rate or pausing transmission, to release bandwidth resources for high-priority live streams.

[0100] Step S5300: In response to a restriction event corresponding to restricting the pull transmission of the live stream of an external live broadcast room, in addition to the live stream of the current live broadcast room, the live streams that need to be restricted from pull transmission are selected according to priority from low to high.

[0101] When it is necessary to restrict the live stream of an external live broadcast room in an orderly manner according to a certain strategy, it can ensure that the transmission quality of key live streams can be prioritized when network resources are tight. When the live broadcast application needs to restrict the pull transmission of the live stream of an external live broadcast room, a restriction event can be triggered based on the event mechanism. The live broadcast application then responds to this event and selects the live stream that needs to be restricted from pulling transmission from low to high according to the priority order preset in the previous step.

[0102] Specifically, when the live broadcast application detects that the network service condition is lower than the conditional grace interval or the surplus bandwidth resources are exhausted, the restriction process is initiated. In this process, this step is executed with the help of the event mechanism, and according to the previously determined live stream priority, starting from the low-priority live stream, the live streams that need to be restricted from pulling and transmitting are provided one by one as the target live streams. For example, if the live stream of an external live broadcast room is given the lowest priority because its real-time transmission bit rate is low or the number of connected shared nodes is small, then when the bandwidth resources are tight, this live stream will be first determined as the target live stream, thereby restricting the transmission of this live stream.

[0103] This restriction strategy ensures that even when network conditions are limited, high-priority live streams, such as the live streams of the current live broadcast room or those of external live broadcast rooms with high bandwidth requirements, can still obtain sufficient bandwidth resources to maintain their transmission quality. In this way, network resources can be effectively managed, the transmission efficiency of live streams can be optimized, and fair bandwidth allocation can be achieved between different live streams.

[0104] This embodiment intelligently schedules the transmission of the live stream by dynamically setting the priority of the live stream and responding to the restriction event. Compared with other embodiments, this embodiment has significant technical advantages, including but not limited to:

[0105] First, it ensures that when network bandwidth resources are limited, those live streams with higher bandwidth requirements or more critical user experience, such as the live streams of the current live broadcast room or external live broadcast rooms with higher priority, can be transmitted first, thereby improving the transmission quality and user experience of key live streams.

[0106] Secondly, by real-time monitoring of network service conditions and the degree of utilization of surplus bandwidth resources, this embodiment can flexibly adjust the transmission strategy of the live stream and optimize the allocation of network resources, so that network resources can be utilized more efficiently and reasonably.

[0107] In addition, the restriction strategy in this embodiment not only takes into account the real-time transmission bit rate of the live stream, but also takes into account the total number of connected shared nodes, which makes the priority setting more comprehensive and accurate, and can more accurately reflect the actual demand for bandwidth of the live stream. When network resources are tight, priority is given to limiting those live streams with lower priorities, effectively releasing bandwidth resources, ensuring the stable transmission of high-priority live streams, and reducing the risk of network congestion and live stream interruption. This dynamic adjustment mechanism improves the adaptability and robustness of live stream transmission, so that the live service can still maintain a high service quality and user experience when facing network fluctuations and changes.

[0108] Based on any embodiment of the method of the present application, the surplus bandwidth resources and network service conditions of the current shared node are continuously detected in real time, including:

[0109] Step S3210: respectively counting the bandwidth margins of the uplink bandwidth and the downlink bandwidth of the current shared node after being occupied by the live stream, and when any one of the bandwidth margins of the uplink bandwidth and the downlink bandwidth exceeds its corresponding preset threshold, determining the corresponding bandwidth margin as the corresponding surplus bandwidth resource;

[0110] When the surplus bandwidth resources of the shared nodes are monitored in real time, detailed statistics can be collected on the uplink bandwidth and downlink bandwidth usage of the current shared nodes to determine the uplink and downlink bandwidth margins that can be used for additional live streaming transmission.

[0111] After obtaining the bandwidth occupancy data, the corresponding bandwidth margin can be calculated, that is, the total bandwidth capacity minus the occupied bandwidth. If the bandwidth margin in either direction (uplink or downlink) exceeds the corresponding preset threshold, this part of the excess bandwidth is determined as surplus bandwidth resources. The preset threshold can be set based on the requirements of network stability and service quality to ensure that the shared node can provide transmission capabilities for other live streams while maintaining the current service quality. In a more specific implementation, the algorithm for determining surplus bandwidth resources in step S5100 can be referred to to specifically determine the surplus bandwidth resources corresponding to the uplink and downlink.

[0112] Step S3220, obtaining the network response index of the live stream of the current live room, the network configuration index of the current shared node and the system overhead index obtained by real-time detection, and determining the corresponding total index values;

[0113] Accurately obtaining network response indicators, network configuration indicators, and system overhead indicators helps to evaluate the network service conditions of the current shared nodes. These indicators together determine whether the current shared nodes have sufficient network capabilities and resources to support additional live stream sharing tasks.

[0114] The network response index mainly reflects the real-time transmission performance of the live stream of the current live broadcast room as the actual consumption stream of the current shared node. In this embodiment, it includes packet loss rate and network delay. These specific indicators themselves are numerical data, and can be weighted and converted into a unified total indicator value in advance as the corresponding real-time consumption stream score floating score ScoreStreamFloated. In one embodiment, for the packet loss rate RTTStreamA and the network delay LossRateStreamA, the following formula is used to fuse to obtain the floating score: packet loss rate and Rtt. ScoreStreamFloated = LossRateStreamA*w1+RTTStreamA*w2, where weights w1 and w2 can be set as needed.

[0115] The network configuration indicator includes the NAT type in the network settings of the current shared node, which affects the interconnection and interoperability between nodes. NAT types can be divided into Full Cone NAT, Restricted Cone NAT, Port-RestrictedCone NAT and Symmetric NAT, etc. Different NAT types have different friendliness to P2P connections, which affects the transmission efficiency of the live stream. In this regard, the network setting fixed score ScoreFixed can be pre-set according to the type, thereby providing the corresponding total indicator value. In one embodiment, regarding the setting of the fixed score ScoreFixed, Full Cone NAT is X, Port-Restricted Cone NAT is Y, Restricted Cone NAT and Symmetric NAT are Z, where X>Y>Z, to reflect the value of different types of indicators.

[0116] The system overhead index includes the remaining resources after the computing resources are consumed when the current shared node processes all live streams, such as the CPU usage margin CPULeft, the GPU usage margin GPULeft, and the memory usage margin MemLeft. These resource surpluses can comprehensively measure the ability of the current shared node to process live streams. Therefore, they need to be monitored in real time and quantified into a machine score floating score ScoreMachineFloated through weighted fusion as the total indicator value in order to evaluate the service capabilities of the shared node. In one embodiment, the floating score ScoreMachineFloated = CPULeft*f1+GPULeft*f2+MemLeft*f3. Among them, the weights f1>f3>f2.

[0117] Step S3230: perform weighted fusion on the total values ​​of each of the indicators to obtain a network service score as the network service condition, wherein the network response indicator is configured as a negative item, and the weight of each indicator is arranged from large to small as follows: network response indicator, system overhead indicator, and network configuration indicator.

[0118] After determining the total value of each indicator, the network service score ScoreFinal that represents the network service condition can be calculated using the following formula:

[0119] ScoreFinal=ScoreFixed*fa+ScoreMachineFloated*fb-ScoreStreamFloated*fc

[0120] Among them, ScoreFixed is the total value of the network configuration indicator, which is a fixed score determined by the corresponding NAT type, ScoreStreamFloated is the total value of the network response indicator, which is a floating score, and ScoreMachineFloated is the total value of the system overhead indicator, which is also a floating score. The weights fa, fb, and fc are arranged from large to small according to the importance of each indicator, and the weighted result of the network response indicator item is configured as a negative value to reflect the impact of the network response indicator as a negative item.

[0121] The network response index, as a negative item, reflects the real-time transmission performance of the live stream, mainly including packet loss rate and network delay. These indicators directly affect the quality of the live stream, so in one embodiment, they are given the greatest weight, and fc>fa>fb, so as to highlight the importance of the total value of each indicator in the calculation of the network service score.

[0122] It can be seen that the network service score ScoreFinal comprehensively considers the impact of network configuration, network response and system overhead, and provides a quantitative network service condition evaluation result. When ScoreFinal exceeds the preset conditional grace interval, it indicates that the current shared node has good network service conditions and can perform the live stream sharing task of the external live broadcast room. On the contrary, if ScoreFinal is lower than the conditional grace interval, or the surplus bandwidth resources are exhausted, it is necessary to limit the pull transmission of the live stream of the external live broadcast room to ensure the transmission quality and stability of the live stream of the current live broadcast room.

[0123] Specifically, the network service score ScoreFinal can be used to determine whether the current shared node is suitable for performing additional live stream sharing tasks. The value of ScoreFinal not only reflects the network service conditions of the current shared node, but is also directly related to the decision of whether to start a new channel and whether to maintain the existing channel. When ScoreFinal is a negative number, it indicates that the network service conditions of the current shared node are not sufficient to support additional live stream transmissions, so it is necessary to stop the establishment of new channels, and even disconnect channels such as non-consumer streams StreamB and StreamC to ensure that the live stream of the current live room StreamA is not affected. When ScoreFinal is greater than the preset ConstA value, it means that the current shared node has greater computing power and network redundancy, so these resources can be used first to perform live stream sharing tasks in external live rooms.

[0124] In another embodiment, when ScoreFinal exceeds a higher threshold value ConstB, it indicates that the current shared node not only has good network conditions, but also can easily achieve NAT penetration, and is suitable for undertaking those live sharing tasks that require high penetration capabilities. Therefore, it can be used as a criterion, for example, in step S3310, for the peer network to prioritize matching live sharing tasks that require high penetration capabilities for the current shared node. Since ConstB is greater than ConstA, and the conditional grace interval is actually limited to [0, ConstA], a hierarchical decision-making mechanism is provided to dynamically adjust the allocation and execution of live stream sharing tasks according to the specific value of ScoreFinal. Such a design can respond to changes in network conditions more flexibly and efficiently, and optimize the transmission and sharing of live streams.

[0125] This embodiment achieves accurate evaluation of shared node network service conditions by comprehensively considering network response indicators, system overhead indicators, and network configuration indicators, thereby achieving significant technical advantages at multiple levels, including but not limited to:

[0126] First, by real-time monitoring and quantifying these key indicators, this embodiment can ensure that additional live stream sharing tasks are undertaken only when the network conditions of the shared nodes permit. This effectively avoids the degradation of live stream transmission quality or task failure due to insufficient network conditions, and improves the stability and reliability of live stream transmission.

[0127] Secondly, this embodiment optimizes the efficiency of network resource usage by dynamically adjusting the allocation of live stream sharing tasks. When the network conditions are good, the shared nodes can make full use of their surplus bandwidth resources, while limiting additional transmission tasks when the network conditions are tight. This flexible resource management strategy reduces network congestion and improves overall transmission efficiency.

[0128] Furthermore, this embodiment provides a hierarchical decision-making mechanism for shared nodes by setting different thresholds (ConstA and ConstB), which can intelligently decide whether to start a new channel or maintain an existing channel according to the specific value of the network service score (ScoreFinal). This mechanism not only ensures the transmission quality of high-priority live streams, but also enables shared nodes to adapt to rapid changes in network conditions and adjust transmission strategies in a timely manner.

[0129] In addition, by preferentially matching live broadcast sharing tasks that require high penetration capabilities to those sharing nodes whose ScoreFinal exceeds the ConstB value, the success rate of NAT penetration is improved, which is particularly important for improving the transmission efficiency of live broadcast streams in P2P networks. In this way, this embodiment not only improves user experience, but also enhances the scalability and flexibility of the live broadcast platform, so that efficient and stable services can be maintained when facing large-scale user access.

[0130] On the basis of any embodiment of the method of the present application, when the network service condition is lower than the condition tolerance interval or the surplus bandwidth resources are exhausted, limiting the pull transmission of the live stream of the external live broadcast room includes:

[0131] Step S3410: When the network service condition is lower than the conditional grace interval or the surplus bandwidth resources are exhausted, a restriction event corresponding to restricting the pull transmission of the live stream of the external live broadcast room is triggered, and the live stream that needs to be restricted from pull transmission determined in response to the restriction event is obtained as the target live stream;

[0132] In this step, when it is monitored that the network service conditions are lower than the conditional grace interval or the surplus bandwidth resources are exhausted, a restriction event will be triggered. This restriction event is a response to the current network conditions, used to indicate that the network environment no longer supports additional live streaming transmission tasks. This restriction event can lead to the execution of step S5300, that is, determining the target live stream that needs to be restricted from pulling and transmitting. According to the mechanism of step S5300, one or more live streams are selected as target live streams according to the preset priority rules and the current network conditions. These target live streams will be restricted from pulling and transmitting to release bandwidth resources. For example, it may result in the selection of the live stream with the lowest priority as the target live stream.

[0133] Step S3420, terminating the pulling and transmitting of the target live stream, or disconnecting the connection of at least one shared node connected to the current shared node corresponding to the target live stream, so as to achieve the pulling and transmitting of the live stream of the restricted external live room;

[0134] The restriction processing of the target live stream may include terminating the pulling of these live streams, or disconnecting one or more shared nodes connected to the current shared node, thereby ensuring that the current network node can effectively reduce the network load and prevent the degradation of the live stream transmission quality due to insufficient bandwidth.

[0135] Step S3430: When the network service condition is lower than the condition tolerance interval, stop pulling and transmitting the live stream of the newly added external live broadcast room.

[0136] When the network service condition is lower than the condition tolerance range, the pull transmission of the live stream of the newly added external live broadcast room can be stopped to prevent the further increase of network load and ensure the stable transmission of the current live stream. At the same time, the pull request for the live stream of the new live broadcast room is also suspended until the network service condition improves, thus ensuring that the transmission of the existing live stream is not affected.

[0137] Through the above process, this embodiment can dynamically adjust the transmission strategy of the live stream, optimize resource allocation according to the real-time network conditions, ensure the stability and efficiency of the live stream transmission, thereby improving the adaptability and robustness of the live broadcast platform, and can respond quickly when network conditions change, ensuring the continuity and quality of user experience.

[0138] Based on any embodiment of the method of the present application, the method further includes:

[0139] Step S7100: When the graphical user interface where the current live broadcast room is located is switched to an invisible state, the live broadcast stream pulling and transmission of each external live broadcast room is suspended, and a stream pulling suspension notification is sent to the relevant shared nodes that are pulling and transmitting the live broadcast stream;

[0140] For the current shared node, when the graphical user interface of the live broadcast room it is accessing is switched to an invisible state, specific operations can be performed to optimize resource usage and battery consumption. Specifically, the visibility state of the graphical user interface of the current live broadcast room is usually caused by user interaction, such as the user switching to another application or locking the screen. Once it is detected that the graphical user interface of the live broadcast room is no longer visible, the live stream pulling transmission of all external live broadcast rooms is automatically suspended. This is to reduce unnecessary data transmission, thereby reducing network bandwidth occupancy and energy consumption of terminal devices. In the process of suspending the pull-stream transmission, the current shared node sends a pull-stream suspension notification to the relevant shared nodes that are pulling and transmitting these live streams to inform the shared nodes that the current live stream transmission has been suspended.

[0141] In addition, when sending the notification of pausing the streaming, the status of the live stream currently being transmitted will also be recorded, including the amount of cached data, transmission progress, etc., so that when the live stream transmission is resumed, it can be transmitted from the correct position to ensure that the continuity of the live stream is not affected.

[0142] Step S7200: maintaining the data communication connection with the relevant shared node during the suspension of the streaming transmission until a preset time period is reached;

[0143] In order to maintain the stability of the network connection and avoid the additional overhead caused by frequent establishment and disconnection of the connection, while the live streaming transmission is suspended, the data communication connection with the relevant shared nodes is maintained until a preset duration is reached. The preset duration for maintaining the connection can be predetermined based on a variety of factors, such as network conditions, battery life of the shared nodes, and user usage habits. During this preset duration, the visibility status of the graphical user interface is continuously monitored, and the live streaming transmission is ready to be resumed at any time.

[0144] Step S7300: During the suspension of the streaming transmission, when the graphical user interface is switched to a visible state, a streaming resumption notification is sent to the relevant sharing nodes to resume the streaming transmission of each live stream.

[0145] When the user switches back to the live broadcast room, that is, when the graphical user interface where the live stream of the current live broadcast room is located becomes visible again, it is necessary to respond quickly and resume the transmission of the live stream. Specifically, once the change in the visibility of the graphical user interface is detected and it is confirmed that it has switched from an invisible state to a visible state, the recovery process of the live stream transmission can be triggered. In this process, a stream pull resumption notification is sent to the relevant shared nodes that previously paused the transmission. This notification will instruct the shared node to restart pulling and transmitting the previously paused live stream. In order to ensure the continuity of the live stream, the status information of the live stream is recorded during the pause period, including the amount of cached data and the transmission progress, so that the relevant shared nodes can continue to pull the stream from the paused position without starting from the beginning, thereby ensuring the smoothness of the user experience.

[0146] For example, if a user receives a phone call while watching a live broadcast, the GUI of the live broadcast room may be temporarily invisible, pausing the pull and transmission of the live stream. After the call is over, the user returns to the live broadcast room, the interface becomes visible again, and a pull and transmission resumption notification is sent, and the transmission of the live stream is resumed, and the user can continue to watch the live broadcast with almost no interruption.

[0147] In this way, the embodiment can maximize the use of network resources while maintaining the efficiency and stability of live streaming transmission, providing users with a smoother and higher-quality live experience. When the technical solution of the present application is applied to mobile terminals such as smart phones, it can also run smoothly and stably.

[0148] See also Figure 3 According to one aspect of the present application, a live stream parallel processing device is provided, comprising an internal demand service module 3100, an environment monitoring module 3200, an external demand service module 3300, and an external demand restriction module 3400, wherein the internal demand service module 3100 is configured to continuously pull the live stream of the current live room required for playing the graphical user interface of the current sharing node from the peer-to-peer network, and transmit the live stream to other sharing nodes participating in the live stream sharing task corresponding to the current live room; the environment monitoring module 3200 is configured to continuously detect the surplus bandwidth resources and network service conditions of the current sharing node in real time; the external demand service module 3300 is configured to use the surplus bandwidth resources to execute the live stream sharing task corresponding to the external live room when the network service condition exceeds a preset conditional grace interval, and continuously pull the live stream of the external live room from the peer-to-peer network and transmit it to the sharing nodes participating in the corresponding live stream sharing task; the external demand restriction module 3400 is configured to limit the pulling and transmission of the live stream of the external live room when the network service condition is lower than the conditional grace interval or the surplus bandwidth resources are exhausted.

[0149] Based on any embodiment of the device of the present application, the internal demand service module 3100 includes: an internal demand acquisition module, which is configured to obtain the live stream sharing list of the current live room from the peer network according to the graphical user interface of the current sharing node in the current live room being accessed, and the live stream sharing list includes the network addresses of multiple sharing nodes participating in the live stream sharing task of the corresponding live room; an internal demand stream pulling module, which is configured to establish a connection to the sharing node participating in the corresponding live stream sharing task based on the network address, and continuously pull the live stream of the current live room through the connected sharing node for local caching; an internal demand transmission module, which is configured to respond to the stream pulling transmission event of any sharing node participating in the corresponding live stream sharing task, and transmit the cached live stream corresponding to the current live room to it.

[0150] Based on any embodiment of the device of the present application, the external demand service module 3300 includes: an external demand acquisition module, which is configured to obtain a live stream sharing task that matches the network service condition from a peer network, and obtain a live stream sharing list of the corresponding external live room, wherein the live stream sharing list includes the network addresses of multiple shared nodes participating in the live stream sharing task of the corresponding live room; an external demand stream pulling module, which is configured to establish a connection to the shared node participating in the corresponding live stream sharing task based on the network address, and continuously pull the live stream of the corresponding external live room through the connected shared node for local caching; an external demand transmission module, which is configured to respond to a stream pulling transmission event of any shared node participating in the corresponding live stream sharing task, and transmit the cached live stream corresponding to the corresponding external live room to it.

[0151] On the basis of any embodiment of the device of the present application, the device also includes: an occupancy determination module, which is configured to determine the degree of utilization of surplus bandwidth resources by each live stream based on the real-time transmission bit rate of the live stream of the external live broadcast room and the total number of shared nodes that participate in the live broadcast sharing task of the live stream and are connected to the current shared node; a level setting module, which is configured to set the priority of the corresponding live stream according to the utilization level of the live stream of each external live broadcast room on the basis of maintaining the live stream of the current live broadcast room as the highest priority; a stream selection restriction module, which is configured to respond to a restriction event corresponding to restricting the pull transmission of the live stream of the external live broadcast room, and select the live stream that needs to be restricted from pulling transmission according to the priority from low to high, except for the live stream of the current live broadcast room.

[0152] Based on any embodiment of the device of the present application, the environment monitoring module 3200 includes: a bandwidth determination module, which is configured to respectively count the bandwidth margins of the uplink bandwidth and the downlink bandwidth of the current shared node after being occupied by the live stream, and when any one of the bandwidth margins of the uplink bandwidth and the downlink bandwidth exceeds its corresponding preset threshold, the corresponding bandwidth margin is determined as the corresponding surplus bandwidth resource; an indicator quantification module, which is configured to obtain the network response index of the live stream of the current live room, the network configuration index and the system overhead index of the current shared node obtained by real-time detection, and determine the corresponding total number of indicators; a condition determination module, which is configured to weightedly fuse the total number of each indicator to obtain a network service score as the network service condition, wherein the network response indicator is configured as a negative item, and the weights of each indicator are arranged from large to small as follows: network response indicator, system overhead indicator, network configuration indicator.

[0153] Based on any embodiment of the device of the present application, the external demand restriction module 3400 includes: a target determination module, which is configured to trigger a restriction event corresponding to restricting the pull transmission of the live stream of the external live broadcast room when the network service condition is lower than the condition grace interval or the surplus bandwidth resources are exhausted, and obtain the live stream that needs to be restricted from pulling and transmitting in response to the restriction event as the target live stream; a restriction execution module, which is configured to terminate the pull transmission of the target live stream, or disconnect the connection of at least one shared node corresponding to the target live stream that is connected to the current shared node, so as to achieve the restriction of the pull transmission of the live stream of the external live broadcast room; an extreme processing module, which is configured to stop the pull transmission of the live stream of the newly added external live broadcast room when the network service condition is lower than the condition grace interval.

[0154] Based on any embodiment of the device of the present application, the device also includes: a hidden response module, which is configured to suspend the streaming transmission of the live streams of each external live room when the graphical user interface where the current live room is located is switched to an invisible state, and send a streaming suspension notification to the relevant shared node that is pulling and transmitting the live stream; a link maintenance module, which is configured to maintain the data communication connection with the relevant shared node during the suspension of streaming transmission until a preset duration is reached; a recovery execution module, which is configured to send a streaming recovery notification to the relevant shared node when the graphical user interface is switched to a visible state during the suspension of streaming transmission, and resume the streaming transmission of each live stream.

[0155] Another embodiment of the present application also provides a live stream parallel processing device. Figure 4 As shown, a schematic diagram of the internal structure of a live stream parallel processing device. The live stream parallel processing device includes a processor, a computer-readable storage medium, a memory, and a network interface connected through a system bus. Among them, the computer-readable non-volatile readable storage medium of the live stream parallel processing device stores an operating system, a database, and computer-readable instructions. The database may store an information sequence. When the computer-readable instructions are executed by the processor, the processor can implement a live stream parallel processing method.

[0156] The processor of the live stream parallel processing device is used to provide computing and control capabilities to support the operation of the entire live stream parallel processing device. The memory of the live stream parallel processing device may store computer-readable instructions, and when the computer-readable instructions are executed by the processor, the processor may execute the live stream parallel processing method of the present application. The network interface of the live stream parallel processing device is used to connect and communicate with a terminal.

[0157] Those skilled in the art will understand that Figure 4 The structure shown in the figure is only a block diagram of a part of the structure related to the scheme of the present application, and does not constitute a limitation on the live stream parallel processing device to which the scheme of the present application is applied. The specific live stream parallel processing device may include more or fewer components than those shown in the figure, or combine certain components, or have a different component arrangement.

[0158] In this embodiment, the processor is used to execute Figure 3 The memory stores the program code and various data required to execute the above modules or submodules. The network interface is used to realize data transmission between user terminals or servers. The non-volatile readable storage medium in this embodiment stores the program code and data required to execute all modules in the live stream parallel processing device of this application, and the server can call the program code and data of the server to execute the functions of all modules.

[0159] The present application also provides a non-volatile readable storage medium storing computer-readable instructions. When the computer-readable instructions are executed by one or more processors, the one or more processors execute the steps of the live stream parallel processing method of any embodiment of the present application.

[0160] The present application also provides a computer program product, including a computer program / instruction, which implements the steps of the method described in any embodiment of the present application when executed by one or more processors.

[0161] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiments of the present application can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile readable storage medium. When the program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, the aforementioned storage medium can be a computer-readable storage medium such as a disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM).

[0162] In summary, this application brings significant application advantages to the live broadcast platform, and optimizes the live streaming transmission by real-time monitoring and dynamic adjustment of the network service conditions and surplus bandwidth resources of shared nodes. It not only improves the utilization efficiency of network resources and reduces the distribution pressure of the server, but also enhances the scalability and flexibility of live streaming transmission, so that the stable transmission of live streaming can be ensured even when the network conditions are unstable or the bandwidth is limited. In addition, this application improves the user experience and enhances the adaptability and robustness of live streaming transmission by processing multiple live streams in parallel on the terminal device side and dynamically adjusting the transmission strategy, so that the live broadcast platform can quickly respond and maintain the continuity and quality of the service in the face of network fluctuations and changes, providing users with a smoother and higher-quality live broadcast experience.

Claims

1. A method for parallel processing of live streams, characterized in that: include: Continuously pull the live stream of the current live room required for playing the graphical user interface of the current sharing node from the peer-to-peer network, and transmit the live stream to other sharing nodes participating in the live stream sharing task corresponding to the current live room; Continuously detect the surplus bandwidth resources and network service conditions of the current shared nodes in real time; When the network service condition exceeds the preset conditional grace interval, the surplus bandwidth resources are used to execute the live stream sharing task corresponding to the external live broadcast room, and the live stream of the external live broadcast room is continuously pulled from the peer-to-peer network and transmitted to the sharing nodes participating in the corresponding live stream sharing task; When the network service condition is lower than the condition tolerance interval or the surplus bandwidth resources are exhausted, the pull transmission of the live stream of the external live broadcast room is restricted.

2. The method for parallel processing of live streams according to claim 1, characterized in that: Continuously pull the live stream of the current live room required for playing the graphical user interface of the current sharing node from the peer-to-peer network, and transmit the live stream to other sharing nodes participating in the live stream sharing task corresponding to the current live room, including: According to the graphical user interface of the current sharing node, in the current live broadcast room being accessed, obtaining a live stream sharing list of the current live broadcast room from a peer network, wherein the live stream sharing list includes network addresses of multiple sharing nodes participating in the live stream sharing task of the corresponding live broadcast room; Establishing a connection to a sharing node participating in the corresponding live stream sharing task based on the network address, and continuously pulling the live stream of the current live broadcast room through the connected sharing node for local caching; In response to a stream pulling transmission event of any sharing node participating in the corresponding live stream sharing task, the cached live stream corresponding to the current live broadcast room is transmitted to the node.

3. The method for parallel processing of live streams according to claim 1, characterized in that: Continuously pull the live stream of the external live broadcast room from the peer-to-peer network and transmit it to the sharing nodes participating in the corresponding live stream sharing task, including: Acquire a live stream sharing task matching the network service condition from a peer-to-peer network, and obtain a live stream sharing list of a corresponding external live broadcast room, wherein the live stream sharing list includes network addresses of multiple sharing nodes participating in the live stream sharing task of the corresponding live broadcast room; Establishing a connection to a sharing node participating in the corresponding live stream sharing task based on the network address, and continuously pulling the live stream of the corresponding external live broadcast room through the connected sharing node for local caching; In response to a stream pulling transmission event of any shared node participating in the corresponding live stream sharing task, the cached live stream corresponding to the corresponding external live broadcast room is transmitted to the shared node.

4. The method for parallel processing of live streams according to claim 1, characterized in that: The method further comprises: Determine the degree of utilization of surplus bandwidth resources by each live stream according to the real-time transmission bit rate of the live stream of the external live broadcast room and the total number of sharing nodes participating in the live sharing task of the live stream and connected to the current sharing node; On the basis of maintaining the live stream of the current live broadcast room as the highest priority, the priority of the corresponding live stream is set according to the utilization level of the live stream of each external live broadcast room; In response to a restriction event corresponding to restricting the pull transmission of the live stream of an external live broadcast room, in addition to the live stream of the current live broadcast room, the live streams that need to be restricted from pull transmission are selected according to priority from low to high.

5. The method for parallel processing of live streams according to claim 1, characterized in that: Continuously detect the surplus bandwidth resources and network service conditions of the current shared nodes in real time, including: The bandwidth margins of the uplink bandwidth and the downlink bandwidth of the current shared node after being occupied by the live stream are counted respectively, and when any one of the bandwidth margins of the uplink bandwidth and the downlink bandwidth exceeds its corresponding preset threshold, the corresponding bandwidth margin is determined as the corresponding surplus bandwidth resource; Obtain the network response index of the live stream of the current live broadcast room, the network configuration index of the current shared node and the system overhead index obtained by real-time detection, and determine the corresponding total index values; The total values ​​of each of the indicators are weighted and integrated to obtain a network service score as the network service condition, wherein the network response indicator is configured as a negative item, and the weight of each indicator is arranged from large to small as follows: network response indicator, system overhead indicator, and network configuration indicator.

6. The method for parallel processing of live streams according to claim 1, characterized in that: When the network service condition is lower than the condition tolerance interval or the surplus bandwidth resources are exhausted, limiting the pull transmission of the live stream of the external live broadcast room, including: When the network service condition is lower than the conditional grace interval or the surplus bandwidth resources are exhausted, a restriction event corresponding to restricting the pull transmission of the live stream of the external live broadcast room is triggered, and the live stream that needs to be restricted from pull transmission determined in response to the restriction event is obtained as the target live stream; Terminating the pull transmission of the target live stream, or disconnecting at least one shared node corresponding to the target live stream that is connected to the current shared node, so as to achieve the pull transmission of the live stream limiting the external live room; When the network service condition is lower than the condition tolerance interval, the pull transmission of the live stream of the newly added external live broadcast room is stopped.

7. The method for parallel processing of live streams according to any one of claims 1 to 6, characterized in that: The method further comprises: When the graphical user interface where the current live broadcast room is located is switched to an invisible state, the live stream pulling and transmission of each external live broadcast room is suspended, and a pull stream suspension notification is sent to the relevant shared nodes that are pulling and transmitting the live stream; During the suspension of the streaming transmission, the data communication connection with the relevant shared node is maintained until a preset time period is reached; During the suspension of the streaming transmission, when the graphical user interface is switched to a visible state, a streaming resumption notification is sent to the relevant sharing nodes to resume the streaming transmission of each live stream.

8. A live stream parallel processing device, characterized in that: include: The internal demand service module is configured to continuously pull the live stream of the current live broadcast room required for playing the graphical user interface of the current sharing node from the peer-to-peer network, and transmit the live stream to other sharing nodes participating in the live stream sharing task corresponding to the current live broadcast room; An environment monitoring module is configured to continuously detect the surplus bandwidth resources and network service conditions of the current shared nodes in real time; The external demand service module is configured to use the surplus bandwidth resources to execute the live stream sharing task corresponding to the external live broadcast room when the network service condition exceeds the preset conditional grace interval, and continuously pull the live stream of the external live broadcast room from the peer-to-peer network and transmit it to the sharing node participating in the corresponding live stream sharing task; The external demand restriction module is configured to restrict the pull transmission of the live stream of the external live broadcast room when the network service condition is lower than the condition tolerance interval or the surplus bandwidth resources are exhausted.

9. A live stream parallel processing device, comprising a central processing unit and a memory, characterized in that: The central processing unit is used to call and run the computer program stored in the memory to execute the steps of the method according to any one of claims 1 to 7.

10. A non-volatile readable storage medium, characterized in that: It stores a computer program implemented according to the method described in any one of claims 1 to 7 in the form of computer-readable instructions, and when the computer program is called and executed by a computer, the steps included in the corresponding method are executed.

Images