Intelligent distribution method and device based on CDN node dynamic video transcoding

Abstract

The invention relates to the technical field of video transcoding, in particular to an intelligent distribution method and device based on CDN node dynamic video transcoding. Comprising the following steps that: terminal equipment reports context sensing information to a server, an edge node of a content distribution network CDN receives a video content request and the context sensing information, generates a transcoding strategy identifier, dynamically determines a video output parameter combination suitable for the video content request, and transmits the video output parameter combination to the server; and when the edge node queries that no transcoded video data corresponding to the transcoding strategy identifier exists in a local cache, a transcoding component is called to transcode the original video data stream in real time according to the video output parameter combination, and adaptive video stream data is generated. According to the invention, the transcoding decision and execution unit sinks to the edge node within one hop from the user, the image quality change is accurately matched with the network capability, smooth and smooth quality transition is realized, buffer pause and visual step brought by version jump are eliminated, and real seamless viewing is realized.

Description

Intelligent Distribution Method and Apparatus Based on CDN Node Dynamic Video Transcoding Technical Field

[0001] This invention relates to the field of video transcoding technology, and more specifically, to an intelligent distribution method and apparatus based on dynamic video transcoding of CDN nodes. Background Technology

[0002] In current online video services, service providers face a common and challenging problem: users use a wide variety of devices, ranging from small-screen smartphones to large-screen smart TVs, with vastly different display and processing capabilities; simultaneously, users' network environments are constantly fluctuating, such as switching from stable home Wi-Fi to mobile cellular data networks. To cope with this diversity, a common approach is to pre-prepare multiple versions of the video for distribution. The operational process of this model is as follows: The video platform first processes each original high-definition video master on a high-performance server located in a central data center, converting it in batches into multiple versions with different resolutions. Copies of the video are prepared in varying resolutions and file sizes. For example, an original ultra-high-definition video might be converted into a 4kW ultra-high-definition version, a 2,160-pixel full high-definition version, a 1,280-pixel high-definition version, and a 720-pixel standard-definition version. These pre-converted video copies are then transmitted and stored in content delivery network (CDN) cache nodes across the country. When a user clicks to play, the video playback software on their device automatically selects a suitable version from these fixed options based on the current network speed. However, because the number of pre-prepared versions is limited, it's impossible to exhaust all combinations of devices and network conditions, leading to limitations for smaller screens. On slow networks, mobile phones are forced to attempt to load excessively large high-definition files, causing playback stuttering. Conversely, high-performance large-screen TVs, even on high-speed networks, can only obtain lower-resolution versions, failing to fully utilize their display advantages and resulting in blurry images. When a user's network conditions change dynamically, such as moving from a room with poor signal to a location near a wireless router and improving network speed, the player can only switch between a few existing fixed versions. If the new network speed happens to fall between the bandwidth requirements of two preset versions, the user will not get the smoothest experience or the clearest picture quality. The version switching process itself may also cause temporary buffering. The platform faces challenges such as abrupt changes in buffering or image quality, high infrastructure costs, and low resource utilization. To cover various potential needs as much as possible, the platform must pre-produce and store five to ten, or even more, different versions of each video content, consuming massive amounts of data storage space. More seriously, all these versions need to be transmitted from the central data center to various edge cache nodes, occupying huge amounts of internal network bandwidth. Therefore, this paper proposes an intelligent distribution method and device based on CDN node dynamic video transcoding, which uses CDN edge nodes to sense terminal capabilities and network status in real time, dynamically completes video transcoding and distribution, and achieves multi-terminal adaptation of a single video source. Summary of the Invention

[0003] The purpose of this invention is to provide an intelligent distribution method and apparatus based on dynamic video transcoding of CDN nodes, so as to solve the problems mentioned in the background art, such as low adaptation accuracy, impaired user experience, high adaptive latency, awkward switching experience, high infrastructure cost, and low resource utilization.

[0004] To address the aforementioned technical problems, one objective of this invention is to provide an intelligent distribution method based on dynamic video transcoding of CDN nodes, comprising the following steps: A terminal device reports context-aware information to a server, including its screen physical resolution, a list of supported video decoding formats, and real-time estimated network bandwidth; an edge node of the Content Delivery Network (CDN) receives a video content request and the context-aware information, generates a transcoding strategy identifier, and dynamically determines a combination of video output parameters suitable for the video content request, wherein the parameter combination includes at least a target resolution, a target bitrate, and a target encoding format; the edge node queries its local cache to check if transcoded video data corresponding to the transcoding strategy identifier exists; if not, the edge node obtains the original video data, calls its internally integrated transcoding component equipped with a hardware acceleration unit, and performs real-time transcoding of the original video data stream according to the video output parameter combination to generate adapted video stream data; the adapted video stream data is sent to the terminal device and cached in the edge node's local storage using the transcoding strategy identifier as an index key.

[0005] Preferably, the reporting of context-aware information adopts a three-layer information acquisition system, including the following steps: In the static capability layer: the actual number of pixels of the display panel is obtained by calling the native graphics interface of the operating system, and the physical resolution of the screen is output; at the same time, all available hardware decoders are enumerated by querying the system media framework, and their supported encoding standards, configuration files and levels are parsed to generate a priority list sorted by decoding efficiency and energy consumption, and a list of supported video decoding formats is output; In the dynamic state layer: the download throughput of historical video segments is passively observed and continuously analyzed to provide continuous, low-overhead baseline estimates, and when the network state is unclear or changes drastically, active detection is performed to send detection packet sequences to edge nodes, and the bottleneck bandwidth is calculated based on packet pair dispersion technology. The passive observation and active detection data are fused through Kalman filter data to output real-time estimated network bandwidth; In the reporting control layer: the complete context is reported during the first playback, and when the bandwidth change rate is detected to exceed a preset threshold, event reporting is immediately triggered. At the same time, a silent period is set to prevent invalid reporting storms caused by instantaneous network jitter.

[0006] Preferably, the dynamic determination of the video output parameter combination suitable for the video content request includes the following steps: comparing the screen physical resolution with the original resolution of the requested video content, and selecting a standard resolution level from a set of standard resolution levels that does not exceed the screen physical resolution and is adapted to the current network conditions as the target resolution; inputting the real-time estimated network bandwidth into a preset bandwidth-bitrate mapping relationship model that includes network buffer margin, and outputting the target bitrate; selecting the format with the highest compression efficiency from the list of supported video decoding formats reported by the terminal device, sorted according to the preset encoding efficiency priority, as the target encoding format.

[0007] Preferably, the establishment of the bandwidth-bitrate mapping model by querying a pre-set model containing network buffer capacity includes the following steps: collecting massive amounts of real user playback session data, including bandwidth time-series data, bitrate switching records, buffering events, and user terminal information; establishing bandwidth stability profiles for different network types, time periods, and regions through data mining; organizing large-scale subjective tests, allowing subjects to rate the quality of the same video content at different bitrates, and establishing a three-dimensional mapping database of "resolution-bitrate-subjective quality"; formulating initial mapping rules based on streaming media transmission theory, dividing the bandwidth into multiple intervals, and using different reservation ratios in each interval; and training a prediction model, using bandwidth, network type, historical stability indicators, video content complexity, etc., as features to predict the optimal bitrate as the target bitrate.

[0008] Preferably, the generation of the transcoding strategy identifier includes the following steps: concatenating the target resolution, target bitrate, and target encoding format into a string according to a predefined format template; applying an encrypted hash function to the serialized string to generate a hash value as the final transcoding strategy identifier; wherein: in the node's local database, establishing a mapping relationship between the transcoding strategy identifier and the combination of video output parameters and context-aware information.

[0009] Preferably, the edge node queries the local cache for the existence of transcoded video data corresponding to the transcoding strategy identifier using a similarity matching algorithm, including the following steps: extracting key parameter information from the transcoding strategy identifier; using a weighted similarity calculation method to assign different weights to different parameters, with the similarity weights for resolution and encoding format being higher than those for bitrate; multiplying the similarity scores of each parameter by their corresponding weights and summing them to obtain a comprehensive similarity score; if the comprehensive similarity score is higher than the similarity threshold, then outputting that the data exists, outputting the matching buffered version, and detecting the difference between the bitrate of the buffered version and the target bitrate, and adjusting the bitrate of the video stream based on the buffered version.

[0010] Preferably, the step of calling its internally integrated transcoding component equipped with a hardware acceleration unit to perform real-time transcoding of the original video data stream according to the video output parameter combination to generate adapted video stream data includes the following steps: establishing an input buffer in the edge node memory to temporarily store the received original video data in sequence, wherein the original video data is the video segment to be transcoded as needed; allocating hardware acceleration resources in parallel at the edge nodes; converting the video output parameter combination into configuration parameters recognizable by the hardware encoder; executing the transcoding pipeline in real time using multiple threads; during the transcoding process, the encoder provides real-time feedback on the actual output bitrate and frame rate indicators, and if a deviation outside the threshold range is detected between the actual output and the target parameter combination, the transcoding controller dynamically fine-tunes the encoding parameters.

[0011] Preferably, the caching in the local storage of the edge node includes the following steps: Establishing a main directory for each video content, named after the transcoding strategy identifier of the video content; creating a subdirectory for each different transcoding version within this main directory, the subdirectory name being the hash value of the corresponding transcoding strategy identifier; storing all video segment files and related metadata files for that version in each subdirectory, recording detailed parameter information for that version; maintaining a version index table in the edge node memory, using the video content identifier as the primary key, with each primary key corresponding to a version linked list; each node in the linked list storing a transcoding strategy identifier and a pointer to the position of that version in local storage; simultaneously, establishing a reverse index from the transcoding strategy identifier to the version node; when a new transcoding version is generated and ready for caching, creating a corresponding node in the memory index, then writing the video segment data into the corresponding subdirectory in local storage; after writing, updating the status of the memory index node to ready; and marking popular versions that are being accessed as active.

[0012] Preferably, the cache cached in the local storage of the edge node further includes a cache eviction policy, comprising the following steps: calculating an eviction score for each cache version, including the last access timestamp, access frequency, version size, and transcoding computation cost; running a background daemon process to scan all cache versions at fixed intervals and calculate the eviction score, comparing the score with a preset eviction threshold, marking versions exceeding the threshold as recyclable, sorting them by eviction score from high to low, and immediately initiating the eviction process when the local storage space utilization exceeds the warning line, performing deletion operations to release space according to the sorting.

[0013] The second objective of this invention is to provide an intelligent distribution device based on dynamic video transcoding of CDN nodes, including any one of the intelligent distribution methods based on dynamic video transcoding of CDN nodes described above, comprising a context-aware information acquisition unit, a transcoding strategy identifier generation unit, a similarity matching unit, a transcoding component, and an index storage unit; the context-aware information acquisition unit is used to report context-aware information, including its screen physical resolution, a list of supported video decoding formats, and real-time estimated network bandwidth, to the server through the terminal device; the transcoding strategy identifier generation unit is used by the edge nodes of the content delivery network (CDN) to receive video content requests and the context-aware information, and generate a transcoding strategy identifier. The transcoding strategy identifier dynamically determines the combination of video output parameters applicable to the video content request; the similarity matching unit is used to enable edge nodes to query whether there is transcoded video data corresponding to the transcoding strategy identifier in their local cache; the transcoding component is used to enable edge nodes to obtain the original video data when it does not exist in the local cache, call its internally integrated transcoding component equipped with a hardware acceleration unit, and transcode the original video data stream in real time according to the combination of video output parameters to generate adapted video stream data; the index storage unit is used to send the adapted video stream data to the terminal device and cache it in the local storage of the edge node with the transcoding strategy identifier as the index key.

[0014] Compared with existing technologies, the beneficial effects of this invention are as follows: This invention, through a closed loop of real-time terminal context awareness and on-demand edge transcoding, can generate theoretically optimal video stream parameter combinations for each specific device at each specific network moment, and generates transcoding strategy identifiers. It maps the infinitely complex terminal context and network state into cacheable and reusable unique instructions, thus logically achieving for the first time a unified approach to personalized customization and large-scale reuse of video streams. This provides a theoretically infinitely near-optimal adaptation capability for a massive number of heterogeneous terminals, fundamentally eliminating the mismatch problem caused by limited pre-installed versions, where high-end devices watch low-definition or high-definition is forced to play in weak network environments. Furthermore, by pushing the transcoding decision-making and execution unit down to an edge node within one hop of the user, new decisions can take effect immediately when the network state changes, and transcoding and switching are completed within the next video segment loading cycle. Since the switching process occurs during the continuous transmission of streaming media, and the image quality change is precisely matched with network capabilities, the user will perceive a smooth and seamless quality transition, completely eliminating the buffering pauses and visual leaps caused by version jumps, achieving truly seamless viewing. Attached Figure Description

[0015] Figure 1 is a flowchart of the first overall process of Example 1; Figure 2 is a flowchart of the second overall process of Example 1; Figure 3 is a flowchart of the transcoding principle of Example 1. Detailed Implementation

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

[0017] Example 1, as shown in Figures 1-3, aims to provide an intelligent distribution method based on dynamic video transcoding of CDN nodes, comprising the following steps: Step 1: The terminal device reports context-aware information to the server, including its screen physical resolution (number of physical pixels), a list of supported video decoding formats (a list of video encoding formats supported by its hardware chip for decompression and playback), and real-time estimated network bandwidth (the specific value of the currently available network bandwidth estimated through real-time detection). Specifically, the triggering conditions for the terminal device to report to the server include: the initialization time of the first video playback request, and when the change in the real-time network bandwidth value exceeds a preset threshold during video playback. The reporting of perceived information adopts a three-layer information acquisition system, including the following steps: In the static capability layer: by calling the operating system's native graphics interface (such as Android's DisplayMetrics, iOS's UIScreen.nativeBounds), the actual number of pixels on the display panel is obtained, and the screen's physical resolution is output to ensure the accuracy of adaptation and avoid errors caused by logical resolution or scaling; at the same time, by querying the system media framework (such as Android's MediaCodecList, iOS's VTDecompressionSession), all available hardware decoders are enumerated, and their supported encoding standards (such as H.264 / AVC, H.264, H.264) are parsed.The system generates a priority list sorted by decoding efficiency and energy consumption based on H.265 / HEVC, AV1, configuration files, and levels. It outputs a list of supported video decoding formats, directly querying the hardware decoder support list instead of relying on a crude device model database. This ensures absolute compatibility in transcoding format selection and avoids power consumption spikes or playback failures caused by software decoding. At the dynamic state layer: passive observation continuously analyzes the download throughput of historical video segments, providing continuous, low-overhead baseline estimates. Active detection is performed when network conditions are unclear or drastically changing, sending probe packet sequences to edge nodes. Bottleneck bandwidth is calculated based on packet pair distribution technology. Passive observation and active detection data are fused using a Kalman filter to output real-time estimated network bandwidth. The continuity of passive observation and the accuracy of active detection overcome the limitations of single methods (such as the lag of passive observation and the overhead and intrusiveness of active detection), resulting in estimates that more closely reflect the actual available network capacity and yield more stable and accurate estimates. At the reporting control layer: the complete context is reported upon initial playback. When a bandwidth change rate exceeds a preset threshold (e.g., 20%), further updates are provided. Event reporting is triggered immediately upon occurrence of a network fluctuation, with a silent period to prevent invalid reporting storms caused by network jitter. Communication only occurs when there are meaningful changes in network status, greatly reducing unnecessary uplink traffic and server processing load, while ensuring that edge nodes can obtain critical status changes immediately. Finally, the collected information is encapsulated through optimized protocols and integrated into the video stream request with minimal overhead: Extended HTTP request header fields (such as X-Device-Capabilities) are prioritized, and structured data (such as resolution, codec lists, bandwidth estimates, round-trip time, and packet loss rate) is encoded into compact key-value pairs or binary protocols (such as TLV encoding) to achieve a balance between high readability and low transmission overhead. To ensure broad applicability, the solution is encapsulated in a unified client SDK. This SDK is natively adapted for different platforms such as Android, iOS, Web, and smart TVs, providing a consistent API interface externally and calling the platform-specific system APIs internally to complete information collection, while uniformly encapsulating the reporting protocol.

