Calculate HLS live playlist refresh interval accurately
Previously, we calculated the next playlist reload time by adding the target duration (or half of it, depending on whether there is a real update in the new playlist snapshot) from the last load completion time, which makes the reload interval as long as `targetDuration(or half of it) + lastLoadDuration`. While still complying to the standard that "the client MUST wait for at least the target duration before attempting to reload the Playlist file again", this could cause buffering when the playback position is close to the end of live window. This change is to calculate the reload interval accurately by not adding the term `lastLoadDuration`. Issue: androidx/media#663 #minor-release PiperOrigin-RevId: 573300009
This commit is contained in:
parent
8b7ebc7032
commit
58a63c82aa
@ -30,6 +30,9 @@
|
||||
* Cronet Extension:
|
||||
* RTMP Extension:
|
||||
* HLS Extension:
|
||||
* Refresh the HLS live playlist with an interval calculated from the last
|
||||
load start time rather than the last load completed time
|
||||
([#663](https://github.com/androidx/media/issues/663)).
|
||||
* DASH Extension:
|
||||
* Smooth Streaming Extension:
|
||||
* RTSP Extension:
|
||||
|
@ -761,7 +761,8 @@ public final class DefaultHlsPlaylistTracker
|
||||
? playlistSnapshot.targetDurationUs
|
||||
: (playlistSnapshot.targetDurationUs / 2);
|
||||
}
|
||||
earliestNextLoadTimeMs = currentTimeMs + Util.usToMs(durationUntilNextLoadUs);
|
||||
earliestNextLoadTimeMs =
|
||||
currentTimeMs + Util.usToMs(durationUntilNextLoadUs) - loadEventInfo.loadDurationMs;
|
||||
// Schedule a load if this is the primary playlist or a playlist of a low-latency stream and
|
||||
// it doesn't have an end tag. Else the next load will be scheduled when refreshPlaylist is
|
||||
// called, or when this playlist becomes the primary.
|
||||
|
Loading…
x
Reference in New Issue
Block a user