Dynamic flow identification processing method, apparatus, device, storage medium, and program product

Abstract

Embodiments of the present application provide a dynamic flow identifier processing method and device, computer equipment, computer readable storage medium and computer program product, and belong to the technical field of network live broadcast. The method comprises: obtaining special live broadcast scene information corresponding to a target live broadcast room and corresponding service attribute information; generating a target dynamic flow identifier based on the special live broadcast scene information; establishing an association between the target dynamic flow identifier and the service attribute information; configuring life cycle state information for the target dynamic flow identifier; and generating and outputting target dynamic flow identifier management information. In this way, the target dynamic flow identifier is associated with the special live broadcast scene, the service attribute and the life cycle state, which is conducive to improving the consistency of the identifier, the attribute and the state information in the subsequent processing link.

Description

Technical Field

[0001] This application relates to the field of live streaming media processing technology, and in particular to a dynamic stream identifier processing method, apparatus, computer device, computer-readable storage medium, and computer program product. Background Technology

[0002] In live streaming scenarios, the pushing end typically pushes the live stream to edge nodes via a pushing address, while the playback end retrieves the corresponding live content via a pulling address. Both the pushing and pulling addresses usually include a stream identifier to identify the source and ownership of the live stream. With the increasing prevalence of special live streaming scenarios such as encrypted live streaming, resource-permission live streaming, exclusive-permission live streaming, and internal enterprise live streaming, the stream identifier, in addition to distinguishing different live streams, may also need to be used in conjunction with information such as the live streaming scenario, processing attributes, permission status, and timeliness. In relevant live stream management methods, the stream identifier is usually bound to the live streaming room, and business attributes can be managed through additional tags or external permission information. In special live streaming scenarios, if edge nodes cannot promptly detect changes in the stream identifier's status, or if the live stream processing logic is inconsistent across different scenarios, it may affect the coordinated processing of identifiers, attributes, and status information in the live stream processing chain.

[0003] It should be noted that the above content is not necessarily prior art, nor is it intended to limit the scope of patent protection of this application. Summary of the Invention

[0004] This application provides a dynamic stream identifier processing method, apparatus, computer device, computer-readable storage medium, and computer program product to solve or alleviate one or more of the above-mentioned technical problems.

[0005] One aspect of this application provides a dynamic stream identifier processing method, applied to a live stream management system, the method comprising: Obtain the special live streaming scene information corresponding to the target live streaming room and the business attribute information corresponding to the special live streaming scene information; Based on the specific live streaming scenario information, a target dynamic stream identifier is generated; Establish the association between the target dynamic flow identifier and the business attribute information; Configure lifecycle status information for the target dynamic stream identifier; Generate and output target dynamic flow identifier management information, which includes the target dynamic flow identifier, the association relationship, and the lifecycle status information.

[0006] Optionally, based on the specific live streaming scenario information, a target dynamic stream identifier is generated, including: Determine the scene identification information corresponding to the special live streaming scene information; Obtain the live room identifier information and stream identifier generation time information of the target live room; Generate random identification information; Based on the scene identifier information, the live room identifier information, the stream identifier generation time information, and the random identifier information, a stream identifier to be verified is generated; Generate verification information based on the stream identifier to be verified; The verification information is combined with the stream identifier to be verified to obtain the target dynamic stream identifier.

[0007] Optionally, establishing the association between the target dynamic flow identifier and the business attribute information includes: Lightweight attribute information and full attribute information are determined from the aforementioned business attribute information; Configure the lightweight attribute information to be obtainable from the target dynamic stream identifier; Establish a mapping relationship between the target dynamic stream identifier and the full set of attribute information; Generate mapping verification information based on the target dynamic flow identifier and the full attribute information; The mapping verification information is associated with the mapping relationship and stored. The mapping verification information is used to verify the consistency between the target dynamic stream identifier and the full attribute information.

[0008] Optionally, lifecycle state information is configured for the target dynamic flow identifier, including: Obtain the lifecycle rules corresponding to the specific live streaming scenario information; Based on the lifecycle rules, the validity period information and failure triggering conditions of the target dynamic flow identifier are determined; Based on the validity period information and the failure triggering conditions, the lifecycle status information is generated; The failure triggering conditions include at least one of the following: the target dynamic stream identifier exceeds its corresponding validity period, the live stream corresponding to the target live stream room ends, the live stream scene of the target live stream room is switched, and the attribute status corresponding to the business attribute information changes.

[0009] Optionally, the method further includes: When the target live streaming room is detected to have switched from the first live streaming scene to the second live streaming scene, a new dynamic stream identifier corresponding to the second live streaming scene is generated. Establish the association between the new dynamic stream identifier and the business attribute information corresponding to the second live streaming scenario; Update the lifecycle status information of the target dynamic flow identifier to an invalid state; Output the failure status information of the new dynamic flow identifier and the target dynamic flow identifier.

[0010] Optionally, the method further includes: Receive scene configuration data, wherein the scene configuration data includes at least one of scene identifier configuration data, stream identifier structure configuration data, attribute field configuration data, authentication rule configuration data, and lifecycle rule configuration data; Based on the scenario configuration data, generate scenario flow identifier management rules; Based on the aforementioned scene stream identifier management rules, dynamic stream identifier generation, attribute association, and lifecycle state configuration are performed for the corresponding special live streaming scenarios.

[0011] Optionally, the method further includes: When the lifecycle status information of the target dynamic flow identifier represents a failure status, the target dynamic flow identifier is added to the failure flow identifier queue. Based on the failure time information, the dynamic flow identifiers in the failure flow identifier queue are sorted; Based on the preset cleanup batch and data storage load status, the dynamic flow identifiers to be cleaned are determined from the failed flow identifier queue; Perform cleanup processing or backup-after cleanup processing on the dynamic stream identifier to be cleaned.

[0012] Optionally, output target dynamic flow identifier management information, including: The target dynamic stream identifier and the lifecycle status information are output to the live streaming scheduling system so that the live streaming scheduling system can generate a push stream address containing the target dynamic stream identifier; The push address includes edge node address information, port information, the target dynamic stream identifier, authentication information, and stream identifier validity information.

[0013] Optionally, output target dynamic flow identifier management information, including: Write the current active data corresponding to the target dynamic stream identifier into the first data storage unit; Write the full data corresponding to the target dynamic stream identifier into the second data storage unit; Write the log data corresponding to the target dynamic stream identifier into the third data storage unit; Write the mapping verification information corresponding to the target dynamic flow identifier and the business attribute information into the fourth data storage unit.

[0014] Optionally, the special live streaming scenario information includes at least one of the following: encrypted live streaming scenario information, resource permission live streaming scenario information, exclusive permission live streaming scenario information, enterprise internal live streaming scenario information, temporary authorization live streaming scenario information, and multi-resolution live streaming scenario information.

[0015] Another aspect of this application provides a dynamic flow identifier processing method applied to edge nodes, the method comprising: Receive live stream processing events carrying the target dynamic stream identifier; Parse the target dynamic flow identifier to obtain the scene identifier information corresponding to the target dynamic flow identifier; Obtain the status information and service attribute information corresponding to the target dynamic flow identifier; Based on the scene identification information, the status information, and the business attribute information, the live stream processing event is authenticated using stream identification. Based on the authentication result of the stream identifier authentication, the live stream processing event is processed as an access process, a distribution process, a termination process, or an alarm process.

[0016] Optionally, after parsing the target dynamic flow identifier to obtain the scene identifier information corresponding to the target dynamic flow identifier, the method further includes: Based on the scene identification information, the live stream processing event corresponding to the live stream scene type is determined; Based on the live streaming scenario type, determine the processing channel corresponding to the live streaming processing event; The live stream processing events are assigned to the processing channel.

[0017] Optionally, obtaining the status information and service attribute information corresponding to the target dynamic flow identifier includes: Query the local stream identifier status cache of the edge node; If available cached data corresponding to the target dynamic stream identifier exists in the local stream identifier status cache, the status information and / or the service attribute information are determined based on the available cached data. If the available cached data is not found in the local stream identifier status cache, a data query request is sent to the central computer room data system; Receive the query results returned by the central computer room data system, and determine the status information and / or the business attribute information based on the query results.

[0018] Optionally, based on the scene identification information, the status information, and the business attribute information, stream identification authentication is performed on the live stream processing event, including: Based on the event type and processing stage of the live stream processing event, determine the target authentication stage corresponding to the target dynamic stream identifier; Based on the target authentication stage, the authentication data required for the flow identifier authentication is determined; Based on the authentication data, staged authentication is performed on the live stream processing event; The target authentication stage includes at least one of the following: pre-pull authentication stage, in-pull authentication stage, pre-pull authentication stage, in-pull authentication stage, and in-transmission authentication stage.

[0019] Optionally, based on the scene identification information, the status information, and the business attribute information, stream identification authentication is performed on the live stream processing event, including: Determine whether the target dynamic stream identifier belongs to the blacklist stream identifier; If the target dynamic stream identifier belongs to the blacklist stream identifier, the live stream processing event is rejected and an abnormal request alarm message is generated; If the target dynamic stream identifier does not belong to the blacklist stream identifier, the stream identifier authentication continues to be performed based on the scenario identifier information, the status information, and the business attribute information.

[0020] Optionally, based on the scene identification information, the status information, and the business attribute information, stream identification authentication is performed on the live stream processing event, including: When the live stream processing event is a push stream access event, the push stream address authentication information and timeliness information carried by the push stream access event are obtained, and the push stream access event is authenticated before push stream based on the target dynamic stream identifier, the push stream address authentication information and the timeliness information. When the live stream processing event is a push stream transmission event, the push stream terminal identification information corresponding to the push stream transmission event is obtained, and the push stream transmission event is authenticated during the push stream based on the binding relationship between the push stream terminal identification information and the target dynamic stream identifier.

[0021] Optionally, based on the scene identification information, the status information, and the business attribute information, stream identification authentication is performed on the live stream processing event, including: When the live stream processing event is a pull stream access event, the viewing terminal identification information corresponding to the pull stream access event is obtained, the permission verification method corresponding to the scene identification information is determined, and the pull stream access event is authenticated before pull stream based on the viewing terminal identification information, the permission verification method and the business attribute information. When the live stream processing event is a pull stream transmission event, the timeliness authentication of the pull stream process corresponding to the pull stream transmission event is performed based on the status information.

[0022] Optionally, when the live stream processing event is an attribute verification event, stream identifier authentication is performed on the live stream processing event based on the scene identification information, the status information, and the business attribute information, including: Obtain the first attribute verification information corresponding to the target dynamic flow identifier. The first attribute verification information is generated based on the business attribute information obtained by local parsing or caching of the edge node. The second attribute verification information corresponding to the target dynamic flow identifier is obtained from the central computer room data system. The second attribute verification information is generated based on the business attribute information stored in the central computer room data system. Perform a consistency check on the first attribute verification information and the second attribute verification information; If the consistency check fails, the live stream transmission corresponding to the target dynamic stream identifier is terminated and an attribute anomaly alarm message is generated.

[0023] Optionally, based on the authentication result of the stream identifier authentication, the live stream processing event is subjected to access processing, distribution processing, termination processing, or alarm processing, including: If the authentication result indicates that the authentication is successful, a live stream processing strategy is determined based on the business attribute information; Based on the live stream processing strategy, at least one of the following processes is performed on the live stream corresponding to the live stream processing event: access, transcoding, encryption, bitrate control, or distribution. If the authentication result indicates that the authentication has failed, the live stream processing event is terminated, and an alarm message corresponding to the reason for the authentication failure is generated.

[0024] Optionally, obtaining the status information and service attribute information corresponding to the target dynamic flow identifier includes: Establish a status synchronization connection with the central computer room data system; The state change information is obtained through the state synchronization connection. The state change information includes at least one of the following: flow identifier failure status, attribute change information, and blacklisted flow identifier list. Based on the state change information, update the local stream identifier state cache; In the event of a detected interruption of the state synchronization connection, the live stream processing event is processed based on the local stream identifier state cache. When the state synchronization connection is restored, the full state information is obtained from the central computer room data system, and the local stream identifier state cache is updated based on the full state information.

[0025] Another aspect of this application provides a dynamic stream identifier processing device, applied to a live stream management system, the device comprising: The acquisition module is used to acquire special live streaming scene information corresponding to the target live streaming room and business attribute information corresponding to the special live streaming scene information; The generation module is used to generate a target dynamic stream identifier based on the specific live streaming scenario information; The association module is used to establish the association relationship between the target dynamic flow identifier and the business attribute information; The configuration module is used to configure lifecycle status information for the target dynamic flow identifier; The output module is used to generate and output target dynamic flow identifier management information, which includes the target dynamic flow identifier, the association relationship, and the lifecycle status information.

[0026] Another aspect of this application provides a dynamic stream identifier processing apparatus applied to an edge node, the apparatus comprising: The receiving module is used to receive live stream processing events carrying the target dynamic stream identifier; The parsing module is used to parse the target dynamic flow identifier to obtain the scene identifier information corresponding to the target dynamic flow identifier; The acquisition module is used to acquire the status information and business attribute information corresponding to the target dynamic flow identifier; The authentication module is used to perform stream identifier authentication on the live stream processing event based on the scene identification information, the status information, and the business attribute information; The processing module is used to perform access processing, distribution processing, termination processing, or alarm processing on the live stream processing event based on the authentication result of the stream identifier authentication.

