Earlier when gap is at the start of a sequence
it was automatically filled with silent audio.
Now setting forceAudioTrack flag is mandatory to
indicate that the gap at the start of a sequence
must be filled with silent audio.
PiperOrigin-RevId: 742625236
I could've add another test that seeks into the media before replying, but I
don't think fundamentally it's different from the one added.
I wish I could add one that replays while playing, but it'd be hard to match
the frames perfectly.
I'll add more timestamp based tests
PiperOrigin-RevId: 742229436
It's unclear why the listeners would need access to the
PlaybackVideoGraphWrapper as there should always be only one. Also,
it's not common practice to pass the parent object to the listener in
media3 (see Player.Listener for example).
PiperOrigin-RevId: 740686007
Previously, `exportSuccess_populatesEditingEndedEvent` and `exportError_populatesEditingEndedEvent` used an AtomicReference to capture the EditingEndedEvent. However, this led to a race condition where `EditingEndedEvent` was accessed before it was set in the `onMetricsReported` callback, resulting in a NullPointerException. This change replaces the AtomicReference with a SettableFuture to ensure the test waits for the event to be reported before asserting its value.
PiperOrigin-RevId: 739146511
CodecDbLite is a repository of chipset-specific codec recommendations.
Initially, these recommendations will focus on video encoders,
specifically choosing the right encoder to use on a given chipset
and the B-frame configuration to use with that encoder.
PiperOrigin-RevId: 738895394
The goal is to get rid of VideoSink.onRendererEnabled so that this
interface becomes renderer-agnostic. Indeed, for multi video sequences,
the DefaultVideoSink won't receive input from a single renderer anymore.
This is a no-op refactoring
PiperOrigin-RevId: 738296515
This test is failing in <unknown commit> when the following happens in
PlaybackVideoGraphWrapper:
- Both InputVideoSinks call onInputStreamChanged with startPosition
1000000000000
- Before the first VideoGraph output frame is available, both
InputVideoSinks call onInputStreamChanged with startPosition
1000000200000. This incorrectly erases startPosition
1000000000000 from TimedValueQueue streamStartPositionsUs. Indeed, when
1000000200000 is added for the second time, the whole queue is cleared
because this new value is not strictly greater than the previous one.
This start position logic should only be used for single-sequence
rendering. Disable the test until this is fixed.
PiperOrigin-RevId: 737982504
This brings the parts related to video frame release decision making
in a single place and simplifies the calling side in
MediaCodecVideoRenderer.
PiperOrigin-RevId: 737941729
This fixes the following issue: in CompositionPlayer, if the
Composition was containing a looping sequence with duration larger than
all the other sequences, the Composition duration was set to the
looping sequence duration. This is incorrect because looping sequences
should be clipped to match the other sequences.
PiperOrigin-RevId: 737927987
Before this change, exporting a Composition with all looping sequences
would result in a runtime exception due to a divide-by-zero exception
in TransformerInternal.
PiperOrigin-RevId: 737568877
A problem was discovered in Composition demo app where after playing a composition using CompositionPlayer, pressing the "play" button again would not restart the playback. This issue has been resolved, just adding a test to make sure we're not missing any regressions.
PiperOrigin-RevId: 735793488
In certain bluetooth playback scenarios, it was found that the delta of audio duration written by the AudioSink from the current playback position was greater than the size of the audio track buffer, causing underruns.
The solution is to utilize the audio track buffer size as an upper limit for an audio renderer's getDurationToProgress.
PiperOrigin-RevId: 735761604
Before this CL:
- MediaCodecVideoRenderer.onProcessedStreamChanged was called for the
first stream in CompositionPlayer.
- MediaCodecVideoRenderer.onProcessedStreamChanged was NOT called for
the first stream in ExoPlayer.setVideoEffects.
This discrepancy was adding some complexity to the code, making it less robust.
PiperOrigin-RevId: 735439320
This improves consistency by grouping it with other test builders and resolves a missing build rule, ensuring developers can properly use it for testing.
PiperOrigin-RevId: 735396181
This is a step towards merging setStreamStartPositionUs with
onInputStreamChanged, which makes sense as the start position can only
change on stream change.
PiperOrigin-RevId: 735309009
This is a step towards unifying ShadowMediaCodecConfig for ExoPlayer and Transcoding tests.
The buffer size for ExoPlayer's CodecConfig is set to 150_000. This is because some test media has samples larger than 100kB. We can increase the buffer size for Transcoding-related codec configurations.
PiperOrigin-RevId: 734297632
When `forceTransformerToFail` is set to true, the builder will use a `FailingMuxerFactory` which creates a `FailingMuxer` that throws a `MuxerException` when attempting to write sample data. This ensures Transformer will fail as muxers are used for all cases (transmuxing and transcoding).
PiperOrigin-RevId: 734281681
This is a step towards unifying ShadowMediaCodecConfig for ExoPlayer and Transcoding tests.
This change includes extracting encoder/decoder configurtion logic to a static method that can be called by `ShadowMediaCodecConfig.CodecImpl#configure()` and `TestUtil#addCodec()`.
This is a non-functional refactor.
PiperOrigin-RevId: 734137675
The gap item earlier meant audio gap.
Now the gap item will be filled with audio, video
or both based upon what all tracks are present in the
Sequence.
If the very first item is a gap then it is filled with
audio only. Support for video gap at start will be added in
a follow up CL.
If the first item is a gap then `forceAudioTrack`
is set to true.
PiperOrigin-RevId: 733422557
This change exposes a flag in `DefaultAudioMixer#Factory` to set whether
to upmix/downmix using constant power or constant gain mixing matrices.
This is a non-functional change.
PiperOrigin-RevId: 733339367
This change introduces `GainProcessor` to apply gain automation over an
audio stream. The gain automation is defined with a `GainProvider`.
`DefaultGainProvider` implements a basic `GainProvider` that allows
populating a gain automation line additively by adding fade shapes
(`FadeProvider`) at specific positions with specific durations.
`DefaultGainProvider` also implements basic equal gain and equal power
fades.
The current `DefaultGainProvider` implementation does not support adding
fades at relative offsets from the stream end. Users must know the
stream duration in advance and add fades at absolute positions.
PiperOrigin-RevId: 733311314
This method didn't have any effect because onEnabled, which also sets
the firstFrameState, should always be the next method being called.
PiperOrigin-RevId: 732846722
