HLS file processing method and system based on sidecar mode

Abstract

The invention relates to the field of streaming media service and video processing, and discloses an HLS file processing method and system based on a sidecar mode, and the method comprises the steps: capturing at least one main index file and a plurality of slice files through a sidecar assembly based on a video stream of a server side; then, constructing a slice file index database without initial duration, and complementing the duration of the slice file so as to ensure the time sequence accuracy of the HLS file; carrying out placeholder filling to maintain the continuity of the HLS file aiming at the condition that the video stream is cut off; verifying the information integrity of the slice file referenced in each main index file; and finally, the server side feeds back the HLS file passing the verification to the user side. According to the method, the function of the server side is enhanced without modifying a source code of the server side or participating in a compiling process, the compatibility and maintenance risks caused by upgrading of the server side are effectively avoided, and the method has extremely high pluggable performance and deployment flexibility in a micro-service environment.

Description

Technical Field

[0001] This invention relates to the field of streaming media services and video processing, and in particular to an HLS file processing method and system based on the sidecar mode. Background Technology

[0002] In scenarios where video-on-demand and surveillance are integrated, it is necessary to associate a video stream within a business-related time period with specific business information such as the business ID and the start and end times of the video, so that users can quickly locate and play back the corresponding video according to their business needs. However, the following problems still exist in the process of obtaining HLS files: 1. The video stream slice file index lacks accurate duration information. Currently, most methods for detecting the duration of video segments are relatively simple, such as relying solely on filenames, video paths, or calling tools like FFprobe segment by segment to obtain the duration. They do not build multi-level, end-to-end detection methods, and the duration detection mechanism is imperfect. This single detection method may not be able to accurately obtain the duration of a segment, which in turn makes it impossible to accurately locate the corresponding segment file based on the start and end time interval specified by the business.

[0003] 2. The conflict between index rebuilding performance and storage consumption If the segment duration is obtained solely by filename or video path, and the main index file is not updated in time due to network latency or server failure (e.g., newly added segments are not written to the index), the detected duration will lag behind the actual video stream, compromising the index's accuracy. If the duration is obtained by calling tools like FFprobe for each segment file and then written to the segment file index database, significant I / O and CPU overhead will occur. When a large number of segment files accumulate from a single stream, analyzing them one by one with FFprobe will generate massive decoding and disk read / write operations in a short period, impacting real-time service.

[0004] 3. Insufficient video interruption detection and compensation functions. In real-world, complex network environments, video interruption detection can miss certain segments. If blank segments are not detected in time, they cannot be filled, severely impacting playback continuity. Existing technologies lack a unified mechanism for filling in missing video segments. Developers need to generate missing segments and stitch them together at the business layer using FFmpeg. This process is inefficient because FFmpeg is mostly a single-process synchronous process, and processing long blank segments is time-consuming. Furthermore, the parameters of the placeholder segments and the original video are prone to differ, resulting in poor stitching quality. Even if standard-length placeholder segments are pre-generated, corresponding templates need to be generated for multi-bitrate and multi-resolution streams. Storage resources increase dramatically with the number of variations, and pre-computation consumes a lot of computing power, affecting normal streaming media processing.

[0005] In summary, the main bottlenecks of existing technologies for processing HLS files are: the lack of accurate duration information in the video stream slice file index during HLS file acquisition; the trade-off between index reconstruction performance and storage consumption; and insufficient video interruption detection and filling functions. These issues affect file processing efficiency, leading to a decrease in server real-time processing capabilities, and impacting server availability and user satisfaction. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention provides an HLS file processing method and system based on the sidecar mode. The technical solution provided by this invention includes: The HLS file export processing method based on the sidecar mode includes the following steps: S1. The sidecar component captures at least one master index file and multiple slice files based on the video stream from the server. S2. Construct an initial slice file index database without duration based on the multiple slice files, and complete the duration of the slice files to ensure the timing accuracy of the HLS files; S3. In case of interruptions in the video stream, placeholder padding is performed to maintain the continuity of the HLS file; S4. Verify the integrity of the information in the slice files referenced in each of the main index files; S5. The server sends the verified HLS file back to the user.

