The start position and buffer adjustement are only allowed to change
when the stream changes so it makes more sense to call
setStreamTimestampInfo when the stream changes.
This is part of an effort to simplify stream change notification to the
video sink, to ease implementation of multi sequences preview.
PiperOrigin-RevId: 734062686
This is a step towards removing the assumption that there is only one
sequence and therefore one renderer feeding data to DefaultVideoSink and
VideoFrameReleaseControl.
PiperOrigin-RevId: 734062629
This is a step towards removing the assumption that there is only one
sequence and therefore one renderer feeding data to DefaultVideoSink and
VideoFrameReleaseControl.
This is a no-op refactoring.
PiperOrigin-RevId: 734044100
This was requested in Issue: androidx/media#2191 for playback of Opus and Vorbis
files with more than two channels with a float PCM pipeline.
Also, add ChannelMappingAudioProcessorTest.
PiperOrigin-RevId: 733766680
This is analagous to `String.codePointAt` and similar methods. By
dealing only in unicode code points, and returning an `int`, we can
avoid having to reason about how to handle UTF-8 code units that
require two UTF-16 code units (each one a Java `char`) to represent
them.
The zero-arg `peekChar` method remains undeprecated, because it behaves
as "you'd expect" when compared to `peekUnsignedByte` (always reads two
big-endian bytes).
PiperOrigin-RevId: 733752645
With using the `MediaPeriodId` from the `ExoPlaybackException`, ExoPlayerImplInternal can set the same id to the renderer group(primary and secondary).
Tested with `ExoPlayerWithPrewarmingRenderersTest` error-based unit tests like `play_errorByPrewarmingSecondaryRendererAfterAdvancingReadingPeriod_doesNotResetPrimaryRenderer`. If the media period was not set in BaseRenderer then the exception would have the incorrect mediaperiod, attribute the error to the non-prewarming renderer, and the test would fail.
PiperOrigin-RevId: 733744777
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
With multi video sequences previewing in CompositionPlayer,
VideoFrameReleaseHelper won't be connected to a single renderer.
Multiple renderers will feed the VideoGraph at the same time, and the
VideoGraph output will be connected to the VideoFrameReleaseHelper.
PiperOrigin-RevId: 733250499
The original behaviour of the `handleSetCookieRequests` is preserved.
A bug is addressed, where it woulld set `Set-Cookie` header in the client request (as opposed to the expected `Cookies`).
PiperOrigin-RevId: 732945338
This makes charset-heavy tests easier to read (and I'm going to add some
more in a follow-up change).
Also switch to Truth's `isEmpty()` assertion as prompted by a lint
check.
PiperOrigin-RevId: 732925878
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
AudioManager internally assumes the thread is was created on can be
used as a callback thread. Since the AudioManager is only created
once in the lifetime of an app, we need to make sure its obtained
on a thread that stays alive.
#cherrypick
PiperOrigin-RevId: 732072255
On API < 26, the callback thread couldn't be set and the current compat
code assumes it's always the main thread. This isn't true, however,
because AudioManager uses the thread on which it was first instantiated
anywhere in the app.
#cherrypick
PiperOrigin-RevId: 731696188
A state holder that handles interaction with a UI component that toggles through a range of playback speeds.
[demo-compose] Use PlaybackSpeedState to create PlaybackSpeedTextButton
Add the button to the bottom extra controls.
PiperOrigin-RevId: 731449526
Also only fully-qualify the media3 types, since these are the ones that
are at risk of moving - I don't think `android.os.Handler` is going
anywhere, and doesn't need to be proguard-kept anyway.
PiperOrigin-RevId: 731315177
Without this change, content that contains a PSSH box with only
the ClearKey UUID is not playable on devices with API < 27.
This includes our `sample_fragmented_clearkey.mp4` test content.
PiperOrigin-RevId: 731308444
This resolves the jacoco log spam when running Robolectric tests on
JDK 21, and therefore unblocks bumping our Java language level to 21.
PiperOrigin-RevId: 731297393
When there is both audio and video track, then fragment
creation is driven by video track (a combination of duration
so far + next key frame). But if there is no video track, then
the duration so far drives the fragment creation.
Due to bug, when there is only audio track, only first
fragment was created as expected and then a new fragment is
created for every audio sample.
#cherrypick
PiperOrigin-RevId: 731257696
