Question: is there a way to signal "end of session"

[jackjansen]

A question that I've had for a long time: is there a way in which the receiver could detect end-of-session?

I'm not sure whether this is something that evanescent could do, or whether it requires something on the side of the sender.

I have this vague memory that we had something in the VRTogether era, where some sort of a conversion was done on the MPD file so that it became re-playable.

If we had something like this it would make the logic of the tests (and also production code, in some cases) easier, because when the receiver would see end-of-session it would simply exit with status 0. Currently it cannot really detect that the sender has closed the session, so it just terminates when it hasn't received any data for something like 5 seconds, but it can't tell whether that was because the sender closed the connection orderly or because it crashed.

[rbouqueau]

Yes it can be signalled. I think this means you're asking me to test it :)

[rbouqueau]

Just checked the code (that I'm updating) and the signals unity bridge / llplayout API doesn't include anyway to signal an end of session.

The MPEG_DASH_Input class (called from the DashDemuxer Module) actually stops the session when it is done (activate(false)). It happens in 3 conditions:

1. mpd->periodDuration reached, knowing that mpd is only refreshed once at start.
2. error (404) with on-demand content (should be out of scope for us).
3. if "streams" have no Representation attached (should be out of scope for us).

So 1. means that when the sender re-writes the MPD on-demand (which it does - see below), the client doesn't reparse it:

	if (totalDurationInMs > 0) {
		m_host->log(Info, "Manifest rewritten for on-demand. Media files untouched.");

		auto cfg = m_cfg;
		cfg.live = false;
		cfg.minUpdatePeriodInMs = 0;
		totalDurationInMs -= segDurationInMs;
		auto xml = createManifest(cfg);
		postManifest(xml);
	}

So we can do two things:

1. The caller of the SUB API detects that there is no more frames (=induces a delay).
2. The client could download the MPD regularly (at the price of more requests on the llrelay (or implement a cache in llrelay e.g. If-Modified-Since header)).

[rbouqueau]

@jackjansen What do you think about the two options at the bottom?

[jackjansen]

I think that what we do at the moment is similar to (1): after a period of no frames detected we timeout.

But I'm wondering: could we do something similar to (2), but combined with (1)?
So, if the client detects there havent been any frames for longer than, say 4*frameDuration it requests a new manifest, and if this manifest now shows that live==false and currentTimestamp > totalDurationInMs it knows the session is over.

I'm absolutely fine with implementing the timeout in the user code (i.e. my code) and calling something like sub_reloadManifest() whenever I have missed enough frames to warrant checking. Or maybe that should be bool sub_checkForEndOfLiveSession(); which would have all the knowledge of the manifests in your code, which might be more elegant. In the API documentation we state that this is a fairly expensive operation so you shouldn't call it like you would call fp->eof().

[rbouqueau]

MPEG_DASH_Input::processStream() is called regularly (i.e. in a 10ms loop) to try to get a new segment. When we don't get the segment (after 20 retries!!!) we just assume it is too early:

	if (empty) {
		if (mpd->dynamic) {
			int leeway = 1;
			if (!stream->anySegmentDataReceived) leeway += 1;
			stream->currNumber = std::max<int64_t>(stream->currNumber - leeway, rep->startNumber(mpd.get())); // too early, retry
			return;
		}

I feel this part of the code deserves a refresh ;) It's doing way too much HTTP requests. Hopefully it is unit tested. I'm still thinking at how to improve it. I agree with you we should be able to refresh the MPD at some point - I guess refreshing when we already make so much HTTP requests can't hurt ;)

PS1: it's in the part of code that I remember being problematic (with a race condition) in MPEG_DASH_Input::processStream().

PS2: I had also suggested to @soheibthriber that we improve the GPAC support in Signals or that we even switch to using GPAC as a client.

[jackjansen]

Whoah!!!!! That is very interesting!!! You may have found the reason that #25 is bothering us so much more in the case of multi-tiled streams!!!

Because with a single-tile stream there's just going to be this one thread that is banging on the server, but with a multi-tiled stream there are N threads doing that! So there's a much bigger chance that they will drown out the poor uploaders, who have the data that all the downloaders are clamouring for, but they can't get through....

cc @ireneviola

[rbouqueau]

Interesting. My question of re-using this Signals workflow versus GPAC is real. GPAC also gained support for SSR (sub-segment representation) which indexes whatever chunks/fragments from the DASH manifest. This allows to a certain extend to reuse the underlying TCP connection for a "stream". These are real network concerns that CDNs try to address (=minimizing the number of requests etc.) for scaling purposes.

[rbouqueau]

See my latest commit.

[jackjansen]

On the original subject of this issue: signalling end-of-file.
We've discussed things like uploading a new mpd, but noted that doing this would have some mild issue, like needing the receiver to regularly poll to see if the mod has changed.

I have a couple of ideas, but not sure whether these are implementable and/or good ideas and/or standard-compliant.

• Only have the receiver poll for a potential new MPD whenever it tried to read a segment that gave a 404. This depends on that not happening during normal runs.
• Have the transmitter write an empty segment (length 0). Probably after rewriting the MPD. The receiver would now only check for a new MPD if it encountered an empty segment. Not sure if this is allowed by the Dash standard.
• Maybe just using the empty segment as an indicator, and forget about getting a new MPD?

[rbouqueau]

I think we should just work to try to reload the MPD, what do you think?

About your ideas:

Only have the receiver poll for a potential new MPD whenever it tried to read a segment that gave a 404. This depends on that not happening during normal runs.

Signals doesn't allow that because the HTTP output is actually a module. By design Signals doesn't allow general communication between modules nor with the application (only in light or controlled ways e.g. errors or initial callbacks).

We don't have this issue in GPAC where the architecture has more object types. There is a 'downloader' object that allows fine control. One more reason to switch to GPAC eventually :)

Have the transmitter write an empty segment (length 0). Probably after rewriting the MPD. The receiver would now only check for a new MPD if it encountered an empty segment. Not sure if this is allowed by the Dash standard.

Actually that's an old idea: a zero sized 'mdat' box signals an end-of-isobmff file, and the GPAC team proposed an 'eods' box to signal an end of segment in ultra low latency mode.

Maybe just using the empty segment as an indicator, and forget about getting a new MPD?

That's the second option.

[jackjansen]

So, what do you think is the cleanest way to implement this?

[rbouqueau]

I suggest I try both when I have time (realistically not before Wednesday).