Live broadcast stream management method and device, equipment, medium and program product

Abstract

The invention provides a live broadcast stream management method and device, equipment, a medium and a program product. A specific embodiment of the live broadcast stream management method in the application comprises the steps of receiving a live broadcast service attribute configuration request sent by a user, wherein the live broadcast service attribute configuration request comprises a live broadcast session identifier and a live broadcast service attribute tag; determining a live broadcast service function dimension to which the live broadcast service attribute tag belongs; dynamically configuring a live broadcast service attribute tag for a live broadcast stream in a live broadcast session corresponding to the live broadcast session identifier based on the live broadcast service function dimension; determining a node capability label corresponding to the live broadcast service attribute label; and sending the live broadcast stream configured with the live broadcast service attribute tag to the node configured with the node capability tag. According to the embodiment, the problems of disordered live broadcast service attribute management and function conflict in a traditional architecture are solved, and the stability and resource utilization efficiency of a live broadcast link are guaranteed through accurate node matching and dynamic scheduling.

Description

TECHNICAL FIELD

[0001] The present application relates to the live broadcast technology field, and particularly relates to a live broadcast stream management method, device, equipment, medium and program product. BACKGROUND

[0002] At present, a cloud live broadcast architecture has become a core infrastructure supporting efficient operation of various live broadcast services, and a core link and function division form a relatively mature operation mode: a host uses a professional stream pushing tool to push a live broadcast stream generated in real time to an edge computing uplink stream receiving node, the node serves as a core source station of the live broadcast stream and undertakes double key functions. On one hand, the live broadcast stream received is actively pushed to live broadcast recording, live broadcast screenshot, audio processing and other supporting services, so that the live broadcast content can be recorded and retained in real time, and the needs of business traceability, content compliance review and the like are met; on the other hand, the node opens a stream pulling authority to a CDN (Content Delivery Network) and a live broadcast transcoding function component, and allows the components to directly obtain the live broadcast stream from the source station, generates an adaptive version with different encoding formats and code rates through transcoding, and finally ensures that a user can efficiently pull the adaptive live broadcast stream from the CDN node through a terminal player, so that stability and high availability of the whole link are realized.

[0003] With continuous in-depth expansion of a live broadcast service scenario, functions implemented by relying on a live broadcast stream are increasingly rich and diverse, like live broadcast time shift, DRM (Digital Rights Management), paid live broadcast, 4K quality, HDR (High Dynamic Range) stream pushing, Dolby and the like. Implementation of these functions needs to be deeply bound with the live broadcast stream, and a frequency of function iteration is constantly accelerated, which makes expansion efficiency and long-term maintenance cost of the live broadcast stream function gradually become a key factor affecting competitiveness of the live broadcast service, and puts forward more stringent requirements for a management mode of the live broadcast stream function under an existing architecture. SUMMARY

[0004] Aspects of the present application provide a live broadcast stream management method, device, equipment, medium and program product to solve the problem of live broadcast service attribute management confusion and function conflict in a traditional architecture.

[0005] One aspect of this application provides a live stream management method, comprising: receiving a live stream service attribute configuration request sent by a user, the live stream service attribute configuration request including a live stream session identifier and a live stream service attribute tag; determining the live stream service function dimension to which the live stream service attribute tag belongs; dynamically configuring the live stream service attribute tag for the live stream in the live stream session corresponding to the live stream session identifier based on the live stream service function dimension; determining the node capability tag corresponding to the live stream service attribute tag; and sending the live stream with the configured live stream service attribute tag to the node with the configured node capability tag.

[0006] Another aspect of this application provides a live stream management device, comprising: a request receiving module configured to receive a live stream service attribute configuration request sent by a user, the live stream service attribute configuration request including a live stream session identifier and a live stream service attribute tag; a dimension determination module configured to determine the live stream service function dimension to which the live stream service attribute tag belongs; a tag configuration module configured to dynamically configure a live stream service attribute tag for the live stream in the live stream session corresponding to the live stream session identifier based on the live stream service function dimension; a tag determination module configured to determine the node capability tag corresponding to the live stream service attribute tag; and a live stream sending module configured to send the live stream configured with the live stream service attribute tag to the node configured with the node capability tag.

[0007] In another aspect of this application, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the live stream management method as described above.

[0008] In another aspect, this application provides a computer-readable storage medium having computer program instructions stored thereon, which can be executed by a processor to implement the live stream management method as described above.

[0009] Another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the live stream management method as described above.

[0010] The solution provided in this application embodiment realizes full lifecycle management of live stream business attribute tags from "configuration-activation-distribution-cleanup". It not only solves the problems of chaotic business attribute management and functional conflicts in the traditional architecture, but also ensures the stability of the live stream link and the efficiency of resource utilization through precise node matching and dynamic scheduling. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 A flowchart illustrating an embodiment of the live stream management method provided in this application; Figure 2 A flowchart illustrating another embodiment of the live stream management method provided in this application; Figure 3 A schematic diagram of the live stream node processing architecture; Figure 4 A schematic diagram of the structure of an embodiment of the live stream management device provided in this application; Figure 5 This is a schematic diagram of the structure of a device suitable for implementing the solutions in the embodiments of this application; The same or similar reference numerals in the accompanying drawings represent the same or similar parts. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0014] In a typical configuration of this application, the terminal and the service network devices each include one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0015] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0016] Computer-readable media include permanent and non-permanent, removable and non-removable media, which can store information by any method or technology. Information can be computer program instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, read-only optical disc (CD-ROM), digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information accessible by a computing device.

