MediaInfo: introduce DescriptorType

[stschr]

This PR addresses #4123 and #4124 to the extend that MediaInfo is populated with new elements containing an array of new DescriptorType for all manifest elements of this type (viewpoint, role, accessibility, audioChannelConfiguration).

Old elements are still available to maintain backward compatibility, but could be deleted in future (when migrating to v5.0?).

settings related API (setInitialMediaSettingsForType , setTrack, extractSettings, matchSettings,.. ) are not yet updated. as I'm hesitant to expose two redundant elements to customers.

@dsilhavy : May I ask you to review and provide your feedback? Thank you!

[dsilhavy]

Thanks @stschr I will check it

[dsilhavy]

@stschr Thank you for the PR I left some comments. If you read this in time: Can you joint our dash.js call tomorrow. I would like to discuss this question with you again:

My suggestion would be to save the data as it is done below for supplementalPropertiesAsArray but in supplementalProperties and not use supplementalPropertiesAsArray

We can highlight this change in the release notes in case applications use this attribute in some way. However, the question arises if then do it all at once and remove the old format for viewpoint, role, accessibility, audioChannelConfiguration already here as well.

[stschr]

Thanks @dsilhavy !
Indeed I plan to join the call tomorrow.

Agree - in principle - with all your suggestions.
Changes are WIP, with the low hanging fruits already committed. Hope to get everything 'editorial' done prior to our call tomorrow where we can discuss the non-backward-compatible changes.

[stschr]

Just to get a common understanding:
With the duality of "legacy" vs "new" elements in a 2-phased release, how do we want to handle these names? (e.g. roles and rolesWithSchemeIdUri)

• As discussed yesterday, V4.7.0 will have both names.
• But in V5.0, do we just deprecate=remove the legacy name?
  Or do we want to rename the *WithSchemeIdUri to the 'legacy' name (not nice)? Is such decision still important if we rename the parent object (MediaInfo --> e.g. TracKInfo) ?

Otherwise:
I just rebased my branch with development, thus this PR is ready to be merged.

[dsilhavy]

Thanks @stschr I will check asap.

Regarding your question: In my opinion, we should use the legacy name in version 5. As a user, I would expect to get schemeIdUri and value for each object (role, viewpointetc.). The extension withSchemeIdUri seems to be redundant as I would expect to find this information anyways.

[bbert]

@dsilhavy @stschr
I am rebasing XML parser pull request and face an issue with what has been done in this PR.
As a remind, in XML parser pull request, we take the opportunity for simplification to remove all references to "asArray", while assuming which nodes shall be represented as arrays or not according to the DASH spec.

Regarding SupplementalProperty, these are stored in 2 ways in MediaInfo: supplementalProperties and supplementalPropertiesAsArray, with supplementalProperties as an object with schemeIdUri property as a key.

Is there any valid reason to keep the supplementalProperties as an object, except for the PlaybackController which looks for SupplementalProperty with schemeIdUri equal to DVB LL scheme? In that case we can simply filter the array.

[dsilhavy]

@bbert Thanks we kept this for backwards compatiblity. I agree with you, please see my comment here: #4158 (comment)

[bbert]

@dsilhavy OK fine, so I suggest in XML parser PR to store in supplementalProperties as an array, as I done for all other elements that are parsed as arrays (0..N or 1..N in the spec)