Guard against out-of-range timestamp

We've found that in our production environment, the AAC stream's timestamp exceeds the 33bit limit from time to time, when it happens, `peekId3PrivTimestamp` returns a value that is greater than `TimestampAdjuster.MAX_PTS_PLUS_ONE`, which causes a overflow in `TimestampAdjuster.adjustTsTimestamp` (overflow inside `ptsToUs`) after playing for a while . When the overflow happens, the start time of the stream becomes negative and the playback simply stucks at buffering forever.

I fully understand that the 33bit is a spec requirement, thus I asked our stream provider to correct this mistake. But in the mean time, I'd also like ExoPlayer to handle this situation more error tolerance, as in other platforms (iOS, browsers) we see more tolerance behavior.
This commit is contained in:
simophin 2017-11-24 17:27:35 +13:00 committed by Oliver Woodman
parent d5b79f3a43
commit cf3ab9051d

View file

@ -306,7 +306,7 @@ import java.util.concurrent.atomic.AtomicInteger;
if (PRIV_TIMESTAMP_FRAME_OWNER.equals(privFrame.owner)) {
System.arraycopy(privFrame.privateData, 0, id3Data.data, 0, 8 /* timestamp size */);
id3Data.reset(8);
return id3Data.readLong();
return id3Data.readLong() & ((1L << 33) - 1L);
}
}
}