[0007] Preferably, the method for completing the duration of the slice file includes: S201. Based on the at least one master index file, obtain the duration of the recorded slice file as the first duration, and update the obtained first duration to the slice file index database; S202. For a slice file whose duration has not been obtained, compare the sequence number order of the slice files in the video stream. If the start time of the current slice plus the preset slice duration equals the start time of the slice file corresponding to the next sequence number, then the duration of the current slice file is the preset slice duration and is used as the second duration. S203. For slice files whose duration has not yet been obtained, the duration of the slice file is obtained through a streaming media processing tool and used as the third duration.

[0008] Preferably, the method of obtaining the third duration using the streaming media processing tool includes: submitting the path of the segment file whose duration has not yet been obtained to the verification pool of the streaming media processing tool, executing the streaming media processing tool through an asynchronous thread pool to obtain the third duration, and writing the third duration into the segment file index database.

[0009] Preferably, after writing the third duration into the slice file index database, the third duration is then updated to the local cache; before using the streaming media processing tool, it is first checked whether there is already a duration record corresponding to the slice file path in the local cache; if so, the corresponding third duration is directly updated to the slice file index database.

[0010] Preferably, the placeholder filling method includes: S301. Obtain multiple placeholder video clips and generate a combination of placeholder video clips of several durations; S302. The duration to be filled at the interruption point is taken as the filling duration, and the combination of the placeholder video segments is matched according to the filling duration to form a filling slice; S303. Update the storage path of the filled slice and the filling duration to the HLS file.

[0011] Preferably, the method for generating the filled slice includes: Define a set of preset durations; Based on the different durations in the preset duration set, obtain a combination of several different placeholder video segments; The placeholder video segments in the combination of placeholder video segments are spliced ​​together to obtain the filling slice.

[0012] Preferably, the combination of placeholder video clips should meet the following conditions: The sum of the durations of each placeholder video segment equals the filling duration; Minimize the number of placeholder video segments.

[0013] Preferably, the information to be verified includes: the filename, path, start time, duration, and sequence number of the slice file.

[0014] The present invention also provides an HLS file processing system based on the sidecar mode, the system being used to implement the HLS file processing method based on the sidecar mode described in any one of the above-mentioned inventions.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. This invention enhances server functionality without requiring modification of server-side source code or participation in the compilation process, effectively avoiding compatibility and maintenance risks associated with server-side upgrades, and exhibits extremely high pluggability and deployment flexibility in microservice environments.

[0016] 2. This invention presents a layered and progressive duration completion method consisting of "path resolution → adjacent file verification → streaming media processing tools." This method solves the problems of insufficient accuracy and low efficiency in HLS file duration detection in existing technologies; it can achieve duration detection and rapid index construction for massive amounts of segmented files. Experimental verification shows that when processing 100,000-level segmented files, the overall processing time is reduced from 12 hours using traditional methods to approximately 1 hour, with duration extraction efficiency improved by over 95%.

[0017] 3. In response to interruptions in the video stream, a placeholder filling method is used to automatically identify and fill in the interrupted segments, ensuring the continuity and integrity of video playback; by pre-generating placeholder segments of various durations, the optimal segment combination can be filled within milliseconds, ensuring that the playback duration of the player is consistent with the actual recording duration, greatly improving playback continuity and user experience. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art 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.

[0019] Figure 1 This is a flowchart of an HLS file processing method based on the sidecar mode according to the present invention. Detailed Implementation

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

[0021] Example 1 like Figure 1 As shown, this embodiment provides an HLS file processing method based on the sidecar mode, including the following steps: The client submits an export request for an HLS file to the server. At least one sidecar component is deployed on the server to respond to the export request. The HLS file includes a main index file and slice files. In some preferred embodiments, the HLS file includes a .m3u8 main index file and .ts format slice files. The sidecar component represents an auxiliary processing module deployed on the server that can intercept, parse, and export the HLS file.

[0022] Existing HLS file export methods typically rely directly on the server-side to handle request processing. When a user requests an export, the server is responsible for generating or forwarding index and slice files. Under heavy server load, export tasks can degrade the performance of core business services, easily causing response delays or incomplete exported data. To address these issues, this invention deploys a sidecar component on the server side. This component responds directly to the user's export request and handles subsequent file capture and processing, reducing the server load. The steps include: S1. The sidecar component captures at least one master index file and multiple slice files based on the video stream from the server. Traditionally, HLS file capture relies on manually copying the log directory or obtaining files one by one using download tools, which is inefficient. Furthermore, manual methods are prone to missing segments, resulting in incomplete exported files. To address these issues, in some preferred embodiments, the sidecar component deployed in this invention automatically captures the generated master index file and corresponding segment files from the server's video stream output, achieving seamless integration and ensuring both completeness and real-time performance of the capture.

