Fixing the "Auto" Quality Logic

[sskwhiteshadow 6]

Improvement ideas on a very broke auto quality settings

1. Shift from "Start-up Probe" to "Buffer-Health" Monitoring

Currently, Emby often makes a quality decision based on a quick speed test at the very beginning of a stream.

• The Problem: If that 1-second window has a minor latency spike, the server locks the user into a low-bitrate "safe" mode for the whole movie.

• The Fix: Implement Adaptive Bitrate (ABR) based on the client's actual buffer. The player should look at how many seconds of video are currently "buffered." If the buffer is full (e.g., 30 seconds), it should automatically request a higher bitrate chunk. If the buffer drops below 5 seconds, it drops the quality.

2. "Upward Mobility" Logic

In its current state, Emby is very aggressive at dropping quality when it detects a bottleneck but almost never tries to "step back up" once the bottleneck clears.

• The Fix: The code needs a "Recovery" loop. Every 60 seconds, the client should attempt to fetch a single high-quality segment. If that segment downloads within a specific time threshold, the entire stream should scale back up to that quality level.

3. Modernizing the FFmpeg Core

Emby’s transcode logic often inflates bitrates when converting from H.265 (HEVC) to H.264 because it uses older encoding presets to save CPU cycles.

• The Fix: Update to the latest FFmpeg libraries and implement CRF (Constant Rate Factor) encoding for "Auto" transcodes. This ensures the bitrates stay lean while maintaining visual quality, preventing the "death loop" where high bitrates cause the very buffering the software is trying to avoid.

[yocker 1582]

4 hours ago, sskwhiteshadow said:

Improvement ideas on a very broke auto quality settings

1. Shift from "Start-up Probe" to "Buffer-Health" Monitoring

Currently, Emby often makes a quality decision based on a quick speed test at the very beginning of a stream.

• The Problem: If that 1-second window has a minor latency spike, the server locks the user into a low-bitrate "safe" mode for the whole movie.

• The Fix: Implement Adaptive Bitrate (ABR) based on the client's actual buffer. The player should look at how many seconds of video are currently "buffered." If the buffer is full (e.g., 30 seconds), it should automatically request a higher bitrate chunk. If the buffer drops below 5 seconds, it drops the quality.

2. "Upward Mobility" Logic

In its current state, Emby is very aggressive at dropping quality when it detects a bottleneck but almost never tries to "step back up" once the bottleneck clears.

• The Fix: The code needs a "Recovery" loop. Every 60 seconds, the client should attempt to fetch a single high-quality segment. If that segment downloads within a specific time threshold, the entire stream should scale back up to that quality level.

3. Modernizing the FFmpeg Core

Emby’s transcode logic often inflates bitrates when converting from H.265 (HEVC) to H.264 because it uses older encoding presets to save CPU cycles.

• The Fix: Update to the latest FFmpeg libraries and implement CRF (Constant Rate Factor) encoding for "Auto" transcodes. This ensures the bitrates stay lean while maintaining visual quality, preventing the "death loop" where high bitrates cause the very buffering the software is trying to avoid.

Didn't Plex implement something similar that they never got working as intended?

Genuine question as i have never really followed Plex.  

[sskwhiteshadow 6]

I dont think they did. 

I would love they move to a HLS/DASH similar to what everyone else uses (netflix, youtube, disney) 


 

1. Shift from "Start-up Probe" to "Buffer-Health" Monitoring

Currently, servers often make a quality decision based on a single speed test at the very beginning of a stream.

• The Problem: A 1-second latency spike at the start of a stream locks the user into a low-bitrate "safe" mode for the entire duration, even if the network stabilizes immediately after.

• The Fix: Implement Continuous Buffer-Health Monitoring. The client should report its "seconds of video buffered" to the server.

  Logic: If the buffer is healthy (e.g., >30 seconds), the server maintains or increases quality. If the buffer drops below a critical threshold (e.g., <10 seconds), the server requests a lower-bitrate segment.

2. Implementing "Upward Mobility" Logic

Private media servers are traditionally aggressive at dropping quality but almost never try to "step back up" once a bottleneck clears.

• The Problem: A temporary network hiccup results in a permanent 720p stream for a user who has a 4K-capable connection.

• The Fix: A "Recovery Loop" must be implemented.

  Logic: Every 60 seconds, the client should attempt to fetch a single high-quality "probe segment." If that segment downloads within a specific time threshold (e.g., in less than 50% of its own playback time), the client signals the server to scale the entire stream back up to the higher quality tier.

3. Quality-Based Encoding (CRF) vs. Static Bitrates

Many transcode engines use older encoding presets that prioritize hitting a specific bitrate number over actual visual quality, often leading to "bitrate bloat" or unnecessary buffering.

• The Problem: High-motion scenes look like garbage at low bitrates, while static scenes waste bandwidth by over-allocating bits.

• The Fix: Implement CRF (Constant Rate Factor) for auto-transcodes.

  Logic: Instead of telling FFmpeg to hit "4 Mbps," tell it to maintain a "Perceived Quality Level" (e.g., CRF 23). This allows the bitrate to fluctuate naturally—dropping during simple scenes to save bandwidth and peaking only when the visual complexity requires it. This prevents the "death loop" where high bitrates cause the very buffering the software is trying to avoid.
   

Feature	Legacy Logic	Proposed Logic
Initial Decision	Start-up Bandwidth Probe	Buffer-Depth Analysis
Recovery	Manual Only	Automatic "Probe" Segments
Rate Control	CBR/VBR (Bitrate Targets)	CRF (Quality Targets)
Jitter Handling	Aggressive Down-stepping	Rolling Average Smoothing

Edited May 14 by sskwhiteshadow