5.11

[RufaelDev]

why ? why a separate section when only one exception ? please clarify

[sandersaares]

Where else?

More exceptions have been added in latest draft.

[RufaelDev]

I have never seen a specification with a section on forbidden techniques. At least explain why certain parts of DASH are not recommended for usage and at least rephrase the section to unsupported features in the timing module or something like this. Having a section forbidden techniques looks odd to me. Section could probably be in the beginning of the document or in a subsection in an introduction chapter.

[sandersaares]

Latest draft adds explanations for each of the items in the list. Does this satisfy your request for explanations? https://dashif-documents.azurewebsites.net/Guidelines-TimingModel/master/Guidelines-TimingModel.html#timing-nonos

This list is not important enough to be in the beginning of the document, it is just crossing some Ts and dotting some Is to avoid accidental use of incompatible features of DASH.

[sandersaares]

Proposed resolution: close issue.

Rationale: explanations were added.

[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]

There SHALL NOT be "missing content segments" ([DASH] 6.2.6) in the content. If content is lost during processing, the expectation is that the encoder/packager will either replace it with valid dummy content (e.g. blank picture or silent audio) or start a new period that does not contain the representation that incurs data loss.

This is unworkable in a practical large-scale implementation. For example, in a system which transforms per-representation UDP multicasts into segments, an occasional packet loss may result in a dropped segment from one of the representations. Creating a 1-2 segment period is unworkable. Creating a "dummy segment" with black frames when you have a different representation amplifies the customer impact vs showing a lower resolution. Substituting a segment from a different representation unbeknown to the client may be problematic in avc1/hvc1 cases as SPS/PPS will probably differ, and the client will not download an initialization segment if it does not know it is switching.

The above are the precise reasons both DASH and HLS have signaling for gaps in segments. I think that we are assuming the "happy path" too often and ignoring things which may go wrong in other parts of a deployment.

[sandersaares]

Creating a 1-2 segment period is unworkable.

There are some XML inefficiency concerns, of course, but otherwise adjusting the content based on period membership enables lost data to be removed from playback for a short duration.

Please explain why you believe this to be unworkable.

[ZmGorynych]

If your packager input is per-representation MPEG-2 TS multicast over UDP (which is very frequently the case), occasional missing packet can result in loss of a segment for a single representation. This turns a single period into 3: a pre-loss period with N representations, a 1-segment period with N-1 representation, and the N-representation continuation of the initial period. We just tripled the size of the MPD (including e.g. all DRM information). This increases bandwidth as well as client-side MPD processing overhead. Our client developers complained that these 2 sec periods are problematic from implementation standpoint as well. We've seen pathological cases where long-running DVR recordings had 100-300 Period elements mainly due to bursts of UDP packet losses. It is far beyond the degree of "XML inefficiency".

[sandersaares]

Thank you for clarifying.

I agree with your assessment that a lost segment can triple the MPD size. Proposals such as your recent one to optimize for MPD size by reuse of elements can help offset this cost, while still allowing players to assume that periods are whole (though I wonder how player backward compatibility can be ensured). Perhaps DASH-IF could also help out here by encouraging the removal of less useful metadata from the MPD (https://github.com/Dash-Industry-Forum/DASH-IF-IOP/issues/274 is a small, perhaps trivial, step in this direction).

Even after optimizing for XML size, this mechanism will always be less efficient than marking individual lost segments - no argument there! But the role of DASH-IF is to offer interoperability guidelines, not to specify the most optimized form of DASH. We need to consider what clients implement and the overwhelming feedback from client developers so far has been that gaps are difficult to handle. This is backed by practice, where numerous issue reports and playback inconsistencies in players can be tracked down to some gaps or missing data. Support for explicitly signaled gaps seems not a common feature, as well.

When we consider what is appropriate for DASH-IF guidelines, we have to target the players that exist, the ones that cannot always handle gaps. Implementors can always create their own more optimized players and signal individual segments but that is not the interoperable solution; it is not a solution you can deploy today and expect success with. Of course, if player developers claim otherwise I am happy to defer to their opinion.

[ZmGorynych]

I don't think our role as DASH-IF is limited to codifying existing implementations -- we do want to provide solutions to common problems. This means introducing new features of the spec. If we took the above approach earlier, we wouldn't have had lots of features we are actively using as we introduced many new features to DASH since the first version of these guidelines in mid-2013.

[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]

I agree that we cannot limit our role to codifying existing implementations. However, we must still be strongly guided by existing implementations. Where no widespread solutions exist, we can innovate and offer something new to the community (e.g. thumbnail tiles for seeking previews, CPIX). Where existing solutions are entrenched, we must innovate slowly and only once we have reason to believe that our guidelines are accepted as meaningful - it is no good to make ambitious guidelines that nobody plans to implement due to some Catch-22 situation.

When it comes to "missing content segments", we are in a situation where players currently used do not support any such thing. If we made guidelines that recommend this to be used, implementors would quickly find that this does not work and would not trust our guidelines.

I can probably agree that the ecosystem would benefit from players implementing this. Yet DASH-IF control over what is implemented by players is limited, even with dash.js (constrained by time and money and test vectors).

If DASH-IF can publish test vectors that include "missing content segments", perhaps we could encourage player authors to implement this. However, I see it as out of scope of the timing model guidelines, as this should really be strongly inclined towards what already works today. I suspect our live document might include some more thorough treatment of segment loss and perhaps viewing this from a live authoring guidelines angle might be a better path toward encouraging player authors to implement this feature.

Proposed resolution: close issue with no action in scope of timing model guidelines, to be revisited once ecosystem has evolved to a state where players do support this feature. Suggest live service guidelines mention this as desirable feature to see in future players (if they do not already do so) that DASH-IF publish thorough test vectors to allow player developers to test this feature.

[RufaelDev]

Change the shall to a should as there is clearly no consensus around this and given that DASH and HLS both support this is sufficient evidence that discontinuity signalling is the right direction and not filling blank segments which affects user experience.

[sandersaares]

The guidelines do not say that blank segments should be filled. The guidelines recommend that a period without the representation suffering from missing content be produced for the duration of the missing content. This is something that works in existing players, unlike "missing content segments" that have no support from many popular players.

Indeed, "missing content segments" are just another form of "blank segments" in a very real sense, they just potentially place less requirements on the decoder (in theory) than "true" blank segments.

[RufaelDev]

multi-period is still under development in dash-if in a separate CR, players have even more difficulties with multi-period (this activity was partially initiated by the current DASH.js maintainers), Alex already pointed out all the problems with inserting short periods under 2s, so filling blank or silent frames is the only alternative that is somewhat viable from this document, Alex also pointed out some of the problems with that in relation to the decoding pipelines. I think that such radical behavior should be discussed in MPEG not DASH-IF, also there is no test content contrary to vectors signaling discontinuities, while there is for regular discontinuity signalling which is also compatible with HLS.

[sandersaares]

Alex already pointed out all the problems with inserting short periods under 2s, so filling blank or silent frames is the only alternative that is somewhat viable from this document,

If players cannot handle short periods, the periods can be made longer. It is not true to say that filling in blank frames is the only alternative. I will add a note to the text that clients may have trouble with short periods, to better outline this.

I was also made aware that some readers may be missing important context given that 6.2.6 is (I think?) new in a recent DASH version. "Missing content segments" specifically refers to segments that signal the "miss" brand - that is, the player is expected to parse a segment, find that it has no contents and is "missing", and then take some suitable recovery action.

[haudiobe]

Solved by profile.

[haudiobe]

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

[sandersaares]

This was solved by profile, as above. All is well (although I think MPEG addressing it would be welcome). I'll close it as I do not believe anyone needs to address anything more here in DASH-IF context.