DASH-IF-IOP
DASH-IF-IOP copied to clipboard
Core features vs Basic constraints
It seems the core features should be the list for features commonly supported and then the basic contraints are set for those core features. Suggest to combined these two sections, and find a logical way of describing the common features. The constraints for each feature can be listed under that feature.
Recommended order of core features and basic constraints:
- CMAF constraints
- General CMAF requirements
- Representation/track constraints
- Segment constraints
- SAP
- duration
- URL resolution
- large scale and time values
- clock drift
- Adaptation/Switching set constraints
- single decoder requirement and time scale requirement
- seamless switching
- segment alignment
- adaptation set types
- video AS
- audio AS
- Text AS
- multiple periods
- period splicing conditions
- cross period signaling
- MPD constraints
- buffer signaling
- real time clock sync
- representation duration in xml
- MPD size
Also move (Expanding URL templates) to (Segment addressing) section
-
If we start with the assumption that the CMAF DASH Profile is base conformance, then the question I have is how duplicative constraint specification will be. It seems more like we will detail proper signalling in the IOP, but the constraints for a single CMAF Presentation will be driven by the CMAF Profile and not the IOP. There are certainly additional constraints that we will need to detail for cross period/presentation points.
Yeah, we should avoid duplicating.
A good deep review of what we have and migration to CMAF DASH profile would be good. Ideally, the outcome would be an understanding that we can get rid of a lot of our text and/or migrate it to CMAF DASH profile (if not already there).
I have been meaning to try do such a review but so far it is stuck on the intentions stage and in practical terms I doubt I can do anything on this topic before July.
Related: https://github.com/Dash-Industry-Forum/DASH-IF-IOP/issues/371#issuecomment-558067589