[0027] Another aspect of this application provides a computer device, including: At least one processor; and A memory that is communicatively connected to the at least one processor; Wherein: the memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to execute any of the above dynamic stream identifier processing methods.

[0028] Another aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements any of the above-described dynamic stream identifier processing methods.

[0029] Another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements any of the above-described dynamic stream identifier processing methods.

[0030] The embodiments of this application employing the above-described technical solution may have the following advantages: By acquiring specific live streaming scenario information and business attribute information, a target dynamic stream identifier is generated based on the specific live streaming scenario information, and a correlation is established between the target dynamic stream identifier and the business attribute information, enabling the live stream identifier to be associated with the corresponding specific live streaming scenario and business attribute. By configuring lifecycle state information for the target dynamic stream identifier and outputting target dynamic stream identifier management information, the live streaming scheduling, edge processing, or data storage stages can perform subsequent processing based on the target dynamic stream identifier, the correlation, and the lifecycle state information. This reduces the risk of processing inconsistencies caused by the disconnect between the live stream identifier and the specific live streaming scenario, business attribute, and valid state, and improves the stability of live stream management in special live streaming scenarios. Attached Figure Description

[0031] The accompanying drawings exemplify embodiments and form part of the specification, serving together with the textual description to explain exemplary implementations of the embodiments. The illustrated embodiments are for illustrative purposes only and do not limit the scope of the claims. Throughout the drawings, the same reference numerals refer to similar but not necessarily identical elements.

[0032] Figure 1 The diagram illustrates the operating environment of the dynamic stream identifier processing method according to Embodiment 1 of this application. Figure 2 A flowchart illustrating the dynamic stream identifier processing method according to Embodiment 1 of this application is shown schematically. Figure 3 Schematic illustration Figure 2 Flowchart of the sub-steps in step S202; Figure 4 Schematic illustration Figure 2 Flowchart of the sub-steps in step S204; Figure 5 Schematic illustration Figure 2 Flowchart of the sub-steps in step S206; Figure 6 This schematically illustrates a flowchart of scene switching and expansion processing according to Embodiment 1 of this application; Figure 7 A flowchart illustrating the dynamic stream identifier processing method according to Embodiment 2 of this application is shown schematically. Figure 8 Schematic illustration Figure 7Flowchart of the sub-steps in step S706; Figure 9 The diagram illustrates an application example of the dynamic stream identifier processing method according to Embodiment 1 of this application. Figure 10 A block diagram of a dynamic stream identifier processing apparatus according to Embodiment 3 of this application is shown schematically; Figure 11 A block diagram of a dynamic stream identifier processing apparatus according to Embodiment 4 of this application is schematically shown; and Figure 12 A schematic diagram of the hardware architecture of a computer device according to Embodiment 5 of this application is shown. Detailed Implementation

[0033] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0034] It should be noted that the descriptions involving "first," "second," etc., in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of that feature. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0035] In the description of this application, it should be understood that the numerical labels before the steps do not indicate the order of the steps, but are only used to facilitate the description of this application and to distinguish each step, and therefore should not be construed as a limitation of this application.

[0036] First, a definition of the terminology used in this application is provided: A dynamic stream identifier can be identification information used to identify the source, origin, scene, or status of a live stream. In some embodiments, a dynamic stream identifier can be represented as a stream name, a portion of a field in the stream name, an identifier field associated with the stream name, or identifier data used to generate push stream addresses, pull stream addresses, and edge node processing logic.

[0037] Special live streaming scenario information can be used to characterize live streaming scenarios that have specific business attributes or processing requirements compared to regular live streaming scenarios. For example, special live streaming scenario information may include at least one of the following: encrypted live streaming scenario information, resource-permission live streaming scenario information, exclusive-permission live streaming scenario information, internal enterprise live streaming scenario information, temporarily authorized live streaming scenario information, and multi-resolution live streaming scenario information. The above scenario types are merely examples and do not constitute a limitation on the scope of special live streaming scenario information.

[0038] Business attribute information can be used to characterize the processing attributes, permission attributes, timeliness attributes, clarity attributes, encryption attributes, or other data that can be used for live stream processing in specific live streaming scenarios. All business attribute information can be stored in the central data center system, or a portion of lightweight attribute information suitable for rapid parsing by edge nodes can be configured to be parsed from the dynamic stream identifier.

[0039] Lifecycle status information can be used to characterize the valid, invalid, pending, or cleared status of a dynamic stream identifier, or other information related to the lifespan and status changes of the dynamic stream identifier. This lifecycle status information can be output along with the dynamic stream identifier to the live streaming scheduling system, the central data center system, or edge nodes, enabling these systems to process the data based on the current status of the dynamic stream identifier.

[0040] It should be noted that when processing data such as streaming client identification information, viewing client identification information, business attribute information, permission verification data, order status data, permission status data, and authorization list data, this application may be conducted with legal authorization or in compliance with platform data processing rules. Related data may be anonymized, encrypted, subject to access control, minimized, or logged in accordance with business compliance requirements to reduce unnecessary data exposure.

[0041] Secondly, to facilitate understanding of the technical solutions provided in the embodiments of this application by those skilled in the art, the relevant technologies are described below: In current mainstream cloud live streaming platforms, after a broadcaster creates a live stream room, the platform allocates corresponding edge nodes based on the broadcaster's network status, regional location, and other information, and generates a push stream address containing a fixed stream name and basic authentication parameters. After the live stream content is processed by the edge nodes, viewers watch it through the corresponding pull stream address.

[0042] As live streaming services extend to specialized scenarios such as resource-permission live streaming, exclusive-permission live streaming, encrypted live streaming, and temporary-authorization live streaming, mainstream cloud live streaming platforms have optimized for these specific scenarios. For example, they have enhanced access control capabilities by adding password verification, order verification, and dynamic authentication codes, or improved the efficiency of encrypted stream processing through dedicated transcoding channels. However, existing solutions still largely follow the core stream management model of "fixed stream name + tagged attributes," that is, distinguishing between special scenarios by adding business tags or dynamic parameters to a fixed stream name.

[0043] However, the technical solutions for managing live streaming scenarios that the inventors are aware of have the following drawbacks: First, the fixed stream name mechanism poses a fundamental risk to content security. Encryption and access control are primarily based at the live stream level. While stream names may have dynamic suffixes or encrypted parameters, their core identifiers remain permanently bound to the live stream, lacking a connection to scene attributes or authorization expiration. If an attacker obtains the core fields of the stream name, they can still construct valid stream requests through concatenation, speculation, or decryption, bypassing existing room-level authentication restrictions. Furthermore, due to the lack of complete lifecycle control for stream names, even after the live stream ends or authorization expires, the stream name may remain valid for a long time, easily leading to security issues such as leakage of historical live stream content, unauthorized broadcasting of content with access permissions, and leakage of sensitive information.

[0044] Second, the tag-based attribute management model is prone to causing chaos in stream management. Using a "fixed stream name + attribute tag" approach to describe live streaming service characteristics, with different service attributes (such as encryption, resource permissions, etc.) all bound to the same stream identifier, easily leads to tag priority conflicts, abnormal attribute overriding, and overly tight configuration coupling. Attribute modifications need to be synchronized to the central data center, edge nodes, and playback terminals, posing a high risk of synchronization delays and potentially causing streaming failures, incorrect permission identification, or playback anomalies. Furthermore, the existing stream name and service attribute mapping lack an effective anti-tampering mechanism, allowing third parties to bypass authentication logic by illegally modifying attribute mapping relationships, thus causing security failures.

[0045] Third, there is a lack of flexible adaptability to complex business scenarios. Because the stream name generation logic is essentially still strongly bound to the live streaming room and weakly correlated with specific business scenarios, switching between scenarios such as regular live streaming, encrypted live streaming, and temporary authorized live streaming requires frequent adjustments to the stream name attribute configuration, which is complex and prone to configuration errors. Furthermore, the fixed stream name has limited tag capabilities, making it difficult to support multi-dimensional and personalized business needs, such as complex scenarios like specified user authorization, dynamic time period restrictions, or multi-level permission combinations. When the platform adds special live streaming types, the existing stream management system, edge node logic, and authentication chain need to be adjusted simultaneously, resulting in long development cycles, high system coupling, and a lack of unified and reusable scenario configuration capabilities.

[0046] Fourth, the authentication process lacks end-to-end dynamic security control. The authentication logic is mainly concentrated at the push and pull stream entry points, and the live stream lacks a continuous validity verification mechanism during transmission, transcoding, and distribution. Edge nodes perform static authentication parameter comparisons without establishing real-time stream status synchronization with the central system. When the live stream scenario changes, the live stream ends, or permissions expire, edge nodes cannot detect changes in stream status in a timely manner and may continue to process corresponding stream requests, leading to problems such as the continued propagation of invalid streams, content leakage, or playback anomalies.

[0047] Fifth, existing stream names lack automated lifecycle and resource recycling mechanisms. Stream names are retained in the system database long after generation. Even if the corresponding live streaming service has ended and the authorization relationship has expired, the relevant stream names still require manual or periodic cleanup, easily resulting in a large number of invalid stream resources occupying database and cache space for extended periods, reducing system query and management efficiency. The continued existence of a large number of historical invalid stream names also increases the possibility for attackers to perform pattern analysis, concatenation speculation, and brute-force attacks on valid stream names, further enhancing the overall system security risk.

[0048] To address this, this application provides a dynamic stream identifier processing technical solution. This solution integrates a live stream management system encompassing dynamic stream name generation, attribute binding, timeliness control, automatic expiration, and intelligent cleanup, achieving automated and secure management of live streams from generation to destruction. By employing a structured dynamic stream name generation rule of "scene encoding + live room ID + timestamp + random string + verification code," a unique binding is established between the stream name and the live stream scene, and tamper-proofing is achieved through the verification code. Secure binding and rapid parsing of business attributes are achieved through a combination of embedded attribute encoding in the stream name and encrypted mapping in the central data center. A multi-stage authentication mechanism covering the entire process of pushing, transmitting, and pulling streams is constructed, combined with a visual rule configuration engine, enabling rapid expansion and reuse for special live stream scenarios. A real-time status synchronization mechanism is established between edge nodes and the central data center, allowing edge nodes to perceive changes in stream name status in real time and promptly terminate expired stream processing, thereby improving security, flexibility, and resource management efficiency in special live stream scenarios. Details are provided below.

[0049] Finally, for ease of understanding, an exemplary operating environment is provided below.

[0050] like Figure 1As shown in the diagram, the operating environment includes: a live stream management system 2, a live stream scheduling system 4, edge nodes 6, a central data center system 8, a streaming tool 10, and a playback terminal 12. The live stream management system 2 can generate dynamic stream identifiers, establish the association between dynamic stream identifiers and business attribute information, and configure lifecycle status information. The live stream scheduling system 4 can generate streaming addresses based on target dynamic stream identifiers and lifecycle status information. The edge nodes 6 can receive streaming requests, pull requests, or processing events during live stream transmission, parse target dynamic stream identifiers, and perform authentication, access, distribution, termination, or alarm processing based on the status information and business attribute information corresponding to the target dynamic stream identifiers. The central data center system 8 can store the current active data, full data, log data, and mapping verification information corresponding to the dynamic stream identifiers, and provide status synchronization information or authentication data to the edge nodes 6. The streaming tool 10 can send scene selection, parameter configuration, or scene switching requests to the live stream scheduling system 4 and push the live stream to the edge nodes 6 based on the streaming address. The playback terminal 12 can send a pull request to the edge node 6 and receive the live stream or processing result returned by the edge node 6 based on the stream identifier authentication result.

[0051] The live stream management system 2, live stream scheduling system 4, and central computer room data system 8 can be implemented by a single server, server cluster, cloud computing service center, distributed computing node, or virtualized computing instance, respectively. Edge node 6 can be an edge server, edge server cluster, or content distribution node deployed close to the network side of the streaming or playback end. Streaming tool 10 and playback end 12 can run on smartphones, tablets, personal computers, live streaming devices, smart TVs, set-top boxes, or other terminal devices with network communication capabilities. It should be noted that the above-mentioned number of devices, deployment locations, and communication methods are exemplary and can be adjusted according to network scale, live stream service type, and system deployment method in different implementation scenarios.

[0052] In some embodiments, the central data center system 8 may include a cache storage unit, a persistent storage unit, a log storage unit, and a verification storage unit. The cache storage unit can be used to store data related to currently active dynamic stream identifiers; the persistent storage unit can be used to store the full data of dynamic stream identifiers; the log storage unit can be used to store operation logs and authentication logs related to dynamic stream identifiers; and the verification storage unit can be used to store mapping verification information or state change verification information. Through the collaboration of these multiple storage units, the edge node 6, the live streaming scheduling system 4, and the live streaming management system 2 can access different types of data based on different processing needs.

[0053] Example 1 Figure 2A flowchart illustrating a dynamic stream identifier processing method according to Embodiment 1 of this application is shown schematically. This embodiment can be applied to a live stream management system. Figure 2 As shown, the dynamic stream identifier processing method may include steps S200 to S208, wherein: Step S200: Obtain the special live streaming scene information corresponding to the target live streaming room and the business attribute information corresponding to the special live streaming scene information.

[0054] Step S202: Generate a target dynamic stream identifier based on the specific live streaming scenario information.

[0055] Step S204: Establish the association between the target dynamic flow identifier and the business attribute information.

[0056] Step S206: Configure lifecycle status information for the target dynamic flow identifier.

[0057] Step S208: Generate and output target dynamic flow identifier management information, which includes the target dynamic flow identifier, the association relationship, and the lifecycle status information.

[0058] In this embodiment, the live stream management system first acquires the specific live stream scenario information and business attribute information of the target live stream room, and then generates a target dynamic stream identifier based on the specific live stream scenario information, establishing an identifier-level association between the target dynamic stream identifier and the corresponding live stream scenario. Subsequently, the live stream management system can establish the association between the target dynamic stream identifier and the business attribute information, and configure lifecycle status information, so that the target dynamic stream identifier can not only represent the source or origin of the live stream, but also be associated with business attributes and valid status. By outputting the target dynamic stream identifier management information, the subsequent live stream scheduling system, edge nodes, or central data center system can perform push address generation, status storage, stream identifier authentication, or live stream processing based on the unified identifier management information. Through the above steps, the live stream identifier under special live stream scenarios can be transformed from a fixed identifier or single tag management method to a dynamic management method associated with scenarios, business attributes, and lifecycle status. This reduces the risk of processing inconsistencies caused by weak associations between live stream identifiers and special live stream scenarios, and provides a data foundation for subsequent edge nodes to perform authentication and status control based on dynamic stream identifiers.

[0059] The following combination Figure 2 The steps S200 to S208 and other related steps are further described.

[0060] Step S200: Obtain the special live streaming scene information corresponding to the target live streaming room and the business attribute information corresponding to the special live streaming scene information.

[0061] Specifically, the target live stream room can be the live stream room that currently needs to generate a push address, switch live stream scenarios, or update the stream identifier status. Special live stream scenario information can come from the push streaming tool, live stream scheduling system, live stream service configuration system, or central data center system. For example, the push streaming client or tool can submit scenario selection information before initiating a push stream; the live stream scheduling system can forward the scenario selection information to the live stream management system; the live stream management system can also query the special live stream scenario information currently corresponding to the target live stream room based on pre-configured scenario rules.

[0062] Business attribute information may include processing attributes corresponding to specific live streaming scenarios. For example, business attribute information for encrypted live streaming scenarios may include encryption status, encryption level, or encryption processing flags; business attribute information for resource permission live streaming scenarios may include resource permission status, permission verification method, or order association flags; business attribute information for exclusive permission live streaming scenarios may include member permission flags; business attribute information for temporary authorization live streaming scenarios may include the scope of authorized objects or authorization validity period information; and business attribute information for multi-resolution live streaming scenarios may include resolution levels, bitrate control strategies, or transcoding processing flags. All of the above business attribute information can be configured, stored, and retrieved according to the platform's data processing rules.

[0063] In some embodiments, specific live streaming scenario information and business attribute information can be obtained through the same scenario configuration request or separately from different data sources. For example, specific live streaming scenario information can come from a scenario selection request submitted by the streaming tool, while business attribute information can come from the attribute configuration associated with that scenario in the central data center's data system. By obtaining and associating scenario information and business attribute information separately, the live streaming management system can obtain complete scenario and attribute inputs before generating the target dynamic stream identifier.

[0064] Step S202: Generate a target dynamic stream identifier based on the specific live streaming scenario information.

[0065] Specifically, the live stream management system can determine the identifier generation rules corresponding to a specific live stream scenario based on that scenario information, and generate a target dynamic stream identifier according to the identifier generation rules. The target dynamic stream identifier may include scenario identifier information used to characterize the specific live stream scenario, and may further include other identifier fields used to distinguish the live stream room, generation time, or randomness.

[0066] In some embodiments, the target dynamic stream identifier can be obtained by combining multiple fields. Different fields can be used to characterize the live streaming scene, live streaming room, generation time, randomness, and integrity verification, respectively. Through this combination method, the target dynamic stream identifier can simultaneously meet the needs of scene association, live stream differentiation, and verification processing.

[0067] In optional embodiments, such as Figure 3 As shown, for step S202, generating a target dynamic stream identifier based on the specific live streaming scenario information may include steps S300 to S310, wherein: Step S300: Determine the scene identifier information corresponding to the special live streaming scene information.

[0068] Step S302: Obtain the live room identifier information and stream identifier generation time information of the target live room.

[0069] Step S304: Generate random identification information.

[0070] Step S306: Generate a stream identifier to be verified based on the scene identifier information, the live room identifier information, the stream identifier generation time information, and the random identifier information.

[0071] Step S308: Generate verification information based on the stream identifier to be verified.

[0072] Step S310: Combine the verification information with the stream identifier to be verified to obtain the target dynamic stream identifier.

[0073] In this embodiment, scene identification information can be used to represent the specific live streaming scene corresponding to the target dynamic stream identifier. For example, scene identification information can be an encoding corresponding to an encrypted live streaming scene, a resource permission live streaming scene, a dedicated permission live streaming scene, a temporary authorization live streaming scene, or other special live streaming scenes. Live room identification information can be used to represent the target live streaming room. Stream identifier generation time information can be used to represent the generation time of the target dynamic stream identifier. Random identifier information can be used to reduce the probability of the same live streaming room generating the same dynamic stream identifier within a similar time period. Verification information can be used to perform integrity verification or consistency verification on the stream identifier to be verified.

[0074] In some embodiments, the live stream management system can first read the scene code from the scene configuration data based on specific live stream scene information, then read the live stream identifier information and current generation time information of the target live stream room, and generate a random string. The live stream management system can combine the above information according to preset combination rules to form a stream identifier to be verified, then generate verification information based on the stream identifier to be verified, and append the verification information to the stream identifier to be verified to obtain the target dynamic stream identifier.

[0075] In other embodiments, scene identifier information, live room identifier information, stream identifier generation time information, and random identifier information can be combined in different orders, or organized using delimiters, fixed-length fields, or key-value pairs. Verification information can be generated based on digest algorithms, signature algorithms, or other integrity verification methods. The specific organization methods described above should not be construed as limitations on the target dynamic stream identifier structure, as long as they enable the target dynamic stream identifier to form an identifiable association with the specific live streaming scenario and possess the necessary distinguishing and verification capabilities.

[0076] In some embodiments, the target dynamic stream identifier can adopt a field combination structure of "scene code, live room identifier information, stream identifier generation time information, random identifier information, and verification information". Specifically, the scene code can be a combination of letters or numbers of a preset length to represent a specific live scene type; the live room identifier information can be used to represent the target live room; the stream identifier generation time information can be a timestamp accurate to the second; the random identifier information can be generated using a combination of letters and numbers; and the verification information can be generated based on the aforementioned fields to verify whether the target dynamic stream identifier has been tampered with. In some embodiments, the total length of the fields of the target dynamic stream identifier can be controlled within a preset length, for example, within 48 bits, to balance transmission efficiency and parsing efficiency.

[0077] Specifically, scene encoding can include encodings corresponding to different live streaming scenarios. For example, encrypted live streaming scenarios can correspond to ENCR, resource-permission live streaming scenarios can correspond to PAY_, exclusive-permission live streaming scenarios can correspond to MEMS, temporary-authorization live streaming scenarios can correspond to TEMP, and regular live streaming scenarios can correspond to LIVE. Live room identification information can be represented by 8 digits, stream identifier generation time information can be represented in YYYYMMDDHHMMSS format, random identifier information can be represented by a 16-character alphanumeric combination, and verification information can be represented by a 6-character alphanumeric combination.

[0078] Furthermore, the verification information can be generated based on the preceding fields in the stream identifier to be verified. For example, a digest processing can be performed on the fields obtained by combining the scene code, live room identifier information, stream identifier generation time information, and random identifier information, and a preset number of bits can be extracted from the digest processing result as the verification information. In one example, MD5 digest processing can be performed on the first 42 bits of the field, and the first 6 bits of the digest processing result can be used as the checksum. It should be noted that MD5 is only an exemplary verification method. In other embodiments, other digest algorithms, signature algorithms, or verification algorithms can also be used to generate the verification information.

[0079] For example, the target dynamic stream identifier can be represented as ENCR_10000001_20251213160000_7f9b2c5e8d3a147c_9s2k7d. Here, ENCR represents an encrypted live streaming scenario, 10000001 represents the live stream room identifier, 20251213160000 represents the stream identifier generation time, 7f9b2c5e8d3a147c represents random identifier information, and 9s2k7d represents verification information. Using this method, edge nodes can identify the live streaming scenario based on the scenario encoding in the target dynamic stream identifier and can perform integrity verification on the target dynamic stream identifier based on the verification information.

[0080] In this way, the target dynamic stream identifier can reflect information related to special live streaming scenarios in the identifier structure, and improve the identifier's distinguishability and integrity verification capability by using time information, random identifier information and verification information, thus providing a foundation for subsequent business attribute association and edge node parsing.

[0081] Step S204: Establish the association between the target dynamic flow identifier and the business attribute information.

[0082] Specifically, the live stream management system can use the target dynamic stream identifier as an index object or associated object to establish a correspondence with business attribute information. This association can be stored in the central data center system or provided to edge nodes in the form of status synchronization information or configuration data. Business attribute information can include lightweight attribute information suitable for rapid parsing, or it can include full attribute information that needs to be queried in the central data center system.

[0083] In optional embodiments, such as Figure 4 As shown, for step S204, establishing the association between the target dynamic flow identifier and the service attribute information may include steps S400 to S408, wherein: Step S400: Determine lightweight attribute information and full attribute information from the business attribute information.

[0084] Step S402: Configure the lightweight attribute information to be information that can be parsed from the target dynamic stream identifier.

[0085] Step S404: Establish the mapping relationship between the target dynamic stream identifier and the full attribute information.

[0086] Step S406: Generate mapping verification information based on the target dynamic flow identifier and the full attribute information.

[0087] Step S408: The mapping verification information is associated with the mapping relationship and stored. The mapping verification information is used to verify the consistency of the correspondence between the target dynamic stream identifier and the full attribute information.

[0088] In this embodiment, lightweight attribute information can be information that edge nodes need to quickly identify when receiving push or pull streaming requests. For example, lightweight attribute information may include basic processing flags such as scene type, whether permission verification is required, whether encryption processing is required, and whether bitrate control is required. Configuring lightweight attribute information to be obtainable from the target dynamic stream identifier allows edge nodes to quickly obtain basic processing information without frequently accessing the central data center system.

[0089] Full attribute information can include more complete business configuration data than lightweight attribute information. For example, full attribute information may include permission verification methods, authorization validity periods, associated permission data, transcoding requirements, resolution policies, log recording tags, or other data related to specific live streaming scenarios. Establishing a mapping relationship between the target dynamic stream identifier and full attribute information allows the central data center data system, edge nodes, or other services to query corresponding attribute data based on the target dynamic stream identifier when more complete business attributes are needed.

[0090] Mapping verification information can be generated jointly based on the target dynamic stream identifier and full attribute information, used to verify whether the correspondence between the two is consistent. In some embodiments, mapping verification information can be a hash value, signature value, digest value, or other verification data. When performing attribute consistency verification, edge nodes or central data center data systems can generate or read verification information based on the parsed attribute information and the stored attribute information respectively, and compare the consistency of the verification information.

[0091] In some embodiments, lightweight attribute information can be configured using lightweight encoding to be information that can be parsed from the target dynamic stream identifier. Specifically, at least one of the following lightweight attribute information—scene type, core permission identifier, and time range—can be Base64 encoded, and the encoding result can be configured in the random identifier field or other parsable fields of the target dynamic stream identifier. After receiving a live stream processing event carrying the target dynamic stream identifier, the edge node can directly parse this field to obtain the basic attribute information, thereby reducing the number of real-time queries to the central data center system.

[0092] In some embodiments, the full attribute information may include at least one of the following: encryption key, resource permission order identifier, membership level threshold, specified user list, encryption method, and resolution limitation information. The live stream management system can establish a mapping relationship between the full attribute information and the target dynamic stream identifier, and store this mapping relationship in the central data center system. Furthermore, a combined hash value can be generated based on the target dynamic stream identifier and the full attribute information, and this combined hash value can be stored as mapping verification information for subsequent consistency verification.

[0093] Specifically, in one attribute binding process, after generating the target dynamic stream identifier, the live stream management system can first embed lightweight attribute information into the target dynamic stream identifier, then establish a mapping relationship between the full attribute information and the target dynamic stream identifier and write it into a cached storage unit, and finally generate a combined hash value based on the target dynamic stream identifier and the full attribute information, and write the combined hash value into a verification storage unit. Through this method, edge nodes can quickly parse basic attributes using the target dynamic stream identifier, and when full attribute information or tamper-proof verification is required, they can obtain full attribute information and mapping verification information from the central data center system.

[0094] By employing the above method, attribute information suitable for rapid edge processing and full attribute information suitable for central storage querying can be managed hierarchically, thus balancing edge processing efficiency and central attribute integrity. Simultaneously, mapping verification information provides a consistency verification basis for the correspondence between target dynamic flow identifiers and business attribute information, reducing processing risks caused by abnormal attribute associations.

[0095] Step S206: Configure lifecycle status information for the target dynamic flow identifier.

[0096] Specifically, lifecycle status information can be used to indicate whether the target dynamic stream identifier is in a valid state, an invalid state, a pending cleanup state, or another state. The live stream management system can configure lifecycle status information for the target dynamic stream identifier based on specific live stream scenario information, business attribute information, live stream status, validity period configuration, or scenario switching.

[0097] In optional embodiments, such as Figure 5 As shown, for step S206, configuring lifecycle status information for the target dynamic flow identifier may include steps S500 to S504, wherein: Step S500: Obtain the lifecycle rules corresponding to the special live streaming scenario information.

[0098] Step S502: Based on the lifecycle rules, determine the validity period information and failure triggering conditions of the target dynamic flow identifier.

[0099] Step S504: Generate the lifecycle status information based on the validity period information and the failure triggering conditions.

[0100] The failure triggering conditions include at least one of the following: the target dynamic stream identifier exceeds its corresponding validity period, the live broadcast corresponding to the target live broadcast room ends, the live broadcast scene of the target live broadcast room is switched, and the attribute status corresponding to the business attribute information changes.

[0101] In this embodiment, lifecycle rules can correspond to specific live streaming scenario information. For example, encrypted live streaming scenarios can be configured with shorter validity periods or strict expiration conditions; resource-permission live streaming scenarios can associate validity periods with live streaming sessions, resource permission permissions, or viewing time periods; temporary authorization live streaming scenarios can associate validity periods with authorization time ranges; and multi-resolution live streaming scenarios can associate lifecycle rules with the current live stream transcoding status or resolution policy status. These lifecycle rules can be determined by scenario configuration data or by the live stream management system based on business attribute information.

[0102] Validity information can be used to limit the available time range of the target dynamic stream identifier. Expiration trigger conditions can be used to limit when the target dynamic stream identifier should change from a valid state to an invalid state or other states. The end of the live broadcast in the target live room, the switch of the live broadcast scene, or the change of the attribute status corresponding to the business attribute information may all cause the original target dynamic stream identifier to no longer be suitable for subsequent push or pull streaming processing.

[0103] In some embodiments, lifecycle rules may include manual configuration and automatic association. Manual configuration allows the streaming client or management system to configure the validity period of the target dynamic stream identifier. Automatic association allows the live stream management system to automatically determine the validity period of the target dynamic stream identifier based on the expected live stream duration, special live stream scenario type, or business attribute information. The validity period information may be embedded in the target dynamic stream identifier or stored in the central data center data system in association with the target dynamic stream identifier.

[0104] In some embodiments, the live stream management system can set up a stream identifier expiration monitoring thread. This thread can scan for currently valid dynamic stream identifiers according to a preset monitoring period, and determine whether to update the corresponding dynamic stream identifier to an invalid state based on validity information, the live streaming status of the target live room, the live streaming scene switching status, or attribute status changes corresponding to business attribute information. In some embodiments, the preset monitoring period can be down to the millisecond level. Through this method, the invalidation handling of dynamic stream identifiers can be automatically triggered by the system, reducing the delay caused by manual cleanup or manual status updates.

[0105] In this way, the target dynamic stream identifier is no longer just a static identifier that exists indefinitely, but has manageable state information. Subsequent live streaming scheduling systems or edge nodes can determine whether the target dynamic stream identifier can still be used for push streaming access, pull streaming access, or live stream transmission processing based on the lifecycle state information, thereby reducing the risk of failed stream identifiers continuing to participate in processing.

[0106] Step S208: Generate and output target dynamic flow identifier management information, which includes the target dynamic flow identifier, the association relationship, and the lifecycle status information.

[0107] Specifically, the target dynamic stream identifier management information can be output to the live broadcast scheduling system, the central data center system, edge nodes, or other systems related to live broadcast processing. The live broadcast scheduling system can generate push addresses based on the target dynamic stream identifier management information; the central data center system can store current active data, full data, log data, or mapping verification information based on the target dynamic stream identifier management information; and edge nodes can perform authentication and processing control based on the target dynamic stream identifier management information or its corresponding status synchronization information.

[0108] In some embodiments, target dynamic stream identifier management information can be output in the form of messages, API calls, database writes, cache updates, or state synchronization events. Different output formats can be adapted to the processing requirements of live streaming scheduling, central storage, and edge synchronization.

[0109] In some embodiments, the live streaming scheduling system can receive scene selection requests, parameter configuration requests, or scene switching requests sent by the streaming tool via a long-lived connection. For example, the live streaming scheduling system can establish a WebSocket long-lived connection with the streaming tool and receive request data encapsulated in JSON format. In some embodiments, the request data can also be encapsulated using encryption methods, such as AES-256 encryption. After receiving the request data, the live streaming scheduling system can perform validity checks on the scene configuration parameters to reduce the risk of invalid parameters causing errors in the generation of the target dynamic stream identifier.

[0110] In some embodiments, the live streaming scheduling system can determine edge nodes based on the broadcaster's network information and node status information. Specifically, candidate edge nodes can be determined based on at least one of the following: the streaming endpoint's network address, network operator, edge node load rate, node health status, and specific live streaming scenario type. The target edge node can be determined using at least one of weighted round-robin and scenario-specific node matching. In one example, an edge node can be selected as a candidate edge node if its load rate is not higher than a preset load threshold. For scenarios such as encrypted live streaming or resource-permission-based live streaming, edge nodes that meet the security level requirements can be prioritized. Through these methods, the edge node address information in the streaming address can be matched with the processing requirements of the live streaming scenario.

[0111] In an optional embodiment, step S208, outputting the target dynamic flow identifier management information, may include: The target dynamic stream identifier and the lifecycle status information are output to the live streaming scheduling system so that the live streaming scheduling system can generate a push stream address containing the target dynamic stream identifier; The push address includes edge node address information, port information, the target dynamic stream identifier, authentication information, and stream identifier validity information.

[0112] In this embodiment, the live streaming scheduling system can generate a push stream address based on the target dynamic stream identifier and lifecycle status information. The edge node address information can be used to indicate the edge node to which the broadcaster connects for pushing the stream; the port information can be used to indicate the access port of the edge node; the authentication information can be used to perform pre-pull authentication when the edge node receives a push stream request; and the stream identifier validity information can be used to enable the edge node to obtain the validity period-related data of the target dynamic stream identifier when resolving the push stream address.

[0113] In some embodiments, the live streaming scheduling system can combine edge node address information, port information, target dynamic stream identifier, authentication information, and stream identifier expiration information into a target push stream address when generating the push stream address. After receiving the target push stream address, the push stream tool can send a push stream request to the corresponding edge node based on the push stream address. The edge node can parse the target dynamic stream identifier and stream identifier expiration information in the push stream address and perform authentication by combining it with data returned from local cache or central data center system.

[0114] In some embodiments, the push address can be a standard RTMP push address or an FLV push address. The push address may include the target edge node's address information, port information, target dynamic flow identifier, authentication information, and expiration time information. Authentication information can be generated using the target dynamic flow identifier, the push end key, and a timestamp. For example, authentication information can be generated using an asymmetric encryption algorithm; in one example, the SM2 asymmetric encryption algorithm can be used. The `sign` field in the push address can represent authentication information, and the `expire` field can represent the target dynamic flow identifier or the push address's expiration timestamp.

[0115] For example, a push stream address can be represented as: rtmp: / / edge node address:port / live / ENCR_10000001_20251214160000_7f9b2c5e8d3a1f7c_9s1k7d?sign=xxxxxx&expire=20251215180000. Here, the edge node address and port represent the edge node's address and port information, ENCR_10000001_20251214160000_7f9b2c5e8d3a1f7c_9s1k7d represents the target dynamic stream identifier, sign represents authentication information, and expire represents the expiration timestamp. Using this method, the edge node can obtain the target dynamic stream identifier and expiration information by parsing the push stream address and perform pre-pull authentication accordingly.

[0116] In this way, the target dynamic stream identifier and lifecycle status information can be entered into the push stream address generation link, so that the push stream address not only points to the edge node, but also carries the dynamic stream identifier and timeliness information related to the specific live streaming scenario, thereby providing a basis for edge nodes to perform authentication before pushing the stream.

[0117] In an optional embodiment, step S208, outputting the target dynamic flow identifier management information, may include: Write the current active data corresponding to the target dynamic stream identifier into the first data storage unit; Write the full data corresponding to the target dynamic stream identifier into the second data storage unit; Write the log data corresponding to the target dynamic stream identifier into the third data storage unit; Write the mapping verification information corresponding to the target dynamic flow identifier and the business attribute information into the fourth data storage unit.

[0118] In this embodiment, the first data storage unit can be used to store data related to the target dynamic stream identifier that is currently in a valid or active state, so that edge nodes or live streaming scheduling systems can quickly query it. The second data storage unit can be used to store the complete business attributes, lifecycle rules, and historical status corresponding to the target dynamic stream identifier. The third data storage unit can be used to store log data generated during the generation, status change, authentication processing, or cleanup processing of the target dynamic stream identifier. The fourth data storage unit can be used to store the mapping verification information between the target dynamic stream identifier and business attribute information.

[0119] In some embodiments, the first data storage unit may be a cached storage unit, the second data storage unit may be a persistent storage unit, the third data storage unit may be a log-type storage unit, and the fourth data storage unit may be a verification-type or tamper-proof verification-related storage unit. The implementation of the above storage units can be selected according to the system deployment environment and should not be construed as limiting a specific database type.

[0120] In some embodiments, the first data storage unit can be implemented using a cached database, such as a cached database cluster, to store lightweight attribute information, full attribute information, timeliness information, and status information of the currently active dynamic stream identifier. The cached database can employ master-slave replication and sentinel mode to improve data read capability and availability. In some embodiments, the data expiration time corresponding to the live stream in the first data storage unit can be configured to a preset duration after the live stream ends, such as 1 hour.

[0121] In an optional embodiment, the second data storage unit can be implemented using a relational database, such as a distributed database like a relational database, to persistently store the full data of the dynamic stream identifier, the streaming end configuration parameters, and the viewing end permission data. In one implementation, the second data storage unit can be partitioned into databases according to the live stream identifier and tables according to the generation date to improve the efficiency of historical data query.

[0122] In an optional embodiment, the third data storage unit can be implemented using a log retrieval database, for example, to store dynamic stream identifier log data, push stream logs, pull stream logs, authentication logs, status change logs, edge node operation logs, and system operation logs. The third data storage unit can support querying or aggregation analysis according to at least one of the following dimensions: dynamic stream identifier, push stream identifier information, scenario type, time range, and authentication result.

[0123] In some embodiments, the fourth data storage unit can be implemented using a verification-type storage node, such as a blockchain light node, to store the combined hash value of the target dynamic flow identifier and all attribute information, as well as the hash value corresponding to the state change of the dynamic flow identifier. Edge nodes and the central data center system can use the fourth data storage unit to verify the integrity of the mapping relationship between the target dynamic flow identifier and the business attribute information.

[0124] Furthermore, when writing target dynamic stream identifier management information, the currently active data can be written to the first data storage unit first, then the full data can be asynchronously synchronized to the second data storage unit, and mapping verification information can be generated and written to the fourth data storage unit. Simultaneously, relevant logs can be written to the third data storage unit. When reading data, edge node authentication and attribute queries can preferentially access the first data storage unit, historical data queries can access the second data storage unit, log queries can access the third data storage unit, and anti-tampering verification can access the fourth data storage unit.

[0125] Furthermore, the central data center system can be configured with a data synchronization verification thread to check the consistency of dynamic stream identifier data between the first and second data storage units. If inconsistency is detected, a synchronization repair process can be triggered to ensure consistency between cached and persistent storage data. This approach enables collaboration between high-concurrency queries, historical storage, log analysis, and tamper-proof verification.

[0126] In optional embodiments, such as Figure 6 As shown, the method may further include steps S600 to S606, wherein: Step S600: When it is detected that the live streaming scene of the target live streaming room has switched from the first live streaming scene to the second live streaming scene, a new dynamic stream identifier corresponding to the second live streaming scene is generated.

[0127] Step S602: Establish the association between the new dynamic stream identifier and the business attribute information corresponding to the second live streaming scenario.

[0128] Step S604: Update the lifecycle status information of the target dynamic flow identifier to the failure status.

[0129] Step S606: Output the failure status information of the new dynamic flow identifier and the target dynamic flow identifier.

[0130] In this embodiment, the first live streaming scenario and the second live streaming scenario can respectively represent different scenarios corresponding to the target live streaming room at different time periods. For example, the target live streaming room can switch from a regular live streaming scenario to a resource permission live streaming scenario, or it can switch from an encrypted live streaming scenario to a dedicated permission live streaming scenario. When the live streaming scenario changes, the original target dynamic stream identifier may no longer be suitable for representing new business attributes or access requirements. Therefore, the live streaming management system can generate a new dynamic stream identifier for the second live streaming scenario.

[0131] Establishing a correlation between the new dynamic stream identifier and the corresponding business attribute information of the second live streaming scenario allows the new live streaming processing link to be processed according to the attributes of the second live streaming scenario. Updating the lifecycle status information of the original target dynamic stream identifier to an invalid state allows subsequent edge nodes or the live streaming scheduling system to identify that the old stream identifier should no longer be used. Outputting the invalid status information of the new dynamic stream identifier and the old stream identifier allows the live streaming scheduling system, the central data system, and edge nodes to synchronize the identifier status after the scenario switch.

[0132] In some embodiments, after updating the target dynamic stream identifier to a failed state, a failure broadcast notification can be proactively sent to the edge node corresponding to the target dynamic stream identifier. The failure broadcast notification may include the target dynamic stream identifier, failure time information, and failure reason information. Upon receiving the failure broadcast notification, the edge node can immediately terminate the push stream connection, pull stream connection, or live stream forwarding processing corresponding to the target dynamic stream identifier. The failure broadcast notification can be sent via long-lived connection push, message queue broadcast, or state synchronization channel. These methods reduce the failure latency caused by edge nodes relying on periodic state synchronization, thereby improving the real-time performance of dynamic stream identifier failure handling.

