search

Dash-Industry-Forum / DASH-IF-IOP

DASH-IF Interoperability Points issue tracker and document source code
31 stars 7 forks source link

Ambiguity on the ` "urn:mpeg:dash:period-continuity:2015"` supplemental descriptor #415

Open peaBerberian opened 1 year ago

peaBerberian commented 1 year ago

Hi,

At Canal+, we're looking into indicating period-continuity and/or period-connectivity between AdaptationSet in multiple Periods by defining <SupplementalProperty> elements with respectively a "urn:mpeg:dash:period-continuity:2015" or a "urn:mpeg:dash:period-connectivity:2015" schemeIdUri (I understand that the former imply the latter) to improve the pertinence of our client's track selection logic when encountering Period boundaries with such situations.

In the DASH-IF v4.3, there's a little ambiguity on what to set in the value part of that element:

  1. In 3.2.12 (Content Offering with Periods), we can read:

    Media Presentations should signal period-continuous Adaptation Sets by using a supplemental descriptor on Adaptation Set level with @schemeIdUri set to "urn:mpeg:dash:period-continuity:2015" with: • the @value of the descriptor matching the value of an @id of a Period that is contained in the MPD, • the value of the AdaptationSet@id being the same in both Periods.

    Basically indicating that period-connected AdaptationSet always have the same id property and that the wanted other Period's id is used as a value

  2. However in 3.9.4.8. (Other Annotation, Auxiliary Data), we can read:

    Auxiliary information is expressed by [...] - The Supplemental descriptor with the @schemeIdUri and @value pairs: [...] Period-continuous Adaptation Sets by using Aa @schemeIdUri set to "urn:mpeg:dash:period-continuity:2015" with the @value of the descriptor matching the value of an @id of a Adaptation Set that is contained in the MPD

    Indicating this time that the value should be set to the other AdaptationSet it is continuous with - or at least that's how I understand it.

Which one is right? I would guess (1), as it looks more normative and as it is referenced multiple times in the specification, but that would mean that (2) may be erroneous and should be corrected.

Am I correct?

PS: I tried looking at how other client implementations interpreted it, but it seems to be rarely, if ever, used at least in the open-source DASH clients I looked into, sadly

haudiobe commented 1 year ago

f2f 2022/12/13:

@haudiobe will look into this