Stuck outside availabilityWindow after rapid bandwidth drop #1723
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
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
?: yesAre 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
The text was updated successfully, but these errors were encountered: