Channel recording method and device of unicast live broadcast source, computer equipment, storage medium and computer program product

Abstract

The invention relates to a channel recording method and device of a unicast live broadcast source, computer equipment, a storage medium and a computer program product. Relates to the video live broadcast field. The method comprises the following steps: initiating a main index request for a unicast live broadcast source of a hypertext live broadcast stream, analyzing and obtaining a link address of a sub-index file based on a response result, periodically initiating a sub-index request, and analyzing returned index content to obtain a fragment file newly added relative to a previous request period; based on the acquisition sequence, sequentially initiating file list requests, and storing the received files in a buffer area; and under the condition that no new fragment is added in the current request period, ending the current request period, and starting the next request period after a preset time interval so as to carry out channel recording of the unicast live broadcast source. By adopting the method, the reliability and the updating timeliness of the access data when the channel recording method faces an HLS unicast live broadcast source in an IPTV scene can be ensured.

Description

Technical Field

[0001] This application relates to the field of video live streaming technology, and in particular to a channel recording method, apparatus, computer equipment, storage medium, and computer program product for a unicast live streaming source. Background Technology

[0002] HLS (HTTP Live Streaming), as a streaming media transmission protocol, is widely used in IPTV (Internet Protocol TV) live streaming, time-shifting, and playback scenarios. Based on the HTTP (Hypertext Transfer Protocol) fragmentation transmission mechanism and adaptive bitrate capability, it boasts good network compatibility and playback stability. However, in certain IPTV deployment environments, some live channel sources are only pushed by the encoder in HLS unicast form, or network isolation limitations prevent regional and edge nodes from directly accessing multicast sources.

[0003] The channel recording function in current IPTV systems is mainly designed for multicast streams. When facing HLS unicast sources, the data stream cannot be obtained if a passive receiving method is used. The simple file download method lacks an intelligent recognition mechanism for new content, which can easily lead to duplicate downloads or missing segments. Furthermore, it cannot flexibly adapt to the different requirements of HLS slicing parameters in different regions, affecting the subsequent playback quality.

[0004] Therefore, existing channel recording methods suffer from unreliable data access and untimely updates when dealing with HLS unicast live sources in IPTV scenarios. Summary of the Invention

[0005] Based on this, it is necessary to address the aforementioned technical problems of unreliable data access and untimely updates in existing channel recording methods when dealing with HLS unicast live sources in IPTV scenarios. This paper proposes a channel recording method, apparatus, computer equipment, computer-readable storage medium, and computer program product for unicast live sources.

[0006] Firstly, this application provides a method for recording channels of a unicast live source, applied to a streaming media server, including:

[0007] Initiate a main index request for the unicast live source of the hypertext live stream, and parse and obtain the link address of the sub-index file based on the response result;

[0008] Based on the link address of the sub-index file, sub-index requests are periodically initiated, and the returned index content is parsed to obtain the newly added fragment files relative to the previous request cycle.

[0009] Based on the acquisition order of the newly added fragment files, file list requests are sent to the newly added fragment files in sequence, and the received files are stored in the buffer to trigger the data processing flow;

[0010] If no new segments are added during the current request period, the current request period ends, and the next request period starts after a preset time interval to record the channel of the unicast live source.

[0011] In one embodiment, parsing the returned index content to obtain the newly added shard files relative to the previous request cycle includes: obtaining the first timestamp of the last processed shard file in the previous request cycle; obtaining multiple shard files in the current sub-index file and a second timestamp set corresponding to the multiple shard files; and comparing the size of each timestamp in the second timestamp set with the size of the first timestamp to determine the newly added shard files relative to the previous request cycle.

[0012] In one embodiment, the step of comparing the size of each timestamp in the second timestamp set with the size of the first timestamp to determine the newly added fragment file relative to the previous request period includes: determining the fragment files in the second timestamp set that are larger than the first timestamp as newly added fragment files relative to the previous request period.

[0013] In one embodiment, parsing the returned index content to obtain the newly added shard files relative to the previous request cycle further includes: obtaining the first sequence number of the last processed shard file in the previous request cycle; obtaining multiple shard files in the current sub-index file and a second sequence number set corresponding to the multiple shard files; comparing the difference between each sequence number in the second sequence number set and the first sequence number, and selecting a target number of shard files based on the difference to determine them as newly added shard files relative to the previous request cycle.

[0014] In one embodiment, the step of sequentially initiating file list requests to the newly added file segments based on the acquisition order of the newly added file segments, and storing the received files in a buffer to trigger a data processing flow, includes: establishing a request sequence based on the acquisition order of the newly added file segments; allocating a corresponding buffer for each file segment sequentially based on the request sequence, and storing the received file segments in the buffer in real time; and after completing the storage of any one file segment, triggering the data processing flow to process the file segments in the buffer.

[0015] In one embodiment, before triggering the data processing flow to process the fragmented file in the buffer, the method further includes: detecting the integrity of the data in the fragmented file.

[0016] In one embodiment, detecting the integrity of the data in the fragment file includes: comparing the actual size of the data in the fragment file with the labeled size in a preset index file; and determining that the fragment file has missing data if the actual size is inconsistent with the labeled size.

[0017] In one embodiment, after determining that the fragment file has missing data, the process includes: for the fragment file with missing data, filling in the missing data until the actual size is consistent with the labeled size.