[0017] The solution provided in this application embodiment realizes full lifecycle management of live stream business attribute tags from "configuration-activation-distribution-cleanup". It not only solves the problems of chaotic business attribute management and functional conflicts in the traditional architecture, but also ensures the stability of the live stream link and the efficiency of resource utilization through precise node matching and dynamic scheduling.

[0018] In practical scenarios, the entity executing the above method can be a user device, a network device, or a device formed by integrating user devices and network devices through a network, or it can be an application running on the above devices. The user device includes, but is not limited to, various terminal devices such as computers, mobile phones, tablets, smartwatches, and wristbands. The network device includes, but is not limited to, network hosts, single network servers, multiple network server sets, or cloud computing-based computer sets. Here, the cloud consists of a large number of hosts or network servers based on cloud computing, where cloud computing is a type of distributed computing, consisting of a virtual computer composed of a group of loosely coupled computer sets.

[0019] Figure 1 A flowchart illustrating an embodiment of the live stream management method provided in this application is shown. The method includes at least the following processing steps: Step S101: Receive the live streaming service attribute configuration request sent by the user.

[0020] In this embodiment, the entity executing the live stream management method can receive a live stream service attribute configuration request sent by the user.

[0021] The cloud-based live streaming management system can receive live streaming service attribute configuration requests from users through communication interfaces with user terminals (such as the live streaming tool client used by broadcasters and the business management platform operated by operations personnel). These requests are triggered in various scenarios. They can be automatically generated when a broadcaster selects desired service functions (such as DRM encryption, 4K quality, HDR streaming, etc.) through the function selection interface of the live streaming tool when creating a new live stream session. Alternatively, they can be initiated by operations personnel manually configuring service attributes for a specific live stream session in the business management platform for a particular live event (such as a paid concert live stream).

[0022] The live streaming service attribute configuration request can include two types of core information: First, the live streaming session identifier, which can be a globally unique string or numeric code used to accurately locate a specific live streaming session. This identifier can be linked to basic data such as the host information, start time, and live streaming room identifier of the live streaming session. Second, the live streaming service attribute tags. Each live streaming service tag can correspond to a specific live streaming service function, defined using a standardized TAG format. For example, "DRM_ENCRYPT" represents DRM encryption function, "4K_VIDEO" represents 4K picture quality function, "HDR_STREAM" represents HDR streaming function, and "DOLBY_AUDIO" represents Dolby audio function, etc. Multiple non-conflicting tags can be carried simultaneously to meet complex business requirements.

[0023] Step S102: Determine the live streaming business function dimension to which the live streaming business attribute tag belongs.

[0024] In this embodiment, the aforementioned execution entity can determine the live streaming service function dimension to which the live streaming service attribute tag belongs.

[0025] Upon receiving a request for configuring live streaming service attributes, a pre-defined mapping rule library of "Live Streaming Service Attribute Tags - Live Streaming Service Function Dimensions" can be invoked to determine the dimension of each live streaming service attribute tag in the request. The live streaming service function dimensions can be divided into two categories: room dimension and stream dimension. This division can be determined based on the coverage and effectiveness rules of the service functions, as detailed below: Room Dimension: Applicable to live streaming business functions that require uniform application across all live streams within a live streaming room. For example, DRM encryption: if a paid live stream needs to ensure copyright security for all streams, it must be applied to the main stream, backup streams, and multi-camera streams within the live streaming room to prevent content leakage due to unencrypted streams. Another example is Dolby audio functionality, which requires ensuring all audio streams within the live streaming room use Dolby encoding to guarantee a consistent listening experience for viewers. This type of tag can be marked as "ROOM_LEVEL" in the mapping rule base, indicating that its scope applies to the entire live streaming room.

[0026] Stream Dimension: Applicable to business functions that only need to apply to specific live streams within a live streaming room. For example, the 4K quality function: some broadcasters may only want the main live stream to provide 4K resolution, while backup streams or low-bandwidth adaptation streams still use 1080P to save resources; another example is the special screenshot function: only specific streams containing key content need to be captured frequently, while other streams do not need to enable this function to reduce node load. This type of tag can be marked as STREAM_LEVEL in the mapping rule base, indicating that its scope of application is a specified single or multiple streams.

[0027] If the request contains tags of two different dimensions, the dimensions can be determined separately and the dimension attributes of each tag can be recorded to prepare for subsequent differentiated configuration.

[0028] Step S103: Based on the live streaming business function dimension, dynamically configure live streaming business attribute tags for the live stream in the corresponding live streaming session.

[0029] In this embodiment, the aforementioned execution entity can dynamically configure live streaming service attribute tags for the live stream in the live streaming session corresponding to the live streaming session identifier based on the live streaming service function dimension.

[0030] Based on the functional dimensions of live streaming services, differentiated configuration strategies can be adopted to dynamically bind business attribute tags to the live stream in each live session, ensuring the accuracy and flexibility of tag configuration.

[0031] In some embodiments, for scenarios where the live streaming service function is based on the room dimension, the live streaming room corresponding to the live streaming session can be determined based on the live streaming session identifier, and live streaming service attribute tags can be configured for all live streams within the live streaming room. The specific implementation can be as follows: The first step is to locate the live stream room: by querying the live stream room management database through the live stream room identifier, the corresponding live stream room identifier is obtained, and the stream list of the live stream room is further retrieved to determine all the live stream information that has been created or is to be created in the live stream room, including but not limited to stream identifier, stream type (mainstream, backup stream, multi-camera stream), and current status (not streaming, streaming in progress, paused).

