Rufael Mekuria

Deriving the SAP type is not very difficult for a packager, if follows straight from the decode and presentation timelines. I am wondering what would be the benefit of deprecating...

One solution would be the handline in azure proposed by microsoft: https://docs.microsoft.com/en-us/azure/media-services/previous/media-services-specifications-live-timed-metadata#22-fragmented-mp4-ingest-smooth-streaming !-- Example Section in MPD --> PD94bWwgdmVyc2lvbj0iMS4wIiBlbm PD94bWwgdmVyc2lvbj0iMS4wIiBlbm note: this needs some updates in DASH IOP and DASH...

Thanks for the pointer that code looks complicated for what should be trivial, we try to avoid embedding xml in xml from a different namespace when we can, for us...

DASH spec is quite clear, and you can find similar definition in ISOBMFF SAP Type 1 corresponds to what is known in some coding schemes as a ”Closed GoP random...

how about 'meta' and allowing extensions meta.XXX ?

I would rather see the first option explained better and the second removed, this for the sake of clarity

The version I have does not have that (15th of april), it states 1...N can you give more examples ?

these were the two points were this information is given: https://dashif-documents.azurewebsites.net/DASH-IF-IOP/master/DASH-IF-IOP.html#audio-constraints https://dashif-documents.azurewebsites.net/DASH-IF-IOP/master/DASH-IF-IOP.html#selection-annotations

was this not part of the metadata adaptation sets ?

I think referring to CMAF may help, as CMAF switching sets have some features that can help as it takes into account these visual disturbances aspect ratio, referencing may help...