Live broadcasting room fragment retrieval method and system

Abstract

The invention discloses a live broadcast room fragment retrieval method and system, and the method comprises the steps: carrying out the real-time segmented recording of a live broadcast stream, generating a video fragment file, and storing the video fragment file in an object storage service; extracting audio data from the video clip file, and splitting the audio data into transport stream unit files; acquiring a plurality of transport stream unit files, dynamically splicing the transport stream unit files into a plurality of audio list files, and organizing the audio list files by taking a batch across live broadcast rooms as a unit to form a batch processing task; loading an open source speech recognition model, executing parallel speech recognition on the audio list file, and generating a text recognition result containing a timestamp; constructing each text unit, the corresponding accurate starting time, the ending time and the corresponding live broadcast room identifier into a fine-grained index document, and storing the fine-grained index document into a search engine; and receiving a retrieval keyword input by a user, executing query in the search engine, and generating a video list file. According to the invention, ASR processing cost and time consumption can be greatly reduced.

Description

Technical Field

[0001] This invention relates to the field of information processing, and more specifically to a method and system for retrieving live stream clips. Background Technology

[0002] With the rapid development of live-streaming e-commerce and content platforms, efficient analysis and accurate retrieval of massive amounts of live-streaming data have become key requirements for improving operational efficiency and user experience. Live-streaming content is characterized by high concurrency, long duration, and large scale, with tens of thousands of hours of video generated daily, corresponding to tens of millions of pieces of text information. Traditional methods relying on manual screening are completely unable to meet actual business needs, and it is necessary to use automatic speech recognition technology to convert audio and video content into searchable text.

[0003] Currently, cloud-based ASR services provided by external vendors are the mainstream solution. The typical process involves first recording the live stream video in segments, then uploading the audio files to a third-party platform (such as iFlytek or Volcano Engine) for speech-to-text transcription. While this model can achieve basic text extraction, it exposes multiple shortcomings when dealing with tens of thousands of hours of live stream data daily: Firstly, external ASR services are billed based on usage, resulting in high overall costs when combined with public network traffic transmission fees; secondly, service provider interfaces have concurrency limitations and low efficiency in processing long audio files, with the ratio of original video to ASR processing time often reaching 10:1 or even higher, causing the daily live stream content to be unable to be transcribed on the same day, severely lagging behind business response needs; furthermore, the logic of external services is opaque, easily leading to recognition failures or service instability in high-concurrency scenarios, lacking controllability and stability guarantees.

[0004] Furthermore, existing technologies also have significant shortcomings in subsequent retrieval stages. Even when ASR text is obtained, traditional solutions typically only coarsely associate the entire text with timestamps, lacking a fine-grained sentence-level index structure. This makes it difficult to accurately locate the specific playback position after keyword matching. At the same time, the retrieval results require tracing back to the original video file and manually extracting the corresponding segments. The visualization process is cumbersome, has high latency, and cannot support interactive queries with millisecond-level response times. Summary of the Invention

[0005] This invention proposes a method and system for retrieving live stream segments to improve the aforementioned problems.

[0006] Specifically, this embodiment of the invention provides a live stream segment retrieval method, which includes: S110, performing real-time segmented recording of the live stream, generating a video segment file containing a live stream identifier and an absolute timestamp, storing the video segment file in an object storage service, and triggering a data processing message; S120, in response to the data processing message, extract audio data from the video segment file and split the audio data into transport stream unit files of fixed duration; S130: Obtain multiple transport stream unit files from the object storage service, dynamically concatenate them into multiple audio list files according to preset rules, and organize the audio list files in batches across live streaming rooms to form a batch processing task; S140, Load and configure the open-source speech recognition model, and perform parallel speech recognition on the audio manifest file in the batch processing task to generate text recognition results containing timestamps; S150, The text recognition result is formatted and divided into sentence-level text units. Each text unit, along with its corresponding precise start time, end time, and the identifier of the live broadcast room, is constructed into a fine-grained index document and stored in the search engine. S160: Receive the search keywords input by the user, perform a millisecond-level matching query in the search engine, obtain the matching text units and their spatiotemporal information, locate and aggregate the corresponding video transmission stream unit files from the object storage service according to the spatiotemporal information, and concatenate them in chronological order to generate a video list file that can be played directly.

