Video transmission method and electronic device

Abstract

This application provides a video transmission method and an electronic device. The method includes: receiving a byte range request sent by a client; the byte range request is used to request the acquisition of a target byte range of a target video in a virtual transport stream; the virtual transport stream is a contiguous byte address space formed by mapping multiple video segments of the target video in playback order using virtual addresses; mapping the starting offset of the target byte range forward to the virtual offset of the most recent keyframe whose virtual offset is less than or equal to the starting offset to obtain a starting virtual offset; and returning the byte range in the virtual transport stream from the starting virtual offset to the ending offset of the target byte range to the client. This application solves the technical problem in related technologies where relying solely on fragment-level indexing for byte range mapping in drag-and-drop, random access, or keyframe recovery scenarios leads to screen tearing, stuttering, or first-frame decoding failure.

Description

Technical Field

[0001] This application relates to the field of Internet video transmission and content distribution, and more specifically, to a video transmission method and an electronic device. Background Technology

[0002] In online video distribution scenarios, for drag-and-drop, random access, or keyframe recovery scenarios, the byte range mapping is usually only based on the segment-level index (such as the TS (Transport Stream) segment start and end offset). The server directly returns data according to the original offset, which can easily cause the decoder to fail to recognize the starting bitstream, resulting in screen tearing, stuttering, or failure to decode the first frame. Summary of the Invention

[0003] This application provides a video transmission method and an electronic device to at least solve the technical problems in the related art where relying solely on fragment-level indexes for byte range mapping in drag-and-drop, random access, or keyframe recovery scenarios leads to screen tearing, stuttering, or first frame decoding failure.

[0004] According to one aspect of the embodiments of this application, a video transmission method is provided, comprising: receiving a byte range request sent by a client; the byte range request being used to request the acquisition of a target byte range of a target video in a virtual transport stream; the virtual transport stream being a contiguous byte address space formed by mapping multiple video segments of the target video to virtual addresses in playback order; mapping the starting offset of the target byte range forward to the virtual offset of the most recent keyframe whose virtual offset is less than or equal to the starting offset to obtain a starting virtual offset; and returning the byte range in the virtual transport stream from the starting virtual offset to the ending offset of the target byte range to the client.

[0005] According to another aspect of the embodiments of this application, a video transmission apparatus is also provided, the apparatus further comprising: a receiving module, configured to receive a byte range request sent by a client; the byte range request is used to request the acquisition of a target byte range of a target video in a virtual transport stream; the virtual transport stream is a continuous byte address space formed by virtual address mapping of multiple video segments of the target video in playback order; an alignment module, configured to map the starting offset of the target byte range forward to the virtual offset of the most recent keyframe whose virtual offset is less than or equal to the starting offset, to obtain a starting virtual offset; and a reading module, configured to return the byte range in the virtual transport stream from the starting virtual offset to the ending offset of the target byte range to the client.

[0006] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed by a processor.

[0007] According to another aspect of the embodiments of this application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the steps in any of the method embodiments described above.

[0008] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to perform the steps of any of the above method embodiments through the computer program.

[0009] This application constructs a virtual transport stream to achieve a unified byte address mapping for multiple video segments, eliminating the need to pre-generate a complete physical copy of the TS, thus reducing object storage and update costs. Furthermore, by mapping the request start offset forward to the nearest keyframe position, it ensures that the returned byte range starts from the keyframe, enabling the decoder to decode correctly. This achieves a balance between decodeability and byte precision, solving the technical problem in related technologies where relying solely on fragment-level indexes for byte range mapping in drag-and-drop, random access, or keyframe recovery scenarios leads to screen tearing, stuttering, or first-frame decoding failure. This improves the stability of video playback and user experience, and shortens the latency of first-frame and drag-and-drop recovery. Attached Figure Description

[0010] Figure 1 This is a schematic diagram illustrating an application scenario of a video transmission method according to an embodiment of this application;

[0011] Figure 2 This is a flowchart illustrating an optional video transmission method according to an embodiment of this application;

[0012] Figure 3 This is an optional virtual large TS streaming system architecture diagram according to an embodiment of this application;

[0013] Figure 4 This is a flowchart of an optional virtual large TS streaming method according to an embodiment of this application;

[0014] Figure 5 This is a schematic diagram of an optional two-level index mapping according to an embodiment of this application;

[0015] Figure 6This is a schematic diagram of a consistency token dual verification and degradation recovery state machine according to an embodiment of this application;

[0016] Figure 7 This is a schematic diagram of constrained prefetch control and source retrieval granularity alignment according to an embodiment of this application;

[0017] Figure 8 This is a structural block diagram of an optional video processing apparatus according to an embodiment of this application;

[0018] Figure 9 This is a computer system architecture block diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0019] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0020] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0021] According to one aspect of the embodiments of this application, a video transmission method is provided. Optionally, in this embodiment, the above-described video transmission method may be applied to, but is not limited to, [examples of applications such as...]. Figure 1The diagram shows a hardware environment including client 102, CDN (Content Delivery Network) edge node 104, and origin server 106. Client 102 can connect to CDN edge node 104 via the network, and CDN edge node 104 connects to origin server 106 via the network. It can be used to provide services (e.g., application services) to client 102 or clients installed on client 102. A database can be set up on or independently of CDN edge node 104 to provide data storage services for CDN edge node 104.

[0022] In this process, client 102 initiates a byte range request to CDN edge node 104, requesting the virtual transport stream of the target video. Upon receiving the request, CDN edge node 104 parses the set of video segments corresponding to the requested range and the byte offset range within each video segment, obtaining the URI of each video segment in object storage. Subsequently, CDN edge node 104 concurrently initiates multiple byte range requests to origin server 106, reading the specified byte range of the corresponding video segment. Origin server 106 responds to each request, returning the original transport data blocks of the corresponding video segment. CDN edge node 104 concatenates these data blocks in memory according to virtual byte order, forming a continuous byte stream without generating any physical file. Finally, CDN edge node 104 returns the concatenated byte stream as a response to client 102 via the network.

[0023] The aforementioned networks may include, but are not limited to, at least one of the following: wired networks and wireless networks. The aforementioned wired networks may include, but are not limited to, at least one of the following: wide area networks (WANs), metropolitan area networks (MANs), and local area networks (LANs). The aforementioned wireless networks may include, but are not limited to, at least one of the following: Wireless Fidelity (WIFI) and Bluetooth. Client 102 may be, but is not limited to, personal computers (PCs), mobile phones, tablets, etc. CDN edge nodes 104 and origin servers may be, but are not limited to, cloud servers, server clusters, or other server types.

[0024] The video transmission method of this application embodiment can be executed by CDN edge node 104. Figure 2 This is a flowchart illustrating an optional video transmission method according to an embodiment of this application, such as... Figure 2 As shown, the process of this method may include the following steps:

[0025] Step S202: Receive a byte range request sent by the client; the byte range request is used to request the target byte range of the target video in the virtual transport stream; the virtual transport stream is a continuous byte address space formed by virtual address mapping of multiple video segments of the target video in the playback order.

[0026] Step S204: Map the starting offset of the target byte range forward to the virtual offset of the most recent keyframe whose virtual offset is less than or equal to the starting offset, to obtain the starting virtual offset.

[0027] Step S206: Return the byte range in the virtual transport stream from the starting virtual offset to the ending offset of the target byte range to the client.

[0028] The video transmission method in this embodiment can be applied to the field of Internet video transmission and content distribution. It can be applied to scenarios where client devices that do not support the native HLS (HTTP Live Streaming) protocol but support byte range requests can drag and drop videos, play the first frame, or access them randomly. It can also be applied to typical scenarios such as fMP4 / M4S fragmentation, EXT-X-BYTERANGE (HLS extension directive), EXT-X-DISCONTINUITY (HLS extension directive), ad insertion, multi-bitrate ABR (Adaptive Bitrate Streaming) switching, and range-free request compatibility processing, so as to realize virtual continuous streaming transmission without the need to pre-generate complete physical files.

[0029] In online video distribution scenarios, HLS content is typically stored as playlist files (such as m3u8 index files, which are UTF-8 encoded text index files) and multiple video segments (such as TS). For clients that do not support native HLS playback links and only support pulling TS streams by byte range requests (such as HTTP Range) (such as some smart TVs, set-top boxes, or embedded players), the following solutions are commonly used in engineering:

[0030] (1) All video segments are merged in advance to generate a complete physical copy of the transport stream, and then sent to the client in byte ranges;

[0031] (2) After receiving the client request, temporarily assemble the target fragments according to the fragmentation order and return them;

[0032] (3) Implement hotspot preloading and caching optimization based solely on video popularity, without jointly controlling request range, origin retrieval granularity, and version consistency.

[0033] Among these, the complete transport stream physical copy generation scheme requires the additional generation of a complete transport stream physical copy, which increases the object storage capacity and brings version update and synchronization maintenance costs. Secondly, in drag-and-drop, random access, or keyframe recovery scenarios, relying solely on fragment-level indexes (such as the start and end offsets of video segments) for byte range mapping can easily lead to the source return starting point falling at a non-keyframe position, causing client decoding failure, screen tearing, or stuttering, and failing to balance byte positioning accuracy and playback decodeability.

[0034] To at least partially address the technical issues in the aforementioned related technologies where relying solely on fragment-level indexes for byte range mapping in drag-and-drop, random access, or keyframe recovery scenarios leads to screen tearing, stuttering, or first-frame decoding failures, this embodiment constructs a virtual transport stream to map multiple video segments into a unified, continuous byte address space. This eliminates the need to pre-generate a physical copy of the complete transport stream, which is expected to reduce object storage overhead corresponding to the physical copy of the complete transport stream, lower object storage and update costs, provide a continuous and randomly accessible virtual transport stream for non-HLS terminals, and shorten drag-and-drop recovery latency for non-HLS terminals. Furthermore, upon receiving a byte range request, the starting offset of the request is mapped forward to the nearest keyframe position, ensuring that the returned byte range starts from the keyframe and that the source data begins at the start of a decodeable frame, enabling the decoder to decode normally. This improves playback stability without altering the semantics of the client request, achieving a balance between decodeability and byte precision.

[0035] The client refers to a video playback client that does not support the HLS protocol but supports HTTP Range requests, and is used to initiate byte range fetching to CDN edge nodes.

[0036] A byte range request refers to a request initiated by a client according to the Range header format of the HTTP protocol, used to request data within a target byte range in the target video. CDN edge nodes can obtain the target byte range [start_req, end_req] by parsing the Range header. For example, a byte range request can be an HTTP Range request or an EXT-X-BYTERANGE request, where EXT-X-BYTERANGE is a tag in the HLS protocol used to specify the byte range within a segment, allowing for more precise control over data transmission.

[0037] The target video refers to the video content currently requested for playback by the client. This corresponds to a set of raw HLS files stored at the CDN edge nodes. A set of raw HLS files refers to the collection of standard HLS format files generated after the video content was initially transcoded and fragmented, including a fragment index file and multiple video segments. The fragment index file is a metadata file describing the playback order, duration, byte range, and storage address of the multiple video segments of the target video; its typical format is .m3u8. Multiple video segments refer to independent media data units divided from the transcoded target video. Each video segment is a continuous audio and video stream of fixed duration (e.g., 10 seconds), typically in TS fragment (.ts) or fMP4 / M4S fragment (.m4s) formats.

[0038] The target byte range refers to the byte range [start_req, end_req] specified in the byte range request; the start offset (denoted as start_req) is the starting byte position of the target byte range in the virtual transport stream; the end offset (denoted as end_req) is the ending byte position of the target byte range in the virtual transport stream.

[0039] A virtual transport stream refers to a virtual continuous byte stream formed by mapping multiple video segments of a target video into a unified continuous byte address space according to the playback order. The server does not need to pre-generate a physical copy of the complete transport stream, and it can also be called a virtual large TS. The essence of a virtual transport stream is the server's logical abstraction and offset mapping of video segments. When the client initiates an HTTP Range request, the CDN edge node accurately locates the target segment sequence and the offset within the segment based on this mapping relationship, dynamically splices and returns the required byte range, without any storage, generation, or synchronization process of a physical copy of the complete transport stream. A physical copy of the complete transport stream is a single entity file generated by merging all video segments in order, occupying independent storage space. Version updates require regeneration and full replacement, resulting in high storage costs, large synchronization delays, and difficulty in ensuring version consistency. A virtual transport stream completely avoids this physical file, only retaining the original video segments and metadata index, with zero storage overhead. Version changes only require updating the index, achieving second-level effectiveness and no redundant storage. Virtual transport streams do not rely on file system-level concatenation but are dynamically assembled through memory stream pipelines. They support high concurrency, low latency, and strong consistency of byte range access, making them a new paradigm of efficient, low-cost, and scalable streaming for non-HLS clients.

