Adaptive Bit Rate Streaming Latency Reduction

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current video content delivery methods using unicast and HTTP Adaptive Streaming (HAS) result in significant end-to-end delays, particularly when viewing live events, due to buffering requirements that increase latency and delay the appearance of content on user screens.

Innovation Solution

A method and client device implementation that measure delivery times of media segments to calculate short-term and long-term network delivery rates, allowing for dynamic adjustment of bit rates to optimize streaming quality and reduce latency by requesting segments at appropriate bit rates based on these estimates.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If data is buffered at the client device before decoding and playback, then continuous play-out is increased (probability of data running out is reduced), but end-to-end delay or latency is increased

Engineering Contradiction:
Improvecontinuous play-outVSAvoidend-to-end delay
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system dynamically adjusts the buffer size based on real-time network conditions and delivery rate estimates. The buffer size is increased when network conditions are poor to ensure continuous playback, and decreased when network conditions are good to reduce latency. This dynamic adaptation allows the system to resolve the contradiction between reliability and time loss by making the buffer size flexible rather than fixed.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The system continuously measures actual delivery rates of video segments and uses this feedback to adjust buffer size and bit rate selection. By monitoring whether segments are delivered faster or slower than expected and using this information to modify playback parameters, the system can maintain continuous playback while minimizing delay through data-driven decision making.

Inventive Principle:
Principle #23Feedback

2Adaptability or versatility

If HTTP Adaptive Streaming is used to deliver video segments at different quality levels, then media quality and timely delivery are optimized, but significant end-to-end delays occur causing content to appear on user screen a significant time after the actual event

Engineering Contradiction:
Improvemedia quality adaptationVSAvoidend-to-end delay
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The system performs preliminary measurement of delivery rates for video segments before finalizing bit rate selection. By measuring actual delivery performance in advance and using this information to predict future delivery characteristics, the system can make more accurate bit rate decisions that balance quality and latency, avoiding the delays associated with conservative quality selection.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system changes the parameter of buffer size dynamically based on measured delivery rates. When delivery rates indicate that higher bit rates can be delivered reliably, the system increases buffer size to allow smoother playback at higher quality. When delivery rates are poor, the system decreases buffer size to reduce the delay between content generation and display, thus resolving the contradiction between adaptability and time loss.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS12096089B2Adaptive bit rate streaming
Publication Date: 2024.09.17 BRITISH TELECOM PLC
  • US12096089B2 patent drawing
  • US12096089B2 patent drawing

AI summary

Described is a method of media content delivery, where measurements of network delivery rates are used to determine at which bit rate to request each content segment. The aim is to ensure continuous play-out of good quality segments, without relying on a large buffer, so that end-to-end delay is kept low. The historical network delivery rate is measured on two or more timescales, such as a short-term delivery rate and a long-term delivery rate, and these are used to decide when to request a higher bit rate segment than the previous segment, and when to request a lower bit rate segment than the previous segment.