[0018] Step 2: The edge nodes of the Content Delivery Network (CDN) receive the video content request and the context-aware information, generate a transcoding strategy identifier, and dynamically determine the video output parameter combination suitable for the video content request. This parameter combination includes at least the target resolution, target bitrate, and target encoding format. Further, the dynamic determination of the video output parameter combination suitable for the video content request includes the following steps: comparing the screen's physical resolution with the original resolution of the requested video content, and selecting a standard resolution level from a set of standard resolution levels that does not exceed the screen's physical resolution and is suitable for the current network conditions as the target resolution. The target resolution is not always the highest output resolution, but rather a standardized resolution level that best suits the device's screen size and does not exceed its physical pixel limit. For example, for a device with a full HD screen, even if the original video... The decision engine may prioritize outputting full HD or HD resolutions to avoid unnecessary computation and bandwidth consumption, based on the real-time estimated network bandwidth input to a preset bandwidth-bitrate mapping model that includes network buffer margins. This model outputs the target bitrate, taking into account the network margins required for stable video stream transmission. When the reported bandwidth is 3.5 million bits per second, the model may output 3 million bits per second as a suggested video bitrate, reserving some bandwidth to cope with network fluctuations. From the list of supported video decoding formats reported by the terminal device, the model prioritizes the formats based on preset encoding efficiency, selecting the format with the highest compression efficiency as the target encoding format. This ensures the best bandwidth savings for the current picture quality. For example, if the device supports both high-efficiency video encoding and more advanced third-generation audio and video encoding formats, the latter is preferred.

[0019] To calculate a target video bitrate that maximizes video quality while ensuring smooth playback under given real-time network bandwidth constraints, the establishment of a bandwidth-bitrate mapping model that includes network buffer capacity involves the following steps: collecting massive amounts of real user playback session data, including bandwidth time-series data, bitrate switching records, buffer events, and user terminal information; establishing bandwidth stability profiles for different network types (4G, 5G, Wi-Fi), different time periods, and different regions through data mining; organizing large-scale subjective tests, allowing subjects to rate the quality of the same video content at different bitrates (e.g., MOS score), and establishing a three-dimensional mapping database of "resolution-bitrate-subjective quality"; formulating initial mapping rules based on streaming media transmission theory, dividing the bandwidth into multiple intervals, and using different reservation ratios in each interval (more reservation for low bandwidth, and appropriate reduction for high bandwidth); and training a prediction model (e.g., gradient boosting decision tree or neural network). The network, characterized by bandwidth, network type, historical stability metrics, and video content complexity, predicts the optimal bitrate as the target bitrate. Specifically, the bandwidth-bitrate mapping model adopts a hierarchical decision structure: Input: real-time bandwidth, network type, target resolution, historical stability metrics; Based on the network type and target resolution, a basic mapping table is selected (initial mapping rules form the basic mapping table). In the mapping table, the baseline bitrate corresponding to the bandwidth is found. A dynamic adjustment factor is calculated based on stability metrics (such as bandwidth variance in the most recent minute). If the stability metric is high (large network fluctuations), the dynamic adjustment factor is reduced (e.g., 0.9), further reducing the bitrate; if the stability metric is low, the dynamic adjustment factor is increased (e.g., 1.05), making better use of the bandwidth. Then, the initial target bitrate is calculated, with a lower limit constraint: not lower than the lowest acceptable bitrate at this resolution (determined by the subjective quality database), and an upper limit constraint: not exceeding the bitrate of the original video source at this resolution. The final target bitrate is then output.

[0020] It is worth noting that the generation of the transcoding strategy identifier includes the following steps: Concatenating the target resolution, target bitrate, and target encoding format into a string according to a predefined format template. The format design must ensure unambiguity and compactness, for example: Video Content ID: Normalized Resolution: Target Bitrate: Target Encoding Format: Decision Version Number; Applying a cryptographic hash function to the serialized string to generate the hash value as the final transcoding strategy identifier. Hashization facilitates fixed-length output (e.g., 256 bits), making storage and indexing easier. The same input will always produce the same hash value, ensuring complete reproducibility of the strategy. Simultaneously, the hashing process is irreversible, preventing the derivation of specific parameter configurations from the identifier, providing a certain degree of technical protection, and greatly reducing the storage and retrieval complexity of the cache index; Furthermore, establishing a mapping relationship between the transcoding strategy identifier and video output parameter combinations and context-aware information in the node's local database ensures that the same terminal context and video request will generate the exact same strategy identifier at any time and on any edge node, achieving distributed cache consistency and global efficiency optimization.

