Adaptive streaming (ABR)

ABR keeps video smooth even when the network goes up and down. The player chooses the right quality every few seconds: if bandwidth dips, it steps down to avoid stalls; when the network improves, it steps back up. On AIOZ Stream, these choices balance perceived quality (VMAF — Video Multi-Method Assessment Fusion) with rebuffer penalties and add stabilizers like hysteresis and minimum dwell time. The result is fewer glitches, steadier quality, and Quality of Experience (QoE).

What is ABR?

Adaptive Bitrate (ABR) is a way to stream video with multiple quality levels so playback stays smooth on real networks. The player watches your current bandwidth, device, and buffer level, then picks the most suitable quality for each segment. In short: fewer stalls, steadier quality, and a better viewing experience.

How ABR works

1. Encode → Ladder: Transcode one source into multiple renditions (e.g., 240p→1080p; different bitrates/codecs).
2. Package → Segments/Manifests: Produce HLS/DASH playlists (e.g., M3U8) with chunked segments.
3. Deliver → Edge/DePIN: Serve via AIOZ’s decentralized edge for lower latency and cost.
4. Play → Observe: The player measures throughput, buffer, dropped frames, and device constraints.
5. Decide → Switch: A QoE‑aware algorithm picks the next segment’s rendition, trading off quality vs stall risk.
6. Learn → Telemetry: Player emits events; analytics aggregates session KPIs.

For example:

A viewer starts at 720p. When bandwidth drops near 1.2 Mbps, the player steps to 480p to avoid a stall. As the buffer recovers and throughput rises, it climbs back to 720p. Stabilizers like hysteresis and minimum dwell time keep it from bouncing up and down

AIOZ Stream’s ABR & QoE approach

AIOZ Stream’s ABR decisions are QoE‑aware:

• Perceived quality signals: rendition deltas by expected VMAF or subjective quality.
• Stall penalties: prioritize no rebuffer; account for startup and mid‑playback stalls.
• Stability guards:
  • Hysteresis around thresholds to avoid rapid up‑down switches.
  • Minimum dwell time at a rung before allowing another jump.
  • Capped step size under poor networks (e.g., avoid 1080p→360p free‑fall).
• Device‑aware ladders: allow min / max bitrate and resolution caps per device profile such as mobile, TV, low‑power.
• Regional tuning: different default bitrates by market conditions.

What you get?

These choices reduce oscillations, make quality more predictable, and improve session-level satisfaction under fluctuating bandwidth.

See more: QoE metrics, HLS vs WebRTC.

Bitrate ladder: a practical starting point

Use this as a starting point. Final values depend on content complexity, target devices, and regional bandwidth. Always A/B against your catalog.

Tuning tips:

• Keep VMAF deltas between adjacent rungs meaningful so each switch is perceptible.
• Consider content‑aware encoding to lower bitrates on simple scenes.
• For HEVC/AV1 ladders, you can target 20–40% lower bitrates at similar quality, and gate by device support.
• Restrict max rung on constrained devices to reduce waste.

Measuring playback: instrumentation & analytics

Track both stall risk and perceived quality signals. Recommended KPIs below:

• Rebuffer ratio aims < 0.5–1.0% where feasible.
• Startup time to first frame optimize under 2s for short‑form. Slightly higher acceptable for long‑form/TV.
• Average VMAF (or similar) over played segments; monitor variance across devices/regions.
• Time at highest sustainable rung, switch count/oscillation rate, effective bitrate.
• Error rate and AB test flags for ladder trials.

Integrity & attribution hooks

• Playback integrity verification: Emit signed events from player, edge to support transparent accounting and fraud‑resistant payouts.
• Ad yield loop (AVOD): Feed player‑level QoE and engagement into the ad‑selection layer to balance revenue vs experience.
• Region/device analytics: Use cohort dashboards to tune ladders by market and device profile.
• Emit player events like startup, stall start/end, rendition change, and aggregate daily. **See: Player analytics.

HLS vs WebRTC: when to use it

• HLS / LL‑HLS: great for large audiences and predictable cost; latency typically 6–12s.
• WebRTC: ideal for interactive use cases (<2s latency).
• Hybrid: host panel on WebRTC; mirror to HLS for scale. See: HLS vs WebRTC.

Quick start on AIOZ Stream

1. Sign up and get an API key.
2. Upload a short VOD or start a live input.
3. Use the default ladder; enable analytics.
4. Check KPIs → iterate ladder and player caps.

See: Quick Start.

FAQ

How do I choose ladder renditions?

Start with device‑targeted profiles, then ensure each rung delivers a meaningful quality jump. Also, run A/B tests on your actual catalog and adjust by region.

How do I prevent oscillations?

Use hysteresis, require a minimum dwell time at each rung, and limit step size when the network worsens. When in doubt, prefer smooth down‑steps instead of big jumps so the buffer can recover gracefully.

Does ABR work on low bandwidth?

Yes. The player favors stall avoidance first, even if that means staying at lower rungs for a while. Keep audio continuity, and consider content‑aware encoding to keep quality acceptable at low bitrates.

What metrics should I track?

Monitor rebuffer ratio, startup time, average VMAF, time‑at‑highest sustainable rung, and switch count. As a rule of thumb, aim for startup < 2s and rebuffer < 0.5–1% where feasible.

Do you support device‑aware ladders?

Yes. Set min or max bitrate and resolution per device profile and cap the top rung on small screens.