Codec and frame-rate switches inside the ladder: why the join stalls
A ladder that uses HEVC for 4K and H.264 below it, or ads encoded at a different frame rate from the programme, forces the decoder to tear down and start again at every boundary. On a television that shows up as a stall or a black frame.
How mixed ladders come about
It is a natural outcome of adding 4K later. The original ladder was H.264 because everything decodes it; the 4K rung was added in HEVC because H.264 at that resolution is wasteful and many devices cap H.264 at Level 4.2 anyway. Frame rates drift the same way: film content at 24 or 25 fps, sport at 50 or 60, and ads delivered by an agency at whatever their tooling produced.
Each of those is defensible on its own. The trouble is that adaptive bitrate switching now crosses a codec or frame-rate boundary mid-stream, and so does every ad break.
Why the switch hurts on a television
A hardware decoder is initialised for one codec, one profile and one set of stream parameters. Changing codec means tearing it down and creating a new one, which on TV silicon takes noticeably longer than in a desktop browser. In a Media Source Extensions player the SourceBuffer was created for a specific MIME type and codec string; a method to change it mid-stream exists in current browser engines but is missing or unreliable on many television runtimes, leaving the player to recreate the buffer and lose what it held.
Frame-rate changes add a second problem that has nothing to do with the player. Televisions configured to match output refresh rate to content re-negotiate the HDMI or panel mode when the frame rate changes, and that produces a black screen for a second or two at exactly the ad boundary. Timestamp discontinuities at the join make the stall longer still.
- Decoder teardown and reinitialisation at every codec-family switch.
- SourceBuffer recreation on players without reliable mid-stream codec changes.
- Display mode re-sync when frame rate changes between content and ads.
- ABR oscillating across the codec boundary because the rungs are close in bitrate.
Building a ladder that does not do this
The simplest fix is one codec family per ladder: an H.264 ladder that stops at 1080p, and a separate HEVC ladder including 4K, with the player choosing one ladder at startup based on device capability and never crossing between them. In DASH that is expressed as separate adaptation sets; in HLS as variant streams the player filters by codec before it starts. Frame rate should be constant across every rung of a ladder.
Ads should be transcoded to match the content they will play against - same codec, same frame rate, same resolution tier, keyframe-aligned - which is the step most often skipped. Server-side ad insertion makes that a hard requirement rather than a hope, because the stitched stream has to be continuous. Where a client-side transition cannot be avoided, the player needs a deliberate reinitialisation path and gap-jumping logic at the boundary rather than waiting for the pipeline to recover on its own.