AAV1+DASH +OSSFS cloud native live broadcast system oriented to global high-concurrency scene

Abstract

The invention relates to an AV1 + DASH + OSSFS cloud native live broadcast system oriented to a global high concurrency scene, and belongs to the technical field of live broadcast systems. The architecture is as follows: an encoder server operates an encoder supporting AV1 encoding and deploys an ossfs client at the same time; an encoder generates a multi-code-rate. M4s slice and a. Mpd index file from a video stream according to a DASH protocol, and the multi-code-rate. M4s slice and the. Mpd index file are directly written into an ossfs mounted local directory; mounting and synchronizing the ossfs: mounting a cloud service layer OSS Buck as a local file system by the ossfs, and automatically synchronizing. M4s and. Mpd files written by the encoder to the OSS by the ossfs; and in the synchronization process, the ossfs realizes consistency verification of the metadata and the file content through the OSS API. According to the stream pulling end, a DASH player client requests a. Mpd file through an OSS public network address or a bound CDN domain name, and after analysis, the. M4s slice with the corresponding code rate is pulled from an OSS / CDN according to the real-time network condition, so that self-adaptive playing is achieved. According to the scheme, the packet size is saved by 30%-40% through AV1, meanwhile, the problem of network adaptation shortages is solved through DASH + OSSFS, the traffic cost is reduced by half, the jamming rate is reduced by six percent, and the global 4K user experience is unified.

Description

Technical Field

[0001] This invention relates to an AV1+DASH+OSSFS cloud-native live streaming system for high-concurrency scenarios worldwide, belonging to the field of live streaming system technology. Background Technology

[0002] I. Existing Technical Architecture Traditional solutions consist of an "encoder server," a "media server," and a "distribution network," with the following specific process: The encoder server runs an H.264 / H.265-based encoder, which slices the video stream into .ts media slices (containing video and audio) and .m3u8 index files according to the HLS protocol, and outputs them to the local directory. The media server needs to deploy a web service that supports HLS (such as Nginx), set the encoder output directory as the service root directory, and provide access to the slice files to the outside world via HTTP; The player client requests the .m3u8 file through the media server address, parses it, and then streams the .ts segment for playback.

[0003] II. Disadvantages of Existing Technologies (1) The contradiction between coding efficiency and bandwidth usage To meet the core image quality indicators of 4K (no loss of detail, no compression block effect), H.264 / H.265 encoding has high bandwidth requirements at the same image quality (e.g., 4-8Mbps for 1080P live streaming, and 15-22Mbps bitrate for HEVC-encoded 4K live streaming). This leads to a surge in bandwidth costs in high-concurrency scenarios when business surges. If the bitrate is reduced to below 12Mbps, text and edge details in 4K images will be noticeably blurred (SSIM drops below 0.9). Reducing the bitrate to save bandwidth results in a significant degradation in image quality, making it difficult to balance the "image quality-bandwidth" relationship.

[0004] (2) The HLS protocol traditionally has higher latency. In traditional implementations, HLS initially mandated the use of MPEG-2 Transport Stream (.ts) containers. Compared to fMP4, .ts containers have a larger header overhead, with each slice containing duplicate metadata, leading to lower network transmission efficiency and wasted bandwidth. The classic HLS operating model requires the server to generate a complete slice file (e.g., 2-6 seconds) before the client can download it. This inherently results in a delay of at least 2-3 slices (i.e., 6-18 seconds). (3) Limited elastic scaling and concurrency capabilities The bottleneck is the outbound bandwidth and number of connections of the media server. A single server can only support a few thousand concurrent connections (calculated at 1080P@5Mbps, 1Gbps bandwidth can only support 200 concurrent connections); expansion requires building a load balancing cluster, which is technically complex and costly.

[0005] (4) High reliability and high maintenance costs The media server is a single point of failure; a crash or disk failure will cause a complete interruption of the live broadcast. Dedicated personnel are required to maintain the server system and handle security vulnerabilities, resulting in high labor costs.

[0006] (5) Poor global distribution adaptability The network environment varies greatly across different regions, making it difficult for HLS to dynamically adapt to network fluctuations for users worldwide. When combined with CDN, origin return rules need to be manually configured, making cross-regional latency optimization difficult. Summary of the Invention