[0032] The second step is batch tag configuration: For live streaming service attribute tags at the room level, the stream tag configuration interface can be called to write the live streaming service attribute tag into the metadata of all live streams within the live streaming room, and simultaneously update the stream attribute cache and distributed database. At the same time, a full-stream tag activation notification can be triggered, informing downstream components such as edge nodes, transcoding services, and CDN that all live streams within this live streaming room have enabled the live streaming service function and must be processed according to the corresponding rules. For example, after receiving the notification, the edge receiving node can automatically load the DRM encryption module for all inbound streams in this live streaming room; the transcoding service can ensure that all outbound streams carry DRM encryption information.

[0033] The third step is a dynamic update mechanism: If room dimension tags need to be added or deleted during the live broadcast, only one operation is needed to synchronously update the live broadcast business attribute tags of all live streams in the live broadcast room, without the need to configure them one by one, which greatly improves the efficiency of operation.

[0034] In some embodiments, for scenarios where the live streaming service function dimension is the stream dimension, the live room corresponding to the live session can be determined based on the live session identifier, and live streaming service attribute tags can be configured for specific live streams within the live room. For example, the live stream identifiers of all live streams within the live room are sent to the user; a live stream selection instruction sent by the user is received, which includes a specific live stream identifier selected by the user from all live stream identifiers; and live streaming service attribute tags are configured for the specific live stream based on the specific live stream identifier. A specific implementation can be as follows: The first step, live stream room location and stream list push: First, the live stream room is identified by the live stream session identifier, and the stream identifiers and basic information (such as stream name, resolution, and current status) of all live streams within that room are obtained to generate a stream selection list. Then, this stream selection list is pushed to the user through the user's terminal interface (such as the stream function configuration pop-up in the live streaming tool or the stream selection page in the business management platform), allowing the user to select the specific live stream for which live stream business attribute tags need to be configured.

[0035] The second step is user selection and instruction reception: The user selects a specific live stream on the terminal interface and submits the selection result. The user terminal can send a live stream selection instruction containing a specific live stream identifier to the execution entity. The live stream selection instruction can clearly indicate the stream identifier and the corresponding live stream service attribute label that need to be configured.

[0036] The third step is precise tag configuration: After receiving the live stream selection instruction, the stream tag configuration interface can be called to write live business attribute tags only to the stream metadata of the live stream corresponding to the specific live stream identifier in the live stream selection instruction, while other live streams remain unaffected. Simultaneously, the binding relationship between tags and streams can be recorded and stored in the stream tag association table for easy subsequent querying and management.

[0037] Furthermore, to enable dynamic configuration, it can support real-time adjustment of stream dimension tags during live streaming. For example, if a streamer wants to enable the 4K quality feature of the backup stream midway through the live stream, they can initiate a new live streaming service attribute configuration request through the live streaming tool. The aforementioned execution entity can immediately add the "4K_VIDEO" tag to the backup stream and trigger policy updates in downstream components to ensure that the configuration takes effect in real time.

[0038] Step S104: Determine the node capability tags corresponding to the live streaming service attribute tags.

[0039] In this embodiment, the aforementioned execution entity can determine the node capability tags corresponding to the live streaming service attribute tags.

[0040] To ensure that live streams configured with live streaming service attribute tags can be received and processed by nodes with corresponding processing capabilities, a one-to-one mapping relationship between "live streaming service attribute tags - node capability tags" can be established. The specific implementation can be as follows: The first step is to build a mapping rule base: Maintain a global mapping rule base of "live streaming service attribute tags - node capability tags". This mapping rule base can be formulated based on the technical requirements of live streaming service functions and the hardware / software configuration of nodes. For example, for the live streaming service attribute tag "DRM_ENCRYPT", the node needs to support DRM encryption modules and key management service integration capabilities, so the corresponding node capability tag is "NODE_CAP_DRM" (DRM encryption); for the live streaming service attribute tag "4K_VIDEO" (4K quality), the node needs to have 4K decoding / encoding chips and high bandwidth processing capabilities, so the corresponding node capability tag is "NODE_CAP_4K".

[0041] The second step is tag mapping and matching: For each configured live streaming service attribute tag, the "Live Streaming Service Attribute Tag - Node Capability Tag" mapping rule library can be queried to obtain the corresponding node capability tag. If a live streaming stream is configured with multiple live streaming service attribute tags, it can match multiple node capability tags, meaning that the live streaming stream can be scheduled to a node that has both of these capabilities.

[0042] The third step is capability tag verification: To avoid capability mismatches caused by outdated mapping rules (such as adding new capabilities after node hardware upgrades without updating the rules), the real-time capability information of nodes in the node capability database can be synchronized periodically, and the mapping rule library of "Live Streaming Business Attribute Tags - Node Capability Tags" can be verified and updated. For example, if a new node supports AV1 encoding, a corresponding "NODE_CAP_AV1" capability tag mapping can be added to the mapping rule library for the "AV1_VIDEO" business tag.

[0043] For the mapping rule bases of "Live Streaming Business Attribute Tags - Live Streaming Business Function Dimensions" and "Live Streaming Business Attribute Tags - Node Capability Tags", in order to clarify their storage format and data association logic, the core data structure can be designed using JSON format. For example, {"DRM_ENCRYPT":{"dimension":"ROOM_LEVEL","node_capability":"NODE_CAP_DRM"}} means that the live streaming business attribute tag "DRM_ENCRYPT" belongs to the live streaming business function dimension "ROOM_LEVEL" and the corresponding node capability tag is "NODE_CAP_DRM".

[0044] Step S105: Send the live stream with the configured live streaming service attribute tags to the node with the configured node capability tags.

[0045] In this embodiment, the aforementioned execution entity can send the live stream configured with live streaming service attribute tags to the node configured with node capability tags.

[0046] After matching the live streaming service attribute tags with the node capability tags, the scheduling system can accurately distribute the live streaming streams with configured live streaming service attribute tags to nodes with corresponding capabilities, ensuring the correctness and efficiency of live streaming processing. Simultaneously, to achieve dynamic resource optimization and fault redundancy, the following safeguards can be established: Node filtering and priority ranking: The scheduling system first queries the node management database to filter all nodes configured with target capability tags, and then prioritizes the nodes based on indicators such as the current load rate, geographical distance from the broadcaster's location, and node health status. For example, nodes with a load rate below 60%, geographical distance from the broadcaster within 500 kilometers, and no faults in the past hour are given priority to ensure streaming stability and low latency.

[0047] To ensure the feasibility of node priority ranking logic, a weighted scoring ranking algorithm can be provided. Through quantitative index calculation and standardization, this algorithm ensures that the scheduling system can accurately select the optimal node. Specifically, it can be as follows: The scheduling system can use a node comprehensive scoring function to determine the priority of candidate nodes. Nodes with higher scores are selected first. The core formula is: Score = ×Norm(1-Load)+ ×Norm(1 / Latency)+ ×Norm(Health_Status).

[0048] Where Load is the current load rate of the node (the average of CPU utilization and bandwidth utilization, with a value of [0,1]); Latency is the network latency between the node and the streamer's push position (in ms, with a value of [10,500]); Health_Status is the health status of the node (1 represents no faults in the past hour, 0 represents the existence of fault records). , , Weighting factors (satisfying) + + =1); Norm(·) is a normalization function used to eliminate dimensional differences. For Norm(1-Load), 1-Load represents the load idle degree, which is in the range [0,1] and can be directly taken as a value; for Norm(1 / Latency), linear normalization is used, and the formula is (1 / Latency-1 / 500) / (1 / 10-1 / 500); for Norm(Health_Status), it is a binary indicator, which does not need to be converted and can be directly taken as 1 or 0. This is used as the weight for load idleness, and is usually set to the highest value to ensure resource sufficiency. =0.4; As a delay weight, it is usually chosen as the next highest value to avoid audio-visual desynchronization, such as =0.35; The weight for health status is usually set slightly lower, because the absence of faults in the past hour has already covered stable scenarios, such as... =0.25.

[0049] Stream distribution and link establishment: The scheduling system can send a stream reception command to the highest priority node. The stream reception command can include information such as the live stream identifier, live service attribute tag, and transmission protocol. After confirming that its capabilities match and resources are sufficient, the node can return a receive-ready response. The aforementioned execution entity then notifies the broadcaster terminal or streaming tool to push the live stream to that node, completing the establishment of the stream distribution link.

[0050] Failover mechanism: If a node fails during live stream transmission, the scheduling system can monitor the node status in real time. Once an anomaly is detected, it immediately selects the second-best node from the backup node list, re-establishes the stream transmission link, and notifies downstream components to update the stream source address to ensure uninterrupted live streaming.

[0051] In some embodiments, after a live session ends, the business attribute tags of all live stream configurations within the live session can be cleared.

[0052] To avoid invalid tags consuming system resources and to prevent confusion in subsequent live stream configurations, a tag cleanup process can be triggered after each live stream session ends. The first step is tag association query: by the live session identifier, query the stream tag association table to obtain the stream identifier and corresponding tag information of all configured live service attribute tags under that live session.

[0053] The second step is batch tag deletion: For room-level tags, the live business attribute tags of all live streams within the live room can be deleted directly; for stream-level tags, only the live business attribute tags of a specific live stream can be deleted. Simultaneously, the tag cache related to that live stream session is cleared from the stream attribute cache library to prevent cached data residue.

[0054] The fourth step is to clean up the log records: After the tags are cleaned up, you can record the cleanup logs, including but not limited to the live broadcast session identifier, cleanup time, cleaned stream identifier, and list of deleted tags, which will facilitate subsequent problem tracing and auditing.

[0055] In some embodiments, after a live stream with configured live streaming service attribute tags is sent to a node with configured node capability tags, the scheduling result containing the node capability tags can be sent to the user. The scheduling system can automatically generate a scheduling result notification after completing the matching and distribution of the live stream to the node. This notification may include the live session identifier, live stream identifier, matched node capability tags, basic node information, and scheduling status. The scheduling result notification can be pushed through the user terminal's interactive interface or synchronized to a user-specified message receiving address via an API (Application Programming Interface). For example, after a broadcaster configures the "DRM_ENCRYPT" tag, the system can push feedback to them that the live stream has been scheduled to a node with the [NODE_CAP_DRM] capability, allowing the user to monitor the stream's distribution status in real time. If a node failure subsequently occurs, this feedback can be used to quickly locate the problematic node.

