Dual-Path Live Streaming for Low Latency and Seamless Rewind
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Streaming of live video and/or audio content over the Internet often experiences high latency due to the use of TCP as a transport-layer protocol and various buffers in content delivery networks, which is undesirable for applications like gaming and betting.
Innovation Solution
A content streaming system with two delivery paths: a first path using RTP and UDP for live content transmission through fanout nodes to reduce latency, and a second path using HTTP or HTTPS for recorded content delivery in response to seek or rewind requests.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If TCP protocol and content delivery network buffers are used for streaming, then reliability and data integrity are improved, but latency increases significantly
Solution Approach 1:
The patent segments the streaming delivery into two distinct paths: a low-latency path using UDP protocol without reordering for live content, and a reliable path using HTTP/HTTPS with buffering for recorded content. This segmentation allows each path to be optimized for its specific purpose, resolving the contradiction between reliability and latency.
Solution Approach 2:
The patent introduces an intermediary mechanism that detects seek/rewind requests and dynamically switches between delivery paths. When a seek request is detected, the system transitions from the UDP-based low-latency path to the HTTP/HTTPS-based reliable path, and vice versa. This intermediary switching mechanism allows the system to maintain reliability when needed while minimizing latency during normal playback.
2Manufacturing precision
If packet reordering is implemented to ensure correct playback sequence, then content accuracy is improved, but latency and buffering requirements increase
Solution Approach 1:
The patent segments the delivery path to separate packet reordering functionality from the main transmission path. The UDP-based path delivers packets without reordering for immediate playback, while a separate mechanism handles reordering only when switching to recorded content via HTTP/HTTPS. This eliminates the need for continuous buffering and reordering in the low-latency path.
Solution Approach 2:
Instead of the conventional approach of always reordering packets to ensure correctness, the patent inverts the approach by delivering packets in received order via UDP for live content, and only applies reordering when switching to recorded content. This inversion eliminates unnecessary buffering delay for the time-critical live streaming portion.
3Reliability
If HTTP/HTTPS protocol is used for content delivery, then reliability is improved, but latency increases making it unsuitable for live content
Solution Approach 1:
The patent segments content delivery into two protocol-based paths: UDP for live content where speed is critical, and HTTP/HTTPS for recorded content where reliability is paramount. This segmentation allows each protocol to be used in its optimal context, with UDP providing fast delivery for live streams and HTTP/HTTPS providing reliable delivery for on-demand content.
Solution Approach 2:
The patent implements dynamic protocol selection based on the type of content being delivered and user actions. The system dynamically switches between UDP and HTTP/HTTPS protocols depending on whether live or recorded content is being streamed, and whether seek/rewind requests are detected. This dynamic adaptation allows the system to optimize for speed when using UDP while maintaining reliability when using HTTP/HTTPS.
Data Source
AI summary
Disclosed are systems, methods, and devices transmitting live content. There is provided a first delivery path for streaming live content data, without packet reordering, to a player device, and a second delivery path for streaming recorded content data to the player, wherein the system is configured to transition from the first delivery path to the second delivery path in response to a seek and/or rewind request from the player device.