[0018] In one embodiment, after storing the received file into the buffer, the process includes: establishing a unique data slot for each of the fragment files and writing the data of each fragment file into the corresponding slot; sending a notification to a preset parsing module to control the preset parsing module to read data from each of the slots.

[0019] In one embodiment, after storing the received file in the buffer to trigger the data processing flow, the method further includes: generating information containing the data address, data size, data name, and timestamp corresponding to the data based on the received file; and sending the information to a message queue so that a preset parsing module can start a parsing task based on the content of the information.

[0020] In one embodiment, the parsed data is divided into storage units of fixed duration according to a preset time length; a file name and index record corresponding to each storage unit are generated, and the information in the historical database is updated. The historical database includes files of channel recordings of each unicast live source in history.

[0021] Secondly, this application also provides a channel recording device for a unicast live source, comprising:

[0022] The request parsing module is used to initiate a main index request for the unicast live source of the hypertext live stream, and parse and obtain the link address of the sub-index file based on the response result;

[0023] The request parsing module is also used to periodically initiate sub-index requests based on the link address of the sub-index file, and parse the returned index content to obtain the newly added fragment files relative to the previous request cycle.

[0024] The file storage module is used to initiate file list requests to the newly added file segments sequentially based on the acquisition order of the newly added file segments, and store the received files in the buffer to trigger the data processing flow.

[0025] The channel recording module is used to end the current request cycle when no new segments are added during the current request cycle, and start the next request cycle after a preset time interval to record the channel of the unicast live source.

[0026] Thirdly, this application also provides a computer device, the computer device including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to perform the following steps:

[0027] Initiate a main index request for the unicast live source of the hypertext live stream, and parse and obtain the link address of the sub-index file based on the response result;

[0028] Based on the link address of the sub-index file, sub-index requests are periodically initiated, and the returned index content is parsed to obtain the newly added fragment files relative to the previous request cycle.

[0029] Based on the acquisition order of the newly added fragment files, file list requests are sent to the newly added fragment files in sequence, and the received files are stored in the buffer to trigger the data processing flow;

[0030] If no new segments are added during the current request period, the current request period ends, and the next request period starts after a preset time interval to record the channel of the unicast live source.

[0031] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0032] Initiate a main index request for the unicast live source of the hypertext live stream, and parse and obtain the link address of the sub-index file based on the response result;

[0033] Based on the link address of the sub-index file, sub-index requests are periodically initiated, and the returned index content is parsed to obtain the newly added fragment files relative to the previous request cycle.

[0034] Based on the acquisition order of the newly added fragment files, file list requests are sent to the newly added fragment files in sequence, and the received files are stored in the buffer to trigger the data processing flow;

[0035] If no new segments are added during the current request period, the current request period ends, and the next request period starts after a preset time interval to record the channel of the unicast live source.

[0036] Fifthly, this application also provides a computer program product, which includes a computer program that, when executed by a processor, performs the following steps:

[0037] Initiate a main index request for the unicast live source of the hypertext live stream, and parse and obtain the link address of the sub-index file based on the response result;

[0038] Based on the link address of the sub-index file, sub-index requests are periodically initiated, and the returned index content is parsed to obtain the newly added fragment files relative to the previous request cycle.

[0039] Based on the acquisition order of the newly added fragment files, file list requests are sent to the newly added fragment files in sequence, and the received files are stored in the buffer to trigger the data processing flow;

[0040] If no new segments are added during the current request period, the current request period ends, and the next request period starts after a preset time interval to record the channel of the unicast live source.

[0041] The aforementioned channel recording method, apparatus, computer equipment, storage medium, and computer program product for unicast live streaming sources, during the channel recording process of a unicast live streaming source, first initiates a main index request for the unicast live streaming source of the hypertext live stream, and obtains the link address of the sub-index file based on the response result; then, according to the link address of the sub-index file, it periodically initiates sub-index requests, and parses the returned index content to obtain the newly added segment files relative to the previous request cycle; next, based on the acquisition order of the newly added segment files, it sequentially initiates file list requests to the newly added segment files, and stores the received files in a buffer to trigger the data processing flow; and if no new segment is added in the current request cycle, it ends the current request cycle and starts the next request cycle after a preset time interval to perform channel recording of the unicast live streaming source. In the above process, to address the access requirements of HLS unicast live streaming sources in IPTV scenarios, a step-by-step design is adopted, which involves parsing sub-index file links using the main index request, capturing newly added fragment files using periodic sub-index requests, and requesting and caching fragment files in sequence. This ensures the reliability and timeliness of data access. Furthermore, the hierarchical request mechanism of the main index and sub-index ensures the accuracy of live streaming source link parsing and avoids link acquisition failures caused by complex index levels. The periodic sub-index request strategy can capture newly added fragment files in real time, meeting the timeliness requirements of live recording. The combination of sequential fragment file requests and buffer storage ensures the continuity of data transmission and processing, avoids file corruption or loss, and further guarantees the reliability and timeliness of access data for the channel recording method when facing HLS unicast live streaming sources in IPTV scenarios. Attached Figure Description

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

[0043] Figure 1 This is a flowchart illustrating a channel recording method for a unicast live streaming source in one embodiment.

[0044] Figure 2 This is a flowchart illustrating a channel recording method for a unicast live streaming source in another embodiment;

[0045] Figure 3 This is a schematic diagram of the live streaming service architecture for a channel recording method of a unicast live streaming source in one embodiment;

[0046] Figure 4 This is a schematic diagram of the file content of a channel recording method for a unicast live streaming source in one embodiment;

