Interoperable DASH timing model #210

sandersaares · 2018-11-07T10:19:05Z

Work in progress - do not merge.

This pull request adds a new section to IOP, defining an interoperable timing model.

Workflow:

January 2019 - review period.
February 2019 - merge this PR into IOP v5
After merge - create separate PR to adjust other chapters to match (reference timing mechanisms instead of re-defining them; also adjust to match updated constraints).

documentbot · 2018-11-07T10:21:43Z

Automated build report

Build was successful. Outputs:

This comment will be updated after each build. Last update was at 2019-04-02 06:23:35Z.

sandersaares · 2018-11-12T13:08:57Z

I have expanded the PR contents with a more substantial description of the timing model, focusing on the aspects of relevance to the topics under discussion.

DASH-IF-IOP.bs.md

technogeek00

Quick review of the xlink addition, I've got a list of restrictions with Xlink that we've used to a high degree of success. I'll try to dig that out to see if there is anything useful for the IOP.

DASH-IF-IOP.bs.md

Unknown what right thing to do is

technogeek00

@haudiobe importing comments from your document for direct interaction here.

technogeek00 · 2019-02-06T05:56:07Z

DASH-IF-IOP.bs.md


+This chapter describes an interoperable view of DASH presentation timing and segment addressing. This interpretation is considerably narrower than afforded by [[MPEGDASH]], constraining services to a specific set of reasonably flexible behaviors that are highly interoperable with modern client platforms. Services conforming to this document SHALL use this timing model.


From @haudiobe: What does this SHALL mean? This is not testable

The purpose of this clause is to indicate that if services want to conform to IOP, they need to use this timing model. To emphasize that this is not some optional feature that can be toggled for some use cases. To emphasize that it is a mandatory part of making interoperable services.

I agree that it is not testable in isolation.

technogeek00 · 2019-02-06T05:56:54Z

DASH-IF-IOP.bs.md


+The playback of a static MPD SHALL NOT depend on the mapping of the MPD timeline to real time. A client MAY play any part of the presentation at any time.


From @haudiobe: Correct as long as this is included within the availability times

Right. This links to #261

technogeek00 · 2019-02-06T05:57:18Z

DASH-IF-IOP.bs.md


+The playback of a static MPD SHALL NOT depend on the mapping of the MPD timeline to real time. A client MAY play any part of the presentation at any time.
+
+The MPD timeline of a dynamic MPD SHALL have a fixed mapping to real time, with each point on the timeline corresponding to a point in real time. Clients MAY introduce an additional offset with respect to real time [[#timing-timeshift|to the extent allowed by the time shift signaling in the MPD]].


From @haudiobe: This is not a shall, just a statement of fact

What is a fact to one person is one interpretation out of many to another person. Outlining basic operating constants with SHALL seems perfectly sensible.

A SHALL is always something that you can assert a test with. This is what Waqar does, looks for SHALLs and implements this. What would be the test?

I can see the value in that usage but I would not say that this word "always" necessarily applies. It is one possible way to apply this terminology, perhaps one that you are used to. Certainly I cannot say it is a bad way to do it. However, I would not say it is the only way. The purpose of SHALLs is not only to express testable technical facts, it is first and foremost to express requirements that guide human beings in their actions.

I do not think it is a hard requirement to have a SHALL here. I will try experimenting with alternative phrasings when I have a moment.

DASH-IF-IOP.bs.md

technogeek00 · 2019-02-06T05:58:32Z

DASH-IF-IOP.bs.md

+
+Note: In addition to mapping the content to real time, [[#timing-mpd-updates|a dynamic MPD can be updated during the presentation]]. Updates may add new periods and remove or modify existing ones, though some restrictions apply. See [[#timing-mpd-updates]].
+
+The zero point in the MPD timeline of a dynamic MPD SHALL be mapped to the point in real time indicated by `MPD@availabilityStartTime`. This value SHALL NOT change between MPD updates.


The zero point in the MPD timeline of a dynamic MPD SHALL be mapped to the point in real time indicated by MPD@availabilityStartTime.

From @haudiobe: Why SHALL? This is a definition. This is an anchor. See 4.3, clause 3.2.7.1

This value SHALL NOT change between MPD updates

From @haudiobe: Correct, but not the right place to be documented

Marking definitions with SHALL seems reasonable to me. Not every reader has the same views on what are facts and what are optional features and what are valid interpretations of facts. SHALL makes it very unambiguous.

With regard to the place for it to be documented, I find it a suitable place but I am open to alternative suggestions if there is an obviously superior location to describe it.

technogeek00 · 2019-02-06T06:13:48Z

DASH-IF-IOP.bs.md

+:: Same as the `timescale` field of the Media Header Box and same as the `SegmentBase@timescale` attribute in the MPD.
+
+: `earliest_presentation_time`
+:: The start timestamp of the first [=media segment=] on the [=sample timeline=], in [=timescale units=].


From @haudiobe: This is all defined in the ISO BMFF SPEC, so it is confusing to do it differently here

This is copied from IOP v4 and just worded to match v5 terminology. I make no judgement on whether we need it in v4/v5 at all but it seems to be useful enough (especially as not all readers will always have BMFF on hand and this is quite a critical structure).

technogeek00 · 2019-02-06T06:14:15Z

DASH-IF-IOP.bs.md

+	<figcaption>Explicit addressing uses a segment template that is combined with explicitly defined time spans for each [=media segment=] in order to reference [=media segments=], either by start time or by sequence number.</figcaption>
+</figure>
+
+The MPD SHALL contain a `SegmentTemplate/SegmentTimeline` element that contains a set of [=segment references=] which satisfies the requirements defined in this document. The references exist as a sequence of `S` elements, each of which references one or more [=media segments=] with start time `S@t` and duration `S@d` [=timescale units=] on the [=sample timeline=]. The `SegmentTemplate@duration` attribute SHALL NOT be present.


From @haudiobe: These are all repetitions of the DASH spec, and are confusing. They can be used as explanation, but not new requirements.

The contribution text is designed to be readable on its own. It is not a COR or AMD for DASH, to only cover gaps.

technogeek00 · 2019-02-06T06:14:35Z

DASH-IF-IOP.bs.md

+
+Note: Only additional references are counted, so `S@r=5` indicates a total of 6 consecutive [=media segments=] with the same duration.
+
+The start time of a [=media segment=] SHALL be calculated from the start time and duration of the previous [=media segment=] if not specified by `S@t`. There SHALL NOT be any gaps or overlap between [=media segments=].


From @haudiobe: What does it mean: "The start time of a media segment SHALL". It is a definition, not a requirement

What is a definition and what is a requirement is not a big difference in my mind. Different readers have different viewpoints. Clearly stating things we expect to be constants in the universe using SHALL statements makes sense to me and avoids alternative interpretations or doubt from easily arising.

technogeek00 · 2019-02-06T06:15:03Z

DASH-IF-IOP.bs.md

+
+#### Inaccuracy in media segment timing when using simple addressing #### {#timing-addressing-inaccuracy}
+
+When using [=simple addressing=], the samples contained in a [=media segment=] MAY cover a different time span on the [=sample timeline=] than what is indicated by the nominal timing in the MPD, as long as no constraints defined in this document are violated by this deviation.


From @haudiobe: There is a very clear and detailed requirement on this in v4.3. Please check 3.2.7.1

I do not understand the purpose of this comment.

I agree that there is some text in 3.2.7.1 that has a certain degree of overlap.

OK so we need to combine 3.2.7.1 with this text?

Yes, this text is not meant to be purely additive. It restates parts of IOP v4.3 in many places, simply with more clarified wording.

technogeek00 · 2019-02-06T06:16:38Z

DASH-IF-IOP.bs.md

+
+## Segment alignment ## {#timing-segmentalignment}
+
+[=Media segments=] are said to be aligned if the start/end points of all [=media segments=] on the [=sample timeline=] are equal in all [=representations=] that belong to the same adaptation set.


start/end points of all media segments on the sample timeline are equal

From @haudiobe: Please check MPEG-DASH – very clearly defined in clause 4. The above is not correct as it would not allow different frame rates in one adaptation set.

If different frame rates would lead to non-aligned segments then YES they are not allowed in one adaptation set.

However, it does not necessarily follow that different frame rates would lead to non-aligned segments. You can still do it with alignment, you just cannot do it arbitrarily but have to maintain the alignment.

acbegen · 2019-02-06T14:51:41Z

I agree with Thomas. SHALL statements require testing for interoperability. Definitions do not (though everybody needs to implement it that way). If you want it to use for definition, I suggest you use lower case "shall" or "must", as the uppercase versions have a different meaning.
In a document like IOP, I would not expect too many SHALL (as opposed to what we have now in IOP5).

to align with widespread terminology. #246

sandersaares · 2019-05-14T09:52:29Z

The content is merged into master branch but I leave this PR open as some discussions on language aspects here might still be beneficial (potentially). However, for any new comments please open new issues on GitHub.

technogeek00 · 2019-05-23T10:02:40Z

Closing actual PR as contents have been merged, can reference back in closed state for historical conversations.

Period splitting example for 166 and 178

5ba8940

sandersaares added 6 commits November 7, 2018 14:11

Clarify wording of SegmentBase subset

93ca880

Clarify durations on diagram

2532c77

Wording clarification

02d7540

Disambiguate wording

57236bf

presentationDuration

9d947ba

Expand timing model description from concise form

46a9cfe

sandersaares changed the title ~~Period splitting example for #166 and #178~~ DASH timing model that forbids short representations but permits free period splitting Nov 12, 2018

sandersaares added 6 commits November 12, 2018 16:30

Wording

5ef9fea

Fix incorrect word

b10a5c4

Dynamic MPD can have duration

7be9ec0

Fix duplicate "Period 1"

03672dd

Attempt to clarify wording of PTO for live profile

46567ab

Resolve issue on continuity reference direction

0d35675

ojw28 reviewed Nov 14, 2018

View reviewed changes

sandersaares added 10 commits November 14, 2018 12:15

Period start/duration must be accurate

85da68b

the -> a

5024152

mediaPresentationDuration with dynamic -> SHALL/SHALL NOT

6e47cc7

Give names to addressing modes

2443532

Much edits.

a5e86c7

Make it more explicit that the period ends must be accurate.

88aab52

More illustrations and such

d2611bc

Continuity -> Connectivity

2790040

next/previous -> future/past

e0e4bed

Language

22ee7d0

sandersaares mentioned this pull request Nov 16, 2018

Does IOP specify handling of "video+audio -> video-only" transitions well enough? #216

Open

sandersaares added 2 commits November 16, 2018 14:31

Merge 3.2.12

af9c040

Mention the schemeIdUri for continuity

23569cd

sandersaares added 10 commits December 30, 2018 08:42

Remove needless MPD@mediaPresentationDuration from example

ec67c92

Clean up explicit addressing diagram

dc5ccad

Do not have to modify <S> on partial expiration

c71748e

$number$ is allowed in SegmentTimeline!

c7635e0

xlink example

f5b4508

Improved image captioning

295e331

startNumber might need to change with explicit addressing

f3df1e7

Clarify note

243fd71

Remove editorial notes - not super needed anymore

c05ee24

XLink chapter

12b587d

technogeek00 reviewed Jan 16, 2019

View reviewed changes

DASH-IF-IOP.bs.md Outdated Show resolved Hide resolved

DASH-IF-IOP.bs.md Outdated Show resolved Hide resolved

DASH-IF-IOP.bs.md Outdated Show resolved Hide resolved

DASH-IF-IOP.bs.md Outdated Show resolved Hide resolved

sandersaares mentioned this pull request Jan 23, 2019

Revisit Initialization range requirement for on-demand content #242

Closed

sandersaares changed the title ~~DASH timing model that forbids short representations but permits free period splitting~~ Interoperable DASH timing model Jan 29, 2019

sandersaares added 3 commits February 5, 2019 13:49

x

aa22d3a

MPD@sPD clarifications

e824946

Remove XLink recursion constraint (ref Dash-Industry-Forum#267)

1a5cf18

Unknown what right thing to do is

technogeek00 reviewed Feb 6, 2019

View reviewed changes

technogeek00 modified the milestones: IOP v5, Interoperable Timing Model PR Mar 19, 2019

sandersaares added 3 commits April 2, 2019 14:00

Minor adjustments

5fd5f03

Reference "verbose names" of addressing modes #246

39196cc

Renamed "time shift window" to "time shift buffer"

a1a727f

to align with widespread terminology. #246

technogeek00 closed this May 23, 2019

sandersaares mentioned this pull request Nov 25, 2019

Do not allow inaccuracy when using SegmentTimeline Dash-Industry-Forum/Guidelines-TimingModel#20

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Interoperable DASH timing model #210

Interoperable DASH timing model #210

sandersaares commented Nov 7, 2018 •

edited

Loading

documentbot commented Nov 7, 2018 •

edited

Loading

sandersaares commented Nov 12, 2018

technogeek00 left a comment

technogeek00 left a comment

technogeek00 Feb 6, 2019

sandersaares Feb 6, 2019

technogeek00 Feb 6, 2019

sandersaares Feb 6, 2019

technogeek00 Feb 6, 2019

sandersaares Feb 6, 2019

haudiobe Feb 6, 2019

sandersaares Feb 7, 2019

technogeek00 Feb 6, 2019

sandersaares Feb 6, 2019

technogeek00 Feb 6, 2019

sandersaares May 14, 2019

technogeek00 Feb 6, 2019

sandersaares May 14, 2019

technogeek00 Feb 6, 2019

sandersaares Feb 6, 2019

technogeek00 Feb 6, 2019

sandersaares Feb 6, 2019

haudiobe Feb 6, 2019

sandersaares Feb 7, 2019 •

edited

Loading

technogeek00 Feb 6, 2019

sandersaares May 14, 2019

acbegen commented Feb 6, 2019

sandersaares commented May 14, 2019

technogeek00 commented May 23, 2019


		This chapter describes an interoperable view of DASH presentation timing and segment addressing. This interpretation is considerably narrower than afforded by [[MPEGDASH]], constraining services to a specific set of reasonably flexible behaviors that are highly interoperable with modern client platforms. Services conforming to this document SHALL use this timing model.


		The playback of a static MPD SHALL NOT depend on the mapping of the MPD timeline to real time. A client MAY play any part of the presentation at any time.


		The playback of a static MPD SHALL NOT depend on the mapping of the MPD timeline to real time. A client MAY play any part of the presentation at any time.

		The MPD timeline of a dynamic MPD SHALL have a fixed mapping to real time, with each point on the timeline corresponding to a point in real time. Clients MAY introduce an additional offset with respect to real time [[#timing-timeshift\|to the extent allowed by the time shift signaling in the MPD]].


		Note: In addition to mapping the content to real time, [[#timing-mpd-updates\|a dynamic MPD can be updated during the presentation]]. Updates may add new periods and remove or modify existing ones, though some restrictions apply. See [[#timing-mpd-updates]].

		The zero point in the MPD timeline of a dynamic MPD SHALL be mapped to the point in real time indicated by `MPD@availabilityStartTime`. This value SHALL NOT change between MPD updates.


		Note: Only additional references are counted, so `S@r=5` indicates a total of 6 consecutive [=media segments=] with the same duration.

		The start time of a [=media segment=] SHALL be calculated from the start time and duration of the previous [=media segment=] if not specified by `S@t`. There SHALL NOT be any gaps or overlap between [=media segments=].


		#### Inaccuracy in media segment timing when using simple addressing #### {#timing-addressing-inaccuracy}

		When using [=simple addressing=], the samples contained in a [=media segment=] MAY cover a different time span on the [=sample timeline=] than what is indicated by the nominal timing in the MPD, as long as no constraints defined in this document are violated by this deviation.


		## Segment alignment ## {#timing-segmentalignment}

		[=Media segments=] are said to be aligned if the start/end points of all [=media segments=] on the [=sample timeline=] are equal in all [=representations=] that belong to the same adaptation set.

Interoperable DASH timing model #210

Interoperable DASH timing model #210

Conversation

sandersaares commented Nov 7, 2018 • edited Loading

documentbot commented Nov 7, 2018 • edited Loading

Automated build report

sandersaares commented Nov 12, 2018

technogeek00 left a comment

Choose a reason for hiding this comment

technogeek00 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sandersaares Feb 7, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

acbegen commented Feb 6, 2019

sandersaares commented May 14, 2019

technogeek00 commented May 23, 2019

sandersaares commented Nov 7, 2018 •

edited

Loading

documentbot commented Nov 7, 2018 •

edited

Loading

sandersaares Feb 7, 2019 •

edited

Loading