[0133] In some embodiments, when the live streaming scenario in the target live streaming room changes, the live streaming scheduling system can generate a new push address based on the new dynamic stream identifier and send the new push address to the push tool. The push tool can then perform subsequent push streaming based on the new push address. For the playback end, the edge node or the live streaming scheduling system can update the corresponding pull address based on the new dynamic stream identifier, enabling the playback end to continue acquiring the live stream based on the updated pull address. This approach reduces the risk of the old dynamic stream identifier continuing to be used during the switch between old and new dynamic stream identifiers and allows both the push and pull sides to process the stream based on the new dynamic stream identifier.

[0134] By using the above methods, when switching between target live streaming scenarios, an orderly switch between the old and new dynamic stream identifiers can be achieved, reducing the risk of the old dynamic stream identifiers continuing to participate in push or pull streaming processing.

[0135] In an optional embodiment, the method may further include steps S610 to S614, wherein: Step S610: Receive scene configuration data, wherein the scene configuration data includes at least one of scene identifier configuration data, flow identifier structure configuration data, attribute field configuration data, authentication rule configuration data, and lifecycle rule configuration data.

[0136] Step S612: Generate scene flow identifier management rules based on the scene configuration data.

[0137] Step S614: Based on the scene stream identifier management rules, perform dynamic stream identifier generation, attribute association, and lifecycle state configuration for the corresponding special live streaming scenario.

[0138] In this embodiment, scene configuration data can be used to describe the stream identifier generation method, attribute field range, authentication logic, and lifecycle rules for a specific live streaming scenario. Scene identifier configuration data can be used to determine the scene code or scene type. Stream identifier structure configuration data can be used to determine the field composition or combination rules of dynamic stream identifiers. Attribute field configuration data can be used to determine the field range in business attribute information and its association with stream identifiers. Authentication rule configuration data can be used to determine the data or verification methods that edge nodes need to read when performing authentication at different stages. Lifecycle rule configuration data can be used to determine the validity period and expiration trigger conditions of dynamic stream identifiers.

[0139] In some embodiments, the live stream management system can maintain a set of scene stream identifier management rules. When a new special live stream scene is added or an existing special live stream scene is adjusted, the corresponding scene stream identifier management rules can be generated or updated through scene configuration data. Subsequently, when processing special live stream scene information of a target live stream room, the live stream management system can call the corresponding rules to perform dynamic stream identifier generation, attribute association, and lifecycle state configuration.

[0140] In some embodiments, scene stream identifier management rules can be generated through visual configuration and a rule engine. For example, scene encoding, stream identifier structure, attribute fields, authentication rules, edge node processing logic, and lifecycle rules can be configured through the rule engine. The rule engine can be implemented using an engine capable of generating rules based on configuration data and performing rule matching. When adding new special live streaming scenarios, adaptation can be completed through rule configuration, reducing the need to modify the core stream identifier management logic.

[0141] Specifically, the scenario configuration process can include: adding a scenario type, defining the stream identifier structure, configuring attribute fields, configuring authentication and processing logic, and publishing the configuration. When adding a scenario type, you can configure the scenario name, unique scenario code, and basic type. When defining the stream identifier structure, you can configure whether the target dynamic stream identifier needs additional fields, the length of the random identifier information, and the method for generating verification information. When configuring attribute fields, you can configure lightweight attribute information and full attribute information separately, and configure attribute verification rules. When configuring authentication and processing logic, you can configure whether password verification, permission verification, encryption processing, transcoding processing, and lifecycle rules are required. After publishing the configuration, the rule engine can apply the new scenario stream identifier management rules to the dynamic stream identifier generation, attribute association, and lifecycle state configuration processes. Through this method, when adding special live streaming scenarios, adaptation can be completed through rule configuration, reducing the need to modify the core stream identifier management logic.

[0142] By using the above methods, the logic for generating and managing stream identifiers under different special live streaming scenarios can be configured, reducing the need to modify the core processing logic due to the addition of new scenarios and improving the consistency of dynamic stream identifier management under different special live streaming scenarios.

[0143] In an optional embodiment, the method may further include steps S620 to S626, wherein: Step S620: If the lifecycle status information of the target dynamic flow identifier represents a failure status, the target dynamic flow identifier is added to the failure flow identifier queue.

[0144] Step S622: Sort the dynamic flow identifiers in the failed flow identifier queue based on the failure time information.

[0145] Step S624: Based on the preset cleanup batch and data storage load status, determine the dynamic flow identifier to be cleaned from the failed flow identifier queue.

[0146] Step S626: Perform cleaning or backup-after-cleaning processing on the dynamic stream identifier to be cleaned.

[0147] In this embodiment, the failed flow identifier queue can be used to centrally manage dynamic flow identifiers that have entered a failed state. Failure time information can be used to indicate when a dynamic flow identifier entered a failed state. A preset cleanup batch can be used to limit the number of dynamic flow identifiers processed in a single cleanup. Data storage load status can be used to indicate the current load level of the relevant storage system.

[0148] In some embodiments, when a target dynamic stream identifier becomes invalid, the live stream management system can add the target dynamic stream identifier to the invalid stream identifier queue. The system can sort the queue according to the failure time and extract the dynamic stream identifiers to be cleaned from the queue when the data storage load meets the cleanup start conditions. For dynamic stream identifiers that need to retain historical data, backups or necessary historical records can be performed first, and then the cleanup process can be performed.

[0149] In some embodiments, the preset cleanup batch can be configured based on the processing capacity of the central data center's data system. For example, 1000 failed dynamic flow identifiers can be extracted from the failed flow identifier queue each time as dynamic flow identifiers to be cleaned, to avoid excessive data storage load caused by cleaning too much data at once. The data storage load status can include the database load rate. In one example, the cleanup process can be started when the database load rate is below a first load threshold; the cleanup process can be paused when the database load rate is above a second load threshold. The first load threshold can be 60%, and the second load threshold can be 80%. The above values ​​are merely examples and can be configured according to the actual deployment environment.

[0150] Furthermore, for dynamic stream identifiers that need to retain historical data, the retention period can be configured. For example, dynamic stream identifier data in resource permission live streaming scenarios can be configured to be retained for one year; after the retention period expires, the corresponding dynamic stream identifier is added to the set of dynamic stream identifiers to be cleaned up. For data that needs to be audited or traced, it can be backed up first, and then the cleanup process can be performed. Through the above methods, the storage resources occupied by invalid dynamic stream identifiers can be reduced while taking into account the needs of historical data query, problem investigation, and security auditing.

[0151] By using the above methods, we can avoid invalid dynamic stream identifiers occupying the current active data storage space for a long time, reduce the impact of invalid data on query and status synchronization processing, and retain the necessary data foundation for historical tracing or business auditing.

[0152] In an optional embodiment, the special live streaming scenario information includes at least one of encrypted live streaming scenario information, resource permission live streaming scenario information, exclusive permission live streaming scenario information, enterprise internal live streaming scenario information, temporary authorization live streaming scenario information, and multi-resolution live streaming scenario information.

[0153] In this embodiment, encrypted live streaming scenario information can be used to indicate that the corresponding live stream needs to be processed according to an encryption strategy. Resource permission live streaming scenario information can be used to indicate that the corresponding live stream needs to be associated with resource permission data for pre-stream authentication. Exclusive permission live streaming scenario information can be used to indicate that the corresponding live stream needs to be associated with member permission data. Enterprise internal live streaming scenario information can be used to indicate that the corresponding live stream needs to perform access control according to a preset organizational scope or authorization scope. Temporary authorization live streaming scenario information can be used to indicate that the corresponding live stream is only allowed to access within the scope of the authorization validity period or authorized objects. Multi-resolution live streaming scenario information can be used to indicate that the corresponding live stream needs to undergo bitrate control, transcoding, or resolution distribution processing according to business attribute information.

[0154] Through the above methods, the live stream management system can adapt to various special live streaming scenarios through a unified dynamic stream identifier management logic, and configure corresponding business attributes, lifecycle rules and authentication rules for different scenarios.

[0155] As an application example, the broadcaster selects a live streaming scenario with resource permissions using a streaming tool and submits the scenario selection information and parameter configuration for the target live streaming room. The live streaming scheduling system forwards this scenario selection information to the live streaming management system. The live streaming management system obtains the resource permission live streaming scenario information and business attribute information corresponding to the target live streaming room, generates a target dynamic stream identifier based on the resource permission live streaming scenario information, and establishes a relationship between the target dynamic stream identifier and the business attributes related to resource permissions. The live streaming management system also configures validity period information and expiration trigger conditions for the target dynamic stream identifier and outputs the target dynamic stream identifier management information to the live streaming scheduling system, the central data system, and edge nodes. The live streaming scheduling system generates a streaming address based on the target dynamic stream identifier, and the streaming tool pushes the live stream to the edge nodes based on the streaming address. When receiving a streaming request or a streaming request, the edge nodes can parse the target dynamic stream identifier and perform authentication processing in conjunction with status information and business attribute information.

[0156] Example 2 Figure 7 A flowchart illustrating a dynamic flow identifier processing method according to Embodiment 2 of this application is shown schematically. This embodiment can be applied to edge nodes. Figure 7 As shown, the dynamic stream identifier processing method may include steps S700 to S708, wherein: Step S700: Receive a live stream processing event carrying the target dynamic stream identifier.

[0157] Step S702: Parse the target dynamic flow identifier to obtain the scene identifier information corresponding to the target dynamic flow identifier.

[0158] Step S704: Obtain the status information and service attribute information corresponding to the target dynamic flow identifier.

[0159] Step S706: Based on the scene identification information, the status information, and the business attribute information, perform stream identification authentication on the live stream processing event.

[0160] Step S708: Based on the authentication result of the stream identifier authentication, perform access processing, distribution processing, termination processing, or alarm processing on the live stream processing event.

[0161] In this embodiment, the edge node can receive live stream processing events carrying target dynamic stream identifiers during live stream processing and parse scene identifier information from the target dynamic stream identifier. The edge node can also obtain the status information and service attribute information corresponding to the target dynamic stream identifier to determine whether the target dynamic stream identifier is valid, whether it matches the corresponding service attribute, and whether it meets the authentication requirements of the current processing stage. Based on the stream identifier authentication result, the edge node can continue to perform access or distribution processing, or it can terminate processing or trigger alarm processing.

[0162] In this way, edge nodes no longer process push and pull streams solely based on fixed flow names or single entry point authentication results. Instead, they can combine target dynamic flow identifiers, status information, and business attribute information to perform flow identifier authentication at different processing stages. This improves the edge nodes' responsiveness to changes in dynamic flow identifier status and business attributes.

[0163] The following combination Figure 7 The steps S700 to S708 and other related steps are further described.

[0164] Step S700: Receive a live stream processing event carrying a target dynamic stream identifier. The live stream processing event includes at least one of a push stream access event, a push stream transmission event, a pull stream access event, a pull stream transmission event, and an attribute verification event.

[0165] Specifically, push stream access events can be events generated when a push stream tool initiates a push stream connection or push stream request to an edge node. Push stream transmission events can be events generated during the continuous transmission of a live stream from the push stream client to the edge node. Pull stream access events can be events generated when the playback client requests to retrieve a live stream from the edge node. Pull stream transmission events can be events generated during the continuous distribution of a live stream from the edge node to the playback client. Attribute validation events can be events used during live stream transmission to verify whether the business attributes corresponding to the target dynamic stream identifier are consistent.

[0166] The target dynamic stream identifier can be located in the push stream address, pull stream address, request parameters, request path, header fields, or other data locations that can be parsed by the edge nodes. Edge nodes can extract the target dynamic stream identifier from the corresponding data after receiving a live stream processing event.

[0167] Step S702: Parse the target dynamic flow identifier to obtain the scene identifier information corresponding to the target dynamic flow identifier.

[0168] Specifically, edge nodes can extract scene identifier information from the target dynamic stream identifier according to the structure parsing rules of the target dynamic stream identifier. The scene identifier information can be used to indicate the live stream scene type corresponding to the current live stream processing event. Edge nodes can select the corresponding processing channel, authentication rules, or live stream processing strategy based on the scene identifier information.

[0169] In some embodiments, edge nodes can access live streams using port multiplexing and stream identifier differentiation. That is, the same access port can receive push or pull access events carrying different target dynamic stream identifiers, and the edge node distinguishes different live streams by parsing the target dynamic stream identifier. In one example, the same port can simultaneously access 100,000 live streams corresponding to different dynamic stream identifiers. The above number is only an example and can be adjusted according to the deployment scale and processing capacity of the edge nodes.

[0170] In some embodiments, edge nodes can quickly identify the live streaming scene type using the 4-bit scene code in the target dynamic stream identifier, and allocate corresponding processing thread pools, processing queues, or processing channels for different live streaming scene types. For example, for encrypted live streaming scenes and resource-permission live streaming scenes, processing channels with higher security levels or stricter authentication processes can be allocated; for multi-resolution live streaming scenes, processing channels with transcoding or bitrate control capabilities can be allocated. This approach reduces the probability of resource contention between live streams from different scenes.

[0171] In an optional embodiment, after step S702, the method may further include steps S710 to S714, wherein: Step S710: Based on the scene identification information, determine the live scene type corresponding to the live stream processing event.

[0172] Step S712: Based on the live streaming scenario type, determine the processing channel corresponding to the live streaming processing event.

[0173] Step S714: Assign the live stream processing event to the processing channel.