[0023] S2. Construct an initial slice file index database without duration based on the multiple slice files, and complete the duration of the slice files to ensure the timing accuracy of the HLS files; In some preferred embodiments, the slice file index database is a structured database used to store information such as the filename, start time, and duration of each slice file.

[0024] A common method for obtaining the duration of each segment is to directly rely on the duration recorded in the HLS file itself. However, some segments may not carry accurate duration information when they are generated, potentially resulting in missing duration information and limiting functions such as player skipping, preloading, and playback positioning. Furthermore, relying solely on the server's main index file cannot dynamically adapt to actual changes in the segment files. Additionally, some technical solutions simply rely on tools like FFmpeg (such as the ffprobe command) to extract duration information from each segment file. While this method offers high accuracy, it suffers from low processing efficiency, high computational overhead, and is unsuitable for large-scale real-time streaming. Especially in environments with a large number of segments or poor network conditions, frequent calls to external parsing tools can lead to system response delays, impacting overall performance. In some preferred embodiments, the present invention proposes a method for completing the duration of each slice, specifically including: obtaining the duration of the recorded slice file as a first duration based on at least one master index file, and updating the slice file index database with the obtained first duration; for slice files whose duration has not been obtained, comparing the sequence number order of the slice files in the video stream, if the start time of the current slice plus a preset slice duration equals the start time of the slice file corresponding to the next sequence number, then the duration of the current slice file is the preset slice duration as a second duration; for slice files whose duration has still not been obtained, obtaining the duration of the slice file as a third duration through a streaming media processing tool.

[0025] S3. In case of interruptions in the video stream, placeholder padding is performed to maintain the continuity of the HLS file; In real-world, complex network environments, video interruption detection is prone to missed detections. If the system fails to detect blank periods in time, it cannot generate placeholder segments, leading to noticeable stuttering or interruptions during playback. Current technologies lack a unified mechanism for filling in missing video gaps, typically requiring developers to manually generate and stitch placeholder segments using FFmpeg at the business layer. However, FFmpeg is mostly a single-process synchronous process, resulting in low generation efficiency and time-consuming stitching in long-duration blank scenarios. Furthermore, the generated placeholder segments may differ from the original video in parameters (bitrate, resolution, encoding method), leading to poor compatibility with the playback end. Even using a pre-generated standard-length placeholder segment solution requires generating different templates for multi-bitrate and multi-resolution streams, consuming significant storage resources; simultaneously, the pre-calculation process consumes computing power, impacting normal streaming media processing. To address the above problems, the placeholder filling method of the present invention includes: acquiring multiple placeholder video segments using a streaming media tool, generating a combination of placeholder video segments of several durations; using the duration to be filled at the interruption point as the filling duration, and matching the combination of placeholder video segments according to the filling duration as a filling slice; updating the storage path of the filling slice and the filling duration in an index file. This process handles interruptions in the video stream.

[0026] S4. Verify the integrity of the information in the slice files referenced in each of the main index files; Existing HLS file export processes often lack a slice file verification mechanism, leading to the possibility of corrupted files being included in the export results. If a slice referenced by the main index file is missing or corrupted, playback will fail. To address these issues, the sidecar component of this invention checks the existence and validity of each referenced slice in the main index file, ensuring that the references match the actual files and preventing invalid exports due to missing or corrupted slice files.

[0027] S5. The server sends the verified HLS file back to the user.

[0028] Existing technologies typically return captured files directly in a package without verification. This can lead to users receiving incorrect or incomplete files, causing playback errors. In some preferred embodiments, the sidecar component of this invention returns the final, complete HLS file to the user only after completing video capture, duration padding, interruption placeholders, and integrity verification.

[0029] This embodiment avoids putting excessive pressure on the server during the export process, thereby ensuring the stable operation of core services; it ensures that the exported main index file and slice files are complete and usable, avoiding unusable export results due to missing or corrupted files; by completing the slice duration and filling placeholders in case of interruption, it ensures the timing accuracy and playback continuity of the HLS file; and it enables users to directly obtain HLS files that have undergone integrity verification, significantly improving the reliability of the export process.

