representations -> shall cover -> should cover

[RufaelDev]

For covering an entire representation with samples, make shall cover a should cover, as to allow for discontinuitity signalling in case something goes wrong upstream, which happens sometimes. Discontinuities are not recommended but may occur in practical cases. DASH can signal discontinuity for example in the segment timeline. This should be recommended, and it is also part of the timing model.

reconsider introducing unnecessary segment references, it is confusing.

[sandersaares]

as to allow for discontinuitity signalling in case something goes wrong upstream, which happens sometimes.

Discontinuities are not a part of the interoperable timing model. If discontinuities occur, the packager is expected to remove the discontinuous adaptation sets or representatations for the duration of the discontinuity.

The reason is that while it is simpler to create packagers that just signal discontinuities, this is more complex for clients to handle. As clients are the more restricted party in terms of their capabilities (due to being often based on very limited MSE APIs), we need to avoid any gaps in the content. Discontinuities are a gap - handle them by splitting the periods and removing the offending component for the duration of the gap. Period continuity signaling allows clients to handle this seamlessly when possible.

I will add a chapter that explicitly addresses this and provides an example.

[RufaelDev]

Why would it be difficult for a client to handle ? Should still means it is part of the conformance, it just means that in well defined exceptional circumstance another measure can be taken, so should can still be used even if discontinuities are not part of the timing model, as should implies it is necessary for conformance reasons. Therefore SHOULD instead of SHALL be used

[sandersaares]

Why would it be difficult for a client to handle

There was strong feedback from client developers that they expect playback without gaps and that any gaps are difficult to handle. This was the primary motivation behind the work on the timing model, as DASH was far too relaxed with allowing gaps to be present.

Should still means it is part of the conformance, it just means that in well defined exceptional circumstance another measure can be taken,

For this to be a "SHALL" we need to have a known reason why a well defined exception might be necessary. Sure, some individual clients might support that but DASH-IF guidelines are for general interoperability and we have no reason to assume this is generally implemented (and real world experience tends to support that discontinuities mess things up). Based on the client developer feedback that gaps are not expected (and real world experience with players that aligns with that - gaps cause issues), interoperability is best served by forbidding missing data in any of its forms during a presentation.

To permit discontinuities in the timeline, we would need a strong belief that clients can actually support this well. Furthermore, we already have a workaround - start a period where you drop the representation temporarily - which is likely to receive more implementation support becuase multi-period support is relatively common in players these days (though imperfect at times).

Yes, starting a new period is more effortful for the packager (and carries a cost in MPD size) but the packager is the more capable and flexible party in a DASH service-client relationship, so should bear the burden of complex data processing.

[sandersaares]

Proposed resolution: close issue with no action.

Rationale: banning discontinuities is at the heart of the timing guidelines, a view where they are permitted is intentionally not compatible with thse guidelines.

[haudiobe]

(IOPv5 20/02/05): No other comments. If no further comments are received, the issue will be closed during the next (IOPv5 20/02/12)

[ZmGorynych]

Banning discontinuities is impractical for large-scale deployments. They do and will happen in practical systems, although these are rare. Designing clients for only a happy path is highly undesirable -- things can and will go wrong, and you need the ability of each link in the delivery chain to function in presence of imperfect input.

In the end we want a 99.999% reliability at scale, and "happy path" assumptions are elegant but will not get us there.

[haudiobe]

(IOPv5 20/02/12): Proponents and commenters not present. Remains open

[haudiobe]

(IOPv5 20/02/26): Proponents and commenters not present. Remains open

[sandersaares]

It is important to make a distinction here about what the timing model guidelines are about: they say that the content description given to the DASH client must not contain gaps. This does not mean that the guidelines cannot be applied to scenarios where gaps occur - it simply means that any gaps (regions of a representation's timeline that the packager is unable to publish) must be handled in an appropriate manner by the packager to present the DASH client with a continuous timeline.

The mechanisms for handling this are already described by the proposed guidelines: https://dashif-documents.azurewebsites.net/Guidelines-TimingModel/master/Guidelines-TimingModel.html#missing-segments

While I agree that each link in the chain should be maximally robust, this does not mean that it is okay to simply pass defects in the data stream down the chain, loading maximum complexity into every successive component. Equally important is that each step in the chain publish maximally easy to use content and fix up what can be reasonably fixed up.

A DASH packager can and should overcome segment loss between the encoder and the packager, especially given the strong feedback we have received from player authors that gaps are difficult to deal with. The recommended method for this in the current proposal is to create a period where the lost segment is not a valid segment for playback (assumes availability of alternatives, of course, for meaningful outcome). This will lead to content that plays well in existing DASH clients.

There are other mechanisms to help hypothetical future players deal with such content even better and potentially also reduce processing complexity on the service side but that's a discussion already ongoing in #46 so I will not repeat it here.

Proposed resolution: close issue with no action.

[RufaelDev]

I am uncomfortable re-inventing DASH features in the DASH-IF. Players can handle discontinuities as supported by DASH specification, I have tested this on many players, the proposal of adding a silent/blank frame is untested and can cause much more problems as a player does not 'see' the discontinuity possibly trying to playback erroneous information leading to much bigger errors. Section 14 should be removed or updated, such drastic recommendations should be discussed in MPEG not DASH-IF, re-inventing DASH in DASH-IF is undesirable. Proposed resolution: update the document according to feedback or develop a more realistic timing model instead that at least aligns with what is defined in MPEG DASH.

[sandersaares]

I am uncomfortable re-inventing DASH features in the DASH-IF

There is nothing being reinvented here. The suggestions offered in the timing model guidelines have been mentioned in discussions over many years and frankly, none of this is innovative in the least. Please let's stick to the facts and avoid overly dramatic descriptions.

Players can handle discontinuities as supported by DASH specification,

Some players, perhaps. In some situations, perhaps. We have strong feedback from client developers that gaps make life very hard (and the possibility that gaps are permitted has been very surprising to some). Overall, the ecosystem does not handle gaps well.

the proposal of adding a silent/blank frame is untested and can cause much more problems as a player does not 'see' the discontinuity possibly trying to playback erroneous information leading to much bigger errors.

This is a relatively inisignificant workaround suggestion with some drawbacks that should be obvious to the reader but if you feel it is objectionable, sure, let's get rid of this workaround suggestion.

[haudiobe]

(IOPv5 20/03/04):

• Proposal to have a "should" (supported by Alex, Iraj, Rufael) with a should that the gap is signaled.
• Proposal to have a "shall" (supported by Sander). We can define a profile that signals that this is the case. All timing guidelines are part of this profile. We create a profile for the timing model.

[haudiobe]

Action to Thomas: Add in umbrella document the profile.

[haudiobe]

Please check clause 6.4 here: https://1drv.ms/w/s!AiNJEPgowJnWgotJG4uaEqFkZ3r1wQ?e=9T5DOu

[RufaelDev]

looks good to me!

[sandersaares]

LGTM

I think the URLs should have /published/ instead of /master/, though - point to the published versions, not the working copy (at least eventually).

For example: https://dashif-documents.azurewebsites.net/Guidelines-TimingModel/published/Guidelines-TimingModel.html (currently 404 since we have not officially published any version)