Bandwidth estimate lost between loads

[ericmatthys]

Have you read the FAQ and checked for duplicate open issues?: Yes

What version of Shaka Player are you using?: 2.3.3

Can you reproduce the issue with our latest release version?: Yes

Can you reproduce the issue with the latest code from master?: Not sure

Are you using the demo app or your own custom app?: Custom

If custom app, can you reproduce the issue using our demo app?: Yes

What browser and OS are you using?: Chrome, macOS High Sierra

What are the manifest and license server URIs?:
(NOTE: you can send the URIs to shaka-player-issues@google.com instead, but please use GitHub and the template for the rest)
(NOTE: a copy of the manifest text or an attached manifest will not be enough to reproduce your issue, and we will ask you to send a URI instead)

https://news-video-stream.plex.tv/6dbdaab270debb3f452c1c12763d93ff/video.mpd
https://news-video-stream.plex.tv/ccbc59240fca593594456f1fe3f3b3c4/video.mpd

What did you do?

I've tried increasing defaultBandwidthEstimate to choose a higher quality default variant. I've tried decreasing bufferingGoal to force switches to different qualities to happen sooner.

What did you expect to happen?

I'd expect the bandwidth estimates to more closely reflect the performance that I am seeing with abr disabled. I am not sure why bandwidth estimates are coming back low when I am able to easily play the highest quality streams.

What actually happened?

Low initial bandwidth estimates will cause the stream to switch to a lower quality after first selecting a variant based on defaultBandwidthEstimate.

With abr.enabled set to false, the highest quality variants will play without issue and the buffer can easily outpace the playhead. However, with abr enabled, bandwidth estimates that are calculated will end up causing lower quality streams to be played than what the player seems capable of.

Often times, I'll see bandwidth estimates increase over the course of the video and higher quality variants will gradually be selected over the first minute or so.

I know there's a lot of variability in these situations, but I'd like to better understand what I can do to diagnose this.

[ismena]

Hi @ericmatthys, thanks for the report.