[0174] In this embodiment, the live streaming scenario type can correspond to scenarios such as encrypted live streaming, resource-permission live streaming, exclusive-permission live streaming, enterprise internal live streaming, temporary-authorized live streaming, or multi-resolution live streaming. The processing channel can include a thread pool, processing queue, processing service, processing module, or other resources that can be used to carry live stream processing events. Edge nodes can allocate live stream processing events for different scenarios to different processing channels based on scenario identification information.

[0175] In some embodiments, edge nodes can maintain a correspondence between scene identifier information and processing channels. Once an edge node parses the scene identifier information corresponding to a target dynamic stream identifier, it can locate the corresponding processing channel and assign the live stream processing event to that channel. For live streaming scenarios with high security requirements, processing channels with stricter authentication processes can be configured; for multi-resolution live streaming scenarios, processing channels with bitrate control or transcoding capabilities can be configured.

[0176] In this way, edge nodes can classify and process live stream processing events based on scene identification information in the target dynamic stream identifier, thereby improving the matching degree of processing logic under different special live streaming scenarios.

[0177] Step S704: Obtain the status information and service attribute information corresponding to the target dynamic flow identifier.

[0178] Specifically, status information can be used to indicate whether the target dynamic stream identifier is valid, invalid, blacklisted, or has undergone attribute changes. Business attribute information can be used to indicate the processing attributes of the live stream corresponding to the target dynamic stream identifier in the current specific live streaming scenario. Edge nodes can obtain the above information from their local stream identifier status cache or query the above information from the central data center system.

[0179] In an optional embodiment, step S704 may include steps S720 to S726, wherein: Step S720: Query the local stream identifier status cache of the edge node.

[0180] Step S722: If available cached data corresponding to the target dynamic flow identifier exists in the local flow identifier status cache, determine the status information and / or the service attribute information based on the available cached data.

[0181] Step S724: If the available cached data is not found in the local stream identifier status cache, a data query request is sent to the central computer room data system.

[0182] Step S726: Receive the query results returned by the central computer room data system, and determine the status information and / or the business attribute information based on the query results.

[0183] In this embodiment, the local flow identifier status cache can store dynamic flow identifier-related status data that the edge node needs to process or is currently processing. Available cached data can be unexpired status information or business attribute information that matches the target dynamic flow identifier. Edge nodes prioritize querying the local flow identifier status cache, which can reduce processing latency caused by frequent access to the central data center system. When no available cached data exists in the local flow identifier status cache, the edge node can send a data query request to the central data center system to obtain the latest status information or business attribute information of the target dynamic flow identifier.

[0184] In this way, edge nodes can strike a balance between processing efficiency and status accuracy: local caching is used to improve routine processing efficiency, while the central data center system provides authoritative data when the cache is insufficient or when the latest information is needed.

[0185] In an optional embodiment, step S704 may further include steps S730 to S738, wherein: Step S730: Establish a status synchronization connection with the central computer room data system.

[0186] Step S732: Obtain state change information through the state synchronization connection. The state change information includes at least one of the following: flow identifier failure state, attribute change information, and blacklisted flow identifier list.

[0187] Step S734: Update the local stream identifier state cache based on the state change information.

[0188] Step S736: If the state synchronization connection is detected to be interrupted, the live stream processing event is processed based on the local stream identifier state cache.

[0189] Step S738: If the state synchronization connection is restored, obtain full state information from the central computer room data system and update the local stream identifier state cache based on the full state information.

[0190] In this embodiment, the state synchronization connection can be a communication connection between the edge node and the central data center system for synchronizing dynamic flow identifier state changes. State change information may include the failure status of a dynamic flow identifier, changes in service attributes, a blacklist of flow identifiers, or other data that needs to be updated by the edge node. The local flow identifier state cache can be incrementally updated based on the state change information.

[0191] In the event of a state synchronization connection interruption, edge nodes can continue processing live stream events based on their existing local stream identifier state cache. To mitigate the risks associated with state expiration, edge nodes can exercise conservatism within the validity period of their local cache, or reject relevant live stream processing events if the cached data does not meet authentication requirements. Once the state synchronization connection is restored, edge nodes can retrieve full state information from the central data center system and update their local stream identifier state cache to minimize potential state discrepancies during the connection interruption.

[0192] In an optional embodiment, the state synchronization connection can be implemented using a WebSocket long-lived connection. Edge nodes can send heartbeat packets to the central data system via the state synchronization connection and obtain flow identifier state change information based on the heartbeat packets or corresponding responses. In one example, the edge node can send a heartbeat packet every 100 milliseconds to obtain the failure status, attribute change information, and blacklist of flow identifiers for dynamic flow identifiers.

[0193] Furthermore, state synchronization can employ an incremental synchronization method. This means the central data center system can synchronize only the dynamic flow identifier information whose state has changed to the edge nodes, instead of synchronizing all dynamic flow identifier data each time. This approach reduces the amount of data transmitted between the edge nodes and the central data center system, and improves state synchronization efficiency.

[0194] In this way, edge nodes can promptly detect the failure, attribute changes, and blacklist status of target dynamic stream identifiers, and maintain a certain processing capacity through local caching when synchronization connection is abnormal.

[0195] Step S706: Based on the scene identification information, the status information, and the business attribute information, perform stream identification authentication on the live stream processing event.

[0196] Specifically, edge nodes can determine the authentication rules applicable to the current live stream processing event based on scene identification information, determine whether the target dynamic stream identifier is valid based on status information, and determine whether permission verification, encryption processing, bitrate control, or other processing is required based on business attribute information. Stream identifier authentication can be performed in stages according to the event type and processing stage of the live stream processing event.

[0197] In optional embodiments, such as Figure 8 As shown, for step S706, based on the scene identification information, the status information, and the business attribute information, stream identification authentication is performed on the live stream processing event, which may include steps S800 to S804, wherein: Step S800: Based on the event type and processing stage of the live stream processing event, determine the target authentication stage corresponding to the target dynamic stream identifier.

[0198] Step S802: Based on the target authentication stage, determine the authentication data required for the stream identifier authentication.

[0199] Step S804: Based on the authentication data, perform stage authentication on the live stream processing event.

[0200] The target authentication stage includes at least one of the following: pre-pull authentication stage, in-pull authentication stage, pre-pull authentication stage, in-pull authentication stage, and in-transmission authentication stage.

[0201] In this embodiment, the pre-pull authentication stage can be used to verify the push address, target dynamic stream identifier, and timeliness information before push access. The push authentication stage can be used to verify the binding relationship between the push end identifier information and the target dynamic stream identifier during push transmission. The pull authentication stage can be used to verify the matching relationship between the viewer's permissions and service attribute information before the playback end requests to pull the stream. The pull authentication stage can be used to verify the real-time status of the target dynamic stream identifier during continuous pull transmission. The transmission authentication stage can be used to verify the consistency of the service attributes corresponding to the target dynamic stream identifier during live stream transmission.

[0202] For example, the process can first verify whether the target dynamic stream identifier is valid, then verify whether the push stream address authentication information matches the preset signature result, and finally verify whether the expiration information in the target dynamic stream identifier has expired. If all verifications pass, the stage authentication can be considered successful. If any verification fails, the corresponding live stream processing event can be terminated, and corresponding alarm information can be generated.

[0203] In this way, edge nodes can use different authentication data to perform authentication at different processing stages, avoiding concentrating all authentication logic at a single entry point, thereby improving the state awareness capability during the live stream processing.

[0204] In an optional embodiment, step S706, which involves performing stream identifier authentication on the live stream processing event based on the scene identifier information, the status information, and the business attribute information, may include steps S810 to S814, wherein: Step S810: Determine whether the target dynamic stream identifier belongs to the blacklist stream identifier.

[0205] Step S812: If the target dynamic stream identifier belongs to the blacklist stream identifier, reject the live stream processing event and generate an abnormal request alarm message.

[0206] Step S814: If the target dynamic stream identifier does not belong to the blacklist stream identifier, continue to perform the stream identifier authentication based on the scene identifier information, the status information and the business attribute information.

[0207] In this embodiment, the blacklist stream identifiers may include dynamic stream identifiers that have expired but are still frequently requested, dynamic stream identifiers identified as abnormal, or illegal stream identifiers issued by the central data center system. Edge nodes can perform blacklist verification before performing authentication at other stages to quickly reject obviously abnormal live stream processing events.

[0208] In some embodiments, the blacklist of stream identifiers can be synchronized in real time from the central data center system to the edge nodes. The blacklist can include expired dynamic stream identifiers, dynamic stream identifiers identified as invalid, and dynamic stream identifiers associated with abnormal requests. Edge nodes can prioritize blacklist verification during push stream access, pull stream access, or live stream transmission. If the target dynamic stream identifier belongs to the blacklist, the edge node can reject the corresponding push or pull stream request and report an abnormal request alarm to the central data center system. This approach allows for the interception of abnormal stream identifier requests at an earlier stage, reducing subsequent authentication and processing resource consumption.

[0209] By using the above methods, the processing overhead of edge nodes in performing subsequent complex authentication processes for illegal or abnormal dynamic flow identifiers can be reduced, and the ability to intercept abnormal flow identifier requests can be improved.

[0210] In an optional embodiment, step S706, which involves performing stream identifier authentication on the live stream processing event based on the scene identifier information, the status information, and the business attribute information, may include: When the live stream processing event is a push stream access event, the push stream address authentication information and timeliness information carried by the push stream access event are obtained, and the push stream access event is authenticated before push stream based on the target dynamic stream identifier, the push stream address authentication information and the timeliness information. When the live stream processing event is a push stream transmission event, the push stream terminal identification information corresponding to the push stream transmission event is obtained, and the push stream transmission event is authenticated during the push stream based on the binding relationship between the push stream terminal identification information and the target dynamic stream identifier.

[0211] In this embodiment, the streaming address authentication information can be used to verify whether the streaming address was generated by the live broadcast scheduling system or whether it meets preset authentication conditions. The timeliness information can be used to verify whether the target dynamic stream identifier or streaming address is still within its valid time range. The streaming end identifier information can be identifier information used to represent the streaming tool, broadcaster terminal, or streaming account. The binding relationship can be the association data between the target dynamic stream identifier and the streaming end identifier information.

[0212] During the pre-pull authentication phase, edge nodes can first determine whether the push access event meets the access conditions based on the target dynamic stream identifier, push address authentication information, and timeliness information. After the pre-pull authentication is successful, the edge node can further perform in-pull authentication based on the binding relationship between the push end identifier information and the target dynamic stream identifier during the push transmission process.

[0213] In optional embodiments, pre-pushing authentication may include verification of the validity of the push address, verification of the integrity of the target dynamic flow identifier, and verification of the validity of the target dynamic flow identifier. Specifically, the edge node can parse the sign field in the push address to verify the push address authentication information, verify the integrity of the target dynamic flow identifier based on the verification information in the target dynamic flow identifier, and determine whether the target dynamic flow identifier is within its validity period based on the expire field in the push address or the validity information in the central data center system. In the event of an invalid push address, an invalid target dynamic flow identifier, or an expired target dynamic flow identifier, the edge node can reject the push access event and generate an alarm message indicating an invalid push address or an invalid flow identifier.

[0214] In some embodiments, authentication during streaming may include verification of the streaming endpoint's identity and verification of the binding relationship between the target dynamic stream identifier and the streaming endpoint. Specifically, the edge node may send the streaming endpoint's identifier information and the target dynamic stream identifier to the central data center system, which will then verify whether a binding relationship exists between the streaming endpoint's identifier information and the target dynamic stream identifier. If the binding relationship verification fails, the edge node may reject the streaming transmission event or terminate the live stream access, and generate an alarm message indicating that the streaming endpoint's identity is invalid or that the stream identifier does not match the streaming endpoint.

[0215] By using the above methods, edge nodes can verify different authentication elements in the two stages of push stream access and push stream transmission, reducing the risk of push stream addresses being used abnormally or the push stream terminal not matching the target dynamic stream identifier.

[0216] In an optional embodiment, step S706, which involves performing stream identifier authentication on the live stream processing event based on the scene identifier information, the status information, and the business attribute information, may include: When the live stream processing event is a pull stream access event, the viewing terminal identification information corresponding to the pull stream access event is obtained, the permission verification method corresponding to the scene identification information is determined, and the pull stream access event is authenticated before the pull stream is pulled based on the viewing terminal identification information, the permission verification method and the business attribute information. When the live stream processing event is a pull stream transmission event, the timeliness authentication of the pull stream process corresponding to the pull stream transmission event is performed based on the status information.

[0217] In this embodiment, the viewing end identification information can be identification information used to represent the playback end, viewing account, or viewing request source. The permission verification method can be determined by the scenario identification information. For example, a resource permission live streaming scenario can correspond to a resource permission verification method; a dedicated permission live streaming scenario can correspond to a member permission verification method; and a temporary authorization live streaming scenario can correspond to an authorization scope or authorization validity period verification method. Business attribute information can provide the attribute data required for the permission verification method.

[0218] During the pre-stream authentication phase, edge nodes can verify whether the viewing end meets the streaming access conditions based on the viewing end's identifier information, permission verification method, and business attribute information. During the streaming authentication phase, edge nodes can continuously or periodically confirm whether the target dynamic stream identifier is still valid based on status information.

