Adaptive bitrate check for app version 3.57, streamed playback only, over 7 days (21–28 Jul 2026). ABR is working on both video and audio: delivered bitrate is spread across the full ladder and rebuffering is effectively zero. The one thing that stands out — half of audio playback sits below 64 kbps — is explained by radio, which is low-bitrate by design, not by ABR being held down.
Context
Data pulled via analytics-mcp (license default-license), filtered to custom_data_5 = "3.57" (app version) and custom_data_4 = "streamed" (excludes downloaded playback), then split by custom_data_2 into audio vs video. Distributions are built from sample counts bucketed by bitrate range — i.e. share of actual playback time at each rung — because the API exposes video_bitrate only as an average and does not support grouping by raw bitrate. See [[analytics-overview]] for the integration model and [[params-enrichment-plan]] for the custom_data definitions this analysis relies on.
How it works
Does ABR work? Yes. Two signals together confirm it: delivered bitrate is genuinely spread across the whole ladder rather than pinned to one rung, and rebuffering is near-zero — the player is pushing quality as high as the network allows and backing off cleanly before the buffer empties. Serving high bitrates with effectively no stalling is the standard signature of healthy ABR.
| Content | Avg rebuffer % | Read |
|---|---|---|
| Video | 0.0020% | essentially no stalling |
| Audio | 0.0032% | essentially no stalling |
Video bitrate ranking (streamed video, 551,103 samples; avg 5.35 Mbps):
| Rank | Bitrate band | Share of playback time |
|---|---|---|
| 1 | 4–8 Mbps | 33.0% |
| 2 | 2–4 Mbps | 24.1% |
| 3 | ≥8 Mbps | 22.8% |
| 4 | 1–2 Mbps | 15.0% |
| 5 | 0.5–1 Mbps | 3.5% |
| 6 | <0.5 Mbps | 1.5% |
About 80% of video viewing happens at 2 Mbps or above and 56% at 4 Mbps+, with only 5% dropping to the low rungs (the ABR safety net for weak networks). Healthy shape.
Audio bitrate ranking (streamed audio, 4,456,940 samples with a bitrate):
| Rank | Bitrate band | Share of playback time |
|---|---|---|
| 1 | <64 kbps | 52.5% |
| 2 | 128–256 kbps | 35.9% |
| 3 | ≥256 kbps | 11.5% |
| — | 64–128 kbps | 0.1% (rung barely used) |
Audio switches across at least three distinct rungs with the same near-zero rebuffering, so ABR adapts on audio too.
Android vs iOS (streamed video). Both platforms serve high video bitrate with near-zero rebuffering; the gap is small and Android is actually marginally higher:
| Platform | Plays | Share | Avg video bitrate | Rebuffer % |
|---|---|---|---|---|
| Android | 32,758 | 85.9% | 5.42 Mbps | 0.0021% |
| iOS | 5,387 | 14.1% | 5.01 Mbps | 0.0015% |
Android carries 86% of streamed video volume, so the app-wide 5.35 Mbps average is essentially the Android number. iOS runs 0.4 Mbps lower on average but rebuffers slightly less — a healthy, unremarkable split with no platform disadvantage on delivered quality. (This is a narrower, streamed-video-only cut than the June snapshot in [[qoe-state-2026-06]], where iOS averaged much lower across all content.)
The sub-64 kbps audio is radio, not a quality problem. Isolating genuine sub-64 kbps playback (audio_bitrate between 1 and 63,999 — excluding the 0/unknown-bitrate samples the naive < 64000 filter also catches) shows the band is ~99% radio: 2,321,478 radio samples vs 21,856 podcast and negligible audioseries/audiobook. Radio is continuous low-bitrate audio streamed at a low rung by design — 99.5% of radio playback is below 64 kbps, so it genuinely lives here.
Podcast is not low-bitrate by design: of 2.09M podcast samples with a real bitrate, only 1.0% are sub-64 kbps — the other 99% play at ≥64 kbps (mostly 128 kbps+), which is where real audio ABR is happening. Note that a naive audio_bitrate < 64000 filter also matches samples with no reported bitrate (0/unknown, e.g. startup/untracked), which are disproportionately podcast; always constrain to > 0 when measuring the genuine low band.
Per-title example — Bule Lemah Lembut, Endingnya MAUT (ITWILL)
Drilling into a single asset (video_id 6aca0ddd-4aac-480a-a655-8efc2324e800) shows how per-title encoding shapes the numbers. Its ladder caps around 2–4 Mbps — nothing at 4 Mbps+ — so its average sits well below the app-wide figure (7-day MCP pull, 796 bitrate samples, avg 2.76 Mbps):
| Bitrate band | Share of playback time |
|---|---|
| 2–4 Mbps | 78.0% |
| 0.5–1 Mbps | 17.8% |
| 1–2 Mbps | 4.1% |
| <0.5 Mbps | 0% |
| ≥4 Mbps | 0% |
About 78% of playback is at the asset's top rung and ~18% drops to 0.5–1 Mbps — ABR behaving normally, just on a shorter ladder than higher-resolution titles. The low average is a property of the asset, not an ABR fault.
The Video Bitrate Heatmap. The Bitmovin dashboard also offers a per-title heatmap the analytics-mcp server cannot reproduce (positional data is dashboard-only):
What it is. It shows which quality rung viewers watched at each position along the video's timeline, plus how many were still watching there — answering "where in the video do users sit at low quality, and where do they drop off?" rather than "how did quality change over calendar time." This instance is auto-limited to the last 24 hours (a dashboard restriction), so it reflects only a handful of plays and will not reconcile one-to-one with the 7-day MCP numbers above.
How to read it.
- Top chart (heatmap). X-axis is playback position — time into the video (0:00 → ~7:08), not wall-clock time. Y-axis lists this asset's rungs:
2.16 Mbit/s (608×1080)high and634 kbit/s (242×432)low. A filled block at a position means playback happened at that rung there — at 0:00 viewers are split across both rungs; a high-rung block sits around 1:04. - Right-side bars. Aggregate split of plays across the two rungs: 3 plays (60%) low, 2 plays (40%) high.
- Bottom chart (Engagement). Plays still active at each position — an audience-retention curve. It starts at 3 plays at 0:00, falls to 1 by ~1:04, and reaches 0 shortly after: viewers dropped off within roughly the first minute.
The heatmap is best for spot-checking recent playback of one title; the MCP rung distribution above is the reliable multi-day view.
Related
- [[qoe-state-2026-06]]
- [[analytics-overview]]
- [[params-enrichment-plan]]
- [[overview-and-findings]]