[0007] The purpose of this invention is to provide an AV1+DASH+OSSFS cloud-native live streaming system for high-concurrency scenarios worldwide, in order to solve the above-mentioned technical problems.

[0008] To achieve the above objectives, the technical solution adopted by the present invention is as follows: An AV1+DASH+OSSFS cloud-native live streaming system designed for high-concurrency scenarios globally has the following architecture: Encoder server: Runs an encoder that supports AV1 encoding, and deploys an ossfs client; The encoder generates multi-bitrate .m4s slices and .mpd index files from the video stream according to the DASH protocol, and writes them directly to the local directory mounted by ossfs; ossfs mounting and synchronization: ossfs mounts the cloud service layer OSS Bucket as a local file system. The .m4s and .mpd files written by the encoder are automatically synchronized to OSS by ossfs. During the synchronization process, ossfs uses the OSS API to verify the consistency between metadata and file content.

[0009] Pulling end: The DASH player client requests the .mpd file via the OSS public IP address or the bound CDN domain name. After parsing, it pulls the .m4s slice with the corresponding bitrate from OSS / CDN according to the real-time network conditions to achieve adaptive playback.

[0010] A further improvement to the technical solution of this invention is as follows: Optimize AV1 encoding parameters: adopt "constant quality mode" to ensure image quality stability, set --cpu-used=4 to balance encoding speed and compression efficiency; when generating multi-bitrate streams, use the --crf parameter to ensure smooth transition of bitrate steps.

[0011] A further improvement to the technical solution of this invention is: a DASH and OSSFS collaborative mechanism. 1) Dynamic updates of .mpd: After the encoder generates a new slice, it automatically updates the @duration and SegmentList fields of .mpd. The updated .mpd is synchronized to OSS in real time by ossfs to ensure that the client obtains the latest index; 2) Dynamic bitrate grading: Automatically generates three bitrate levels: 4K@9Mbps, 4K@12Mbps, and 4K@15Mbps. The .mpd index updates the slice bitrate information in real time. When the user's network fluctuates, the bitrate is switched within 0.5 seconds, reducing the stuttering rate to 1.8%. 3) Flexible slice duration: Supports dynamic slicing from 4 to 6 seconds. For low-bandwidth users, the loading latency for 4K slices is reduced from 10 seconds to 4.5 seconds, balancing loading speed and image quality. 4) Slice consistency guarantee: Use the ossfs --attr-cache-timeout=0 parameter to disable metadata caching. When the client requests .m4s, it directly reads the latest version of OSS to avoid slice loss caused by local caching.

[0012] Due to the adoption of the above technical solution, the technical effects achieved by this invention are as follows: 1. Extremely high elasticity and scalability with high concurrency: The concurrent pressure of streaming is entirely borne by OSS. Whether it is a small number of viewers or tens of millions of viewers, the encoder server always only performs simple upload tasks, achieving true "unlimited concurrency" and completely solving the concurrency bottleneck problem of media servers in traditional solutions.

[0013] 2. Extremely high reliability and data durability: Enjoy the high availability guaranteed by Alibaba Cloud OSS Service Level Agreement (SLA), typically up to 99.995%. Data is automatically and redundantly backed up on multiple physical devices and availability zones on OSS, virtually eliminating the risk of data loss and greatly improving system reliability.

[0014] 3. Significantly reduces operational complexity and costs (O&M): No media servers need to be managed; the entire streaming and distribution process is hosted by Alibaba Cloud. Operations and maintenance only need to focus on whether the encoder itself is running normally, greatly reducing labor costs and the probability of errors.

[0015] 4. Cost-effectiveness and Pay-as-you-go pricing: Enjoy the advantages of cloud-native pay-as-you-go pricing. In terms of storage costs, OSS storage fees are extremely low; regarding traffic costs, you only pay for the external network traffic actually drawn by viewers, incurring almost no traffic fees when there are no viewers. For business scenarios with unstable traffic, the cost-effectiveness is extremely high.

[0016] 5. Seamless integration with CDN for global acceleration: CDN acceleration can be enabled for OSS Bucket with one click. By utilizing Alibaba Cloud's global CDN nodes, viewers can obtain video slices from the nearest location and achieve a playback experience with extremely low latency and extremely high speed. The configuration is simple and the effect is immediate, solving the problem of complex global distribution in traditional solutions. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the architecture of the present invention; Figure 2 This is a comparison of the advantages of the present invention with traditional solutions. Figure 1 ; Figure 3 This is a comparison of the advantages of the present invention with traditional solutions. Figure 2 ; Figure 4 This is a schematic diagram of the traditional methodology architecture; Detailed Implementation

