Method for managing live segments, related apparatus and computer program product

Abstract

This application provides a method, related apparatus, and computer program product for managing live stream segments. The application acquires live stream segments generated from a live stream; determines a target threshold for the live stream based on its live stream status information, which includes at least one of the following: live stream duration, live stream popularity, and live stream segment delivery rate; in response to a target number of received, unindexed live stream segments being greater than or equal to the target threshold, generates an index file and descriptive information for the unindexed live stream segments, the descriptive information indicating the time range and / or quantity range of the live stream segments included in the index file; provides the index file and descriptive information to an index storage; and in response to continued receiving of unindexed live stream segments after the index file is generated, jumps to executing the determination of the target threshold for the live stream based on its live stream status information. This improves the performance of live stream segment management.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, electronic device, computer-readable medium, and computer program product for managing live broadcast segments. Background Technology

[0002] With the rapid development of internet technology, live streaming technology has gradually become an important online interaction method and has been widely used in entertainment, education, commerce and other fields.

[0003] However, with the increasing richness and diversity of live streaming content, users' needs for watching live streams have also become more diverse. In practical applications, due to factors such as time conflicts, network limitations, or personal schedules, users are often unable to participate in or watch live streams in real time. At the same time, many users want to be able to repeatedly watch content they are interested in, which has led to a growing demand for accessing and rewatching historical live stream content. To meet these needs, current live streaming platforms have launched live stream recording services, allowing users to flexibly and repeatedly watch previously streamed content through recorded live streams, thus improving the user experience.

[0004] Against this backdrop, how to store recorded live content at a lower cost and manage the recorded live content more effectively and with higher quality is a matter of concern and urgent need. Summary of the Invention

[0005] This application provides a method, apparatus, electronic device, computer-readable storage medium, and computer program product for managing live stream segments. These methods not only improve query efficiency when searching for live stream segments using index files by allowing the creation of multiple index files to segmentally correspond to and indicate live stream segments, but also balance the relationship between index efficiency and index file size by dynamically adjusting the number of live stream segments included in and targeted by the index files, thereby improving the overall management performance of live stream segments.

[0006] One aspect of this application provides a method for managing live stream segments, comprising: acquiring live stream segments generated for a live stream; determining a target threshold for the live stream based on live stream status information, wherein the live stream status information includes at least one of the following: live stream duration, live stream popularity, and live stream segment delivery rate; generating an index file and descriptive information for the unindexed live stream segments in response to a target number of received unindexed live stream segments being greater than or equal to the target threshold, wherein the descriptive information indicates the time range and / or quantity range of the live stream segments included in the index file; providing the index file and descriptive information to an index storage; and, in response to receiving unindexed live stream segments after generating the index file, jumping to the process of determining the target threshold for the live stream based on the live stream status information.

[0007] Another aspect of this application provides an apparatus for managing live stream segments, comprising: a live stream segment receiving module configured to acquire live stream segments generated for a live stream; a target threshold determination module configured to determine a target threshold for a live stream based on live stream status information, wherein the live stream status information includes at least one of the following: live stream duration, live stream popularity, and live stream segment delivery rate; a first index building module configured to generate an index file for the unindexed live stream segments and descriptive information of the index file in response to a target number of received unindexed live stream segments being greater than or equal to the target threshold, wherein the descriptive information indicates the time range and / or quantity range of the live stream segments included in the index file; an index storage module configured to provide the index file and descriptive information to an index storage; and an execution jump module configured to jump to the execution of determining the target threshold for the live stream based on the live stream status information in response to the continued receipt of unindexed live stream segments after the index file is generated.

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

[0009] Another aspect of this application provides a computer-readable storage medium having computer program instructions stored thereon, which can be executed by a processor to implement the method for managing live broadcast segments as provided above.

[0010] Another aspect of this application is a computer program product that includes a computer program having computer program instructions stored thereon, which, when executed by a processor, can implement the method for managing live broadcast segments as provided above.

[0011] The solution provided in this application involves: acquiring live segments generated for a live stream; determining a target threshold for the live stream based on its live stream status information, wherein the live stream status information includes at least one of the following: live stream duration, live stream popularity, and live segment delivery rate; generating an index file and descriptive information for the unindexed live segments in response to the target number of received, unindexed live segments being greater than or equal to the target threshold, wherein the descriptive information indicates the time range and / or quantity range of the live segments included in the index file; providing the index file and descriptive information to the index storage; and jumping to the determination of the target threshold for the live stream based on its live stream status information in response to the continued receipt of unindexed live segments after the index file is generated. This not only improves query efficiency when querying live segments using index files by allowing the creation of multiple index files to segmentally correspond to and indicate live segments, but also balances the relationship between index efficiency and index file size by dynamically adjusting the number of live segments included and targeted in the index file, thereby improving the overall management performance of live segments. Attached Figure Description

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

[0013] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0014] Figure 1 A flowchart illustrating a process for managing live stream segments, as provided in one embodiment of this application;

[0015] Figure 2 A flowchart illustrating a process for providing a live broadcast segment, as provided in one embodiment of this application;

[0016] Figure 3 A flowchart illustrating a process for managing live stream segments in a specific application scenario, provided as an embodiment of this application;

[0017] Figure 4 A schematic diagram of the structure of an apparatus for managing live broadcast segments provided in an embodiment of this application;

[0018] Figure 5 This is a schematic diagram of the structure of an electronic device suitable for implementing the solutions in the embodiments of this application.

[0019] The same or similar reference numerals in the accompanying drawings represent the same or similar parts. Detailed Implementation

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

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

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

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

[0024] As discussed above, after recording live content, how to store it at a lower cost and manage the recorded live content more effectively and with higher quality is a matter of concern and urgent need.

[0025] In some solutions, after recording the live stream as a file, it is often saved as a complete streaming media file. However, this approach not only consumes significant storage resources but also makes it difficult for users to quickly locate and extract content segments of interest.