[0040] CDN edge nodes record the virtual offset of each byte in the virtual transport stream. The virtual offset of each byte in the virtual transport stream refers to the global byte position number of each byte within the virtual transport stream. It starts from the beginning of the entire video stream (offset 0) and increments byte by byte in playback order until the end of the video. For example, if a video consists of three TS segments with lengths of 2MB, 3MB, and 1.5MB respectively, then the virtual offset range for the first segment is [0, 2097151], the second is [2097152, 5242879], and the third is [5242880, 6815743].

[0041] A keyframe is an independently decodeable I-frame in video encoding. In video encoding, P-frames and B-frames rely on preceding I-frames or other reference frames for decoding. If reading begins from a non-keyframe (such as a P-frame), the client will be unable to reconstruct the image due to the lack of a reference frame, resulting in screen tearing, stuttering, or decoding failure. Therefore, in this embodiment, any playback start point is aligned with an I-frame to ensure decodeability. Using keyframes as "anchor points" for decoding ensures playback continuity. In this embodiment, the CDN edge nodes also record the global byte offset of each keyframe in the virtual transport stream. To ensure that the user-requested start point is not skipped, in this embodiment, the start offset of the target byte range is mapped forward to the virtual offset of the most recent keyframe whose virtual offset is less than or equal to the start offset. Selecting to map forward to the most recent keyframe whose virtual offset is less than or equal to the start offset minimizes redundant data transmission. The virtual offset of the most recent keyframe whose virtual offset is less than or equal to the start offset refers to the virtual position of the I-frame whose virtual offset value does not exceed the start offset and is closest to the start offset among all keyframes. If the origin pull starts from the most recent keyframe with a virtual offset greater than the starting offset, decoding is possible, but the preceding content of the user request will be lost, violating HTTP Range semantics and causing playback misalignment. If an earlier keyframe is selected, decoding is possible, but a large amount of useless data will be read, increasing origin pull bandwidth and latency, and reducing efficiency. In this embodiment, finding the "most recent" I-frame is done as close as possible to the starting point of the user request while ensuring decodeability, achieving "precise start," which guarantees successful decoding while preserving the integrity of the request's byte boundaries to the greatest extent.

[0042] For example, if the client broadcaster requests Range: bytes=5000000–6000000, there are three keyframes (I-frames) in the virtual transport stream, with corresponding virtual offsets of 4900000, 4980000, and 5020000. If the origin pull starts from 5020000 (>5000000), the content [5000000–5019999] will be lost, violating HTTP Range semantics and causing playback misalignment. If the origin pull starts from 4900000 (much less), 120KB of redundant data will be read, increasing bandwidth and latency. If the origin pull starts from 4980000 (≤5000000 and the most recent), only 20KB of necessary preamble will be read, ensuring reliable decoding and output that strictly matches the requested range.

[0043] Optionally, the CDN edge node receives an HTTP request from the client, which carries a Range header field (such as Content-Range, indicating the byte range contained in the current response body) to indicate the byte range requested by the client. The CDN edge node parses the Range header field of the HTTP request, extracts the start and end offsets of the target byte range, and obtains the target byte range. Next, the CDN edge node queries the virtual byte address space location corresponding to the start offset based on the pre-built virtual transport stream, and determines the target video segment where that location is located. The CDN edge node obtains the keyframe distribution information within the target video segment, compares the start offset with the virtual offsets of each keyframe, and determines the keyframe whose virtual offset is less than or equal to the start offset and is closest to the start offset. The virtual offset of this keyframe is then determined as the start virtual offset. This process maps the start offset of the target byte range forward to the virtual offset of the most recent keyframe whose virtual offset is less than or equal to the start offset, ensuring that the returned byte range starts from the keyframe, enabling the decoder to decode correctly. Finally, the CDN edge node reads data from the virtual transport stream, starting from the byte position corresponding to the starting virtual offset and continuing until the byte position corresponding to the ending offset. It then encapsulates the read byte range into an HTTP response and returns it to the client. The CDN edge node outputs data in virtual byte order and does not generate a complete physical copy of the TS stream.

[0044] For example, the corresponding byte ranges of each target fragment covered by the target byte range can be read concurrently and output in virtual byte order in the memory stream pipeline without generating a complete physical copy of the TS. Preferably, an HTTP 206 response is returned along with the corresponding Content-Range, Content-Length, and Accept-Ranges. Accept-Ranges and Content-Length are HTTP response header fields. Accept-Ranges tells the client that this service supports requests by byte range; Content-Length explicitly refers to the "length of this response body." For a normal 200 OK full response, Content-Length can be equal to the entire resource length. For a 206 Partial Content response, Content-Length indicates the length of the segment returned this time, not the total length.

[0045] In some embodiments, when the HTTP request initiated by the client does not carry the Range header field, it is preferable to process the entire range of bytes=0-virtual_end, i.e., return the complete virtual transport stream; or first return Accept-Ranges and Content-Length, and then the client continues to pull according to the compatibility policy. In this embodiment, the CDN edge node returns these two headers when there is no Range request for the first time, guiding the terminal to initiate a precise Range request subsequently.

[0046] The embodiments provided in this application construct a virtual transport stream to achieve a unified byte address mapping for multiple video segments, eliminating the need to pre-generate a complete physical copy of the TS, thus reducing object storage and update costs. Furthermore, by mapping the request start offset forward to the nearest keyframe position, it ensures that the returned byte range starts from the keyframe, enabling the decoder to decode normally. This achieves a balance between decodeability and byte precision, solving the technical problem in related technologies where relying solely on fragment-level indexes for byte range mapping in drag-and-drop, random access, or keyframe recovery scenarios leads to screen tearing, stuttering, or first-frame decoding failure. This improves the stability of video playback and user experience, and shortens the latency of first-frame and drag-and-drop recovery.

[0047] In an exemplary embodiment, the on-demand splicing scheme of related technologies only records the granular mapping relationship of the segments. When the client request spans multiple segments, it is difficult to accurately locate the start and end offsets of reading in each segment, which easily leads to problems such as repeated fetching, positioning errors, and discontinuous response. At the same time, for drag-and-drop, random access, or keyframe recovery scenarios, relying solely on segment-level indexes (such as the start and end offsets of video segments) for byte range mapping can easily cause the source return starting point to fall at a non-keyframe position, resulting in client decoding failure, screen tearing, or stuttering, failing to balance byte positioning accuracy and playback decodeability. To solve this problem, this embodiment introduces a two-level index structure of segment-level indexes and keyframe-level indexes. The segment-level index accurately locates the target video segment where the starting offset is located, and the keyframe-level index aligns the starting offset forward to the virtual byte offset of the nearest keyframe, achieving accurate byte positioning and keyframe alignment across segments. This accurately supports byte positioning, keyframe processing, and sequential splicing of any HTTP Range request in cross-segment scenarios.

[0048] In some embodiments, the target video has a segment-level index and a keyframe-level index.

[0049] The segment-level index, also known as the SegmentIndex, is an index structure used to record metadata information for each video segment. It maps byte-range requests to a target set of segments and a set of offsets within each segment. For each video segment, the segment-level index records its metadata. The metadata for each video segment includes at least the segment number (segment_no), URI, duration, byte size, virtual_start, virtual_end, version_id, ETag, and checksum. Virtual_start represents the starting byte offset of the video segment in the virtual transport stream (accumulated from 0); virtual_end represents the ending byte offset of the video segment in the virtual transport stream (inclusive); version_id represents the unique identifier of the video version to which the video segment belongs, generated by the transcoding or content update system; ETag represents the entity tag of the video segment in object storage, automatically generated by the storage system; and checksum represents the checksum of the video segment content (e.g., a SHA256 digest), calculated and stored by the server.

[0050] In this embodiment, the start and end byte offsets of each video segment among the multiple video segments are recorded in the segment-level index. The start and end byte offsets of each video segment include a start byte offset (virtual_start) and an end byte offset (virtual_end). By recording the start byte offset (virtual_start) and end byte offset (virtual_end) of each video segment through the segment-level index, precise byte mapping is achieved. For any Range request, the target segment sequence covered by the target byte range and the offset within the segment can be accurately calculated, preventing duplicate fetching and boundary misalignment.

[0051] The keyframe-level index, also known as GOPIndex, is an index structure used to record metadata information for each keyframe. It records the metadata for each Group of Pictures (GOP). A GOP is an independent decoding unit in video encoding, consisting of an I-frame and several subsequent P-frames and B-frames. The metadata for each GOP includes at least gop_no (GOP number), the segment number to which the GOP belongs, the keyframe timestamp, the intra-segment start and end offsets, and the virtual start and end offsets. The intra-segment start and end offsets refer to the start and end byte offsets of a GOP within its video segment; the virtual start and end offsets refer to the start and end byte offsets of the GOP after mapping it to the unified byte address space of the virtual transport stream. Intra-segment start and end offsets belong to local coordinates within the segment, while virtual start and end offsets belong to global virtual coordinates.

[0052] In some embodiments, the keyframe-level index also records the virtual byte offset of keyframes in each GOP within the virtual transport stream, and the intra-fragment offset of keyframes in each GOP within their respective video segments. The virtual byte offset of keyframes in each GOP within the virtual transport stream refers to the global byte position of each keyframe within the virtual transport stream, belonging to global virtual coordinates. The intra-fragment offset of keyframes in each GOP within their respective video segments refers to the local byte position of keyframes within each GOP within their respective video segments; that is, the byte offset from the beginning of the keyframe in each GOP within its respective video segment to the first byte of that keyframe, belonging to local physical coordinates.

[0053] In this embodiment, the virtual byte offset of the keyframes in each GOP in the virtual transport stream is recorded by the keyframe-level index, as well as the offset of the keyframes in each GOP within the segment of the video segment to which they belong. When the request is a drag or the first frame, it is automatically aligned forward to the nearest keyframe, ensuring both good decodeability and byte precision.

[0054] In this embodiment, a virtual byte mapping table, VirtualByteMap, is established based on the segment-level index SegmentIndex and the keyframe-level index GOPIndex of the target video. This maps multiple video segments of the target video into a unified virtual byte address space, enabling the client to access the target video through... A single-file Range access can be initiated via a .m3u8.ts file or an equivalent route.

[0055] In some embodiments, for fMP4 / M4S scenarios, the segment-level index SegmentIndex can be expanded into a moof (Media Object Header) / mdat box (Media Data) level range index, and GOPIndex can be replaced or supplemented with an index based on sync sample or key sample.

[0056] In some embodiments, mapping the starting offset of the target byte range forward to the virtual offset of the most recent keyframe whose virtual offset is less than or equal to the starting offset to obtain the starting virtual offset includes: determining the target video segment where the starting offset of the target byte range is located based on the start and end byte offsets of each video segment in a plurality of video segments recorded in the segment-level index; and aligning the starting offset of the target byte range forward to the virtual byte offset of the most recent keyframe in the target video segment whose virtual offset is less than or equal to the starting offset based on the virtual byte offsets of each keyframe in each video segment recorded in the keyframe-level index to obtain the starting virtual offset.

[0057] The target video segment refers to the video segment where the starting offset of the target byte range is located, that is, the video segment whose starting offset falls between the starting byte offset and the ending byte offset of the video segment.

[0058] Optionally, the CDN edge node obtains the segment-level index corresponding to the target video. The segment-level index records the start byte offset (virtual_start) and end byte offset (virtual_end) of each video segment in multiple video segments. The CDN edge node compares the start offset of the target byte range with the start and end byte offsets of each video segment recorded in the segment-level index to determine which video segment's start and end byte offsets the start offset falls between, thus identifying that video segment as the target video segment. Next, the CDN edge node obtains the keyframe-level index corresponding to the target video. The keyframe-level index records the virtual byte offset of each keyframe within each video segment. The CDN edge node queries the keyframe-level index for the virtual byte offsets and virtual offsets of all keyframes within the target video segment. Then, the CDN edge node compares the start offset with the virtual offsets of each keyframe within the target video segment, determining the keyframe whose virtual offset is less than or equal to the start offset and is closest to the start offset. The CDN edge node converts the virtual byte offset of this keyframe into a virtual offset, obtaining the starting virtual offset. This process aligns the starting offset of the target byte range forward to the virtual byte offset of the most recent keyframe in the target video segment whose virtual offset is less than or equal to the starting offset, thus obtaining the starting virtual offset.

