suggestedPresentationDelay

[irajs]

Due to various delays and processes required to create and publish media segments, it will often be the case that media segments become available with some delay, both with regard to the expected scheduling and with regard to differences between representations. The mechanism for signaling the expected delay is MPD@suggestedPresentationDelay.

MPD@suggestedPresentationDelay is not intended to signal the delay on availability of segments. It is a suggested delay for presentation. If we want to use it for this purpose, we should add a note that we are using it for this purpose.

Also

"Services SHALL provide a suitable value for MPD@suggestedPresentationDelay to ensure that media segments that overlap the time shift window are available."

and

Clients SHALL NOT present any samples that are entirely outside the time shift window (whether in the past or the future).

[sandersaares]

It is a suggested delay for presentation

Can you clarify what you mean by this? What do you see as the role of this delay? Why would someone introduce this delay?

[irajs]

according to MPEG- DASH spec; this attribute is to synchronize multiple players. that's why it defines presentation delay and not for signaling margins of the timing of segment availability.

a possible problem with using it would be if legacy player/services are using it for the intended purpose and not what is defined here.

[sandersaares]

to synchronize multiple players.

I see the words used to describe this feature but I do not see the practical use cases.

Let me put it like this: I would expect players to play at the end of the time shift window (t=now) by default. SPD just shifts this point into the past.

In either case, clients are synchronized, just at different points (unless client decisions override the default synchronization). I do not see what synchronization aspect is added by SPD.

A service should make available at t=now the content that it wants clients to play at t=now. What is the value added by SPD here?

I could theoretically understand updating SPD in the middle of a live stream to change the synchronization point at runtime but this seems like a very artificial scenario to me.

I suspect SPD is in reality only used to work around services that do poor timing and need to work around the problem that content that is meant to be available is not yet available. Actually, I even remember that some clients completely ignored this value, at least a few years ago.

Let's expand this into a bigger question: do we need suggestedPresentationDelay at all? I would be happy to get rid of it if we have no real use cases that need it.

[sandersaares]

Okay, I tried to understand this more to better identify the role of SPD. I think I see this role now. The result was incorporated into Dash-Industry-Forum/DASH-IF-IOP#210 as a new chapter on presentation delay: https://dashif-documents.azurewebsites.net//DASH-IF-IOP/pull/210/DASH-IF-IOP.html#timing-delay

That being said, I still do not see any connection with synchronizing multiple players.

Please see if this improved description is satisfactory.

[haudiobe]

IOP 19/01/29: The statement is not correct. Please check 4.3.4.1 bullet point 5.

[sandersaares]

Problematic clause removed. Rest of chapter adjusted for enhanced clarity.

[haudiobe]

IOP 19/01/29: please everyone check if ok

[sandersaares]

No more comments, so I assume all is well. Closing.