Network live broadcast method and device, electronic equipment and nonvolatile storage medium

Abstract

The invention discloses a network live broadcast method and device, electronic equipment and a nonvolatile storage medium. The method comprises the steps that a playing request sent by a target object is received, and the playing request comprises program channel information in an IPTV service; determining a channel ID corresponding to the program channel information in the IPTV service from a channel playing list; a uniform resource locator corresponding to the channel ID is inquired from a first-level node in the live broadcast system, and the first-level node is used for creating and recording program channels in all IPTV (Internet Protocol Television) services; and according to the uniform resource locator, pulling the corresponding target slice live stream data from the slice server through the first-level node. The technical problems that the user experience is poor, the reliability of the live broadcast service is low and the live broadcast service is interrupted due to wireless network live broadcast are solved.

Description

Technical Field

[0001] The present application relates to the field of IPTV technology, and in particular to a method, device, electronic device and non-volatile storage medium for network live broadcasting. Background Art

[0002] Internet Protocol TV (IPTV) services are limited to private network services and only support wired installation. The threshold for business promotion is high, and compared with Internet services, they are obviously disadvantaged. Supporting wireless installation through the gateway full routing mode and routing table can reduce wiring, create a simple, beautiful, and low-carbon new look, promote business development, and bring new vitality to the IPTV business. Combining the Internet Protocol Television Application Package Kit (IPTV APK) with wireless installation to promote IPTV services can lower the threshold for business installation and greatly save hardware terminal costs. However, compared with traditional wired live broadcasts, IPTV wireless network live broadcasts have the problem of live broadcast service viewing freezes, poor user perception, high installation threshold, low reliability of live broadcast services, and live broadcast services may be interrupted.

[0003] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0004] The embodiments of the present application provide a method, device, electronic device and non-volatile storage medium for live broadcasting on a network, so as to at least solve the technical problems of poor user experience, low reliability of live broadcasting and interruption of live broadcasting caused by wireless network live broadcasting.

[0005] According to one aspect of an embodiment of the present application, a method for live broadcasting is provided, including: receiving a playback request sent by a target object, wherein the playback request includes program channel information in an Internet television IPTV service; determining a channel ID corresponding to the program channel information in the Internet television IPTV service from a channel play list; querying a uniform resource locator corresponding to the channel ID from a first-level node in a live broadcasting system, wherein the first-level node is used to create and record program channels in all Internet television IPTV services; based on the uniform resource locator, pulling corresponding target slice live stream data from a slice server through the first-level node, wherein the slice server stores slice live streams corresponding to program channels in all Internet television IPTV services.

[0006] In some embodiments of the present application, the slice server is deployed in a slice server cluster, and the method also includes: when an abnormality occurs in the slice server, the slice live streams corresponding to all program channels in the abnormal slice server are rebuilt to other slice servers in the slice server cluster.

[0007] In some embodiments of the present application, the slice server includes a primary slice server and a backup slice server. A preset number of primary slice servers constitute a primary slice server cluster, and a preset number of backup slice servers constitute a backup slice server cluster.

[0008] In some embodiments of the present application, the method also includes: determining whether the program channel information in the playback request is popular channel information, and obtaining a determination result; when the determination result indicates that the program channel information in the playback request is popular channel information, obtaining load information of other slice servers; when the load of the slice server that plays the popular channel information exceeds a first preset threshold, allocating the slice tasks corresponding to the popular channel information to other slice servers based on the load information of other slice servers.

[0009] In some embodiments of the present application, the corresponding target slice live stream is pulled from the slice server through the first-level node, including: when the program channel information included in the playback request is popular channel information, obtaining the channel ID of the popular channel play list from the channel play list; querying the first uniform resource locator corresponding to the channel ID from the first-level node in the live broadcast system; based on the first uniform resource locator, pulling the corresponding target slice live stream from the slice server through the first-level node.

[0010] In some embodiments of the present application, the corresponding target slice live stream is pulled from the slice server through the first-level node, including: when the program channel information included in the playback request is unpopular channel information, the playback request is reported to the first-level node; the second uniform resource locator corresponding to the playback request is queried from the first-level node in the live broadcast system; based on the second uniform resource locator, the corresponding target slice live stream is pulled from the slice server through the first-level node.

[0011] In some embodiments of the present application, the first-level node includes an active first-level node and a backup first-level node. The active first-level node has a higher priority than the backup first-level node. When an abnormality occurs in the active first-level node, the backup first-level node is switched to.

[0012] In some embodiments of the present application, the corresponding target slice live stream is pulled from the slice server through the first-level node, including: pulling the target slice live stream from the main slice server in the slice server through the first-level node; when the number of failures in pulling the target slice live stream through the main slice server reaches a second preset threshold, using the backup slice server in the slice server to pull the target slice live stream.

[0013] According to another aspect of an embodiment of the present application, a device for live broadcasting is also provided, including: a receiving module, used to receive a playback request sent by a target object, wherein the playback request includes program channel information in an Internet television IPTV service; a determining module, used to determine a channel ID corresponding to the program channel information in the Internet television IPTV service from a channel play list; a query module, used to query a uniform resource locator corresponding to the channel ID from a first-level node in a live broadcasting system, wherein the first-level node is used to create and record program channels in all Internet television IPTV services; a pulling module, used to pull corresponding target slice live stream data from a slice server through a first-level node based on the uniform resource locator, wherein the slice server stores slice live streams corresponding to program channels in all Internet television IPTV services.

[0014] According to another aspect of an embodiment of the present application, a non-volatile storage medium is further provided, in which a program is stored, wherein when the program is running, a device where the non-volatile storage medium is located is controlled to execute the above-mentioned network live broadcast method.