[0047] Figure 5 This is a schematic diagram of the unicast source channel recording process in one embodiment of the unicast live source channel recording method;

[0048] Figure 6 This is a schematic diagram of the unicast stream receiving request interaction in a channel recording method for a unicast live source in one embodiment;

[0049] Figure 7 This is a schematic diagram comparing the recording architecture of unicast and multicast sources in a channel recording method for unicast live streaming sources in one embodiment.

[0050] Figure 8 This is a structural block diagram of a channel recording device for a unicast live source in one embodiment;

[0051] Figure 9 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0053] IPTV (Internet Protocol TV) live streaming service primarily refers to end users receiving and watching television channel programs in real time. Users can also view recorded programs through live time-shifting and replay functions for exciting moments. In the IPTV live streaming service architecture, channel sources are typically provided via multicast, requiring a streaming media server to record and process the multicast content. The streaming media server's functional modules include: receiving and caching, parsing, storage, and media services. Its main responsibilities include receiving the multicast stream from the channel, storing it in a buffer, parsing the video stream, storing the content as required, and ultimately enabling live streaming, time-shifting, and replay services for the terminal.

[0054] Currently, commonly used video streaming protocols include RTSP (Real-Time Streaming Protocol), HLS (HTTP Live Streaming), and HPD (Hypertext Protocol Delivery). Among them, HLS, based on the HTTP protocol, exhibits significant advantages in network compatibility and video distribution, and is widely used. The core principle of the HLS protocol is to divide the original audio and video files into short segment files (TS, Transport Stream format), and to achieve dynamic bitrate switching and playback control through an index file (M3U8). The segment duration is an important parameter for controlling the playback effect. To support the HLS protocol, the streaming media server needs to divide the data into multiple small TS segments according to the configured segment duration during parsing and store them. Simultaneously, it records relevant information for each segment to provide an index file. Currently, channel recording methods in IPTV scenarios are mostly applicable to multicast sources. However, in certain provinces, some live sources push live HLS unicast URLs (Uniform Resource Locators) via encoders, or only the central server can access the multicast source, while regional and edge servers cannot connect due to network limitations. In the special case where the channel access source is an HLS unicast source, traditional multicast recording is no longer fully applicable. Directly downloading and storing index information and TS files does not allow for flexible configuration of HLS segmentation parameters for each region's service. Therefore, existing channel recording methods suffer from unreliable data access and untimely updates when dealing with HLS unicast live sources in IPTV scenarios.

[0055] To address the technical issues of unreliable data access and untimely updates in existing channel recording methods when dealing with HLS unicast live sources in IPTV scenarios, in one embodiment, such as... Figure 1 As shown, a method for recording channels from a unicast live streaming source is provided. This embodiment illustrates the application of this method to a streaming media server. In this embodiment, the method includes the following steps:

[0056] Step S102: Initiate a main index request for the unicast live source of the hypertext live stream, and obtain the link address of the sub-index file based on the response result.

[0057] Among them, the hypertext live stream is an adaptive bitrate streaming media transmission protocol based on the HTTP protocol; the unicast live source is a live data source that adopts the unicast transmission mode, that is, the server and the client establish a one-to-one communication link, and each client independently receives the live data stream, which is different from multicast (one-to-many) and broadcast (one-to-all); the main index request is a network request initiated by the client to the server to obtain the main index file of the HLS live source. The main index file can contain core configurations such as the link address of the sub-index file and the bitrate information; the sub-index file is a secondary index file pointed to by the main index file, which can contain the link address of the specific live segment file, the segment duration, etc.

[0058] Step S104: Based on the link address of the sub-index file, periodically initiate sub-index requests and parse the returned index content to obtain the newly added fragment files relative to the previous request cycle.

[0059] The periodic initiation of sub-index requests involves repeatedly sending sub-index requests to the server at preset time intervals to obtain the latest sub-index content and capture newly added shard files. Newly added shard files are the shard files added to the sub-index files obtained in the current request cycle compared to the previous request cycle.

[0060] Step S106: Based on the acquisition order of the newly added fragment files, file list requests are sent to the newly added fragment files in sequence, and the received files are stored in the buffer to trigger the data processing flow.

[0061] The file list request is a network request initiated sequentially to download the file segments based on the link addresses of the newly added segment files; buffer storage is the process of temporarily storing the downloaded segment files in memory or local cache area. The buffer can provide functions such as data temporary storage, sequential sorting, and read / write isolation to avoid data loss due to slow file writing speed; the data processing flow is the processing operation performed on the segment files stored in the buffer, which can include segment verification, audio and video decoding, file merging, format conversion, etc.

[0062] Step S108: If no new segments are added during the current request period, end the current request period and start the next request period after a preset time interval to record the channel of the unicast live source.

[0063] The preset time interval is the length of time after pausing the request and restarting the next request cycle when no new segment files are added; channel recording is the process of continuously storing the real-time content of the HLS unicast live source as a video file that can be accessed locally or in the cloud through the above-mentioned steps of index request, segment acquisition, and data processing.