[0219] In some embodiments, pre-stream authentication can determine the corresponding permission verification method based on scenario identification information. For example, in a resource-permission live streaming scenario, the viewing client can be verified to have resource-permission viewing permissions based on associated permission data; in a dedicated permission live streaming scenario, the viewing client can be verified to have membership permissions; and in a temporary authorization live streaming scenario, the viewing client's identification information can be verified to be in the specified user list. The aforementioned order status, permission status, or authorization list data can be obtained and used provided that data compliance requirements are met.

[0220] In some embodiments, time-sensitive authentication during streaming can be performed periodically during the streaming process. For example, an edge node can obtain or query the real-time status information of the target dynamic stream identifier every 5 seconds, and determine whether the target dynamic stream identifier has expired based on the real-time status information. If the target dynamic stream identifier has expired, the edge node can immediately terminate the streaming service and cause the playback end to stop obtaining the live stream based on that dynamic stream identifier.

[0221] By using the above methods, the playback terminal can be controlled by the dynamic stream identifier status and business attributes both before access and during the streaming process, thereby reducing the risk of continuing to stream after the dynamic stream identifier expires.

[0222] In an optional embodiment, when the live stream processing event is an attribute verification event, step S706, based on the scene identification information, the status information, and the business attribute information, performs stream identification authentication on the live stream processing event, which may include: Obtain the first attribute verification information corresponding to the target dynamic flow identifier. The first attribute verification information is generated based on the business attribute information obtained by local parsing or caching of the edge node. The second attribute verification information corresponding to the target dynamic flow identifier is obtained from the central computer room data system. The second attribute verification information is generated based on the business attribute information stored in the central computer room data system. Perform a consistency check on the first attribute verification information and the second attribute verification information; If the consistency check fails, the live stream transmission corresponding to the target dynamic stream identifier is terminated and an attribute anomaly alarm message is generated.

[0223] In this embodiment, the first attribute verification information can be generated based on business attribute information parsed by the edge node or obtained from local caching. The second attribute verification information can be generated or retrieved based on business attribute information stored in the central data center system. The edge node can compare the first and second attribute verification information to determine whether the business attributes used for processing on the edge node side are consistent with the business attributes in the central data center system.

[0224] In some embodiments, the first attribute verification information and the second attribute verification information can be hash values, digest values, signature values, or other verification data that can characterize the consistency of attribute data. The edge node triggers an attribute verification event during live stream transmission and compares the two attribute verification information. If the consistency verification fails, it indicates that the business attributes corresponding to the target dynamic stream identifier may be inconsistent, and the edge node can terminate the live stream transmission and generate an attribute anomaly alarm information.

[0225] In some embodiments, authentication during transmission may include attribute consistency authentication. Edge nodes may periodically obtain attribute verification information corresponding to the target dynamic stream identifier from the central data center system and compare it with attribute verification information obtained by the edge nodes based on local parsing or local caching. For example, an edge node may obtain the attribute hash value corresponding to the target dynamic stream identifier from the central data center system every 10 seconds and perform a consistency check with the locally parsed attribute hash value. If the consistency check fails, the edge node may terminate the transmission of the live stream corresponding to the target dynamic stream identifier and report an attribute inconsistency alarm to the central data center system.

[0226] The above methods can be used to verify the correspondence between the target dynamic stream identifier and the business attribute information during the live stream transmission process, thereby reducing the risk of live stream processing caused by attribute asynchrony or attribute anomalies.

[0227] Step S708: Based on the authentication result of the stream identifier authentication, perform access processing, distribution processing, termination processing, or alarm processing on the live stream processing event.

[0228] Specifically, the authentication result can indicate whether authentication is successful, unsuccessful, or abnormal. Edge nodes can determine the subsequent processing method based on the authentication result. If authentication is successful, the edge node can continue to perform push streaming access, live stream transcoding, live stream encryption, live stream distribution, or pull streaming services; if authentication fails or is abnormal, the edge node can terminate the corresponding live stream processing event and generate alarm information.

[0229] In an optional embodiment, step S708, based on the authentication result of the stream identifier authentication, performs access processing, distribution processing, termination processing, or alarm processing on the live stream processing event, which may include steps S850 to S854, wherein: Step S850: If the authentication result indicates that the authentication is successful, determine the live stream processing strategy based on the business attribute information.

[0230] Step S852: Based on the live stream processing strategy, perform at least one of the following processing on the live stream corresponding to the live stream processing event: access, transcoding, encryption, bitrate control, or distribution.

[0231] Step S854: If the authentication result indicates that the authentication has failed, terminate the live stream processing event and generate an alarm message corresponding to the reason for the authentication failure.

[0232] In this embodiment, the live stream processing strategy can be determined by business attribute information. For example, in an encrypted live stream scenario, the live stream processing strategy may include performing encryption processing on the live stream or using an encrypted channel; in a resource-permission live stream scenario, the live stream processing strategy may include performing permission verification before distribution; in a multi-resolution live stream scenario, the live stream processing strategy may include transcoding or distribution according to a bitrate control strategy or a resolution strategy. If authentication fails, the edge node can generate alarm information based on the reason for the failure, such as time-out alarms, permission mismatch alarms, attribute consistency anomaly alarms, or blacklist stream identifier alarms.

[0233] In some embodiments, edge nodes can perform differentiated processing based on business attribute information associated with the target dynamic stream identifier. Specifically, in encrypted live streaming scenarios, edge nodes can obtain encryption keys from the central data center system and perform real-time encryption processing on the live stream before distribution. In one example, the real-time encryption processing can use AES-256 encryption. In resource-permission live streaming scenarios, edge nodes can verify the resource permission status of the viewer based on associated permission data, and terminate the streaming service if the resource permission status expires. In exclusive-permission live streaming scenarios, edge nodes can verify the permission status of the viewer, and terminate the streaming service if the permission status expires. In multi-resolution live streaming scenarios, edge nodes can generate or distribute live streams with corresponding bitrates based on the resolution limitation attributes associated with the target dynamic stream identifier, for example, distributing 4K streaming addresses only to viewers that meet the permission conditions. In temporary-authorization live streaming scenarios, edge nodes can verify whether the viewer identifier information belongs to a specified user list, and terminate the streaming service if the viewer identifier information is removed from the specified user list.

[0234] In this way, edge nodes can execute processing strategies that match the live streaming scenario based on the business attribute information associated with the dynamic stream identifier, so that processing actions such as access, transcoding, encryption, bitrate control and distribution are consistent with the business attributes corresponding to the target dynamic stream identifier.

[0235] In this way, edge nodes can combine the stream identifier authentication result with the live stream processing strategy, so that the live stream processing action is consistent with the business attributes corresponding to the dynamic stream identifier.

[0236] As an application example, such as Figure 9As shown, the streamer's push-stream tool (pushing tool) can send live streaming requests to the cloud-based uplink scheduling system (live streaming scheduling system). The edge node selection module in the cloud-based uplink scheduling system can select target edge nodes and apply for dynamic stream names from the real-time stream name generation system through the push-stream address generation module. The stream name rule parsing module in the real-time stream name generation system (live streaming management system) can parse scene rules, the dynamic stream name generation engine can generate target dynamic stream names, and the stream name attribute binding module can bind business attributes to dynamic stream names and store the corresponding mapping relationship in the stream name-attribute mapping database. After the push-stream address generation module generates the corresponding push-stream address, it can be sent to the streamer's push-stream tool through the push-stream address distribution module. The streamer's push-stream tool can push streams to the edge node processing system (edge ​​nodes) based on the push-stream address. The multi-stream name recognition module in the edge node processing system can recognize dynamic stream names, and the real-time authentication request module can initiate authentication with the central data center system. The permission verification engine in the central computer room data system can complete permission verification based on the stream name-attribute mapping database, business attribute configuration module, and scene rule management module. The business attribute parsing module can parse business attributes, and the live stream processing module completes the live stream processing. The processed live stream can be returned to the playback end (viewer's end) player for playback via the pull stream address return module. The scene information receiving module can receive the special live scene information corresponding to the target live room sent by the broadcaster push streaming tool, and send the scene information to the stream name rule parsing module in the real-time stream name generation system. The log storage and analysis module can receive the log data output by the real-time authentication request module and the permission verification engine, and store and analyze the log data.

[0237] As another application example, in a resource-permission live streaming scenario, the playback client sends a pull-stream access event to the edge node, carrying a target dynamic stream identifier. The edge node parses the target dynamic stream identifier to obtain scene identifier information and determines the resource-permission live streaming scenario corresponding to the live stream processing event based on the scene identifier information. The edge node queries its local stream identifier status cache. If available cached data exists locally, it reads the status information and business attribute information corresponding to the target dynamic stream identifier; if no available cached data exists locally, it queries the corresponding data from the central data center system. The edge node performs pre-pull-stream authentication based on the viewer's identifier information, permission verification method, and business attribute information. After successful pre-pull-stream authentication, the edge node continues to perform time-sensitive authentication based on the status information during the pull-stream transmission process. When the target dynamic stream identifier becomes invalid or the attribute consistency verification fails, the edge node can terminate the corresponding live stream transmission and generate an alarm message.

[0238] Example 3 Figure 10The diagram schematically illustrates a dynamic stream identifier processing apparatus according to Embodiment 3 of this application. This apparatus can be divided into one or more program modules. One or more program modules are stored in a storage medium and executed by one or more processors to complete the embodiments of this application. The program module referred to in the embodiments of this application refers to a series of computer program instruction segments capable of performing a specific function. The following description will specifically introduce the functions of each program module in this embodiment.

[0239] like Figure 10 As shown, the dynamic stream identifier processing device can be applied to a live stream management system. The device 1000 includes an acquisition module 1010, a generation module 1020, an association module 1030, a configuration module 1040, and an output module 1050.

[0240] The acquisition module 1010 is used to acquire special live streaming scene information corresponding to the target live streaming room and business attribute information corresponding to the special live streaming scene information.

[0241] The generation module 1020 is used to generate a target dynamic stream identifier based on the special live streaming scenario information.

[0242] The association module 1030 is used to establish the association relationship between the target dynamic flow identifier and the business attribute information.

[0243] Configuration module 1040 is used to configure lifecycle status information for the target dynamic flow identifier.

[0244] The output module 1050 is used to generate and output target dynamic flow identifier management information, which includes the target dynamic flow identifier, the association relationship, and the life cycle status information.

[0245] It should be noted that the dynamic flow identifier processing device of this embodiment can execute any of the dynamic flow identifier processing methods in Embodiment 1. The specific implementation method and technical effect can be referred to Embodiment 1, and will not be repeated here.

[0246] Example 4 Figure 11 The diagram schematically illustrates a dynamic stream identifier processing apparatus according to Embodiment 4 of this application. This apparatus can be divided into one or more program modules. One or more program modules are stored in a storage medium and executed by one or more processors to complete the embodiments of this application. The program modules referred to in the embodiments of this application are a series of computer program instruction segments capable of performing specific functions. The following description will specifically introduce the functions of each program module in this embodiment.

[0247] like Figure 11As shown, the dynamic stream identifier processing device can be applied to edge nodes. The device 1100 includes a receiving module 1110, a parsing module 1120, an acquisition module 1130, an authentication module 1140, and a processing module 1150.

[0248] The receiving module 1110 is used to receive live stream processing events carrying target dynamic stream identifiers, wherein the live stream processing events include at least one of push stream access events, push stream transmission events, pull stream access events, pull stream transmission events, and attribute verification events.

[0249] The parsing module 1120 is used to parse the target dynamic flow identifier to obtain the scene identifier information corresponding to the target dynamic flow identifier.

[0250] The acquisition module 1130 is used to acquire the status information and business attribute information corresponding to the target dynamic flow identifier.

[0251] The authentication module 1140 is used to perform stream identification authentication on the live stream processing event based on the scene identification information, the status information and the business attribute information.

[0252] The processing module 1150 is used to perform access processing, distribution processing, termination processing or alarm processing on the live stream processing event based on the authentication result of the stream identifier authentication.

[0253] It should be noted that the dynamic flow identifier processing device of this embodiment can execute any of the dynamic flow identifier processing methods in embodiment two. The specific implementation method and technical effect can be referred to embodiment two, and will not be repeated here.

[0254] Example 5 Figure 12 This illustration schematically depicts the hardware architecture of a computer device according to Embodiment 5 of this application. In some embodiments, the computer device 10000 may be a smartphone, wearable device, tablet computer, personal computer, in-vehicle terminal, game console, virtual machine, workbench, digital assistant, set-top box, robot, or other terminal device. In other embodiments, the computer device 10000 may be a rack server, blade server, tower server, or cabinet server (including standalone servers or server clusters composed of multiple servers), etc. Figure 12 As shown, the computer device 10000 includes, but is not limited to: a memory 10010, a processor 10020, and a network interface 10030 that can communicate and be linked with each other via a system bus. Wherein: The memory 10010 includes at least one type of computer-readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 10010 may be an internal storage module of a computer device 10000, such as the hard disk or memory of the computer device 10000. In other embodiments, the memory 10010 may also be an external storage device of the computer device 10000, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 10000. Of course, the memory 10010 may also include both the internal storage module and the external storage device of the computer device 10000. In this embodiment, the memory 10010 is typically used to store the operating system and various application software installed on the computer device 10000, such as the program code of the method described in Embodiment 1 or 2. Furthermore, the memory 10010 can also be used to temporarily store various types of data that have been output or will be output.

[0255] In some embodiments, processor 10020 may be a central processing unit (CPU), controller, microcontroller, microprocessor, or other chip. Processor 10020 is typically used to control the overall operation of computer device 10000, such as performing control and processing related to data interaction or communication with computer device 10000. In this embodiment, processor 10020 is used to run program code stored in memory 10010 or process data.