[0007] Preferably, in step S110, the storage path of the video clip file follows a specific naming rule: the root directory of the path is the live broadcast room identifier, the file name is formed by connecting the absolute start timestamp and absolute end timestamp of the clip in the live broadcast stream with an underscore, and the file extension is .ts.

[0008] Preferably, in step S120, the fixed duration is set to 2 seconds.

[0009] Preferably, in step S130, the total duration of a single audio manifest file does not exceed 30 seconds; and the number of audio manifest files contained in a single batch is 25.

[0010] Preferably, it further includes: disabling specific functional modules in the open-source speech recognition model that are not compatible with the live streaming scenario, wherein the specific functional modules include a masking sound activity detection module and a speaker separation module.

[0011] Preferably, in step S150, the formatting of the text recognition result includes a text segmentation and timing operation. This operation, based on the timestamp information output by the speech recognition model, segments the continuous recognized text at semantic pauses or silence intervals to form independent sentence text units of appropriate length. Each text unit is bound to its precise start and end times to form a complete index entry.

[0012] Preferably, in step S150, the constructed fine-grained index document is stored in the Elasticsearch search engine, and the fields of the index document include at least: single sentence text content, sentence start time, sentence end time, and the live broadcast room ID.

[0013] Preferably, in step S160, locating the video transmission stream unit file from the object storage service based on the spatiotemporal information of the matching text unit specifically involves: determining the file storage root directory based on the "home live room ID", calculating the timestamp range of all transmission stream unit files covering the time interval based on the "start time of the sentence" and the "end time of the sentence", and generating a corresponding file path list.

[0014] This invention also provides a live stream segment retrieval system, which includes: a data acquisition and preprocessing module, used to record the live stream in real time segments, generate video segment files containing live stream identifiers and absolute timestamps, store the video segment files in an object storage service, and trigger data processing messages; The audio extraction and standardization module is used to respond to the data processing message, extract audio data from the video segment file, and split the audio data into transport stream unit files of fixed duration; The audio splicing and batch processing module is used to obtain multiple transport stream unit files from the object storage service, dynamically splice them into multiple audio list files according to preset rules, and organize the audio list files in batches across live streaming rooms to form batch processing tasks. The speech recognition processing module is used to load and configure an open-source speech recognition model, and perform parallel speech recognition on the audio list file in the batch processing task to generate text recognition results containing timestamps; the text indexing and storage module is used to format the text recognition results, divide them into sentence-level text units, and construct a fine-grained index document for each text unit and its corresponding precise start time, end time and the live broadcast room identifier, and store it in the search engine. The retrieval and fragment reconstruction module is used to receive search keywords input by the user, perform millisecond-level matching queries in the search engine, obtain matching text units and their spatiotemporal information, locate and aggregate the corresponding video transport stream unit files from the object storage service according to the spatiotemporal information, and concatenate them in chronological order to generate a video list file that can be played directly.

[0015] Based on the above embodiment, it is possible to achieve an exponential reduction in ASR processing costs, significantly improve the timeliness of ASR processing and fragment retrieval, significantly enhance the system's controllability and stability, and construct a complete low-cost, high-efficiency, and highly available live streaming content retrieval and playback technology system. Attached Figure Description To more clearly illustrate the technical solution of the present invention, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 This is a schematic diagram of the structure of the live broadcast segment retrieval system provided in the first embodiment of the present invention.

[0017] Figure 2 This is a flowchart illustrating the live stream segment retrieval method provided in the second embodiment of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] In the live-streaming e-commerce scenarios of large e-commerce platforms, tens of thousands of live-streaming rooms are broadcasting simultaneously every day, generating massive amounts of live-streaming video content. Platform operators, content review teams, and ordinary users all have a need for quick retrieval and playback of specific live-streaming segments, such as finding a segment where a host explains a specific product, "sunscreen," tracing the original context of a controversial statement, or rewatching a prize draw segment in a live stream. Traditional solutions rely on manual annotation or costly third-party speech recognition services, which cannot meet the needs for low-cost, high-efficiency, and fine-grained retrieval. This invention provides a live-streaming segment retrieval method and system that deeply integrates live-streaming processing, low-cost, high-concurrency speech recognition, fine-grained text indexing, and rapid video segment reconstruction, constructing an efficient, stable, and economical live-streaming content retrieval system.

[0020] The following describes the live stream segment retrieval system according to an embodiment of the present invention. Please refer to... Figure 1 The overall architecture of this system includes a data acquisition and preprocessing module 10, an audio extraction and standardization module 20, an audio splicing and batch processing module 30, a speech recognition processing module 40, a text indexing and storage module 50, and a retrieval and segment reconstruction module 60. These modules work together to form a complete closed loop from live stream input to video segment retrieval output.

[0021] In this embodiment, the data acquisition and preprocessing module 10 can be deployed at the edge node of the live stream distribution network, responsible for real-time segmented recording of the continuously incoming live stream. The core task of this module is to generate structured video segment files. The specific operation process is as follows: the data acquisition and preprocessing module 10 continuously monitors the live stream, and generates an independent video segment file whenever the accumulated recording reaches a preset duration or an interruption of the live stream is detected. The storage path of this file follows strict naming rules. Its root directory is the unique identifier of the live stream room, and the file name is formed by connecting the absolute start timestamp and absolute end timestamp of the segment in the original live stream with an underscore. The file extension is uniformly in transport stream format. For example, a live stream room with a start time of 1765814400 (timestamp), a live stream room ID of 11223344, and a live stream duration of 5 seconds, would have a .ts file named: 11223344 / 1765814400_176581440.ts. This naming convention ensures a unique and reversible mapping between the physical storage location of each video clip in the object storage service and its logical spatiotemporal attributes. After generating the video clip file, the module immediately uploads it to the distributed object storage service, ensuring data persistence and high availability. Upon successful upload, the module publishes a data processing message to the message queue. This message body includes at least the complete storage path of the newly generated video clip file, the live stream identifier, and the timestamp range, thereby triggering subsequent processing.

[0022] In this embodiment, the audio extraction and standardization module 20, as the first link in the asynchronous processing pipeline, continuously listens for data processing messages issued by the data acquisition and preprocessing module 10. Upon receiving a message, the audio extraction and standardization module 20 downloads the corresponding video transport stream unit file from the object storage service according to the file path in the message. After downloading, the audio extraction and standardization module 20 calls the audio and video processing library to perform audio extraction, separating the audio track from the video file and discarding the video data to significantly reduce the amount of data processed subsequently. The extracted raw audio data is typically in pulse code modulation (PCM) format. To adapt to the input format requirements of the subsequent speech recognition model and to achieve standardization of the processing units, the audio extraction and standardization module 20 also resamples and encodes the audio data, uniformly converting it into standardized audio. Subsequently, the audio extraction and standardization module 20 performs a crucial splitting operation, cutting this continuous standardized audio data into segments of fixed duration along the timeline to generate a series of small transport stream unit files. After extensive engineering testing and efficiency considerations, this invention sets the fixed duration to 2 seconds. This setting is based on a comprehensive consideration of the data packet size of the live streaming protocol, network transmission efficiency, and subsequent file management overhead. A 2-second audio file size is moderate, ensuring that individual files are small enough to support highly flexible batch combination and scheduling in subsequent processes, while avoiding the creation of a massive number of small files due to excessive segmentation, which would introduce unbearable metadata management, input / output operations, and network request overhead. Each 2-second streaming unit file is also stored in object storage services, with its filename inherited from the original video segment, but with an added index representing its sequence number within that segment. For example, a live stream with a start time of 1765814400 (timestamp), a live stream ID of 11223344, and a live stream duration of 5 seconds, would have its .ts file split into: 11223344 / 1765814400_1765814402.ts, 11223344 / 1765814402_1765814404.ts, 11223344 / 1765814404_1765814405.ts.

