- 06 Jul, 2022 1 commit
-
- 07 Jul, 2022 1 commit
-
-
PiperOrigin-RevId: 459215225 (cherry picked from commit f00f93a9)
Rohit Singh committed
-
- 06 Jul, 2022 1 commit
-
- 05 Jul, 2022 1 commit
-
- 04 Jul, 2022 1 commit
-
-
PiperOrigin-RevId: 458883441 (cherry picked from commit 8e5af4a3)
Marc Baechinger committed
-
- 01 Jul, 2022 5 commits
-
-
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 ceb23e69)
tonihei committed -
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 21638fa3)
rohks committed
-
- 29 Jun, 2022 1 commit
-
- 28 Jun, 2022 4 commits
-
-
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 6f9ce405)
ibaker committed
-
- 27 Jun, 2022 2 commits
-
-
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 5c2752b4)
tonihei committed -
This was likely missed in https://github.com/androidx/media/commit/33373d0d0a159ad9c9c3590c838098c4c1530910. PiperOrigin-RevId: 457422574 (cherry picked from commit 8e716d68)
tonihei committed
-
- 23 Jun, 2022 1 commit
-
- 21 Jun, 2022 1 commit
-
-
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 a7649b63)
tonihei committed
-
- 20 Jun, 2022 1 commit
-
- 16 Jun, 2022 1 commit
-
-
#minor-release PiperOrigin-RevId: 455380010 (cherry picked from commit 7563bd27)
christosts committed
-
- 15 Jun, 2022 2 commits
-
-
PiperOrigin-RevId: 455157744 (cherry picked from commit 12e75627)
christosts committed
-
- 10 Jun, 2022 1 commit
-
- 07 Jun, 2022 1 commit
-
- 17 Jun, 2022 1 commit
-
-
The API 32 SDK has incorrect versioning metadata for Spatializer. It reports the whole class has only been present since API 33 (which is surely impossible given it's present in the API 32 SDK): https://issuetracker.google.com/234009300 The metadata seems to be correct in the API 33 SDK, so this baseline will no longer be needed when we bump to `compileSdkVersion = 33`.
Ian Baker committed
-
- 16 Jun, 2022 5 commits
-
-
Fixing lint errors in the string.xml files makes no sense because these are overridden with the next automated string import. Adding a lint-baseline.xml instead for the ui module. See https://issuetracker.google.com/208178382 #minor-release PiperOrigin-RevId: 455354304 (cherry picked from commit 61ab75b8)
bachinger committed -
PiperOrigin-RevId: 455347182 (cherry picked from commit dc0e5c44)
Marc Baechinger committed
- 15 Jun, 2022 9 commits
-
-
These calls were not implemented so far as they require a mix of initial prepareFrom/playFrom calls and addQueueItem. We can also support clients without queue handling to set single MediaItems. To make the calls consistent and predictable in the session, we need to ensure that none of the play/pause/addQueueItem/ removeQueueItem/prepare/playFromXYZ/prepareFromXYZ are called before the controller is prepared and has media. #minor-release PiperOrigin-RevId: 455110246 (cherry picked from commit b475f1f2)
tonihei committed -
PiperOrigin-RevId: 455094147 (cherry picked from commit ad3348cc)
Marc Baechinger committed -
See https://issuetracker.google.com/208178382 PiperOrigin-RevId: 454949204 (cherry picked from commit 1f380c1d)
bachinger committed
