google / google/ExoPlayer

DASH Live stream - AdaptiveTrackSelection, DefaultBandwidthMeter, and isTransferAtFullNetworkSpeed

Open
#10,082 5 comments 0 reactions 1 assignee Claimed by @marcbaechinger View on GitHub
needs triage question
Dominant language
Java
Stars
21.9k
Forks
6k
PR merge metrics
No merged PRs in 30d

Description

I am tracking an issue with a DASH live stream where playback starts when the bandwidth is low ~1mbs and recovers over a few minutes but the playback quality doesn't reflect the new bandwidth.

The network recovers by ~1mbs every 30 seconds climbing up to 32mbs

However, the quality of the stream never climbs to its full quality, instead sticks at the lower end ~2mbs

While debugging this I have observed the following.

AdaptiveTrackSlection is using an implementation of a BandwidthMeter that is utilising DefaultBandwithMeter to supply the Bitrate Estimate. However I have noticed that within a short time [isTransferAtFullNetworkSpeed starts returning false and therefore onTransferEnd](https://github.com/google/ExoPlayer/blob/f1b37bc547e7194354fe31e240afa8a8fb0b5c6c/library/core/src/main/java/com/google/android/exoplayer2/upstream/DefaultBandwidthMeter.java#L385) stops monitoring the transfers and the bitrateEstimate sticks at the last value.

isTransferAtFullNetworkSpeed is returning false because the DataSpec has DataSpec.FLAG_MIGHT_NOT_USE_FULL_NETWORK_SPEED set.

The knock on effect of this is that because this bitrate is low, the recovery of the network makes no difference and playback continues at a low quality. Manually the only way to recover it is to stop playback and start it again, or some combination of pause/seek that seems to allow the DataSpec to be reevaluated and for a brief moment the transfer are monitored and allows a new bitrateEstimate to be calculated for a while before the condition because false again and monitoring stops.

If I remove this check playback performs and ladders up and down as expected.

So I'm trying to understand the conditions to how this flag gets set and reset, and if relying on the estimate from DefaultBandwidthMeter is advisable. I feel like I'm missing something important...

Comments in the commit hints at this being for detecting network throttling in order to discard these samples. However I have seen this behaviour on non throttled networks, albeit playback hits full bandwidth but sampling then stops. Trying therefore to understand is this a real issue in a live environment or only occurring because of how out throttling tests are being performed.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.