Fixing the "Auto" Quality Logic

[sskwhiteshadow 2]

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.