Any chance you were increasing defaultBandwidthEstimate before the call to player.load()?
If that's the case, the new value got overridden by the default value.
(We can discuss changing that logic, but I want to make sure there isn't a bigger problem here first).

If you configure defaultBandwidthEstimate to a higher value after loading the manifest, the abr should respect the new value and choose a higher resolution variant.

Please let me know if that's happening for you and then we can discuss further.

[ericmatthys]

defaultBandwidthEstimate is working correctly. It will allow a higher quality stream to be selected by default. I'm experiencing issues with actual bandwidth estimates seemingly more conservative than necessary. I know this is not very empirical, but bandwidth estimates with abr seem to select stream qualities below what is possible with abr disabled. I'm able to easily buffer ahead with the highest quality stream and abr disabled, but the calculated bandwidth estimates end up choosing a lower quality stream when abr is enabled. Often, bandwidth estimates gradually increase throughout the video. Let me know what I can do to help, as I'm not giving you much actionable data here.

[ismena]

Okay, let's see if I understand the issue correctly: when abr is enabled it first starts from the default value that's lower than what your network speed can allow which causes a lower resolution variant to be selected. It gradually catches up, but not soon enough. Is that right?

If that's the case, you could try tweaking player.config.abr.switchInterval and player.config.abr.bandwidthUpgradeTarget. Here's the description of what they do from externs/shaka/player.js:

`

• @Property {number} switchInterval
• The minimum amount of time that must pass between switches, in
• seconds. This keeps us from changing too often and annoying the user.
• @Property {number} bandwidthUpgradeTarget
• The fraction of the estimated bandwidth which we should try to use when
• upgrading.
  `

Abr always starts from the defaultBandwidthEstimate gradually working it's way towards the actual bandwidth. Decreasing switchInterval will allow switches to occur more often thus catching up sooner and increasing bandwidthUpgradeTarget will make jumps more rapid.

[ericmatthys]

Mostly, although the default estimate is mostly irrelevant to the problem. Let's say I configure a very high default estimate. It'll start at the highest quality stream. The initial bandwidth estimate that comes back after the minimum total bytes required for an estimate is met is lower than what my network speed should allow, forcing a switch to a lower quality. From there, it's usually a slow rise back up to a higher quality as the bandwidth estimates increase. This is frustrating because my network could have easily played the highest quality stream, so the estimates seem wrong or overly conservative.

I'll give the switchInterval and bandwidthUpgradeTarget configuration changes a try.

[joeyparrish]

If you find that the estimated bandwidth is lower than what your network can technically support, this is actually normal and expected.

There are many reasons why a 10Mbit connection does not achieve a full 10Mbit in practice, and they are difficult to predict or model in advance. Our estimate is based on our actual throughput, which means our estimate accounts for these things naturally: WiFi connection quality/stability, throughput to the actual server hosting the segments, and even latency introduced by our own one-at-a-time way of streaming segments. (Shaka Player would be more efficient at consuming available bandwidth if we overlapped the beginning of a request with the end of the previous request. For complexity reasons, we don't do this.)

It's always possible that we're doing something wrong, or that our estimate could be better. Let us know how those config changes work for you.

[ericmatthys]

Thanks for the input! I'm not trying to compare the bandwidth estimate with my download speed. I'm just comparing my experience with abr enabled compared to abr disabled. I get smooth playback with no buffering and fairly quick start times using the highest quality stream with abr disabled, so it seems unexpected for abr to choose lower quality streams. I know that's not very scientific though. I'll play with the configuration more and let you know.

[joeyparrish]

Ah, I see! Then the configurations are definitely for you. We have conservative default settings, and we try not to use more than a certain percentage of what we think your bandwidth is. You can raise that percentage.

[ericmatthys]

I played with those configuration options and I think the effect is too subtle to make an impact on my scenario. Here are some (cleaned) logs showing the issue:

(video:4) startup complete
Load latency: 3.613
canSwitch_
Calling switch_(), bandwidth=1932 kbps
switch: switching to Stream (video:6)
Calling switch_(), bandwidth=2730 kbps
switch: switching to Stream (video:5)
Calling switch_(), bandwidth=3196 kbps
switch: switching to Stream (video:4)
Calling switch_(), bandwidth=3988 kbps
switch: Stream (video:4) already active
Calling switch_(), bandwidth=4503 kbps
switch: switching to Stream (video:3)
Calling switch_(), bandwidth=5893 kbps
switch: Stream (video:3) already active
Calling switch_(), bandwidth=5552 kbps
switch: Stream (video:3) already active
Calling switch_(), bandwidth=6057 kbps
switch: Stream (video:3) already active
Calling switch_(), bandwidth=6602 kbps
switch: Stream (video:3) already active
Calling switch_(), bandwidth=5856 kbps
switch: Stream (video:3) already active
Calling switch_(), bandwidth=7081 kbps
switch: Stream (video:3) already active
Calling switch_(), bandwidth=8226 kbps
switch: Stream (video:3) already active
Calling switch_(), bandwidth=7945 kbps
switch: Stream (video:3) already active
Calling switch_(), bandwidth=8189 kbps

Lower video indices are higher qualities, so 3 is high and 6 is low. You can see the default estimate starts with video 4. The initial estimate comes back and it drops to 6. Then one by one, it increases quality until it sits at video 3.

Compounding the problem, I think load will start with fresh estimates each time, so after that video completes or is skipped, the next video will not use any of the previous bandwidth knowledge. This means that the next video starts this climb all over again. With abr disabled or when forcing artificially high estimates from the estimator, there are no problems with buffering.

I've tried two things to counteract this: (1) listen to the adaptation event and use player.getStats().estimatedBandwidth to keep track of these estimates and store them per hostname. When another video is played, if there is already a known estimate from a previous playback, it will use that as defaultBandwidthEstimate. (2) I've increased the minTotalBytes_ property in the estimator that is required for calculated estimates to be used instead of the default estimate. This at least gives the estimator more time before it attempts a switch. Obviously the latter isn't ideal since I don't think there's an official configuration option for changing that.

[ismena]

@ericmatthys I'm sorry, it seems we've lost track of this issue. :(
Do I understand correctly that the experience mentioned above was after you set the defaultBandwidthEstimate to a higher value?

@TheModMaker could I bring you into this? I'm a bit puzzled by why our bandwidth estimate drops initially if defaultBandwidthEstimate has been configured. Do you think we might be doing something wrong?

[ericmatthys]

@ismena No worries. Yes, that is with a higher defaultBandwidthEstimate.

[TheModMaker]

We used to keep bandwidth estimates between loads, but some change broke that. We should be keeping bandwidth estimates. Also, we don't use the defaultBandwidthEstimate to seed the estimator, we only use it to select the first streams. So once we have a "good" estimate, we will use that, which always starts out small.

I notice that on my network the estimate starts off extremely small despite downloading every segment quickly. Maybe the starting 0 value is affecting the average for a while?

[joeyparrish]

Fix cherry-picked to v2.4.5.