[0059] For example, suppose the target video contains three video segments, and the segment-level index records are as follows: the first video segment has a start byte offset of 0 and an end byte offset of 999999; the second video segment has a start byte offset of 1000000 and an end byte offset of 1999999; the third video segment has a start byte offset of 2000000 and an end byte offset of 2999999. If the start offset of the target byte range is 1500000, the CDN edge node determines through comparison that the start offset 1500000 falls between the start byte offset 1000000 and the end byte offset 1999999 of the second video segment, and therefore identifies the second video segment as the target video segment.

[0060] Further assuming the keyframe-level index records that the second video segment contains three keyframes with virtual offsets of 1050000, 1200000, and 1450000, respectively. The CDN edge node compares the starting offset of 1500000 with the virtual offsets of these three keyframes, determining that the virtual offset of 1450000 is less than or equal to the starting offset of 1500000 and is closest to the starting offset. Therefore, the virtual offset of 1450000 is set as the starting virtual offset. This process achieves precise positioning and alignment of the target video segment and keyframes through a two-layer indexing system.

[0061] Figure 3 A virtual large TS streaming transmission system architecture diagram is provided for embodiments of this application, such as... Figure 3 As shown, the system includes a player, CDN edge nodes, a virtual large TS service module, an object storage module (sharded origin server, storing m3u8 files and TS shards), an index storage module (storing shard-level indexes and keyframe-level indexes), a historical stable version index storage module, a prefetch control module (used to determine the prefetch window, concurrent prefetching, and interval alignment), and a metrics acquisition module (used to collect multiple system parameters, such as cache, bandwidth, and QPS). The virtual large TS service module is preferably deployed in the CDN origin link and is used to perform interval resolution, two-layer index positioning, consistency verification, concurrent reading, sequential output, and anomaly degradation.

[0062] Figure 4 A flowchart of a virtual large TS streaming method provided in this application embodiment is shown below. Figure 4 As shown, the m3u8 file and TS segment set corresponding to the target video are obtained from the object storage module. The virtual large TS service module constructs the segment-level index SegmentIndex and the keyframe-level index GOPIndex, and establishes a virtual byte mapping table VirtualByteMap based on the segment-level index SegmentIndex and the keyframe-level index GOPIndex. The CDN edge node receives the terminal HTTP request, parses the Range header, and locates the target byte range [start_req, end_req].

[0063] Figure 5 This application provides a schematic diagram of a two-level index mapping, as shown in the embodiment. Figure 5As shown, after obtaining the m3u8 file and the set of segments {ts1, ts2, ..., tsn} of a target video, the segment order, URI, and duration are parsed first. Then, the byte length size_i, version identifier, and ETag of each video segment are obtained, and the virtual_start and virtual_end of each video segment are calculated using prefix sums. In this embodiment, SegmentIndex records at least segment_no, uri, duration, byte_size, virtual_start, virtual_end, version_id, ETag, and checksum, which are used to map HLS segments to a unified virtual byte space (i.e., a virtual byte stream). GOPIndex records at least gop_no, the segment number, the keyframe timestamp, the start and end offsets within the segment, the virtual start and end offsets, and the TS packet alignment offset, which are used to locate the random position near the boundary between the keyframe and the TS packet. For example, when a video contains three segments (assuming the 17th to 19th TS) with byte lengths of 2MB, 3MB, and 1.5MB respectively, the corresponding virtual ranges can be [0, 2097151], [2097152, 5242879], and [5242880, 6815743] respectively. When the client initiates a Range: bytes=3600000-3900000 request, the VirtualByteMap determines that the request spans the 17th segment (17.ts) and the 18th segment (18.ts), and the intra-segment offsets of the 17th and 18th segments are [(17.ts, 348416-2097151), (18.ts, 0-151264)], and can be aligned forward to the nearest keyframe according to GOPIndex.

[0064] This embodiment introduces a two-layer index structure of segment-level index and keyframe-level index. The segment-level index accurately determines the target video segment where the starting offset is located, and the keyframe-level index aligns the starting offset forward to the nearest keyframe. This achieves accurate byte positioning and keyframe alignment across segments, solving the technical problems in related technologies where inaccurate cross-segment request offset calculation leads to repeated fetching, discontinuous response, decoding failure and screen distortion when dragging the first frame, when only segment-level mapping is used. It improves the accuracy of cross-segment range positioning, reduces repeated fetching, and shortens the latency of the first frame and drag recovery.

[0065] In one exemplary embodiment, each of the multiple video segments includes multiple transport stream packets.

[0066] A transport stream packet is the basic encapsulation unit used for video data transmission, also known as a TS packet or Transport Stream Packet. Each transport stream packet has a fixed byte length, typically 188 bytes, and consists of a header and a payload. The header identifies the attributes of the transport stream packet, while the payload carries the actual audio and video data.

[0067] Each transport stream packet has a corresponding boundary, which refers to the starting byte offset of each transport stream packet within its respective video segment; that is, the offset position of the first byte of the transport stream packet within the video segment. Since each transport stream packet has a fixed length of 188 bytes, the boundaries of adjacent transport stream packets are separated by 188 bytes.

[0068] There is an inclusion relationship between video segments and transport stream packets. Each video segment (such as a TS fragment file) contains multiple transport stream packets, and a video segment typically contains one or more Group of Pictures (GOPs). GOP data is mapped to multiple 188-byte TS packets during transmission. Specifically, the audio and video data within a video segment is divided into multiple 188-byte transport stream packets according to the transport stream protocol. These transport stream packets are arranged sequentially to constitute the byte content of the video segment. Therefore, the starting byte position of a video segment corresponds to the boundary of the first transport stream packet within that video segment, and any byte offset within a video segment can be mapped to the corresponding transport stream packet boundary.

[0069] In some embodiments, for drag-and-drop, random access, or keyframe recovery scenarios, relying solely on fragment-level information for byte range mapping makes it difficult to balance decodeability and byte precision. Specifically, when the byte range requested by the client is not aligned to the TS packet boundary, TS packet truncation leads to transport layer parsing anomalies, preventing the client from correctly parsing the TS packet after receiving data, thus affecting the continuity and stability of video playback. To address this issue, this embodiment, based on the above embodiments, further aligns the starting virtual offset to the boundary of the transport stream packet, ensuring that the returned byte range starts from the complete TS packet, thereby balancing keyframe decodeability and the correctness of the TS transport encapsulation boundary.

[0070] In some embodiments, the method further includes: aligning the starting virtual offset to the boundary of the transport stream packet whose most recent virtual offset is less than or equal to the starting virtual offset, to obtain the starting packet alignment offset; and returning the byte range in the virtual transport stream between the starting packet alignment offset and the termination offset of the target byte range to the client.

[0071] In this embodiment, when the client requests improved decoding friendliness, the target fragment set covering the target byte range and the read offset within each fragment are determined based on the fragment-level index in the VirtualByteMap. When the terminal strategy requires improved decoding friendliness, the origin retrieval starting point is aligned forward to the nearest keyframe boundary based on the keyframe-level index GOPIndex, and further aligned to the TS packet boundary. That is, the starting offset start_req of the target byte range is aligned forward to the nearest keyframe boundary that is less than or equal to the starting offset start_req, and then the starting offset start_req after alignment with the keyframe is further aligned again to the nearest TS packet boundary that is less than the starting offset start_req. The ending offset end_req of the target byte range does not need to undergo the same mechanical operation; it is usually determined whether to extend backward depending on the origin retrieval strategy.

[0072] The starting virtual offset is the adjusted starting position obtained after keyframe alignment, ensuring that it begins from the keyframe. If the starting virtual offset is aligned backward to a transport stream packet boundary larger than the starting virtual offset, the returned byte range may skip the beginning of the keyframe data, resulting in incomplete keyframe data and preventing the decoder from decoding correctly. Therefore, in this embodiment, the starting virtual offset is aligned to the transport stream packet boundary where the virtual offset is less than or equal to the starting virtual offset, ensuring that the keyframe data is complete and starts from a complete TS packet. This guarantees both the decodeability of the keyframe and the correctness of the TS packet boundary. Furthermore, if an earlier TS packet boundary is chosen (e.g., 10 packets away from the starting virtual offset), an additional 1880 bytes of redundant data need to be read, increasing back-to-source bandwidth, buffer pressure, and response latency, thus reducing efficiency. If the nearest TS packet boundary (i.e. the one immediately before the starting offset) is selected, only one more TS packet (≤188 bytes) needs to be read, which is the minimum additional overhead to meet the TS encapsulation requirements. Therefore, in this embodiment, the starting virtual offset is aligned to the boundary of the transport stream packet whose virtual offset is less than or equal to the starting virtual offset, rather than to the boundary of the transport stream packet whose virtual offset is greater than the starting virtual offset. This can compress the system overhead to the theoretical minimum while ensuring absolutely reliable playback.

[0073] The starting virtual offset is aligned to the boundary of the most recent transport stream packet whose virtual offset is less than or equal to the starting virtual offset, resulting in the starting packet alignment offset. The starting packet alignment offset refers to the adjusted starting byte offset obtained by aligning the starting virtual offset forward to the boundary of the most recent transport stream packet. This ensures that the returned byte range begins with a complete transport stream packet. The starting packet alignment offset is less than or equal to the starting virtual offset, and the difference between the starting packet alignment offset and the starting virtual offset is less than the length of one transport stream packet (i.e., less than 188 bytes). The starting packet alignment offset is a global offset value calculated and determined in the unified byte address space of the virtual transport stream. It does not depend on physical fragment boundaries but is based on logically mapped virtual coordinates, ensuring that regardless of which physical TS fragment the data originates from, the starting point of the read always conforms to the TS packet encapsulation protocol, while accurately matching the user's requested range.

[0074] Optionally, after obtaining the starting virtual offset, the CDN edge node calculates the corresponding transport stream packet position within the virtual transport stream. Since each transport stream packet has a fixed length of 188 bytes, the CDN edge node can determine the offset of the starting virtual offset within the current transport stream packet by performing a modulo operation on the starting virtual offset. The CDN edge node calculates the integer part of the starting virtual offset divided by 188, and then multiplies this integer part by 188 to obtain the starting packet alignment offset. This process ensures that the starting packet alignment offset corresponds to the beginning position of a complete transport stream packet. Finally, starting from the byte position corresponding to the starting packet alignment offset, the CDN edge node reads data from the virtual transport stream until the byte position corresponding to the ending offset, encapsulates the read byte range into an HTTP response, and returns it to the client. Because the starting packet alignment offset corresponds to the boundary of a complete transport stream packet, the returned byte range starts from the complete transport stream packet, allowing the client to correctly parse the transport stream packet.

[0075] For example, assuming the initial virtual offset is 1000 bytes and each transport stream packet is 188 bytes long, the CDN edge node calculates that the integer part of 1000 divided by 188 is 5 (because 1000 ÷ 188 ≈ 5.32), so the initial packet alignment offset is 5 × 188 = 940 bytes. The CDN edge node reads data from the 940th byte of the virtual transport stream until the byte position corresponding to the ending offset, and returns the read byte range to the client. Since the 940th byte corresponds to the starting position of the 6th transport stream packet (counting from 0), the returned byte range starts from the complete transport stream packet, and the client can correctly parse the transport stream packet data.

[0076] This embodiment, based on keyframe alignment, further aligns the starting virtual offset to the transport stream packet boundary, ensuring that the returned byte range starts from both the keyframe and the complete transport stream packet. This balances the keyframe's decodability with the correctness of the TS transport encapsulation boundary, solving the technical problem of transport layer parsing abnormalities caused by TS packet truncation in related technologies. It improves the continuity and stability of video playback and avoids playback stuttering or screen tearing caused by misaligned TS packet boundaries.

[0077] In one exemplary embodiment, for drag-and-drop, random access, or keyframe recovery scenarios, relying solely on fragment-level information makes it difficult to determine the relationship between the requested range and keyframe boundaries, TS packet boundaries, or GOP boundaries, making it difficult to balance decodeability and byte precision. Specifically, when the byte range requested by the client is not aligned to the TS packet boundary, TS packet truncation will cause transport layer parsing anomalies, and the client will be unable to correctly parse the TS packet after receiving data, thus affecting the continuity and stability of video playback. To solve this problem, this embodiment, based on keyframe alignment, further aligns the starting virtual offset forward to the transport stream packet boundary according to the transport stream packet boundary recorded in the keyframe-level index, ensuring that the returned byte range starts from the complete TS packet, thereby balancing keyframe decodeability and the correctness of the TS transport encapsulation boundary.

