Comments on clause 4.0

[haudiobe]

On the figure The figure should add the case where the arrival time is after the event start time and the duration is signaled. In this case dispatch is done later. The mode is not clearly explained.

In this figure, two modes are shown:

on-receive Dispatch Mode: Dispatching at AT or earlier.

It is unclear how you can dispatch before something has arrived

Since the segment carrying an emsg/metadata sample has to be parsed before (or assuming zero decode/rendering delay as the latest at) AT on the media timeline, the event/metadata sample shall be dispatched at this time or before to Application in this mode.

what does it mean: "it shall be dispatched"? I believe the model is that you dispatch the event when you load the segment into the decode buffer and when ISO BMFF parsing starts. So I would not make this a shall, a recommendation that the data is dispatched at the time when the containing segment is parsed

Application has a duration of ST-AT for preparing for the event. In this mode, the client doesn’t need to maintain states of Application events or metadata samples either.

but this is not relevant here. It should be important what data fields are created.

Application may have to maintain the state for any event/metadata sample, its ST and DU, and monitor its activation duration, if it needs to. Application also needs to schedule each event/sample at its ST, so it must be time-aware to properly make use of these timing parameters.

this is an assumption, the interpretation of the timing is left to the application AFAIK. The whole description is not instructive enough to understand what the client exactly does. DASHEventProcessingModel-v2.4.pptx. The attached slide set has a better description here.

on-start Dispatch Mode: Dispatching exactly at ST, which is the start/presentation time of the event/metadata sample.

DASH Player shall calculate the ST for each parsed event/metadata sample and dispatch the message_data at this exact moment.

The requirement is: The DASH player shall dispatch the event to the application when the media time of the corresponding media is played, or at the earliest time within the event duration.

In this mode, since Application receives the event/sample at its start/presentation time, it needs to act on the received data right away, i.e. no advanced notice is given to Application in this mode. Application however may not need to maintain a state for the events and timed metadata samples, if the durations and/or the sequence and order of events/samples are not important to Application. Depending on the nature, meaning and relationship between different event instances/metadata samples, Application may need to maintain the state for them.

The above is too much information, not even sure it is correct. We can write some information on how the application behaves, but should do this separately from the requirements for the DASH client (or better said for the event parser). The best is to have a very clear set of requirements that can either be referenced by or moved to CTA DPC spec

Note: According to ISO/IEC 23009-1, the parameter duration has a different meaning in each dispatch mode. In the case of on-start, duration defines the duration starting from ST in which DASH Player shall disp atch the event exactly once. In the nromal playback, the player dispatches the event at ST. However if DASH Player for instance seek to a moment after ST and during the above duration, then it must dispatch the event immidiately. In the case of on-receive, duration is a property of event instance and is defined by the scheme_id owner.

The note may stay, but it needs to be put into a requirement as above.

[haudiobe]

(Event TF 2019/09/20) Agree to not add this to initial version

[irajs]

The above comment (agree to not to add..) belongs to section 3 and not 4._

_On the figure The figure should add the case where the arrival time is after the event start time and the duration is signaled. In this case dispatch is done later. The mode is not clearly explained.

This case is arrival time after ST which is not possible in normal playback. Since the event is always received at <LAT =<ST, dispatching at time ST<t=<ST+DU can occur in normal playback only if the client receives the segment but not process the event, which should not be the case. If the case is random access to a moment in range ST<t=<ST+DU, the client doesn't see the segment carrying the event.

In this figure, two modes are shown:

on-receive Dispatch Mode: Dispatching at AT or earlier.

It is unclear how you can dispatch before something has arrived

changed the term to LAT, to show this is the latest possible arrival time and not the actual arrival time.

Since the segment carrying an emsg/metadata sample has to be parsed before (or assuming zero decode/rendering delay as the latest at) AT on the media timeline, the event/metadata sample shall be dispatched at this time or before to Application in this mode.

what does it mean: "it shall be dispatched"? I believe the model is that you dispatch the event when you load the segment into the decode buffer and when ISO BMFF parsing starts. So I would not make this a shall, a recommendation that the data is dispatched at the time when the containing segment is parsed

Since the event buffer is different than the decoder buffer, the events with receive dispatch can be/shall be dispatched earlier their decoding time.

Application has a duration of ST-AT for preparing for the event. In this mode, the client doesn’t need to maintain states of Application events or metadata samples either.

but this is not relevant here. It should be important what data fields are created.

it shows the benefits and drawbacks of this dispatch mode for the application.

Application may have to maintain the state for any event/metadata sample, its ST and DU, and monitor its activation duration, if it needs to. Application also needs to schedule each event/sample at its ST, so it must be time-aware to properly make use of these timing parameters.

this is an assumption, the interpretation of the timing is left to the application AFAIK. The whole description is not instructive enough to understand what the client exactly does. DASHEventProcessingModel-v2.4.pptx. The attached slide set has a better description here. revised and shorten it.

on-start Dispatch Mode: Dispatching exactly at ST, which is the start/presentation time of the event/metadata sample.

DASH Player shall calculate the ST for each parsed event/metadata sample and dispatch the message_data at this exact moment.

The requirement is: The DASH player shall dispatch the event to the application when the media time of the corresponding media is played, or at the earliest time within the event duration.

changed it to: The DASH player shall dispatch the event to the application at the presentation time of the corresponding media sample, or in the case of passing that moment, at the earliest time within the event duration.

In this mode, since Application receives the event/sample at its start/presentation time, it needs to act on the received data right away, i.e. no advanced notice is given to Application in this mode. Application however may not need to maintain a state for the events and timed metadata samples, if the durations and/or the sequence and order of events/samples are not important to Application. Depending on the nature, meaning and relationship between different event instances/metadata samples, Application may need to maintain the state for them.

The above is too much information, not even sure it is correct. We can write some information on how the application behaves, but should do this separately from the requirements for the DASH client (or better said for the event parser). The best is to have a very clear set of requirements that can either be referenced by or moved to CTA DPC spec

Changed it to: In this mode, since Application receives the event/sample at its start/presentation time, it may need to act on the received data immediately.

Note: According to ISO/IEC 23009-1, the parameter duration has a different meaning in each dispatch mode. In the case of on-start, duration defines the duration starting from ST in which DASH Player shall disp atch the event exactly once. In the nromal playback, the player dispatches the event at ST. However if DASH Player for instance seek to a moment after ST and during the above duration, then it must dispatch the event immidiately. In the case of on-receive, duration is a property of event instance and is defined by the scheme_id owner.

The note may stay, but it needs to be put into a requirement as above.

Changed to reflect the note: The DASH player shall dispatch the event to the application at the presentation time of the corresponding media sample, or in the case of the start of playback after that moment and during the event duration, at the earliest time within the event duration. In this mode, since Application receives the event/sample at its start/presentation time, it may need to act on the received data immediately.

[haudiobe]

(Event TF - 19/10/04) Check implementation, if no further comments, will closed at next Event TF.