[0064] In the aforementioned method for recording channels of a unicast live stream source, a main index request for the unicast live stream source of the hypertext live stream is first initiated, and the link address of the sub-index file is obtained by parsing the response result. Then, based on the link address of the sub-index file, sub-index requests are periodically initiated, and the returned index content is parsed to obtain the newly added fragment files relative to the previous request cycle. Next, based on the acquisition order of the newly added fragment files, file list requests are initiated to the newly added fragment files in sequence, and the received files are stored in a buffer to trigger the data processing flow. If no new fragments are added in the current request cycle, the current request cycle ends, and the next request cycle is started after a preset time interval to perform channel recording of the unicast live stream source. In the above process, to address the access requirements of HLS unicast live streaming sources in IPTV scenarios, a step-by-step design is adopted, which involves parsing sub-index file links using the main index request, capturing newly added fragment files using periodic sub-index requests, and requesting and caching fragment files in sequence. This ensures the reliability and timeliness of data access. Furthermore, the hierarchical request mechanism of the main index and sub-index ensures the accuracy of live streaming source link parsing and avoids link acquisition failures caused by complex index levels. The periodic sub-index request strategy can capture newly added fragment files in real time, meeting the timeliness requirements of live recording. The combination of sequential fragment file requests and buffer storage ensures the continuity of data transmission and processing, avoids file corruption or loss, and further guarantees the reliability and timeliness of access data for the channel recording method when facing HLS unicast live streaming sources in IPTV scenarios.

[0065] In one exemplary embodiment, parsing the returned index content to obtain the newly added fragment files relative to the previous request cycle includes:

[0066] Get the first timestamp of the last processed shard file in the previous request cycle; get multiple shard files in the current sub-index file and the set of second timestamps corresponding to the multiple shard files; compare the size of each timestamp in the second timestamp set with the size of the first timestamp to determine the shard file added relative to the previous request cycle.

[0067] The first timestamp refers to the timestamp of the last shard file that has been downloaded, verified, stored or processed in the previous request cycle; the second timestamp set is the set of timestamps that are parsed from the sub-index file in the current request cycle and correspond one-to-one with multiple shard files; the shard file timestamp comparison is the process of comparing each timestamp in the second timestamp set with the first timestamp to select the shard files that meet the new conditions.

[0068] In this embodiment, the first timestamp of the processed segments from the previous cycle is extracted as a benchmark, and compared one by one with the second timestamp set of the current sub-index files. Only the segments with timestamps greater than the benchmark value are selected, which effectively avoids repeatedly obtaining processed content or missing newly added segments, ensuring the continuity and integrity of live recording and improving transmission and storage efficiency.

[0069] In one embodiment, comparing the size of each timestamp in the second timestamp set with the size of the first timestamp to determine the newly added fragment files relative to the previous request period includes: determining the fragment files in the second timestamp set that are larger than the first timestamp as newly added fragment files relative to the previous request period.

[0070] The new shard file is based on the core basis of timestamp value comparison. The shard file with timestamp greater than the first timestamp in the second timestamp set is identified as the standardized judgment criterion for new shards after the previous request cycle. By comparing the quantified time dimension threshold with the value of the object to be judged, the new shards can be quickly filtered. The order of timestamps corresponds to the order of shard generation.

[0071] In this embodiment, by using explicit numerical comparison logic, the generation sequence of the segment files is directly correlated, avoiding repeated recording of processed segments or omission of newly added content, thus ensuring the continuity of HLS unicast live stream recording; at the same time, it reduces invalid network requests and duplicate storage, improving the overall operating efficiency of the recording system.

[0072] More specifically, in one embodiment, parsing the returned index content to obtain the newly added fragment files relative to the previous request cycle further includes:

[0073] Get the first sequence number of the last processed shard file in the previous request cycle; get multiple shard files in the current sub-index file and the set of second sequence numbers corresponding to the multiple shard files; compare the difference between each sequence number in the second sequence number set and the first sequence number, select the target number of shard files based on the difference, and determine them as the newly added shard files relative to the previous request cycle.

[0074] The first sequence number is the sequence identifier corresponding to the last shard file that has completed all processing in the previous request cycle; the second sequence number set is the set of sequence identifiers parsed from the sub-index file in the current request cycle, which corresponds one-to-one with multiple shard files; the sequence number difference comparison is the process of subtracting each number in the second sequence number set from the first sequence number to obtain the difference between each shard number and the base number, and determining whether the shard is new content based on the difference; the target quantity is a preset threshold for the number of new shard files selected based on the sequence number difference.

[0075] In this embodiment, by comparing the difference between each sequence number in the second sequence number set and the first sequence number, a target number of segment files are selected based on the difference, and these segment files are determined to be newly added relative to the previous request cycle, which can improve the overall operating efficiency of the recording system.

[0076] In one embodiment, based on the order in which the newly added file segments are acquired, file list requests are sequentially sent to the newly added file segments, and the received files are stored in a buffer to trigger a data processing flow, including:

[0077] A request sequence is established based on the order in which the newly added fragment files are acquired; a corresponding buffer is allocated for each fragment file in turn based on the request sequence, and the received fragment files are stored in the buffer in real time; after the storage of any fragment file is completed, the data processing flow is triggered to process the fragment files in the buffer.

[0078] The request sequence is an ordered queue built based on the order in which new file chunks are acquired; buffer allocation is an independent memory or storage area allocated separately for each file chunk in the request sequence; real-time storage to the buffer means that the downloaded data of the file chunk is written to the corresponding dedicated buffer in real time via network stream, without waiting for the entire file to be downloaded before storage, realizing a streaming processing mode of downloading and storing simultaneously; the file chunk storage completion triggering mechanism is a preset trigger condition used to detect whether the file chunk has been completely written to the dedicated buffer; buffer file chunk processing is a targeted processing operation performed on the complete file chunk stored in the dedicated buffer after the data processing flow is triggered.

