- 06 Nov, 2019 1 commit
-
-
r2.10.7
Oliver Woodman committed
-
- 05 Nov, 2019 13 commits
-
-
PiperOrigin-RevId: 278658259
olly committed -
PiperOrigin-RevId: 278332587
kimvde committed -
PiperOrigin-RevId: 277963928
kimvde committed -
Which ensures both get updated when the MediaSessionConnector player changes. Issue:#6582 PiperOrigin-RevId: 277254889
aquilescanta committed -
- 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
olly committed -
PiperOrigin-RevId: 277910360
kimvde committed -
E-AC3 with JOC is signaled using the CHANNELS attribute for HLS: https://developer.apple.com/documentation/http_live_streaming/hls_authoring_specification_for_apple_devices/hls_authoring_specification_for_apple_devices_appendices PiperOrigin-RevId: 277680300
andrewlewis committed -
The framework opus decoder discards some samples after a call to flush(). Because we flush a decoder that is being retained across an input format change, this means that the start of audio gets truncated when transitioning to a new opus stream. See also https://android.googlesource.com/platform/frameworks/av/+/refs/heads/android10-release/media/libstagefright/codecs/opus/dec/SoftOpus.cpp. Avoid this by recreating opus decoders instead of flushing them. It seems fine to do this for all opus decoders as reinitialization should be cheap, OEM-provided implementations may also discard samples and playback shouldn't be interrupted on reinitialization due to the downstream AudioTrack buffer. PiperOrigin-RevId: 277458759
andrewlewis committed -
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
olly committed -
Float.MIN_VALUE is very close to zero: PiperOrigin-RevId: 276674142
ibaker committed -
PiperOrigin-RevId: 276660235
aquilescanta committed -
Without this, a subtitle track empty edit list used to offset the start of subtitles is ignored. Also the current code seems to depend on the order in which we parse the tracks (audio first means we have gapless info when we parse video track, while video first we wouldn't). It's not clear why we can't handle both edit lists & gapless info PiperOrigin-RevId: 276029744
ibaker committed -
The compositeSequenableLoader was causing NPEs in isLoading. Initializing it upfront prevents this problem and is in line with what we do in all real MediaPeriods. PiperOrigin-RevId: 275491511
tonihei committed
-
- 18 Oct, 2019 2 commits
-
-
r2.10.6
Oliver Woodman committed -
Issue:#6537 PiperOrigin-RevId: 275477266
samrobinson committed
-
- 17 Oct, 2019 1 commit
-
-
If an odd resolution is impossible in the specification itself, then we know that the caller is passing invalid data. Round up on the assumption it's a rounding error so that playback can proceed. Issue: #6551 PiperOrigin-RevId: 275226813
olly committed
-
- 15 Oct, 2019 1 commit
-
-
Same change as done in https://github.com/google/ExoPlayer/commit/c49388aca2047ed7680e7d8834def4f769060e2d. PiperOrigin-RevId: 274894288
tonihei committed
-
- 14 Oct, 2019 7 commits
-
-
Oliver Woodman committed
-
Oliver Woodman committed
-
PiperOrigin-RevId: 274568961
olly committed -
PiperOrigin-RevId: 274568660
aquilescanta committed -
PiperOrigin-RevId: 274564800
olly committed -
PiperOrigin-RevId: 274561876
olly committed -
PiperOrigin-RevId: 274534626
olly committed
-
- 13 Oct, 2019 15 commits
-
-
Issue: #6523 PiperOrigin-RevId: 274160232
andrewlewis committed -
It's documented to be for temporary loss only (i.e. the case where externally reported playWhenReady is still true) PiperOrigin-RevId: 274129922
olly committed -
PiperOrigin-RevId: 273971120
krocard committed -
This supports both chunkless & traditional preparation PiperOrigin-RevId: 273938344
ibaker committed -
Playback cannot be suppressed if playWhenReady=false PiperOrigin-RevId: 273726084
olly committed -
PiperOrigin-RevId: 273549830
Oliver Woodman committed -
Issue: #6297 PiperOrigin-RevId: 273297284
olly committed -
It's confusing that app:played_color also modifies the colors that derive from it, but the corresponding setter does not. It seems generally clearer just to define constants. PiperOrigin-RevId: 273249557
olly committed -
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
olly committed -
PiperOrigin-RevId: 272856747
Oliver Woodman committed -
These seem to be created by the Android Studio layout inspector PiperOrigin-RevId: 272856118
ibaker committed -
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
olly committed -
PiperOrigin-RevId: 272654378
andrewlewis committed -
Log only if an error occured. PiperOrigin-RevId: 272618322
sofijajvc committed -
PiperOrigin-RevId: 272614917
olly committed
-