Terminology alignment with MPEG-DASH?

[irajs]

Some of the terminology used in the document is not exactly aligned with MPEG-DASH. We need to decide whether we want to keep it aligned , or if differing, add a note to each new term on how relates to MPEG-DASH corresponding term.

Examples: Segment addresses (MPEG-DASH) vs Segment References (here) representation is a sequence of segments (MPEG-DASH) vs representation is a sequence of segment addresses (here) time shift buffer vs time shift window

[haudiobe]

IOP 19/01/29: agree to align, but if MPEG is confusing we clarify this and share this with MPEG

[sandersaares]

The terminology chosen for the contribution in Dash-Industry-Forum/DASH-IF-IOP#210 is selected for clarify of understanding as a stand-alone text. A strong connection to MPEG-DASH has not been a priority for me in creating it. MPEG-DASH is treated in this text as a source of algorithms and MPD XML schema definitions.

Taking a closer look at the examples in the post above:

• Segment address VS reference. This is because in case of indexed addressing, segments do not have individual addresses but rather have address+byterange. The MPEG-DASH notion that in case of indexed addressing the whole mp4 file is "a segment" I reject outright as silly.
• What a representation is - references or segments - I think this aspect of the definition is rather insubstantial. Might be feasible to do some alignment here during merging of the document but overall this seems like not worth much attention.
• Time shift buffer / window is a deliberate choice to emphasize that it is a measure of time, not of data. I am sure this distinction has an element of subjectiveness to it but so it is. See also "availability window".

[acbegen]

Well, certainly alignment is important. Someone reading the mpeg spec and ours should not get confused. On the specific items above: 1) Segment address can contain a byte range, that is not confusing or wrong at all. "Segment reference" should be dropped. 2) Representations are not a sequence of segment addresses. 3) Timeshift window makes sense to me, but the industry is so much used to the term timeshift buffer. So, we should mention somewhere they are interchangeably used.

[sandersaares]

Yeah probably time shift window does not pass the bar for benefit/confusion ratio and should become time shift buffer in this text. It really is used a lot with specific meaning.

In colloquial terms an address is a URL. URLs do not contain byte ranges. Therefore "segment address" that contains a byte range is a very confusing concept. MPEG confusing terminology is not a positive contribution to IOP and I think we need to prefer clarify over alignment.

[haudiobe]

IOP 19/02/19 Use term "segment" as much as possible, but make sure that we add sufficient explanation. Also make sure that the segment addressing mode names are aligned or at least explained

[sandersaares]

Added clarification and mentioned that "segment" equates "CMAF Segment".

Added notes about segment addressings that reference their "verbose names" aka "SegmentTemplate without SegmentTimeline". I think they are already explained sufficiently well, just a reference to their other names was missing.

Renamed "time shift window" to "time shift buffer" to align with widespread terminology.

I invite further pointing-out of terminology that could potentially benefit from alignment or clarification.

[sandersaares]

Digging more in v4.3, I see various sections that give detailed advice on choosing the best addressing mode. I will merge this advice into the addressing modes chapter to explain better what impact the choices have.

[sandersaares]

Lots of work done and lots of comments addressed on this topic. If anything remains, please file new issue.