[0078] In some embodiments, aligning the starting virtual offset to the boundary of the transport stream packet whose most recent virtual offset is less than or equal to the starting virtual offset to obtain the starting packet alignment offset includes: aligning the starting virtual offset forward to the boundary of the transport stream packet in the target video segment whose most recent virtual offset is less than or equal to the starting virtual offset, based on the boundary of each transport stream packet in each video segment recorded in the keyframe-level index, to obtain the starting packet alignment offset.

[0079] The boundary of a transport stream packet refers to the starting byte offset of each transport stream packet within its respective video segment; that is, the offset position of the first byte of the transport stream packet within the video segment. The boundaries of transport stream packets are recorded in the keyframe-level index GOPIndex, used to identify the precise position of each transport stream packet within the video segment. The keyframe-level index also records information such as the offset of the source return starting point of each GOP after alignment with the TS packet boundaries, used to balance the decodeability of keyframes with the correctness of TS transport encapsulation boundaries. A TS fragment typically contains one or more GOPs, and GOP data is mapped into multiple 188-byte TS packets during transmission. By recording the boundaries of each transport stream packet through the keyframe-level index, TS packet boundary alignment can be further achieved on top of keyframe alignment, ensuring that the returned byte range begins both from a keyframe and from a complete transport stream packet.

[0080] Optionally, after determining the starting virtual offset using the keyframe-level index, the CDN edge node queries the keyframe-level index for the boundary of each transport stream packet within the target video segment. The keyframe-level index records the boundaries of all transport stream packets within each video segment, and these offset values ​​are arranged in byte order. Next, the CDN edge node compares the starting virtual offset with the boundaries of each transport stream packet within the target video segment. Since the boundaries of transport stream packets are local coordinates within the video segment, the CDN edge node needs to convert the boundaries into virtual offsets, that is, add the boundary to the starting byte offset of the target video segment to obtain the virtual offset of each transport stream packet in the virtual transport stream. Then, the CDN edge node determines the transport stream packet whose virtual offset is less than or equal to the starting virtual offset and is closest to the starting virtual offset. The boundary of this transport stream packet is converted into a virtual offset to obtain the starting packet alignment offset. This process aligns the starting virtual offset forward to the boundary of the nearest transport stream packet in the target video segment whose virtual offset is less than or equal to the starting virtual offset, thus obtaining the starting packet alignment offset.

[0081] For example, suppose the starting byte offset of the target video segment is 1,000,000, and the starting virtual offset is 1,450,120 bytes. The CDN edge nodes query the transport stream packet boundaries within the target video segment from the keyframe-level index. Assume the queried boundaries include 450,000, 450,188, and 450,376 (corresponding to transport stream packets starting at bytes 450,000, 450,188, and 450,376 within the video segment). The CDN edge nodes convert these boundaries into virtual offsets: 450,000 + 1,000,000 = 1,450,000, 450,188 + 1,000,000 = 1,450,188, and 450,376 + 1,000,000 = 1,450,376. The CDN edge node compares the starting virtual offset 1450120 with these virtual offsets. It determines that virtual offset 1450000 is less than or equal to the starting virtual offset 1450120 and is the closest to the starting virtual offset; therefore, 1450000 is determined as the starting packet alignment offset. Since 1450000 corresponds to boundary 450000, i.e., the transport stream packet starting at byte 450000 within the target video segment, the returned byte range starts from the complete transport stream packet, allowing the client to correctly parse the transport stream packet data.

[0082] like Figure 4 As shown, the Virtual TS service module determines the target fragment set covering the target byte range and the read offset within each fragment according to the Virtual ByteMap table, and aligns the source return starting point forward to the nearest keyframe boundary according to the keyframe-level index GOPIndex, and further aligns it to the TS packet boundary.

[0083] This embodiment, based on achieving dual-layer index positioning and keyframe alignment, further aligns the starting virtual offset forward to the transport stream packet boundary according to the transport stream packet boundary recorded in the keyframe-level index. This ensures that the returned byte range starts from both the keyframe and the complete transport stream packet, balancing the keyframe's decodability with the correctness of the TS transport encapsulation boundary. It solves the technical problem of transport layer parsing abnormalities caused by TS packet truncation in related technologies, improves the continuity and stability of video playback, and avoids playback stuttering or screen tearing caused by misaligned TS packet boundaries. Compared with ordinary on-demand splicing solutions, this embodiment not only records fragment-level information but also further records keyframe-level offsets and GOP boundaries, thereby improving cross-fragment positioning accuracy and drag-and-drop recovery friendliness.

[0084] In an exemplary embodiment, in the related technology, in scenarios of multi-node concurrent source return, shard rolling update, or asynchronous refresh of object storage replicas, if the multiple shards involved in the target byte range come from different versions, it is easy for the data corresponding to the same range to be mixed with multiple versions, resulting in terminal lag, screen distortion, or decoding abnormalities.

[0085] To address the aforementioned issues, this embodiment introduces a consistency token strongly bound to the target byte range. Consistency checks are performed before the origin server access, ensuring that all video segments within the target byte range originate from the same version and preventing the output of mixed-version data. Here, "origin server access" refers to the process where a CDN edge node, when its local cache misses, initiates a data read request to its upstream storage system (such as object storage or the origin server) to retrieve the missing TS fragments or byte range data.

[0086] In some embodiments, the target video includes a segment index file; the segment index file is used to record metadata of multiple video segments; the target video has a corresponding segment-level index.

[0087] The segment index file is an index file that records the metadata of multiple video segments of the target video. The metadata of a video segment refers to information describing the attributes of each video segment. In the HLS protocol, the segment index file is typically an m3u8 file, and the metadata of each video segment includes information such as the URI, duration, and byte length of each video segment. The index version number of the segment index file is a unique identifier that identifies the current version of the segment index file. It is generated by the transcoding system or content update system and is used to track changes to the index file.

[0088] In some embodiments, before mapping the starting offset of the target byte range forward to the virtual offset of the most recent keyframe whose virtual offset is less than or equal to the starting offset to obtain the starting virtual offset, the method further includes: generating a first token based on the target byte range, the index version number of the fragment index file, and the metadata of the target fragment sequence; wherein the target fragment sequence refers to at least one video segment among multiple video segments that overlaps with the target byte range; in response to the first token being consistent with the version of the fragment-level index, performing the mapping of the starting offset of the target byte range forward to the virtual offset of the most recent keyframe whose virtual offset is less than or equal to the starting offset to obtain the starting virtual offset; in response to the first token being inconsistent with the version of the fragment-level index, performing a degradation strategy.

[0089] The target segment sequence refers to at least one video segment among multiple video segments that overlaps with the target byte range; that is, all video segments covered by the target byte range. The metadata of the target segment sequence refers to the metadata set of each video segment within the target segment sequence. For example, the metadata of the target segment sequence includes information such as video identifier, target segment sequence, segment ETag set, segment checksum set, and start and end offsets of the target byte range. The video identifier typically comes from the video resource context, playback request parameters, or routing identifier and is used to uniquely identify the current target video; the target segment sequence is the set of video segments that overlap with the target byte range; the segment ETag set is the set of ETag values ​​for each segment in the target segment sequence; and the segment checksum set is the set of checksums for each segment in the target segment sequence.

[0090] The first token is a consistency token that binds the target byte range, the index version number of the segment index file, and the metadata of the target segment sequence. It is used to verify whether the segment versions involved in the target byte range are consistent. In this embodiment, the preferred method for generating the first token is: Token=HMAC-SHA256(server_key, concat(video_id,bitrate_id, index_version, ordered(segment_seq_list), sorted(etag_set),sorted(checksum_set), start_req, end_req, expiry_ts)), where video_id (video identifier) ​​usually comes from the video resource context, playback request parameters, or routing identifier, and is used to uniquely identify the current target video. It is not a segment-level index field. bitrate_id (ID that identifies the video bitrate layer, such as 720p, 1080p, 3000k) usually comes from the bitrate variant selection result, playback context, or m3u8 level information, and is used to identify the currently accessed bitrate version. It is usually not directly a segment-level index field. `index_version` (the index version number of the segmented index file) typically comes from the index snapshot metadata of the current segment-level index `SegmentIndex` / virtual byte map table `VirtualByteMap`. It identifies the index version used for this mapping and verification and should not be simply interpreted as a field of a single segment, but rather as version information of the entire index snapshot. For example, `index_version` could be the index version number of the u3m8 index file. `sorted(etag_set)` (the set of segmented ETags) represents the set of ETags corresponding to each target segment covered by the target byte range. It can usually be extracted from the `SegmentIndex` record corresponding to the target segment and sorted according to rules. When key protection is not required, a SHA256 digest concatenated from the aforementioned fields can also be used.

[0091] like Figure 5 As shown, after determining the target byte range, a first token (a hash value) is generated before returning to the source, based on the video identifier, index version number, target segment sequence, segment ETag set, segment check value set, and start and end offset of the target byte range. The first token is then verified against the version number of the segment-level index SegmentIndex. If the verification is successful, the subsequent process is executed; otherwise, a downgrade strategy is implemented.

[0092] The fact that the first token matches the version of the fragment-level index means that the versions of all video segments involved in the target byte range match the version of the currently used fragment-level index, ensuring that the returned data comes from the same version and avoiding playback abnormalities caused by mixed version data.

[0093] The inconsistency between the first token and the fragment-level index version means that the fragments involved in the target byte range may come from different versions, indicating version drift or inconsistency. A degradation strategy needs to be implemented to ensure playback stability. The degradation strategy is executed when the first token and fragment-level index version are inconsistent, the index version and fragment version are inconsistent, or the origin pull failure reaches a threshold. The degradation strategy is a fallback mechanism implemented when consistency checks fail, ensuring that the system can still provide service under abnormal conditions. In this embodiment, the degradation strategy includes four levels (L1-L4). The L1 degradation strategy only retrieves the latest version from the source and re-verifies the fragments that are locally inconsistent. The L2 degradation strategy switches the historical stable version index (referring to the stable index snapshot used for rollback when the overall version of the target byte range drifts) when the overall version of the target byte range drifts. The L3 degradation strategy degrades to direct pass-through at the fragment level when the historical stable version index is unavailable. The L4 degradation strategy returns a 503 or recoverable error message with a retry indication when the source station is unreachable or the retry failure reaches a threshold. At the same time, it records the failure event for subsequent scheduling and parameter correction.

[0094] Optionally, the CDN edge node receives the byte range request sent by the client and parses out the target byte range [start_req, end_req]. The CDN edge node determines the target segment sequence covering the target byte range, i.e., the set of video segments overlapping with the target byte range, based on the VirtualByteMap. The CDN edge node obtains the segment index file (m3u8) of the target video and its index version number. The CDN edge node extracts the metadata of each segment in the target segment sequence, including version ID, ETag, and checksum. The CDN edge node generates a first token based on the target byte range, the index version number of the segment index file, and the metadata of the target segment sequence, preferably using the HMAC-SHA256 or SHA256 digest algorithm. The CDN edge node performs a consistency check between the first token and the version of the segment-level index, checking whether the version of the target segment sequence is consistent with the current index version. If the check is consistent, the CDN edge node continues to execute the keyframe mapping step, mapping the starting offset of the target byte range forward to the virtual offset of the most recent keyframe. If the verification fails, the CDN edge node executes a degradation strategy, selecting the appropriate degradation level based on the specific situation: If only some shards are inconsistent, execute L1 degradation: retrieve the latest version from the origin server for each locally inconsistent shard and re-verify. If the overall version of the target byte range has drifted, execute L2 degradation: switch to a historical stable version index. If the historical stable version index is unavailable, execute L3 degradation: degrade to direct pass-through at the shard level. If the origin server is unreachable or retry fails, execute L4 degradation: return a 503 or recoverable error message.

[0095] Figure 6 This is a schematic diagram of a consistency token dual-verification and degradation recovery state machine provided in an embodiment of this application, as shown below. Figure 6As shown, when a terminal initiates a request for Range: bytes=1000000-3000000, the server first determines, based on the VirtualByteMap, that the request spans two shards, ts1 and ts2. The read range for ts1 is [1000000, 2097151], and the read range for ts2 is [0, 902848]. The CDN edge node can generate a consistency token based on video_id, bitrate_id, index_version, etag_ts1, etag_ts2, start_req, and end_req. Preferably, the token is HMAC-SHA256(server_key, concat(video_id, bitrate_id, index_version, sorted(etag_set), start_req, end_req, expiry_ts)), or the SHA256 digest value concatenated from the aforementioned fields is used. Before initiating a retrieval to the origin server, the server performs a first check to confirm that the current index version matches the target shard version. A second check is performed before the read is completed and the data is officially output to confirm that no version drift occurred during the retrieval. If the second check fails, it is preferable to switch to a historically stable version index for remapping and then perform a retrieval to the origin server again.