[0079] Furthermore, in one embodiment, before triggering the data processing flow to process the fragmented files in the buffer, the method further includes: detecting the integrity of the data in the fragmented files.

[0080] Furthermore, in one embodiment, detecting the integrity of the data in the fragmented file includes: comparing the actual size of the data in the fragmented file with the labeled size in a preset index file; and determining that there is data missing in the fragmented file if the actual size is inconsistent with the labeled size.

[0081] Among them, the actual size of the fragment file is the actual storage space occupied in the buffer after the fragment file is downloaded through the network; the preset index file labeled size is the theoretical data size of the corresponding fragment file in the sub-index file of the HLS live source; the size consistency comparison is the process of comparing the actual size of the fragment file with the preset index file labeled size to determine whether the two meet the preset consistency conditions; the data missing determination is the process of determining that some data in the fragment file has not been downloaded or the data transmission has been lost when the size consistency comparison result does not meet the preset conditions.

[0082] In this embodiment, by comparing the actual size of the segment file with the size marked in the preset index file, a quantitative integrity verification standard is established. This can quickly identify missing or corrupted files during data transmission, prevent incomplete segments from entering subsequent processing, ensure the integrity of HLS unicast live recording content, shorten verification time, and improve recording efficiency.

[0083] In one embodiment, after determining that there is missing data in the fragment file, the method includes: for the fragment file with missing data, filling in the missing data until the actual size matches the labeled size.

[0084] Among them, the data missing fragment completion mechanism is a standardized process that, after size consistency comparison, determines that the fragment file is missing data, and uses specific technical means to supplement the missing data fragments until the actual size of the fragment file is completely consistent with the size marked in the preset index file.

[0085] In this embodiment, by locating the range of missing data and initiating targeted retransmission, the missing parts are accurately supplemented until the actual size matches the labeled size. This avoids the invalidation of segment files or the incomplete recording content due to the loss of some data, ensuring the integrity of the HLS unicast live stream and significantly improving the overall operating efficiency of the recording system.

[0086] In an exemplary embodiment, after storing the received file into the buffer, the process includes: establishing a unique data slot for each fragment file and writing the data of each fragment file into the corresponding slot; sending a notification to the preset parsing module to control the preset parsing module to read data from each slot.

[0087] Among them, the unique identifier of the fragment file is the identification information assigned to each fragment file to uniquely distinguish different fragments; the data slot is a structured storage unit established based on the unique identifier of the fragment file and used to exclusively store the complete data of a single fragment file; the parsing module notification mechanism is the data sent by the storage module to the preset parsing module after completing the writing of fragment file data to the corresponding slot; after receiving the notification, the preset parsing module for slot data reading control reads data from the corresponding data slot according to preset rules based on the slot ID and fragment unique identifier in the notification.

[0088] In this embodiment, by assigning a unique identifier to a dedicated data slot for each file segment, precise mapping is achieved, avoiding confusion or overwriting of data from multiple segments, ensuring that the live stream parsing is consistent with the original segment timing, reducing unnecessary resource consumption, and improving the collaborative efficiency of storage and parsing.

[0089] In one embodiment, after storing the received file in a buffer to trigger the data processing flow, the method further includes: generating information containing the file's data address, data size, data name, and the timestamp corresponding to the data based on the received file; and sending the information to a message queue so that a preset parsing module can start a parsing task based on the content of the information.

[0090] Among them, the fragmented file metadata is a structured data set generated based on the received fragmented files to describe the core attributes of the files; the data address is the access address of the fragmented file in the storage system; the message queue is middleware used to temporarily store the fragmented file metadata and realize asynchronous communication between the storage module and the parsing module; the parsing task startup mechanism is a standardized process in which the parsing module automatically triggers the parsing operation based on the fragmented file metadata obtained from the message queue.

[0091] In this embodiment, by sending information to a message queue, the preset parsing module can start a parsing task based on the content of the information, which can reduce the data parsing time, improve the data parsing efficiency, and thus improve the efficiency of live recording.

[0092] In another embodiment, the parsed data is divided into storage units of fixed duration according to a preset time length; a file name and index record corresponding to each storage unit are generated, and the information in the historical database is updated. The historical database includes the channel recording files of each unicast live source in history.

[0093] The fixed-duration storage unit is an independent video storage unit formed by dividing the parsed continuous live data stream according to a preset fixed time length. The storage unit index record is a structured index data generated for each fixed-duration storage unit to describe its core attributes and storage location. It can include information such as file name, storage path, start timestamp, end timestamp, file size, and live source identifier. The historical database is a structured database used to centrally store and manage all unicast live source channel recording-related data. The historical database information update mechanism is a process in which the index record of a new fixed-duration storage unit is synchronously written into the historical database and the relevant statistical information is updated after the new fixed-duration storage unit is generated, ensuring the real-time consistency between the historical database data and the actual recorded files.

[0094] In this embodiment, by dividing the parsed data into fixed-duration storage units, problems such as storage redundancy and management difficulties caused by excessively large single files are avoided, thus realizing modular management of recorded content; structured file name generation rules and index records ensure that each storage unit has a unique identifier and traceability, which facilitates subsequent rapid identification, classification and storage, and ensures the efficiency of IPTV channel recording.

