You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In CR-Low-Latency-Live r8 , section 9.X.6.3.7, there is a table which I quote part of it as below:
Parameters
Proposed default value
DASH Mapping of Parameters
Target Latency
3.5
Maximum Latency
10
Change Lead Time (CLT)
5 seconds
MPD@minimumUpdatePeriod (MUP)
Reference Buffer Duration (RBD)
2.0 seconds
MPD@minBufferTime (MBT)
Adaptation Set Type
LL-Chunk
Nominal CMAF Fragment/Segment Duration
8 seconds
Nominal MP4/CMAF chunk duration
0.5 seconds
Since the MUP is 5 seconds, the client refreshes the MPD every 5 seconds. To ensure enough data to play before the new MPD is downloaded, at the beginning of the playback (after receiving the initial MPD), the client may start from a position at least 5-sec older than the live edge.
Assuming that the live edge is near the end of the latest available segment (and also the last segment in the current MPD). The client plays from the start of the latest available segment after buffering 2-sec (MBT) data. It does not wait for the next segment because the new MPD is to be downloaded after 5 sec. So when playing the segment, the latency is ~10 sec (8 + 2), almost the maximum latency. According to the sec 9.X.4.2, the content should not be presented if the latency exceeds the maximum latency.
My question is, in the low-latency stream playback, could the client subtract the MUP when calculating the latency? Or should the service provider be responsible to consider the MUP when defining the Target Latency so that the client does not have to worry about the conflicting attributes in some cases?
The text was updated successfully, but these errors were encountered:
The MUP is independent of the segment duration and the latency. MUP is needed if you change delivery, for example adding a new period. In this case you want clients to come back quickly.
The client is aware of the timing and timelines of segment availabilities and when a new segment is expected to be offered. We have added some joining recommendations for the client implementation in clause 9.X.4. and 9.X.7. The client may wait for next new segment, join the latest segment and accelerate playback or may download a portion of the segment and start in the middle. Please check the guidelines more detailed.
We will discuss this also in the live TF for additional input,
haudiobe
transferred this issue from Dash-Industry-Forum/DASH-IF-IOP
Feb 18, 2022
In CR-Low-Latency-Live r8 , section 9.X.6.3.7, there is a table which I quote part of it as below:
Since the MUP is 5 seconds, the client refreshes the MPD every 5 seconds. To ensure enough data to play before the new MPD is downloaded, at the beginning of the playback (after receiving the initial MPD), the client may start from a position at least 5-sec older than the live edge.
Assuming that the live edge is near the end of the latest available segment (and also the last segment in the current MPD). The client plays from the start of the latest available segment after buffering 2-sec (MBT) data. It does not wait for the next segment because the new MPD is to be downloaded after 5 sec. So when playing the segment, the latency is ~10 sec (8 + 2), almost the maximum latency. According to the sec 9.X.4.2, the content should not be presented if the latency exceeds the maximum latency.
My question is, in the low-latency stream playback, could the client subtract the MUP when calculating the latency? Or should the service provider be responsible to consider the MUP when defining the Target Latency so that the client does not have to worry about the conflicting attributes in some cases?
The text was updated successfully, but these errors were encountered: