1. 08 Jun, 2022 2 commits
  2. 06 Jun, 2022 1 commit
    • Add interface for async texture processors. · 84b46c10
      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
  3. 31 May, 2022 2 commits
    • Add async error listener to transformer to avoid exception wrapping. · a04cc94a
      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
    • Move program initialization to texture processor constructor. · 23b0610a
      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
  4. 30 May, 2022 1 commit
  5. 22 Jul, 2022 1 commit
  6. 21 Jul, 2022 1 commit
  7. 15 Jul, 2022 2 commits
  8. 13 Jul, 2022 2 commits
  9. 12 Jul, 2022 2 commits
    • Add migration script · 9b7674ab
      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 d59334c5)
      bachinger committed
    • Don't set the tag in CastTimeline · 268de237
      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
  10. 13 Jul, 2022 1 commit
  11. 12 Jul, 2022 2 commits
  12. 11 Jul, 2022 2 commits
    • Use the public MediaItem in the timeline of CastPlayer · 05e42ebb
      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
    • Listen to playWhenReady changes in LeanbackPlayerAdapter · 36a99cb1
      #minor-release
      
      Issue: google/ExoPlayer#10420
      PiperOrigin-RevId: 460223064
      (cherry picked from commit c43d9f5b)
      christosts committed
  13. 07 Jul, 2022 4 commits
    • Add tests for extracting MP4 with large bitrates · 43eb3d0f
      Also added the test to `MP4PlaybackTest`.
      
      PiperOrigin-RevId: 459492188
      (cherry picked from commit a1665841)
      rohks committed
    • Add missing Nullable annotation · f9f6cb34
      PiperOrigin-RevId: 459485334
      (cherry picked from commit 752e82df)
      christosts committed
    • Don't block AudioTrack when waiting for previous release · d39075a2
      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
    • Merge pull request #10260 from sr1990:clearkey_parse_licenseurl · ef966415
      PiperOrigin-RevId: 459215225
      (cherry picked from commit 95218076)
      Rohit Singh committed
  14. 06 Jul, 2022 1 commit
  15. 05 Jul, 2022 1 commit
  16. 07 Jul, 2022 1 commit
  17. 01 Jul, 2022 3 commits
    • Only consider enabled tracks in ProgressiveMediaPeriod.bufferedPosition · 84280c85
      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
    • Fix MP4 parser issue in reading bitrates from esds boxes. · 3d79536f
      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
    • Fix MP4 parser issue in reading length of URL array from esds boxes. · 3709e90e
      As per MP4 spec, the length of URL array is a 8 bit number.
      
      #minor-release
      
      PiperOrigin-RevId: 458421436
      (cherry picked from commit 5095ff16)
      rohks committed
  18. 29 Jun, 2022 1 commit
  19. 28 Jun, 2022 4 commits
  20. 27 Jun, 2022 2 commits
  21. 23 Jun, 2022 1 commit
  22. 21 Jun, 2022 1 commit
    • Clear pending doSomeWork messages when sleeping for offload · de78cfa3
      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
  23. 20 Jun, 2022 1 commit
  24. 17 Jun, 2022 1 commit