[0026] To improve upon this approach, some solutions store the live stream as "live segments." This involves breaking the live stream down into numerous independent segments and then indexing (or indexing information) each segment, allowing users to quickly locate the live content they need or are interested in. However, in this approach, the index (indexing information) is typically built for all live segments as a whole (e.g., using the same index file to create and store the indexing information for all live segments). This not only potentially wastes indexing resources unnecessarily but also makes it difficult to efficiently complete the indexing process when extracting specific live segments, hindering timely and efficient responses to user requests.

[0027] To address this, this application provides a method for managing live stream segments. The method acquires live stream segments generated for a live stream; determines a target threshold for the live stream based on its live stream status information, wherein the live stream status information includes at least one of the following: live stream duration, live stream popularity, and live stream segment delivery rate; in response to a target number of received, unindexed live stream segments being greater than or equal to the target threshold, generates an index file and descriptive information for the unindexed live stream segments, wherein the descriptive information indicates the time range and / or quantity range of the live stream segments included in the index file; provides the index file and descriptive information to an index storage; and in response to continued receiving of unindexed live stream segments after the index file is generated, jumps to executing the determination of the target threshold for the live stream based on the live stream status information. Therefore, this method not only improves query efficiency when querying live stream segments using index files by allowing the creation of multiple index files to segmentally correspond to and indicate live stream segments, but also balances the relationship between index efficiency and index file size by dynamically adjusting the number of live stream segments included and targeted in the index file, thereby improving the overall management performance of live stream segments.

[0028] In practical scenarios, the execution entity of this method can be a user device, a device composed of a user device and a network device integrated through a network, or an application running on the aforementioned devices. User devices include, but are not limited to, various terminal devices such as computers, mobile phones, tablets, smartwatches, and wristbands. Network devices include, but are not limited to, network hosts, single network servers, multiple network server sets, or cloud computing-based computer sets. Here, the cloud consists of a large number of hosts or network servers based on cloud computing. Cloud computing is a type of distributed computing, consisting of a virtual computer composed of a group of loosely coupled computer sets.

[0029] When the executing entity is software, it can be installed in the electronic devices listed above. It can be implemented as multiple software programs or software modules, or as a single software program or software module, without specific limitations.

[0030] Figure 1 The present application illustrates a process 100 for managing live stream segments, which includes at least the following processing steps:

[0031] (Step) S101, Obtain the live stream segments generated for the live stream;

[0032] In the embodiments of this application, considering that storing live stream segments often requires strong computing power (e.g., encoding the live stream to generate live stream segments) and storage capacity, the "server" is chosen as the execution subject for discussion, for example, the execution subject of process 100 could be the live stream server of a live streaming platform. Furthermore, as discussed above, if user devices also have corresponding computing power and permissions, they can also serve as the "execution subject," and this application does not intend to impose any restrictions on this.

[0033] In embodiments of this application, the executing entity can acquire live stream segments generated from the live stream. For example, if the executing entity is executored as a "server" or "live stream server," the executing entity can perform operations such as transcoding on the live stream provided by the broadcaster to convert it into a corresponding "media file" to obtain a live stream segment. For example, the executing entity can choose to process the live stream periodically to generate one or more live stream segments of similar or close length.

[0034] Then, the executing entity can store it (for example, store it in the cache or storage area of ​​the live stream segment) through its internal data flow and file flow, in order to actually complete the purpose of "obtaining the live stream segment generated for the live stream" in this step.

[0035] In some embodiments, the format of the live stream segment may differ depending on the transmission protocol used between the live stream and the user device. For example, under the HTTP Live Streaming (HLS) protocol, the live stream segment may be in m4s format.

[0036] S102, Based on the live streaming status information of the live stream, determine the target threshold for the live stream;

[0037] In the embodiments of this application, the executing entity may, after acquiring a live stream segment, select to determine a target threshold for the live stream based on the live stream status information.

[0038] In different embodiments and scenarios, this step is not actually directly related to S101 in terms of timing. That is, the executing entity can either execute this step after obtaining the live broadcast segment (e.g., after obtaining the first live broadcast segment) as discussed above, or choose to execute this step before obtaining the live broadcast segment. For example, S102 can be executed synchronously with the action of receiving the live broadcast stream, so that the action of determining the target threshold can be completed earlier.

[0039] The live stream status information may include at least one of the following: live stream duration, live stream popularity, and live stream segment delivery rate. Accordingly, the executing entity may use this live stream status information to determine a target threshold for the live stream. This target threshold may be used in a subsequent step (e.g., S103) to determine and constrain the number of associated live stream segments that can be included in an index file; that is, when the number of associated live stream segments is greater than or equal to the target threshold, the index file can be considered to have been fully used.

[0040] This allows for the use of multiple index files to create indexes for the live stream and all live segments. Furthermore, it enables the dynamic adjustment of the number of associated live segments within each index file based on the live stream's characteristics. This avoids problems that arise when indexing at a fixed granularity, such as excessively large index files that hinder searching, or too many or too fragmented index files. This approach better balances indexing efficiency with index file size and quantity, allowing the system to dynamically adjust the index files based on at least one of the following three dimensions: live stream duration, live stream popularity, and live segment delivery rate, achieving a dynamic balance.

[0041] Typically, a numerical correspondence between the target threshold and the actual live streaming status information used (i.e., which one or more of the following: live streaming duration, live streaming popularity, and live streaming segment delivery rate) can be established. This allows the executing entity to map the specific value of the target threshold based on this numerical correspondence after obtaining the live streaming status information.

[0042] In some embodiments, corresponding standard durations and standard popularity can be set for live streaming duration and live streaming popularity, so that the standard duration and standard popularity can be used to provide a more granular strategy for determining the target threshold in the "numerical correspondence" by combining long live streaming, short live streaming, popular live streaming, and unpopular live streaming.

