haudiobe
commented
2 years ago Technical Q&A: First analysis
- Thank you for the question
- 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,
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?