[0096] like Figure 6 As shown, when inconsistencies in shard versions are detected within the target range, any target shard fails to retrieve the origin server's version to the latest version and re-verifies it, or prefetching causes insufficient QPS margin at the origin server, the CDN edge node preferentially performs a four-level degradation process: L1, retrieves the latest version from the origin server for locally inconsistent shards and re-verifies it; L2, when the overall version of the target range drifts, switches to a historical stable version index and remaps it; L3, when the historical index is unavailable, it degrades to direct pass-through at the shard level; L4, when the origin server is unreachable or retry failures reach the threshold, it returns a 503 error or a recoverable error message with a Retry-After indication. During the above degradation process, the CDN edge node can also record fault logs, update the scheduling blacklist, shrink prefetch parameters, and re-enter the normal dual verification and constrained prefetching process after conditions recover.

[0097] In this embodiment, a first token is generated and verified before the source is retrieved, ensuring that all fragments involved in the target byte range come from the same version. This avoids the output of mixed version data and solves the problem in related technologies where the target byte range may be mixed with fragments of different versions when multiple nodes retrieve the source concurrently, leading to playback abnormalities. This improves the stability and reliability of video playback. Compared with related virtual file stream schemes, this embodiment introduces a consistency token bound to the target byte range and a historical stable version index rollback to solve the problem of mixed version output from multiple nodes.

[0098] In one exemplary embodiment, related technologies suffer from the problem that even if consistency checks are performed before returning to the source, fragment version changes may occur during the source return process, resulting in inconsistent data versions returned to the client. To address this issue, this embodiment performs a second consistency check before output, forming a dual-check mechanism to ensure that the final data returned to the client is version consistent.

[0099] In some embodiments, the target video includes a segment index file; the segment index file is used to record metadata of multiple video segments; the target video corresponds to a segment-level index. The segment index file, the metadata of the video segments, and the segment-level index have been explained in the foregoing embodiments and will not be repeated here.

[0100] In some embodiments, before returning the byte range in the virtual transport stream between the starting virtual offset and the ending offset of the target byte range to the client, the method further includes: generating a second token based on the target byte range, the index version number of the fragment index file, and the metadata of the target fragment sequence; wherein the target fragment sequence refers to at least one video segment among a plurality of video segments that overlaps with the target byte range; in response to the second token being consistent with the version of the fragment-level index, returning the byte range in the virtual transport stream between the starting virtual offset and the ending offset of the target byte range to the client; and in response to the second token being inconsistent with the version of the fragment-level index, executing a degradation strategy.

[0101] The target byte range, the index version number of the fragment index file, and the metadata of the target fragment sequence have been explained in the previous embodiments and will not be repeated here.

[0102] In this embodiment, the second token refers to a consistency verification object generated before output, used to verify whether the fragment versions involved in the target byte range are consistent. The generation method of the second token can be the same as that of the first token, and will not be described again here.

[0103] The second token matching the version of the fragment-level index means that the versions of all fragments involved in the target byte range match the version of the currently used fragment-level index, ensuring that the returned data comes from the same version and avoiding playback anomalies caused by mixed version data.

[0104] The inconsistency between the second token and the fragment-level index version indicates that a fragment version change may have occurred during the origin pull process, resulting in version drift or inconsistency. A degradation strategy is required to ensure playback stability. When the second token and the fragment-level index version are inconsistent, a degradation strategy is executed. The degradation strategy has been explained in the preceding embodiments and will not be repeated here.

[0105] Optionally, the CDN edge node receives the byte range request sent by the client and parses out the target byte range [start_req, end_req]. The CDN edge node determines the target fragment sequence covering the target byte range based on the VirtualByteMap. The CDN edge node performs keyframe mapping and transport stream packet boundary alignment to obtain the start packet alignment offset. The CDN edge node concurrently reads the data of the corresponding byte range of each target fragment. Before returning the data to the client, the CDN edge node obtains the fragment index file of the target video and its index version number again. The CDN edge node extracts the metadata of each fragment in the target fragment sequence, including version ID, ETag, and checksum. The CDN edge node generates a second token based on the target byte range, the index version number of the fragment index file, and the metadata of the target fragment sequence, preferably using the HMAC-SHA256 or SHA256 digest algorithm. The CDN edge node performs a consistency check between the second token and the fragment-level index version to check whether the version of the target fragment sequence is consistent with the current index version. If the verification matches, the CDN edge node returns the read byte data to the client in sequence, returns an HTTP 206 Partial Content response, and sets the correct Content-Range and Content-Length headers. If the verification fails, the CDN edge node executes a degradation strategy, selecting an appropriate degradation level based on the specific situation: If only some fragments are inconsistent, execute L1 degradation: retrieve the latest version from the origin server for the partially inconsistent fragments and re-verify. If the entire version of the target byte range has drifted, execute L2 degradation: switch to a historical stable version index. If the historical stable version index is unavailable, execute L3 degradation: degrade to direct pass-through at the fragment level. If the origin server is unreachable or retry fails, execute L4 degradation: return 5.

[0106] 3. The error message may be recovered.

[0107] like Figure 4 As shown, the Virtual Large TS service module generates a consistency token based on the video identifier, index version number, target fragment sequence, fragment ETag set, fragment checksum set, and the start and end offsets of the target byte range. It performs at least two consistency checks before returning to the origin and before outputting. When consistency checks fail, the index version is inconsistent with the fragment version, or the return-to-origin failure reaches a threshold, a tiered degradation strategy is applied, and historical stable version indexes can be retrieved from the historical stable version index storage module. When consistency checks pass, the Virtual Large TS service module concurrently reads the corresponding byte ranges of each target fragment from the object storage module through the origin scheduling module and outputs them in virtual byte order in the memory stream pipeline, returning an HTTP 206 response.

[0108] In this embodiment, a second token is generated and verified again before output, forming a dual verification mechanism to ensure that the data version returned to the client is consistent. This solves the playback anomaly problem caused by the change of fragment version during the back-to-source process in related technologies, and improves the stability and reliability of video playback. Compared with related virtual file stream schemes, this embodiment introduces a consistency token bound to the target byte range and a historical stable version index rollback to solve the problem of multi-node mixed version output.

[0109] In one exemplary embodiment, in video distribution systems, a popularity-based prefetching strategy is commonly used to cache popular segments in advance in order to improve playback smoothness. However, hotspot preloading schemes in related technologies typically only focus on popularity or cache hit rate, which may amplify issues such as origin server jitter and peak load on the origin server in high-concurrency scenarios.

[0110] To address the aforementioned issues, this embodiment introduces a constrained prefetch control mechanism. Based on the source server's query margin per second and the source-to-source amplification ratio, the prefetch behavior is controlled to prevent prefetching from going out of control. In the first frame, dragging, and hotspot scenarios, prefetching is implemented in a constrained manner, thereby reducing the instantaneous pressure on the source server and improving the playback experience.

[0111] In some embodiments, the method further includes: obtaining the source station's query margin parameter per second and determining the source-back-to-source amplification ratio of the source station storing the target video; the source-back-to-source amplification ratio characterizes the resource preloading capability of the source station; in response to the source-back-to-source amplification ratio being greater than a preset maximum amplification threshold, or the source station's query margin parameter per second being less than a preset minimum margin threshold, determining a preset minimum prefetch window as the target prefetch window; starting from the termination offset of the target byte range, reading the set of prefetch segments covered by the target prefetch window in the virtual transport stream, and caching the set of prefetch segments in a specified cache.

[0112] Prefetching refers to reading bytes outside the target byte range of the current request that may be accessed later. In this embodiment, prefetching behavior is controlled based on the origin server's query margin per second and the origin server amplification ratio to prevent prefetching from getting out of control.

[0113] The origin server's remaining query per second (QPS) parameter refers to the current remaining query processing capacity per second of the origin server. It is typically calculated by the monitoring and metric collection module based on the origin server's current QPS, rate limiting threshold, reserved capacity, and real-time load. It can be expressed as the current remaining available request capacity or a normalized remaining value, and is provided to the prefetch control module. The origin server refers to the underlying data storage system or server that stores raw HLS shard files (such as m3u8 + TS) and responds to CDN edge node requests to the origin server. It is typically object storage (such as Alibaba Cloud OSS, AWS S3) or a content origin server.

[0114] The origin-fetching amplification ratio refers to the ratio of the number of bytes actually read by the origin server to the number of bytes actually sent by the terminal, and is used to characterize the resource preloading capability of the origin server. In this embodiment, the origin-fetching amplification ratio can be expressed as: rho = fetched_bytes / delivered_bytes, where rho represents the origin-fetching amplification ratio; fetched_bytes represents the number of bytes actually read by the origin server; and delivered_bytes represents the number of bytes actually sent by the terminal.

[0115] The preset maximum amplification threshold refers to the maximum allowable value of the source-to-origin amplification ratio. Exceeding this value indicates low prefetch efficiency. Specifically, a source-to-origin amplification ratio greater than the preset maximum amplification threshold means that in order to satisfy a small number of data requests from the terminal, the origin server needs to read a large amount of additional data, resulting in low prefetch efficiency. Continuing to maintain a large prefetch window will lead to a waste of origin server resources and an increase in the origin server load.

[0116] The preset minimum margin threshold refers to the minimum allowable QPS margin of the origin server. A value below this threshold indicates that the origin server is under high load. Specifically, if the origin server's query per second margin parameter is less than the preset minimum margin threshold, it means that the origin server is currently under high load and has limited remaining processing capacity. Continuing to implement an aggressive prefetching strategy may further increase the load on the origin server, or even cause it to overload. In this case, it is necessary to limit the prefetching behavior to protect the stability of the origin server.

[0117] A source-to-source amplification ratio greater than the preset maximum amplification threshold and a source server query margin per second less than the preset minimum margin threshold both indicate that it is not suitable to continue expanding the prefetch. The prefetch window should be shrunk, prefetch concurrency reduced, and source server stability prioritized. In this embodiment, when the source-to-source amplification ratio is greater than the preset maximum amplification threshold, or the source server query margin per second is less than the preset minimum margin threshold, a hard constraint is triggered first. Instead of continuing to amplify the prefetch window according to the normal window after heat correction, the target prefetch window is directly shrunk to the preset minimum prefetch window. The target prefetch window (denoted as W_final) refers to the final window size for prefetching. The preset minimum prefetch window (denoted as Wmin) refers to the minimum prefetch window size used under hard constraint conditions to protect source server stability. In this embodiment, the target prefetch window W_final = Wmin.

[0118] After determining the target prefetch window, starting from the termination offset of the target byte range, the set of prefetch segments covered by the target prefetch window in the virtual transport stream is read. The set of prefetch segments refers to the set of video segments covered by the target prefetch window.

[0119] Optionally, the CDN edge node receives a byte range request from the client and parses out the target byte range [start_req, end_req]. The CDN edge node processes the request and returns the data for the target byte range. The CDN edge node obtains the QPS margin parameter of the origin server and acquires the current load and remaining processing capacity of the origin server through the monitoring and metric collection module. The CDN edge node calculates the origin amplification ratio: rho = fetched_bytes / delivered_bytes, where fetched_bytes represents the number of bytes actually read by the origin server; delivered_bytes represents the number of bytes actually delivered by the terminal. The CDN edge node determines whether a hard constraint condition is triggered: if the origin amplification ratio is greater than the preset maximum amplification threshold, or the origin server's QPS margin parameter is less than the preset minimum margin threshold, a hard constraint is triggered, and the CDN edge node determines the preset minimum prefetch window as the target prefetch window. Starting from the end offset end_req of the target byte range, the CDN edge node determines the set of prefetched shards covered by the target prefetch window. The CDN edge node reads the data of the prefetched shard set and caches it in a specified cache for use by subsequent requests.

[0120] This embodiment introduces a constrained prefetch control mechanism, which controls prefetch behavior based on the source station QPS margin and the source-backhaul amplification ratio. This avoids source station load peaks caused by uncontrolled prefetching, solves the problem that hotspot preloading schemes in related technologies may amplify source-backhaul jitter and source station load peaks, and improves the stability and reliability of the system.

[0121] In one exemplary embodiment, the related technology suffers from a problem where the prefetching strategy is singular and does not take into account the combined influence of multiple system parameters, resulting in unsatisfactory prefetching results.

