Faster-Than-Real-Time Encoder Pool for Low-Concurrency Video Channels
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Cloud-based video encoding services for low-concurrency linear channels face inefficiencies due to wasted computational resources and delays in providing encoded video streams, as these channels often have no viewers for extended periods, leading to unnecessary per-minute charges and delayed video availability.
Innovation Solution
Implementing a system that uses a faster-than-real-time (FTRT) encoder to initially encode video streams at a lower quality level, allowing immediate delivery, while a real-time linear (RTL) encoder is initialized in the background, switching to RTL once ready, and returning FTRT encoders to a pool for future use.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Manufacturing precision
If a real-time linear (RTL) encoder is started to encode video streams, then video encoding quality is improved, but startup delay increases
Solution Approach 1:
The system pre-starts FTRT encoders in advance to encode video streams before RTL encoders are fully initialized. This preliminary action ensures that video encoding can begin immediately upon viewer request, eliminating startup delay while maintaining a pathway to high-quality encoding once the RTL encoder is ready.
Solution Approach 2:
The FTRT encoder acts as an intermediary solution during the transition period. It provides functional video encoding capability while the RTL encoder is being initialized, bridging the gap between immediate delivery needs and high-quality encoding requirements without requiring the RTL encoder to be fully ready.
2Speed
If FTRT encoders are used to encode video streams immediately, then delivery speed is improved, but video quality deteriorates
Solution Approach 1:
The system dynamically switches encoding responsibilities from FTRT to RTL encoders based on readiness status. Initially, FTRT encoders handle delivery to ensure immediate speed, but once RTL encoders are fully initialized, the system transitions to RTL encoding to restore high video quality, making the encoding quality dynamic rather than static.
Solution Approach 2:
The encoding parameters change based on encoder readiness. FTRT encoders operate with parameters optimized for speed (faster-than-real-time encoding), while RTL encoders use parameters optimized for quality (real-time encoding with higher fidelity). The system adjusts which encoder is active based on the initialization state, changing operational parameters to match delivery requirements.
3Manufacturing precision
If RTL encoders are started for each channel request, then encoding quality is maintained, but computational resource waste increases
Solution Approach 1:
The system pre-starts FTRT encoders in advance so they are immediately available to handle video encoding requests. This preliminary preparation eliminates the need to spin up new encoders for each channel request, reducing computational overhead and resource waste while maintaining encoding capability through the FTRT encoders during low-concurrency periods.
Solution Approach 2:
FTRT encoders serve as universal, always-available encoding resources that can handle multiple channel requests immediately. Rather than creating dedicated RTL encoders for each channel (which would waste resources on low-concurrency channels), the system uses a pool of FTRT encoders that can service multiple channels, reducing overall computational resource consumption.
4Reliability
If continuous video encoding is performed for low-concurrency channels, then video availability is improved, but operational cost increases
Solution Approach 1:
The system uses already-running FTRT encoders to service video encoding requests for low-concurrency channels without requiring dedicated continuous RTL encoder instances. The FTRT encoders self-serve by handling encoding tasks for multiple channels as needed, providing video availability on-demand rather than through continuous dedicated encoding, thereby reducing operational costs.
Solution Approach 2:
The system discards the assumption that each channel needs a dedicated continuous encoder instance. Instead, it recovers computational resources by using a shared pool of FTRT encoders that can be dynamically allocated to different low-concurrency channels as requests arrive, eliminating wasted operational costs on continuously running encoders for channels with no or few viewers.
Data Source
AI summary
Systems, methods, and devices relating to video encoding for low-concurrency video channels are described herein. A video processing system may receive a manifest request for an encoded video stream associated with a selected channel. Based on the manifest request, the video processing system may request for a real-time linear (RTL) encoder to be started to encode the input compressed video stream for the channel in real-time. Also based on the manifest request, the video processing system may assign a faster-than-real-time (FTRT) encoder from a pool of already-running FTRT encoders to encode the video stream in real-time until the RTL encoder is fully started. The FTRT encoder may encode at a lower quality level to enable expedited real-time encoding. Based on the RTL encoder being fully started, the video processing system may switch the encoding from the FTRT encoder to the RTL encoder. The FTRT encoder may be returned to the FTRT encoder pool.