r1.0.0 beta02 #120
Merged
r1.0.0 beta02 #120
Conversation
This file contains hidden or 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
PiperOrigin-RevId: 453510883 (cherry picked from commit 96274bf)
We need to request the external storage permission to access these PiperOrigin-RevId: 454160546 (cherry picked from commit b5f53e7)
PiperOrigin-RevId: 455121899 (cherry picked from commit 99cdc51)
PiperOrigin-RevId: 455157744 (cherry picked from commit 12e7562)
#minor-release PiperOrigin-RevId: 455380010 (cherry picked from commit 7563bd2)
Issue: google/ExoPlayer#10316 PiperOrigin-RevId: 456084302 (cherry picked from commit 6dc85dc)
The offload sleeping stops as soon as a new DO_SOME_WORK message is handled (because this indicates an expected change in rendering and we want to stop sleeping until we know it's safe to do so). Every exit path from doSomeWork needs to clear other pending DO_SOME_WORK messages as these requests have already been handled by the current method invocation. This currently doesn't happen from the offload sleeping return path and a previously queued DO_SOME_WORK message can immediately wake up the rendering loop again. Fix this by moving the message removal to the beginning of the doSomeWork method (as it prevents forgetting it in one of the exit paths later). PiperOrigin-RevId: 456259715 (cherry picked from commit a7649b6)
PiperOrigin-RevId: 456753343 (cherry picked from commit 1d2ad39)
1. The offloadSchedulingEnabled value doesn't need to be in PlaybackInfo because it's never updated in EPII. 2. The sleepingForOffload value in EPII wasn't updated explicitly (just via the return value of a method). It was also only meant to be enabled while the player is actively playing, but confusingly triggered from a path where the player may theoretically be buffering as well. 3. The offload sleeping (=not scheduling doSomeWork) was interwoven into the actual scheduling code making it slightly hard to follow. This can be improved slightly by keeping the offload sleeping decision and the scheduling separate. PiperOrigin-RevId: 457427293 (cherry picked from commit 5c2752b)
Issue: google/ExoPlayer#10363 PiperOrigin-RevId: 457679928 (cherry picked from commit a67db31)
PiperOrigin-RevId: 457680579 (cherry picked from commit b7241d4)
NoUidTimeline still exists as a private detail of TestUtil, but it no longer extends ForwardingTimeline because the interactions are quite hard to reason about. #minor-release PiperOrigin-RevId: 457703593 (cherry picked from commit 2a2d9e3)
Previously two timelines that differed only in shuffle order were considered equal, which resulted in no call to Player.Listener.onTimelineChanged when calling ExoPlayer.setShuffleOrder. This in turn resulted in no call to MediaControllerCompat.Callback.onQueueChanged. Also make a small fix inside ExoPlayerImpl.setShuffleOrder, to ensure that the new shuffle order is used when constructing the masked timeline. Issue: google/ExoPlayer#9889 #minor-release PiperOrigin-RevId: 457703727 (cherry picked from commit 6f9ce40)
Issue: google/ExoPlayer#10298 PiperOrigin-RevId: 457991028 (cherry picked from commit 3fc6a66)
As per MP4 spec, the length of URL array is a 8 bit number. #minor-release PiperOrigin-RevId: 458421436 (cherry picked from commit 42f13c3)
As per MP4 spec, bitrates in esds boxes can be a 32 bit number which doesn't fits in Java int type, so now reading it as a long value. Our class for holding media format, only allows bitrates value to be an int as we don't expect the bitrates to be greater than or equal to 2^31. So we're limiting the values for bitrates to Integer.MAX_VALUE. PiperOrigin-RevId: 458423162 (cherry picked from commit 21638fa)
ProgressiveMediaPeriod loads all available tracks into SampleStreams (because it needs to read the data anyway and it allows easy activation of tracks without reloading). However, the SampleStreams for disabled tracks are not read and no one if waiting for them. The buffered position is used for user-visible state (e.g. in the UI) and to check how much data is already buffered to decide when to stop buffering (using LoadControl). Both values benefit from only using the actually enabled tracks to better reflect what is available for playback at the moment. Issue:Issue: google/ExoPlayer#10361 PiperOrigin-RevId: 458475038 (cherry picked from commit ceb23e6)
PiperOrigin-RevId: 458883441 (cherry picked from commit 8e5af4a)
This is to be consistent with what cast `QueueMediaItem` is doing. If a contentId is not available the contentUrl is used as the ID. #minor-release PiperOrigin-RevId: 459133323 (cherry picked from commit 0a9f900)
This profile is declared as supported although it isn't. Issue: google/ExoPlayer#10345 Issue: google/ExoPlayer#3537 #minor-release PiperOrigin-RevId: 459205512 (cherry picked from commit 656eaf7)
We wait until a previous AudioTrack has been released before
creating a new one. This is currently done with a thread
block operation, which may cause ANRs in the extreme case
when someone attempts to release the player while this is
still blocked.
The problem can be avoided by just returning false from
DefaultAudioSink.handleBuffer to try again until the previous
AudioTrack is released.
Reproduction steps to force the issue:
1. Add Thread.sleep(10000); to the AudioTrack release thread.
2. Add this to the demo app:
private int positionMs = 0;
Handler handler = new Handler();
handler.post(new Runnable() {
@OverRide
public void run() {
player.seekTo(positionMs++);
if (positionMs == 10) {
player.release();
} else {
handler.postDelayed(this, 1000);
}
}
3. Observe Player release timeout exception.
These steps can't be easily captured in a unit test as we can't
artifically delay the AudioTrack release from the test.
Issue: google/ExoPlayer#10057
PiperOrigin-RevId: 459468912
(cherry picked from commit a83ab05)
PiperOrigin-RevId: 459485334 (cherry picked from commit cb87b74)
Also added the test to `MP4PlaybackTest`. PiperOrigin-RevId: 459492188 (cherry picked from commit 05e728a)
PiperOrigin-RevId: 459215225 (cherry picked from commit f00f93a)
PiperOrigin-RevId: 459215618 (cherry picked from commit 87adb88)
#minor-release Issue: google/ExoPlayer#10420 PiperOrigin-RevId: 460223064 (cherry picked from commit 4eb34e4)
The media item needs to be assigned to `Window.mediaItem` in `CastTimeline.setWindow`. For this the `MediaItem` needs to be available in the timeline. When a `MediaItem` is passed to the `set/addMediaItems` method, we can't yet know the Cast `MediaQueueItem.itemId` that is generated on the device and arrives with an async update of the `RemoteMediaClient` state. Hence in the `CastTimelineTracker`, we need to store the `MediaItem` by Casts's `MediaItem.contentId`. When we then receive the updated queue, we look the media item up by the content ID to augment the `ItemData` that is available in the `CastTimeline`. Issue: #25 Issue: google/ExoPlayer#8212 #minor-release PiperOrigin-RevId: 460325235 (cherry picked from commit 30fbc3a)
I don't think it's useful to keep these in numerical order, it makes more sense to keep them grouped into a 'logical' ordering. #minor-release PiperOrigin-RevId: 460453464 (cherry picked from commit ad46cb1)
Note: This was already reviewed in <unknown commit>. This doesn't mean we cannot apply further changes though. PiperOrigin-RevId: 460542835 (cherry picked from commit f9a3920)
PiperOrigin-RevId: 460513413 (cherry picked from commit 9d9bbe3)
Leaving the media item that has been passed in unchanged, ensures that the media item in the timeline is equal to the media item that the user has passed into the player. The value of the tag is the uid of the window, meaning this is redundant information. #minor-release PiperOrigin-RevId: 460542246 (cherry picked from commit b61a06b)
PiperOrigin-RevId: 460689252 (cherry picked from commit bd8723e)
The call doesn't currently reset the already loaded suppliers and factories. Also fix the supplier loading code to use a local copy of the current dataSourceFactory to avoid leaking an updated instance to a later invocation. Issue: #116 PiperOrigin-RevId: 460721541 (cherry picked from commit adc5051)
#minor-release PiperOrigin-RevId: 461162552 (cherry picked from commit be27dae)
Also rearranged release notes to correctly show when the changes were released. PiperOrigin-RevId: 462361982 (cherry picked from commit 26c8478)
tpower455
approved these changes
Sep 11, 2022
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.