Live edge logic: startup vs. seeking

[Feenposhleen]

Howdy

We are trying out some live streams that includes a suggestedPresentationDelay (SPD). One thing we noticed is how the calculation of the live edge differs between seeking and startup. When seeking, the edge is at now - SPD, which is expected. When starting a stream, however, the edge is further back, since the rebuffering goal is subtracted as well (now - SPD - rebuffering goal).

When not providing an explicit SPD, it makes sense to add the extra padding (since it's guesswork, and you want to avoid a buffering startup). If provided, however, I think the player should always assume that now - SPD is the live edge. This is according to spec, since a SPD should take into account the typical required buffering in the client, for example based on the network condition (DASH-IF IOP 3.2, 4.3.3.2.2).

One solution could be to simply increase the default SPD, and to no longer append the rebuffering goal on startup. That way you'd get consistent logic.

[joeyparrish]

That makes sense. I agree with your interpretation of the spec. I found a live stream that behaves as you described, and your suggested solution seems to work well, too.