[0021] Step 3: The edge node queries its local cache to see if there is transcoded video data corresponding to the transcoding strategy identifier. The query process involves a similarity matching algorithm, including the following steps: extracting key parameter information from the transcoding strategy identifier. Note that since the identifier is generated using a hash function, the system needs to maintain a mapping table from the identifier to the original parameters, or design a method to derive the parameters from the identifier. The extracted parameters mainly include the target resolution, target bitrate, and target encoding format. These parameters are normalized to ensure they fall within the same numerical range for easier comparison. A weighted similarity calculation method is used, assigning different weights to different parameters, with higher weights for resolution and encoding format than for bitrate. This is because changing resolution and encoding format requires complex pixel-level processing or format conversion, resulting in higher computational costs, while simple bitrate adjustments are easier. For each parameter, the degree of difference between the parameter value in the new request and the parameter value in the cached version is calculated. For example, for resolution, full marks are awarded if they are identical, otherwise zero marks are awarded. For bitrate, the relative difference ratio is used to calculate similarity. For encoding format, full marks are awarded if they are identical, and zero marks are awarded if they are different, or partial marks are awarded based on the difficulty of format conversion. The similarity scores of each parameter are multiplied by their corresponding weights and then summed to obtain the overall similarity score. Firstly, if the overall similarity score is... If the total similarity score is higher than the similarity threshold, the existence is output. Specifically, a preset similarity threshold is set, usually between 70% and 80%. All cached versions of the same video content are traversed, and the comprehensive similarity between each version and the new request is calculated. If the similarity of a version exceeds the threshold, the version with the highest similarity is selected as the matching version. If multiple versions have the same similarity, the most recently accessed version is selected first, because it may still be in the system's cache hotspot. The matching cached version is output, and the difference between the bitrate of the cached version and the target bitrate is detected. The bitrate of the video stream is adjusted based on the cached version. This adjustment is usually much faster than full transcoding. After the adaptation process is completed, the access record of the matching version is updated and distributed to the user. At the same time, the matching decision is recorded for subsequent optimization of the parameter weights of the similarity algorithm.

[0022] Secondly, if the original video data is not present, the edge node acquires the original video data and calls its internally integrated transcoding component equipped with a hardware acceleration unit. Based on the video output parameter combination, the edge node performs real-time transcoding of the original video data stream to generate adapted video stream data. On one hand, through the closed loop of real-time context awareness at the terminal and instant edge transcoding, theoretically optimal video stream parameters are generated for each specific device at a specific network time, completely solving the adaptation mismatch problem caused by preset versions. Under the same network conditions, this can improve the user's subjective quality score. On the other hand, since the transcoding decision and execution occur at the edge node within one hop of the user, the response latency to network state changes is extremely low. Quality adjustment can be completed within the next media segment loading cycle, eliminating the buffering and visual jump caused by version switching, achieving a truly seamless viewing experience. Specifically, the step of calling its internally integrated transcoding component equipped with a hardware acceleration unit, based on the... The video output parameter combination performs real-time transcoding of the original video data stream to generate adapted video stream data, including the following steps: Edge nodes query their internal routing tables or content directories based on the unique identifier of the video content to determine the exact storage location of the original video data. They then directly initiate HTTP / Range requests to the central origin server to obtain video data blocks within a specified time range. If the upstream CDN node (such as a regional center node) has already cached the original video data, it is pulled from the nearest upstream node to reduce backbone network pressure. A persistent connection is established with the origin server / upstream node to receive video data in a streaming manner. An input buffer is set up in the edge node's memory to temporarily store the received original video data sequentially. This original video data consists of video segments that are to be transcoded on demand, not necessarily the entire video, thus reducing operational intensity. Edge nodes allocate hardware acceleration resources in parallel, specifically including: GPU encoding cores, such as NVIDIA... The GPU's NVENC unit, AMD GPU's VCN unit, and Intel GPU's Quick Sync Video engine; dedicated video processing chips (ASICs); FPGA accelerator cards: pre-programmed field-programmable gate arrays (FPGAs) that implement video encoding functions, initializing the encoding session through corresponding driver APIs (such as NVIDIA's Video Codec SDK and Intel's Media SDK); converting video output parameters into configuration parameters recognizable by the hardware encoder, including: target resolution → setting the encoder's output width and height (e.g., 1280x720); target bitrate → setting the encoder's bitrate control mode (e.g., CBR / VBR) and target bitrate value (e.g., 3,000,000 bps); target encoding format → selecting the encoder type (e.g., H.264 / AVC, H.265 / HEVC, AV1 encoder); Simultaneously set auxiliary encoding parameters to balance quality and speed: including a preset "fast transcoding" mode, reducing motion estimation accuracy, reducing the number of reference frames, and automatically calculating and setting keyframe intervals and quantization parameters based on the target bitrate; Multi-threaded real-time transcoding pipeline execution, including: Decoding thread (consumer 1): reads raw video data from the input buffer, calls the hardware decoding unit (such as NVDEC) to decode the compressed raw video stream into raw YUV or RGB pixel data. If the raw encoding format is the same as the target format and only resolution / bitrate adjustment is needed, transcoding mode can be enabled to skip full decoding; Scaling processing thread (optional, if resolution conversion is required): if the target resolution is different from the raw resolution, sends the decoded video frames to the hardware scaling engine. The scaling engine (such as the GPU's texture unit or a dedicated scaler) uses a high-quality scaling algorithm (such as Lanczos) to adjust the frame size in real time, for example, scaling a 4K (3840x2160) frame to 720p (1 280x720); Encoding thread (Consumer 2): Sends the scaled (or directly decoded) video frames to the hardware encoder. The encoder compresses the video frames in real time according to the configured parameters, outputting a compressed video stream that conforms to the target format and bitrate. The hardware encoder typically supports "zero-copy" or "memory mapping" technology to avoid copying data back and forth between system memory and video memory, greatly reducing latency; Encapsulation and segmentation thread (Consumer 3): Encapsulates the basic stream (ES) output by the encoder according to the requirements of the target transmission protocol. Specifically, for the HLS protocol: encapsulates it into a .ts transport stream file and generates a corresponding .m3u8 index file; for the DASH protocol: encapsulates it into MP4 segments (fMP4) and generates an MPD manifest file, and cuts the continuous encoded stream into independent segments according to the preset segment length (usually 2-10 seconds); During transcoding, the encoder provides real-time feedback on the actual output bitrate and frame rate. If a deviation outside the threshold range is detected between the actual output and the target parameter combination (such as a quality degradation due to a sudden increase in content complexity), the transcoding controller dynamically fine-tunes the encoding parameters.

