Seeking within DVRWindow takes a lot of time if suggestedPresentationDelay exists in MPD

[tomraut]

Environment

• The MPD passes the DASH-IF Conformance Tool on https://conformance.dashif.org/
• The stream has correct Access-Control-Allow-Origin headers (CORS)
• There are no network errors such as 404s in the browser console when trying to play the stream
• The issue observed is not mentioned on https://github.com/Dash-Industry-Forum/dash.js/wiki/FAQ
• The issue occurs in the latest reference client on http://reference.dashif.org/dash.js/ and not just on my page

• Link to playable MPD file: not available at the moment
• Dash.js version: 3.1.0
• Browser name/version: Chrome latest
• OS name/version: OS X Mojave

Steps to reproduce

1. Start live stream with suggestedPresentationDelay set in MPD file.
2. Seek backwards using timeline.
3. Try to seek back to live.

Observed behaviour

It can take up to several minutes before playback resumes.

[dsilhavy]

@tomraut Would be good if you can provide a test stream. I tried this one and I could not reproduce the issue: https://wowzaec2demo.streamlock.net/live/bigbuckbunny/manifest_mvnumber.mpd

[tomraut]

@dsilhavy we don't have any streams where suggestedPresentationDelay would be in place at MPD but I've been using our 24/7 news stream (https://mtvdashliveusp2-a.akamaized.net/live/E39USP/E39USP.isml/E39USP.mpd) and placing suggestedPresentationDelay on the fly before passing manifest to dash.js. Do you think you could do the same?

[dsilhavy]

@tomraut Can you please check if your problem was fixed with #3285 -> Nightly version:
http://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html

[dsilhavy]

Feedback from @tomraut

• minBufferTime 10 => 4: stream is -16s from live edge, seeking back and forth works without issues

• suggestedPresentationDelay added and set to 4: stream is -14s from live edge but seeking back and forth does not work, player starts fetching audio/video packages without ever resuming playback, see screenshots below

@dsilhavy :
The issue is still that after seeking back to the live edge no valid segment request for the target latency can be found. Player starts downloading segments from the beginning. I think suggestedPresentationDelay should be aligned to what is available in the MPD, but dash.js should be able to handle the case when it is not.

Right now the live delay gets adjusted during the startup. so whenever no segment is available the live delay is adjusted until we find a valid segment in the timeline. problem is, we are playing at the bleeding live edge (in terms of whats available in the mpd). So when you seek within the dvr window and back to live, live delay might still be too close to the now time. then no segment request can be generated. this needs to be improved.