[0018] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below in conjunction with specific embodiments.

[0019] The technical solution of this invention is an AV1+DASH+OSSFS cloud-native live streaming system for high-concurrency scenarios worldwide. It achieves high-quality and high-efficiency video live streaming through a completely new architecture.

[0020] Combination Figure 1 This section provides a detailed explanation of the system.

[0021] Encoder server: Runs an encoder that supports AV1 encoding (such as SVT-AV1, libaom), and deploys an ossfs client; the encoder generates .m4s slices and .mpd index files of the video stream in multiple bitrates (such as 360P@500kbps, 1080P@2Mbps, 2160P@6Mbps) according to the DASH protocol, and writes them directly to the local directory mounted by ossfs (example path: / mnt / oss-live / stream / ).

[0022] ossfs mounting and synchronization: ossfs mounts the Alibaba Cloud OSS Bucket as a local file system. The .m4s and .mpd files written by the encoder are automatically synchronized to OSS by ossfs (synchronization delay ≤ 1 second). During the synchronization process, ossfs uses the OSS API to verify the consistency between metadata (such as slice duration and bitrate) and file content.

[0023] Pulling end: DASH player clients (such as Shaka Player, ExoPlayer) request .mpd files via OSS public IP address or bound CDN domain name, and after parsing, pull .m4s slices of the corresponding bitrate from OSS / CDN according to real-time network conditions to achieve adaptive playback.

[0024] The advantages of the above technical solutions are: optimized packet size, specifically, AV1 encoding reduces the single slice packet size from 11.25-16.5MB (HEVC) to 6.75-11.25MB under consistent 4K quality, saving 30%-40%; and it uses the DASH protocol to solve the fixed slice / bitrate problem of HLS, OSSFS+OSS replaces self-built servers to break through bandwidth bottlenecks, and CDN dynamically adapts to the global network.

[0025] The key technologies of this technical solution are described below: I. Intra-frame prediction: Prediction direction selection adopts adaptive Angular mode (1-67 directions) + auxiliary DC / Planar mode.

[0026] It has the following advantages: 4K resolution contains a lot of details (such as text and edges), Angular mode predicts 67 directions to accurately match complex textures, and the image quality loss is 8% lower than that of DC mode alone.

[0027] Solid color backgrounds (such as live streaming backgrounds) automatically switch between DC / Planar mode, reducing encoding time by 10% and ensuring real-time live streaming.

[0028] 2. GOP interval (I-frame interval), specifically, the keyframe generation cycle is 5 seconds (corresponding to 125 frames at 25fps frame rate).

[0029] 4K I-frame bitrate is 8-10 times that of P-frame. A 5-second interval can control the bitrate of a single I-frame to 60-80Mbps, avoiding a 30% bitrate spike caused by excessively dense I-frames (<3 seconds).

[0030] The 5-second interval meets the fast loading requirements of 4K users who "enter the live stream midway" (loading delay ≤ 2 seconds), avoiding delays exceeding 3 seconds caused by excessively sparse I-frames (> 8 seconds).

[0031] 3. Deblocking filter strength, strength 1 (--deblock=1:1).

[0032] When a 4K image is enlarged, the compression block effect is more obvious. An intensity of 0 cannot eliminate the block effect, while an intensity of ≥2 will cause details to be blurred (such as the blurring of the edges of text in 4K).

[0033] Strength 1 can eliminate 90% of the block artifacts, and the encoding time only increases by 5%, meeting the dual requirements of "real-time performance + image quality" for live streaming.

[0034] IV. SAO filtering parameters, specifically, the Sample Adaptive Offset (SAO) value is enabled (--sao=1).

[0035] For 4K dynamic scenes (such as sports event footage), SAO filtering can compensate for edge brightness differences, improving SSIM from 0.92 to 0.94 without compensating for image quality by increasing the bitrate (increasing packet size).

[0036] V. Bitrate / quality control method: Constant Quality Factor (CQP) is adopted.

[0037] 4K scenes involve complex lighting and scene transitions, and fixed bitrate mode is prone to "wasted bitrate in dark scenes and insufficient bitrate in bright scenes". CQP mode uses CRF=27 to precisely control the image quality of the entire scene and ensure that PSNR is stable at ≥36dB.

