Live broadcast stream state access method and device

Abstract

The embodiment of the invention provides a live broadcast stream state access method and device, computer equipment, a computer readable storage medium and a computer program product, and belongs to the technical field of live broadcast. The live broadcast stream state access method comprises the following steps: in response to a write-in request of live broadcast stream state data of a data write-in end, obtaining to-be-written first live broadcast stream state data; writing the first live broadcast stream state data into a plurality of storage middleware; in response to an access request of live broadcast stream state data of a data access end, respectively acquiring second live broadcast stream state data corresponding to the access request from the plurality of storage middleware; determining target live broadcast stream state data based on the plurality of second live broadcast stream state data; and returning the target live broadcast stream state data to the data access end. By writing the first live broadcast stream state data into the plurality of storage middleware, the situation that the live broadcast content cannot be normally played due to the fault of the single storage middleware can be reduced.

Description

Technical Field

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

[0002] In live streaming scenarios, the viewing address for a live stream is typically generated based on the live stream status data. To ensure the availability of the viewing address, a storage middleware is usually used to store the live stream status data and provide an access interface for upstream services to call.

[0003] However, in the actual process of accessing the live stream status data, the storage middleware is prone to failure, which may cause the upstream service to fail to obtain the viewing address of the live room correctly, thus preventing the live content from playing normally and resulting in a poor user experience.

[0004] 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

[0005] This application provides a method, apparatus, computer device, computer-readable storage medium, and computer program product for accessing the status of a live stream, in order to solve or alleviate one or more of the technical problems mentioned above.

[0006] One aspect of this application provides a method for accessing the status of a live stream, the method comprising: In response to the write request for live stream status data from the data writing end, obtain the first live stream status data to be written; The first live stream status data is written to multiple storage middleware respectively; In response to the access request for live stream status data from the data access terminal, the second live stream status data corresponding to the access request is obtained from the plurality of storage middleware respectively; Determine the target live stream status data based on multiple second live stream status data; The target live stream status data is returned to the data access terminal.

[0007] Optionally, the first live stream status data includes status data in multiple fields, and the first live stream status data is written to multiple storage middlewares, including: Configure the corresponding version number information for each of the multiple fields; The first live stream status data, configured with the version number information, is written to multiple storage middleware.

[0008] Optionally, the first live stream status data is written to multiple storage middleware, including: The first live stream status data is written to the plurality of storage middlewares through the live stream status data SDK; wherein, the live stream status data SDK includes: a plurality of interface modules that perform data writing operations for the plurality of storage middlewares respectively.

[0009] Optionally, each of the storage middlewares is deployed across multiple data nodes, including RocksDB and Redis. The method further includes: synchronizing the first live stream status data to the multiple data nodes where the storage middlewares are deployed; wherein, When the storage middleware is RocksDB, the first live stream status data is synchronized to the multiple data nodes where RocksDB is located through a data synchronization platform; When the storage middleware is Redis, the first live stream status data is synchronized to the multiple data nodes where Redis is located via a message queue.

[0010] Optionally, each field in the second live stream status data is associated with a corresponding status identifier, which is used to determine whether the status data of each field is correct; multiple sets of second live stream status data include multiple sets of status data under the same field; determining the target live stream status data based on multiple sets of second live stream status data includes: Based on the status identifier associated with multiple fields in multiple second live stream status data, the corresponding target field is determined from each group of identical fields in multiple second live stream status data; The target live stream status data is determined based on the status data of multiple target fields.

[0011] Optionally, the status identifier includes a first identifier and a second identifier; based on the status identifier associated with multiple fields in the multiple second live stream status data, the corresponding target field is determined from each group of identical fields in the multiple second live stream status data, including: In a set of identical fields, if the status identifier associated with multiple fields is the first identifier, obtain the version number information corresponding to the multiple fields whose status identifier is the first identifier; The field with the latest version number information is identified as the target field in a set of identical fields; or If, in a set of identical fields, there is only one field whose associated status identifier is the first identifier, then the field whose status identifier is the first identifier is identified as the target field in the set of identical fields. Assemble the status data of all target fields into the target live stream status data.

[0012] Optionally, the status identifier includes a first identifier and a second identifier; the method further includes: If, in a set of identical fields, the status identifier associated with multiple fields is the second identifier, then data access is determined to have failed. The system returns a message indicating that data access failed to the data access endpoint.

[0013] Another aspect of this application provides a live stream status access device, the device comprising: The acquisition module is used to respond to the write request of the live stream status data from the data writing end and acquire the first live stream status data to be written. The writing module is used to write the first live stream status data to multiple storage middleware respectively; The acquisition module is also used to respond to the access request for live stream status data from the data access terminal, and to acquire the second live stream status data corresponding to the access request from the plurality of storage middleware respectively; The determination module is used to determine the target live stream status data based on multiple second live stream status data. The return module is used to return the target live stream status data to the data access terminal.