[0030] Example 2 Based on Example 1, this example provides a method for completing the duration of the slice file, specifically including: S201. Based on the at least one master index file, obtain the duration of the recorded slice file as the first duration, and update the slice file index database with the obtained first duration.

[0031] In some preferred embodiments, the first duration is the duration of the TS slice file directly read from the m3u8 file. The duration information contained in each "#EXTINF:" tag is parsed from the m3u8 index file, and this duration is used as the first duration and filled into the duration field of the corresponding slice. The m3u8 index file is read line by line; if "#EXTINF:x.xxxx" is detected, the next line containing the TS slice file name is read and a corresponding relationship is established.

[0032] S202. For a slice file whose duration has not been obtained, compare the sequence number order of the slice files in the video stream. If the start time of the current slice plus the preset slice duration equals the start time of the slice file corresponding to the next sequence number, then the duration of the current slice file is the preset slice duration, which is used as the second duration.

[0033] In some preferred embodiments, the preset slice duration can be 10 seconds, or it can be a reasonable design by those skilled in the art based on actual conditions or site requirements. For slice files lacking #EXTINF tag information, if the slice's start time information is available (such as player recordings or timestamps), the duration of the current slice can be inferred by calculating the start time difference between adjacent slices. If the segment file is segment_ i The start time is T i segment_{ i The starting time of +1} is T i+1 The duration of the current slice is inferred to be T. i+1 -T i ; If the inferred duration of the current slice file is equal to the preset slice duration of 10 seconds, then the inferred result is updated in the slice file index database; if the inferred value is abnormal (such as being negative or greater than the threshold of 9 seconds or 11 seconds), then it is skipped.

[0034] S203. For slice files whose duration has not yet been obtained, the duration of the slice file is obtained through a streaming media processing tool and used as the third duration.

[0035] In some preferred embodiments, the third duration is the duration of the TS segment file obtained by the streaming media processing tool; for TS segment files skipped in step S202, the streaming media processing tool FFprobe is called to parse them and extract the third duration of the TS segment. An asynchronous thread pool is used to execute commands. This mechanism, by reusing threads and executing non-blockingly, can fully utilize system resources while ensuring the smooth operation of the main thread, making it particularly suitable for batch processing of file path verification needs.

[0036] In some preferred embodiments, the asynchronous thread pool executes commands as follows: ffprobe -v error -show_entries format=duration\ -of default=noprint_wrappers=1:nokey=1\ <ts_path> The meanings of its main parameters are explained below: The "-v error" field indicates that the log level is set to error, and only error messages will be output. The “show_entries format=duration” field indicates the metadata entries to be displayed, mainly the duration field in the format (i.e., file format information). This field is selected because it is used to detect the duration of sliced ​​files. In the field "-of default=noprint_wrappers=1:nokey=1", "-of default" indicates that the default output format is used, which is essentially a simplified INI-like structure; "noprint_wrappers=1" means that the header and footer wrapping information (such as "FORMAT" and " / FORMAT") are not printed; "nokey=1" means that the field name "duration=" is not displayed, and only the duration value itself is output. This can reduce redundant information, reduce parsing costs, and make pure numerical output easier to import into the slice file index database when processing massive slice files.

[0037] “<ts_path> "Field: Indicates the input file path, usually a .ts format video file, specifying the target file to be analyzed; The above command was executed successfully, and the output is a simple numerical value.

[0038] The continuous duration completion method in this embodiment effectively solves the problems of insufficient accuracy and low efficiency in duration detection in the prior art. In terms of accuracy, multi-level detection eliminates the defects of single detection and significantly reduces the detection error rate. In terms of efficiency, the layered strategy of prioritizing lightweight detection and supplementing with heavy tool verification significantly reduces resource consumption and meets the real-time detection requirements in continuous video streams. It can realize duration detection and rapid index construction of massive slice files.

[0039] Example 3 Based on any one of Embodiments 1 and 2, this embodiment utilizes a streaming media processing tool to obtain the third duration.

