r2.10.7 #6619
Merged
r2.10.7 #6619
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
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
PiperOrigin-RevId: 276660235
Float.MIN_VALUE is very close to zero: PiperOrigin-RevId: 276674142
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
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
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
PiperOrigin-RevId: 277910360
- 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
…tion Which ensures both get updated when the MediaSessionConnector player changes. Issue:#6582 PiperOrigin-RevId: 277254889
PiperOrigin-RevId: 277963928
PiperOrigin-RevId: 278332587
PiperOrigin-RevId: 278658259
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.