[0256] Network interface 10030 may include a wireless network interface or a wired network interface, which is typically used to establish a communication link between computer device 10000 and other computer devices. For example, network interface 10030 is used to connect computer device 10000 to an external terminal via a network, establishing a data transmission channel and communication link between computer device 10000 and the external terminal. The network may be an intranet, the Internet, Global System for Mobile Communication (GSM), Wideband Code Division Multiple Access (WCDMA), 4G network, 5G network, Bluetooth, Wi-Fi, or other wireless or wired networks.

[0257] It should be pointed out that, Figure 12 Only computer devices with components 10010-10030 are shown; however, it should be understood that it is not required to implement all of the shown components, and more or fewer components may be implemented instead.

[0258] Example 6 This application also provides a computer-readable storage medium. The computer-readable storage medium can store computer instructions that, when executed by a processor, implement the methods in any of the above embodiments.

[0259] In this embodiment, the computer-readable storage medium includes flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the computer-readable storage medium can be an internal storage unit of a computer device, such as the hard disk or memory of the computer device. In other embodiments, the computer-readable storage medium can also be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device. Of course, the computer-readable storage medium can also include both the internal storage unit and the external storage device of the computer device. In this embodiment, the computer-readable storage medium is typically used to store the operating system and various application software installed on the computer device, such as the program code of the methods in Embodiments 1, 2, or 3. In addition, the computer-readable storage medium can also be used to temporarily store various types of data that have been output or will be output.

[0260] Example 7 This application also provides a computer program product, including a computer program, which, when executed by a processor, can implement the dynamic stream identifier processing method in any of the above embodiments.

[0261] It should be noted that the apparatus, computer equipment, computer-readable storage medium, and computer program product provided in the above embodiments belong to the same concept as those in the method embodiments. For details of their implementation, please refer to the method embodiments, which will not be repeated here.

[0262] The above embodiments are only used to illustrate the technical solutions of the embodiments of this application, and are not intended to limit them. Although the embodiments of this application have 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, and such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A dynamic stream identifier processing method, characterized in that, Applied to a live stream management system, the method includes: Obtain the special live streaming scene information corresponding to the target live streaming room and the business attribute information corresponding to the special live streaming scene information; Based on the specific live streaming scenario information, a target dynamic stream identifier is generated; Establish the association between the target dynamic flow identifier and the business attribute information; Configure lifecycle status information for the target dynamic stream identifier; Generate and output target dynamic flow identifier management information, which includes the target dynamic flow identifier, the association relationship, and the lifecycle status information.

2. The method according to claim 1, characterized in that, Based on the specific live streaming scenario information, a target dynamic stream identifier is generated, including: Determine the scene identification information corresponding to the special live streaming scene information; Obtain the live room identifier information and stream identifier generation time information of the target live room; Generate random identification information; Based on the scene identifier information, the live room identifier information, the stream identifier generation time information, and the random identifier information, a stream identifier to be verified is generated; Generate verification information based on the stream identifier to be verified; The verification information is combined with the stream identifier to be verified to obtain the target dynamic stream identifier.

3. The method according to claim 1, characterized in that, Establishing the association between the target dynamic flow identifier and the business attribute information includes: Lightweight attribute information and full attribute information are determined from the aforementioned business attribute information; Configure the lightweight attribute information to be obtainable from the target dynamic stream identifier; Establish a mapping relationship between the target dynamic stream identifier and the full set of attribute information; Generate mapping verification information based on the target dynamic flow identifier and the full attribute information; The mapping verification information is associated with the mapping relationship and stored. The mapping verification information is used to verify the consistency between the target dynamic stream identifier and the full attribute information.

4. The method according to claim 1, characterized in that, Configure lifecycle state information for the target dynamic stream identifier, including: Obtain the lifecycle rules corresponding to the specific live streaming scenario information; Based on the lifecycle rules, the validity period information and failure triggering conditions of the target dynamic flow identifier are determined; Based on the validity period information and the failure triggering conditions, the lifecycle status information is generated; The failure triggering conditions include at least one of the following: the target dynamic stream identifier exceeds its corresponding validity period, the live stream corresponding to the target live stream room ends, the live stream scene of the target live stream room is switched, and the attribute status corresponding to the business attribute information changes.

5. The method according to claim 1, characterized in that, The method further includes: When the target live streaming room is detected to have switched from the first live streaming scene to the second live streaming scene, a new dynamic stream identifier corresponding to the second live streaming scene is generated. Establish the association between the new dynamic stream identifier and the business attribute information corresponding to the second live streaming scenario; Update the lifecycle status information of the target dynamic flow identifier to an invalid state; Output the failure status information of the new dynamic flow identifier and the target dynamic flow identifier.

6. The method according to claim 1, characterized in that, The method further includes: Receive scene configuration data, wherein the scene configuration data includes at least one of scene identifier configuration data, stream identifier structure configuration data, attribute field configuration data, authentication rule configuration data, and lifecycle rule configuration data; Based on the scenario configuration data, generate scenario flow identifier management rules; Based on the aforementioned scene stream identifier management rules, dynamic stream identifier generation, attribute association, and lifecycle state configuration are performed for the corresponding special live streaming scenarios.

7. The method according to claim 1, characterized in that, The method further includes: When the lifecycle status information of the target dynamic flow identifier represents a failure status, the target dynamic flow identifier is added to the failure flow identifier queue. Based on the failure time information, the dynamic flow identifiers in the failure flow identifier queue are sorted; Based on the preset cleanup batch and data storage load status, the dynamic flow identifiers to be cleaned are determined from the failed flow identifier queue; Perform cleanup processing or backup-after cleanup processing on the dynamic stream identifier to be cleaned.

8. The method according to claim 1, characterized in that, Output target dynamic stream identifier management information, including: The target dynamic stream identifier and the lifecycle status information are output to the live streaming scheduling system so that the live streaming scheduling system can generate a push stream address containing the target dynamic stream identifier; The push address includes edge node address information, port information, the target dynamic stream identifier, authentication information, and stream identifier validity information.

9. The method according to claim 1, characterized in that, Output target dynamic stream identifier management information, including: Write the current active data corresponding to the target dynamic stream identifier into the first data storage unit; Write the full data corresponding to the target dynamic stream identifier into the second data storage unit; Write the log data corresponding to the target dynamic stream identifier into the third data storage unit; Write the mapping verification information corresponding to the target dynamic flow identifier and the business attribute information into the fourth data storage unit.

10. A dynamic stream identifier processing method, characterized in that, Applied to edge nodes, the method includes: Receive live stream processing events carrying the target dynamic stream identifier; Parse the target dynamic flow identifier to obtain the scene identifier information corresponding to the target dynamic flow identifier; Obtain the status information and service attribute information corresponding to the target dynamic flow identifier; Based on the scene identification information, the status information, and the business attribute information, the live stream processing event is authenticated using stream identification. Based on the authentication result of the stream identifier authentication, the live stream processing event is processed as an access process, a distribution process, a termination process, or an alarm process.

11. The method according to claim 10, characterized in that, After parsing the target dynamic flow identifier to obtain the scene identifier information corresponding to the target dynamic flow identifier, the method further includes: Based on the scene identification information, the live stream processing event corresponding to the live stream scene type is determined; Based on the live streaming scenario type, determine the processing channel corresponding to the live streaming processing event; The live stream processing events are assigned to the processing channel.

12. The method according to claim 10, characterized in that, Obtaining the status information and service attribute information corresponding to the target dynamic flow identifier includes: Query the local stream identifier status cache of the edge node; If available cached data corresponding to the target dynamic stream identifier exists in the local stream identifier status cache, the status information and / or the service attribute information are determined based on the available cached data. If the available cached data is not found in the local stream identifier status cache, a data query request is sent to the central computer room data system; Receive the query results returned by the central computer room data system, and determine the status information and / or the business attribute information based on the query results.

13. The method according to claim 10, characterized in that, Based on the scene identification information, the status information, and the business attribute information, stream identification authentication is performed on the live stream processing event, including: Based on the event type and processing stage of the live stream processing event, determine the target authentication stage corresponding to the target dynamic stream identifier; Based on the target authentication stage, the authentication data required for the flow identifier authentication is determined; Based on the authentication data, staged authentication is performed on the live stream processing event; The target authentication stage includes at least one of the following: pre-pull authentication stage, in-pull authentication stage, pre-pull authentication stage, in-pull authentication stage, and in-transmission authentication stage.

14. The method according to claim 10, characterized in that, Based on the scene identification information, the status information, and the business attribute information, stream identification authentication is performed on the live stream processing event, including: Determine whether the target dynamic stream identifier belongs to the blacklist stream identifier; If the target dynamic stream identifier belongs to the blacklist stream identifier, the live stream processing event is rejected and an abnormal request alarm message is generated; If the target dynamic stream identifier does not belong to the blacklist stream identifier, the stream identifier authentication continues to be performed based on the scenario identifier information, the status information, and the business attribute information.

15. The method according to claim 10, characterized in that, Based on the scene identification information, the status information, and the business attribute information, stream identification authentication is performed on the live stream processing event, including: When the live stream processing event is a push stream access event, the push stream address authentication information and timeliness information carried by the push stream access event are obtained, and the push stream access event is authenticated before push stream based on the target dynamic stream identifier, the push stream address authentication information and the timeliness information. When the live stream processing event is a push stream transmission event, the push stream terminal identification information corresponding to the push stream transmission event is obtained, and the push stream transmission event is authenticated during the push stream based on the binding relationship between the push stream terminal identification information and the target dynamic stream identifier.

16. The method according to claim 10, characterized in that, Based on the scene identification information, the status information, and the business attribute information, stream identification authentication is performed on the live stream processing event, including: When the live stream processing event is a pull stream access event, the viewing terminal identification information corresponding to the pull stream access event is obtained, the permission verification method corresponding to the scene identification information is determined, and the pull stream access event is authenticated before pull stream based on the viewing terminal identification information, the permission verification method and the business attribute information. When the live stream processing event is a pull stream transmission event, the timeliness authentication of the pull stream process corresponding to the pull stream transmission event is performed based on the status information.

17. The method according to claim 10, characterized in that, When the live stream processing event is an attribute verification event, stream identifier authentication is performed on the live stream processing event based on the scene identification information, the status information, and the business attribute information, including: Obtain the first attribute verification information corresponding to the target dynamic flow identifier. The first attribute verification information is generated based on the business attribute information obtained by local parsing or caching of the edge node. The second attribute verification information corresponding to the target dynamic flow identifier is obtained from the central computer room data system. The second attribute verification information is generated based on the business attribute information stored in the central computer room data system. Perform a consistency check on the first attribute verification information and the second attribute verification information; If the consistency check fails, the live stream transmission corresponding to the target dynamic stream identifier is terminated and an attribute anomaly alarm message is generated.

18. The method according to claim 10, characterized in that, Based on the authentication result of the stream identifier authentication, the live stream processing event is processed as follows: access processing, distribution processing, termination processing, or alarm processing, including: If the authentication result indicates that the authentication is successful, a live stream processing strategy is determined based on the business attribute information; Based on the live stream processing strategy, at least one of the following processes is performed on the live stream corresponding to the live stream processing event: access, transcoding, encryption, bitrate control, or distribution. If the authentication result indicates that the authentication has failed, the live stream processing event is terminated, and an alarm message corresponding to the reason for the authentication failure is generated.

19. The method according to claim 10, characterized in that, Obtaining the status information and service attribute information corresponding to the target dynamic flow identifier includes: Establish a status synchronization connection with the central computer room data system; The state change information is obtained through the state synchronization connection. The state change information includes at least one of the following: flow identifier failure status, attribute change information, and blacklisted flow identifier list. Based on the state change information, update the local stream identifier state cache; In the event of a detected interruption of the state synchronization connection, the live stream processing event is processed based on the local stream identifier state cache. When the state synchronization connection is restored, the full state information is obtained from the central computer room data system, and the local stream identifier state cache is updated based on the full state information.

20. A dynamic stream identifier processing device, characterized in that, The device, used in a live stream management system, includes: The acquisition module is used to acquire special live streaming scene information corresponding to the target live streaming room and business attribute information corresponding to the special live streaming scene information; The generation module is used to generate a target dynamic stream identifier based on the specific live streaming scenario information; The association module is used to establish the association relationship between the target dynamic flow identifier and the business attribute information; The configuration module is used to configure lifecycle status information for the target dynamic flow identifier; The output module is used to generate and output target dynamic flow identifier management information, which includes the target dynamic flow identifier, the association relationship, and the lifecycle status information.

21. A dynamic stream identifier processing device, characterized in that, Applied to edge nodes, the device includes: The receiving module is used to receive live stream processing events carrying the target dynamic stream identifier; The parsing module is used to parse the target dynamic flow identifier to obtain the scene identifier information corresponding to the target dynamic flow identifier; The acquisition module is used to acquire the status information and business attribute information corresponding to the target dynamic flow identifier; The authentication module is used to perform stream identifier authentication on the live stream processing event based on the scene identification information, the status information, and the business attribute information; The processing module is used to perform access processing, distribution processing, termination processing, or alarm processing on the live stream processing event based on the authentication result of the stream identifier authentication.

22. A computer device, characterized in that, include: At least one processor; and A memory communicatively connected to the at least one processor; wherein: The memory stores a computer program 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 to 19.

23. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 19.

24. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 19.

Images