[0095] This application provides a method for recording channels from a unicast live streaming source. To better understand the process of the aforementioned method for recording channels from a unicast live streaming source, combined with... Figures 2-7 As shown below, the specific process of a channel recording method for a unicast live source according to this application is described in detail, including the following steps:

[0096] Step S202, Index file request and parsing.

[0097] The streaming media server first sends a main m3u8 request to the unicast source based on the source URL. If the request response is abnormal, a timer is added to continue probing the request after a certain interval until the unicast source responds normally. If the request responds normally, the response content is parsed, the URL of the sub-m3u8 is analyzed and recorded. To obtain fragment information, the server sends a sub-m3u8 request. If the response fails, the server attempts to send the sub-m3u8 request N times consecutively. After N failures, it rolls back to request the main m3u8. If the response is successful, the sub-m3u8 content is parsed. A diagram of the sub-m3u8 content is shown below. Figure 4 As shown, this includes information about the overall stream and the URLs of the latest N TS fragments. The URLs of each TS fragment can be analyzed and obtained. During the initial parsing of the sub-m3u8 file, all fragments need to be added to the subsequent request list. However, subsequent sub-m3u8 files may contain duplicate TS fragments; therefore, newly added fragment URLs need to be filtered out and added to the request list to avoid duplicate requests. There are two filtering methods:

[0098] 1) When the TS file name contains timestamp information, the timestamp of the latest TS file is recorded in each analysis. The filtering condition for the shard is: the shard timestamp information TS_timestamp is greater than the latest timestamp of the previous shard (TS_timestamp>Latest_timestamp). After filtering, the latest timestamp is updated for the next comparison.