[0015] According to another aspect of an embodiment of the present application, an electronic device is also provided, including: a memory and a processor, the processor being used to run a program stored in the memory, wherein the above-mentioned network live broadcast method is executed when the program is run.

[0016] According to another aspect of an embodiment of the present application, a computer program product is also provided, including computer instructions, which implement the above-mentioned network live broadcast method when executed by a processor.

[0017] In an embodiment of the present application, a play request sent by a target object is received, wherein the play request includes program channel information in an Internet television IPTV service; a channel ID corresponding to the program channel information in the Internet television IPTV service is determined from a channel play list; a uniform resource locator corresponding to the channel ID is queried from a first-level node in a live broadcast system, wherein the first-level node is used to create and record program channels in all Internet television IPTV services; based on the uniform resource locator, corresponding target slice live stream data is pulled from a slice server through a first-level node, wherein the slice server stores slice live streams corresponding to program channels in all Internet television IPTV services, by determining the channel ID corresponding to the program channel information in the Internet television IPTV service from a channel play list, finding the corresponding uniform resource locator according to the channel ID, thereby pulling the corresponding target slice live stream data, layer by layer, and finally returning it to the user for live viewing. By cutting the live stream into slice live streams, the stability and user experience of the live service can be significantly improved, and it can also better adapt to the modern network environment and the diversity of user devices, thereby solving the poor user experience caused by wireless network live broadcast, the low reliability of the live service and the technical problems of interruption of the live service. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0019] Figure 1 It is a hardware structure block diagram of a computer terminal for implementing a method for network live broadcasting according to an embodiment of the present application;

[0020] Figure 2 It is a flowchart of a method for live broadcasting on the Internet according to an embodiment of the present application;

[0021] Figure 3 is a schematic diagram of the system architecture of a method for live broadcasting on the Internet according to an embodiment of the present application;

[0022] Figure 4 It is a schematic diagram of a system-level automatic disaster recovery process of a network live broadcast method according to an embodiment of the present application;

[0023] Figure 5 This is a schematic diagram of a service adaptive switching process of a network live broadcast method according to an embodiment of the present application;

[0024] Figure 6 It is a structural diagram of a network live broadcast device according to an embodiment of the present application. DETAILED DESCRIPTION

[0025] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present application.

[0026] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0027] In order to better understand the embodiments of the present application, the technical terms involved in the embodiments of the present application are explained as follows:

[0028] HTTP Live Streaming (HLS) is an adaptive bitrate streaming protocol based on HTTP: HLS uses the HTTP protocol for transmission, which means that it can utilize the existing HTTP server and content delivery network (CDN) infrastructure without the need for a dedicated streaming server. HLS provides multiple audio and video clips with different bitrates, allowing the client to automatically select the most appropriate bitrate for playback based on network conditions, thereby providing a good playback experience even in a low-bandwidth environment. HLS supports breakpoint resumption, that is, if the network connection is interrupted during playback, the client (user end) can continue to request the next clip from the interrupted position to achieve seamless playback. HLS uses a playlist in the playlist (M3U8) format to describe the metadata of the audio and video stream, including the Uniform Resource Locator (URL), duration, bitrate and other information of the clip. The client (user end) decides which clips to play based on this information.

[0029] Real Time Streaming Protocol (RTSP): An application layer protocol in the Transmission Control Protocol (TCP) / IP protocol system. It is a network protocol used to control real-time media. It can perform real-time transmission and control of media data. It is often used in audio and video stream transmission scenarios. RTSP is mainly used for real-time data on-demand and streaming media services. It can control media playback, pause, fast forward, fast rewind and other operations. The RTSP protocol is based on a request / response model, similar to the HTTP protocol, but it focuses more on the control of real-time data streams. RTSP can use TCP or User Datagram Protocol (UDP) for data transmission, which makes it flexible under different network conditions. In addition, RTSP also supports a variety of media encoding formats, such as MPEG, H.264, etc., and can handle multiple synchronized media streams, such as transmitting video and audio at the same time.

[0030] Server Load Balancing (SLB): supports load balancing and health checks. It is a technology that distributes workloads to multiple servers or network devices in a network to optimize resource usage, maximize throughput, minimize response time, and avoid overloading any single server. Load balancing can ensure high availability and fault tolerance, and is a key component for building a stable and reliable service architecture.

[0031] In the related art, Internet Protocol TV (IPTV) services are limited to private network services and only support wired installation. The threshold for business promotion is high, and it has obvious disadvantages compared with Internet services. Supporting wireless installation through the gateway full routing mode and routing table can reduce wiring, create a simple, beautiful, and low-carbon new look, promote business development, and bring new vitality to the IPTV business. Combining IPTV APK wireless installation to promote IPTV services can lower the threshold for business installation and greatly save hardware terminal costs. However, compared with traditional wired live broadcasts, IPTV's wireless network live broadcast has the problem of live broadcast service viewing freezes, poor user perception, high installation threshold, low reliability of live broadcast services, and interruptions of live broadcast services. Therefore, there are problems of poor user experience, low reliability of live broadcast services, and interruptions of live broadcast services due to wireless network live broadcasts. In order to solve this problem, a relevant solution is provided in the embodiments of the present application, which is described in detail below.

[0032] According to an embodiment of the present application, an embodiment of a method for live broadcasting is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0033] The method embodiments provided in the embodiments of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 The hardware structure block diagram of a computer terminal for implementing a method for network live broadcast is shown. Figure 1 As shown, the computer terminal 10 may include one or more (102a, 102b, ..., 102n are used to illustrate) processors 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 104 for storing data, and a transmission module 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the BUS bus), a network interface, a power supply and / or a camera. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.