[0014] 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 instructions that can be executed by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method as described above.

[0015] Another aspect of this application provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the method described above.

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

[0017] The embodiments of this application employing the above-described technical solution may have the following advantages: By writing the first live stream status data into multiple storage middleware, and retrieving corresponding second live stream status data from these middleware during data access, the target live stream status data is selected from among the second live stream status data. This reduces the likelihood of live stream content failing due to a single storage middleware malfunction, improves the availability of live stream status data, enhances the stability of live stream playback, and improves the user experience. Attached Figure Description

[0018] 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.

[0019] Figure 1 The diagram illustrates the operating environment of the live stream status access method according to Embodiment 1 of this application. Figure 2 A flowchart illustrating a live stream status access method according to Embodiment 1 of this application is shown schematically. Figure 3 Schematic illustration based on Figure 2 Flowchart of the sub-steps in step S202; Figure 4 Schematic illustration based on Figure 2 Flowchart of the sub-steps in step S206; Figure 5 Schematic illustration based on Figure 4 Flowchart of the sub-steps in step S400; Figure 6 The diagram illustrates a new flowchart of the live stream status access method according to Embodiment 1 of this application; Figure 7 The diagram illustrates an application example of the live stream status access method according to Embodiment 1 of this application. Figure 8 A block diagram schematically illustrates a live stream status access device according to Embodiment 2 of this application; and Figure 9 A schematic diagram of the hardware architecture of a computer device according to Embodiment 3 of this application is shown. Detailed Implementation

[0020] 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.

[0021] 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.

[0022] It should be noted that, in any stage of this application involving the collection, storage, use, transmission, and processing of data, each stage strictly adheres to the laws, regulations, industry standards, and regulatory requirements of the data source, usage location, and relevant countries and regions to ensure the legality and compliance of data activities. In the collection stage, the purpose, method, and scope of collection are clearly communicated to the data subject in a prominent manner. Collection is conducted only after obtaining the data subject's legal authorization, ensuring that the collection process follows the "minimum necessary" principle and does not exceed the scope of data collection. In the storage stage, storage periods are limited, and data is promptly deleted or anonymized / encrypted after the storage purpose is achieved. In the usage stage, a strict data security protection mechanism is implemented, using field-level desensitization technology and processing the original data according to preset desensitization rules. For different types of data, multiple desensitization strategies, such as data generalization, data anonymization, and data encryption, are employed to effectively mitigate the risk of sensitive information leakage and ensure that all data used is securely processed and desensitized, comprehensively protecting the rights and interests of data subjects and data security. In the transmission and processing stages, the confidentiality and security of data are ensured during transmission and processing.

[0023] 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.

[0024] First, a definition of the terminology used in this application is provided: Live stream status: A state machine mechanism used to record and describe various status information of the live stream in the live room.

[0025] Redis: An open-source, network-enabled, in-memory, persistent, log-structured key-value database written in ANSI C.

[0026] RocksDB: A high-performance, scalable, embedded, persistent, reliable, easy-to-use, and customizable key-value store.

[0027] Storage middleware: A middleware component that provides data read, write, and management capabilities between applications and the underlying storage system.

[0028] Field: The basic unit used to represent a specific attribute or data item in a data record.

[0029] SDK: Software Development Kit. A collection of tools used to build software with specific functions, which may include interface documentation, sample code, library files, etc., making it easy for developers to integrate specified functions or services into their applications.

[0030] Data node: refers to the physical server or logical unit that actually undertakes data storage and processing tasks in a distributed storage architecture. Multiple data nodes can be distributed in different data centers or clusters to improve the reliability and scalability of the system.

[0031] 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 live streaming scenarios, issuing a live stream viewing address is a fundamental capability. The live stream playback address is assembled from the stream state data of multiple live streams. A persistent middleware is used to persistently store the stream state data, while also providing a query interface. The query service can be deployed in a multi-active manner, including dual-datacenter or multi-datacenter deployments.

[0032] However, although a persistent middleware can enable data sharing and access across multiple data centers, we have found the following pain points that cannot be resolved in practice: First, if the single persistent middleware it relies on fails, the entire live streaming system will be unable to obtain the correct live stream status data, resulting in the live stream being unable to play.

[0033] Secondly, when the storage middleware performs data synchronization across multiple data centers, if there is a synchronization delay, some data centers may access outdated or incorrect data, resulting in incorrect playback addresses and preventing the live stream from playing.

