RufaelDev
commented
5 years ago I consider this as unreasonable feedback
- The community review was closed on aug 31st, in this time no such negative feedback was received
- none of the issues specified are addressed in other parts of the draft, this track solves issues that were left unaddressed for timed metadata tracks and event processing, and solves the hiatus
- the track uses events defined in DASH and is therefore in scope of the work item
- you cannot use redundant samples to signal an id and value as needed by event api, this is impossible
- you cannot use duration 0 in a simple timed metadata track, being aware of it does not solve this
- multiplexing is not allowed in CMAF tracks, multiplexing for streaming is not considered good practice in streaming in general
- again value and id are part of client processing model, so they need to be available otherwise the processing model cannot be used as defined in this document, including the client api.
- yes overlap, it was solved in webvtt, but broadcast events may be much longer, also that spec is not referenced in this specification, it only works for webvtt cues. It is not clear if that solution will work. This spec needs to define an approach similar to that, and this clause comes closest for events.
- I think this is important for DASH IF and DASH in general, to have a consistent processing model for events, carriage as timed metadata should also be considered.
- I checked the scope of the workitem, it looks in scope as it deals with processing of DashEventMessageBoxes
- other standard bodies already look at this like MISB and it applied to their use case aswell.
- It is already used by major companies in the streaming industry
- taking all this into consideration I find this comment to be unreasonable
irajs
haudiobe
This issue has nothing to do with event processing and should therefore be removed.
Timed metadata tracks are a lightweight structure for carrying information related to a media presentation. However, some drawbacks of such a simple ISOBMFF timed metadata track are that:
value= value in DashEventMessageBox is not present to signal sub-schemes
id= id used in DashEventMessageBox is not used, so processing cannot detect duplicate metadata samples
disagree on this, you can always use redundant samples instead
multiple samples at the same time are not allowed, due to ISOBMFF constraints (duration 0 is not allowed, two samples with same presentation time in track is not allowed), while MPD and inband events may have concurrent instances.
which is not necessarily a problem if you are aware of it. Then you need to define a payload system for your event to aggregate more messages
restricting the track to one scheme per timed metadata track is restrictive, while in a single MPD or a single Represenation multiple MPD/inband event schemes can be used
well, this is not a problem if we allow multiplexed metadata tracks. This would be easy and we can permit multiplexing for non-media tracks
the parameters value and id are not available and cannot be passed to the API
this issue is not really important, as the value can be part of the metadata track identifier
a new timed metadata occuring before the end of prior sample duration is not allowed while overlapping events, however, is possible with MPD and inband events
again this problem has been solved for subtitles, so it can surely be solved also for timed metadata
Therefore, a DASH Event compatible timed metadata track that solves these drawbacks is defined and recommended. The DASH Event compatible timed metadata track, a metadata track with embbeded event message boxes is formatted as follows:
This clause is not suitable here. If at all, it should be developed in MPEG. It is also outside the scope of the work item. Hence no more technical comments are provided