[0056] In some embodiments, the metadata of a live stream configured with live stream service attribute tags can carry a specific identifier corresponding to the live stream service attribute tag. This specific identifier can be a standardized code that corresponds one-to-one with the live stream service attribute tag; for example, the tag “DRM_ENCRYPT” corresponds to the specific identifier “DRM_000001”, and the tag “4K_VIDEO” corresponds to the specific identifier “4K_000001”. When dynamically configuring tags for a live stream, the live stream management system can synchronously write this specific identifier into the metadata field of the live stream. In this way, downstream components can quickly identify the service attributes of the live stream by parsing the specific identifier in the metadata, improving processing efficiency. For example, when a CDN node receives a live stream carrying the identifier “DRM_000001”, it can directly determine that the live stream needs to enable DRM decryption adaptation logic without calling system interfaces to query tag information, reducing cross-service interaction time and ensuring the real-time nature of stream distribution.

[0057] The solution provided in this application implements full lifecycle management of live stream service attribute tags from "configuration-activation-distribution-cleanup". This not only solves the problems of chaotic management and functional conflicts in live stream service attributes in traditional architectures, but also ensures the stability and resource utilization efficiency of the live stream link through precise node matching and dynamic scheduling. With this solution, when new functions (such as HDR streaming) are launched, there is no need to modify the core link code; only the addition of tags and node configurations is required, shortening the development and deployment cycle from an average of 2 weeks to 2 days.

[0058] Figure 2 A flowchart illustrating another embodiment of the live stream management method provided in this application is shown. The method includes at least the following processing steps: Step S201: Receive the live streaming service attribute configuration request sent by the user.

[0059] Step S202: Determine the live streaming business function dimension to which the live streaming business attribute tag belongs.

[0060] Step S203: Based on the live streaming business function dimension, dynamically configure live streaming business attribute tags for the live stream in the corresponding live streaming session.

[0061] Step S204: Determine the node capability tags corresponding to the live streaming service attribute tags.

[0062] In this embodiment, the specific operations of steps S201-S204 have been described. Figure 1 The steps S101-S104 in the illustrated embodiment are described in detail and will not be repeated here.

[0063] Step S205: Identify the type of live streaming service attribute tag through the proxy node, and send the live stream with configured live streaming service attribute tag to the node with configured node capability tag in a manner corresponding to the type of live streaming service attribute tag.

[0064] In this embodiment, the aforementioned execution entity can identify the type of live streaming service attribute tag through the proxy node, and send the live stream configured with the live streaming service attribute tag to the node configured with the node capability tag in a manner corresponding to the type of the live streaming service attribute tag.

[0065] To address the issues of high latency and poor stability in cross-regional streaming for broadcasters in traditional centralized data center models, multiple PROXY nodes can be deployed nationwide. These PROXY nodes are connected to the central data center via dedicated lines or intranets, providing low-latency transmission and tag recognition capabilities. Based on the type of live streaming service attribute tags (regular tags / special tags), PROXY nodes can employ differentiated transmission strategies, as detailed below: The first step is tag type classification: In the live streaming business attribute tag management library, live streaming business attribute tags are pre-classified into regular business attribute tags and special business attribute tags. The classification can be based on the resource requirements, node deployment density, and security requirements of the business function: Regular business attribute tags correspond to basic functions with low resource requirements and high node deployment density. The nodes for such functions are deployed in all provinces and cities across the country, which can be scheduled locally without relying on a central data center. Special business attribute tags can correspond to advanced functions with high resource requirements, low node deployment density, or high security requirements. These functions require high-performance nodes in a central ultra-large data center, which regular nodes do not have the processing capabilities for.

[0066] The second step, for scenarios where the live streaming service attribute tag is a regular service attribute tag, can be achieved by directly sending the live stream with the configured live streaming service attribute tag to a node with the configured node capability tag adjacent to the proxy node via a proxy node. The specific implementation is as follows: When a PROXY node receives a live stream pushed by a broadcaster, it first extracts the live stream's business attribute tags through the stream metadata parsing module. If the tags are determined to be regular business attribute tags, the following process is executed: First, local node query: PROXY nodes can call the local node capability query interface to query a list of all regular nodes within their coverage area that are configured with the corresponding node capability tags.

[0067] Next, optimal node selection: PROXY nodes can be selected based on indicators such as real-time load of regular nodes, geographical distance from the broadcaster, and node response speed. For example, PROXY nodes can prioritize nodes with a load rate of 50%, a distance of 20 kilometers from the broadcaster, and a ping value of <10ms.

[0068] Then, direct streaming: PROXY nodes can directly establish streaming links with optimal regular nodes, pushing the live stream to those nodes without going through a central server room. This process involves short transmission distances and stable links, reducing streaming latency and effectively ensuring the quality of the streamer's feed and the viewing experience for the audience.

[0069] Finally, link monitoring and dynamic adjustment: PROXY nodes can monitor the streaming status in real time. If the load of the current regular node increases or a minor fault occurs, it will immediately switch to the backup regular node to ensure that the streaming is uninterrupted.

[0070] Thirdly, for scenarios where the live streaming service attribute tag is a special service attribute tag, the live stream configured with the live streaming service attribute tag can be sent to the node in the central data center that is configured with the node capability tag through a dedicated line between the proxy node and the central data center. The specific implementation is as follows: When the PROXY node parses a flow's business attribute tag as a special business attribute tag, since regular nodes do not have the corresponding processing capabilities, it can be processed by a special node in the central data center. The specific process is as follows: First, the central data center node query: PROXY nodes can connect to the node scheduling center in the central data center via a dedicated line and send a special node query request containing live streaming service attribute tags. The scheduling center can then query the list of special nodes in the central data center and filter out special nodes that are configured with the corresponding capability tags and have sufficient resources.