[0034] To address this, this application provides a live stream status access technology solution. In this solution, considering the significant single point of failure risk associated with relying on a single storage middleware, the entire live stream status access system employs multi-data source storage for both data storage and access. Specifically, the upstream service updates stream status data simultaneously to multiple data sources, employing two storage middlewares: RocksDB and Redis. When providing data query services, both data storage middlewares can be accessed simultaneously, and the latest data is returned by merging them. To resolve the data synchronization latency issue in the data center, since the used storage middlewares are key-value systems, a timestamp version number can be added to the stream status data to identify its latest status. During dual-data source access, the data with the latest version number for the same key is retrieved, thus resolving the dual-data center data synchronization latency issue. By introducing multi-data source storage access and data version number capabilities, the entire live stream access system can automatically resolve single-storage system failures and internal storage system data latency issues, significantly improving the high availability of the live stream status system. See below for details.

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

[0036] like Figure 1 As shown, the runtime environment diagram includes: Service platform 2, clients (4A, 4B, ..., 4N).

[0037] Service platform 2 can connect to clients (4A, 4B, ..., 4N) via the network.

[0038] Service platform 2 can be a single server, a server cluster, or a cloud computing service center.

[0039] Service platform 2 can provide clients with services such as writing live stream status data and accessing live stream status data.

[0040] Service platform 2 may be located in a data center, such as a single location, or distributed across different geographical locations (e.g., multiple locations). Service platform 2 may provide services via a network. The network includes various network devices such as routers, switches, multiplexers, hubs, modems, bridges, repeaters, firewalls, proxy devices, and / or similar devices. The network may include physical links, such as coaxial cable links, twisted-pair cable links, fiber optic links, or combinations thereof, or wireless links, such as cellular links, satellite links, Wi-Fi links, etc.

[0041] Clients (4A, 4B, ..., 4N) can be configured to access the content and services of service platform 2. Clients (4A, 4B, ..., 4N) can include electronic devices with built-in or external display panels, such as mobile devices, tablets, laptops, workstations, virtual reality devices, gaming devices, digital streaming media devices, vehicle terminals, smart TVs, set-top boxes, etc., and can also include virtualized computing instances. Virtualized computing instances can include virtual machines, such as simulations of computer systems, operating systems, servers, etc. The computing device can load the virtual machine based on the virtual image and / or other data defining specific software (e.g., operating system, dedicated applications, servers) used for simulation. As the demand for different types of processing services changes, different virtual machines can be loaded and / or terminated on one or more computing devices.

[0042] A client (4A, 4B, ..., 4N) can be associated with one or more users. A single user can also use one or more of the clients (4A, 4B, ..., 4N) to access service platform 2. Clients (4A, 4B, ..., 4N) can travel to various locations and use different networks to access service platform 2.

[0043] The technical solution of this application will be described below through multiple embodiments, using service platform 2 as the implementing entity. It should be understood that these embodiments can be implemented in many different forms and should not be construed as being limited to the embodiments described herein.

[0044] Example 1 Figure 2 A flowchart illustrating a live stream status access method according to Embodiment 1 of this application is shown schematically.

[0045] like Figure 2 As shown, the live stream status access method may include steps S200~S208, wherein: Step S200: In response to the write request for live stream status data from the data writing end, obtain the first live stream status data to be written.

[0046] Step S202: Write the first live stream status data into multiple storage middleware respectively.

[0047] Step S204: In response to the access request for live stream status data from the data access terminal, the second live stream status data corresponding to the access request is obtained from the plurality of storage middleware respectively.

[0048] Step S206: Determine the target live stream status data based on multiple second live stream status data.

[0049] Step S208: Return the target live stream status data to the data access terminal.

[0050] The live stream status access method provided in this embodiment writes the first live stream status data into multiple storage middlewares. During data access, it retrieves multiple corresponding second live stream status data from these storage middlewares and filters out the target live stream status data from among them. This reduces the likelihood of live stream content failing due to a single storage middleware malfunction, improves the availability of live stream status data, enhances the stability of live stream playback, and improves the user experience.

[0051] The following combination Figure 2 The steps in steps S200 to S208, as well as other optional steps, are described in detail.

[0052] Step S200 In response to the write request for live stream status data from the data writing end, the first live stream status data to be written is obtained.

[0053] The data writing end can include various business servers of the live streaming platform, such as the broadcasting server, the streaming push server, and the scheduling server. The data writing end can continuously and in real-time report the status data of the first live stream during the live broadcast. Upon receiving the data writing request, the request content can be parsed and verified through a preset interface or SDK component to obtain the status data of the first live stream.

[0054] The first live stream status data may include multiple fields such as live stream identifier, origin IP, heartbeat, resolution, frame rate, bitrate, streaming status, and disconnection alarm. For example, when a broadcaster starts a live stream in room A, the broadcast service (i.e., the data writer) can send a write request for live stream status data to the live stream status access system. This write request may include information such as the unique identifier of live stream A (room_id), the currently used stream address (stream_url), bitrate, and live stream status (is_live).

