v4: dynamic to static broken

[bbert]

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:
• Dash.js version: 4.0.0
• Browser name/version:
• OS name/version:

Steps to reproduce

1. Please provide clear steps to reproduce your problem

See issue #3263 to get how to play catch-up/start-over streams

2. If the bug is intermittent, give a rough frequency if possible

Observed behavior

catch-up/start-over streams do not start anymore. Support for such streams has been introduced in PR #3280
If setting start time (anchor time) to 0, then stream may start, but dynamic to static transition is broken: playback is stopped once we reach end of stream (dynamic to static transition) even if we are not playing at end of stream.

Console output

Expected behavior

When starting catch-up/start-over streams, playback should by default start a live edge.
At dynamic to static transition, playback should continue until reaching end of stream.

[dsilhavy]

@bbert Thanks for reporting, there was a bug in the calculation of the segment availability end time for streams with end time set to "Infinite".

Can you confirm that this 49e4f5c fixes the issue.

[bbert]

The commit fixes the issue for starting playback.
However, at dynamic to static transition, there is a regression since buffering is signaled to be completed, and if we seek back before reaching end of stream, then no more new segments are requested.
In previous version we were checking if there was no more segment in list before triggering buffering to be completed.

[dsilhavy]

@bbert I tried to reproduce this but it worked for me so far with:

• echo "https://live.unified-streaming.com/scte35/scte35.isml/.mpd?vbegin=$(($(date -u +%s)-240))&vend=$(($(date -u +%s)+20))"
• Seeking back before transition to VoD
• Playing behind the live edge and waiting for transition to VoD

Note that with the current nightly version we have a problem with the Unified teststream. dash.js uses the settings defined in the ServiceDescription element. However, there are no segments defined in the MPD that fulfill the max latency target. Consequently, dash.js keeps seeking to the live edge and stalls.

[lkinasiewicz]

I think that the problem may be here:

dash.js/src/dash/DashHandler.js

Lines 212 to 213 in b5f408b

	if (isDynamicManifest && dynamicStreamCompleted) {
	isFinished = true;

Just like @bbert mentioned - when the manifest changes from dynamic to static, dynamicStreamCompleted is set to true, dashHandler.isMediaFinished returns true and StreamProcessor stops buffering:

dash.js/src/streaming/StreamProcessor.js

Lines 409 to 418 in b5f408b

	if (isMediaFinished) {
	const segmentIndex = dashHandler.getCurrentIndex();
	logger.debug(`Segment requesting for stream ${streamInfo.id} has finished`);
	eventBus.trigger(Events.STREAM_REQUESTING_COMPLETED, { segmentIndex }, {
	streamId: streamInfo.id,
	mediaType: type
	});
	scheduleController.clearScheduleTimer();
	return;
	}

In 3.2.2 there was a flag in DashHandler indicating whether isMediaFinished can be ignored when generating new requests:

dash.js/src/dash/DashHandler.js

Line 293 in 27f4eb3

const finished = !ignoreIsFinished ? isMediaFinished(representation) : false;

This was removed in 4.0.0, so maybe this caused the regression? Maybe we can just remove the conditional mentioned above:

dash.js/src/dash/DashHandler.js

Lines 212 to 213 in b5f408b

	if (isDynamicManifest && dynamicStreamCompleted) {
	isFinished = true;

and let the logic that follows, handle static manifest?

[dsilhavy]

Thanks for your analysis and suggestion @lkinasiewicz . Together with @bbert we solved this a little differently in #3748 , moving the check of the DashHandler after trying to generate a request.