[0038] VI. Multi-bitrate grading, specifically refers to constant quality factor (CRF), using 4K base version @29, standard version @27, and high-definition version @25.

[0039] For every 2 reduction in CRF, the bitrate increases by approximately 25%. This gradation ensures a smooth transition in image quality between 4K slices with different bitrates (SSIM difference ≤ 0.02), so users are unaware of switching bitrates.

[0040] Optimize AV1 encoding parameters: Use "Constant Quality Mode (CQP)" to ensure image quality stability, and set --cpu-used=4 to balance encoding speed and compression efficiency (saving 40% bandwidth compared to H.265, while keeping encoding latency within 2 seconds); when generating multi-bitrate streams, use the --crf parameter to grade (e.g., 360P@CRF=30, 1080P@CRF=24, 2160P@CRF=25) to ensure a smooth transition of bitrate steps.

[0041] This technical solution employs a collaborative mechanism between DASH and OSSFS, and its specific working method is as follows: 1. Dynamic updates of .mpd: After the encoder generates a new slice, it automatically updates the @duration and SegmentList fields of .mpd. ossfs synchronizes the updated .mpd to OSS in real time to ensure that the client obtains the latest index.

[0042] 2. Dynamic bitrate grading: Automatically generates three bitrate levels: 4K@9Mbps (basic), 4K@12Mbps (standard), and 4K@15Mbps (high definition). The .mpd index updates the slice bitrate information in real time. When the user's network fluctuates (such as 4G→5G), the bitrate is switched within 0.5 seconds, and the stuttering rate is reduced to 1.8%.

[0043] 3. Flexible slice duration: Supports dynamic slicing from 4 to 6 seconds (6 seconds when the network is good, 4 seconds when the network is poor). For low-bandwidth users in Africa, the loading latency for 4K slices has been reduced from 10 seconds to 4.5 seconds, balancing loading speed and image quality.

[0044] 4. Slice consistency guarantee: Use the ossfs --attr-cache-timeout=0 parameter to disable metadata caching. When the client requests .m4s, it directly reads the latest version of OSS to avoid slice loss caused by local caching.

[0045] OSSFS+OSS: Breaking the Bottleneck of Self-Built Servers 1. No bandwidth limit: As a distributed storage, OSS naturally supports tens of millions of 4K concurrent connections without the need for additional servers. Even when there is a sudden surge of 50,000 4K concurrent connections, it can still maintain a synchronization latency of ≤1.2 seconds, which is 100 times faster than the scaling response speed of traditional servers. 2. Global Network Adaptation: OSS supports multi-region backup (Beijing, Tokyo, Frankfurt nodes), OSSFS automatically synchronizes popular 4K slices to the nearest node, and CDN dynamically caches based on user IP—prioritizing 15Mbps high bitrate slices in Asia and prioritizing 9Mbps basic bitrate slices in Africa. The average latency for global 4K streaming is ≤380ms, which is 62% lower than traditional solutions. 3. Zero-maintenance network configuration: No need to manually configure load balancing and CDN origin rules. OSS and CDN are bound with one click. Network parameters (such as cache TTL and bitrate priority) are automatically adapted to the regional network, improving operation and maintenance efficiency by 90%.

[0046] This technical solution achieves efficient integration of AV1 and DASH, combining the high compression efficiency of AV1 with the adaptive bitrate characteristics of DASH. While reducing bandwidth costs by 40%, it adapts to complex network environments through multi-bitrate slicing, thus resolving the "quality-bandwidth" contradiction in traditional encoding.

[0047] This technical solution enables automated deployment of DASH driven by OSSFS: it utilizes OSSFS to achieve automatic synchronization of .mpd indexes and .m4s slices, as well as metadata consistency verification, eliminating the manual configuration and synchronization risks of traditional DASH and lowering the deployment threshold.

[0048] This technical solution employs a cloud-native global distribution architecture: integrating OSS's distributed storage, CDN's dynamic caching and cross-regional replication capabilities, enabling the DASH protocol to support global concurrency and low-latency access without additional modifications, breaking through the geographical limitations of traditional solutions.

[0049] This technical solution has significant improvements over traditional solutions in terms of key characteristics and indicators, specifically for example... Figure 2 , Figure 3 As shown.