[0055] In practical applications, the data writing end is not limited to a single service module. Specifically, multiple business modules supported by the deployment architecture can simultaneously report write requests. For example, write requests from both the live streaming server and the push streaming server can be received simultaneously through asynchronous access, message queues, HTTP APIs, etc., ensuring the stability and high throughput of data writing.

[0056] Step S202 The first live stream status data is written to multiple storage middleware respectively.

[0057] After acquiring the initial live stream status data, to improve data storage reliability and the fault tolerance of the data access system, the initial live stream status data is written to multiple storage middleware. For example, if only Redis is used as a single storage middleware, the live stream status data will be inaccessible if the Redis service fails to respond to requests due to memory overflow or crash, thus affecting live stream playback. However, if the initial live stream status data is written to both Redis and RocksDB middleware simultaneously, if Redis fails, the system can switch to RocksDB to read the data, ensuring the continuous availability of the live stream status data and preventing live stream interruption. Therefore, by writing data to multiple storage middleware, not only is the fault tolerance of the data access system enhanced, but the stability and reliability of data access are also improved.

[0058] Multiple storage middleware can include high-performance disk-based key-value databases (such as RocksDB), in-memory key-value stores (such as Redis), relational databases (such as MySQL and PostgreSQL), or document-oriented databases (such as MongoDB). Different types of storage middleware have different access speeds and storage characteristics. In specific implementations, the appropriate storage middleware can be selected according to the actual scenario, and no further restrictions are imposed here.

[0059] Step S204 In response to the access request for live stream status data from the data access terminal, the second live stream status data corresponding to the access request is obtained from the plurality of storage middleware respectively.

[0060] The data access endpoint can include modules such as the playback server, scheduling server, and operation and maintenance monitoring server in the live streaming platform. These modules need to read the status data of the live stream in real time during live playback, stream status display, or backend management. Access requests for live stream status data can include live room identifiers, stream identifiers, or other data that can uniquely identify a live stream.

[0061] In practical applications, upon receiving an access request for live stream status data, queries can be initiated concurrently to multiple storage middleware. For example, if Redis and RocksDB are currently deployed, query commands can be sent to both middleware simultaneously to obtain the latest second live stream status data. Concurrent queries can minimize response time; even if one storage middleware experiences an error or delay, valid data can still be obtained from other middleware.

[0062] Step S206 The target live stream status data is determined based on multiple second live stream status data.

[0063] Since the second live stream status data is obtained from multiple storage middleware, it is necessary to determine the target live stream status data to be returned to the data access client from among these multiple second live stream status data. In practical applications, if the second live stream status data returned by a certain middleware includes exception information such as timeout errors or read failures, then the second live stream status data returned by that middleware is considered invalid. If the second live stream status data returned by a certain middleware is normal and does not contain error codes or status exceptions, then it can be considered valid data. Furthermore, one of the valid second live stream status data can be selected as the target live stream status data from among the multiple valid second live stream status data.

[0064] Step S208 The target live stream status data is returned to the data access terminal.

[0065] After determining the target live stream status data, this data is returned to the data access client as a response. By returning the target live stream status data, the data access client can obtain the current valid status information of the live stream. In practical applications, the process of returning the target live stream status data can be accomplished through predefined interfaces, such as RESTful API calls or RPC request responses. To ensure the stability and security of data transmission, methods such as timeout retries and data encryption can be used for data transmission.

[0066] In an optional embodiment, the first live stream status data includes status data in multiple fields, such as... Figure 3 As shown, step S202 includes: Step S300: Configure the corresponding version number information for each of the multiple fields.

[0067] Step S302: Write the first live stream status data with the configured version number information into multiple storage middleware respectively.

[0068] The status data across multiple fields can include live stream identification information, streaming status, resolution parameters, origin server network information, etc. To improve the consistency and availability of status data across multiple data sources, a corresponding version number is configured for each field when writing the first live stream status data. For example, when the same live stream status data is written to storage middleware in different data centers, network jitter, synchronization latency, or differences in write performance may cause time differences or data loss in the data status of each data center. By pre-configuring version number information for each field, the field data with the newest version number can be identified during the data access phase, thereby avoiding the generation of incorrect playback addresses due to reading old data.

[0069] In this embodiment, by configuring corresponding version number information for each field, the update time of each field can be accurately identified, ensuring that when reading data from multiple data sources in the future, the latest status of each field can be determined based on the version number, thereby further improving the fault resistance and high availability of the live stream status access system.

[0070] In an optional embodiment, the first live stream status data is written to multiple storage middleware, including: The first live stream status data is written to the plurality of storage middlewares through the live stream status data SDK; wherein, the live stream status data SDK includes: a plurality of interface modules that perform data writing operations for the plurality of storage middlewares respectively.

