- 08 Jun, 2022 2 commits
-
-
PiperOrigin-RevId: 453633920 (cherry picked from commit d5e4faa9)
hschlueter committed -
SingleFrameGlTextureProcessor is now an abstract class containing a default implementation of the more flexible GlTextureProcessor interface while still exposing the same simple abstract methods for single frame processing it previously did. FrameProcessorChain and GlEffect will be changed to use GlTextureProcessor in follow-ups. PiperOrigin-RevId: 453633000 (cherry picked from commit 0b37d860)
hschlueter committed
-
- 06 Jun, 2022 1 commit
-
-
Implementations of this interface will be able to drop or add frames, change timestamps, accept multiple input frames before producing output, and process frames on their own background thread. A default implementation of this interface will be added to SingleFrameGlTextureProcessor in a follow-up. PiperOrigin-RevId: 453159835 (cherry picked from commit 023d19c8)
hschlueter committed
-
- 31 May, 2022 2 commits
-
-
This internal listener avoids wrapping the TransformationExceptions in PlaybackExceptions that are handled via the Player.Listener and is also used for FrameProcessingExceptions which already avoided the PlaybackException layer previously. This listener will also be useful in follow-ups for encoder-related TransformationExceptions that are thrown in the SurfaceProvider that will be called on the GL thread. PiperOrigin-RevId: 452074575 (cherry picked from commit 960422e3)
hschlueter committed -
Once the more advanced GlTextureProcessor interface exists, it will be possible to change the output size of a GlTextureProcessor between frames. To keep the re-configuration based on the frame sizes minimal, things indepedent of the frame size, such as the GlProgram, can be initialized in the constructor. PiperOrigin-RevId: 451997584 (cherry picked from commit 54d44d38)
hschlueter committed
-
- 30 May, 2022 1 commit
-
-
Gives a bit more information upon failures PiperOrigin-RevId: 451882968 (cherry picked from commit d1c3b051)
aquilescanta committed
-
- 22 Jul, 2022 1 commit
-
-
r2.18.1
Rohit Kumar Singh committed
-
- 21 Jul, 2022 1 commit
-
- 15 Jul, 2022 2 commits
-
- 13 Jul, 2022 2 commits
-
-
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: androidx/media#116 #minor-release PiperOrigin-RevId: 460721541 (cherry picked from commit 6be0d6ea)
tonihei committed -
PiperOrigin-RevId: 460689252 (cherry picked from commit 60437397)
Rohit Singh committed
-
- 12 Jul, 2022 2 commits
-
-
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 9d87c0db)
bachinger committed
- 13 Jul, 2022 1 commit
-
-
PiperOrigin-RevId: 460513413 (cherry picked from commit c75b6a3a)
Rohit Singh committed
-
- 12 Jul, 2022 2 commits
-
- 11 Jul, 2022 2 commits
-
-
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: androidx/media#25 Issue: google/ExoPlayer#8212 #minor-release PiperOrigin-RevId: 460325235 (cherry picked from commit 02e1484e)
bachinger committed -
#minor-release Issue: google/ExoPlayer#10420 PiperOrigin-RevId: 460223064 (cherry picked from commit c43d9f5b)
christosts committed
-
- 07 Jul, 2022 4 commits
-
-
PiperOrigin-RevId: 459485334 (cherry picked from commit 752e82df)
christosts committed -
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 a80dd604)tonihei committed -
PiperOrigin-RevId: 459215225 (cherry picked from commit 95218076)
Rohit Singh committed
- 06 Jul, 2022 1 commit
-
- 05 Jul, 2022 1 commit
-
- 07 Jul, 2022 1 commit
-
-
PiperOrigin-RevId: 458883441 (cherry picked from commit 486c3504)
Rohit Singh committed
-
- 01 Jul, 2022 3 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 577e1916)
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. #minor-release PiperOrigin-RevId: 458423162 (cherry picked from commit 9e10286b)
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 5c7ec13e)
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 aedde2de)
tonihei committed -
This was likely missed in https://github.com/google/ExoPlayer/commit/33373d0d0a159ad9c9c3590c838098c4c1530910. PiperOrigin-RevId: 457422574 (cherry picked from commit aaa01529)
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 251389d7)
tonihei committed
-
- 20 Jun, 2022 1 commit
-
- 17 Jun, 2022 1 commit
-
-
r2.18.0
Ian Baker committed
-