Skip to content

SDK / exoplayer

Go to a project
Switch branch/tag
  1. 22 Jul, 2022 1 commit
  3. 21 Jul, 2022 2 commits
  5. 15 Jul, 2022 1 commit
  7. 13 Jul, 2022 2 commits
  9. 12 Jul, 2022 2 commits
    • Add migration script · 6180035e 
      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 f9a39201)
      bachinger committed
    • Don't set the tag in CastTimeline · 05a1bbf6 
      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 b61a06ba)
      bachinger committed
  11. 13 Jul, 2022 1 commit
  13. 12 Jul, 2022 2 commits
  15. 11 Jul, 2022 2 commits
    • Use the public MediaItem in the timeline of CastPlayer · fe6baee7 
      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 30fbc3a2)
      bachinger committed
    • Listen to playWhenReady changes in LeanbackPlayerAdapter · 329aa586 
      #minor-release

Issue: google/ExoPlayer#10420
PiperOrigin-RevId: 460223064
(cherry picked from commit 4eb34e4c)
      christosts committed
  17. 07 Jul, 2022 3 commits
    • Add tests for extracting MP4 with large bitrates · c40d669c 
      Also added the test to `MP4PlaybackTest`.

PiperOrigin-RevId: 459492188
(cherry picked from commit 05e728a3)
      rohks committed
    • Add missing Nullable annotation · f9e08274 
      PiperOrigin-RevId: 459485334
(cherry picked from commit cb87b743)
      christosts committed
    • Don't block AudioTrack when waiting for previous release · 9af65a90 
      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 a83ab05a)
      tonihei committed
  19. 06 Jul, 2022 1 commit
  21. 07 Jul, 2022 1 commit
  23. 06 Jul, 2022 1 commit
  25. 05 Jul, 2022 1 commit
  27. 04 Jul, 2022 1 commit
  29. 01 Jul, 2022 5 commits
  31. 29 Jun, 2022 1 commit
  33. 28 Jun, 2022 4 commits
  35. 27 Jun, 2022 2 commits
  37. 23 Jun, 2022 1 commit
  39. 21 Jun, 2022 1 commit
    • Clear pending doSomeWork messages when sleeping for offload · 59fbb455 
      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
  41. 20 Jun, 2022 1 commit
  43. 17 Jun, 2022 2 commits
  45. 16 Jun, 2022 2 commits