[0071] The live stream status data SDK has a unified data writing interface. Internally, the SDK is configured with multiple interface modules adapted to different storage middleware for write operations. For example, when the live streaming platform's server reports the first live stream status data indicating a change in the status of a live room, the SDK first performs basic format conversion and field validation on the data. Then, it can synchronously write the data to multiple storage middlewares by calling the interface modules configured for RocksDB and Redis in parallel.

[0072] In some embodiments, the live stream status data SDK may also include an exception handling module. This module can handle scenarios where writes to a specific storage middleware fail, thereby ensuring the stability of the write process. For example, when writing the first live stream status data for live room A, the live stream status data SDK concurrently writes the first live stream status data to Redis and RocksDB. If, due to network jitter or a Redis service instance crash, the Redis write fails, the exception handling module can immediately capture the exception and execute a preset fault handling strategy. For instance, after detecting a Redis write failure, it first retryes the write operation several times. If the retry still fails, it skips the write to Redis, only writes the data to RocksDB, and records the exception event in the log. The live stream status data SDK continues to report successful write statuses to upstream services, preventing the overall write operation from failing due to a single storage middleware write failure, thus improving the reliability of data writing.

[0073] In this embodiment, by calling multiple write interface modules for different storage middleware through the live stream status data SDK, the differences in write operations between the various storage middlewares can be masked, making the data writing process more efficient and stable.

[0074] In an optional embodiment, each of the storage middlewares is deployed across multiple data nodes, including RocksDB and Redis. The method further includes: synchronizing the first live stream status data to the multiple data nodes deployed on the storage middlewares; wherein, When the storage middleware is RocksDB, the first live stream status data is synchronized to the multiple data nodes where RocksDB is located through a data synchronization platform; When the storage middleware is Redis, the first live stream status data is synchronized to the multiple data nodes where Redis is located via a message queue.

[0075] Multiple data nodes can include different data centers, servers, or clusters, forming a distributed storage structure. To ensure the consistency and real-time performance of written data across different data nodes, it is necessary to synchronize the data to all deployed nodes of the corresponding middleware after writing the first live stream status data.

[0076] For example, when a RocksDB storage middleware is deployed in the main data center (e.g., a data center deployed in location A), after completing the write operation of the first live stream status data, the data synchronization platform can be further triggered to perform a data synchronization operation to synchronize the first live stream status data to other backup data centers where the RocksDB storage middleware is located (e.g., data centers deployed in different regions B and C). Specifically, the Binlog listening module inside the data synchronization platform can be used to capture the change events written by RocksDB and generate corresponding data synchronization tasks. The data synchronization tasks will be automatically pushed to the RocksDB storage middleware deployed in the backup data centers. For example, when the broadcaster starts the live stream, the RocksDB in the main data center writes the first live stream status data with room_id "room123". The data synchronization platform will synchronize this data to the RocksDB nodes in the two remote backup data centers in locations B and C, so that any business request accessing these data centers can read the latest first live stream status data.

[0077] For example, with Redis as the storage middleware, the main data center (e.g., the data center deployed in location A) writes the first live stream status data to its local Redis using the live stream status data SDK, simultaneously generating a corresponding data change message and sending this message to a pre-defined message queue (e.g., Kafka, RocketMQ). Other data centers (e.g., locations B and C) can subscribe to the change messages in this message queue, receive them in real time, and write the message content to their respective Redis databases. This achieves synchronized updates of Redis data across multiple data centers, ensuring that business requests accessing Redis in any data center can obtain the latest live stream status data.

[0078] In this embodiment, the reliability of data storage is improved by synchronizing live stream status data to storage middleware deployed on multiple data nodes. Based on the data synchronization platform and message queue, the first live stream status data written to RocksDB and Redis is synchronized to multiple other data nodes where RocksDB and Redis reside, ensuring that live streaming service requests can obtain the latest live stream status data from storage middleware in any data center, further improving the fault tolerance and high availability of the live stream status access system.

[0079] In an optional embodiment, each field in the second live stream status data is associated with a corresponding status identifier, which is used to determine whether the status data of each field is correct; multiple sets of the second live stream status data include multiple sets of status data under the same field; such as Figure 4 As shown, step S206 includes: Step S400: Based on the status identifier associated with multiple fields in the multiple second live stream status data, determine the corresponding target field from each group of identical fields in the multiple second live stream status data.

[0080] Step S402: Determine the target live stream status data based on the status data of multiple target fields.

[0081] For each identical field in the multiple second live stream status data returned by different storage middlewares, the validity of the data for that field can be determined by the status identifier associated with each field. This allows for the selection of the final target field from among the valid fields. Filtering out invalid fields ensures the accuracy and reliability of the target field. Furthermore, by summarizing and integrating the status data of multiple target fields, accurate and valid target live stream status data is obtained and returned as the final query result to the data access client.

