timescale SHALL requirement

[irajs]

The sample timeline is measured in timescale units defined as a number of units per second. This value SHALL be present in the MPD as SegmentTemplate@timescale or SegmentBase@timescale (depending on the addressing mode).

also: The SegmentBase@timescale attribute SHALL be present and ...

Why do we need a SHALL here? in MPEG-DASH, this is optional.

[sandersaares]

This is intentional. I describe my reasoning for this.

The default value is 1, which is relatively unrealistic for a timescale as I have never seen timing rounded up to seconds in any real situations (at least since Apple introduced fractional seconds in HLS playlists).

Therefore, it seems safe to consider a missing timescale (== a timescale of 1) to be a content authoring error. The author of such content likely did not realize he needs to define the timescale and just forgot about it, instead of truly intending there to be a timescale of 1.

If he is lucky, the player might instead use the timescale from the sidx box. If he is unlucky, timing may fail to be correctly calculated. In the interest of interoperability, it seems prudent to always require a timescale to be explicitly defined, given that the default value is unrealistic.

[irajs]

Interesting observation. Then an one line note saying this is a practical requirement, would be good, since it probably makes DVB-DASH & HbbTV profile incompatible in this aspect.

[jpiesing]

Interesting observation. Then an one line note saying this is a practical requirement, would be good, since it probably makes DVB-DASH & HbbTV profile incompatible in this aspect.

Why would it make them incompatible? Is it just that DVB-DASH doesn't have such a requirement so valid DVB-DASH content would not be valid DASH-IF content?

[irajs]

The DVB-DASH content which don't have @timescale would not be conforming to DASH-IF IOP if we keep this as a SHALL.

Livesim doesn't add @timescale to its. You can argue that is not a real content, and it can easily be added.

[sandersaares]

Is there actually real DVB-DASH content with no timescale (=timescale of 1)?

[jpiesing]

Is there actually real DVB-DASH content with no timescale (=timescale of 1)?

There's no easy way to know. There's random DVB-DASH content all over the place. Looking at the test suite, 90% of references to SegmentTemplate in MPDs also have the word timescale on the same line.

The only ones which look suspicious are ones like this;

<SegmentTemplate media="HEAAC_96K_3secseg_tml/segments/seg-.fmp4/timeline-$Time$.m4s" initialization="HEAAC_96K_3secseg_tml/segments/seg-.fmp4/dashfile.mp4" />
<SegmentTemplate media="segments/seg-.fmp4/timeline-$Time$.m4s" initialization="segments/seg-.fmp4/dashfile.mp4" />
<SegmentTemplate media="segments/seg-.fmp4/timeline-$Time$.m4s" initialization="segments/seg-.fmp4/dashfile.mp4" />

If you agree that these might have an issue then I can ask about what was really meant.

[sandersaares]

It might be valuable to investigate, indeed, to find out if they truly have a timescale of 1. It feels unlikely to me, so maybe the test suite needs to be adjusted to not use the default value.

I added a note to #210 about why we do not keep this attribute optional, pointing to the unrealistic default value and being indicative of authoring error.

I do not think we need any notes about compatibility here in IOP, as such differences between different related specs are normal occurrence and especially if we are working on defining an interoperable timing model. One might say that the existing situation with different non-interoperable interpretations of DASH timing we see in the wild naturally incorporates conflicts no matter what we do.

I will mark this as closed for now but if you feel that we need to revisit some part of this, please leave a comment and we will take this up for discussion in the next IOP call.