Clarify expected manifest transformation when a live event ends

[ojw28]

Related to: google/ExoPlayer#4780
Version of guidelines: https://dashif.org/docs/DASH-IF-IOP-v4.2-clean.htm

This is a request to clarify the expected manifest transformation when a live event ends, specifically for the case described in Section 4.5 (MPD and Segment-based Live Service Offering).

In particular, is it expected that minimumUpdatePeriod will be removed from the manifest when the event has ended? Currently minimumUpdatePeriod is listed as a mandatory in Table 14 in 4.5.1.1, which suggests that it should not be removed. However if this is the case, how can a client determine that the manifest wont change at some point in the future? The manifest duration will be set to indicate that no further content will be appended to the manifest, but I can't see a way that the client to determine that content wont be removed from the start of the manifest. If content wont be removed from the start, I'd argue that minimumUpdatePeriod should be removed from the manifest to make it clear to clients that the manifest will not change. This would be consistent with the definition of minimumUpdatePeriod in the DASH specification, which says:

If this attribute is not present it indicates that the MPD does not change.

Note that for the case described in Section 4.4 (Simple Live Service Offering including MPD Updates), specifically 4.4.3.1, it does say that minimumUpdatePeriod should be removed when the presentation is terminated. I don't see why the case described in Section 4.5 should be different in this regard.

Thoughts?

[sandersaares]

I think a definition of "live event" would be helpful here.

What should happen at the end? Does it become a VOD? Or does it "expire" as a live stream, sliding off the time shift window into nothingness?

Both are valid scenarios, I guess.

• if there is a fixed end point but otherwise it remains a live service (time shift window still applies, old content still gets deleted) then set duration on MPD and last period, at minimum.
• if nothing is going to change in the MPD going forward, set type=static and it shall no longer be a live service offering.

Spec 4.6 talks about the latter in fair detail. Do I understand it right that the confusion is about the former scenario? Or something else entirely?

[ojw28]

From the issue I'm trying to deal with (ref'd at the top), it seems there's confusion about the latter case. Several providers we're working with are leaving minimumUpdatePeriod and type=dynamic in the manifest, even though it isn't going to change going forward. They believe this is the correct thing to do as per the guidelines. See for example:

google/ExoPlayer#4780 (comment)
google/ExoPlayer#4780 (comment)

These are comments from one provider, but I'm aware of at least one other major streaming provider who are doing the same thing.

Perhaps the problem is that if a provider simply views their stream as a live stream that's ended (for example because their UI doesn't provide access to the stream as an on-demand stream - so they don't really consider that as a use case they provide), then they're probably not even going to read section 4.6. The start of that section describes it as being specific to the scenario of wanting to offer the content as on-demand. Furthermore it's confusing that section 4.4 describes what happens when the presentation is terminated, but section 4.5 omits to do so for the more advanced case.

I would suggest that either:

• Sections 4.4 and 4.5 should both clearly define what should happen upon termination, for both of the scenarios you mention.
• If what should happen is the same for both sections, neither section 4.4 or 4.5 should define what should happen, and there should be a subsequent section that defines what should happen upon termination that 4.4 and 4.5 can both refer to. This section should not be under the guise of a particular use case (e.g. offering up live content as on-demand), but rather as a section describing the fundamental transformation that should happen upon termination, so that it's clear a provider should implement what's described regardless of what use cases they support.

[sandersaares]

My conclusions from F2F discussion:

• xlink periods can have arbitrary duration not known to packager
• therefore the packager might not know the full duration of an MPD if xlink periods are present
• therefore packager cannot always know the correct value for MPD@mediaPresentationDuration if xlink periods are present
• there are no other tools for signaling "live event is over, no more periods are going to appear";
• therefore "live event is over" cannot be signaled.

This is not a happy conclusion. We need a way to signal this but we also need a consistent timing model.

Ideas for fixing it:

• ask MPEG to define a "this period is the last period" attribute
• forbid xlink periods with arbitrary durations, packager must know duration (not realistic, this is a valid use case)

[sandersaares]

So where does this leave us?

The only signal we have currently available is MPD@minimumUpdatePeriod. A service can signal that it will never update the MPD by removing this attribute. This implies that there will be no more content coming.

Is this signal enough? My gut feeling says yes. It is also what is proposed in the OP. I will integrate this as some "signaling end of dynamic content" chapter into Dash-Industry-Forum/DASH-IF-IOP#210 unless objections arise.

How does this interact with the dynamic->static conversion scenario? After all, if I signal that the event is over by saying "the MPD will never change" I cannot then later go and change it to a static manifest... or can I? Maybe this is fine in practice and only a theoretical obstacle.

[sandersaares]

Here is my attempt at wording this: https://dashif-documents.azurewebsites.net//DASH-IF-IOP/pull/210/DASH-IF-IOP.html#timing-mpd-updates-theend

[ojw28]

I think it makes sense for the wording to decouple "nothing more will be added" from "this manifest wont change". "Nothing more will be added" can be true without "this manifest wont change", in the case that the manifest is being updated to remove content from the start as it becomes unavailable. My current understanding is:

• The manifest having an overall duration is what indicates where the end of the content is (the last period having a duration isn't sufficient by itself, since another period may be added). If a client has managed to play up to position defined by the start time + the duration, it knows it should transition to ENDED. If a client has run out of content to play before playing up to this position, or if the duration is unknown, it should transition to BUFFERING.
• minimumUpdatePeriod being removed indicates the manifest wont change.

After all, if I signal that the event is over by saying "the MPD will never change" I cannot then later go and change it to a static manifest... or can I? Maybe this is fine in practice and only a theoretical obstacle.

If it's ever going to change then it makes sense that it would change when minimumUpdatePeriod is removed. Although from a practical point of view I don't see the harm in changing it later (new playbacks will see it, existing ones wont because the client wont be refreshing the manifest).

[ojw28]

So I'd suggest that there should be two separate SHALL clauses (one corresponding to each bullet point above).

[sandersaares]

I agree in principle but in practice, I see a problem.

Given that xlink periods can have a duration that is not known to the packager, there could be situations where the packager is unable to signal end of content via MPD@mediaPresentationDuration as it does not necessarily know the durations of the xlink periods.

This would make for a mechanism that only works without xlink periods, which seems undesirably limited. The interpretation I came up with (tying together end of content with end of updates) seemed to be a compromise that remains xlink compatible while not preventing any obvious use cases (since the main reason for MPD updates is to add more content, stopping MPD updates when content ends seems relatively harmless).

[ojw28]

OK, I think that makes sense. Thanks for the explanation.

[sandersaares]

No further comments received in some time, so closing. This is now integrated into timing model document.