[0082] In practical applications, the selected target fields in each group can be assembled according to a preset field structure to construct the target live stream status data. The field assembly process can be based on predefined field templates, such as fields like: live room identifier, push status, resolution, and origin IP, and then the values ​​of the corresponding target fields can be uniformly filled in according to the field names.

[0083] For example, if the "bitrate" field in the second live stream status data is returned in both storage middleware (such as RocksDB and Redis), and the status indicator of the "bitrate" field in RocksDB indicates that the stream status data for this field is valid, while the status indicator of the "bitrate" field in Redis indicates that the stream status data for this field is invalid, then the "bitrate" in RocksDB can be determined as the target field. Similarly, for other fields such as "frame rate" and "stream status," the same judgment method is used to determine multiple target fields to obtain the target live stream status data.

[0084] In this embodiment, by configuring a status identifier for each field in the second live stream status data, and filtering out the target field from multiple identical fields based on the status identifier, the filtering of identical fields from multiple data sources can be achieved, thereby improving the accuracy and reliability of the target live stream status data.

[0085] In an optional embodiment, the status identifier includes a first identifier and a second identifier; such as Figure 5 As shown, step S400 includes: Step S500: In a set of identical fields, if the status identifier associated with multiple fields is the first identifier, obtain the version number information corresponding to the multiple fields whose status identifier is the first identifier.

[0086] Step S502: The field with the latest version number information is identified as the target field in a group of identical fields. Or Step S504: In a set of identical fields, if there is only one field whose associated status identifier is the first identifier, then the field whose status identifier is the first identifier is determined as the target field in the set of identical fields.

[0087] Step S506: Assemble the status data of all target fields into the target live stream status data.

[0088] When multiple fields within a set of identical fields all have the first status identifier (e.g., "valid"), it indicates that all of these identical fields are currently available data. In this case, to avoid data conflicts or overwriting, version number comparisons are needed to further filter out the latest and valid target field. In practical applications, the version number can be automatically generated from the timestamp accompanying the data when it was written to the field. A uniform format can be used to record the field version number, such as "version=202506271130", or a long integer timestamp "timestamp=1722067800000" can be used to represent the data generation time. For example, if the version number information of the "Push Stream Status" field of a certain live streaming room is "v100" and the associated status identifier is the first status recorded in RocksDB, while the version number information of the corresponding field in Redis is "v102" and the associated status identifier is also the first status, then by comparing the version number information, the field with the latest version number information (i.e. "v102") is determined as the target field in the same field group ("Push Stream Status" field), and is used to assemble it into the final target live streaming status data.

[0089] When only one field in a set of identical fields has the first status identifier, it indicates that only the field with the first status identifier is reliable, while the others are invalid or unavailable. In this case, the unique valid field can be directly selected as the target field. For example, when retrieving the field "clarity," if RocksDB returns the first status identifier while Redis returns the second status identifier (such as "invalid" or "0"), then "clarity" returned by RocksDB can be directly selected as the target field. Subsequently, the selected target fields from multiple sets of identical fields are assembled to generate the final target live stream status data. For example, if the target fields include "stream identifier," "clarity," "bitrate," and "stream status," these fields can be merged according to a preset format into complete target live stream status data and returned to the data access client.

[0090] In this embodiment, multiple target fields are selected from multiple sets of identical fields using status identifiers and version number information to construct target live stream status data. Even when multiple data sources have some anomalies or synchronization delays, the accuracy and timeliness of the target live stream status data can still be guaranteed, further improving the fault resistance and high availability of the live stream status access system.

[0091] In an optional embodiment, the status identifier includes a first identifier and a second identifier; such as Figure 6 As shown, the method further includes: In step S600, if multiple fields in a set of identical fields have the same status identifier as the second identifier, it is determined that the data access has failed.

[0092] Step S602: Return the data access failure information to the data access terminal.

[0093] Due to data synchronization failures, data loss, or other reasons, multiple fields in a set of identical fields may display the second identifier, indicating that the field is invalid across all data sources. For example, if the "bitrate" field in the second live stream status data read from both RocksDB and Redis data sources displays the second identifier, it means that the stream status data for this field is invalid, confirming a data access failure. In some embodiments, the information indicating a data access failure may include an error code indicating the field access failure, the name of the failed field, and a description of the reason for the failure. For instance, when a third-party platform queries the status of a live stream via an API interface, if a field such as "bitrate" cannot be retrieved due to anomalies in all data sources, it can return the error code "FIELD_NOT_AVAILABLE" and the failed field "bitrate" to allow upstream services to take appropriate action (e.g., retry, downgrade display, or notify the user of a current live stream anomaly).