[0023] Step 4: The adapted video stream data is sent to the terminal device and cached in the local storage of the edge node using the transcoding strategy identifier as the index key. This achieves structural optimization of infrastructure costs, significantly reduces back-to-origin bandwidth costs, and only requires transmitting one high-quality source stream from the origin station to the edge, avoiding the bandwidth consumption of full distribution of multiple versions. It is expected to save origin station egress bandwidth. Furthermore, edge storage efficiency is significantly improved, with cached content changing from fixed multiple versions to dynamically generated versions that are actually needed, significantly improving storage space utilization, especially for long-tail content, reducing storage waste. Therefore, fixed, pre-consumed storage and bandwidth costs are transformed into elastic, on-demand edge computing costs, achieving precise matching of resource allocation and business needs.

[0024] Furthermore, the caching in the local storage of the edge node includes the following steps: A main directory is created for each video content, named after the transcoding strategy identifier of the video content. Within this main directory, a subdirectory is created for each different transcoding version. The name of the subdirectory is the hash value of the corresponding transcoding strategy identifier. Each subdirectory stores all video segment files for that version, along with related metadata files, recording detailed parameter information for that version, including resolution, bitrate, encoding format, creation time, last access time, and access count. A version index table is maintained in the edge node's memory, using the video content identifier as the primary key. Each primary key corresponds to a version linked list, and each node in the linked list stores a transcoding strategy identifier and a pointer to that version. The system stores a pointer to the version's location in local storage. Simultaneously, it establishes a reverse index from the transcoding strategy identifier to the version node, enabling bidirectional fast lookup. When a specific version needs access, the system locates the version list using the content identifier and then traverses the list to find the target version; alternatively, it can directly locate the version from the reverse index using the transcoding strategy identifier. When a new transcoded version is generated and ready for caching, a corresponding node is created in the memory index, and then the video segment data is written to the corresponding subdirectory in local storage. After writing is complete, the status of the memory index node is updated to ready. If a failure occurs during the writing process, the operation is rolled back to ensure no incomplete cached versions are left. Popular versions that are being accessed are marked as active to prevent accidental modification or deletion during access.

[0025] To effectively utilize limited storage space, infrequently used cached versions need to be periodically cleaned up. The cached versions in the local storage of the edge nodes also include a cache eviction policy, comprising the following steps: Calculating an eviction score for each cached version, including the last access timestamp, access frequency, version size, and transcoding computation cost. The last access time is the most important factor; the further back the last access time of a version is from the current time, the higher its eviction score. Lower access frequency also results in a higher eviction score, and a larger version's storage space usage increases the eviction score accordingly. Furthermore, if the transcoding computation cost of a version is very high, its eviction score will be appropriately reduced to avoid the high computational overhead of re-transcoding after eviction. A background daemon process is run, scanning all cached versions at fixed intervals (e.g., 72 hours) and calculating eviction scores. These scores are compared with a preset eviction threshold. Versions exceeding the threshold are marked as recyclable and sorted from highest to lowest eviction score. When the local storage space usage exceeds a warning line (e.g., 85%), the eviction process is immediately initiated, and versions are deleted according to the sorted order. In addition to freeing up storage space, versions with higher scores are prioritized for elimination. The elimination process employs a gradual strategy, eliminating a certain percentage of storage space each time (e.g., 5% to 10%) to avoid impacting system performance on large-scale cleanup. For versions marked as recyclable, it is first checked whether there are active transmission sessions using that version to ensure that ongoing services are not interrupted. After confirming that it is no longer in use, the node information of that version is removed from the memory index, and the free status of the storage space is updated. The actual data deletion operation may be delayed, employing a lazy deletion mechanism, performing physical deletion when the system load is low. Note: For popular versions with particularly high access frequency in the recent period, even if their last access time is relatively early, their retention time will be extended. For versions with extremely high transcoding computation costs (such as versions transcoded from 8 kilowatt ultra-high definition), a longer protection period will be given. At the same time, the parameters of the elimination strategy can be dynamically adjusted according to the operating conditions. For example, when storage space is sufficient, a more lenient elimination strategy can be adopted; when storage space is tight, a more aggressive elimination strategy will be adopted.

[0026] Therefore, as illustrated above, this invention provides an example: Assume a user requests to play a movie. Their device screen has a full HD resolution, the network bandwidth is 5 megabits per second, and it supports efficient video encoding formats. The edge node first generates a transcoding strategy identifier based on this information: movie identifier_full HD_5 megabits_efficient video encoding. Then, the node searches for a completely matching version in the cache. Assuming no match is found, a similarity matching algorithm is initiated, and the following cached versions are found: movie identifier_full HD_4.5 million bits_efficient video encoding (last access time: 3 hours ago), movie identifier_HD_5 megabits_efficient video encoding (last access time: 1 hour ago), movie identifier_full HD_5 megabits_general video encoding (last access time: 5 hours ago). The similarity between each version and the new request is calculated: Version 1: resolution completely matches, encoding format completely matches, bitrate difference is 10%, overall similarity is 92%.

