Bitmovin Player adaptive bitrate streaming guide

Purpose

This page explains:

• The generic ABR model (from Bitmovin official material)

• How ION integrates Bitmovin ABR across platforms

• Which ION configuration keys influence ABR behavior

• What each ABR-related configuration means in simple English

Primary generic ABR reference:

• https://bitmovin.com/blog/adaptive-streaming/

Scope

This document is intentionally focused on ABR behavior and ABR-related integration/configuration in ION using Bitmovin.

ABR in simple terms

Adaptive Bitrate Streaming (ABR) means the player automatically changes video quality while playback is running.

It does this to keep playback smooth when network conditions change.

Instead of one fixed stream, ABR uses multiple renditions (quality levels). The player chooses the best next segment based on:

• Current download speed

• Current buffer health

• Device capability and playback context

Core ABR building blocks

Encoding ladder

The same content is prepared at different bitrates and resolutions:

• Top ladder rungs: higher quality, more bandwidth

• Lower ladder rungs: lower quality, less bandwidth

Segments and manifest

Each rendition is split into short chunks and listed in a manifest.

Common manifest formats:

• HLS: .m3u8

• MPEG-DASH: .mpd

Player adaptation logic

At runtime, the player decides which next segment/rendition to request.

How ION integrates ABR with Bitmovin

Web / Smart TV (Tizen, webOS, browser)

ION uses Bitmovin Web SDK modules including ABR module support and applies adaptation settings during player configuration.

ION also applies resolution capping at runtime (for device caps) and buffer controls from platform configuration.

Android

ION native Android integration uses Bitmovin adaptation callbacks and applies additional quality selection logic that respects display resolution constraints.

For live playback, Android also reads latency/time-shift related values from platform configuration.

iOS / tvOS

ION creates Bitmovin adaptation configuration objects and currently relies mainly on default adaptation behavior unless additional tuning is explicitly added.

Operator configuration – if you change X, what happens?

Base location for most ABR controls:

• videoPlayBack in each client platformconfig.json

Use this section as an operator playbook for configurability.

Key to the following table:

• Yes: configurable by operator

• Not supported: not supported by player, hence not configurable

• No: supported by player but not configurable by operator. Player adapts to optimal behavior.

Platform configuration applicability summary

AdaptationConfigurationType (Web / Smart TV only)

Supported values in current ION path:

• wish

• median

• weightedaverage

Current state in checked client configurations:

• All discovered configs use wish

Operator impact when changed:

• wish:

  • Balanced quality and stability

  • Good default for TV-first services

• weightedaverage:

  • Quality can climb faster when network improves

  • May be less forgiving on unstable networks

• median:

  • More conservative behavior

  • Fewer aggressive quality jumps

  • Usually safer for unstable Wi-Fi / crowded networks

What end users may notice:

• Moving to weightedaverage – faster quality upgrades after startup

• Moving to median – fewer swings, but slower to reach top quality

videoPlayBack.bufferDuration.forwardDuration

What it controls:

• How much video is buffered ahead of current playback

If increased:

• Playback usually feels more stable

• Fewer stalls during short bandwidth drops

• Quality changes can feel slower

If decreased:

• Player reacts faster to network changes

• Higher chance of buffering on weak or spiky networks

videoPlayBack.bufferDuration.backwardDuration

What it controls:

• How much already-played media is kept behind current position

If increased:

• Smoother short backward seeks/rewinds

• Can increase memory usage

If decreased:

• Less memory pressure

• Less comfortable short back-seek behavior

videoPlayBack.bufferDuration.startupThreshold

What it controls:

• How much must be buffered before playback starts (most relevant on Android)

If increased:

• Safer startup with fewer early stalls

• Longer start time before first frame

If decreased:

• Faster startup

• Greater risk of early buffering on weak networks

videoPlayBack.bufferDuration.targetLatency (live, Android)

What it controls:

• Desired delay from the live edge

If decreased:

• Closer-to-live experience

• More sensitive to network instability

If increased:

• More delay from live edge

• Usually smoother and more stable live playback

videoPlayBack.bufferDuration.minTimeShiftBufferDepth (live, Android)

What it controls:

• Minimum depth of live timeshift/DVR buffer

If increased:

• Better cushion for live stability and timeshift

• Can increase latency/memory footprint

If decreased:

• Tighter live window

• Less tolerance for instability

Low-latency and ABR estimation behavior

What it controls:

• Low-latency playback settings for live streams

• How the player estimates bandwidth and chooses quality on Web and Smart TV

Current behavior in ION:

• Android live playback uses targetLatency and minTimeShiftBufferDepth from platform config when they are set.

• Web and Smart TV use Bitmovin ABR adaptation settings from AdaptationConfigurationType.

• There is no separate operator-facing switch for a standalone "buffer estimation algorithm".

If low-latency values are reduced:

• Playback moves closer to the live edge

• The stream becomes more sensitive to weak or unstable networks

If low-latency values are increased:

• Playback stays further behind live

• Live playback is usually smoother and easier to maintain

If ABR estimation is changed from wish to median or weightedaverage:

• Quality changes may become more conservative or more aggressive depending on the profile

• Startup quality, switching speed, and stability can all change

Runtime resolution capping

What it controls:

• The highest video resolution ABR is allowed to select

If cap is lowered:

• Lower data usage and often better stability

• Reduced peak visual quality

If cap is raised:

• Better possible quality on capable devices/networks

• Higher data usage and possible increase in stalls on weak links

Safe rollout steps for operators

1. Change one key at a time.

2. Run A/B or phased rollout by operator profile or region.

3. Watch these metrics: rebuffer ratio, startup time, selected bitrate trend, live latency stability.

4. Roll back quickly if rebuffer ratio worsens.

ABR observability available in ION

ION reports ABR-relevant playback telemetry such as:

• Selected bitrate

• Available bitrate ladder values

• Download bitrate

• Average download bitrate

• Stream bitrate

• Buffered duration

• Dropped frames

Why this matters for operators:

• Helps confirm if adaptation is working as intended

• Helps diagnose complaints like buffering, quality drops, and instability by profile/device/network

Practical operator guidance

For a stable rollout and tuning:

1. Start from known-good defaults for the operator profile you are supporting.

2. Tune one buffer/adaptation dimension at a time.

3. Validate with real telemetry (selected bitrate vs download bitrate vs stalls).

4. Separate tuning strategy by content type:

   • Live sports/news: prioritise stability and controlled latency.

• • VOD premium: prioritise sustained visual quality with a safe buffer.

5. Re-validate across low-end devices and weaker networks before production rollout.