steaming.rebufferingGoal is being ignored after v4.6.0

[z-cui-233]

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

If the problem is related to FairPlay, have you read the tutorial?

N/A

What version of Shaka Player are you using?

Nightly

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

Can you reproduce the issue with the latest code from main?
Yes

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

If custom app, can you reproduce the issue using our demo app?
N/A

What browser and OS are you using?
macOS Catalina v10.15.7
Chrome 120.0.6099.216（Official Build） （x86_64）

For embedded devices (smart TVs, etc.), what model and firmware version are you using?
N/A

What are the manifest and license server URIs?

Big Buck Bunny: the Dark Truths of a Video Dev Cartoon (DASH)
https://storage.googleapis.com/shaka-demo-assets/bbb-dark-truths/dash.mpd

What configuration are you using? What is the output of player.getConfiguration()?

The default configuration on shaka demo, with following extra configuration:

{
  "streaming": {
    "rebufferingGoal": 100
  }
}

What did you do?

1. Go to nightly demo - CUSTOM CONTENT
2. Click "+" button. and input

• Manifest URL: https://storage.googleapis.com/shaka-demo-assets/bbb-dark-truths/dash.mpd
• Name: Test
• Extra config

{
  "streaming": {
    "rebufferingGoal": 100
  }
}

3. Save and play.

What did you expect to happen?

By reading this tutorial about rebufferingGoal, I think shaka player should wait for the buffer reaching to 100s to start playing the video. And it actually did if I try it on version 4.5.0 or earlier.

What actually happened?

Video is played without waiting for the rebufferingGoal being achieved.

I'm not very familiar with shaka-player's source code, after a few investigation I feel this change (#5696) might be the root cause. Also I'm not sure if it's an intentional change or a bug.

[Iragne]

if i'm not wrong the rebufferingGoal is only apply with manifest.dash.ignoreMinBufferTime <= true

[z-cui-233]

@Iragne By reading the code(1, 2), I think it only happens when rebufferingGoal is less than minBufferTime. The value of max(config.rebufferingGoal, manifest.minBufferTime) is supposed to be respected when shaka-player handles the play -> pause(for buffering) -> play(after has enough buffer) thing.

[Iragne]

Hum need more attention agree.

[Iragne]

Thanks I clearly found the issue of the rate control and the buffering state.
I'm checking now the impact of it

[Iragne]

here the first proposed solution but still in draft #6433

[joeyparrish]

Fix reverted by #6540, reopening

[Iragne]

@avelad I'm seeing your commit associated to reverting back to the previous code.
This code is not adding any test case for the player integration and i understand it cause the validation issue on Tizen.

Should we work on a more robust test scenario that is not breaking Tizen "sorry for that".

[avelad]

I'm happy to review you PR for it :)

[Iragne]

Well happy to rework on it but happy to make sure i can properly test tizen.
How i should do because Tizen is not part of the ./all.py tests and i don't want to re impact Tizen and CI/CD