MPD Update

[haudiobe]

Submitter: Oliver Woodman
This issue is spun out of a discussion here: google/ExoPlayer#3457

The paragraph under discussion in the DASH-IF guidelines is:

"In order to make the MPD joining friendly and to remove data that is available in the past, any segments that have fallen out of the time shift buffer may no longer be announced in the MPD. In this case, the Period start may be moved by changing one or both, MPD@availabilityStartTime and Period@start. However, this requires that the @startNumber, @presentationTimeOffset and S values need to be updated such that the Segment Information accorging to section 4.3.2.2.6 is not modified over an MPD update."

There appear to be a few issues:

1. As noted in the issue ref'd above, allowing @availabilityStartTime to change appears to directly contradict 23009-1 which states: "When the MPD is updated, the value of MPD@availabilityStartTime shall be the same in the original and the updated MPD"

2. Given Period@id is optional in the DASH spec, fixed Period@start values are a convenient way for DASH clients to match periods in the updated manifest to those in a previous manifest. Allowing Period@start values to change makes matching periods more difficult.

3. I cannot think of a reason why it would be necessary, or a good idea, to adjust Period@start in the way described. I don't think such adjustments are ever required to remove segments that are no longer available in the period. Making the adjustment appears to require changing other variables (e.g. @presentationTimeOffset also has to change) in a way so that the end result is the changes cancel one another out. This is more complicated than not changing any of them, and is more difficult for clients to handle (e.g. see point above).

Unless this type of manifest adjustment is genuinely necessary, it seems preferable that the DASH-IF guidelines should instead require Period@start and MPD@availabilityStartTime to remain unchanged across manifest updates.

[ojw28]

I took a look at the change request for this issue. The change looks like an improvement, but is there a reason the two sentences starting from:

In this case, the Period start may be moved ...

are still present? As per (1) above, the manifest update described in those sentences appears to violate 23009-1 by allowing Period@start to change. As per (3) above, the manifest update described appears to be unnecessary because the end result is that the parameter changes cancel one another out.

Have I misunderstood? Is there a plan to remove those sentences in a future revision unless someone can justify why the manifest update described is required for a concrete use case? Thanks!

[haudiobe]

addressed in v4.12

[ojw28]

@haudiobe - Could you respond to my questions about the amendment in the post above? Thanks!

[haudiobe]

OJW, we discussed this in detail and made it a "should". It does not contradict with 23009-1, it only contradicts with a specific profile. The rest is pretty clear that you use Period id. What else do you think is unclear?

[ojw28]

It may only contradict a specific profile, but isn't the profile it contradicts the one that everyone's going to be using for live (and the one used throughout the DASH-IF document)? In which case it seems fairly confusing. I think it would be clearer if the part starting "In this case, the Period start may be moved ..." were amended to more explicitly state:

• There's no reason to change any of the mentioned variables. This is implicit already by the use of "may", but the way it's written leaves the reader in doubt as to whether updating the manifest as described is a good idea or not, or useful for some reason. It seems preferable to not leave the reader to figure out whether it's important.
• The mentioned variables shall not be changed if using “urn:mpeg:dash:profile:isoff-live:2011”. Because doing so would contradict 23009-1.
• If they are changed, it's important to change all of them. This is already clear in the text.

In practice it feels to me like the second bullet point is going to prevent pretty much anyone from making the manifest change described, which is why I asked whether it would be better to remove the part from "In this case, the Period start may be moved ..."

Apologies if I've misunderstood anything!