Commit 2564a121 by tonihei Committed by Ian Baker

Remove pointless use of playbackInfo.startPositionUs

We have a flag that gets turned on if the current playback position has been
reset, so that messages from this reset position can be triggered. This
mechanism isn't actually depending on the startPositionUs field because it
should always be triggered in the first iteration with the new position.

PiperOrigin-RevId: 290749201
parent 5f9a5850
...@@ -1318,13 +1318,12 @@ import java.util.concurrent.atomic.AtomicBoolean; ...@@ -1318,13 +1318,12 @@ import java.util.concurrent.atomic.AtomicBoolean;
if (pendingMessages.isEmpty() || playbackInfo.periodId.isAd()) { if (pendingMessages.isEmpty() || playbackInfo.periodId.isAd()) {
return; return;
} }
// If this is the first call from the start position, include oldPeriodPositionUs in potential // If this is the first call after resetting the renderer position, include oldPeriodPositionUs
// trigger positions, but make sure we deliver it only once. // in potential trigger positions, but make sure we deliver it only once.
if (playbackInfo.startPositionUs == oldPeriodPositionUs if (deliverPendingMessageAtStartPositionRequired) {
&& deliverPendingMessageAtStartPositionRequired) {
oldPeriodPositionUs--; oldPeriodPositionUs--;
deliverPendingMessageAtStartPositionRequired = false;
} }
deliverPendingMessageAtStartPositionRequired = false;
// Correct next index if necessary (e.g. after seeking, timeline changes, or new messages) // Correct next index if necessary (e.g. after seeking, timeline changes, or new messages)
int currentPeriodIndex = int currentPeriodIndex =
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or sign in to comment