[0043] For example, a standard duration can be pre-set for "already broadcasted duration" to distinguish between "long broadcasts" and "short broadcasts". Then, when using "already broadcasted duration" to determine the target threshold, the implementing entity can provide different determination strategies for "long broadcasts" and "short broadcasts". For example, in the case of long broadcasts, the "target threshold" can be larger to reduce the number of index files used and avoid the broadcast segments being too scattered.

[0044] Accordingly, the executing entity can generate a first reference value based on the ratio of the live broadcast duration to the standard duration, and then use this first reference value as the target threshold.

[0045] In some embodiments, to ensure the range of the target threshold is controllable, a corresponding value range can be configured for the target threshold to limit its range and improve system security. Accordingly, in the example above, the executing entity can specifically determine whether the first reference value falls within the value range. If it does, the executing entity can directly use the first reference value. If not, the executing entity can choose the upper or lower limit of the value range as the target threshold based on the numerical relationship between the first reference value and the value range, thus satisfying both the direction of the first reference value and the requirements for the target threshold. For example, if the first reference value is on the left side of the value range on the number axis (i.e., less than the lower limit of the value range), the executing entity can choose the lower limit of the value range greater than the first reference value as the target threshold. Similarly, if the first reference value is on the right side of the value range on the number axis (i.e., greater than the upper limit of the value range), the executing entity can choose the upper limit of the value range less than the first reference value as the target threshold.

[0046] In some embodiments, to facilitate the management user of the executing entity to further dynamically adjust the target threshold according to their personal needs, the above numerical correspondence may also include adjustment parameters that can be set by the management user, so that the management user can dynamically adjust the target threshold through management parameters.

[0047] Therefore, under such circumstances, when the live streaming status information includes the duration of the live stream, or in other words, when only the duration of the live stream is used to determine the target threshold, the target threshold k can be determined based on the following formula (1):

[0048] k = min(max(T / Tbase × α, Kmin), Kmax) (1)

[0049] Where T is the current "live broadcast duration", Tbase is the standard duration, α is the adjustment parameter, Kmin is the lower limit of the range of values ​​for k, and Kmin is the upper limit of the range of values ​​for k.

[0050] Similarly, when using "live stream popularity" alone, the executing entity can complete the process of determining the target threshold by adjusting the above T to H (e.g., the number of users watching the live stream) and Tbase to Hbase (representing "standard popularity").

[0051] As for the rate of live streaming segments, the executing entity can directly use the rate range it falls into as the target threshold, based on the rate range it pre-configured for the rate range.

[0052] In some embodiments, as discussed above, the target threshold can be determined by combining the duration of the live stream, the popularity of the live stream, and the rate at which the live stream segments are delivered, thereby comprehensively determining the target threshold by combining these three dimensions.

[0053] Specifically, the executing entity can first generate a first reference value based on the ratio of the live broadcast duration to the standard duration; then, the executing entity can generate a second reference value based on the ratio of the live broadcast popularity to the standard popularity; then, the executing entity can generate a third reference value based on the product of the first and second reference values; next, a fourth reference value can be generated based on the ratio of the third reference value to the live broadcast segment delivery rate; finally, if the fourth reference value is within the range of the target threshold, the executing entity can respond by using the fourth reference value as the target threshold.

[0054] In this situation, it is also possible to take advantage of the process and choose to add adjustment parameters so that the management user can also adjust the use of these three factors.

[0055] Accordingly, in such a case, the target threshold k can be determined based on the following formula (2):

[0056] k = min(max(T / Tbase × α × (1 + H / Hbase) / Q, Kmin), Kmax) (2)

[0057] Where T is the current "live broadcast duration", Tbase is the standard duration, α is the adjustment parameter, H is the live broadcast popularity, Hbase is the standard popularity, Q is the live broadcast segment delivery rate, Kmin is the lower limit of the range of k values, and Kmin is the upper limit of the range of k values.

[0058] Accordingly, as discussed above, the executing entity can use the target threshold to continuously detect the target number of unindexed live segments that have been received without indexing. If the target number is equal to or greater than the target threshold, the executing entity can respond by executing S103.

[0059] S103, Generate an index file and description information for the unindexed live stream segment;

[0060] In embodiments of this application, as discussed above, the executing entity can create an index for these unindexed live stream segments to generate an index file (e.g., the index file may at least record index information such as the sequence number of the live stream segments that can locate and identify these live stream segments) and descriptive information for the index file. The descriptive information indicates the time range and / or quantity range of the live stream segments included in the index file.

[0061] Typically, the specific format of the index file corresponds to the transmission protocol used. For example, in the case of the HLS protocol mentioned above, the index file can be in m3u8 format.

[0062] This allows the executing entity to use different index files to index live segments in segments. For example, the first index file in sequence could be used to index and associate the first 100 live segments, while the second index file could be used to index and associate the live segments from 101 to 200.

[0063] In some embodiments, to enable more efficient use of the index file, the implementing entity may choose to store the metadata of the live stream segments along with the live stream segments in the index file. That is, the index file includes metadata describing the segment parameters corresponding to each unindexed live stream segment, allowing the metadata of the live stream segments to be embedded in the index file instead of generating a separate metadata file for each live stream segment. Metadata includes basic metadata and encoded metadata. Basic metadata may include the live stream segment's sequence number, length, storage path, file size, timestamp, relative time offset, storage path, etc., while encoded metadata may include whether it includes the start frame, frame type distribution, encoding parameters (e.g., encoding format, resolution), etc.

[0064] Accordingly, in this way, when using the index storage later, only the index file needs to be stored, without having to generate additional metadata files or store this metadata in the index storage to assist the index (for example, being able to directly obtain relevant information such as sequence number, timestamp, whether it includes the start frame, etc. based on the metadata in the index file). This improves indexing efficiency while avoiding the metadata file occupying the index storage and causing an undesirable expansion of the index storage size.

