To reduce latency in our live HLS service, we are experimenting with short segment durations (1–2 seconds). We have noticed that ABR switching occurs more frequently than expected.
Looking at the console logs, variants appear to enter and leave what is referred to as a "penalty box" under conditions such as -12889 (a segment returning 0 bytes after 1.0 × target_duration) and -12888 (a playlist remaining unchanged beyond 1.5 × target_duration).
Are there recommended practices to reduce this excessive switching? Specifically:
- Is there an API to control this penalty box behavior?
- Would preparing an LL-HLS stream with 1-second parts settle this down?
- Alternatively, would 4-second segments with a slightly smaller
configuredTimeOffsetFromLivehelp stabilize this?
There's no API to control the error-handling behavior you're observing.
The error descriptions are accurate for the error codes. -12889 is indicative of slow/no response for a media segment request. -12888 errors could be due to a stale CDN cache.
LL-HLS may be suitable depending on how close you want the playhead to be to the live-edge. A target duration of 2s is about as low as we'd recommend for regular latency live content.
Note that solely adopting LL-HLS may not solve the above errors if they are due to infrastructure issues.
Longer segments typically move the playhead further away from the live edge. A target duration of 4s and configuredTimeOffsetFromLive is unlikely to deliver the desired experience.
You're always welcome to file a ticket via Feedback Assistant. A sysdiagnose and network trace captured with a tool like Charles Proxy gives valuable context.