[0023] In this embodiment, the audio splicing and batch processing module 30 is responsible for organizing fine-grained transport stream unit files into batch tasks suitable for large-scale parallel speech recognition processing. The audio splicing and batch processing module 30 periodically scans and retrieves newly generated transport stream unit files from the object storage service. Its processing logic comprises two levels: The first step is file concatenation. The audio concatenation and batch processing module 30, following preset concatenation rules, performs binary concatenation on multiple consecutive transport stream unit files belonging to the same live stream room in memory or temporary storage, combining them into a longer audio list file. A key constraint of the preset rules is that the total duration of a single audio list file cannot exceed 30 seconds. This upper limit was optimized after extensive testing of various speech recognition models under different hardware configurations, focusing on memory usage and inference speed. Limiting the audio length to 30 seconds ensures that the memory usage of a single audio file is strictly controlled at a low level when loaded onto the graphics processor for inference, thus leaving sufficient memory space for high-concurrency batch processing. For example, the module might concatenate 15 consecutive 2-second transport stream unit files from the same live stream room into a 30-second audio list file.

[0024] Secondly, batch organization is a core design element for improving system throughput. The audio splicing and batch processing module 30 does not process audio list files sequentially according to the live stream order, but instead adopts a cross-live stream aggregation strategy. Specifically, the module aggregates multiple audio list files from different live streams into a single processing batch. After repeated stress testing and optimization in a typical 12GB video memory environment, the optimal number of audio list files in a single batch was determined to be 25. This scale ensures that a single speech recognition task can fully utilize the graphics processor's computing units, while simultaneously increasing video memory utilization to near saturation without overflowing. By breaking down live stream boundaries and organizing batches with a fixed number of files, the system can maximize the parallel computing capabilities of the graphics processor, significantly improving the efficiency of audio-to-text conversion. Finally, the audio splicing and batch processing module 30 encapsulates the organized batch (containing 25 audio list files and their corresponding metadata information, such as the source live stream and the original timestamp range) into a batch processing task and submits it to the downstream speech recognition processing module 40.

[0025] In this embodiment, the speech recognition processing module 40 carries the core function of converting massive amounts of audio into searchable text. This embodiment uses an open-source speech recognition model (such as FunASR) as the recognition engine. During initialization, the speech recognition processing module 40 loads pre-trained model weights and configuration files from the model repository. Considering the characteristics of live streaming scenarios, the speech recognition processing module 40 performs a key performance optimization operation: disabling specific functional modules in the model that are incompatible with the current requirements. Specifically, the disabled modules include the sound activity detection module and the speaker separation module. In live streaming scenarios, human voice activity is frequent and continuous; the host's explanations, audience interactions, and other audio content are almost continuous throughout the entire process, and environmental noise is relatively controllable. Therefore, the sound activity detection module, specifically used to detect the start and end of speech, is redundant, and its computation becomes a burden. Simultaneously, the retrieval requirements of this invention focus on the semantic content of the text itself, rather than distinguishing the identities of different speakers; therefore, the speaker separation module is also unnecessary. Disabling these two modules directly reduces the complexity of the model's forward inference computation graph, lowers the frequency of memory access and the amount of data, which is one of the core technical means to achieve an order-of-magnitude improvement in recognition speed. After configuration, the speech recognition processing module 40 receives batch processing tasks from the audio splicing and batch processing module 30. The speech recognition processing module 40 starts multiple parallel processing threads or processes, each thread responsible for processing one audio list file in the batch. These threads share the same model instance loaded into the graphics memory, utilizing the parallel computing capabilities of the graphics processor to simultaneously perform speech recognition inference on 25 audio files. The recognition process outputs structured text results, including not only the recognized text content but, more importantly, the speech recognition processing module 40 outputs the precise start and end timestamps of each word or sentence on the corresponding audio timeline. The recognition results of all files are aggregated to generate a set of timestamped text recognition results, ready for the next stage.

