Comments on Clause #1

[haudiobe]

https://dashif-documents.azurewebsites.net/Events/master/event.html#event-architecture

This Figure demonstrates a generic architecture of DASH Player including DASH Events and timed metadata tracks processing models.

This Figure provides a generic reference architecture of a DASH Player including and with special focus to the processing of DASH Event Streams and timed metadata tracks.

In the above figure:

1. DASH Player processes the received MPD. The manifest information including the list of events schemes and values, and timed metadata track schemes are passed to Application.

1. The DASH Player processes the received MPD. For every Period, the MPD may include one or multiple Event Streams (each scope by a scheme/value pair), and Adaptation Sets that carry Representation/tracks for timed metadata. Some or all of these event streams/timed metadata tracks may be suitable for consumption by the application. In the following we refer to any of these streams/tracks as application event streams (AESs)

2. Application subscribes to the event and timed metadata track schemes in which it is interested, with the desired dispatch mode.

2. The Application subscribes to all AESs of interest, and also specifies the desired dispatch mode for each AES.

3. If the manifest includes any MPD Events, the DASH Player parses them and appends them to the Event & Timed Metadata Buffer.

3. If the MPD includes any MPD Event streams, the DASH Player parses each Event in the Event Stream accordingly and appends the relevant data (using a well defined data format as defined in ???) to the Event & Timed Metadata Buffer.

4. Based on the MPD, the DASH Player manages the fetching and parsing of the Segments before appending them to the Media Buffer.

4. Based on the information in the MPD, especially the MPD time of Segments, the DASH Player selects and schedules the fetching of Segments and appends them to the Media Buffer. This is typically done to maintain a stable playback buffer, but segments are typically only accessed close to the time before their playback is scheduled.

5. Parsing a Segment includes:

5. In certain operational modes, the DASH client parses the segments to extract relevant information for its operation. Parsing Segments includes:

1. Parsing the high-level boxes such as Segment Index (sidx) and Event Message boxes, and appending Event Message boxes to the Event & Metadata Buffer.

1. Parsing high-level boxes such as Segment Index (sidx), Event Message (emsg), Producer Reference Time (prft), movie fragment header (moof) boxes, and interpreting the information in the DASH client. For inband event streams, the emsg and typically the moof need to be parsed. The DASH client then uses this information and appends the relevant data (using a well defined data format as defined in ???) to the Event & Timed Metadata Buffer.

2. For an Application-related timed metadata track, the entire Representation/track is parsed including the Initialization Segment (i.e. track header) as well as the Media Segments (i.e. the movie fragments and media data containers).The DASH client then uses this information and appends the relevant data (using the same well defined data format as defined in ???) .

3. For media segments, parsing the segments and appending them to the Media Buffer.

This is not relevant, media segments are not parsed

6.Event & Metadata Buffer is a FIFO buffer, passing the events and timed metadata samples to Event & Metadata Synchronizer and Dispatcher function.

I am not sure they are FIFO? They are time scheduled according to the media presentation time. This should be removed.

7. The DASH Player-specific Events are dispatched to DASH Player’s Control, Selection & Heuristic Logic, while the Application-related Events and timed metadata track samples are dispatched to the application as the following. If an Application is subscribed to a specific Event or timed metadata stream, dispatch the corresponding event instances or timed metadata samples, according to the dispatch mode:

7. The DASH Player-specific Events are dispatched to DASH Player’s Control, Selection & Heuristic Logic, while the Application-related Events and timed metadata track samples are dispatched to the application as the following. If an Application is subscribed to a specific AES, dispatch the corresponding event instances or timed metadata samples, according to the dispatch mode:

1. For on-receive dispatch mode, dispatch the Event information or timed metadata samples as soon as they are received (or no later than AT).

1. For on-receive dispatch mode, dispatch the entire event information as soon as they are appended to the Event and Timed Metadata Buffer.

2. For on-start dispatch mode, dispatch the Event information or timed metadata samples at their associated presentation time, using the synchronization signal from the media decoder.

2. For on-start dispatch mode, dispatch the message data of the event information at their associated presentation time or latest before the event duration has ceased, using the synchronization signal from the media decoder.

[haudiobe]

Change 1: Ok

Change 2: Generally ok, but should go into context with more details and then referenced from here. Also define term for the definition.

Change 3: OK

Change 4: probably ok, please check. Internal object, data structure.

Change 5: Define MPD time as the presentation time documented in the MPD.

Change 6: Generally ok, needs some structure updates

Change 7: Clarify what it means "file format parser"

Change 8: FIFO for immediate dispatch, ordering for synchronous. Expand clarify

Change 9,10,11: brings this in context to above.

Define a data object that is used as internal exchange but also as being passed in the on-receive mode to the application

[irajs]

Implemented.