[0034] It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuits". The data processing circuits may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuit may be a single independent processing module, or may be incorporated in whole or in part into any of the other components in the computer terminal 10. As described in the embodiments of the present application, the data processing circuit acts as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0035] The memory 104 can be used to store software programs and modules of application software, such as program instructions / data storage devices corresponding to the method of live broadcasting on the Internet in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, realizing the above-mentioned method of live broadcasting on the Internet. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the computer terminal 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0036] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the computer terminal 10. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0037] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the computer terminal 10 .

[0038] In the above operating environment, the present application embodiment provides a flowchart of a method for live broadcasting on the Internet, such as Figure 2 As shown, the method comprises the following steps:

[0039] Step S202: receiving a play request sent by a target object (eg, a terminal user), wherein the play request includes program channel information in an Internet protocol television (IPTV) service.

[0040] In the technical solution provided in step S202, the terminal user sends a play request to a secondary node for providing user services, and the secondary node in the live broadcast system receives the play request sent by the target object.

[0041] It should be noted that the above-mentioned secondary nodes support health checks and load balancing based on SLB. If the user makes three consecutive requests to the secondary node of the service without a response, it will automatically switch to other secondary node services to ensure that the user business is not aware of the abnormality of a single node. The health check is mainly used to monitor the health status of the backend server. For example, to ensure that user requests can be forwarded to the normal running service. Health checks can be implemented in the following ways: 1. Regular detection: The secondary node regularly sends heartbeat detection requests, such as HTTP requests, to the primary node or slice server to confirm its own running status. The frequency of heartbeat detection can be adjusted according to system requirements (for example, maintaining an interaction every 3 minutes). If no heartbeat response is received within the predetermined time, SLB will mark the node as unhealthy. 2. Response time detection: SLB can also monitor the response time of each secondary node to process requests. If the response time exceeds the preset threshold, the node is marked as unhealthy. 3. Error rate detection: SLB can count the ratio of error responses returned by the secondary node. If the error rate exceeds the threshold, the node will be marked as unhealthy. 4. Resource usage detection: Monitor the CPU, memory usage, and disk I / O utilization of the secondary node. If the resource usage exceeds the preset threshold, the node will be considered to be in a potentially unhealthy state.

[0042] The goal of load balancing is to evenly distribute user requests to multiple secondary nodes to optimize resource usage and improve service response speed. For example, load balancing can be achieved through the following methods: 1. Round robin: SLB distributes requests to different secondary nodes in turn in order. 2. Least connections: SLB distributes new user requests to the secondary node with the least current connections, thereby ensuring that the load of all nodes is as even as possible. 3. Weighted least connections: On the basis of least connections, a weight is assigned to each secondary node, and SLB distributes requests to the node based on the weight and number of connections. Nodes with high weights will receive more requests. 4. Session persistence: If a user has previously established a connection with a secondary node, all subsequent requests from the user will be directed to the same node to maintain session continuity. 5. Content-based routing: SLB distributes requests to secondary nodes that specialize in processing that type of content based on the content or parameters of the request (such as the type of program channel requested by the user). 6. Intelligent scheduling: Combined with AI algorithms, SLB can predict the load of each secondary node and perform intelligent scheduling to distribute requests to nodes with lower load or stronger processing capabilities.

[0043] Step S204: determining a channel ID corresponding to the program channel information in the IPTV service from the channel playlist (eg, M3U8 file).

[0044] In the technical solution provided in step S204, all secondary nodes (actually providing user services) create hot channels. When a user requests a live broadcast of a hot channel, the secondary node receives the user request information, matches the m3u8 file ID (i.e., the above-mentioned channel ID) of the channel on its own node, and actively carries the ID identifier to the primary node to obtain the uniform resource locator (Uniform Resource Locator, referred to as URL) for playback. URL is a standard format for identifying and locating resources on the Internet. It provides a method to specify the location of documents or other resources on the Internet, as well as the mechanism and protocol for obtaining these resources. The m3u8 file is a kind of M3U (MPEG URL) format, which is generally used for storing and transmitting streaming media playlist information, especially when using the HLS protocol for live or on-demand video content. It is a plain text file containing the URL addresses of multiple media segments (video or audio), as well as the relevant metadata for playing these media segments. In the live broadcast of network TV in a wireless environment, the m3u8 file plays a key role, which helps the client switch between different CDN nodes or slice servers to achieve a smooth live viewing experience, and can automatically select the optimal path to provide services even when the network fluctuates or the server fails.

[0045] Step S206, querying the uniform resource locator (eg, URL) corresponding to the channel ID from the first-level node in the live broadcast system, wherein the first-level node is used to create and record program channels in all network television IPTV services.

[0046] In the technical solution provided in step S206, the first-level node is used to create and record the program channels in all network television IPTV services. The first-level node is equivalent to the intermediate node between the second-level node and the slice server. The first-level node includes the main first-level node and the backup first-level node. The priority of the main first-level node is higher than the backup first-level node. In the case of an abnormality in the main first-level node, it will switch to the backup first-level node. This master-slave mechanism can effectively prevent the interruption of live broadcast services caused by the failure of the first-level node, improve the overall reliability of the system and the continuity of live broadcast services, and is suitable for scenarios with high requirements for the stability of live broadcast services, such as enterprise-level live broadcasts, important press conferences, etc., and can ensure the high quality and high availability of live broadcast services.

[0047] Step S208, according to the uniform resource locator, pull the corresponding target slice live stream data (for example, HLS slice live stream) from the slice server through the first-level node, wherein the slice server stores the slice live streams corresponding to the program channels in all network television IPTV services.