[0099] 2) If the TS file name does not contain a timestamp, record the sequence number of the starting segment in the M3u8 file each time (#EXT-X-MEDIA-SEQUENCE tag). The number of newly added segments is calculated as the difference between the current sequence number and the previous sequence number. Select the corresponding number of segments from the list from the end to the beginning. If they are completely equal, no new segments are added within the interval.

[0100] Step S204: Fragment file request and integrity check.

[0101] After updating the TS fragment request list, the corresponding newly added TS files are immediately requested in sequence. After each request, the response header information is analyzed first, and the response size (content-length field) is recorded. Then, the actual data stream is received, using a receiving-and-processing method. Each received packet is stored in a buffer and connected to the subsequent parser for timely analysis and slicing. Finally, when the entire request has been received, it is necessary to check whether the response of the TS file is complete, that is, to determine whether the actual received content size is consistent with the size in the response header. If they are consistent, it means that the response is normal and the data has been fully received, and the next TS fragment can be requested. If they are inconsistent, a range request is initiated to obtain the missing part. For example, if the actual received data size is N bytes, the TS file is re-requested with the request header Range:bytes=N-.

[0102] In each request cycle, all TS fragments in the list need to be requested, and the sub-m3u8 needs to be requested again immediately. The process of checking and requesting TS fragments is repeated until no new fragments are added. The above process of requesting sub-m3u8 fragments, adding new TS fragments, and finally confirming that no new fragments are added in the sub-m3u8 fragments is counted as one request cycle. After the end of this cycle, a timer is set according to the maximum fragment duration T (#EXT-X-TAGRETDURATION tag) parsed from the final sub-m3u8 fragment. After time T, the above operation is repeated, and the latest fragments are retrieved in this loop.

[0103] Step S206: Reuse existing multicast recordings.

[0104] In this system, after a TS request, the received data stream is immediately stored in a buffer. The parser can directly process the data in the buffer, perform slicing, and write the data to disk. The buffer can be cleaned up and recycled in a timely manner after writing to disk. Through the buffer, the parser can be reused for multicast and unicast recording. This separation of the receiving and parsing modules facilitates support for both multicast and unicast channel access methods. When accessing a multicast source, the multicast address can be directly added to obtain the video stream data. When accessing an HLS unicast source, a terminal-like active method is used to pull and obtain the data. At the same time, it also makes channel recording more flexible, supporting various media protocols. Even when providing the same HLS service, it supports various configuration adjustments for parameters such as slice duration and the number of slices in the index, without being limited by the unicast source.

[0105] Through the above embodiments, for HLS unicast live streaming sources in IPTV scenarios, a complete request cycle is defined as requesting a sub-index to detect newly added TS files, requesting a newly added TS list, and requesting a sub-m3u8 to detect no newly added files. The maximum fragment duration in the index file is used as the cycle interval. The buffer of the original parser for processing TS requests is reused to achieve timely access and flexible parsing of HLS unicast source data, making the multicast architecture compatible with unicast access methods. When filtering newly added fragments, two methods are provided: filtering based on fragment timestamp and index file sequence number. The filtering method can be flexibly set according to whether the fragment information in the HLS unicast source index contains a timestamp, thereby quickly and efficiently filtering out newly added fragments, and it is applicable to all standard HLS unicast sources. The integrity detection and re-request of TS fragments are proposed. At the end of the transmission of a TS fragment, the content-length value in the response header is compared with the size of the actual received data stream to confirm the integrity of the fragment transmission. If there is a missing part, the range method is used to repeatedly request the missing part of the TS fragment, which to a certain extent solves the problem of data loss caused by unicast source service abnormalities or network abnormalities.

[0106] More specifically, during channel injection into an HLS unicast source, the streaming media server initiates index requests and TS fragment requests in a loop based on the unicast source URL, and performs corresponding parsing, such as... Figure 5 This paper proposes a proactive channel recording method and system. In this embodiment, the streaming media server adopts terminal-like behavior to proactively request streaming data from the HLS unicast source. The overall interaction process is described in [link to documentation]. Figure 6The process begins by probing the main index (m3u8) and analyzing the URLs of the sub-indexes (m3u8). Then, sub-index requests are initiated sequentially, valid information in the sub-index files is analyzed, and newly added fragments are filtered. Newly added TS fragments are requested in order until no new fragments are detected when a sub-index request is initiated again. This constitutes one request cycle. After the current cycle ends, the next cycle begins after a maximum fragment duration interval. During a single request cycle, when filtering newly added fragments, the TS fragment timestamp or the sequence number in the index file can be flexibly set based on the actual situation of the source for rapid comparison and filtering. When requesting the list of newly added TS files in order, the received data is stored in a buffer and connected to the subsequent parsing module. This allows for direct reuse of the parsing, storage, and service capabilities of the original multicast architecture, providing unicast compatibility on top of the multicast architecture. Access methods: Integrity checks are performed upon completion of each TS file reception. If a fragment is incomplete, a new range request is initiated to retrieve the missing portion before requesting subsequent fragments. The periodic proactive request streaming access method ensures timely access and updates of audio and video stream content to the greatest extent possible. Flexible fragment filtering during the index analysis phase improves request efficiency and is universally applicable to all HLS unicast sources. Integrity checks during the TS request phase can resolve issues such as data loss caused by unicast source service anomalies or network anomalies. Reusing the multicast architecture's stream parsing module facilitates flexible stream parsing, making the live streaming architecture compatible with both multicast and unicast channel access methods. When accessing a multicast source, video stream data can be directly obtained. When accessing an HLS unicast source, a loop-based proactive data retrieval method is used, and playback of multiple protocols is supported.

[0107] More specifically, this embodiment is applicable to channel recording scenarios for HLS unicast live streaming sources, and a comparison diagram of the recording architecture with that of multicast sources is shown below. Figure 7 As shown.

[0108] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0109] Based on the same inventive concept, this application also provides a channel recording device for a unicast live source to implement the channel recording method for the unicast live source described above. The solution provided by this device is similar to the solution described in the above method. Therefore, the specific limitations in one or more embodiments of the channel recording device for a unicast live source provided below can be found in the limitations of the channel recording method for the unicast live source described above, and will not be repeated here.

[0110] In one exemplary embodiment, such as Figure 8 As shown, a channel recording device for a unicast live source is provided, including: a request parsing module 801, a file storage module 802, and a channel recording module 803, wherein:

[0111] The request parsing module 801 is used to initiate a main index request for the unicast live source of the hypertext live stream, and to parse and obtain the link address of the sub-index file based on the response result.

[0112] The request parsing module 801 is also used to periodically initiate sub-index requests based on the link address of the sub-index file, and parse the returned index content to obtain the newly added fragment files relative to the previous request cycle.

[0113] The file storage module 802 is used to send file list requests to the newly added file segments in sequence based on the acquisition order of the newly added file segments, and store the received files in the buffer to trigger the data processing flow.

[0114] The channel recording module 803 is used to end the current request cycle and start the next request cycle after a preset time interval if no new segments are added during the current request cycle, so as to perform channel recording of the unicast live source.

[0115] Furthermore, in one embodiment, the request parsing module 801 is also used to obtain the first timestamp of the last processed shard file in the previous request cycle; obtain multiple shard files in the current sub-index file and the second timestamp set corresponding to the multiple shard files; and compare the size of each timestamp in the second timestamp set with the size of the first timestamp to determine the shard file newly added relative to the previous request cycle.

[0116] Furthermore, in one embodiment, the request parsing module 801 is also used to determine the fragment files in the second timestamp set that are greater than the first timestamp as newly added fragment files relative to the previous request period.

[0117] Furthermore, in one embodiment, the request parsing module 801 is also used to obtain the first sequence number of the last processed fragment file in the previous request cycle; obtain multiple fragment files in the current sub-index file and the second sequence number set corresponding to the multiple fragment files; compare the difference between each sequence number in the second sequence number set and the first sequence number respectively, select a target number of fragment files based on the difference, and determine them as newly added fragment files relative to the previous request cycle.

[0118] Furthermore, in one embodiment, the file storage module 802 is also used to establish a request sequence based on the acquisition order of the newly added segmented files; allocate a corresponding buffer for each segmented file in turn based on the request sequence, and store the received segmented files into the buffer in real time; after the storage of any segmented file is completed, trigger the data processing flow to process the segmented files in the buffer.

[0119] Furthermore, in one embodiment, the file storage module 802 is also used to detect the integrity of the data in the fragmented file.

[0120] Furthermore, in one embodiment, the file storage module 802 is also used to compare the actual size of the data in the segment file with the labeled size in the preset index file; if the actual size is inconsistent with the labeled size, it is determined that there is data missing in the segment file.

[0121] Furthermore, in one embodiment, the file storage module 802 is also used to fill in the missing data for fragmented files with missing data until the actual size matches the labeled size.

[0122] Furthermore, in one embodiment, the channel recording module 803 is also used to establish a unique data slot corresponding to each segment file, and write the data of each segment file into the corresponding slot; and send a notification to the preset parsing module to control the preset parsing module to read data from each slot.

[0123] Furthermore, in one embodiment, the channel recording module 803 is also used to generate information containing the file's data address, data size, data name, and the timestamp corresponding to the data based on the received file; and send the information to a message queue so that the preset parsing module can start a parsing task according to the content of the information.

[0124] Furthermore, in one embodiment, the channel recording module 803 is also used to divide the parsed data into storage units of fixed duration according to a preset time length; generate file names and index records corresponding to each storage unit respectively; update the information in the historical database, which includes the channel recording files of each unicast live source in history.

[0125] Each module in the aforementioned unicast live stream channel recording device can be fully or partially controlled by software or hardware.

[0126] These modules are implemented through components and their combinations. Each of these modules can be embedded in hardware within or independently of the processor in a computer device, or stored in software within the memory of the computer device, so that the processor can call and execute the operations corresponding to each module.

[0127] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 9 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores channel recording data for unicast live sources. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a method for recording channels for unicast live sources.

[0128] Those skilled in the art will understand that Figure 9 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0129] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0130] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps in the above method embodiments.

