mirror of
https://github.com/samsonjs/media.git
synced 2026-03-31 10:25:48 +00:00
Update stale comment in TrimmingAudioProcessor
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:
parent
23e4236227
commit
ed1eade980
1 changed files with 6 additions and 5 deletions
|
|
@ -155,15 +155,16 @@ import java.nio.ByteBuffer;
|
|||
@Override
|
||||
protected void onFlush() {
|
||||
if (reconfigurationPending) {
|
||||
// This is the initial flush after reconfiguration. Prepare to trim bytes from the start/end.
|
||||
reconfigurationPending = false;
|
||||
endBuffer = new byte[trimEndFrames * inputAudioFormat.bytesPerFrame];
|
||||
pendingTrimStartBytes = trimStartFrames * inputAudioFormat.bytesPerFrame;
|
||||
} else {
|
||||
// Audio processors are flushed after initial configuration, so we leave the pending trim
|
||||
// start byte count unmodified if the processor was just configured. Otherwise we (possibly
|
||||
// incorrectly) assume that this is a seek to a non-zero position. We should instead check the
|
||||
// timestamp of the first input buffer queued after flushing to decide whether to trim (see
|
||||
// also [Internal: b/77292509]).
|
||||
// This is a flush during playback (after the initial flush). We assume this was caused by a
|
||||
// seek to a non-zero position and clear pending start bytes. This assumption may be wrong (we
|
||||
// may be seeking to zero), but playing data that should have been trimmed shouldn't be
|
||||
// noticeable after a seek. Ideally we would check the timestamp of the first input buffer
|
||||
// queued after flushing to decide whether to trim (see also [Internal: b/77292509]).
|
||||
pendingTrimStartBytes = 0;
|
||||
}
|
||||
endBufferSize = 0;
|
||||
|
|
|
|||
Loading…
Reference in a new issue