5.2.2. Representations

[irajs]

CHANGE TO:

A representation is a sequence of segment references and a description of the samples within the referenced media segments [MPEGDASH] 5.3.1 and 5.3.5. Each representation belongs to exactly one adaptation set and to exactly one period, although a representation may be connected with a representation in another period.

Each segment reference addresses a media segment that corresponds to a specific time span on the sample timeline. Each media segment contains samples for a specific time span on the sample timeline.

Note: Simple addressing allows the actual time span of samples within a media segment to deviate from the nominal time span described in the MPD. All timing-related clauses in this document refer to the nominal timing described in the MPD unless otherwise noted.

The exact mechanism used to define segment references depends on the addressing mode used by the representation. This document requires the additional requirement to [MPEGDASH]: all representations in the same adaptation set SHALL use the same addressing mode.

As required by [MPEGDASH], in a static MPD, a representation must contain enough segment references to cover the entire time span of the period.

As required by [MPEGDASH], in a dynamic MPD, a representation must contain enough segment references to cover the time span of the period that intersects with the time shift buffer.

Note: In dynamic MPD, media segments only become available when their end point is within the availability window. It is a valid situation that a media segment is required to be referenced but is not yet available.

As [MPEGDASH] requires, a dynamic MPD must remain valid for its entire validity duration after publishing. In other words, a dynamic MPD mustsupply enough segment references to allow the time shift buffer to extend to now + MPD@minimumUpdatePeriod, where now is the current time according to the synchronized clock.

???An unnecessary segment reference is one that is not defined as required by this chapter.???

This document requires the additional following constraints: In a static MPD, a representation SHALL NOT contain unnecessary segment references, except when using indexed addressing in which case such segment references MAY be present.

[MPEG-DASH] requires that In a dynamic MPD, a representation must contain unnecessary segment references except when any of the following applies, in which case an unnecessary segment reference may be present:

The segment reference is for future content and will eventually become necessary.

The segment reference is defined via indexed addressing.

The segment reference is defined by an element that defines multiple references using S@r, some of which are necessary.

Removal of the segment reference is not allowed by content removal constraints.

[MPEGDASH] requires that there must not be gaps or overlapping media segments in a representation of any period.

This document adds the following requirements for clients: Clients SHALL NOT present any samples from media segments that are entirely outside the period, even if such media segments are referenced.

Media segment start/end points may be unaligned with period start/end points.

This document requires the following: If a media segment overlaps a period boundary, clients SHOULD NOT present the samples that lie outside the period and SHOULD present the samples that lie either partially or entirely within the period.

Note: In the end, which samples are presented is entirely up to the client. It may sometimes be impractical to present media segments only partially, depending on the capabilities of the client platform, the type of media samples involved and any dependencies between samples.

[haudiobe]

Comments in italics

A representation is a sequence of segment references and a description of the samples within the referenced media segments [MPEGDASH] 5.3.1 and 5.3.5.

A Representation is not just references, it is the Segments itself

Each representation belongs to exactly one adaptation set and to exactly one period, although a representation may be connected with a representation in another period.

I do not understand why this is needed. If I repeat a Representation in a Period, I can do so. Unnecessary and confusing additional text.

Each segment reference addresses a media segment that corresponds to a specific time span on the sample timeline. Each media segment contains samples for a specific time span on the sample timeline.

Note: Simple addressing allows the actual time span of samples within a media segment to deviate from the nominal time span described in the MPD. All timing-related clauses in this document refer to the nominal timing described in the MPD unless otherwise noted.

Nominal timing is called MPD time in MPEG DASH. Why create new terminology?

What does "simple addressing" mean?

The exact mechanism used to define segment references depends on the addressing mode used by the representation. This document requires the additional requirement to [MPEGDASH]: all representations in the same adaptation set SHALL use the same addressing mode.

As required by [MPEGDASH], in a static MPD, a representation must contain enough segment references to cover the entire time span of the period.

I do not understand what this means. And if we reference MPEG-DASH, then we should reference the exact clause. MPEG-DASH does not require the above by the way. It is only a recommendation.

As required by [MPEGDASH], in a dynamic MPD, a representation must contain enough segment references to cover the time span of the period that intersects with the time shift buffer.

Segment references is wrong. I also do not understand why we write this. This is the definition of the time shift buffer, but no requirement.

Note: In dynamic MPD, media segments only become available when their end point is within the availability window. It is a valid situation that a media segment is required to be referenced but is not yet available.

The above only true if the @availabilityTimeOffset is not set. And we have well defined terms for end point. It is called MPD end time.

As [MPEGDASH] requires, a dynamic MPD must remain valid for its entire validity duration after publishing. In other words, a dynamic MPD mustsupply enough segment references to allow the time shift buffer to extend to now + MPD@minimumUpdatePeriod, where now is the current time according to the synchronized clock.

Again we are mixing definitions and requirements. We also have the term valid. MPEG-DASH has defined all of the terms carefully. Why are we creating new ones?

???An unnecessary segment reference is one that is not defined as required by this chapter.???

This document requires the additional following constraints: In a static MPD, a representation SHALL NOT contain unnecessary segment references, except when using indexed addressing in which case such segment references MAY be present.

Completely unclear. What is an unnecessary segment?

[MPEG-DASH] requires that In a dynamic MPD, a representation must contain unnecessary segment references except when any of the following applies, in which case an unnecessary segment reference may be present:

The segment reference is for future content and will eventually become necessary.

Again. MPEG-DASH defines valid for this purpose.

The segment reference is defined via indexed addressing.

This is not true either. In DASH you may also have a Segment List, that goes far into the future. Why are we writing this all of this?

[irajs]

I tried to combine the comments and the text. Please look at the pull request for the updated text. However there are the following statements that we should discuss whether we need them:

An unnecessary segment reference is one that is not defined as required by this chapter.

This document requires the following additional requirements to [[MPEGDASH]]:

• In a [=static MPD=], a [=representation=] SHALL NOT contain [=unnecessary segment references=], except when using [=indexed addressing=] in which case such segment references MAY be present.

• In a [=dynamic MPD=], a [=representation=] SHALL NOT contain [=unnecessary segment references=] except when any of the following applies, in which case an [=unnecessary segment reference=] MAY be present:

1. The [=segment reference=] is for future content and will eventually become necessary.
2. The [=segment reference=] is defined via [=indexed addressing=].
3. The [=segment reference=] is defined by an <S> element that defines multiple references using S@r, some of which are necessary.
4. Removal of the [=segment reference=] is not allowed by [[#timing-mpd-updates-remove-content|content removal constraints]].

[sandersaares]

A Representation is not just references, it is the Segments itself

You are right. I have adjusted the text to better express this.

I do not understand why this is needed. If I repeat a Representation in a Period, I can do so. Unnecessary and confusing additional text.

I have added explicit notice that timing model considers repeated/reused representations as distinct instances, treating each one individually. Mostly this is because I do not want to repeat the long and wordy "usage of representation" or equivalent term everywhere. It would be better if MPEG made a distinction between "representation" and "usage of representation" and provided a shorter term here but that ship sailed long ago.

Nominal timing is called MPD time in MPEG DASH. Why create new terminology?

If it is, it is not clearly expressed. The whole point of the timing model document is to more clearly express how to do DASH timing in an interoperable way, so do not be surprised to see concepts explained in different ways than done in MPEGDASH.

What does "simple addressing" mean?

SegmentTemplate with Duration. Click on the link in the document to go to description in the addressing chapter.

I do not understand what this means. And if we reference MPEG-DASH, then we should reference the exact clause. MPEG-DASH does not require the above by the way. It is only a recommendation.

Agreed.

Segment references is wrong. I also do not understand why we write this. This is the definition of the time shift buffer, but no requirement.

We write this to clearly explain how DASH timing works in interoperable scenarios. It is not clear to me what you mean by your 1st and 3rd sentence here.

The above only true if the @availabilityTimeOffset is not set. And we have well defined terms for end point. It is called MPD end time.

The chapter has been adjusted in editing to hopefully remove this confusing aspect.

MPD end time is a very confusing term (is the MPD ending??) and is intentionally not used in the interoperable timing model description.

Again we are mixing definitions and requirements. We also have the term valid. MPEG-DASH has defined all of the terms carefully. Why are we creating new ones?

The text has been amended to improve clarity, changes not yet published on publisc URL (to avoid changing text under community review). Terminology point already addressed above.

Completely unclear. What is an unnecessary segment?

I have adjusted text to better express what is meant.

Again. MPEG-DASH defines valid for this purpose.

Unclear what this comment is intended to say.

This is not true either. In DASH you may also have a Segment List, that goes far into the future. Why are we writing this all of this?

Usage of segment list is not considered interoperable by DASH-IF implementation guidelines, so it does not exist in our universe.

However there are the following statements that we should discuss whether we need them:

Sure. Do we have anything actionable here? Any specific comments or proposals? If no further comments, I would close this issue.

[sandersaares]

Proposed resolution: close the issue.

Rationale: Iraj's PR was merged and I also added many clarifications to the text to continue his work, to better connect to underlying standards. Even if further work remains in some areas, it should be handled as separate issues with a narrower scope.

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

[haudiobe]

(IOPv5 20/02/12): No Comments received. Closed!