Harmonize the sparse track

[RufaelDev]

Currently there is a notion of sparse track that is an ISOBMFF track that contains event messages or other metadata (SCTE-35, id3), this track is also described in the event TF and was proposed to CMAF where it is a TuC this issue is to track the discussion on harmonization of the notion of sparse metatrack, in particular in the ingest spec itself.

• signalling of duration
• avoiding timeline gaps
• signalling advertisement (when the event becomes visible) and application times

[RufaelDev]

doc on timed metadatatrack under discussion:
https://drive.google.com/file/d/1KHcG-0b2JsYC8pwp28Iido-lAnBH7Rur/view?usp=sharing

[RufaelDev]

TF Call 27: low latency and metatrack , make sure LL is not affected

• send in advance
• different source
• pass through
• packager flexibility
• critical emsg -> multiple emsg repeat with same id
• emsg in metadatatrack

[RufaelDev]

CMAF supports timed metadata tracks, we should refer to that and only introduce additional constraints for embedding dash event message boxes, which may be multiple in a sample. Section should be cleaned up to avoid definitions that already exist in CMAF.

[RufaelDev]

add the carriage of id3 in DashEventMessageBox as in https://aomediacodec.github.io/av1-id3/

[RufaelDev]

CMAF timed metadata tracks already supported, try to refer and only have additional constraints in the spec.

[RufaelDev]

The lastest revision clearly separates the usage of CMAF timed metadata track in clauses 1-8 and the CMAF timed metadata track carrying event message boxes, this is important as the latter may need some more work for standardization and checking

[RufaelDev]

addressed: #143