[0040] In existing technologies, some techniques use MP4Box or MediaInfo tools to obtain the duration. MP4Box primarily targets files with .mp4 structures and has poor support for .ts type segments. During parsing, it often fails to obtain a valid duration due to a lack of complete encapsulation header information or keyframe indexes. While MediaInfo can display various audio and video metadata, it lacks the flexibility and robustness for programmatic systems, and has a high probability of parsing failure when dealing with segment files with encoding anomalies or missing frames. To address these issues, in some preferred embodiments, obtaining the third duration using the streaming media processing tool can be achieved by using the streaming media processing tool FFprobe to parse the segment files. First, the path of the segment file whose duration has not yet been obtained is submitted to the verification pool of the streaming media processing tool. Then, the streaming media processing tool is executed through an asynchronous thread pool to obtain the third duration. Finally, the third duration is written to the segment file index database.

[0041] This embodiment, by reusing threads and executing non-blockingly, can make full use of system resources while ensuring the smooth operation of the main thread, making it particularly suitable for batch processing of file path verification needs.

[0042] Example 4 Based on Example 3, a local caching operation is performed on the third duration.

[0043] After the third duration is written to the slice file index database, if the third duration is not synchronously updated to the local cache, the following problem may occur: the system still needs to frequently read duration information from the slice file index database in subsequent processing, causing data access delays or wasted read and write resources. To solve the above problems, in some preferred embodiments, after the third duration is written to the slice file index database, the third duration can be updated to the local cache.

[0044] This embodiment can effectively reduce the frequency of reading and writing to the slice file index database, improve the overall efficiency of video stream processing, and avoid repeated processing of slice files for extracting the third duration.

[0045] In some other preferred embodiments, this embodiment also introduces a local cache hit priority mechanism.

[0046] Typically, the duration of a segment file is obtained directly using streaming media processing tools for duration parsing. This approach does not check whether the duration record for the segment file already exists in the local cache. This could lead to situations where some segment files have already obtained their third duration in historical processing and are cached locally, but due to the lack of cache checks, they are still repeatedly submitted to the streaming media processing tool, resulting in computational redundancy and wasted computing resources. In some preferred embodiments, before the streaming media processing tool is used, the local cache is checked to see if a duration record corresponding to the segment file path already exists. If so, the corresponding third duration is directly updated to the segment file index database.

[0047] This embodiment saves resources by checking the local cache before calling the streaming media processing tool. For existing segment file duration records, the parsing step of the streaming media processing tool is skipped.

[0048] Example 5 Based on Example 1, this example provides a method for filling spaced-out gaps.

[0049] S301. Obtain multiple placeholder video clips and generate a combination of placeholder video clips of several durations.

[0050] In some preferred embodiments, the placeholder video segment is a set of video segments that can match the duration of the interruption, formed by splicing multiple preset placeholder segments of different durations according to certain rules. The placeholder video segment can be obtained using the FFmpeg processing tool to obtain several no-signal placeholder video segments of different resolutions and durations. The placeholder video segment can be of various resolutions and multiple standard durations (such as 1 second, 2 seconds, 5 seconds, 10 seconds, 30 seconds) of no-signal placeholder video segments. The placeholder video segment can adopt the style of black screen, mute, and prompt screen, or it can be a reasonable design by those skilled in the art according to the actual situation or site requirements. Based on the placeholder video clips, generate combinations of placeholder video clips of several durations. For example, generate combinations of placeholder video clips from the obtained 1-second, 2-second, 5-second, 10-second, and 30-second basic placeholder video clips, including "1s+2s, 2s+5s, 5s+10s, 5s+10s+30s", etc.; and store the obtained placeholder video clips uniformly in a local pre-generated video library for easy extraction of corresponding video clips from the pre-generated video library later.

[0051] S302. The duration to be filled at the interruption point is taken as the filling duration, and the combination of the placeholder video segments is matched according to the filling duration as the filling slice.