[0122] To address the aforementioned issues, this embodiment calculates the prefetch window based on multiple system parameters under normal conditions (without hard constraints), making the prefetch strategy more reasonable.

[0123] In some embodiments, the method further includes: in response to the source amplification ratio being less than or equal to a preset maximum amplification threshold and the source station query margin parameter per second being greater than or equal to a preset minimum margin threshold, generating a basic prefetch window based on the drag direction parameter, terminal buffer level parameter, available bandwidth parameter and source station query margin parameter per second, and determining the basic prefetch window as the target prefetch window.

[0124] Among them, a back-to-source amplification ratio less than or equal to the preset maximum amplification threshold means that the prefetching efficiency is high and the amount of extra data read from the source station to meet the terminal data request is within a reasonable range; a source station query margin parameter greater than or equal to the preset minimum margin threshold means that the current load of the source station is low and the remaining processing capacity is sufficient to withstand a certain degree of prefetching requests.

[0125] The drag direction parameter (D) refers to the drag direction of the client player, which is usually determined based on the relative relationship between the terminal's two most recent playback positions, the target position, and the current playback position. For example, dragging from a smaller time point to a larger time point can be considered forward; conversely, dragging backward can be considered backward. Alternatively, the player can directly include the drag direction identifier in the request.

[0126] The terminal buffer level parameter (B) refers to the current amount of buffered data on the client player. It is usually calculated by the player side based on the current buffered duration, the number of buffered bytes, or the duration of continuous playback, and synchronized to the server through request parameters, instrumentation reports, or session status. If the terminal cannot report explicitly, the server can also make an approximate estimate based on the most recent transmission rate and request interval.

[0127] The available bandwidth parameter (N) refers to the available network bandwidth between the client and the server. It is usually obtained by the player side based on download speed tests, historical segment download rates, congestion control results, or network quality assessments, and then reported to the server. Alternatively, it can be estimated by the server based on the current connection throughput, historical request latency, and origin download rate.

[0128] The source server query capacity per second (QPS, Q) parameter refers to the current remaining query processing capacity per second of the source server. It is usually calculated by the monitoring and indicator acquisition module based on the current QPS, rate limiting threshold, reserved capacity and real-time load of the source server. It can be expressed as the current remaining available request capacity or a normalized reserve value and is provided to the prefetch control module.

[0129] In this embodiment, a basic prefetch window is generated based on drag direction parameters, terminal buffer level parameters, available bandwidth parameters, and source station query margin per second parameters. The basic prefetch window refers to the size of the prefetch window calculated comprehensively based on multiple system parameters. For example, the basic prefetch window can be obtained by weighted summing of the drag direction parameters, terminal buffer level parameters, available bandwidth parameters, and source station query margin per second parameters. In other words, the basic prefetch window can be understood as an "ideal prefetch size" estimated by the system based on factors such as drag direction, buffer level, available bandwidth, and source station margin. That is, the more suitable the current situation for prefetching, the larger W_base; the less suitable the current situation for prefetching, the smaller W_base.

[0130] Optionally, the CDN edge node receives a byte range request sent by the client and parses out the target byte range [start_req, end_req]. The CDN edge node processes the request and returns the data for the target byte range. The CDN edge node obtains the QPS margin parameter and origin amplification ratio of the origin server. The CDN edge node determines whether the normal prefetch conditions are met: the origin amplification ratio is less than or equal to the preset maximum amplification threshold, and the origin server QPS margin parameter is greater than or equal to the preset minimum margin threshold. If the normal prefetch conditions are met, the CDN edge node obtains the drag direction parameter (obtained from the client request or player report), the terminal buffer level parameter (obtained from the client request or player report), and the available bandwidth parameter (obtained from the client request or player report, or estimated based on historical request latency). The CDN edge node normalizes these parameters to obtain normalized parameter values. The CDN edge node sets a weight for each normalized parameter and calculates the base prefetch window in a weighted manner: W_base = λD D' + λB B' + λN N' + λQ Q', where λD, λB, λN, and λQ are the weights of the drag direction parameter, terminal buffer level parameter, available bandwidth parameter, and origin server query capacity per second parameter, respectively, and λD + λB + λN + λQ = 1. D', B', N', and Q' are the normalized parameter values ​​of the drag direction parameter, terminal buffer level parameter, available bandwidth parameter, and origin server query capacity per second parameter. The CDN edge node determines the base prefetch window as the target prefetch window. Starting from the end offset end_req of the target byte range, the CDN edge node determines the set of prefetch fragments covered by the target prefetch window. The CDN edge node reads the data from the prefetch fragment set and caches it in a designated cache for use by subsequent requests.

[0131] This embodiment calculates the prefetch window based on multiple system parameters, making the prefetch strategy more reasonable. It solves the problem of unsatisfactory prefetching results caused by a single prefetch strategy in related technologies, and improves the efficiency and accuracy of prefetching.

[0132] In one exemplary embodiment, the related technology has the problem that the prefetch window size may be unreasonable or mismatched with the granularity of the return-to-source process, resulting in low prefetch efficiency.

[0133] To address the aforementioned issues, this embodiment performs amplitude limiting and alignment processing on the basic prefetch window to ensure the rationality of the prefetch window and its matching with the granularity of the source return.

[0134] In some embodiments, the above method further includes: performing a limiting process on the basic prefetch window to obtain a limiting window; the limiting window is between a preset minimum prefetch window and a preset maximum prefetch window; aligning the limiting window to the source fragment granularity parameter and rounding it up to obtain the actual prefetch window; and determining the actual prefetch window as the target prefetch window.

[0135] Scaling refers to the process of limiting the basic prefetch window to between a preset minimum prefetch window and a preset maximum prefetch window. Scaling the basic prefetch window results in a clipped window. The clipped window refers to the size of the prefetch window after scaling.

[0136] For example, in response to the base prefetch window being between the preset minimum prefetch window and the preset maximum prefetch window, the base prefetch window is determined as the clamping window; in response to the base prefetch window being smaller than the preset minimum prefetch window, the preset minimum prefetch window is determined as the clamping window; in response to the base prefetch window being larger than the preset maximum prefetch window, the preset maximum prefetch window is determined as the clamping window. The specific steps are: if the base prefetch window W_base is smaller than the preset minimum prefetch window Wmin, then Wmin is taken as the clamping window; if the base prefetch window W_base is larger than the preset maximum prefetch window Wmax, then Wmax is taken as the clamping window; otherwise, the base prefetch window W_base is directly taken as the clamping window, i.e., W_tmp = clamp(Wmin, Wmax, W_base). The purpose of clamping is to prevent the prefetch window from being too small, resulting in an insignificant prefetching effect, while also avoiding the prefetch window being too large, leading to excessive load on the source station and wasted resources.

[0137] The preset minimum prefetch window refers to the minimum allowed value of the prefetch window, preventing the prefetch window from being too small. The preset maximum prefetch window refers to the maximum allowed value of the prefetch window, preventing the prefetch window from being too large.

[0138] The origin sharding granularity parameter (C) refers to the smallest granularity used when the origin server or object storage performs byte reads. In this embodiment, the clipping window is aligned to the origin sharding granularity parameter and rounded up to obtain the actual prefetch window. Aligning the clipping window to the origin sharding granularity parameter is done to adapt to the read capabilities of the origin server or object storage, avoiding excessively fragmented origin retrievals and improving origin retrieval efficiency. Rounding up instead of rounding down ensures that the prefetch window can cover the complete requirements of the target range, avoiding insufficient prefetched data due to rounding, and reducing the number of subsequent origin retrieval requests. The actual prefetch window refers to the size of the prefetch window after clipping and alignment processing.

[0139] In this embodiment, the actual prefetch window W is not directly equal to the base prefetch window W_base. Instead, the base prefetch window W_base is first restricted to between a preset minimum prefetch window Wmin and a preset maximum prefetch window Wmax, and then aligned to the source fragment granularity C to obtain the actual prefetch window. Simply put, the base prefetch window W_base is the "estimated amount to prefetch," and the actual prefetch window W is the "corrected amount to prefetch." The actual prefetch window W is not directly equal to the base prefetch window W_base, but is obtained by further "limiting" and "granular alignment" based on the base prefetch window W_base.