[0065] S104, Provide the index file and description information to the index storage;

[0066] In the embodiments of this application, as discussed above, the executing entity may provide the index file to the index storage after generating the index file and completing the indexing action for these currently unindexed live segments.

[0067] After the indexing is completed, that is, after the index file is uploaded, the execution entity can continuously detect whether new unindexed live segments are received. If so, the execution entity can respond by selecting to execute S105 to jump to the execution of live status information based on the live stream, determine the target threshold for the live stream (i.e., S102 above) to determine the (new) target threshold corresponding to the new index file, and continue to build a new index file after the number of new unindexed live segments received subsequently reaches the (new) target threshold. In this way, the purpose of using multiple dynamically sized index files to completely index the live segments can be achieved.

[0068] S105, jump to execute based on the live stream status information and determine the target threshold for the live stream.

[0069] In some embodiments, considering that the creation of the index file may also take some time, in such cases, the executing entity can continuously detect the number of unindexed live segments that have not been indexed, and when it approaches a target threshold (for example, when it is greater than or equal to a number value, and the corresponding value of the number threshold is less than the target threshold), it can choose to create a new index file, so that when the previous index file is used, the new index file can be directly used and switched to "seamlessly" connect the generation process of the two index files.

[0070] For example, in practice, when the executing entity starts acquiring live stream segments, it can first generate an initial index file and associate it with the first round of "unindexed live stream segments" as the first "index file". Then, in the process, if the number of unindexed live stream segments acquired is greater than or equal to the above-mentioned number, a second "initial index file" is generated to be used as a new, second index file after the first index file.

[0071] Subsequently, the method for managing live stream segments provided in this application obtains live stream segments generated for a live stream; determines a target threshold for the live stream based on the live stream's live stream status information, wherein the live stream status information includes at least one of the following: live stream duration, live stream popularity, and live stream segment delivery rate; in response to the target number of received unindexed live stream segments that have not been indexed being greater than or equal to the target threshold, generates an index file for the unindexed live stream segments and descriptive information for the index file, wherein the descriptive information indicates the time range and / or quantity range of the live stream segments included in the index file; provides the index file and descriptive information to the index storage; in response to the continued receipt of unindexed live stream segments after the index file is generated, jumps to the execution of determining the target threshold for the live stream based on the live stream's live stream status information. Therefore, it not only improves the query efficiency when querying live stream segments using index files by allowing the creation of multiple index files to segmentally correspond to and indicate live stream segments, but also improves the overall management performance of live stream segments by dynamically adjusting the number of live stream segments included and targeted in the index file, thus balancing the relationship between index efficiency and index file size.

[0072] In some embodiments, if the index file includes basic metadata of the live segment, and the basic metadata includes at least the segment duration, then in such cases, the executing entity can also use the segment duration to calibrate those segment durations that may be abnormal (e.g., excessively large spans) in the index file to improve the quality of the metadata.

[0073] Specifically, the executing entity can detect whether the index file records a first live segment whose corresponding segment duration is greater than or equal to a duration threshold (which can be determined based on the aforementioned "period" length; for example, in the case of a "2s" period, a preset multiple, such as 8s, can be selected as the "duration threshold," or the duration threshold can also be determined based on the segment durations of one or more live segments adjacent to and preceding the live segment, such as the average of 150% or 200% of their average). In other words, if an "abnormal" live segment exists, the executing entity can determine the average segment duration of the second live segment based on the segment durations of each second live segment different from the first live segment in the index file and the number of second live segments. That is, the executing entity can sum the segment durations of each second live segment and then divide the sum by the number of second live segments to obtain the average segment duration.

[0074] Then, the executing entity can update the segment duration corresponding to the first live broadcast segment based on the average duration. For example, the update can be completed by replacing the segment duration corresponding to the first live broadcast segment with the average duration. This avoids system risks caused by errors or anomalies in the duration provision.

[0075] In some embodiments, since the "target threshold" can change dynamically based on the progress of the live stream, in such cases, such as long live streams, the initial target threshold may be inappropriate (for example, based on the increase or accumulation of the live stream duration, the subsequent target threshold may be significantly greater than the initial target threshold). In such cases, the executing entity can also search and retrieve whether there are mergeable index files in the index storage.

[0076] For example, each time a new "target threshold" is used, the executing entity can perform such a check. For instance, starting with the first index file, the executing entity can determine whether it is merging with the second, and even the third and fourth index files. That is, after merging, is the total number of live stream segments associated with them less than the (new) target threshold? If so, i.e., the total number of included live stream segments is less than or equal to the target threshold, the executing entity can treat them as mergingable index files, thus identifying a mergingable index file group. For example, if the combination of the first and second index files is less than the new target threshold, while the combination of the first, second, and third index files is greater than the new target threshold, the executing entity can treat the first and second index files as a mergingable index file group.

[0077] Then, the executing entity can merge the mergeable index files in the mergeable index file group. Thus, through this "backtracking" process, the executing entity can make more granular adjustments to the index files, so that the granularity between the various index files for the same live stream is similar.

[0078] In some embodiments, to address live stream interruptions and prevent timestamp corruption or jumps in an index file that could affect system stability, the executing entity can determine the first timestamp of an unindexed live stream segment after acquiring it (referred to as the "first unindexed live stream segment" for ease of description), and then continuously monitor whether new unindexed live stream segments (referred to as the "second unindexed live stream segment") are continuously and consecutively received after the first timestamp. Accordingly, the first unindexed live stream segment precedes the second unindexed live stream segment (i.e., the two are "continuous") and is adjacent to the second unindexed live stream segment in the live stream.

[0079] For example, a time threshold can be set so that the executing entity can use this time threshold to determine whether the second unindexed live segment is continuously received. If the second timestamp threshold is not received within the preset time threshold range after the first timestamp of the first unindexed live segment, the executing entity can respond by selecting to generate an index file and its description information based on the first unindexed live segment and the third unindexed live segment preceding the first unindexed live segment (i.e., generating the index file according to the original logic of generating the index file, ending with "first unindexed live segment" and being the last unindexed live segment in the file).

[0080] In other embodiments, because the time of generating the index file is later than the time of receiving the unindexed live stream segments, multiple unindexed live stream segments may have actually been received. In such cases, the executing entity can similarly determine whether an interruption has occurred between two adjacent, consecutively received unindexed live stream segments. That is, the executing entity can take the earlier unindexed live stream segment as the first unindexed live stream segment and the adjacent, later unindexed live stream segment as the second unindexed live stream segment, and compare the first timestamp of the first unindexed live stream segment with the second timestamp of the second unindexed live stream segment to determine the distance between them.

[0081] Correspondingly, if the distance is greater than or equal to the time threshold, the executing entity can also respond by generating an index file and its description information based on the first unindexed live stream segment and the third unindexed live stream segment preceding the first unindexed live stream segment. The first unindexed live stream segment precedes the second unindexed live stream segment and is adjacent to the second unindexed live stream segment in the live stream.

[0082] In some embodiments, the executing entity may also choose to set a time threshold that is smaller than the aforementioned time threshold, so that when the distance is between the smaller time threshold and the aforementioned time threshold, the timestamp is corrected (e.g., by subtracting the smaller time threshold), so that the executing entity can repair those "time offsets" that do not reach the interruption criteria, thereby ensuring the quality of the index file.

[0083] In some embodiments, to avoid time chaos caused by streaming interruptions and re-streaming scenarios, the executing entity can also detect whether unindexed live stream segments are consecutive (e.g., whether their "sequence numbers" are consecutive). If the sequence number of the first segment of the fourth unindexed live stream segment and the sequence number of the second segment of the fifth unindexed live stream segment are not consecutive (e.g., the sequence number of the fourth unindexed live stream segment is "3", while the sequence number of the second segment of the fifth unindexed live stream segment that follows and is adjacent to it is "6"), the executing entity can, in response, determine the number of placeholder unindexed segments corresponding to the numerical difference between the first and second segment sequence numbers. For example, in the example above, the executing entity can determine that the numerical difference is 3 based on "6" - "3", and accordingly determine 3 placeholder unindexed segments.

[0084] Then, the executing entity can add placeholder unindexed segments between the fourth and fifth unindexed live segments. This allows unindexed live segments temporarily lost due to transmission failures to be "placed" instead of being directly replaced by later-received unindexed live segments. This approach not only allows the executing entity to directly replace the placeholder unindexed segments with the missing ones when they are actually received after the index file is generated, without altering the original index file's time and order logic, thus avoiding significant adjustments and modifications to the index file, but also enables more accurate control over the entire creation process. It prevents misjudgments in quantity or range from affecting the quality of the index file (e.g., errors in judging before the target threshold lead to too many unindexed live segments being associated with the same index file), thus improving the reliability of the index file.

[0085] Based on any of the above embodiments, the executing entity can also continuously detect whether the live stream has ended (e.g., the user providing the live stream sends an instruction to stop providing it, etc.).

[0086] If the end of the live stream is detected, the execution entity can also check whether there are still unindexed live stream segments. These are unindexed live stream segments that were not indexed due to insufficient quantity (i.e., not meeting the target threshold). If so, the execution entity, in response to the detection of the end of the live stream and the existence of unindexed live stream segments, generates an index file and its description information for the unindexed segments. This ensures that even after the live stream has been completed, the remaining unindexed live stream segments are processed completely, preventing omissions.

[0087] In some embodiments, the executing entity may also choose to determine the number of remaining unindexed live stream segments and, if the number is small, for example, below a remaining number threshold, choose to write them to the previous index file to control the number of index files.

[0088] Furthermore, the process of managing live stream segments can also include the actual delivery of the live stream segments to users, such as viewers.

[0089] For easier understanding of this process, you can also refer to the following: Figure 2 Let's have a discussion. Figure 2 A flowchart of a process 200 for providing a live broadcast segment according to an embodiment of this application is shown. For example, process 200 may be executed after process 100 described above.

[0090] It should be understood that in some scenarios, if at least two index files are configured, then process 200 can actually be executed after the first process 100 is completed, that is, after at least one index file is generated and at least one index file is uploaded to the index storage.

[0091] Process 200 may specifically include the following steps:

[0092] S201, in response to receiving a fragment query request sent by the target device, determine the target description information based on the query request;

[0093] Specifically, as discussed above, a user can use a user device as the target device to send a segment query request to the executing entity. The segment query request can specify the live content and the desired time period of the live content.

[0094] Accordingly, if the executing entity receives the request for the live stream segment, it can determine the target description information based on the requested live stream content. The target description information may include the live stream corresponding to the live stream content, as well as the range of live stream segments corresponding to the "time period" required by the user. For example, the executing entity can convert the time period into a corresponding range of timestamps (e.g., xx seconds to yy seconds).

[0095] S202, Determine the target index file from the index storage based on the target description information;

[0096] Specifically, after determining the target description information based on the above S201, the executing entity can use the target description information to determine the target index file from the index storage.

[0097] In this step, the executing entity can first extract the set of index files corresponding to the live stream, and then determine which target index files include the aforementioned time period.

[0098] For example, the executing entity can estimate the corresponding time range based on the time range included in the description information or by using the quantity range (and average length), and select those index files whose time range falls within the "time period" as the target index files.

[0099] S203, Use the target index file to determine the target set of live stream segments;

[0100] Specifically, in this step, after locating the target index file, the executing entity can search for the target live stream segment corresponding to the start of the time range and the target live stream segment corresponding to the end of the time range in the target index file at the beginning, and then collect them, as well as all the target live stream segments in between, as the target live stream segment set.

