Spec problems with @segmentAlignment and @subSegmentAlignment

[paulhiggs]

The resolution of issue #48 needs to be reflected in the standard, A new datatype is defined (it was defined in the second edition but then dropped)

<xs:simpleType name="ConditionalUintType">
  <xs:union memberTypes="xs:unsignedInt xs:boolean"/>
</xs:simpleType>

This type is used in 5.3.3.3 for @segmentAlignment and @subSegment alignment as they can convey a boolean or an unsigned integer.

Table 5

@segmentAlignment - default: false - When set to 'true', this specifies that for any two Representations, X and Y, within the same Adaptation ...

@subSegmentAlignment - default: false - If the @subsegmentAlignment for an Adaptation Set is set to 'true', all following ...

Clause 5.10.3.3.6

NOTE 2 If AdaptationSet@SegmentAlignment is an integer larger than 1, the alignment described above applies only to non-overlapping Segments.

--> capitalization is incorrect here

Clause 8.8.2.3

AdaptationSet@SegmentAlignment is present and has value of 'true' or '1';

--> is 'true' and '1' the same thing? --> capitalization is incorrect here

[mikedo]

It was definitely agreed by the AHG (in AMD1) that it was to allow both boolean and "integer" forms. I believe that we also constrained the integer values to 0 (false) and 1 (true). xs:boolean allows '0' and '1' already. Although the NOTE 2 infers semantics for >1, there is no normative supporting text for that. I think we should review the AMD1 output and DoC from DIS ballot, and if that supports what I recall, then:

1. Correct the editorial errors above on capitalization and use of @
2. Delete NOTE 2
3. Clarify the formal definition of the SegmentAlignment and SubSegmentAlignment to be xs:boolean, noting that it can be {true, false, 0, 1}
4. Update the schema to be xs:boolean.

   Else, if there is any evidence that integers other than 0 and 1 were intended, then do the opposite.

[paulhiggs]

It was definitely agreed by the AHG (in AMD1) that it was to allow both boolean and "integer" forms. I believe that we also constrained the integer values to 0 (false) and 1 (true). xs:boolean allows '0' and '1' already. Although the NOTE 2 infers semantics for >1, there is no normative supporting text for that. I think we should review the AMD1 output and DoC from DIS ballot, and if that supports what I recall

If this is the case, then having the datatype as xs:boolean is sufficient as it allows string and numeric representations ['true', '1', 'false', '0']

Having integer values to represent different options seems somewhat antiquated - in XML it is better to use an enumeration for readability.

[paulhiggs]

example_G19.mpd has two instances of segmentAlignment="0". These could either

• be removed, as false is the default value, or
• be updated to segmentAlignment="false"

Then all example manifests will only use 'true' or 'false'

[mikedo]

I agree, but this has enough history we should confirm with the editing team.

[ZmGorynych]

There was an intent to have integer @segmentAlignment/ @subSegmentAlignment with values larger than 1, back in 2010-2011. This was intended for allowing some segments not to be aligned.

I have never seen this actually used.

[mikedo]

That's good. The fact that there is no normative language at all that describes the details, any implementations would vary based on the author's understanding/need and almost certainly be non-interoperable. I don't see how we can keep it for more than 0/1 (which xs:boolean already covers). At this point, if someone wants to define new behavior it should be in new attribute, and as Paul mentioned, should be an enumeration of meaningful tokens. We should remove NOTE 2 from the 5th Ed text.

[ZmGorynych]

Let's put a note saying something like "previous editions allowed non-boolean values of this attribute", just to make sure people understand that there was such a practice.

[sdp198]

It looks like this was used in the 3rd Edition - table 5 had mroe text against @segmentAlignment

"For Adaptation Sets containing Representations with a single media content component, when two AdaptationSet elements within a Period share the same integer value for this attribute, then for any two Representations, X and Y, within the union of the two Adaptation Sets, the m-th Segment of X and the n-th Segment of Y are non-overlapping (as defined in subclause 4.5.3) whenever m is not equal to n."

I've never seen it used like that though.

[mikedo]

There is no evidence that there was any practice, and the 3rd Ed text is also non-normative and unclear. In the off-chance that someone did implement it >1 in an MPD, what should the DASH client do exactly?

The DASH AHG resolved to permit 0/1 only. Going beyond that at FDIS is inappropriate in my view.

[sdp198]

I'm not arguing in favour of it, just saying there was at one point some text.

Most clients should treat it as "true". Some could, in theory, use it to enable switching Adaptation sets at segment boundaries.

[ZmGorynych]

I would second Mike here. Let's deprecate and note this explicitly. Thomas's subsequences can be used for the same purpose in a slightly more flexible way.

[haudiobe]

I updated the semantics to boolean only, but there are some leftovers that needed cleaning. I did this as well. I also added a Note.

[paulhiggs]

@haudiobe, can you copy in the FDIS information so we can update the schema accordingly? I think I understand what you have done, but...

[haudiobe]

https://mpeg.expert/live/nextcloud/index.php/s/zFPFaZXTYmAoS8S

[paulhiggs]

A new note is added to the FDIS for AdaptationSet@segmentAlignment and AdaptationSet@subSegmentAlignment which says

NOTE: Previous editions permitted non-boolean values for this attribute. As this was not used in practice and caused confusion, it is deprecated in this edition.

However, it is not 'deprecated' but 'removed'. Deprecated infers it is still permitted, but should not be used or a different method should be used, expecting support to be dropped in future.