[0048] In the technical solution provided in step S208, the slice server is deployed in a slice server cluster. When an abnormality occurs in a slice server, the slice live streams corresponding to all program channels in the abnormal slice server are rebuilt on other slice servers in the slice server cluster. The slice server includes a primary slice server and a backup slice server. A preset number (an integer greater than zero, for example, 3) of primary slice servers constitute a primary slice server cluster, and a preset number of backup slice servers constitute a backup slice server cluster. Through the setting of the primary and backup clusters, not only can the primary slice server be quickly switched to the backup slice server when it fails, but also the ratio of the primary and backup slice servers can be dynamically adjusted during business peaks to optimize resource allocation and improve the response speed and user satisfaction of the live broadcast service.

[0049] The following is a specific embodiment:

[0050] As a key network element for HLS live broadcast, the slice server has a master and backup remote computer room. When a single device is abnormal, the program channel can be automatically migrated without business perception. Multiple slice servers constitute a slice server cluster. After calculating the number of program channels in the existing network, for example, the slice server cluster deploys 3 slice servers. All program channels in the entire network are evenly distributed on the 3 slice servers by number through the consistent hashing algorithm. The channel management system is configured with full channel information. At the same time, the management system (i.e., the above-mentioned live broadcast system) establishes HeartBeat heartbeat detection with the slice server through an http interactive connection (maintaining an interaction every 3 minutes). When no heartbeat is received, it is judged that slice server 1 is abnormal. The channel management system carries the program channel creation message of server 1, rebuilds all program channels of slice server 1 to slice server 2 and slice server 3, and records the program channel data of this node. The number of program channels of slice server 1 is recorded as 0, and the program channels are distributed on the other two slice servers. At the same time, hotspot detection is performed, program channel playback data is recorded, and channels that exceed the playback quantity are marked as popular channel information. A neighbor field is added, which contains the load conditions of other slice servers. When the load of a single slice server increases (the threshold reaches 80%), intelligent scheduling is performed (for example, based on the current network conditions, the load conditions of other slice servers, and the popularity of the channel, intelligently reallocate the slice tasks of some channels to slice servers with lower loads). This scheduling usually uses a consistent hashing algorithm to ensure that channel switching is smooth and does not cause interruptions or delays perceived by users. Back-source between nodes, for example: if the load problem of a slice server is caused by the instability of the channel source, the system will perform back-source operations between nodes. That is, when a slice server finds that the quality of the live stream it obtains from the main source has degraded or been interrupted, it will automatically switch to the backup source to obtain the live stream, and then re-slice it. At the same time, other nodes in the system will also monitor the situation they have detected. In the case of a live broadcast source failure, the system returns to the slice server with more stable quality to obtain a better live broadcast stream. This mechanism helps to quickly restore the quality of the live broadcast stream and ensure the user's viewing experience when the live broadcast source fails. When the load of a slice server (such as slice server 1) suddenly increases and approaches or exceeds the threshold of its processing capacity, the "neighbors" of this server (such as slice server 2 and slice server 3) can be learned through the neighbor field, and part of the load can be intelligently dispatched to these neighbor servers to balance the burden of the entire system and avoid service degradation or interruption caused by single-point overload. At the same time, in the event of a server failure or maintenance, the system can quickly identify the neighbors of the failed server, automatically migrate the channels and services on the failed server to the neighbor server, and achieve seamless switching to ensure that users will not be affected when watching live broadcasts. This mechanism enhances the robustness of the system and user experience, and is one of the key technologies to achieve stable and smooth HLS live broadcast services in a wireless environment.

[0051] In the technical solution provided in step S208, based on the uniform resource locator, when pulling the corresponding target slice live stream data from the slice server through the first-level node, it is first determined whether the program channel information in the playback request is the popular channel information, and a judgment result is obtained; when the judgment result indicates that the program channel information in the playback request is the popular channel information, the load information of other slice servers is obtained; when the load of the slice server that plays the popular channel information exceeds a first preset threshold, the slice tasks corresponding to the popular channel information are allocated to other slice servers based on the load information of other slice servers.

[0052] When pulling the corresponding target slice live stream, there are two situations:

[0053] Case 1: When the program channel information included in the playback request is popular channel information, obtain the channel ID of the popular channel playlist from the channel playlist; query the first uniform resource locator corresponding to the channel ID from the first-level node in the live broadcast system; based on the first uniform resource locator, pull the corresponding target slice live stream (i.e., the above-mentioned target slice live stream data) from the slice server through the first-level node.

[0054] Case 2: When the program channel information contained in the playback request is unpopular channel information, the playback request is reported to the first-level node; the second uniform resource locator corresponding to the playback request is queried from the first-level node in the live broadcast system; based on the second uniform resource locator, the corresponding target slice live stream (i.e., the above-mentioned target slice live stream data) is pulled from the slice server through the first-level node.

[0055] In the above steps, there are multiple ways to pull the corresponding target slice live stream data from the slice server through the first-level node according to the uniform resource locator, for example: pull the target slice live stream from the main slice server in the slice server through the first-level node; when the number of failures in pulling the target slice live stream through the main slice server reaches a second preset threshold, use the backup slice server in the slice server to pull the target slice live stream. When the target slice live stream is pulled successfully, the target slice live stream is stored in the CDN node memory.

[0056] The following is a specific embodiment:

