Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stuck outside availabilityWindow after rapid bandwidth drop #1723

Closed
mr-tichyt opened this issue Dec 10, 2018 · 1 comment
Closed

Stuck outside availabilityWindow after rapid bandwidth drop #1723

mr-tichyt opened this issue Dec 10, 2018 · 1 comment
Labels
flag: good first issue This might be a relatively easy issue; good for new contributors flag: seeking PR We are actively seeking PRs for this; we do not currently expect the core team will resolve this status: archived Archived and locked; will not be updated type: enhancement New feature or request
Milestone

Comments

@mr-tichyt
Copy link
Contributor

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

What version of Shaka Player are you using?: 2.4.4 and also latest (2.5.0-beta)

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

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

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?: not related, all of them

What are the manifest and license server URIs?: private, but not relevant

What did you do?
We use Shaka Player for DASH casting on devices similar to Chromecast that are using WiFi. We found that when the connection is not very stable and the DASH segments are larger (4-8s), rapid drop of bandwidth will easily push the currentTime out of the availablityWindow during live playback. After that, the player tries to jump forward (lib/media/playhead.js:onPollWindow_), but the destination where it tries to jump is very close to the edge of the availabilityWindow (exactly: rebufferingGoal + 5 seconds (constant)). We use rebufferingGoal 2 seconds, so that gives the player 7 seconds before it fall out again.

What did you expect to happen?
When the bandwidth gets higher than the bitrate of the stream, it should come back from buffering after a while.

What actually happened?
When the bandwidth is still pretty low, but gets actually higher then the bitrate of the stream, but just slightly, it will never get out of buffering or it will take like 15 minutes, even though the same adaptation set can be played with the same bandwidth with no problems (like using the low bandwidth from the beginning).

We can change the destination of the jump by increasing the rebufferingGoal, but that is not what we want (longer zapping).

Would it be possible to jump further from the availabilityWindow edge or have some settings parameter for it?

Thank you very much.
Best regards,
Tomas

@joeyparrish
Copy link
Member

Thanks for the report. I think it should be fairly easy to add a setting for this, so that you can jump further ahead, either in all cases or by configuring this only on platforms that need it.

I'm putting the "help wanted" label on it to signal that we'd be very happy to take a PR for this. If you decide to work on a PR, this setting should go in shaka.extern.StreamingConfiguration in externs/shaka/player.js. Be sure to add it both to the @property docs and the @typedef. We used to have a linter that looked out for this, but it's currently broken. Thanks!

@joeyparrish joeyparrish added type: enhancement New feature or request flag: seeking PR We are actively seeking PRs for this; we do not currently expect the core team will resolve this flag: good first issue This might be a relatively easy issue; good for new contributors and removed needs triage labels Dec 10, 2018
@shaka-bot shaka-bot added this to the Backlog milestone Dec 10, 2018
mr-tichyt pushed a commit to mr-tichyt/shaka-player that referenced this issue Dec 11, 2018
mr-tichyt pushed a commit to mr-tichyt/shaka-player that referenced this issue Dec 11, 2018
@joeyparrish joeyparrish modified the milestones: Backlog, v2.5 Dec 13, 2018
mr-tichyt pushed a commit to mr-tichyt/shaka-player that referenced this issue Dec 14, 2018
@shaka-project shaka-project locked and limited conversation to collaborators Feb 12, 2019
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
flag: good first issue This might be a relatively easy issue; good for new contributors flag: seeking PR We are actively seeking PRs for this; we do not currently expect the core team will resolve this status: archived Archived and locked; will not be updated type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants