- This is for consistency with PlayerControlView.
- Also update PlayerNotificationManager notification if shuffle
mode changes. This is for consistency with what happens when
the repeat mode changes. By default the notification will be
unchanged, but custom implementations can extend and then
override createNotification, and given these modes change
infrequently it feels like we can just do this. The alternative
for achieving consistency would be to remove handling of repeat
mode changes.
Issue: #6582
PiperOrigin-RevId: 277925094
The leanback library doesn't know about non-square pixels. So if
we're playing content that uses non-square pixels, we need to adjust
the video dimensions that we provide to leanback such that it
renders the video with the correct aspect ratio.
PiperOrigin-RevId: 277042560
It's confusing that seekTo(player, windowIndex, positionMs) does
clamping, because it only makes sense if windowIndex is the current
window.
Note: This doesn't actually fix anything (other than code clarity).
In cases where we were passing other windowIndices, we always
passed 0 as the position and so the clamping logic wouldn't have
had any effect.
PiperOrigin-RevId: 272857104
Keeping the ones inside loops, because theoretically they
can be useful there (in practice, for this use case, it's
highly unlikely to make any difference).
PiperOrigin-RevId: 272834073
The playback speed set in MediaSession's PlaybackStateCompat needs to be the
actual speed at which the playback position progresses and not the user-defined
target speed.
This fixed a bug where the position advances although the player lost audio
focus.
Issue:#6203
PiperOrigin-RevId: 269295249
The player may suppress playback when waiting for audio focus even if the
state==Player.READY. There is currently no getter or callback to obtain this
piece of information for UI updates or analytics.
Also, it's a important derived state to know whether the playback position is
advancing. Add isPlaying and the corresponding callback to allow retrieving
this information more easily.
Issue:#6203
PiperOrigin-RevId: 268921721
If the app seeks after we get an ads manager but before the player exposes the
timeline with ads, we would end up expecting to play a preroll even after the
seek request arrived. This caused the player to get stuck.
Wait until a non-empty timeline has been exposed via onTimelineChanged before
initializing IMA (at which point it can start polling the player position). Seek
requests are not handled while an ad is playing.
PiperOrigin-RevId: 265058325
Any seek before the first timeline becomes available will result in a NPE.
Change it to handle that case gracefully.
Issue:#5831
PiperOrigin-RevId: 264603061
AdsMediaSource posts AdsLoader.start to the main thread during preparation, but
the app may call AdsLoader.setPlayer(null) before it actually runs (e.g., if
initializing then quickly backgrounding the player).
This is valid usage of the API so handle this case instead of asserting. Because
not calling setPlayer at all is a pitfall of the API, track whether setPlayer
has been called and still assert that in AdsLoader.start.
PiperOrigin-RevId: 264329632
I think we need to start clearing the holder as part of the
DRM rework. When we do this, it'll only be valid to read
from the holder immediately after it's been populated.
PiperOrigin-RevId: 262362725
Android considers ALAC initialization data to consider of the magic
cookie only, where-as FFmpeg requires a full atom. Standardize around
the Android definition, since it makes more sense (the magic cookie
being contained within an atom is container specific, where-as the
decoder shouldn't care what container the media stream is carried in)
Issue: #5938
PiperOrigin-RevId: 261124155
This gives a caller greater confidence that the methods have no
side effects, and remove any nullness issues with these methods
accessing @Nullable member variables.
PiperOrigin-RevId: 256525739
- Inline some unnecessarily split out helper methods
- Clear ExtractorInput from FlacDecoderJni data after usage
- Clean up exception handling for StreamInfo decode failures
PiperOrigin-RevId: 256524955
In surface YUV output mode the width/height fields of the VpxOutputBuffer were
never populated. Fix this by adding a new method to set the width/height and
calling it from JNI like we do for GL YUV mode.
PiperOrigin-RevId: 250449734
Update configuration script to use an external build, so we can remove use of
isysroot which is broken in the latest NDK r19c. Also switch from gnustl_static
to c++_static so that ndk-build with NDK r19c succeeds.
Issue: #5922
PiperOrigin-RevId: 250287551