[0101] In some embodiments, to improve encoding efficiency, the encoding of the live stream can be done in the form of a group of pictures (abbreviated as "Pictures"). In this case, when the executing entity extracts the target live stream segments, it can also select that the first and last target live stream segments in the target live stream segment set both include "I-frames", that is, "keyframes", in order to avoid playback errors and affect playback quality due to the lack of I-frames in the extracted target live stream segment set (or the extracted part of the live stream content).

[0102] Accordingly, in this scenario, taking the "starting point" or the first "target live stream segment" as an example, after determining the starting point of the time period, the executing entity searches backward for the nearest I-frame. If the found I-frame is within the target live stream segment, the executing entity can use it as the "starting point" target live stream segment; otherwise, the executing entity can continue searching forward to find the live stream segment that includes the I-frame, and use it as the actual "starting point" or the first target live stream segment. Similarly, for the "ending point" or the "last" "target live stream segment," the executing entity can search backward in a similar manner, which will not be repeated here.

[0103] In some embodiments, if no I-frame is found while searching forward, the executing entity may choose to abandon the forward search and discard the current target live segment, selecting the nearest target live segment containing an I-frame that is located after the target live segment as the "starting point." This controls the set of target live segments to begin with an I-frame and end before an I-frame. Similarly, if no I-frame is found while searching backward, the executing entity may also choose to abandon the backward search and discard the current target live segment, using the nearest target live segment containing an I-frame that is located before the target live segment as the "ending point."

[0104] S204, return the target set of live stream segments to the target device.

[0105] Specifically, after completing S203 above, the executing entity can return the determined set of target live broadcast segments to the target device to complete the extraction of part of the live broadcast content.

[0106] In some embodiments, in scenarios involving GOPs, since the executing entity can use multiple index files to provide users with indexed live stream segments, in order to avoid errors caused by inconsistent or chaotic timestamps in the index files when indexing across index files, the executing entity can choose to associate the various index files using a unified time and the same timeline. This allows the executing entity to use the same timeline and the same set of timestamp standards during processes such as retrieving I-frames, as described above. For example, the executing entity can use the same timeline to accumulate the time range of the live stream segments included and involved in the index files, ensuring that the various index files are under the same set of timestamp standards.

[0107] Accordingly, in such a case, when executing S103 above, the executing entity may, as an alternative, first generate an index file for the unindexed live stream segments; then, based on the target timeline, determine the third timestamp of the first indexed live stream segment at the beginning of the file and the fourth timestamp of the second indexed live stream segment at the end; and use the time range determined by the third and fourth timestamps as descriptive information.

[0108] Then, when generating subsequent new index files, the executing entity can similarly use the target timeline to determine the corresponding time range as descriptive information. This ensures that all index files are continuous on the target timeline, allowing the time ranges used by earlier index files to be accumulated and added to subsequent index files. For example, for index file A, its time range could be [x1, x2), while the time range of subsequent index file B could be [x2, x3), allowing it to accumulate the time range of index file A. This ensures continuous and consistent time standards between index files, improving index quality when crossing multiple index files.

[0109] In some embodiments, if multiple live streams are provided for the same live content (e.g., each live stream corresponds to a different resolution), the executing entity may also choose to associate and store index files belonging to the same live stream in the index store to generate a set of index files corresponding to the live stream.

[0110] Then, based on the live stream tags, the system associates and stores the corresponding collections of index files for each live stream belonging to the same live content. The live stream tags indicate the live content to which the live stream belongs, as well as the resolution of the live stream.

[0111] This allows the system to quickly associate and locate the required set of index files with the live content after the user specifies the desired resolution, and to respond quickly based on this association when the user switches resolutions.

[0112] In some embodiments, if multiple levels of sharpness are involved, the executing entity may also refer to the number of types of sharpness involved when determining the target threshold, and adjust the target threshold accordingly. For example, as the number of types of sharpness increases, the target threshold may be reduced to ensure the alignment accuracy of each level of sharpness.

[0113] To enhance understanding, this application also provides a specific implementation scheme based on a particular application scenario. Please refer to it. Figure 3 , Figure 3This is a flowchart of a process 300 for managing live broadcast segments in a specific application scenario, provided as an embodiment of this application.

[0114] In process 300, it may exemplary include a user device 310 used by the broadcaster to provide a live stream, and a server 315 for receiving and distributing the live stream.

[0115] In process 300, firstly, the broadcaster (not shown in the figure) can use the user device 310 to capture images, sounds, etc. to form a live stream 321, and use the user device 310 to execute S301 to provide the live stream 321 to the server 315.

[0116] Accordingly, after server 315 receives live stream 321 (or, after it starts receiving live stream 321), in addition to pushing it to other servers (for example, in the case where the live streaming service is provided in a distributed manner, the server may be the server corresponding to the edge node) and user devices to achieve the purpose of providing live streaming, it can also generate live stream segments 331, 332...33N of live stream 321 locally by executing S302, in order to "save" and "record" the live streaming content corresponding to live stream 321.

[0117] For example, server 315 can periodically intercept and decode the content of live stream 321 in S302 to continuously generate live stream segments 331, 332...33N, where N is a positive integer.

[0118] As discussed above, server 315 may simultaneously execute S303 upon starting to generate or receiving a live stream segment (e.g., live stream segment 331) to determine a target threshold 324 for live stream 321 based on the live stream status information 323 of live stream 321. For example, the target threshold generated at this time (or in this first round) could be "3".

[0119] Accordingly, in such a case, after generating and obtaining live segment 333, it can be assumed that the number of unindexed live segments that have been received without indexing, i.e., the target number ("3") of live segments 331, 332 and 333 is greater than or equal to the target threshold 324 ("3"), then the server 315 can respond to this by selecting to execute S304 to generate an index file 341 for the unindexed live segments and a description information 342 for the index file 341.

