The matroska file works without further changes. The FLAC container
file works with `lib-flac-decoder` depending on a bundled `libflac`
implementation, but not when using
`androidx.media3.extractor.flac.FlacExtractor` with a `MediaCodec` FLAC
decoder because the media3 extractor doesn't support 32-bit FLAC yet.
The fix for that is in a follow-up change.
`bear_32bit.flac` was generated from `bear.flac` with `ffmpeg`:
```shell
$ ffmpeg \
-i bear.flac \
-c:a flac \
-sample_fmt s32 \
-strict experimental \
bear_32bit.flac
```
`bear-flac-32bit.mka` was generated by re-muxing `bear_32bit.flac`,
also with `ffmpeg` (trying to convert `bear-flac-24bit.mka` to 32-bit
didn't work, the resulting file was still 24-bit):
```shell
$ ffmpeg \
-i ../flac/bear_32bit.flac \
-c:a copy \
bear-flac-32bit.mka
```
Issue: androidx/media#2197
PiperOrigin-RevId: 736552251
We want to skip the buffers in sync with playback, which
only makes progress once started. This means we can simplify
the logic to only apply the 30ms threashold when started
(which was indirectly the threashold used already because the
frame release would return TRY_AGAIN_LATER).
This means we can remove the
shouldSkipLateBuffersWhileUsingPlaceholderSurface as it was
only used in tests to prevent skipping while we were not
started.
PiperOrigin-RevId: 736533043
This listener is used by apps to associate render timestamp and presentation
timestamp when using a SurfaceTexture, so this timestamp must match up with
what's set in `eglPresentationTimeANDROID`.
PiperOrigin-RevId: 736494784
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 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 part of an effort to remove VideoSink.onRendererEnabled,
which is a step towards making the VideoSink interface renderer
agnostic. The plan is to merge onRendererEnabled, setStreamTimestampInfo
and onInputStreamChanged into a single method in VideoSink.
This change is a no-op refactoring
PiperOrigin-RevId: 735293983
Removed test that attempted to verify behavior when the lib-effect dependency is missing. This is because it fails when adding lib-transformer to test-util dependency. The introduction of lib-transformer brought in lib-effect as a transitive dependency, which conflicted with the test's expectation of the class not being present.
PiperOrigin-RevId: 734547629
If feature is enabled, MediaCodecVideoRenderer will include the `MediaCodec.BUFFER_FLAG_DECODE_ONLY` flag when queuing decode-only input buffers. This flag will signal the decoder to skip the decode-only buffers thereby resulting in faster seeking.
PiperOrigin-RevId: 734152464
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
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
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
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
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
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
Based on the idea for the ExoPlayer stress tests, we can set up more
stress tests for other components that verify
the components do not use system binder calls on the main thread.
PiperOrigin-RevId: 730964902
The test compares creating and interacting with the player
with and without additional binder stress on the system process.
If the ExoPlayer interactions do not use binder calls, the overall
runtime should be within the same range (allowing for some additional
leeway due to the generally increased CPU usage).
Verified the test passes 20/20 without flakes and fails 19/20 even
with a single binder call.
PiperOrigin-RevId: 730963633
This ensures all AudioManager calls are moved off the main
thread.
Having the audio focus management on the playback thread
also allows future improvements like requesting audio focus
only just before the player becomes ready (which is recommended
but not currently done by ExoPlayer).
PiperOrigin-RevId: 730962299
Before this change constructors of `TimelineWindowDefinition` used
`windowOffsetInFirstPeriodUs` for both, `positionInFirstPeriodUs`
and `startTimeUs` of the exposed `Timeline.Window`.
Adding `windowStartTimeUs` differentiates these two properties which
allows using `FakeTimeline` for unit tests that emulate live streams
with a forward moving live window in the period like `HlsMediaSource`
constructs a `SinglePeriodTimeline` for live.
A `TimelineWindowDefinition.Builder` is added for API usability and
sanitation.
PiperOrigin-RevId: 730892809
Before API 27, the platform DRM components incorrectly expected
`C.COMMON_PSSH_UUID` instead of `C.CLEARKEY_UUID` in order to perform
ClearKey decryption. `FrameworkMediaDrm` is responsible for doing this
adjustment on these API levels, but this call was missed when
refactoring some DRM code in
c872af4bc0.
This led to `MediaCodec$CryptoException: Operation not supported in this
configuration` errors when doing ClearKey playback on devices with
API < 27. This was because the earlier, clearer error from the
`MediaCrypto` constructor was being swallowed and transformed to
`requiresSecureDecoder = true` by the `catch` logic in
`FrameworkMediaDrm.requiresSecureDecoder`.
This change also makes the error handling in
`FrameworkMediaDrm.requiresSecureDecoder` more robust by assuming
`requiresSecure = false` for ClearKey (and true for all other DRM
schemes), since we know that ClearKey never supports secure decoding.
This will help avoid more ClearKey playback failures if we see other,
unrelated, errors at this point.
Issue: androidx/media#1732
#cherrypick
PiperOrigin-RevId: 730882278
Add a debugLoggingEnabled parameter in DownloadHelper constructor and forMediaItem overloads. For backward compatibility, this is disabled by default. Currently the debug logging is for track selection results only.
PiperOrigin-RevId: 730881600
If the deprecated path without a context is used, the capabilities
are set externally and can't recover automatically back to the real
capabilities.
Issue: androidx/media#2168
PiperOrigin-RevId: 730427339