[0071] Next, a dedicated line is established: PROXY nodes and target special nodes can establish a connection through a pre-set dedicated line to ensure stable transmission of high-bitrate, high-security streams. PROXY nodes can transmit live streams via dedicated lines, avoiding latency and security risks caused by cross-public network transmission.

[0072] Next, stream transmission and capability verification: PROXY nodes can push the live stream to special nodes. The special nodes first verify the matching between the live stream's business attribute tags and their own capability tags. If the verification passes, subsequent processing such as stream reception, transcoding, and encryption is performed. If the verification fails, feedback is immediately sent to the PROXY node. The scheduling center can then reassign other special nodes to ensure the correctness of stream processing.

[0073] Finally, multi-center disaster recovery backup: If all special nodes in one central data center fail, the dispatch center can reroute the live stream to special nodes in other backup central data centers. PROXY nodes can automatically switch dedicated lines to backup central data centers to achieve cross-center disaster recovery and ensure the continuity of special business functions.

[0074] The solution provided in this application, through label identification and differentiated transmission strategies for PROXY nodes, achieves both local scheduling of regular services, reducing streaming latency and node load, and ensures stable transmission and secure processing of special service streams through dedicated line connections. This solves the problems of poor streaming quality in remote areas and insufficient coverage of special nodes in traditional architectures, further improving the stability and business adaptability of the live streaming link. With this solution, for broadcasters in remote areas, the average streaming latency is reduced by 30% through local access via PROXY nodes.

[0075] Figure 3 A schematic diagram of the live stream node processing architecture is shown. This architecture revolves around the core logic of "matching live stream business attribute tags with node capability tags," integrating PROXY nodes, regular nodes, special business nodes, and related functional modules to form a complete live stream processing system. The functions and interaction relationships of each component are as follows: PROXY nodes can be independent proxy nodes that receive live streams from broadcasters or other sources, undertaking edge access, initial processing, and forwarding tasks. PROXY nodes can also serve as entry points for live streams into the central data center, directing different types of live streams to different nodes within the central data center based on business needs.

[0076] The central data center can include regular nodes, special business A / B / C nodes, recording modules, and screenshot modules. It is the core area for live stream processing, performing various business processes on the live stream, covering regular business, special business, and auxiliary functions such as recording and screenshotting. The central data center can centrally deploy core processing resources and achieve end-to-end management of the live stream from reception and processing to distribution through the collaboration between internal nodes.

[0077] Regular nodes can be the basic processing nodes within the central data center. They handle the routine business processing of the live stream and can distribute the processed live stream to different special business nodes; they also trigger recording and screenshot operations. Regular nodes can serve as the basic hub within the central data center, connecting the live stream input, special business nodes, and recording and screenshot function modules, playing a role in stream distribution and triggering auxiliary operations.

[0078] Specialized service nodes can include Specialized Service A node, Specialized Service B node, and Specialized Service C node, each corresponding to different specialized service processing needs. Specialized service nodes can receive live streams distributed by regular nodes and perform targeted specialized service processing to meet diverse live streaming service scenarios.

[0079] The recording module can be an independent recording function module that records the entire live stream for later playback, on-demand viewing, and other operations. The recording module can be triggered by regular nodes and is an important part of the regular live stream processing workflow for saving live content.

[0080] The screenshot module can be an independent function module that generates screenshots of the live stream according to rules or triggering conditions during the live stream, for use in scenarios such as live stream preview and content sharing. The screenshot module can be triggered by regular nodes and is an important step in the regular processing flow of the live stream, generating live-related screenshot resources.

[0081] Taking a live stream with special business functions as an example, the interaction flow of the live stream node processing architecture can be as follows: The first step is live stream access: The live stream from the broadcaster is first received by the PROXY node. After the PROXY node performs preliminary processing on the live stream, it forwards it to the regular nodes in the central data center.

[0082] The second step is routine business processing and distribution: the routine nodes perform routine business processing on the live stream. Then, on the one hand, the recording module is triggered to record the live content, and the screenshot module is triggered to generate screenshots of the live stream. On the other hand, according to the business needs of the live stream, the processed live stream is distributed to the corresponding special business nodes (for example, if special business node A is responsible for high-definition encoding, the live stream will be distributed to that node when there is a need for high-definition encoding).

[0083] The third step is special business processing: Special business nodes A / B / C receive the live stream distributed by regular nodes and perform targeted special business processing (such as special business node A performing high-definition encoding processing, special business node B performing DRM encryption processing, special business node C implementing multi-view synthesis processing, etc.) to realize different live streaming business scenarios.

[0084] The advantages of a live stream node processing architecture are as follows: Refined business processing: By dividing the work and cooperating between regular nodes and special business nodes, it not only meets the regular business needs of live streaming, but also accurately realizes various special business processing, covering diverse live streaming scenarios.

[0085] Functional completeness: It integrates auxiliary function modules such as recording and screenshotting, providing support for the subsequent use of live streaming content and improving the live streaming business ecosystem.

[0086] Process coherence: From the PROXY node to the live stream access, to the regular nodes for processing and distribution, and then to the special business nodes for dedicated processing, a coherent live stream processing process is formed to ensure the smooth operation of the live streaming business.

