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
Buffering event fired too late #6527
Comments
Do you see the same behavior in Shaka v4.7.x? How about Shaka v4.3.x? I believe something changed regarding how we manage buffering states, though I can't recall in exactly what release branch. |
I downgraded to I suspect the changelog line involved in such change is the one discussed here below, but I'm not sure. Can you confirm it? Anyway, @joeyparrish, do you think the described behavior can be considered as a bug? |
Yes, I think so. That is the exact change I was suspicious of. |
Fixed with #6433 |
Have you read the FAQ and checked for duplicate open issues? Yes
If the problem is related to FairPlay, have you read the tutorial?
What version of Shaka Player are you using?
4.8.1
Can you reproduce the issue with our latest release version?
Yes
Can you reproduce the issue with the latest code from
main
?Not tested
Are you using the demo app or your own custom app?
Custom app
If custom app, can you reproduce the issue using our demo app?
What browser and OS are you using?
Chrome on MacOS 13.6.2 - testing a CTV application on browser
For embedded devices (smart TVs, etc.), what model and firmware version are you using?
What are the manifest and license server URIs?
What configuration are you using? What is the output of
player.getConfiguration()
?Open config
What did you do?
Upgraded from Shaka 3 (latest) to Shaka 4 (latest)
What did you expect to happen?
See Discussion below
What actually happened?
We were upgrading from the latest version of v3 to v4. Everything seems fine but we found out a sort of buffering delay on Live Streaming (DASH) that there wasn't before.
We use
buffering
event to tell the application to show and hide the UI (spinner) usingbuffering: true
orfalse
as the source of thruth.What is weird is that the live content starts to play but the diffence between when the
play
event is fired and when thebuffering
event is fired, can be of over 20 seconds!As per our configuration above, we set a series of configuration parameters.
In order to attempt to reduce the buffering, we started to play with them and found out what follow:
manifest.defaultPresentationDelay
, according to the documentation, has a default value of1.5 * minBufferTime
(which, in our manifests is ofPT10S
=> so it would be of 15s);maxSegmentDuration
isPT4S
;manifest.defaultPresentationDelay
(which is10
right now) below12
(which ismaxSegmentDuration * 3
(why 3?)), the buffering phase acts as described. Over12
, the buffering phase is instant and ends about with theplay
event;manifest.dash.ignoreMinbufferTime: true
and without changing the values above.As we didn't change anything else when moving from Shaka 3 to Shaka 4, what did change in this sense, under the hood? Is such behavior something to be expected?
Here below a redacted manifest of ours on which are able to reproduce the problem.
Were our observation correct? What are we doing wrong?
Can you perhaps provide us some pointers about how to configure correctly the parameters above in relation to our manifests?
Thank you very much!
The text was updated successfully, but these errors were encountered: