-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Support for negative initial timestamps #3498
Comments
Note that I saw some similarities with #3189 ("DASH VOD manifest with large offset at the start can't be played", still open) and #3451 ("Don't jump over the gap at the beginning before the video is played so that the video poster doesn't disappear", closed), but these are (I think) subtly different issues. |
What I think is happening is the first video segment is being skipped. Because the timestamp is 86400000, but the If you adjust the |
The timing model now requires that
It seems that neither Shaka nor DASH.js have explicit support for |
FWIW that works, obviously (see this link), and it displays But still, reading the MPEG DASH Amendment 5 text (which ended up in in ISO/IEC 23009-1:2019 under "7.2.1 Media Presentation timeline") it seems that the idea is that if 'negative' values are present, initial frames should be decoded and skipped, and should only be shown from the Note that the 'negative' values are really an artifact of how the player handles the timeline, as the actual segments never contain negative timestamps. I.e., the player could also subtract the |
This is already supported using the sequence mode. Can you test with main branch? Thanks! |
Using https://shaka-player-demo.appspot.com/demo/, which I assume runs the latest main, I now see a playing stream. In the console I see:
so that is as expected, I think? In other words, it now seems to work correctly. Any idea in which version of Shaka this was fixed? |
@joeyparrish can you help here? |
Sequence mode for HLS was introduced in v4.0.0. The demo app should be displaying the latest release, which as of yesterday, is v4.3.4. Does this help? |
Thanks, that is useful information. It's mostly about when clients ask when this issue was solved, we can tell them to upgrade Shaka past v4.0.0, if possible. |
Have you read the FAQ and checked for duplicate open issues?
Yes.
What version of Shaka Player are you using?
v3.1.1 (debug)
Can you reproduce the issue with our latest release version?
Yes
Can you reproduce the issue with the latest code from
master
?Unknown, I assume v3.1.1 (debug) is master?
Are you using the demo app or your own custom app?
Demo app, at https://shaka-player-demo.appspot.com/demo
If custom app, can you reproduce the issue using our demo app?
n/a
What browser and OS are you using?
Chrome 91.0.4472.114/macOS 11.4: hangs
Chrome 91.0.4472.124/Windows 10.0.19043.1052: hangs
Edge 91.0.864.59/Windows 10.0.19043.1052: hangs
Firefox 89.0.2 /macOS 11.4: works
Firefox 89.0.2/Windows 10.0.19043.1052: works
Safari 14.1.1/macOS 11.4: hangs
For embedded devices (smart TVs, etc.), what model and firmware version are you using?
n/a
What are the manifest and license server URIs?
https://live.unified-streaming.com/shaka-issue-8845/nodrm.ism/.mpd?vbegin=346&vend=1668
(no DRM applied, this should play right away)
Direct demo link:
https://shaka-player-demo.appspot.com/demo/#audiolang=en-US;textlang=en-US;uilang=en-US;asset=https://live.unified-streaming.com/shaka-issue-8845/nodrm.ism/.mpd?vbegin=346&vend=1668;panel=CUSTOM%20CONTENT;build=debug_compiled
What configuration are you using? What is the output of
player.getConfiguration()
?No special configuration, using defaults from https://shaka-player-demo.appspot.com/
What did you do?
Attempt to play the media.
What did you expect to happen?
Media should have started playing. However, it only does so on Firefox, not on Chrome, Edge or Safari. I haven't tried embedded players, but I'm assuming Chromium-derived and Safari-derived browsers will fail identically.
What actually happened?
On Chrome and Safari browsers, the media does not start playing, and a spinner is shown.
The last messages in the console are:
However, as far as I can determine, there is no such gap. The manifest has audio and video which are slightly misaligned due to (probably) hiccups in the encoder, and this causes the audio to start 0.013666s later than the video.
For reference, the full manifest:
The starting segments for both audio and video are number 181 (as indicated by
startNumber=181
):The baseMediaDecodeTime of audio segment 181 is 16589456/48000 = 345.613666s, while the baseMediaDecodeTime of video segment 181 is 86400000/250000 = 345.600000s. So there is a slight misalignment of 0.013666s, but definitely not a 'gap' of 1.907336s!
Note that due to DASH-IF implementation guidelines for the restricted timing model, in particular 9.2.1. Necessary segment references in static presentations, we have adjusted the
presentationTimeOffset
of the video track to ensure both video and audio is available at the start of the presentation. E.g.:AdaptationSet
it hastimescale="48000" presentationTimeOffset="16589456"
, so this starts at exactly 345.613666s too, whileAdaptationSet
it hastimescale="250000" presentationTimeOffset="86403416"
, so this starts at 345.613664s, which is as near to the audio as possible.The text was updated successfully, but these errors were encountered: