Require consistent AdaptationSet/Representation ordering across MPD updates?

[ojw28]

Across an MPD update, is it allowed that:

1. AdaptationSet elements change order within a containing Period?
2. Representation elements change order within a containing AdaptationSet?

If there's currently any ambiguity around this issue, I'd propose adding a clause to 4.4.3.3 requiring that these orders stay the same across manifest updates. It makes the client's life easier, because it allows the client to track state using indices into Period and AdaptationSet structures, and rely on those indices referring to the same things across manifest updates.

Note also that AdaptationSet@id appears to be optional. If AdaptationSet elements can change order and if AdaptationSet@id is omitted, it might not be trivial for the client to even figure out what happened across a manifest update.

[sandersaares]

I agree with the clear need to ensure that a reader can accurately match up elements before/after an update.

Having the order of XML elements be significant feels like a solution that is bound to run into trouble at edge cases, however. I can imagine there being XML producer/consumer libraries that do not preserve order at all. I can also imagine there being situations where a packager needs to assemble a new MPD without knowledge of any previous order (and without any unambiguous way to order them).

I would therefore favor a solution that requires unique IDs on adaptation sets, to remove the possibility of ambiguity.

Ideally, the live source simulator could also be extended with a feature to randomize order at manifest updates, to be able to easily test client behavior on this.

[ojw28]

I can imagine there being XML producer/consumer libraries that do not preserve order at all.

There are other parts of DASH manifests were ordering is required (e.g. S elements in a timeline). So it's unclear to me whether such libraries would really be suitable for manifest processing. Although I guess certain flavors of manifest might avoid all parts of the spec where element ordering is required.

I can also imagine there being situations where a packager needs to assemble a new MPD without knowledge of any previous order (and without any unambiguous way to order them).

If unique IDs are going to be required then don't they provide a unique and unambiguous ordering for whatever is assembling the manifest (i.e. sort by ID)?

[sandersaares]

There are other parts of DASH manifests were ordering is required

OK, fair point. I withdraw my objection to ordering. Given existing requirements on ordering, I am reasonably comfortable assuming that order is understood by whatever XML libraries are used to process DASH.

If unique IDs are going to be required then don't they provide a unique and unambiguous ordering for whatever is assembling the manifest (i.e. sort by ID)?

Mmmmmm, yeah I suppose that is true.

Wait what was that?

Ah I hear xlink knocking on the door! Some elements might only get resolved by the client, with the packager not yet knowing what the id values will be. This xlink topic is really messing with my head. With xlink elements, no attributes are mandatory in any case, so the only way to maintain identity of xlink elements is by element index.

I guess that paints the picture for us regardless?

[sandersaares]

So yes, after consideration I agree with this proposal - order of elements should not change with MPD updates, especially as the order is the only thing we have with xlink.

[technogeek00]

I can agree with the proposal of requiring consistent ordering across updates, though I would like to see us also make AdaptationSet@id required, seems like an odd omission.

[haudiobe]

Option 1: Strong Recommendation to do it, but client shall implement based on ID Option 2: We mandate the ordering.

We make option 2 the default unless someone has good reasons for Option 1. We close this by Feb 5 call.