[0087] Figure 4 A schematic diagram of a structure of an embodiment of the live stream management device provided in this application is shown. This device embodiment is similar to... Figure 1 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0088] like Figure 4As shown, the live stream management device 400 of this embodiment may include: a request receiving module 401, a dimension determination module 402, a tag configuration module 403, a tag determination module 404, and a live stream sending module 405. The request receiving module 401 is configured to receive a live stream service attribute configuration request sent by a user, the request including a live stream session identifier and a live stream service attribute tag; the dimension determination module 402 is configured to determine the live stream service function dimension to which the live stream service attribute tag belongs; the tag configuration module 403 is configured to dynamically configure live stream service attribute tags for the live stream in the live stream session corresponding to the live stream session identifier based on the live stream service function dimension; the tag determination module 404 is configured to determine the node capability tag corresponding to the live stream service attribute tag; and the live stream sending module 405 is configured to send the live stream with the configured live stream service attribute tag to the node with the configured node capability tag.

[0089] In this embodiment, the specific processing of the request receiving module 401, dimension determination module 402, tag configuration module 403, tag determination module 404, and live stream sending module 405 in the live stream management device 400, and the resulting technical effects, can be found in the following references: Figure 1 The relevant descriptions of steps S101-S105 in the corresponding embodiments will not be repeated here.

[0090] In some optional implementations of this embodiment, the live streaming service function dimension includes the room dimension; and the tag configuration module 403 is further configured to: determine the live room corresponding to the live streaming session based on the live streaming session identifier; and configure live streaming service attribute tags for all live streams in the live streaming room.

[0091] In some optional implementations of this embodiment, the live streaming service function dimension includes the stream dimension; and the tag configuration module 403 is further configured to: determine the live room corresponding to the live streaming session based on the live streaming session identifier; and configure live streaming service attribute tags for specific live streaming streams within the live streaming room.

[0092] In some optional implementations of this embodiment, the tag configuration module 403 is further configured to: receive a live stream selection instruction sent by a user, the live stream selection instruction including a specific live stream identifier; and configure live stream service attribute tags for a specific live stream based on the specific live stream identifier.

[0093] In some optional implementations of this embodiment, the tag configuration module 403 is further configured to send the live stream identifiers of all live streams in the live room to the user, wherein the specific live stream identifier is selected by the user from the live stream identifiers of all live streams.

[0094] In some optional implementations of this embodiment, the live stream sending module 405 is further configured to: identify the type of live stream service attribute tag through the proxy node, and send the live stream with configured live stream service attribute tag to the node with configured node capability tag in a manner corresponding to the type of live stream service attribute tag.

[0095] In some optional implementations of this embodiment, the live stream sending module 405 is further configured to: in response to determining that the live stream service attribute tag is a regular service attribute tag, send the live stream with the configured live stream service attribute tag directly to the node with the configured node capability tag that is adjacent to the proxy node through the proxy node.

[0096] In some optional implementations of this embodiment, the live stream sending module 405 is further configured to: in response to determining that the live stream service attribute tag is a special service attribute tag, send the live stream with the configured live stream service attribute tag to the node with the configured node capability tag in the central computer room through the dedicated line between the proxy node and the central computer room.

[0097] In some optional implementations of this embodiment, the live stream management device 400 further includes a tag cleaning module, configured to clean up all business attribute tags configured in the live streams within the live stream session after the live stream session ends.

[0098] In some optional implementations of this embodiment, the live stream management device 400 further includes a result sending module, configured to send the scheduling result containing the node capability tag to the user.

[0099] In some optional implementations of this embodiment, the metadata of the live stream configured with live streaming service attribute tags carries a specific identifier corresponding to the live streaming service attribute tags.

[0100] Based on the same inventive concept, this application also provides an electronic device. The method corresponding to the electronic device can be the live stream management method in the foregoing embodiments, and its problem-solving principle is similar to that method. The electronic device provided in this application includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the methods and / or technical solutions of the foregoing embodiments of this application.

[0101] The electronic device can be a user device, or a device formed by integrating user devices and network devices through a network, or it can be an application running on the aforementioned devices. The user device includes, but is not limited to, various terminal devices such as computers, mobile phones, tablets, smartwatches, and wristbands. The network device includes, but is not limited to, network hosts, single network servers, multiple network server sets, or cloud computing-based computer sets, and can be used to implement some processing functions when setting an alarm clock. Here, the cloud consists of a large number of hosts or network servers based on cloud computing. Cloud computing is a type of distributed computing, consisting of a virtual computer composed of a group of loosely coupled computer sets.

[0102] Figure 5 The diagram illustrates the structure of an apparatus suitable for implementing the methods and / or technical solutions in the embodiments of this application. The apparatus 500 includes a Central Processing Unit (CPU) 501, which can perform various appropriate actions and processes based on a program stored in a Read Only Memory (ROM) 502 or a program loaded from a storage portion 508 into a Random Access Memory (RAM) 503. The RAM 503 also stores various programs and data required for system operation. The CPU 501, ROM 502, and RAM 503 are interconnected via a bus 504. An Input / Output (I / O) interface 505 is also connected to the bus 504.

[0103] The following components are connected to I / O interface 505: an input section 506 including a keyboard, mouse, touchscreen, microphone, infrared sensor, etc.; an output section 507 including a cathode ray tube (CRT), liquid crystal display (LCD), LED display, OLED display, etc., and speakers, etc.; a storage section 508 including one or more computer-readable media such as hard disk, optical disk, magnetic disk, semiconductor memory, etc.; and a communication section 509 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 509 performs communication processing via a network such as the Internet.