[0057] When the program channel information is popular channel information: the secondary node receives the user request information, matches the m3u8 file ID of the channel on its own node (i.e. the above-mentioned channel ID), actively carries the ID identifier to the primary node to obtain the playback URL (i.e. the above-mentioned first uniform resource locator), and obtains the load information of other slice servers through the neighbor field; when the load of the slice server that plays the popular channel information exceeds the first preset threshold (for example, 80% of the total load), the slice tasks corresponding to the popular channel information are allocated to other slice servers according to the load information of other slice servers, and the target slice live stream is pulled from the main slice server in the slice server through the primary node; when the number of failures in pulling the target slice live stream through the main slice server reaches the second preset threshold (for example, 3 active stream pullings are performed in 10 seconds, and the CDN node tomcat component module performs stream pulling detection through http. When a stream pulling failure is detected, it automatically switches to the standby slice server in a remote computer room to pull the stream), the standby slice server in the slice server is used to pull the target slice live stream.

[0058] In the case where the program channel information is unpopular channel information: the secondary node detects that it has no channel and cannot detect the channel ID, and reports the request information carrying the program channel to the primary node to passively trigger the program channel to return to the source for playback (corresponding to the above-mentioned reporting of the playback request to the primary node; querying the second uniform resource locator corresponding to the playback request from the primary node in the live broadcast system, and according to the second uniform resource locator, pulling the corresponding target slice live stream from the slice server through the primary node. When the number of failures to pull the target slice live stream through the primary slice server reaches the second preset threshold (for example, 3 active stream pulls in 10 seconds all fail), the backup slice server in the slice server is used to pull the target slice live stream. At the same time, the primary node connected to the secondary node is configured with a master and a backup, and the primary primary node has a higher priority than the backup primary node. When an abnormality is detected in the primary primary node, it automatically switches to the backup primary node, and the user does not perceive the live broadcast. This processing method for unpopular channels can ensure that even low-traffic channels can get a timely response, meet the needs of different user groups, and is suitable for live broadcast services of long-tail content, such as niche cultural channels, educational live broadcast channels, etc., and can provide more comprehensive live content coverage.

[0059] In addition, on the end-user side, through adaptation with the live broadcast system side, adaptive switching is provided to supplement disaster recovery in scenarios where services are damaged, and smooth self-recovery of user services in multiple scenarios is achieved: the end-user side detects that the live broadcast HLS segment (i.e. the above-mentioned slice live stream) is missing or wrong, and spits out specific fault codes (such as 4XX, 5XX). Based on the AI ​​model, automatic warnings are issued, and multi-dimensional measurement and comparison are performed. Warnings are generated for four situations: sudden increase in quantity, increase in quantity at the same time, greater than the benchmark value, and greater than the predicted value. When the platform side (i.e. the above-mentioned live broadcast system) is turned on, it sends the full information such as the main and backup channel IP and ID to the terminal at the same time. The terminal player determines the error and initiates a request to the platform side server. The platform side splices the default backup scheduling URL to provide services to users. After the HLS segment is restored to stability, it automatically switches back to the HLS live unicast from the default URL. The default playback URL is based on the RTSP protocol. Early intervention based on business warnings can be used to implement problem handling and business scheduling, detect and solve problems before users report them, improve user perception, automatically warn of specific fault codes spit out by the terminal, connect to the production system to dispatch orders, and manually intervene to check network and server performance, indicators, etc., to detect and solve possible hidden dangers in advance without user business awareness.

[0060] HLS live broadcast is adopted in the embodiment of the present application, and there are three feasible solutions: router multicast transparent transmission, RTSP live broadcast, and HLS live broadcast. As shown in Table 1, verification and exploration are carried out from multiple dimensions such as the difficulty of first-line installation, convenience of business promotion, user perception, operation and maintenance pressure and complexity, and investment cost. Finally, it is confirmed that the HLS live broadcast method supports multi-encoding format slicing, has no special requirements for routers, has a low business threshold, is simple to install, and has excellent user perception.

[0061] Table 1

[0062]

[0063] Wireless live broadcast transcodes and slices the live multicast stream into unicast streams through a slicing server, supporting multiple video formats. The common official slicing time is 10 seconds. In theory, the longer the slicing time, the fewer times the slicing server needs to cut, the fewer files stored in the CDN node, and the lower the server performance requirements, but the client cache requirements are high, and the delay increases. Through deep learning algorithm testing and optimization, as shown in Table 2, for the same video file total length, server memory, and CPU configuration, the number of slices and slicing delay are calculated, and the optimal balance between server performance, playback delay, and network anti-interference ability is found. Finally, a single slicing of 6 seconds is confirmed, and the CDN server caches a timestamp (Timestamp, abbreviated as ts). The network anti-interference is 5%, and it can be played for about 40 seconds when the network is disconnected, which is the best user perception.

[0064] Table 2

[0065]

[0066] Through the above steps S202-S208, it is possible to centrally manage program channel information and uniform resource locators of live streams through the first-level node, improve the efficiency of live stream data pulling, and be suitable for large-scale network live broadcast scenarios, such as sports events, news live broadcasts, etc. It can quickly respond to user playback requests, improve user experience, and stably provide live broadcast services based on HLS. Through the disaster recovery of the HLS slice server and CDN streaming media server node system and the adaptive business switching disaster recovery, HLS live broadcast is guaranteed to be zero-interrupted, support wireless installation and ensure user perception, bring new vitality to traditional IPTV services, improve user live broadcast perception, lower the threshold for IPTV business installation, greatly promote IPTV business promotion, and realize normal playback of live broadcast services under wireless installation of IPTV services, ensure that users have the same excellent perception as under wired connections, and optimize and transform from the system level and business level. The slice server level realizes self-migration and self-creation of channels within the cluster through consistent hashing algorithm and heartbeat detection, and has intelligent scheduling for hot spot monitoring of all channels. When a user requests a live broadcast of a popular channel, the secondary node receives the user request information, matches the m3u8 file ID of the channel on its own node, and actively carries the ID to the primary node to obtain the playback URL, and directly pulls the live stream. The user service node has SLB health checks and load balancing, and the user service is unaware of single-node abnormalities. The fault code on the user terminal side automatically warns based on the AI ​​model to achieve adaptive switching and switching back when the service jitters and sharding errors occur, greatly improving user perception.

[0067] Users who do not have reserved wiring or TVs at home and use smart screens or projectors can all install traditional IPTV services wirelessly and watch live broadcasts based on HLS, which reduces the threshold for business promotion. The business side automatically warns and adaptively switches to achieve smooth recovery in the event of business damage. User perception requirements are getting higher and higher. Systems such as big video, short video, video surveillance, and cloud bottom layers all need to have user-unaware switching methods. The complete disaster recovery method can be applied to other systems such as management platforms, capability platforms, authentication platforms, video surveillance, and cloud platforms. It is highly promotable and can be used as a reference in multiple industries.

[0068] The present application also provides a system architecture diagram of a method for live broadcasting on the Internet. Figure 3 As shown in the figure, the end-to-end terminal (i.e., the user end to the live broadcast system end) describes in detail the entire live broadcast business process from the content source to the user end, as well as the interactive relationship between each key component. The following is a detailed description of the system architecture diagram:

[0069] The content source is the starting point of the live broadcast service, which provides the original multicast live broadcast stream. Multicast stream source-1 and multicast stream source-2 (as content sources) are connected to the active slice server cluster composed of multiple switches and slice servers through two active and standby dedicated line links (device-1 and device-2) to ensure the stable transmission of the live broadcast stream.

[0070] First-level disaster recovery: Slice servers are located in different locations and channels are automatically migrated in case of cluster content disasters. The slice server cluster consists of multiple slice servers, such as slice server 1, slice server 2, and slice server 3. They are responsible for receiving multicast streams from content sources, performing transcoding and slicing processing, and converting live streams into unicast streams that adapt to the HLS protocol. These servers have the functions of disaster recovery in different locations and cluster content disasters. When a single server fails, the channel automatically migrates to other servers in the cluster to ensure the continuity of the live broadcast service.

[0071] The (center) first-level node acts as a transit station for HLS live streaming. It creates live streaming of all channels and provides the URL address of the primary and backup slice servers. A stable communication connection is established between the first-level node and the second-level node. When a user requests a live channel (program channel), the first-level node is responsible for scheduling and distributing the corresponding HLS live stream. HLS streaming (primary and backup) serves as the second-level disaster recovery. The primary and backup center first-level nodes (i.e. the above-mentioned primary and backup first-level nodes) provide complete disaster recovery for HLS streaming.

[0072] The secondary node is a service node directly facing users. It obtains the live stream of the specified channel from the primary node according to the user's request (i.e. the play request sent by the target object mentioned above) (i.e. the uniform resource locator corresponding to the channel ID is queried from the primary node in the live broadcast system, and the corresponding target slice live stream data is pulled from the slice server through the primary node according to the uniform resource locator), and implements health checks and load balancing through SLB (Server Load Balancing) technology. When a request anomaly or a primary node failure is detected, the secondary node can seamlessly switch to the backup primary node to ensure uninterrupted user live broadcast services.

[0073] The above user terminals include traditional TVs, smart projectors, smart screens and other devices, which establish connections with secondary nodes through wireless networks and request to watch live broadcasts of specific channels. The user terminals have automatic fault code warning and business adaptive switching functions. When an abnormal live stream is detected, it can automatically switch to the backup URL to ensure that the live experience is not affected.

[0074] The entire system architecture has built a stable, efficient, and user-friendly disaster recovery system for live Internet TV services in a wireless environment, greatly improving the adaptability and competitiveness of IPTV in a wireless environment and providing users with a more convenient and smoother viewing experience.

[0075] The embodiment of the present application also provides a schematic diagram of a system-level automatic disaster recovery process of a network live broadcast method, such as Figure 4 As shown, the goal is to ensure that HLS live broadcast service can achieve seamless switching of services in a wireless environment when an abnormality occurs in the server or network, thereby ensuring the continuity and stability of the live broadcast service.

[0076] User terminals, such as smart screens, mobile phones, and tablets, initiate live channel requests to the secondary node through the wireless network; the secondary node (used to provide user services) processes the request: After receiving the user request, the secondary node first detects whether the service is normal. If not, it will automatically switch to other secondary nodes for processing. If normal, it will perform local processing based on the SLB according to the content of the request (such as the channel ID) and provide HLS live broadcast services to users normally. If the channel (i.e. the above-mentioned program channel) is a popular channel, the secondary node will directly search for the locally stored m3u8 file, carry the ID identifier to request the playback URL from the central primary node (i.e. the above-mentioned primary node), and pull the HLS unicast stream (i.e. the above-mentioned slice live stream). If the pulling of the HLS unicast stream is abnormal, it will automatically switch to the central primary backup node (i.e. the above-mentioned primary backup node) to pull the stream. If the pulling of the HLS unicast stream is normal, it will go to the central primary node to determine whether the slice transcoding stream of the pulled HLS unicast stream is normal. If the slice transcoding stream is abnormal, it will switch to the backup slice server cluster (i.e. the above-mentioned backup slice server cluster). If the slice transcoding stream is normal, the main slice server cluster will determine whether the transcoding in the slice machine cluster is normal. If it is normal, it will transcode the stream normally, store the slice live stream in the CDN node, perform hotspot detection on the playback data, and support intelligent scheduling. If it is abnormal, it will be detected through the consistent hashing algorithm and the channels (i.e. the above-mentioned program channels) will be redistributed in the slice server cluster.

[0077] From slice servers to CDN nodes, and then to user terminal request processing, the live broadcast service is ensured to maintain high reliability and good user experience in a wireless environment.

[0078] The embodiment of the present application also provides a schematic diagram of a service adaptive switching process of a network live broadcast method, such as Figure 5 As shown in the figure, it details how to ensure the continuity of live broadcast services and viewing experience through automatic warning and adaptive switching mechanisms when the user terminal encounters HLS fragment missing or errors. The following are the detailed steps of the process:

[0079] When a user requests to watch a live channel through an IPTV terminal in a wireless environment, the terminal will send a request to the secondary node. The secondary node actively obtains the corresponding HLS live stream playback URL from the primary node through the m3u8 file ID of the channel on its own node, and then pulls the live stream. When a fault occurs, first determine whether it is a blocking problem caused by the inability to pull the stream (i.e., the above-mentioned slice live stream). If so, the disaster recovery switch can be automatically completed, and the stream can be switched to the backup slice server to pull the stream. If it is not a blocking problem caused by the inability to pull the stream (i.e., the above-mentioned slice live stream), during the playback of the live stream, if the terminal detects that the HLS segment is missing or wrong, this may be caused by network fluctuations, server failures, etc. After detecting an error, the terminal will generate a specific fault code. The terminal will judge based on the HTTP response code. If a fault code of 4XX (client error) or 5XX (server error) is encountered, it indicates that the business is damaged. And determine whether to automatically warn based on the AI ​​model. If there is no automatic warning based on the AI ​​model, continue to use HLS to provide services. In the case of automatic warning based on the AI ​​model, once the AI ​​model detects a fault code and triggers a warning, the terminal player will adaptively switch to the backup scheduling URL to detect and determine whether the abnormal fault code continues to appear. If the abnormal fault code continues to appear, continue to use the default URL service and continue to warn (after receiving the warning information, a work order will be automatically dispatched, and the operation and maintenance personnel will intervene to check the network status, server performance indicators, etc., to troubleshoot and solve possible problems in advance, and ensure the high reliability of the live broadcast business and the continuity of the user experience). If the abnormal fault code does not continue to appear, it will automatically switch back to the HLS service (automatically switch from the RTSP backup URL back to the URL of the HLS live broadcast service. This process is smooth and imperceptible to the user).

[0080] The early warning mechanism will analyze from multiple dimensions, including the sudden increase in the number of fault codes, comparison with the same time yesterday, and whether it exceeds the baseline value or predicted value, in order to determine the severity of the error and the scope of impact.

[0081] The present application embodiment provides a schematic diagram of the structure of a network live broadcast device, such as Figure 6 As shown, it includes a receiving module 602 , a determining module 604 , a query module 606 , and a pulling module 608 .

[0082] The receiving module 602 is used to receive a play request sent by a target object, wherein the play request includes program channel information in an Internet protocol television (IPTV) service.

[0083] The determination module 604 is used to determine the channel ID corresponding to the program channel information in the IPTV service from the channel play list.

[0084] The query module 606 is used to query the uniform resource locator corresponding to the channel ID from the first-level node in the live broadcast system, wherein the first-level node is used to create and record the program channels in all network television IPTV services.

[0085] The pulling module 608 is used to pull the corresponding target slice live stream data from the slice server through the first-level node according to the uniform resource locator, wherein the slice server stores the slice live streams corresponding to the program channels in all network television IPTV services.

[0086] The pulling module 608 is also used to rebuild the slice live streams corresponding to all program channels in the abnormal slice server to other slice servers in the slice server cluster when an abnormality occurs in the slice server.

[0087] The pulling module 608 is also used to determine whether the program channel information in the playback request is popular channel information and obtain a judgment result; when the judgment result indicates that the program channel information in the playback request is popular channel information, obtain the load information of other slice servers; when the load of the slice server that plays the popular channel information exceeds a first preset threshold, the slice tasks corresponding to the popular channel information are allocated to other slice servers based on the load information of other slice servers.

[0088] The pulling module 608 is also used to obtain the channel ID of the popular channel play list from the channel play list when the program channel information contained in the playback request is popular channel information; query the first uniform resource locator corresponding to the channel ID from the first-level node in the live broadcast system; and pull the corresponding target slice live stream from the slice server through the first-level node based on the first uniform resource locator.

[0089] The pulling module 608 is also used to report the playback request to the first-level node when the program channel information contained in the playback request is unpopular channel information; query the second uniform resource locator corresponding to the playback request from the first-level node in the live broadcast system; and pull the corresponding target slice live stream from the slice server through the first-level node based on the second uniform resource locator.

[0090] The pulling module 608 is also used to pull the target slice live stream from the main slice server in the slice server through the first-level node; when the number of failures in pulling the target slice live stream through the main slice server reaches a second preset threshold, the backup slice server in the slice server is used to pull the target slice live stream.

[0091] It should be noted that the various modules in the above-mentioned live broadcast device can be program modules (for example, a set of program instructions that implement a certain specific function) or hardware modules. For the latter, it can be expressed in the following forms, but is not limited to this: the expression form of each of the above-mentioned modules is a processor, or the functions of each of the above-mentioned modules are implemented by a processor.

[0092] The embodiment of the present application also provides a non-volatile storage medium, the non-volatile storage medium includes a stored program, wherein when the program is running, the device where the non-volatile storage medium is located is controlled to execute the above network live broadcast method. For example, a play request sent by a target object is received, wherein the play request includes program channel information in the network television IPTV service; a channel ID corresponding to the program channel information in the network television IPTV service is determined from a channel play list; a uniform resource locator corresponding to the channel ID is queried from a first-level node in the live broadcast system, wherein the first-level node is used to create and record program channels in all network television IPTV services; based on the uniform resource locator, the corresponding target slice live stream data is pulled from a slice server through a first-level node, wherein the slice server stores slice live streams corresponding to program channels in all network television IPTV services.

[0093] The embodiment of the present application also provides an electronic device, the electronic device includes a processor, the processor is used to run a program, wherein the above network live broadcast method is executed when the program is running. For example, a play request sent by a target object is received, wherein the play request contains program channel information in the network television IPTV service; the channel ID corresponding to the program channel information in the network television IPTV service is determined from the channel play list; the uniform resource locator corresponding to the channel ID is queried from the first-level node in the live broadcast system, wherein the first-level node is used to create and record all program channels in the network television IPTV service; according to the uniform resource locator, the corresponding target slice live stream data is pulled from the slice server through the first-level node, wherein the slice server stores the slice live stream corresponding to the program channels in all network television IPTV services.

[0094] According to another aspect of the embodiment of the present application, a computer program product is also provided, including a computer program, which implements the above network live broadcast method when executed by a processor. For example, a play request sent by a target object is received, wherein the play request contains program channel information in the network television IPTV service; a channel ID corresponding to the program channel information in the network television IPTV service is determined from a channel play list; a uniform resource locator corresponding to the channel ID is queried from a first-level node in the live broadcast system, wherein the first-level node is used to create and record program channels in all network television IPTV services; based on the uniform resource locator, the corresponding target slice live stream data is pulled from a slice server through a first-level node, wherein the slice server stores slice live streams corresponding to program channels in all network television IPTV services.

[0095] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0096] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units can be a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0097] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.

