search

Dash-Industry-Forum / Guidelines-TimingModel

DASH-IF implementation guidelines: the DASH timing model
9 stars 1 forks source link

period connectivity (5.8.) #42

Closed RufaelDev closed 4 years ago

RufaelDev commented 4 years ago

consider merging with section on periods (or merging het periods section with this section)

why mpd validity duration depends on download time, how can services account for this as it does not control when a client downloads the manifest ? Should this not be relative to the publish time ?

sandersaares commented 4 years ago

consider merging with section on periods (or merging het periods section with this section)

Considered but it seems such an "extension" feature that it does not deserve to be described so far up high in the document, in the middle of the core concepts like timelines.

why mpd validity duration depends on download time, how can services account for this as it does not control when a client downloads the manifest ? Should this not be relative to the publish time ?

Yes, this dependency on the client download start time means that a DASH service must account for things like CDN publishing times in defining its timing characteristics.

But this is how MPEG has defined it:

From a client perspective, after a client fetches an MPD, it specifies the minimum period during which the MPD remains valid

"after" here is ambiguous - when do you start the timer? But 5.4.1 somewhat clarifies this by "adding MPD@minimumUpdatePeriod to the wall-clock time at which they request the MPD." - it is the requesting that starts the timer.

Well, that's how it is. A simpler model might be nice - maybe you can open a discussion topic in MPEG to simplify it?

As it stands today, MPD@publishTime is only used as an identifier and has no role in any timing logic.

This means that the MPD must be aligned with when things are actually published - a DASH packager cannot act as only an MPD generator, it must interact with the whole content publishing path to at least align configurations and delays. Also consider that the moment t=now on the wall clock must not only be synchronized between clients and services but the service must publish segment references in the MPD to cover this moment in time as the client sees it. So if the CDN has a 30 second publishing delay to get to all edges, the MPD must describe 30 seconds of content in addition to what it would normally generate at t=now.

I close this with no action but if you think something actionable remains here please add a comment and we can reopen the topic for further exploration.