Question on 13.3

[dsilhavy]

Some questions on section 13.3 and the segment availability:

• As far as I understand t=now refers to the current wall clock time. How can segments after t=now already be completed?
• So far I only saw @availabilityTimeOffset in the context of low latency streaming to indicate that certain chunks of a media segment can be accessed before the segment is completed. How can the TotalAvailabilityTimeOffset include/span multiple media segments?

Does t = now refer to some time in the "past" and illustrates a client playing not at the bleeding live edge but two segments behind it?

Thanks for your explanation

[sandersaares]

It is worthwhile to always keep in mind that the MPD is a description of what the client can do. It is not a description of what the packager is doing. The MPD is a promise by the DASH service that when the client downloads data from specific URLs within specific time ranges, data matching a specific description will be returned.

Specifically, when the MPD describes a segment starting at time T on the MPD timeline, this does not mean that the packager started creating the segment at time T. It means that the client can start presenting the segment at time T!

When does the packager create this segment? This is not described in the MPD. It is entirely up to the packager and the publisher of the DASH service to determine this. The packager could create segments 1 minute in advance, for example, meaning that a segment starting at t=now was actually created at approximately t=now-60s, and also meaning that there are probably already segments available on the web server that are scheduled for presentation in the future, after t=now, from the client's perspective.

Designing a DASH service is, in part, challenging due to the need to match the service's promises to the capabilities of the network infrastructure (how fast can segments be published from packager to CDN edges, etc - which affect the values published in the MPD!).

As far as I understand t=now refers to the current wall clock time. How can segments after t=now already be completed?

So to answer this directly, it is because those segments were already prepared in the past by the packager.

So far I only saw @availabilityTimeOffset in the context of low latency streaming to indicate that certain chunks of a media segment can be accessed before the segment is completed. How can the TotalAvailabilityTimeOffset include/span multiple media segments?

Yes, that is probably the main use case for this feature. This feature is specified in DASH as just a numeric offset to timing calculations - the feature is not specific to chunked transfer.

Is there a meaningful scenario where the offset would span multiple media segments? Maybe. Technically speaking, as far as the DASH standard is concerned, it certainly could.

We can make up some artificial scenarios where this might be the case. Let's consider a stream with a funny keyframe interval, alternating through 1 second, 2 seconds and 10 seconds (cyclically, so it is known in advance). As a service provider, I want to publish this stream in a low latency form, and I specify a 5 second availability time offset.

At some moments, this 5 second offset will only cover a part of the 10 second segment. At other moments, it could cover the 1 second segment, the 3 second segment and even part of the 10 second segment.

[dsilhavy]

@sandersaares thanks for the detailed explanation. I think a good example for segments already prepared in the past by the packager is ad-insertion. You can prepare the ad segments before they are actually played at t=now. Maybe we can add such an example in one or two lines below as it makes the whole scenario clearer.

Feel free to close this issue at any time :)