[0094] In this embodiment, by determining that data access has failed when all status identifiers in the same field are the second identifier, and promptly returning the failure information to the data access end, the assembly process of the target live stream status data can be terminated in a timely manner when multiple fields are unavailable. This avoids returning incorrect or incomplete data results, further improving the accuracy of data access.

[0095] To make this application easier to understand, the following is combined with... Figure 7 An example application is provided.

[0096] S11, obtain the live stream status data, and update the live stream status data to the live stream status data write SDK.

[0097] S12, the live stream status data writing SDK writes the live stream status data to both RocksDB and Redis storage middleware simultaneously.

[0098] S13, when querying data in the live stream status access system, the live stream status data is obtained from RocksDB and Redis respectively.

[0099] In this exemplary application, by writing the live stream status data to both RocksDB and Redis storage middleware, and retrieving multiple sets of live stream status data from each middleware during data access, the likelihood of live stream content failing due to a single storage middleware failure can be reduced. This improves the availability of live stream status data, thereby enhancing the stability of live stream playback and improving the user experience.

[0100] Example 2 Figure 8 The diagram schematically illustrates a live stream status access device according to Embodiment 2 of this application. This device 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 embodiment of this application. The program module referred to in this embodiment is a series of computer program instruction segments capable of performing a specific function. The following description will specifically introduce the function of each program module in this embodiment. For example... Figure 8 As shown, the device 1000 may include: an acquisition module 1010, a writing module 1020, a determination module 1030, and a return module 1040, wherein: The acquisition module 1010 is used to acquire the first live stream status data to be written in response to the write request of the live stream status data from the data writing end.

[0101] The writing module 1020 is used to write the first live stream status data to multiple storage middleware respectively.

[0102] The acquisition module 1010 is also used to respond to the access request for live stream status data from the data access terminal and acquire the second live stream status data corresponding to the access request from the plurality of storage middleware respectively.

[0103] The determination module 1030 is used to determine the target live stream status data based on multiple second live stream status data.

[0104] The return module 1040 is used to return the target live stream status data to the data access terminal.

[0105] In an optional embodiment, the first live stream status data includes status data of multiple fields, and the first live stream status data is written to multiple storage middlewares, including: Configure the corresponding version number information for each of the multiple fields; The first live stream status data, configured with the version number information, is written to multiple storage middleware.

[0106] In an optional embodiment, the first live stream status data is written to multiple storage middleware, including: The first live stream status data is written to the plurality of storage middlewares through the live stream status data SDK; wherein, the live stream status data SDK includes: a plurality of interface modules that perform data writing operations for the plurality of storage middlewares respectively.

[0107] In an optional embodiment, each of the storage middlewares is deployed across multiple data nodes, including RocksDB and Redis. The method further includes: synchronizing the first live stream status data to the multiple data nodes deployed on the storage middlewares; wherein, When the storage middleware is RocksDB, the first live stream status data is synchronized to the multiple data nodes where RocksDB is located through a data synchronization platform; When the storage middleware is Redis, the first live stream status data is synchronized to the multiple data nodes where Redis is located via a message queue.

[0108] In an optional embodiment, each field in the second live stream status data is associated with a corresponding status identifier, which is used to determine whether the status data of each field is correct; the multiple sets of second live stream status data include multiple sets of status data under the same field; determining the target live stream status data based on the multiple sets of second live stream status data includes: Based on the status identifier associated with multiple fields in multiple second live stream status data, the corresponding target field is determined from each group of identical fields in multiple second live stream status data; The target live stream status data is determined based on the status data of multiple target fields.

[0109] In an optional embodiment, the status identifier includes a first identifier and a second identifier; based on the status identifier associated with multiple fields in the multiple second live stream status data, the corresponding target field is determined from each group of identical fields in the multiple second live stream status data, including: In a set of identical fields, if the status identifier associated with multiple fields is the first identifier, obtain the version number information corresponding to the multiple fields whose status identifier is the first identifier; The field with the latest version number information is identified as the target field in a set of identical fields; or If, in a set of identical fields, there is only one field whose associated status identifier is the first identifier, then the field whose status identifier is the first identifier is identified as the target field in the set of identical fields. Assemble the status data of all target fields into the target live stream status data.

[0110] In an optional embodiment, the status identifier includes a first identifier and a second identifier; the device 1000 is further configured to: If, in a set of identical fields, the status identifier associated with multiple fields is the second identifier, then data access is determined to have failed. The system returns a message indicating that data access failed to the data access endpoint.

[0111] Example 3 Figure 9 This illustration schematically shows a hardware architecture diagram of a computer device 10000 suitable for implementing a live stream status access method according to Embodiment 3 of this application. In some embodiments, the computer device 10000 may be a terminal device such as a smartphone, wearable device, tablet computer, personal computer, in-vehicle terminal, game console, virtual device, workbench, digital assistant, set-top box, robot, etc. In other embodiments, the computer device 10000 may be a rack server, blade server, tower server, or cabinet server (including independent servers or server clusters composed of multiple servers), etc. Figure 9 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 for the live stream status access method. In addition, the memory 10010 can also be used to temporarily store various types of data that have been output or will be output.

