sjs/media
1
0
Fork 0
mirror of https://github.com/samsonjs/media.git synced 2026-04-27 15:07:40 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Update stale comment in TrimmingAudioProcessor

Browse source 
The part about leaving the pending trim start byte count unmodified
if the processor was just configured is not correct.

PiperOrigin-RevId: 295745371
This commit is contained in:
andrewlewis 2020-02-18 17:00:38 +00:00 committed by Oliver Woodman
parent 23e4236227
commit ed1eade980
1 changed files with 6 additions and 5 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

11
library/core/src/main/java/com/google/android/exoplayer2/audio/TrimmingAudioProcessor.java
View file

@ -155,15 +155,16 @@ import java.nio.ByteBuffer;
@Override @Override
protected void onFlush() { protected void onFlush() {
if (reconfigurationPending) { if (reconfigurationPending) {
// This is the initial flush after reconfiguration. Prepare to trim bytes from the start/end.
reconfigurationPending = false; reconfigurationPending = false;
endBuffer = new byte[trimEndFrames * inputAudioFormat.bytesPerFrame]; endBuffer = new byte[trimEndFrames * inputAudioFormat.bytesPerFrame];
pendingTrimStartBytes = trimStartFrames * inputAudioFormat.bytesPerFrame; pendingTrimStartBytes = trimStartFrames * inputAudioFormat.bytesPerFrame;
} else { } else {
// Audio processors are flushed after initial configuration, so we leave the pending trim // This is a flush during playback (after the initial flush). We assume this was caused by a
// start byte count unmodified if the processor was just configured. Otherwise we (possibly // seek to a non-zero position and clear pending start bytes. This assumption may be wrong (we
// incorrectly) assume that this is a seek to a non-zero position. We should instead check the // may be seeking to zero), but playing data that should have been trimmed shouldn't be
// timestamp of the first input buffer queued after flushing to decide whether to trim (see // noticeable after a seek. Ideally we would check the timestamp of the first input buffer
// also [Internal: b/77292509]). // queued after flushing to decide whether to trim (see also [Internal: b/77292509]).
pendingTrimStartBytes = 0; pendingTrimStartBytes = 0;
} }
endBufferSize = 0; endBufferSize = 0;