haudiobe
commented
5 years ago (Live TF 19/05/31) Agree on:
- Requirement is on Max Latency instead of Target Latency
- Single Bitrate streaming may be different
- We can add a few more information on Service Description
- dash.js (has a low-latency mode, and a target latency)
- do some updates based on the discussion
The requirement for the target latency to be larger than the maximum segment duration is overly restrictive and over simplistic. I have two particular comments to make on this point:
a) If there are clients that are unable to deal with a shorter latency, let them just increase the latency! Since there are separate min, target and max latency values signalled, I don't see why the content can't express a preferred latency that is something that only some clients can achieve (and perhaps then only in some circumstances). Surely it's straightforward for players which know that they're not designed to cope with this to adjust the latency that they actually try to achieve based on knowledge of their own capabilities? There's perhaps an argument that right now, the max latency shouldn't be set lower than the segment duration, but where there can exist players that perform well and players that support less well, I strongly believe it is for the player to adjust the target to what it believes can be achieved, not the content provider to lie about what is most appropriate for the content. Content providers shouldn't have to create different MPDs for different clients.
Any constraint defined here should be on the max latency not the target latency and the client guidelines should contain words to the effect of "don't blindly follow a target latency you know you can't achieve".
b) What can be played reliably is a function of many things. It is not just the segment size that affects how resilient playback will be. For example, the lowest bitrate representation that is provided places a limit on the minimum bandwidth with which the stream will play without interruption. Making the latency less than the segment duration has a few consequences, but one effect is that it leads to a different minimum bandwidth limit required for reliable operation. Where the bitrate range within an AdaptationSet is not too great, the limiting bandwidth could be unchanged, even with a lower latency than the segment duration. Also, reliability against some kinds of network issue are simply a function of the client buffer duration, and are unrelated to the segment duration. It's over simplistic to suggest that all is well if the segments are shorter than the latency and should be fine otherwise.
Again, the client should be responsible for looking at the target and increasing it to the minimum it believes can actually be achieved given the other MPD parameters, the design of its switching algorithm and possibly knowledge of past performance. It's really not appropraite to require the content provider to adapt the MPD to the capabilities of individual clients. It might work in the simplest case where the content provider only uses a single player, but that is not the reality for most content providers. Let the contnet provider signal the intent - it's a "service description" after all. Let the player then decide how to best present that content.