[0140] In this embodiment, the actual prefetch window W can be represented as: W = align_up(clamp(Wmin, Wmax, W_base), C), which can be understood in three steps: First, obtain the basic prefetch window W_base. Second, perform window clamping (clamp(Wmin, Wmax, W_base), meaning to limit the basic prefetch window W_base to an allowable range: if the basic prefetch window W_base < the preset minimum prefetch window Wmin, then take Wmin; if the basic prefetch window W_base > the preset maximum prefetch window Wmax, then take Wmax; otherwise, take W_base; that is: W_tmp = clamp(Wmin, Wmax, W_base), the purpose of which is to prevent the prefetch window from being too small or too large. Third, align upwards according to the source fragment granularity C (align_up(..., C), that is, adjust W_tmp to a size that meets the source fragment granularity requirements.

[0141] For example, if C = 1MB and W_tmp = 1.3MB, then after upward alignment: W = 2MB. The purpose of this is to adapt the prefetch window to the smallest read granularity of the origin server or object storage, avoiding excessively fragmented backhauls to the origin.

[0142] Optionally, the CDN edge node receives a byte range request sent by the client and parses out the target byte range [start_req, end_req]. The CDN edge node processes the request and returns the data for the target byte range. The CDN edge node obtains the QPS margin parameter and origin amplification ratio of the origin server. The CDN edge node determines whether the normal prefetch conditions are met: the origin amplification ratio is less than or equal to the preset maximum amplification threshold, and the origin server QPS margin parameter is greater than or equal to the preset minimum margin threshold. If the normal prefetch conditions are met, the CDN edge node generates a basic prefetch window W_base based on the drag direction parameter, terminal buffer level parameter, available bandwidth parameter, and origin server QPS margin parameter. The CDN edge node performs clamping processing on the basic prefetch window to obtain the clamped window W_tmp: W_tmp = clamp(Wmin, Wmax, W_base), where Wmin is the preset minimum prefetch window and Wmax is the preset maximum prefetch window. The CDN edge node aligns the clipping window to the origin shard granularity parameter C and rounds it up to obtain the actual prefetch window W: W = align_up(W_tmp, C). The CDN edge node then determines the actual prefetch window W as the target prefetch window. Starting from the end offset end_req of the target byte range, the CDN edge node determines the set of prefetch shards covered by the target prefetch window. The CDN edge node reads the data from the set of prefetch shards and caches it in a designated cache for use by subsequent requests.

[0143] This embodiment performs amplitude limiting and alignment processing on the basic prefetch window to ensure the rationality of the prefetch window and its matching with the granularity of the source return. This solves the problem of low prefetch efficiency caused by unreasonable prefetch window size or mismatch with the granularity of the source return in related technologies, and improves the efficiency and accuracy of prefetching.

[0144] In one exemplary embodiment, there is a problem in the related technology where the prefetching strategy does not take into account the popularity of the video, resulting in unsatisfactory prefetching results for popular videos.

[0145] To address the aforementioned issues, this embodiment modifies the prefetching strategy based on the heat parameters, making the prefetching strategy more flexible and adaptable to the needs of videos with varying heat levels.

[0146] In some embodiments, the method further includes: correcting the actual prefetch window according to the heat parameter to obtain a corrected actual prefetch window, and determining the modified actual prefetch window as the target prefetch window.

[0147] Among them, the popularity parameter refers to the popularity of a video, which is usually calculated by the popularity service module based on indicators such as user visits, play counts, and click-through rates.

[0148] The corrected actual prefetch window refers to the size of the actual prefetch window after adjustment based on the heat parameter. The specific steps are as follows: the heat parameter H is only an optional auxiliary input, and the actual prefetch window is adjusted to a limited extent using a correction factor κ(H). First, the actual prefetch window W is calculated, and then, referring to the heat parameter H, it is multiplied by a small-range correction coefficient κ(H) to obtain the corrected actual prefetch window W', i.e., W' = W × κ(H). Here, κ(H) is not arbitrarily increased, but only adjusted to a limited extent, for example, controlled within the range of 0.8 to 1.2: when the heat is high, κ(H) can be slightly greater than 1, appropriately increasing the prefetch window; when the heat is low, κ(H) can be slightly less than 1, appropriately decreasing the prefetch window; however, the adjustment range will not be too large to avoid the heat factor dominating the entire prefetch decision.

[0149] Optionally, the CDN edge node receives a byte range request sent by the client and parses out the target byte range [start_req, end_req]. The CDN edge node processes the request and returns the data for the target byte range. The CDN edge node obtains the QPS margin parameter and origin amplification ratio of the origin server. The CDN edge node determines whether the normal prefetch conditions are met: the origin amplification ratio is less than or equal to the preset maximum amplification threshold, and the origin server QPS margin parameter is greater than or equal to the preset minimum margin threshold. If the normal prefetch conditions are met, the CDN edge node generates a basic prefetch window based on the drag direction parameter, terminal buffer level parameter, available bandwidth parameter, and origin server QPS margin parameter. The CDN edge node performs a limiting process on the basic prefetch window to obtain a limited window. The CDN edge node aligns the limited window to the origin fragment granularity parameter and rounds it up to obtain the actual prefetch window W. The CDN edge node obtains the popularity parameter H of the target video and retrieves its popularity level from the popularity service module. Based on the popularity parameter H, the CDN edge node calculates a correction factor κ(H). For example, κ(H) is slightly greater than 1 when the popularity is high, and slightly less than 1 when the popularity is low, controlling the correction factor within the range of 0.8 to 1.2. The CDN edge node corrects the actual prefetch window based on the correction factor, obtaining the corrected actual prefetch window W' = W × κ(H). The CDN edge node determines the corrected actual prefetch window W' as the target prefetch window. Starting from the end offset end_req of the target byte range, the CDN edge node determines the set of prefetch segments covered by the target prefetch window. The CDN edge node reads the data of the prefetch segment set and caches it in a designated cache for use by subsequent requests.

[0150] Figure 7 This application provides a schematic diagram of constrained prefetch control and source retrieval granularity alignment, as shown in the embodiments. Figure 7As shown, the prefetch control module preferably first normalizes the drag direction parameter D, terminal buffer level parameter B, available bandwidth parameter N, and source station QPS margin parameter Q, and ensures that the corresponding weights λD, λB, λN, and λQ satisfy λD+λB+λN+λQ=1; based on this, the basic prefetch window W_base = λD is calculated. D' + λB B' + λN N' + λQ Q' is used to calculate the actual prefetch window W = align_up(clamp(Wmin, Wmax, W_base), C). The heat parameter H is only used as an optional auxiliary input, and W is preferably modified to a limited extent by the correction factor κ(H)∈[0.8, 1.2]. The prefetch module also calculates the back-to-source amplification ratio rho = fetched_bytes / delivered_bytes. When rho is greater than the threshold rho_max or Q is less than the threshold Q_min, the hard constraints of Q and rho take precedence over H, forcing W to shrink to Wmin and reducing unnecessary prefetch threads. After rho and Q are restored to a safe range, the window is gradually expanded according to the ramp strategy.

[0151] As can be seen from the above embodiments, this embodiment is not a simple fragmentation and splicing, but rather the three elements of "indexing, verification, and prefetching" work together around the same virtual byte range: the double-layer index is used for precise positioning, the consistency token is used to block mixed version output, and the constrained prefetching is used to improve latency within the available bandwidth and origin server capabilities. This application embodiment establishes a unified virtual byte address space (i.e., virtual transport stream) through fragment-level indexing and GOP-level indexing without pre-generating a complete TS physical file. Multiple video segments are mapped to a unified virtual byte address space, and interval consistency tokens are generated based on index version, ETag, checksum, or hash chain. In case of consistency anomalies, historical stable version index rollback and fragment-level pass-through degradation are introduced. Constrained prefetching is implemented based on source fragment granularity, source amplification ratio, and QPS margin. Heat is only used as an optional auxiliary input. Combining interval consistency verification and constrained prefetching control, a virtual transport stream with continuous access by HTTP Range is provided for terminals that do not support native HLS (i.e., non-HLS terminals). At the same time, it solves the problems of cross-fragment positioning accuracy, version consistency, and high-concurrency prefetching out of control. It achieves accurate cross-fragment byte-level mapping, collaborative processing of keyframe and TS packet boundaries, multi-node version consistency guarantee, and constrained prefetching control based on source granularity and amplification ratio feedback without generating a complete TS physical file.

[0152] This embodiment modifies the actual prefetch window based on the popularity parameter, making the prefetching strategy more flexible and adaptable to the needs of videos with different popularity levels. It solves the problem of unsatisfactory prefetching results for popular videos caused by the prefetching strategy not considering the video popularity factor in related technologies, and improves the efficiency and accuracy of prefetching. Compared with ordinary hot spot prefetching schemes, this embodiment incorporates the source segmentation granularity, source amplification ratio, and source station QPS margin parameters into the same control closed loop, where the popularity parameter is only used as an optional auxiliary factor, thereby ensuring that the technical solution is still centered on network and system control parameters.

[0153] In an exemplary embodiment, during the prefetching process, if the target prefetch window is not aligned with the source shard granularity parameter, redundant bytes and frequent misaligned requests will occur during source server reads, leading to an increase in the source amplification ratio and a surge in QPS peak. Therefore, in order to solve the above-mentioned problems of low source efficiency and source server overload, in this embodiment, the start and end offsets of the target prefetch window are aligned with the source shard granularity parameter to obtain the actual source interval that adapts to the physical constraints of the storage system, thereby improving the atomicity, resource utilization and system throughput of source server reads.

[0154] In some embodiments, the above method further includes: granularly aligning the start and end offsets of the target prefetch window according to the source fragment granularity parameter to obtain a new target prefetch window, and performing reading of the prefetch fragment set covered by the target prefetch window in the virtual transport stream starting from the end offset of the target byte interval based on the new target prefetch window.

[0155] In this context, the origin-fetch granularity parameter is the smallest unit for byte read operations performed by the object storage system, and its value is determined by the underlying storage architecture (e.g., 1MB, 2MB). The target prefetch window is a logical byte range dynamically expanded by the server based on playback behavior prediction, and its start and end offsets are independent of the client's request range. To ensure that the origin-fetch behavior adapts to the minimum read granularity constraints of the storage system and avoids invalid byte loading and concurrency jitter, in this embodiment, after obtaining the target prefetch window, the start and end offsets of the target prefetch window are aligned according to the origin-fetch granularity parameter to obtain a new target prefetch window.

[0156] The new target prefetch window refers to the actual source return interval after granular alignment, adapted to the smallest read granularity of the source station.

[0157] It should be noted that the keyframe / TS packet boundary processing in the above embodiments is a matter of bitstream diagnosability alignment. Taking a terminal initiating a Range: bytes=1000000-3000000 request as an example, the server first maps this virtual byte range into multiple read ranges within each TS segment using the VirtualByteMap table, for example, mapping it to ts1:[1000000,2097151] and ts2:[0,902848]. At this time, this mapping only indicates the byte coverage range of the byte range request in each TS segment, and has not yet determined whether the starting offset of 1000000 is located at the keyframe boundary or TS packet boundary. If the starting offset falls in the middle of a GOP or a TS packet, the server can further adjust the origin return starting point forward to the offset corresponding to the nearest keyframe based on the keyframe-level index GOPIndex, and further align it to the nearest TS packet boundary, thereby ensuring that the returned bitstream starts from a diagnosable position and avoiding screen tearing, first frame failure, or decoding abnormalities due to improper starting point entry position. In this embodiment, the origin-fetch prefetch interval alignment belongs to the origin-fetch granularity alignment at the storage / network layer. The object of this type of alignment is not the keyframe or TS packet boundary, but rather the smallest read granularity C of the origin server or object storage. For example, when the origin fragment granularity C = 1MB, even after the aforementioned boundary processing, which has yielded a semantically reasonable origin-fetch interval, the server can still extend the origin-fetch interval to the entire boundary at granularity C when actually initiating a read from the origin server. For example, the request-related interval [1000000, 3000000] can be extended and aligned to a more suitable entire interval [0, 3145727] for origin server reading, thereby reducing excessively fragmented small-block origin-fetches, reducing origin-fetch amplification jitter, and matching the prefetch window with the origin server's read granularity. In summary, the former solves the problem of 'whether it can be correctly decoded and played,' while the latter solves the problem of 'how to read from the origin more efficiently and stably.' The two can be executed in the following order: First, perform virtual byte mapping to split the request into internal intervals of each fragment; second, perform keyframe / TS packet boundary processing to ensure that the starting point is decodeable; third, perform back-to-source fragment granularity alignment so that the source server can read in whole blocks; finally, the server outputs only the valid bytes corresponding to the original request interval to the terminal, while the extra read portion generated by the alignment expansion can be used for internal trimming output or subsequent prefetch caching.

[0158] Optionally, for the original start offset `start` of the target prefetch window, the floor function is used to calculate its quotient with the back-to-source fragment granularity parameter `C`, and then multiplied by `C` to obtain the aligned start offset `start_src`. For the original end offset `end` of the target prefetch window, it is first incremented by 1, then the ceil function is used to calculate its quotient with `C`, multiplied by `C`, and then subtracted by 1 to obtain the aligned end offset `end_src`.

[0159] In this embodiment, the starting offset of the new target prefetch window can be expressed as: start_src = floor(start / C) C, the termination offset of the new target prefetch window can be expressed as end_src=ceil((end+1) / C) C-1. Here, start and end are the original start and end offsets of the target prefetch window calculated by the server, and C is the origin retrieval granularity parameter. This alignment operation ensures that all origin retrieval requests are aligned in units of C, thereby maximizing storage read efficiency without sacrificing prefetch performance.

[0160] For example, if start = 1,500,000 bytes and C = 1,048,576 bytes (1MB), then start / C ≈ 1.43, rounded down to 1, therefore start_src = 1. 1048576 = 1048576 bytes. If end = 2500000 bytes and C = 1048576 bytes, then end + 1 = 2500001, (end + 1) / C ≈ 2.38, rounded up to 3, therefore end_src = 3. 1048576-1=3145727 bytes.

[0161] The process involves rounding the starting offset down to ensure that the aligned starting offset is no greater than the original starting offset, avoiding the reading of unnecessary preceding data. It also ensures that the starting point of the prefetch window is aligned with the smallest read granularity of the storage system, guaranteeing that each source retrieval read begins at the physical block boundary of the storage system, improving read efficiency. The original ending offset is then incremented by 1, rounded up, and subtracted by 1 to ensure that the aligned ending offset is no less than the original ending offset, preventing the omission of prefetched data. This calculation method ensures that the ending point of the prefetch window is aligned with the physical block boundary of the storage system, guaranteeing the atomicity of the read operation.

[0162] In some embodiments, such as Figure 7 As shown, when the terminal initiates a Range: bytes=1000000-3000000 request, the server first determines that the request spans two fragments, ts1 and ts2, based on the VirtualByteMap. The read range of ts1 is [1000000, 2097151], and the read range of ts2 is [0, 902848]. When the request does not carry a Range header, it can be directly regarded as a full range request of bytes=0-virtual_end.

[0163] When the terminal policy requires a keyframe-friendly origin pull, the server extends the origin pull starting point forward to the offset corresponding to the nearest keyframe based on GOPIndex, and further aligns it downward to the TS packet boundary. For upstream origin pulls, the extended range can be read, while for the terminal, the output can still be clipped according to the original request range, so as to take into account both decodeability and HTTPRange semantics.

[0164] After returning the target byte range, before performing prefetching, if the source fragment granularity C is 1MB, then start_src=floor(start / C) can be used. C, end_src=ceil((end+1) / C) C-1 aligns the source station read range to the integer boundary.

[0165] This embodiment aligns the start and end offsets of the target prefetch window at the granular level, ensuring that all back-to-origin requests are aligned at the back-to-origin fragment granularity. This allows the storage system to operate in the smallest possible read unit, reducing the frequency of unaligned requests and preventing redundant bytes and frequent unaligned requests from the source server. Consequently, it lowers the back-to-origin amplification ratio and peak OPS, improves the atomicity, resource utilization, and system throughput of source server reads, and solves the problems of low back-to-origin efficiency and source server overload.

[0166] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0167] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory (ROM) / random access memory (RAM), magnetic disk, optical disk), and includes several instructions to cause a client device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0168] According to another aspect of the embodiments of this application, a video processing apparatus is also provided, which can be used to implement the video transmission method provided in the above embodiments, and will not be repeated hereafter. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0169] Figure 8 This is a structural block diagram of an optional video processing apparatus according to an embodiment of this application, such as... Figure 8 As shown, the video processing apparatus includes:

[0170] The receiving module 802 is used to receive a byte range request sent by the client; the byte range request is used to request the target byte range of the target video in the virtual transport stream; the virtual transport stream is a continuous byte address space formed by mapping multiple video segments of the target video in the playback order.