[0104] In particular, the methods and / or embodiments in this application can be implemented as computer software programs. For example, the embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by the central processing unit (CPU) 501, it performs the functions defined in the methods of this application.

[0105] Another embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of this application described above.

[0106] Specifically, this embodiment may employ any combination of one or more computer-readable media. A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium may be, for example—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device.

[0107] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including—but not limited to—electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0108] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including—but not limited to—wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0109] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0110] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0111] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0112] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or page components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between devices or units through some interfaces, and may be electrical, mechanical, or other forms.

[0113] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0114] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in a combination of hardware and software functional units.

[0115] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0116] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

[0117] Furthermore, it is clear that the word "comprising" does not exclude other units or steps, and the singular does not exclude the plural. Multiple units or devices recited in a device claim may also be implemented by a single unit or device through software or hardware. The terms "first," "second," etc., are used to indicate names and do not indicate any specific order.

Claims

1. A live stream management method, comprising: Receive a live streaming service attribute configuration request sent by a user, wherein the live streaming service attribute configuration request includes a live streaming session identifier and a live streaming service attribute tag; Determine the live streaming service function dimension to which the live streaming service attribute tags belong; Based on the live streaming service function dimension, the live streaming service attribute tags are dynamically configured for the live stream in the live streaming session corresponding to the live streaming session identifier. Determine the node capability tags corresponding to the live streaming service attribute tags; The live stream configured with the live streaming service attribute tags will be sent to the node configured with the node capability tags.

2. The method according to claim 1, wherein, The live streaming service functionality includes the room dimension; and The step of dynamically configuring the live streaming service attribute tags for the live stream in the live streaming session corresponding to the live streaming session identifier based on the live streaming service function dimension includes: Based on the live broadcast session identifier, the live broadcast room corresponding to the live broadcast session is determined; Configure the live streaming service attribute tags for all live streams within the live streaming room.

3. The method according to claim 1, wherein, The live streaming service functionality dimensions include the stream dimension; and The step of dynamically configuring the live streaming service attribute tags for the live stream in the live streaming session corresponding to the live streaming session identifier based on the live streaming service function dimension includes: Based on the live broadcast session identifier, the live broadcast room corresponding to the live broadcast session is determined; Configure the live streaming service attribute tags for specific live streams within the live streaming room.

4. The method according to claim 3, wherein, The step of configuring the live streaming service attribute tags for a specific live stream within the live streaming room includes: Receive the live stream selection instruction sent by the user, wherein the live stream selection instruction includes a specific live stream identifier; Based on the specific live stream identifier, configure the live stream service attribute tag for the specific live stream.

5. The method according to claim 4, wherein configuring the live streaming service attribute tag for a specific live stream within the live streaming room further includes: The live stream identifiers of all live streams in the live room are sent to the user, and the specific live stream identifier is selected by the user from the live stream identifiers of all live streams.

6. The method according to any one of claims 1-5, wherein, Sending the live stream configured with the live streaming service attribute tags to the node configured with the node capability tags includes: The agent node identifies the type of the live streaming service attribute tag and sends the live stream configured with the live streaming service attribute tag to the node configured with the node capability tag in a manner corresponding to the type of the live streaming service attribute tag.

7. The method according to claim 6, wherein, The step of sending the live stream configured with the live stream service attribute tag to the node configured with the node capability tag in a manner corresponding to the type of the live stream service attribute tag includes: In response to determining that the live streaming service attribute tag is a regular service attribute tag, the live streaming stream configured with the live streaming service attribute tag is directly sent through the proxy node to a node configured with the node capability tag that is adjacent to the proxy node.

8. The method according to claim 6, wherein, The step of sending the live stream configured with the live stream service attribute tag to the node configured with the node capability tag in a manner corresponding to the type of the live stream service attribute tag includes: In response to determining that the live streaming service attribute tag is a special service attribute tag, the live streaming stream configured with the live streaming service attribute tag is sent to the node configured with the node capability tag in the central data center via a dedicated line between the proxy node and the central data center.

9. The method according to any one of claims 1-8, wherein, The method further includes: After the live broadcast session ends, clear all business attribute tags configured in the live broadcast streams within the live broadcast session.

10. The method according to any one of claims 1-9, wherein, The method further includes: The scheduling result containing the node capability tag is sent to the user.

11. The method according to any one of claims 1-10, wherein, The metadata of the live stream configured with the live stream service attribute tags carries a specific identifier corresponding to the live stream service attribute tags.

12. A live stream management device, comprising: The request receiving module is configured to receive a live streaming service attribute configuration request sent by a user. The live streaming service attribute configuration request includes a live streaming session identifier and a live streaming service attribute tag. The dimension determination module is configured to determine the live streaming service function dimension to which the live streaming service attribute tag belongs; The tag configuration module is configured to dynamically configure the live streaming service attribute tags for the live streaming stream in the live streaming session corresponding to the live streaming session identifier based on the live streaming service function dimension. The tag determination module is configured to determine the node capability tags corresponding to the live streaming service attribute tags; The live stream sending module is configured to send the live stream configured with the live service attribute tags to the node configured with the node capability tags.

13. An electronic device, the electronic device comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-11.

14. A computer-readable medium having stored thereon computer program instructions that can be executed by a processor to implement the method as described in any one of claims 1-11.

15. A computer program product comprising a computer program that, when executed by a processor, implements the method as described in any one of claims 1-11.

Images