#t=0 anchor link no longer starts playback of live stream automatically if "calcFromSegmentTimeline" set to true

[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: https://mtv-live-simulcast.cdn.katsomo.fi/live/E39USP/E39USP.isml/E39USP.mpd#t=0
• Dash.js version: 4.1.0
• Browser name/version: Chrome
• OS name/version: OS X

Steps to reproduce

Start playing mentioned stream. Player loads but user needs to either toggle pause => play or tickle the timeline in order for stream to start to actually play.

Observed behavior

This happens only with dash.js v4.1.0. I've tested the same using v3.2.2 and there everything works without any issues.

[dsilhavy]

@tomraut can you please check if your problem is fixed here: #3815 . The changes should be available in the nightly build soon: http://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html

[tomraut]

@dsilhavy yep, seems to be fixed! Awesome!

[tomraut]

@dsilhavy I may have been too fast to give you test result. When testing with another stream, it is still not fixed. Not sure if ?t= parameter has something to do with this.

Following kind of stream still requires user to tickle timeline:
https://mtv-live-simulcast.cdn.katsomo.fi/live/E6USP/E6USP.isml/E6USP.mpd?t=2021-11-18T06%3A07%3A00.000Z-2021-11-18T07%3A24%3A47.000Z#t=0

[dsilhavy]

I cant check this stream seems to be DRM protected. Does it start when you omit the t parameter?

[tomraut]

@dsilhavy I've done some debugging and I think reason for this not working in our player is this code:

dash.js/src/streaming/controllers/PlaybackController.js

Lines 465 to 471 in 3786007

	const currentTime = getNormalizedTime();
	const actualTime = getActualPresentationTime(currentTime, mediaType);
	const timeChanged = (!isNaN(actualTime) && actualTime !== currentTime);
	if (timeChanged && !isSeeking() && (isStalled() || playbackStalled || videoModel.getReadyState() === 1)) {
	logger.debug(`UpdateCurrentTime: Seek to actual time: ${actualTime} from currentTime: ${currentTime}`);
	seek(actualTime);
	}

When testing same stream (https://mtv-live-simulcast.cdn.katsomo.fi/live/E39USP/E39USP.isml/E39USP.mpd?t=2021-11-18T09%3A00%3A00.000Z-2021-11-18T10%3A34%3A58.000Z#t=0) using reference player and DEBUG logging enabled, I see that it logs this row:
[5938][PlaybackController] UpdateCurrentTime: Seek to actual time: 1637226011.6115 from currentTime: 1637226011.2625

But with DEBUG logging enabled in our player, this is not logged. I've added console logging and re-built dash.js locally and found out that when started same stream in our player, both

const currentTime = getNormalizedTime();
const actualTime = getActualPresentationTime(currentTime, mediaType);

gets exactly same value (1637226055.04) so it never goes inside if clause to execute seek(actualTime);

I'm not sure why on reference page those values get 0.3490 difference but in our player difference is 0.

[tomraut]

@dsilhavy If I test our player with stream without ?t parameter (https://mtv-live-simulcast.cdn.katsomo.fi/live/E39USP/E39USP.isml/E39USP.mpd#t=0), I see that updateCurrentTime is called several times before eventually DVRWindow.start changes and it proceeds to if clause applying seek and stream starts:

*** currentTime:  1637294656.64 DVRWindow: {start: 1637294656.64, end: 1637301856.64}
*** currentTime:  1637294656.64 DVRWindow: {start: 1637294656.64, end: 1637301856.64}
*** currentTime:  1637294656.64 DVRWindow: {start: 1637294656.64, end: 1637301856.64}
*** currentTime:  1637294656.64 DVRWindow: {start: 1637294660.48, end: 1637301860.48}
[4997][PlaybackController] UpdateCurrentTime: Seek to actual time: 1637294660.48 from currentTime: 1637294656.64 

So it seems to me that when there is a ?t parameter in the manifest URL, DVRWindow.start is locked to that moment exactly and logic in updateCurrentTime method no longer works as it relies on the fact that at some point in dynamic streams currentTime differs from DVRWindow.start.

[dsilhavy]

• If you omit #t there should be no seek coming from updateCurrentTime. However, startup might take a while if you don't adjust the live delay or enable calcFromSegmentTimeline
• In my tests on nightly https://reference.dashif.org/dash.js/nightly/samples/dash-if-reference-player/index.html the stream starts every time event if I limit the available bandwidth in the network panel (in case there is no ?t in the URL)
• Adding ?t to the url should have no effect on dash.js itself

[tomraut]

@dsilhavy if I toggle "Calculate segment availability from timeline" ON when using reference player, then stream https://mtv-live-simulcast.cdn.katsomo.fi/live/E39USP/E39USP.isml/E39USP.mpd?t=2021-11-19T09%3A00%3A00.000Z-2021-11-19T10%3A34%3A58.000Z#t=0 does not start and I have to tickle timeline also with reference player in order to start playback.

Should this be considered a bug or a feature?

[dsilhavy]

Looks like a timing issue, would need to check this in detail. It starts after some time though even without manually seeking.

[dsilhavy]

@tomraut Can you confirm that #3833 fixes the issue? I applied a minor offset to not interfere with MSE seekable range. It looked good in my tests.

[dsilhavy]

Fixed in #3833

[tomraut]

@dsilhavy I see you already closed this one, but just to confirm: I've tested your fix and it works for me as well in our setup. Thank you very much!

[dsilhavy]

@tomraut Thank you for verifying