HLS ladder has a bitrate inversion
A lower-resolution variant is allocated more bandwidth than a higher-resolution one, so adaptive switching picks the wrong rendition.
What it means
Two variants in your master playlist are ordered inconsistently: one with fewer pixels declares a higher BANDWIDTH than one with more. For example a 640x360 rung at 3 Mbps sitting alongside a 1280x720 rung at 1 Mbps.
Why it matters
ABR logic selects on bandwidth. When the ladder is inverted, a player with plenty of bandwidth can select the inverted low-resolution rung and stay there, so viewers on fast connections watch a soft picture while paying for more bits than the sharp rendition would cost. It also makes the ladder non-monotonic, which some players handle by refusing to switch at all.
How to fix it
- Re-encode so that bitrate rises monotonically with resolution across the ladder.
- If a rung is genuinely meant to be high-bitrate at low resolution (a high-motion or high-frame-rate variant), give it its own resolution tier rather than colliding with an existing one.
- Check that BANDWIDTH reflects the real peak of each rendition — a stale hand-written value is a common cause.
Check your own stream
The free HLS analyzer runs this check on every analysis and links each finding straight back here.
Open the HLS analyzer →Frequently asked questions
- What does "HLS ladder has a bitrate inversion" mean?
- Two variants in your master playlist are ordered inconsistently: one with fewer pixels declares a higher BANDWIDTH than one with more. For example a 640x360 rung at 3 Mbps sitting alongside a 1280x720 rung at 1 Mbps.
- Why does it matter?
- ABR logic selects on bandwidth. When the ladder is inverted, a player with plenty of bandwidth can select the inverted low-resolution rung and stay there, so viewers on fast connections watch a soft picture while paying for more bits than the sharp rendition would cost. It also makes the ladder non-monotonic, which some players handle by refusing to switch at all.
- How do I fix it?
- 1. Re-encode so that bitrate rises monotonically with resolution across the ladder. 2. If a rung is genuinely meant to be high-bitrate at low resolution (a high-motion or high-frame-rate variant), give it its own resolution tier rather than colliding with an existing one. 3. Check that BANDWIDTH reflects the real peak of each rendition — a stale hand-written value is a common cause.
- How can I detect this automatically?
- Paste your HLS streaming URL into StreamTest's free HLS analyzer. It runs this check on every analysis, flags the finding, and links straight back to this page — no sign-up required.
Related HLS checks
- HLS variant is missing the CODECS attributeWithout CODECS, players must download a segment before they can tell whether they can play the rendition at all.
- HLS variant references an undeclared rendition groupA variant points at an AUDIO or SUBTITLES group that has no matching EXT-X-MEDIA entry, which breaks playback on strict players.
- HLS segment is longer than EXT-X-TARGETDURATIONA segment rounds to more than the declared target duration, which violates the HLS specification.
- HLS live window is shorter than three target durationsThe playlist holds too little content, so any player that falls slightly behind runs off the end of the window.
- HLS playlist has no EXT-X-PROGRAM-DATE-TIMEWithout program date-time the stream cannot be mapped to wall-clock time, which breaks DVR seeking and multi-stream alignment.
- HLS live edge has drifted from wall-clock timeThe newest segment’s program date-time is far from the current time, meaning the playlist is stale or the clocks disagree.