Closed ojw28 closed 4 years ago
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.
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?
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:
https://github.com/google/ExoPlayer/issues/4780#issuecomment-426580657 https://github.com/google/ExoPlayer/issues/4780#issuecomment-426882421
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:
My conclusions from F2F discussion:
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:
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.
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
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:
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).
So I'd suggest that there should be two separate SHALL clauses (one corresponding to each bullet point above).
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).
OK, I think that makes sense. Thanks for the explanation.
No further comments received in some time, so closing. This is now integrated into timing model document.
Related to: https://github.com/google/ExoPlayer/issues/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? CurrentlyminimumUpdatePeriod
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 thatminimumUpdatePeriod
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 ofminimumUpdatePeriod
in the DASH specification, which says: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?