[0027] Version 2: Resolution mismatch (HD is lower than Full HD), encoding format match, bitrate match, overall similarity is 60%.

[0028] Version 3: Resolution matches, encoding format does not match, bitrate matches, overall similarity is 70%; the preset similarity threshold is 80%, therefore Version 1 is selected as the matching version. Version 1 undergoes a rapid bitrate adjustment, increasing it from 4.5 million bits to 5 million bits, and is then distributed to users. Simultaneously, the last access time of Version 1 is updated to the current time. Meanwhile, in the background, the cache eviction daemon detects that a version of another movie has not been accessed for over 72 hours, and its eviction score exceeds the threshold, so it is marked as reclaimable. When storage space usage exceeds the warning line, the system deletes that version from the cache, freeing up storage space.

[0029] The second objective of this invention is to provide an intelligent distribution device based on dynamic video transcoding of CDN nodes, including any of the above-mentioned intelligent distribution methods based on dynamic video transcoding of CDN nodes, comprising a context-aware information acquisition unit, a transcoding strategy identifier generation unit, a similarity matching unit, a transcoding component, and an index storage unit; the context-aware information acquisition unit is used to report context-aware information, including its screen physical resolution, a list of supported video decoding formats, and real-time estimated network bandwidth, to the server through the terminal device; the transcoding strategy identifier generation unit is used by the edge nodes of the content delivery network (CDN) to receive video content requests and the context-aware information, and generate transcoding components. The strategy identifier dynamically determines the combination of video output parameters applicable to the video content request; the similarity matching unit is used to enable edge nodes to query whether there is transcoded video data in their local cache corresponding to the transcoding strategy identifier; the transcoding component is used to enable edge nodes to obtain the original video data when it does not exist in the local cache, call its internally integrated transcoding component equipped with a hardware acceleration unit, and transcode the original video data stream in real time according to the combination of video output parameters to generate adapted video stream data; the index storage unit is used to send the adapted video stream data to the terminal device and cache it in the local storage of the edge node with the transcoding strategy identifier as the index key.

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

Claims

1. An intelligent distribution method based on dynamic video transcoding of CDN nodes, characterized in that, The process includes the following steps: The terminal device reports context-aware information to the server, including its screen physical resolution, a list of supported video decoding formats, and real-time estimated network bandwidth; The edge node of the Content Delivery Network (CDN) receives the video content request and the context-aware information, generates a transcoding strategy identifier, and dynamically determines the combination of video output parameters applicable to the video content request, wherein the parameter combination includes at least the target resolution, target bitrate, and target encoding format. The edge node queries its local cache to see if there is transcoded video data corresponding to the transcoding strategy identifier. If not, the edge node obtains the original video data, calls its internally integrated transcoding component equipped with a hardware acceleration unit, and performs real-time transcoding of the original video data stream according to the video output parameter combination to generate adapted video stream data. The adapted video stream data is then sent to the terminal device and cached in the edge node's local storage using the transcoding strategy identifier as the index key.

2. The intelligent distribution method based on dynamic video transcoding of CDN nodes according to claim 1, characterized in that: The reporting of context-aware information adopts a three-layer information acquisition system, including the following steps: In the static capability layer: the actual number of pixels on the display panel is obtained by calling the native graphics interface of the operating system, and the physical resolution of the screen is output; at the same time, all available hardware decoders are enumerated by querying the system media framework, and their supported encoding standards, configuration files and levels are parsed to generate a priority list sorted by decoding efficiency and energy consumption, and a list of supported video decoding formats is output; In the dynamic state layer: the download throughput of historical video segments is passively observed and continuously analyzed to provide continuous, low-overhead baseline estimates, and when the network state is unclear or changes drastically, active detection is performed, sending detection packet sequences to edge nodes, calculating bottleneck bandwidth based on packet pair dispersion technology, and outputting real-time estimated network bandwidth by fusing passive observation and active detection data through Kalman filter data; In the reporting control layer: the complete context is reported during the first playback, and when the bandwidth change rate is detected to exceed a preset threshold, event reporting is immediately triggered, while a silent period is set to prevent invalid reporting storms caused by instantaneous network jitter.

3. The intelligent distribution method based on dynamic video transcoding of CDN nodes according to claim 2, characterized in that: The dynamic determination of the video output parameter combination suitable for the video content request includes the following steps: comparing the screen physical resolution with the original resolution of the requested video content, selecting a standard resolution level from a set of standard resolution levels that does not exceed the screen physical resolution and is adapted to the current network conditions as the target resolution; inputting the real-time estimated network bandwidth into a preset bandwidth-bitrate mapping relationship model that includes network buffer margin, and outputting the target bitrate; selecting the format with the highest compression efficiency from the list of supported video decoding formats reported by the terminal device, sorted according to the preset encoding efficiency priority, as the target encoding format.

