haudiobe
commented
4 years ago Proposed updates:
This document presents a restricted subset of DASH presentation timing and segment addressing. This focus of this document is considerably narrower than afforded by [MPEGDASH], constraining services to a specific set of practically relevant behaviors that are highly interoperable with modern client platforms.
The main reason for the restrictions are:
- only ISO BMFF based segment formats are considered with focus on CMAF conformance.
- only non-multiplexed Representations are considered.
- only a subset of addressing modes are considered.
According to MPEG-DASH, clause 4.3., DASH defines different timelines. Please read clause 4.3 of MPEG-DASH for details.
The MPD defines the MPD timeline which serves as the baseline for all scheduling decisions made during DASH presentation playback.
A second timeline is used to signal to clients the availability time of Segments at the specified HTTP-URLs. These times are referred to as Segment availability times and are provided in wall-clock time. Clients typically compare their wall-clock time to Segment availability times before accessing the Segments at the specified HTTP-URLs in order to avoid erroneous HTTP request responses.
There exist two types of Media Presentations, indicated by the MPD attribute \@type.
The playback of a static Media Presentation, i.e. MPD@type set to "static", does not depend on the mapping of the MPD timeline to real-time. A DASH client can play any part of the presentation at any time. For static Media Presentations, the availability times of all Segments are identical.
The MPD timeline of a dynamic Media Presentation, , i.e. MPD@type set to "dynamic", documents a fixed mapping to wall-clock time, with each point on the timeline corresponding to a point in real time. For dynamic Media Presentations, the availability times of Segments depend on the position of the Segment in the Media Presentation timeline, i.e. the Segments get available over time. Clients typically introduce an additional offset with respect to Segment availability times to the extent allowed by the time shift signaling in the MPD in order to build a client buffer and enable smooth playback in varying network conditions.
Whereas static Media Presentations are suitable to offer On-Demand content, dynamic Media Presentations are mostly suitable to offer live services.
In addition to mapping the content to real time, an MPD with type dynamic can be updated during the presentation if the @minimumUpdatePeriod element is present. Updates may for example add new periods and remove or modify existing ones, though some restrictions apply. See § 5.2.7.5 MPD updates as well as MPEG-DASH, clause 5.4.
The MPD timeline of a dynamic Media Presentation is anchored against a point in real-time indicated by MPD@availabilityStartTime. Whereas the MPEG DASH specification in clause 5.4 only requires consistent updates, for MPDs following this specification, the MPD@availabilityStartTime SHALL not change over MPD updates.
The ultimate purpose of the MPD is to enable the client to obtain media samples for playback. The following data structures are most relevant to locating and scheduling the samples.
sandersaares
irajs
The playback of a static MPD SHALL NOT depend on the mapping of the MPD timeline to real time. A client MAY play any part of the presentation at any time.
static MPDs are not defined. It is also unclear what this requirements does
The MPD timeline of a dynamic MPD SHALL have a fixed mapping to real time, with each point on the timeline corresponding to a point in real time. Clients MAY introduce an additional offset with respect to real time to the extent allowed by the time shift signaling in the MPD.
dynamic MPD not defined. You mean dynamic Media Presentation? I am ok with the basic introduction, but no shall needed
The zero point in the MPD timeline of a dynamic MPD SHALL be mapped to the point in real time indicated by MPD@availabilityStartTime. This value SHALL NOT change between MPD updates.
unclear what the zero point is? MPD@availabilityStartTime is just an anchor, it has no specific meaning and only operates together with Period@start