The output of CompositionPlayer should be considered as a single clip
(not a playlist) so we should only propagate the first stream change
event in that case.
PiperOrigin-RevId: 752661523
Previously when there were negative timestamps, the tkhd duration was incorrectly equal to the full track duration rather than the presentation duration of the edit list. From the [docs](https://developer.apple.com/documentation/quicktime-file-format/track_header_atom/duration) - "The value of this field is equal to the sum of the durations of all of the track’s edits".
PiperOrigin-RevId: 752655137
Previously a stream error from one playlist item was incorrectly
preserved when switching to the next one, resulting in playback hanging.
Issue: androidx/media#2328
PiperOrigin-RevId: 752624979
Before this CL, the buffer adjustment (which allows to convert from
ExoPlayer time to VideoGraph time) was added to the frame timestamps
before feeding them to the VideoGraph, and then subtracted at the
VideoGraph output. The playback position and stream start position used
for rendering were in ExoPlayer time.
This doesn't work for multi-sequence though because the adjustment might
be different depending on the player (after a seek for example).
To solve this problem, this CL handles rendering in VideoGraph time
instead of ExoPlayer time. More concretely, the VideoGraph output
timestamps are unchanged, and the playback position and stream start
position are converted to VideoGraph time.
PiperOrigin-RevId: 752260744
The code for setting the video output is almost the same across both places,
with one callsite supporting less types of video output. I think it's still
better to share the code, to minimize the margin for mistake later.
PiperOrigin-RevId: 751423005
Scrubbing mode doesn't really work for assets loaded over the network.
This also assumes `asset://`, `data://` and `android.resource://` URIs
are 'local' but not `content://` - because these can be loaded by any
arbitrary `ContentResolver` which may do higher latency/lower bandwidth
remote loading.
PiperOrigin-RevId: 751389438
This also tweaks the logic in `Util.shouldShowPlayButton` to
special-case the 'scrubbing' suppression reason. In most cases of
playback suppression (e.g. transient loss of audio focus due to a phone
call), the recommended UX is to show a 'play' button (i.e. the UI looks
like the player is paused). This doesn't look right when scrubbing
since although 'ongoing' playback is suppressed, the image on screen
is constantly changing, so a 'pause' button is kept (i.e. the UI looks
like the player is playing).
PiperOrigin-RevId: 751385521
The "exotest" prefix was associated with decoders configured for ExoPlayer tests.
However, after adding encoder support to ShadowMediaCodecConfig and migrating transcoding tests to use it, changing the prefix to "media3" makes it more expressive.
Sump files were updated accordingly.
This is a non-functional change.
PiperOrigin-RevId: 751357719
Despite the size being specified as 80 dp, it's important that all the buttons are exactly 1/3 of the Row, even if it means ignoring the size.
PiperOrigin-RevId: 751343084
If set on the requested VideoEncoderSettings, then
these parameters are passed into the MediaFormat
used by the DefaultEncoderFactory to configure the
underlying codec.
PiperOrigin-RevId: 751059914
Flushing a c2.mtk decoder that outputs to a SurfaceTexture often
fails and leaves the SurfaceTexture's BufferQueue in an unrecoverable
state. Release the codec instead.
PiperOrigin-RevId: 751006875
Applications providing custom AudioSink implementations should have the dynamic scheduling for audio playback fallback to the static interval if they are not supporting AudioSink#getAudioTrackBufferSizeUs().
This CL specifically removes the bypass for the static default for if rendering to end of stream. For scenarios with an intermediary layer between MediaCodecAudioRenderer and DefaultAudioSink, there can be potential underruns even though at the MediaCodecAudioRenderer it has nothing else to write.
PiperOrigin-RevId: 750986145
This helps integration with `PlayerControlView` in a follow-up change,
where we need to reliably know if scrubbing mode is still enabled (in
case someone else disables it after we enable it).
PiperOrigin-RevId: 750913644
MergingMediaSource started keeping references to all MediaPeriods
it ever created since 191bc094a5 as the cleanup step attempted
to remove the outer merged period from the list instead of the
inner period of child source.
Issue: androidx/media#2338
PiperOrigin-RevId: 750566825
We suppressed the direct error throwing ability in <unknown commit>
to avoid throwing errors later in the playlist too early. This
logic got moved to MaskingMediaSource in <unknown commit>, but its
original purpose was no longer needed when the player stopped
calling this method directly in <unknown commit>.
This left a pending bug that any other usage of MaskingMediaSource
(e.g. within AdsMediaSource) no longer forwards source prepare
errors.
Issue: androidx/media#2337
PiperOrigin-RevId: 750537823
DefaultVideoSink.join() was called when join() was called on the
InputVideoSink. This makes sense in playlist mode but we shouldn't
join if the VideoGraph output is considered as a single clip.
This change is no-op. Indeed, for CompositionPlayer, the
allowedJoiningTimeMs is set to 0, so that join doesn't have any effect.
PiperOrigin-RevId: 750238085
Before, we were starting and stopping video rendering when the
renderers were started/stopped. This doesn't work for multi-video
sequences though because we shouldn't stop and start rendering at every
MediaItem transition in any of the input sequences.
PiperOrigin-RevId: 750206410
A bug was introduced because it was unclear that button state creation and listener registration were not an atomic operation. This happens because the `LaunchedEffect` which starts the listen-to-Player-Events coroutine can be pre-empted with other side effects, including the ones that change something in the Player.
`remember*State` functions create some button state object and initialise it with the correct fresh values pulled out of the Player. The subscription to Player events with a registration of a Listener(via `*ButtonState.observe()`) is not immediate. It *returns* immediately, but is instead scheduled to happen *later*, although within the same Handler message. Other LaunchedEffects could have been scheduled earlier and could take place between the button state creation and listener subscription.
This is not a problem if no changes to the player happen, but if we miss the *relevant* player events, we might end up with a UI that is out of sync with reality (e.g. button enabled/disabled when it should be flipped, icons toggled the wrong way). The way to fix this is to pull the latest values out of the Player on demand upon starting to listen to Player events.
PiperOrigin-RevId: 750183793
This CL fixes the parser for the RTSP SessionDescription such that it will not choke if there is trailing whitespace in the lines.
PiperOrigin-RevId: 750158624
Add dolby vision with hevc and avc codec in Mp4Muxer according to Dolby
ISO media format standard. As initialization data is required for creation of dovi box, CSD is populated in BoxParser.
PiperOrigin-RevId: 749765993
This allows the app to store the ad playback state and then
when starting again, allow them to resume with the same
ad playback state. This way, users don't have to watch the same
ads twice if/when playback was interrupted. For instance, when the
app was put into background and then is foregrounded again.
PiperOrigin-RevId: 748737832
`Util.SDK_INT` was introduced to be able to simulate any SDK version during tests.
This is possible by using Robolectric's `@Config(sdk)` annotation.
All usages of `Util.SDK_INT` have been replaced by `Build.VERSION.SDK_INT`.
This is a similar change to what was done in #2107.
