Description
Have you read the FAQ and checked for duplicate open issues?
Yes, no open issues, but related issues: #8672 and #8481
If the problem is related to FairPlay, have you read the tutorial?
N/A
What version of Shaka Player are you using?
4.15.3
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?
Custom app
If custom app, can you reproduce the issue using our demo app?
Yes (with custom content)
What browser and OS are you using?
Chrome 137, MacOS
For embedded devices (smart TVs, etc.), what model and firmware version are you using?
N/A
What are the manifest and license server URIs?
Emailed to [email protected]
What configuration are you using? What is the output of player.getNonDefaultConfiguration()?
Default
What did you do?
Play a DASH stream where the last segments (audio, video, text track/ttml) have differend end times.
What did you expect to happen?
End stream when there's nothing left to play
What actually happened?
Infinite buffering.
periodEnd = 6287.239291
Last segment of ttml:
segmentEnd 6264.916
Last segment of audio:
segmentEnd 6280.244
Last segment of video:
segmentEnd 6287.239291666667
So for both audio and ttml segment it hits the logic introduced in this PR, because the difference is larger than 0.1.
This then causes the player to buffer.
I'm not sure whether this is a content issue or not, but I can imagine it's quite common to have streams where the end time of the last segment of audio/video/text doesn't necessarily match.
Are you planning to send a PR to fix it?
No, I've tried in #8762 but unfortunately I can't figure it out.