[0026] In this embodiment, the text indexing and storage module 50 is responsible for converting the raw results of speech recognition into structured data that can be efficiently retrieved. The text indexing and storage module 50 first formats the text recognition results, the core of which is text segmentation and timing. The text output by the speech recognition model 40 may be a continuous long segment. Based on the timestamp information output by the model, combined with simple semantic rules (such as detecting punctuation marks and silence intervals), the text indexing and storage module 50 segments the continuous text at appropriate semantic pauses, forming independent sentence text units of suitable length and relatively complete semantics. For example, the recognition result of a 30-second audio clip, "Today I recommend this sunscreen; it has an SPF50+ index and a very refreshing texture," is segmented into two sentence units: "Today I recommend this sunscreen" and "It has an SPF50+ index and a very refreshing texture." Each text unit is strictly bound to its precise start and end times in the original audio. Subsequently, the text indexing and storage module 50 constructs a fine-grained index document based on these sentence units. Each index document is a structured data object, whose fields include at least: single-sentence text content, the start time of the sentence, the end time of the sentence, and the identifier of the live broadcast room. After construction, the text indexing and storage module 50 writes these index documents to the search engine in batches. The search engine uses an inverted index mechanism, which automatically segments the "single-sentence text content" field and establishes a mapping between terms and the document list. This structure ensures that the query response time can be stably kept at the tens of millisecond level, whether it is precise keyword matching, fuzzy matching, or semantic vector-based similarity matching, achieving near real-time retrieval capabilities for massive amounts of live broadcast text content.

[0027] In this embodiment, the retrieval and fragment reconstruction module 60 provides retrieval services to end users. Users input search keywords, such as "sunscreen," into the front-end interface. Upon receiving the query request, the retrieval and fragment reconstruction module 60 immediately executes the query in a search engine (such as Elasticsearch). The search engine returns a list of all matching indexed documents within milliseconds, containing the text content of each matching statement, its precise start and end times, and the identifier of the live stream room it belongs to. After obtaining this spatiotemporal information, the module initiates the video fragment reconstruction process. First, file location is performed: the root directory path in the object storage service is determined based on the "identifier of the live stream room"; based on the "start time" and "end time" of the statement, all 2-second transport stream unit files required to cover the time interval are determined through simple numerical calculations. Since the file naming rules strictly correspond to the timestamps, this location process does not require traversing the file system; a complete file path list can be generated within milliseconds simply by concatenating path templates. Subsequently, the retrieval and fragment reconstruction module 60 downloads these video transport stream unit files in parallel from the object storage service according to the path list. After downloading, the retrieval and segment reconstruction module 60 aggregates the data by live stream room and concatenates files belonging to the same live stream room in binary format according to their timestamps. Finally, the retrieval and segment reconstruction module 60 encapsulates the concatenated video data into a video list file in a standard streaming media playback format. This format is natively supported by mainstream front-end players, allowing users to play the file seamlessly upon receipt. From the moment a user enters a keyword to seeing a live video segment containing that keyword, the entire end-to-end process—from retrieval and location to downloading, concatenation, and return—is controlled within milliseconds, achieving an interactive retrieval experience.

[0028] Compared with existing technologies, this embodiment can effectively reduce costs, improve ASR speed, increase stability, and make retrieval simpler and more direct. Specifically; Regarding cost, this embodiment can reduce the cost from more than 0.5 yuan / hour to about 0.006 yuan / hour.

[0029] The cost reduction is due to deploying open-source models for ASR, removing unnecessary modules, and performing batch ASR operations. For example: Assuming that approximately 20,000 hours of live stream recording data needs to be processed daily, if we follow the external supplier's solution, even with the purchase of resource packages, it would still cost 10,000 yuan per day, totaling 300,000 yuan per month. However, by deploying an open-source model ourselves and using this batch m3u8 file ASR, we only need two 4090D 48G machines, with each machine costing 1,600 yuan per month. This reduces the cost from 300,000 yuan per month to 3,200 yuan per month.

[0030] Regarding processing time, if batch operations are not performed and only the open-source model is deployed, the parallel capabilities of the GPU can be significantly utilized in this scenario. For example, a 750-second video in this scenario may take about 15 seconds to return after processing by the VAD and SPK modules. However, if it is split into 25 30-second files (the time taken to synthesize the 30-second files is negligible due to the splicing of TS files) and redundant modules are removed, the 750-second video can be processed in only 300-500 milliseconds.

[0031] The larger the audio file, the higher the memory usage. In this embodiment, by segmenting the audio file into segments of less than 30 seconds, a certain amount of memory usage can be saved, allowing a single pod to handle more ASR task requests simultaneously.

[0032] Please see Figure 2 The second embodiment of the present invention also provides a method for retrieving live stream segments, comprising: S110, performing real-time segmented recording of the live stream to generate video segment files containing live stream identifiers and absolute timestamps, storing the video segment files in an object storage service, and triggering a data processing message; S120, responding to the data processing message, extracting audio data from the video segment files, and splitting the audio data into transport stream unit files of fixed duration; S130, obtaining multiple transport stream unit files from the object storage service, dynamically splicing them into multiple audio list files according to preset rules, and organizing the audio list files in batches across live streams to form a batch processing task; S140: Load and configure the open-source speech recognition model, and perform parallel speech recognition on the audio list file in the batch processing task to generate text recognition results containing timestamps; S150: Format the text recognition results, divide them into sentence-level text units, and construct a fine-grained index document for each text unit and its corresponding precise start time, end time, and live room identifier, and store it in the search engine; S160: Receive the search keywords input by the user, perform a millisecond-level matching query in the search engine, obtain the matching text units and their spatiotemporal information, and locate and aggregate the corresponding video transport stream unit files from the object storage service according to the spatiotemporal information, and concatenate them in chronological order to generate a video list file that can be played directly.

[0033] Preferably, in step S110, the storage path of the video clip file follows a specific naming rule: the root directory of the path is the live broadcast room identifier, the file name is formed by connecting the absolute start timestamp and absolute end timestamp of the clip in the live broadcast stream with an underscore, and the file extension is .ts.

[0034] Preferably, in step S120, the fixed duration is set to 2 seconds.

[0035] Preferably, in step S130, the total duration of a single audio manifest file does not exceed 30 seconds; and the number of audio manifest files contained in a single batch is 25.

[0036] Preferably, it further includes: disabling specific functional modules in the open-source speech recognition model that are not compatible with the live streaming scenario, wherein the specific functional modules include a masking sound activity detection module and a speaker separation module.

[0037] Preferably, in step S150, the formatting of the text recognition result includes a text segmentation and timing operation. This operation, based on the timestamp information output by the speech recognition model, segments the continuous recognized text at semantic pauses or silence intervals to form independent sentence text units of appropriate length. Each text unit is bound to its precise start and end times to form a complete index entry.

[0038] Preferably, in step S150, the constructed fine-grained index document is stored in the Elasticsearch search engine, and the fields of the index document include at least: single sentence text content, sentence start time, sentence end time, and the live broadcast room ID.

[0039] Preferably, in step S160, locating the video transmission stream unit file from the object storage service based on the spatiotemporal information of the matching text unit specifically involves: determining the file storage root directory based on the "home live room ID", calculating the timestamp range of all transmission stream unit files covering the time interval based on the "start time of the sentence" and the "end time of the sentence", and generating a corresponding file path list.