[0131] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0132] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0133] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0134] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0135] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method of channel recording for a unicast live source, characterized in that, The method is applied to a streaming media server, and the method comprises: initiating a master index request for a unicast live source of a hypertext live streaming, and parsing a link address of a sub-index file based on a response result; periodically initiating a sub-index request based on the link address of the sub-index file, and parsing returned index content to obtain a newly added segment file relative to a previous request period; based on an acquisition sequence of the newly added segment file, sequentially initiating a file list request for the newly added segment file, and storing received files in a buffer to trigger a data processing procedure; in a case where there is no newly added segment in a current request period, ending the current request period, and starting a next request period after a preset time interval to perform channel recording of the unicast live source.

2. The method of claim 1, wherein the parsing of the returned index content to obtain the newly added segment file relative to the previous request period comprises: obtaining a first timestamp of a last processed segment file in the previous request period; obtaining a plurality of segment files in the current sub-index file and a second timestamp set corresponding to the plurality of segment files; comparing a size of each timestamp in the second timestamp set with the first timestamp respectively to determine the newly added segment file relative to the previous request period.

3. The method of claim 2, wherein the comparing of the size of each timestamp in the second timestamp set with the first timestamp respectively to determine the newly added segment file relative to the previous request period comprises: determining a segment file greater than the first timestamp in the second timestamp set as the newly added segment file relative to the previous request period.

4. The method of claim 1, wherein the parsing of the returned index content to obtain the newly added segment file relative to the previous request period further comprises: obtaining a first sequence number of a last processed segment file in the previous request period; obtaining a plurality of segment files in the current sub-index file and a second sequence number set corresponding to the plurality of segment files; comparing a difference value of each sequence number in the second sequence number set with the first sequence number respectively, selecting a target number of segment files based on the difference value, and determining the target number of segment files as the newly added segment file relative to the previous request period.

5. The method of claim 1, wherein the sequentially initiating of the file list request for the newly added segment file based on the acquisition sequence of the newly added segment file and the storing of the received files in the buffer to trigger the data processing procedure comprise: establishing a request sequence based on the acquisition sequence of the newly added segment file; allocating a corresponding buffer to each segment file sequentially based on the request sequence, and storing the received segment file in the buffer in real time; after completing storage of any one segment file, triggering the data processing procedure to process the segment file in the buffer.

6. The method of claim 5, wherein ​ ​ ​ ​ Before triggering the data processing flow to process the shard files of the buffer, further comprising: Detecting the integrity of the data of the shard files.

7. The method of claim 6, wherein, The detecting the integrity of the data of the shard files comprises: Comparing the actual size of the data of the shard files with the marked size in the preset index file; In the case where the actual size is inconsistent with the marked size, determining that the shard file has data loss.

8. The method of claim 7, wherein, After determining that the shard file has data loss, comprising: For the shard file with data loss, complete the missing data until the actual size is consistent with the marked size.

9. The method of claim 1, wherein, After storing the received file to the buffer, comprising: Respectively establishing a data slot corresponding to the unique identifier of each shard file, and writing the data of each shard file to the corresponding slot; Send a notification to the preset parsing module to control the preset parsing module to read data from each slot.

10. The method of claim 1, wherein, The method further comprises: After storing the received file to the buffer to trigger the data processing flow, further comprising: Based on the received file, generate information containing the data address, data size, data name and data corresponding timestamp of the file; Send the information to the message queue to make the preset parsing module start the parsing task according to the content of the information.

11. The method of claim 10, wherein, The method further comprises: The parsed data is cut into fixed length storage units according to the preset time length; Respectively generate the file name and index record corresponding to each storage unit, and update the information in the history database, which includes the file recorded by the channel of each time unicast live source.

12. An apparatus for channel recording of a unicast live source, the apparatus comprising: The device comprises: A request parsing module for initiating a main index request for the unicast live source of the hypertext live stream, and parsing the link address of the sub index file based on the response result; The request parsing module is also used to periodically initiate a sub index request according to the link address of the sub index file, and parse the returned index content to obtain the newly added shard file relative to the last request period; A file storage module for sequentially initiating a file list request to the newly added shard file based on the order of obtaining the newly added shard file, and storing the received file to the buffer to trigger the data processing flow; A channel recording module for ending the current request period in the case where there is no new shard in the current request period, and starting the next request period after a preset time interval to record the channel of the unicast live source.

13. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that, The processor executes the computer program to realize the steps of the method of any one of claims 1 to 11.

14. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to realize the steps of the method of any one of claims 1 to 11.

15. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to realize the steps of the method of any one of claims 1 to 11.

Images