[0052] In some preferred embodiments, the interruption occurs when the time interval between two adjacent slices is greater than a preset slice period. For example, the preset slice period is set to 5 seconds (i.e., under normal transmission conditions, the time interval between adjacent slices in HLS streaming media should be close to 5 seconds, allowing for an error of ±1 second). The time interval between two adjacent slices is calculated as follows: the end time of the first slice is 00:05:30; the start time of the second slice is 00:05:50; the calculated time interval is 00:05:50 - 00:05:30 = 20 seconds. Since 20 seconds is greater than 5 seconds, it is determined that an interruption has occurred at this point, and the interruption duration is 20 seconds - 5 seconds = 15 seconds. The fill-in duration is used to fill the final video slice of the interruption period, which is composed of placeholder video clips; for example, if an interruption is detected and 15 seconds of fill-in is needed, a placeholder combination of "5s + 10s" is matched as the fill-in slice.

[0053] S303. Update the storage path of the filled slice and the filling duration to the HLS file.

[0054] In some preferred embodiments, the storage path and 5s duration of the fill slice obtained in S302 in the pre-generated library are written into the index file to replace the blank record at the original interruption position.

[0055] This embodiment does not require the real-time generation of placeholder segments. By combining basic segments, processing efficiency is further improved, resource consumption is reduced, and the normal processing of streaming media is avoided.

[0056] Example 6 Based on Example 5, this example provides a method for generating filled slices, specifically including: Define a set of preset durations; In some preferred embodiments, the preset duration set can be defined as {30, 10, 5, 2, 1}, or it can be a reasonable design by those skilled in the art based on actual conditions or site requirements.

[0057] Based on the different durations in the preset duration set, obtain a combination of several different placeholder video segments; In some preferred embodiments, obtaining a combination of several different placeholder video segments based on different durations in a preset duration set can be achieved using the idea of ​​making change with a coin, or it can be a reasonable design by those skilled in the art based on the actual situation or on-site needs.

[0058] In some preferred embodiments, the idea behind coin change is as follows (e.g., the interruption duration is 27s): prioritize basic segments from largest to smallest, and use the fewest segments to cover the target duration.

[0059] From 1 second to 27 seconds, determine whether each duration can be achieved by combining basic segments (30, 10, 5, 2, 1 seconds). For each duration, check in the order of "30 seconds → 10 seconds → 5 seconds → 2 seconds → 1 second", prioritizing the largest available segment (i.e., segment duration ≤ current duration, and remaining duration can be covered by other segments). Record the selected segment immediately. Use an array to record the last selected segment for each duration. Finally, working backward from 27 seconds, subtract the recorded segments one by one to obtain the complete combination.

[0060] The placeholder video segments in the combination of placeholder video segments are spliced ​​together to obtain the filling slice; Existing video technologies employ a segment-by-segment encoding and splicing method, such as splicing 10s+10s, then 10s+10s+5s, and finally concatenating the result with 2s. This relies on FFmpeg's single-process sequential processing, resulting in extremely low efficiency. In some superior embodiments, the splicing mechanism of this invention is as follows: when a 27-second interruption is detected and a placeholder combination of [10s, 10s, 5s, 2s] is matched, the storage paths of the four segments are written to a text file in sequence. Then, matching basic placeholder segments are extracted from a pre-generated video library. These segments have the same resolution, bitrate, frame rate, and audio format as the original video. Next, FFmpeg is called to read the video and audio streams of these four segments sequentially via the concat protocol, using a direct copy mode for processing. This avoids re-encoding the video and audio data, only splicing the original data streams of the four segments into a continuous, complete data stream in chronological order. This process skips the time-consuming encoding stage, significantly reducing processing time.

[0061] In this embodiment, when a video stream is interrupted, a placeholder slice generation and splicing mechanism is used to quickly generate a filler slice with the same parameters as the original video, thereby maintaining the continuity and timing accuracy of the HLS file and significantly improving processing efficiency.

[0062] Example 7 Based on Example 6, this example specifies the conditions that the combination of placeholder video clips should meet: The sum of the durations of each placeholder video segment equals the filling duration; If the sum of the durations of the placeholder video segments is less than the filling duration, the interruption period cannot be fully covered, and users will still see blank screens or jumps (e.g., an interruption of 15 seconds, but combined into 12-second segments, leaving 3 seconds without content), perceiving a service anomaly. If the sum of the durations of the placeholder video segments is greater than the filling duration, the filling segment takes longer, causing the start time of the original next segment to be forcibly shifted backward (e.g., an interruption of 15 seconds, combined into 17-second segments, the original segment starts at 15 seconds, but actually starts at 17 seconds), resulting in time jumps or fast-forwarding during playback.

[0063] Minimize the number of placeholder video segments; If the number of placeholder video segments is not minimized, the splicing operation becomes increasingly cumbersome as the number of segments increases (e.g., 15 one-second segments versus 2 ten-plus-five segments). Assuming a single segment splicing takes 50ms, 15 segments take 750ms, while 2 segments only take 100ms, representing a 7-fold efficiency difference. Furthermore, frequent calls to the splicing tool to process multiple segments will consume the CPU / IO resources of the streaming media server, leading to encoding and transmission delays in the normal video stream.

[0064] Example 8 Based on Example 1, this example further illustrates the verification content of slice file information in HLS files.

[0065] In some preferred embodiments, the sidecar component verifies each slice file individually when exporting HLS files, including the filename, path, start time, duration, and sequence number. During the verification process, if any inconsistencies or missing information are found in a slice file, the sidecar component can mark it or recapture it, thereby ensuring that the exported HLS file information is complete, the timing is correct, and the order is correct.

[0066] This embodiment can significantly improve the reliability of exporting HLS files.

[0067] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A method for processing an HLS file based on a sidecar mode, comprising: The user end proposes an export request of an HLS file to a server end, a sidecar component deployed in at least one of the server ends responds to the export request, and the HLS file comprises a master index file and slice files, and the response method of the export request comprises: S1. The sidecar component captures at least one master index file and a plurality of slice files based on a video stream of the server end; S2. An initial slice file index database without time length is constructed based on the plurality of slice files, the time length of the slice files is completed, and the time sequence accuracy of the HLS file is ensured; S3. In the case of flow interruption in the video stream, placeholder filling is performed to maintain the continuity of the HLS file; S4. The information integrity of the slice files referenced in each master index file is verified; S5. The server end feeds back the HLS file that passes the verification to the user end.

2. The method of claim 1, wherein the method is performed by a proxy server. The method for completing the time length of the slice files comprises: S201. The time length of the recorded slice files is obtained as a first time length based on the at least one master index file, and the obtained first time length is updated to the slice file index database; S202. For the slice files without obtained time length, the sequence number order of the slice files in the video stream is compared, if the starting time of the current slice plus a preset slice time length is equal to the starting time of the slice file corresponding to the next sequence number, the time length of the current slice file is the preset slice time length as a second time length; S203. For the slice files still without obtained time length, the time length of the slice file is obtained as a third time length through a stream media processing tool. 3.The HLS file processing method based on the sidecar mode according to claim 2, characterized in that, The way of obtaining the third time length through the stream media processing tool comprises: submitting the path of the slice file still without obtained time length to a verification pool of the stream media processing tool, executing the stream media processing tool through an asynchronous thread pool to obtain the third time length, and writing the third time length to the slice file index database.

4. The method of claim 3, wherein the method further comprises: After the third time length is written to the slice file index database, the third time length is updated to a local cache again; Before the stream media processing tool is used, it is checked whether there is a time length record corresponding to the path of the slice file in the local cache; if there is, the corresponding third time length is directly updated to the slice file index database.

5. The method of claim 1, wherein the method further comprises: The method of placeholder filling comprises: S301. A plurality of placeholder video clips are obtained, and a plurality of combinations of placeholder video clips with different time lengths are generated; S302. The time length to be filled in the flow interruption is taken as a filling time length, the combination of the placeholder video clips is matched as a filling slice according to the filling time length; S303. The storage path of the filling slice and the filling time length are updated to the HLS file.

6. The method of claim 5, wherein the method further comprises: The generation method of the filling slice comprises: A preset time length set is defined; A combination of a plurality of different placeholder video clips is obtained according to different time lengths in the preset time length set; Each placeholder video clip in the combination of the placeholder video clips is spliced to obtain a filling slice.

7. The proxy mode based HLS file processing method of claim 6, wherein, The combination of the placeholder video clips should meet the following conditions: The sum of the time lengths of the placeholder video clips is equal to the filling time length. Minimizing the number of placeholder video segments. 8.The HLS file processing method based on the sidecar mode of claim 1, wherein, The information checked includes: the file name, path, start time, duration, serial number of the slice file. 9.A system for processing HLS files based on a sidecar mode, the system comprising: The system is used to realize the method for processing the HLS file based on the sidecar mode in any one of claims 1-8.

Images