[0120] Then, server 315 can execute S305 to provide index file 341 and description information 342 to index storage 317.

[0121] Next, server 315 can continue to detect whether new live segments have been received. For example, if new live segments 334, 335...33N are subsequently generated or acquired, server 315 can respond by jumping to S303 above to continue and redetermine the target threshold 324 in order to start the next round of generating the index file for the next round.

[0122] This application also provides an apparatus for managing live broadcast segments, the structure of which is as follows: Figure 4 The apparatus 400 shown includes: a live segment receiving module 410 configured to acquire live segments generated for a live stream; a target threshold determination module 420 configured to determine a target threshold for a live stream based on live stream status information, wherein the live stream status information includes at least one of the following: live stream duration, live stream popularity, and live segment delivery rate; a first index building module 430 configured to generate an index file and descriptive information for the unindexed live segments in response to a target number of received unindexed live segments being greater than or equal to the target threshold, wherein the descriptive information indicates the time range and / or quantity range of the live segments included in the index file; an index storage module 440 configured to provide the index file and descriptive information to an index storage; and an execution jump module 450 configured to jump to the execution of determining the target threshold for the live stream based on the live stream status information in response to the continued receipt of unindexed live segments after the index file is generated.

[0123] This embodiment exists as a device embodiment corresponding to the above method embodiment. The device for managing live broadcast segments provided in this embodiment can not only improve the query efficiency when querying live broadcast segments using index files by allowing the creation of multiple index files to correspond to and indicate live broadcast segments in segments, but also balance the relationship between index efficiency and index file size by dynamically adjusting the number of live broadcast segments included and targeted by the index files, thereby improving the overall management performance of live broadcast segments.

[0124] In some embodiments, the index file includes metadata corresponding to the unindexed live stream segments, which describes the segment parameters of the live stream segment. The metadata includes basic metadata and encoded metadata.

[0125] In some embodiments, the apparatus 400 further includes: an average segment duration determination module, configured to determine the average segment duration of a second live stream segment in response to a first live stream segment in the index file that includes a segment duration in the basic metadata and records a corresponding segment duration greater than or equal to a duration threshold, based on the segment duration of each second live stream segment in the index file that is different from the first live stream segment and the number of second live stream segments; and a segment duration update module, configured to update the segment duration corresponding to the first live stream segment based on the average duration.

[0126] In some embodiments, the target threshold determination module 420 is further configured to, in response to the live broadcast status information being the duration of the live broadcast, generate a first reference value based on the ratio of the duration of the live broadcast to the standard duration; and in response to the first reference value being within the range of the target threshold, use the first reference value as the target threshold.

[0127] In some embodiments, the target threshold determination module 420 is further configured to, in response to the live streaming status information including the live streaming duration, live streaming popularity, and live streaming segment delivery rate, generate a first reference value based on the ratio of the live streaming duration to the standard duration; generate a second reference value based on the ratio of the live streaming popularity to the standard popularity; generate a third reference value based on the product of the first reference value and the second reference value; generate a fourth reference value based on the ratio of the third reference value and the live streaming segment delivery rate; and, in response to the fourth reference value being within the range of the target threshold, use the fourth reference value as the target threshold.

[0128] In some embodiments, the apparatus 400 further includes: an index file set generation module, configured to associate and store index files belonging to the same live stream in an index storage to generate an index file set corresponding to the live stream; and a live stream association module, configured to associate and store the index file sets corresponding to each live stream belonging to the same live content based on the live stream tags of the live stream, wherein the live stream tags indicate the live content to which the live stream belongs and the clarity of the live stream.

[0129] In some embodiments, the apparatus 400 further includes an index file merging module configured to merge mergeable index files in a mergeable index file group in response to the existence of a mergeable index file group in the index storage, wherein the total number of live segments included in the mergeable file group is less than or equal to a target threshold.

[0130] In some embodiments, the apparatus 400 further includes: a second index building module, configured to generate an index file and description information of the index file based on the first unindexed live stream segment and a third unindexed live stream segment located before the first unindexed live stream segment in response to a distance between a first timestamp of the first unindexed live stream segment and a second timestamp of the second unindexed live stream segment being greater than or equal to a time threshold, wherein the first unindexed live stream segment is located before the second unindexed live stream segment and is adjacent to the second unindexed live stream segment in the live stream.

[0131] In some embodiments, the apparatus 400 further includes: a placeholder segment generation module configured to, in response to the discontinuity of the first segment number of the fourth unindexed live segment and the second segment number of the fifth unindexed live segment, determine a number of placeholder unindexed segments corresponding to the numerical difference between the first segment number and the second segment number; and a placeholder segment addition module configured to add a placeholder unindexed segment between the fourth unindexed live segment and the fifth unindexed live segment.

[0132] In some embodiments, the apparatus 400 further includes a third index building module, configured to generate an index file for the unindexed live stream segment and description information of the index file in response to detecting the end of the live stream transmission and the existence of an unindexed live stream segment.

[0133] In some embodiments, the first index building module 430 is further configured to generate an index file for unindexed live segments in response to the description information being used to indicate at least a time range and the target number of unindexed live segments that have been received being greater than or equal to a target threshold; determine a third timestamp of the first indexed live segment at the beginning of the file and a fourth timestamp of the second indexed live segment at the end of the file based on the target timeline; and use the time range determined by the third timestamp and the fourth timestamp as the description information.

[0134] In some embodiments, the apparatus 400 further includes: a description information determination module configured to determine target description information based on a query request in response to receiving a segment query request sent by a target device; an index file determination module configured to determine a target index file from an index storage based on the target description information; a segment set determination module configured to determine a target live segment set using the target index file; and a segment set providing module configured to return the target live segment set to the target device.

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