[0112] 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.

[0113] 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.

[0114] It should be pointed out that, Figure 9 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.

[0115] In this embodiment, the live stream status access method stored in memory 10010 can also be divided into one or more program modules and executed by one or more processors (such as processor 10020) to complete the embodiment of this application.

[0116] Example 4 This application also provides a computer-readable storage medium storing a computer program thereon, wherein the computer program, when executed by a processor, implements the steps of the live stream state access method in the embodiments.

[0117] 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 may 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 may 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 may 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 live stream status access method in this embodiment. 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.

[0118] Example 5 This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods described in the above embodiments.

[0119] Obviously, those skilled in the art should understand that the modules or steps of the embodiments of this application described above can be implemented using general-purpose computer devices. They can be centralized on a single computer device or distributed across a network of multiple computer devices. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computer device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the embodiments of this application are not limited to any particular combination of hardware and software.

[0120] It should be noted that the above are merely preferred embodiments of this application and do not limit the scope of patent protection of this application. Any equivalent structural or procedural changes made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of this application.

Claims

1. A method for accessing the status of a live stream, characterized in that, The method includes: In response to the write request for live stream status data from the data writing end, obtain the first live stream status data to be written; The first live stream status data is written to multiple storage middleware respectively; In response to the access request for live stream status data from the data access terminal, the second live stream status data corresponding to the access request is obtained from the plurality of storage middleware respectively; Determine the target live stream status data based on multiple second live stream status data; The target live stream status data is returned to the data access terminal.

2. The method according to claim 1, characterized in that, The first live stream status data includes status data in multiple fields. The first live stream status data is written to multiple storage middlewares, including: Configure the corresponding version number information for each of the multiple fields; The first live stream status data, configured with the version number information, is written to multiple storage middleware.

3. The method according to claim 2, characterized in that, The first live stream status data is written to multiple storage middleware, including: The first live stream status data is written to the plurality of storage middlewares through the live stream status data SDK; wherein, the live stream status data SDK includes: a plurality of interface modules that perform data writing operations for the plurality of storage middlewares respectively.

4. The method according to claim 1, characterized in that, Each of the aforementioned storage middleware is deployed across multiple data nodes, including RocksDB and Redis. The method further includes: synchronizing the first live stream status data to the multiple data nodes deployed on the storage middleware; wherein... When the storage middleware is RocksDB, the first live stream status data is synchronized to the multiple data nodes where RocksDB is located through a data synchronization platform; When the storage middleware is Redis, the first live stream status data is synchronized to the multiple data nodes where Redis is located via a message queue.

5. The method according to claim 2, characterized in that, Each field in the second live stream status data is associated with a corresponding status identifier, which is used to determine whether the status data of each field is correct. Multiple sets of second live stream status data include multiple sets of status data with the same field; The target live stream status data is determined based on multiple second live stream status data, including: Based on the status identifier associated with multiple fields in multiple second live stream status data, the corresponding target field is determined from each group of identical fields in multiple second live stream status data; The target live stream status data is determined based on the status data of multiple target fields.

6. The method according to claim 5, characterized in that, The status identifier includes a first identifier and a second identifier; based on the status identifier associated with multiple fields in the multiple second live stream status data, the corresponding target field is determined from each group of identical fields in the multiple second live stream status data, including: In a set of identical fields, if the status identifier associated with multiple fields is the first identifier, obtain the version number information corresponding to the multiple fields whose status identifier is the first identifier; The field with the latest version number information is identified as the target field in a set of identical fields; or If, in a set of identical fields, there is only one field whose associated status identifier is the first identifier, then the field whose status identifier is the first identifier is identified as the target field in the set of identical fields. Assemble the status data of all target fields into the target live stream status data.

7. The method according to claim 5, characterized in that, The status identifier includes a first identifier and a second identifier; the method further includes: If, in a set of identical fields, the status identifier associated with multiple fields is the second identifier, then data access is determined to have failed. The system returns a message indicating that data access failed to the data access endpoint.

8. A live stream status access device, characterized in that, The device includes: The acquisition module is used to respond to the write request of the live stream status data from the data writing end and acquire the first live stream status data to be written. The writing module is used to write the first live stream status data to multiple storage middleware respectively; The acquisition module is also used to respond to the access request for live stream status data from the data access terminal, and to acquire the second live stream status data corresponding to the access request from the plurality of storage middleware respectively; The determination module is used to determine the target live stream status data based on multiple second live stream status data. The return module is used to return the target live stream status data to the data access terminal.

9. 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 instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 7.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method described in claims 1 to 7.

Images