S element changes across updates

[technogeek00]

In the timing model 13.6.3 Removing content from the MPD we explicitly make the following restriction on S elements with respect to expired content:

A repeating explicit segment reference (S element with @r != 0) SHALL NOT be removed until all repetitions have expired.

Which, referring back to 9.2.3 Removal of unnecessary segment references, we explicitly allow the following unnecessary references to exist:

The segment reference is defined by an <S> element that uses S@r to define multiple segment references, some of which are necessary.

But what if the service providers pipeline only keeps a fixed amount of segment information available? In this case when a segment falls out of their memory (and subsequently the dvr buffer described by the MPD) they will make the following update to a repeated S element

• Increment S@t by S@d
• If S element does not represent the live head as well, decrement S@r by one

As we have defined it this operation is invalid, but the changes made to the MPD are valid and within the other constraints of consistency within the available segment window. Could we relax the referenced restriction to better account for this service provider model?

[technogeek00]

@sandersaares thoughts on this?

[sandersaares]

In general, I try to think of the MPD as existing to serve the player. What does a player benefit from having the timeline start position be updated to remove data that is already out of the MPD time shift buffer? I think the player benefits not at all. Indeed, less battle-tested implementations might even neglect to check for this type of change - reducing the set of parameters that can change is beneficial for encouraging more robust players to be developed.

Allowing this change in S@t may make the service side easier to develop but IMO complexity should be minimized on the client side, even at the expense of more complexity on the service side if a tradeoff is needed.

Still, my feelings on the subject are not particularly strong. If it seems useful, I do not object.