[0171] Alignment module 804 is used to map the starting offset of the target byte range forward to the virtual offset of the most recent keyframe whose virtual offset is less than or equal to the starting offset, so as to obtain the starting virtual offset;

[0172] The read module 806 is used to return the byte range from the starting virtual offset to the ending offset of the target byte range in the virtual transport stream to the client.

[0173] It should be noted that the receiving module 802 in this embodiment can be used to perform the above step S202, the alignment module 804 in this embodiment can be used to perform the above step S204, and the reading module 806 in this embodiment can be used to perform the above step S206.

[0174] In one exemplary embodiment, each video segment in the plurality of video segments includes a plurality of transport stream packets; the alignment module 804 is further configured to align the starting virtual offset to the boundary of the transport stream packet whose most recent virtual offset is less than or equal to the starting virtual offset, to obtain the starting packet alignment offset; and return the byte range in the virtual transport stream between the starting packet alignment offset and the termination offset of the target byte range to the client.

[0175] In an exemplary embodiment, the target video corresponds to a segment-level index and a keyframe-level index; the alignment module 804 is further configured to determine the target video segment where the starting offset of the target byte interval is located based on the start and end byte offsets of each video segment in the multiple video segments recorded in the segment-level index; and to align the starting offset of the target byte interval forward to the virtual byte offset of the most recent keyframe in the target video segment whose virtual offset is less than or equal to the starting offset based on the virtual byte offset of each keyframe in each video segment recorded in the keyframe-level index, thereby obtaining the starting virtual offset.

[0176] In an exemplary embodiment, the alignment module 804 is further configured to align the starting virtual offset forward to the boundary of the most recent virtual offset in the target video segment that is less than or equal to the starting virtual offset, based on the boundary of each transport stream packet within each video segment recorded in the key frame level index, to obtain the starting packet alignment offset.

[0177] In an exemplary embodiment, the target video includes a segment index file; the segment index file is used to record metadata of multiple video segments; the target video corresponds to a segment-level index; before mapping the starting offset of the target byte range forward to the virtual offset of the most recent keyframe whose virtual offset is less than or equal to the starting offset to obtain the starting virtual offset, the alignment module 804 is further configured to generate a first token based on the target byte range, the index version number of the segment index file, and the metadata of the target segment sequence; wherein the target segment sequence refers to at least one video segment among the multiple video segments that overlaps with the target byte range; in response to the first token being consistent with the version of the segment-level index, the starting offset of the target byte range is mapped forward to the virtual offset of the most recent keyframe whose virtual offset is less than or equal to the starting offset to obtain the starting virtual offset; in response to the first token being inconsistent with the version of the segment-level index, a degradation strategy is executed.

[0178] In one exemplary embodiment, the target video includes a fragment index file; the fragment index file is used to record metadata of multiple video segments; the target video corresponds to a fragment-level index; before returning the byte range in the virtual transport stream from the starting virtual offset to the ending offset of the target byte range to the client, the alignment module 804 is further configured to generate a second token based on the target byte range, the index version number of the fragment index file, and the metadata of the target fragment sequence; wherein the target fragment sequence refers to at least one video segment among the multiple video segments that overlaps with the target byte range; in response to the second token being consistent with the version of the fragment-level index, the byte range in the virtual transport stream from the starting virtual offset to the ending offset of the target byte range is returned to the client; in response to the second token being inconsistent with the version of the fragment-level index, a degradation strategy is executed.

[0179] In an exemplary embodiment, the alignment module 804 is further configured to obtain the source station's query margin per second parameter and determine the source-to-source upscaling ratio of the source station storing the target video; the source-to-source upscaling ratio characterizes the source station's resource preloading capability;

[0180] In response to the source amplification ratio being greater than the preset maximum amplification threshold, or the source station query margin parameter per second being less than the preset minimum margin threshold, the preset minimum prefetch window is determined as the target prefetch window.

[0181] Starting from the end offset of the target byte range, read the set of prefetch fragments covered by the target prefetch window in the virtual transport stream, and cache the set of prefetch fragments in the specified cache.

[0182] In an exemplary embodiment, the alignment module 804 is further configured to, in response to the source amplification ratio being less than or equal to a preset maximum amplification threshold and the source station query margin parameter per second being greater than or equal to a preset minimum margin threshold, generate a basic prefetch window based on the drag direction parameter, terminal buffer level parameter, available bandwidth parameter and source station query margin parameter per second, and determine the basic prefetch window as the target prefetch window.

[0183] In an exemplary embodiment, the alignment module 804 is further configured to perform a limiting process on the basic prefetch window to obtain a limiting window; the limiting window is located between a preset minimum prefetch window and a preset maximum prefetch window;

[0184] Align the clipping window to the source fragment granularity parameter and round it up to obtain the actual prefetch window. Then, determine the actual prefetch window as the target prefetch window.

[0185] In an exemplary embodiment, the alignment module 804 is further configured to correct the actual prefetch window according to the heat parameter to obtain the corrected actual prefetch window, and determine the modified actual prefetch window as the target prefetch window.

[0186] In an exemplary embodiment, the alignment module 804 is further configured to perform granular alignment of the start and end offsets of the target prefetch window according to the back-to-source fragment granularity parameters to obtain a new target prefetch window, and to perform reading of the prefetch fragment set covered by the target prefetch window in the virtual transport stream starting from the end offset of the target byte range based on the new target prefetch window.

[0187] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0188] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein the program executes the steps in any of the above method embodiments when it is run.

[0189] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, ROMs, RAMs, portable hard drives, magnetic disks, or optical disks.

[0190] According to another aspect of the embodiments of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor is configured to perform the steps of any of the method embodiments described above via the computer program. In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0191] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0192] According to another aspect of the embodiments of this application, a computer program product is also provided, comprising a computer program / instructions containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via a communication section 909, and / or installed from a removable medium 911. When the computer program is executed by a central processing unit 901, it performs various functions provided in the embodiments of this application. The sequence numbers of the embodiments of this application above are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0193] Figure 9 A schematic block diagram of a computer system architecture for implementing embodiments of the present application is shown. Figure 9 As shown, the computer system 900 includes a Central Processing Unit (CPU) 901, which performs various appropriate actions and processes based on programs stored in ROM 902 or loaded into RAM 903 from storage section 908. Random Access Memory 903 also stores various programs and data required for system operation. The CPU 901, ROM 902, and RAM 903 are interconnected via bus 904. Input / Output (I / O) interface 905 is also connected to bus 904.

[0194] The following components are connected to I / O interface 905: an input section 906 including a keyboard, mouse, etc.; an output section 907 including a cathode ray tube (CRT), liquid crystal display (LCD), and speakers, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card, such as a local area network card or modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to I / O interface 905 as needed. Removable media 911, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 910 as needed so that computer programs read from them can be installed into storage section 908 as needed.

[0195] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 909, and / or installed from removable medium 911. When the computer program is executed by central processing unit 901, it performs various functions defined in the system of this application.

[0196] It should be noted that, Figure 9 The computer system 900 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

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

[0198] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A method of video transmission, characterized by, include: Receive a byte range request sent by the client; the byte range request is used to request the target byte range of the target video in the virtual transport stream; The virtual transport stream is a contiguous byte address space formed by virtually mapping multiple video segments of the target video in playback order. The starting offset of the target byte range is mapped forward to the virtual offset of the most recent keyframe whose virtual offset is less than or equal to the starting offset, to obtain the starting virtual offset; The byte range in the virtual transport stream between the starting virtual offset and the ending offset of the target byte range is returned to the client.

2. The method of claim 1, wherein, Each of the plurality of video segments includes a plurality of transport stream packets; the method further includes: The starting virtual offset is aligned to the boundary of the transport stream packet whose virtual offset is less than or equal to the starting virtual offset to obtain the starting packet alignment offset; The byte range in the virtual transport stream between the starting packet alignment offset and the ending offset of the target byte range is returned to the client.

3. The method of claim 2, wherein, The target video corresponds to a segment-level index and a keyframe-level index; the step of mapping the starting offset of the target byte range forward to the virtual offset of the most recent keyframe whose virtual offset is less than or equal to the starting offset to obtain the starting virtual offset includes: Based on the start and end byte offsets of each of the multiple video segments recorded in the fragment-level index, the target video segment containing the start offset of the target byte interval is determined. Based on the virtual byte offset of each keyframe in each video segment recorded in the keyframe-level index, the starting offset of the target byte interval is aligned forward to the virtual byte offset of the most recent keyframe in the target video segment whose virtual offset is less than or equal to the starting offset, thus obtaining the starting virtual offset.

4. The method of claim 3, wherein, The step of aligning the starting virtual offset to the boundary of the most recent transport stream packet whose virtual offset is less than or equal to the starting virtual offset, to obtain the starting packet alignment offset, includes: Based on the boundary of each transport stream packet within each video segment recorded in the keyframe-level index, the starting virtual offset is aligned forward to the boundary of the most recent transport stream packet in the target video segment whose virtual offset is less than or equal to the starting virtual offset, thus obtaining the starting packet alignment offset.

5. The method of claim 1, wherein, The target video includes a segment index file; the segment index file is used to record metadata of the multiple video segments; the target video corresponds to a segment-level index; before mapping the starting offset of the target byte range forward to the virtual offset of the most recent keyframe whose virtual offset is less than or equal to the starting offset to obtain the starting virtual offset, the method further includes: A first token is generated based on the target byte range, the index version number of the segment index file, and the metadata of the target segment sequence; wherein the target segment sequence refers to at least one video segment among the plurality of video segments that overlaps with the target byte range; In response to the first token being consistent with the version of the fragment-level index, the process of forward mapping the starting offset of the target byte range to the virtual offset of the most recent keyframe whose virtual offset is less than or equal to the starting offset is performed to obtain the starting virtual offset; If the version of the first token is inconsistent with the version of the shard-level index, a degradation strategy is executed.

6. The method of claim 1, wherein, The target video includes a segment index file; the segment index file is used to record metadata of the plurality of video segments; the target video corresponds to a segment-level index; before returning the byte range in the virtual transport stream between the starting virtual offset and the ending offset of the target byte range to the client, the method further includes: A second token is generated based on the target byte range, the index version number of the segment index file, and the metadata of the target segment sequence; wherein the target segment sequence refers to at least one video segment among the plurality of video segments that overlaps with the target byte range; In response to the second token being consistent with the version of the fragment-level index, the process of moving the byte range in the virtual transport stream from the starting virtual offset to the ending offset of the target byte range is executed and returned to the client; If the second token is inconsistent with the version of the shard-level index, a degradation strategy is executed.

7. The method of claim 1, wherein, The method further includes: Obtain the query margin parameter per second of the source station and determine the source-to-source upscaling ratio of the source station storing the target video; the source-to-source upscaling ratio characterizes the resource preloading capability of the source station; In response to the source amplification ratio being greater than a preset maximum amplification threshold, or the source station query margin parameter per second being less than a preset minimum margin threshold, the preset minimum prefetch window is determined as the target prefetch window. Starting from the termination offset of the target byte range, read the set of prefetch fragments covered by the target prefetch window in the virtual transport stream, and cache the set of prefetch fragments in the specified cache.

8. The method of claim 7, wherein, The method further includes: In response to the source amplification ratio being less than or equal to the preset maximum amplification threshold, and the source station query margin parameter per second being greater than or equal to the preset minimum margin threshold, a basic prefetch window is generated based on the drag direction parameter, terminal buffer level parameter, available bandwidth parameter, and source station query margin parameter per second, and the basic prefetch window is determined as the target prefetch window.

9. The method according to claim 8, characterized in that, The method further includes: The basic prefetch window is subjected to amplitude limiting processing to obtain a amplitude limiting window; the amplitude limiting window is between a preset minimum prefetch window and a preset maximum prefetch window; Align the limiting window to the source fragment granularity parameter and round it up to obtain the actual prefetch window. Then, determine the actual prefetch window as the target prefetch window.

10. The method according to claim 9, characterized in that, The method further includes: The actual prefetch window is corrected based on the heat parameters to obtain the corrected actual prefetch window, and the modified actual prefetch window is determined as the target prefetch window.

11. The method according to any one of claims 7 to 10, characterized in that, The method further includes: The start and end offsets of the target prefetch window are aligned according to the granularity parameters of the source fragmentation to obtain a new target prefetch window. Based on the new target prefetch window, the process of reading the prefetch fragment set covered by the target prefetch window in the virtual transport stream, starting from the end offset of the target byte range, is performed.

12. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 11.

Images