[0040] The above description is merely a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A method for retrieving live stream segments, characterized in that, include: S110, The live stream is recorded in real time in segments, generating video segment files containing live room identifiers and absolute timestamps, and the video segment files are stored in the object storage service, while triggering a data processing message; S120, in response to the data processing message, extract audio data from the video segment file and split the audio data into transport stream unit files of fixed duration; S130: Obtain multiple transport stream unit files from the object storage service, dynamically concatenate them into multiple audio list files according to preset rules, and organize the audio list files in batches across live streaming rooms to form a batch processing task; S140, Load and configure the open-source speech recognition model, and perform parallel speech recognition on the audio manifest file in the batch processing task to generate text recognition results containing timestamps; S150, The text recognition result is formatted and divided into sentence-level text units. Each text unit, along with its corresponding precise start time, end time, and the identifier of the live broadcast room, is constructed into a fine-grained index document and stored in the search engine. S160: Receive the search keywords input by the user, perform a millisecond-level matching query in the search engine, obtain the matching text units and their spatiotemporal information, locate and aggregate the corresponding video transmission stream unit files from the object storage service according to the spatiotemporal information, and concatenate them in chronological order to generate a video list file that can be played directly.

2. The live stream segment retrieval method according to claim 1, characterized in that, In step S110, the storage path of the video clip file follows a specific naming rule: the root directory of the path is the live broadcast room identifier, the file name is formed by connecting the absolute start timestamp and absolute end timestamp of the clip in the live broadcast stream with an underscore, and the file extension is .ts.

3. The live stream segment retrieval method according to claim 1, characterized in that, In step S120, the fixed duration is set to 2 seconds.

4. The live stream segment retrieval method according to claim 1, characterized in that, In step S130, the total duration of a single audio manifest file does not exceed 30 seconds; the number of audio manifest files contained in a single batch is 25.

5. The live stream segment retrieval method according to claim 1, characterized in that, Also includes: The specific functional modules in the open-source speech recognition model that are not compatible with the live streaming scenario are disabled. These specific functional modules include the masked sound activity detection module and the speaker separation module.

6. The live stream segment retrieval method according to claim 1, characterized in that, In step S150, the formatting of the text recognition result includes a text segmentation and timing operation. This operation, based on the timestamp information output by the speech recognition model, segments the continuous recognized text at semantic pauses or silence intervals to form independent sentence text units of appropriate length. Each text unit is bound to its precise start and end times to form a complete index entry.

7. The live stream segment retrieval method according to claim 1, characterized in that, In step S150, the constructed fine-grained index document is stored in the Elasticsearch search engine. The fields of the index document include at least: the text content of a single sentence, the start time of the sentence, the end time of the sentence, and the live broadcast room ID to which it belongs.

8. The live stream segment retrieval method according to claim 1, characterized in that, In step S160, the video transmission stream unit file is located from the object storage service based on the spatiotemporal information of the matching text unit. Specifically, the file storage root directory is determined based on the "home live room ID", the timestamp range of all transmission stream unit files covering the time interval is calculated based on the "start time of the sentence" and the "end time of the sentence", and the corresponding file path list is generated.

9. A live stream segment retrieval system, characterized in that, include: The data acquisition and preprocessing module is used to record the live stream in real time in segments, generate video segment files containing live room identifiers and absolute timestamps, store the video segment files in the object storage service, and trigger data processing messages at the same time. The audio extraction and standardization module is used to respond to the data processing message, extract audio data from the video segment file, and split the audio data into transport stream unit files of fixed duration; The audio splicing and batch processing module is used to obtain multiple transport stream unit files from the object storage service, dynamically splice them into multiple audio list files according to preset rules, and organize the audio list files in batches across live streaming rooms to form batch processing tasks. The speech recognition processing module is used to load and configure an open-source speech recognition model, and perform parallel speech recognition on the audio list file in the batch processing task to generate text recognition results containing timestamps; the text indexing and storage module is used to format the text recognition results, divide them into sentence-level text units, and construct a fine-grained index document for each text unit and its corresponding precise start time, end time and the live broadcast room identifier, and store it in the search engine. The retrieval and fragment reconstruction module is used to receive search keywords input by the user, perform millisecond-level matching queries in the search engine, obtain matching text units and their spatiotemporal information, locate and aggregate the corresponding video transport stream unit files from the object storage service according to the spatiotemporal information, and concatenate them in chronological order to generate a video list file that can be played directly.

Images