[0136] Electronic devices can be user devices, or devices composed of user devices and network devices integrated through a network, or applications running on the aforementioned devices. User devices include, but are not limited to, various terminal devices such as computers, mobile phones, tablets, smartwatches, and wristbands. Network devices include, but are not limited to, network hosts, single network servers, multiple network server sets, or cloud computing-based computer sets, and can be used to implement some processing functions when setting an alarm clock. Here, the cloud consists of a large number of hosts or network servers based on cloud computing. Cloud computing is a type of distributed computing, consisting of a virtual computer composed of a group of loosely coupled computer sets.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims

1. A method for managing live stream segments, characterized in that, include: Acquire live segments generated from the live stream; Based on the live streaming status information of the live stream, a target threshold is determined for the live stream, wherein the live streaming status information includes at least one of the following: live streaming duration, live streaming popularity, and live stream segment delivery rate; In response to a target number of received unindexed live stream segments that have not been indexed being greater than or equal to the target threshold, an index file for the unindexed live stream segments and descriptive information for the index file are generated, wherein the descriptive information indicates the time range and / or quantity range of the live stream segments included in the index file; Provide the index file and the description information to the index storage; In response to receiving the unindexed live stream segment after the index file is generated, the process jumps to executing the live stream status information based on the live stream and determining the target threshold for the live stream.

2. The method according to claim 1, characterized in that, The index file includes metadata corresponding to each of the unindexed live stream segments, which describes the segment parameters of the live stream segment. The metadata includes basic metadata and encoding metadata.

3. The method according to claim 2, characterized in that, In response to the underlying metadata including fragment duration, it also includes: In response to the first live broadcast segment recorded in the index file with a segment duration greater than or equal to the duration threshold, the average segment duration of the second live broadcast segment is determined based on the segment duration corresponding to each of the second live broadcast segments in the index file that are different from the first live broadcast segment and the number of the second live broadcast segments; The duration of the segment corresponding to the first live broadcast segment is updated based on the average duration.

4. The method according to claim 1, characterized in that, In response to the live streaming status information being the duration of the live stream, determining the target threshold based on the live streaming status information includes: A first reference value is generated based on the ratio of the live broadcast duration to the standard duration; In response to the first reference value being within the range of the target threshold, the first reference value is used as the target threshold.

5. The method according to claim 1, characterized in that, In response to the live streaming status information including the live streaming duration, the live streaming popularity, and the live streaming segment delivery rate, determining the target threshold based on the live streaming status information includes: A first reference value is generated based on the ratio of the live broadcast duration to the standard duration; A second reference value is generated based on the ratio of the live stream popularity to the standard popularity. A third reference value is generated based on the product of the first and second reference values; A fourth reference value is generated based on the ratio of the third reference value to the rate provided by the live segment; In response to the fourth reference value being within the range of the target threshold, the fourth reference value is used as the target threshold.

6. The method according to claim 1, characterized in that, The method further includes: The index files belonging to the same live stream are stored together in the index storage to generate a set of index files corresponding to the live stream; Based on the live stream tags, the index file sets corresponding to each of the live streams belonging to the same live content are associated and stored, wherein the live stream tags indicate the live content to which the live stream belongs, as well as the resolution of the live stream.

7. The method according to claim 1, characterized in that, The method further includes: In response to the existence of a mergeable index file group in the index storage, mergeable index files in the mergeable index file group are merged, wherein the total number of live segments included in the mergeable file group is less than or equal to the target threshold.

8. The method according to claim 1, characterized in that, The method further includes: In response to the distance between the first timestamp of the first unindexed live stream segment and the second timestamp of the second unindexed live stream segment being greater than or equal to a time threshold, the index file and the description information of the index file are generated based on the first unindexed live stream segment and the third unindexed live stream segment located before the first unindexed live stream segment, wherein the first unindexed live stream segment is located before the second unindexed live stream segment and is adjacent to the second unindexed live stream segment in the live stream.

9. The method according to claim 1, characterized in that, The method further includes: In response to the discontinuity between the first segment number of the fourth unindexed live segment and the second segment number of the fifth unindexed live segment, a number of unindexed placeholder segments corresponding to the numerical difference between the first segment number and the second segment number are determined. The placeholder unindexed segment is added between the fourth unindexed live segment and the fifth unindexed live segment.

10. The method according to claim 1, characterized in that, The method further includes: In response to detecting the end of the live stream transmission and the existence of the unindexed live stream segment, an index file for the unindexed live stream segment and the description information of the index file are generated.

11. The method of claim 1, wherein, in response to the description information being used at least to indicate the time range, an index file for the unindexed live segment and description information for the index file are generated, comprising: Generate an index file for the unindexed live stream segments; Based on the target timeline, determine the third timestamp of the first indexed live segment at the beginning of the file and the fourth timestamp of the second indexed live segment at the end. The time range determined by the third timestamp and the fourth timestamp is used as the description information.

12. The method according to any one of claims 1-11, characterized in that, The method further includes: In response to receiving a fragment query request sent by the target device, target description information is determined based on the query request; The target index file is determined from the index storage based on the target description information; Use the target index file to determine the set of target live stream segments; The target set of live stream segments is returned to the target device.

13. A device for managing live broadcast segments, characterized in that, include: The live stream segment receiving module is configured to acquire live stream segments generated from the live stream. The target threshold determination module is configured to determine a target threshold for the live stream based on the live stream status information, wherein the live stream status information includes at least one of the following: live stream duration, live stream popularity, and live stream segment delivery rate. The first index building module is configured to generate an index file for the unindexed live stream segments and description information of the index file in response to a target number of received unindexed live stream segments that is greater than or equal to the target threshold, wherein the description information indicates the time range and / or quantity range of the live stream segments included in the index file. An index storage module is configured to provide the index file and the description information to the index storage; The execution jump module is configured to, in response to receiving the unindexed live stream segment after the index file is generated, jump to the execution of the live stream status information based on the live stream to determine the target threshold for the live stream.

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

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

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

Images