Handle laggy manifest servers. Don't reprocess discarded manifests twice.

This commit is contained in:
Oliver Woodman 2015-11-17 15:42:40 +00:00
parent b27dc9b7dc
commit 5de7638f74

View file

@ -121,6 +121,7 @@ public class DashChunkSource implements ChunkSource, Output {
private final boolean live;
private MediaPresentationDescription currentManifest;
private MediaPresentationDescription processedManifest;
private ExposedTrack enabledTrack;
private int nextPeriodHolderIndex;
private TimeRange availableRange;
@ -322,8 +323,11 @@ public class DashChunkSource implements ChunkSource, Output {
}
MediaPresentationDescription newManifest = manifestFetcher.getManifest();
if (currentManifest != newManifest && newManifest != null) {
if (newManifest != null && newManifest != processedManifest) {
processManifest(newManifest);
// Manifests may be rejected, so the new manifest may not become the next currentManifest.
// Track a manifest has been processed to avoid processing twice when it was discarded.
processedManifest = newManifest;
}
// TODO: This is a temporary hack to avoid constantly refreshing the MPD in cases where
@ -727,6 +731,14 @@ public class DashChunkSource implements ChunkSource, Output {
periodHolders.remove(periodHolder.localIndex);
}
// After discarding old periods, we should never have more periods than listed in the new
// manifest. That would mean that a previously announced period is no longer advertised. If
// this condition occurs, assume that we are hitting a manifest server that is out of sync and
// behind, discard this manifest, and try again later.
if (periodHolders.size() > manifest.getPeriodCount()) {
return;
}
// Update existing periods. Only the first and last periods can change.
try {
int periodHolderCount = periodHolders.size();