[0098] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0099] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the relevant technology or all or part of the technical solution, can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, disk or optical disk, etc. Various media that can store program codes.

[0100] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A method for live broadcasting on a network, characterized in that: include: Receiving a play request sent by a target object, wherein the play request includes program channel information in an Internet television IPTV service; Determine a channel ID corresponding to the program channel information in the IPTV service from the channel play list; Querying a uniform resource locator corresponding to the channel ID from a primary node in a live broadcast system, wherein the primary node is used to create and record program channels in all network television IPTV services; According to the uniform resource locator, the corresponding target slice live stream data is pulled from the slice server through the first-level node, wherein the slice server stores the slice live streams corresponding to all program channels in the Internet television IPTV service.

2. The method according to claim 1, characterized in that: The slice server is deployed in a slice server cluster, and the method further includes: When an exception occurs in the slice server, the slice live streams corresponding to all program channels in the abnormal slice server are rebuilt to other slice servers in the slice server cluster.

3. The method according to claim 2, characterized in that The slice servers include active slice servers and backup slice servers. A preset number of active slice servers form an active slice server cluster, and a preset number of backup slice servers form a backup slice server cluster.

4. The method according to claim 1, characterized in that: The method further comprises: Determine whether the program channel information in the play request is popular channel information, and obtain a determination result; When the judgment result indicates that the program channel information in the play request is hot channel information, obtaining load information of other slice servers; When the load of the slice server playing the hot channel information exceeds a first preset threshold, the slice tasks corresponding to the hot channel information are allocated to other slice servers according to the load information of the other slice servers.

5. The method according to claim 1, characterized in that: Pulling the corresponding target slice live stream from the slice server through the primary node includes: When the program channel information included in the play request is hot channel information, obtaining a channel ID of the hot channel play list from the channel play list; Querying a first uniform resource locator corresponding to the channel ID from a primary node in the live broadcast system; According to the first uniform resource locator, the corresponding target slice live stream is pulled from the slice server through the first-level node.

6. The method according to claim 1, characterized in that Pulling the corresponding target slice live stream from the slice server through the primary node includes: When the program channel information included in the play request is information about a less popular channel, reporting the play request to the first-level node; Querying a second uniform resource locator corresponding to the play request from a primary node in the live broadcast system; According to the second uniform resource locator, the corresponding target slice live stream is pulled from the slice server through the first-level node.

7. The method according to claim 1, characterized in that The primary nodes include an active primary node and a backup primary node. The active primary node has a higher priority than the backup primary node. When an abnormality occurs in the active primary node, the node is switched to the backup primary node.

8. The method according to claim 1, characterized in that Pulling the corresponding target slice live stream from the slice server through the primary node includes: Pull the target slice live stream from the primary slice server among the slice servers through the primary node; When the number of failures in pulling the target slice live stream through the main slice server reaches a second preset threshold, a backup slice server among the slice servers is used to pull the target slice live stream.

9. A network live broadcast device, characterized in that: include: A receiving module, used for receiving a play request sent by a target object, wherein the play request includes program channel information in an Internet television IPTV service; A determination module, used to determine a channel ID corresponding to the program channel information in the network television IPTV service from a channel play list; A query module, used to query the uniform resource locator corresponding to the channel ID from the first-level node in the live broadcast system, wherein the first-level node is used to create and record program channels in all network television IPTV services; The pulling module is used to pull the corresponding target slice live stream data from the slice server through the first-level node according to the uniform resource locator, wherein the slice server stores the slice live streams corresponding to the program channels in all the network television IPTV services.

10. A non-volatile storage medium, characterized in that: The non-volatile storage medium stores a program, wherein when the program is running, the device where the non-volatile storage medium is located is controlled to execute the network live broadcast method described in any one of claims 1 to 8.

11. An electronic device, characterized in that: include: A memory and a processor, wherein the processor is used to run a program stored in the memory, wherein the program, when running, executes the method for network live broadcasting described in any one of claims 1 to 8.

12. A computer program product comprising computer instructions, characterized in that: When the computer instructions are executed by a processor, the method for network live broadcasting described in any one of claims 1 to 8 is implemented.

Images