4. The intelligent distribution method based on dynamic video transcoding of CDN nodes according to claim 3, characterized in that: The establishment of the bandwidth-bitrate mapping model, which includes network buffer capacity, involves the following steps: collecting massive amounts of real user playback session data, including bandwidth time-series data, bitrate switching records, buffering events, and user terminal information; establishing bandwidth stability profiles for different network types, time periods, and regions through data mining; organizing large-scale subjective tests, allowing subjects to rate the quality of the same video content at different bitrates, and establishing a three-dimensional mapping database of "resolution-bitrate-subjective quality"; formulating initial mapping rules based on streaming media transmission theory, dividing the bandwidth into multiple intervals, and using different reserve ratios in each interval; and training a prediction model, using bandwidth, network type, historical stability indicators, and video content complexity as features to predict the optimal bitrate as the target bitrate.

5. The intelligent distribution method based on dynamic video transcoding of CDN nodes according to claim 4, characterized in that: The process of generating the transcoding strategy identifier includes the following steps: concatenating the target resolution, target bitrate, and target encoding format into a string according to a predefined format template; applying an encrypted hash function to the serialized string to generate a hash value that is the final transcoding strategy identifier; wherein: in the node's local database, establishing a mapping relationship between the transcoding strategy identifier and the combination of video output parameters and context-aware information.

6. The intelligent distribution method based on dynamic video transcoding of CDN nodes according to claim 1, characterized in that: The edge node queries the local cache to determine if there is transcoded video data corresponding to the transcoding strategy identifier. This involves a similarity matching algorithm, including the following steps: extracting key parameter information from the transcoding strategy identifier; using a weighted similarity calculation method to assign different weights to different parameters, with resolution and encoding format having higher similarity weights than bitrate; multiplying the similarity scores of each parameter by their corresponding weights and summing them to obtain a comprehensive similarity score; if the comprehensive similarity score is higher than a similarity threshold, an existence is detected, a matching buffered version is output, and the difference between the bitrate of the buffered version and the target bitrate is detected. The bitrate of the video stream is then adjusted based on the buffered version.

7. The intelligent distribution method based on dynamic video transcoding of CDN nodes according to claim 1, characterized in that: The process of calling its internally integrated transcoding component, equipped with a hardware acceleration unit, to perform real-time transcoding of the original video data stream based on the video output parameter combination and generate adapted video stream data includes the following steps: establishing an input buffer in the memory of the edge node to temporarily store the received original video data in sequence, wherein the original video data is the video segment to be transcoded as needed; allocating hardware acceleration resources in parallel at the edge node; converting the video output parameter combination into configuration parameters recognizable by the hardware encoder; executing the transcoding pipeline in real time using multiple threads; during the transcoding process, the encoder provides real-time feedback on the actual output bitrate and frame rate indicators, and if a deviation outside the threshold range is detected between the actual output and the target parameter combination, the transcoding controller dynamically fine-tunes the encoding parameters.

8. The intelligent distribution method based on dynamic video transcoding of CDN nodes according to claim 6, characterized in that: The caching in the local storage of the edge node includes the following steps: A main directory is created for each video content, named after the transcoding strategy identifier of the video content. Within this main directory, a subdirectory is created for each different transcoding version. The name of the subdirectory is the hash value of the corresponding transcoding strategy identifier. Each subdirectory stores all video segment files and related metadata files for that version, recording detailed parameter information for that version. A version index table is maintained in the edge node's memory, using the video content identifier as the primary key. Each primary key corresponds to a version linked list. Each node in the linked list stores a transcoding strategy identifier and a pointer to the version's location in local storage. Simultaneously, a reverse index is created from the transcoding strategy identifier to the version node. When a new transcoding version is generated and ready for caching, a corresponding node is created in the memory index. Then, the video segment data is written to the corresponding subdirectory in local storage. After writing, the status of the memory index node is updated to ready. For popular versions that are being accessed, they are marked as active.

9. The intelligent distribution method based on dynamic video transcoding of CDN nodes according to claim 8, characterized in that: The cache cached in the local storage of the edge node also includes a cache eviction policy, comprising the following steps: calculating an eviction score for each cache version, including the last access timestamp, access frequency, version size, and transcoding computation cost; running a background daemon process to scan all cache versions at fixed intervals and calculate the eviction score, comparing the score with a preset eviction threshold, marking versions that exceed the threshold as recyclable, sorting them by eviction score from high to low, and immediately initiating the eviction process when the local storage space usage exceeds the warning line, performing deletion operations to release space according to the sorting.

10. An intelligent distribution device for implementing dynamic video transcoding based on CDN nodes, comprising the intelligent distribution method for dynamic video transcoding based on CDN nodes as described in any one of claims 1-9, characterized in that: The system includes a context-aware information acquisition unit, a transcoding strategy identifier generation unit, a similarity matching unit, a transcoding component, and an index storage unit. The context-aware information acquisition unit is used to report context-aware information, including its screen physical resolution, a list of supported video decoding formats, and real-time estimated network bandwidth, to the server through the terminal device. The transcoding strategy identifier generation unit is used by the edge nodes of the Content Delivery Network (CDN) to receive video content requests and the context-aware information, generate transcoding strategy identifiers, and dynamically determine the combination of video output parameters suitable for the video content requests. The similarity matching unit is used to enable edge nodes to query whether there is transcoded video data in their local cache that corresponds to the transcoding strategy identifier; the transcoding component is used to enable edge nodes to obtain the original video data when it does not exist in the local cache, call its internally integrated transcoding component equipped with a hardware acceleration unit, and transcode the original video data stream in real time according to the combination of video output parameters to generate adapted video stream data; the index storage unit is used to send the adapted video stream data to the terminal device and cache it in the local storage of the edge node with the transcoding strategy identifier as the index key.

Images