[0050] In the implementation of this technical solution, there are the following alternative solutions.

[0051] Encoding format alternative: VP9 encoding (the predecessor of AV1) can be used, but the compression efficiency is 15%-20% lower than AV1.

[0052] Protocol alternative: HLS protocol combined with AV1 (supported by Apple devices) can be used, but HLS has a fixed slice duration (≥6 seconds) and its adaptive flexibility is weaker than DASH (which supports 1-2 second slices).

[0053] Storage alternatives: Object storage from other cloud vendors (such as AWS S3) can be used, but a mounting tool similar to ossfs needs to be developed, and the CDN integration ecosystem is not as complete as Alibaba Cloud's.

[0054] Explanation of terms 1. AV1 encoding characteristics: An open-source, patent-free encoding standard developed by the AOMedia Alliance. Through advanced intra-frame prediction and transform quantization algorithms, it reduces the bit rate by 40% compared to H.265 at the same image quality, making it suitable for high-resolution live streaming scenarios.

[0055] 2. DASH Protocol Details: A dynamic adaptive streaming media protocol based on HTTP. It uses .mpd index files to describe information such as the URL, duration, and bitrate of multi-bitrate slices. Clients can switch bitrates in real time to avoid buffering.

[0056] 3. ossfs and DASH coordination logic: ossfs' --direct-io mode ensures that .m4s slices are written synchronously, and the --no-symlink parameter prevents slice path errors caused by symbolic links, ensuring that DASH clients can correctly resolve slice addresses in .mpd.

[0057] Under the premise of completely consistent 4K image quality, this solution achieves a 30%-40% reduction in packet size through AV1, while DASH+OSSFS solves the network adaptation shortcomings of traditional solutions, achieving "half the traffic cost and 60% reduction in stuttering rate", and a unified 4K user experience globally.

Claims

1. An AV1+DASH+OSSFS cloud-native live streaming system for high-concurrency scenarios worldwide, characterized in that: The architecture is as follows: Encoder server: Runs an encoder that supports AV1 encoding, and deploys an ossfs client; The encoder generates multi-bitrate .m4s slices and .mpd index files from the video stream according to the DASH protocol, and writes them directly to the local directory mounted by ossfs; OSSFS mounting and synchronization: OSSFS mounts the cloud service layer OSS Bucket as a local file system. The .m4s and .mpd files written by the encoder are automatically synchronized to OSS by OSSFS. During the synchronization process, OSSFS uses the OSS API to verify the consistency between metadata and file content. Pulling end: The DASH player client requests the .mpd file via the OSS public IP address or the bound CDN domain name. After parsing, it pulls the .m4s slice with the corresponding bitrate from OSS / CDN according to the real-time network conditions to achieve adaptive playback.

2. The AV1+DASH+OSSFS cloud-native live streaming system for global high-concurrency scenarios as described in claim 1, characterized in that: Optimize AV1 encoding parameters: Use "constant quality mode" to ensure image quality stability, and set --cpu-used=4 to balance encoding speed and compression efficiency; When generating multi-bitrate streams, the --crf parameter is used to grade the bitrates to ensure a smooth transition of bitrate steps.

3. The AV1+DASH+OSSFS cloud-native live streaming system for global high-concurrency scenarios as described in claim 1, characterized in that: DASH and OSSFS Collaboration Mechanism: 1) Dynamic updates of .mpd: After the encoder generates a new slice, it automatically updates the @duration and SegmentList fields of .mpd. The updated .mpd is synchronized to OSS in real time by ossfs to ensure that the client obtains the latest index; 2) Dynamic bitrate grading: Automatically generates three bitrate levels: 4K@9Mbps, 4K@12Mbps, and 4K@15Mbps. The .mpd index updates the slice bitrate information in real time. When the user's network fluctuates, the bitrate is switched within 0.5 seconds, reducing the stuttering rate to 1.8%. 3) Flexible slice duration: Supports dynamic slicing from 4 to 6 seconds. For low-bandwidth users, the loading latency for 4K slices is reduced from 10 seconds to 4.5 seconds, balancing loading speed and image quality. 4) Slice consistency guarantee: Use the ossfs --attr-cache-timeout=0 parameter to disable metadata caching. When the client requests .m4s, it directly reads the latest version of OSS to avoid slice loss caused by local caching.

Images