-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
There should not be a gap in text references >1s error #1562
Comments
I managed to reproduce using the latest code in Full repro steps I came up with:
Also reproduces in v2.4.4, v2.3.10, but not in v2.2.10. |
When the assertion is triggered, the value of This offset value seems to come from this part of the manifest: <Representation id="0" bandwidth="1148" codecs="wvtt" mimeType="application/mp4">
<SegmentTemplate timescale="1000" presentationTimeOffset="57486242"
initialization="--redacted--.mp4" media="--redacted--_$Number$.m4s"
startNumber="1">
<SegmentTimeline>
<S t="57481600" d="3200" r="768"/>
</SegmentTimeline> According to the manifest, it was generated by Shaka Packager version |
This change in the Player seems to cause the issue: c38d4dd Affected versions: v2.3.10, v2.4.2-v2.4.4, v2.5.0-beta |
The only difference in my fork was actually suggested by @kqyang himself and should not cause any of this I believe. The change is only about reading the subtitle file indefinitely while packaging live content. As this is VOD, it should not be affected at all. |
I found the cause in Shaka Player, and it should be easy to fix. Thanks for reporting this! |
Thank you, working perfectly! |
Happy to help! |
This reverts commit c38d4dd, which actually broke text range calculations in v2.3.10, and v2.4.2-v2.4.4. The original commit was meant to account for the period start, but resulted in a double-accounting of presentationTimeOffset. The start and ends times passed into TextEngine's appendBuffer were period-relative, so timestampOffset had already been applied. To avoid further confusion and to fix the original issue the reverted commit tried to address, these have been changed to presentation-relative timestamps. Now the period start and all offsets have been accounted for before the metadata reaches MediaSourceEngine and TextEngine. The tests added in the bad commit have been modified to test for the opposite: that we do not erroneously account for timestamp offset when calculating the buffered ranges for text. Backported to v2.4.x Closes #1562 Change-Id: I9fa7a3f59906c4f3e623f411e48551f86f5c2ff7
Fix cherry-picked to v2.4.5. |
Have you read the FAQ and checked for duplicate open issues?:
yes
What version of Shaka Player are you using?:
2.5.0 -- [JP: assumed to be 2.5.0-beta, which is the latest release as of today]
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?:
both
If custom app, can you reproduce the issue using our demo app?:
yes
What browser and OS are you using?:
mac os & chrome
What are the manifest and license server URIs?:
https://goo.gl/MDjuDA
What did you do?
I tried to play the VOD with enabled subtitles.
What did you expect to happen?
To have a smooth playback
What actually happened?
The playback starts fine but if seek to middle, it stops and keeps spamming the console with Assertion failed: There should not be a gap in text references >1s. I checked the MPD and did not see any gaps in the segment template.
This content was produced with shaka-packager. Please note that this content even with subtitles enabled is playable with dashjs and on android with exoplayer. Is this an issue with the packaged content or with shaka player?
Thank you
Jakub
The text was updated successfully, but these errors were encountered: