Skip to content

SDK / exoplayer

Go to a project
Switch branch/tag
  1. 20 Jul, 2022 3 commits
    • Make DefaultMediaNotificationProvider more configurable · 62a2d76d 
      Add a Builder to constructor DefaultMediaNotificationProvider. The
Builder can also set the provider's:
- notification ID
- notification channel ID
- notification channel name

The change adds an API for apps to set the small icon in notifications.

#minor-release
Issue: androidx/media#104
PiperOrigin-RevId: 462111536
(cherry picked from commit 436ff6d8)
      christosts committed
    • Run MediaSessionStub commands in order · eb823a9a 
      Some commands are run asynchronously and subsequent commands need
to wait until the previous one finished. This can be supported
by returning a Future for each command and using the existing
command execution logic to wait for each Future to complete.

As some MediaSessionStub code is now executed delayed to when it
was originally created, we also need to check if the session is
not released before triggering any actions or sending result codes.

Issue: androidx/media#85
PiperOrigin-RevId: 462101136
(cherry picked from commit 7cb7636e)
      tonihei committed
    • Properly chain commands in MediaSessionStub · d84662e5 
      The commands currently use a task and a postTask that are chained
together manually. In some cases, e.g. when adding MediaItems,
the postTask is already a chain of commands in itself.

To allow using the entire command handling as a single task
(for simplified queueing), we can change the implementation to
always create a single task. If multiple subtasks need to be
chained together, we can do that by wrapping the method calls.
In case a task is asynchronous, we can also use Futures to
chain them together.

Overall, this is just a refactoring and changes no logic.

Issue: androidx/media#85
PiperOrigin-RevId: 462085724
(cherry picked from commit 45f1f5b3)
      tonihei committed
  3. 19 Jul, 2022 9 commits
  5. 18 Jul, 2022 6 commits
    • HDR: Use FP16 color representation for texture processors. · 54cdec46 
      * Introduced `useHdr` for `GlEffect#toGlTextureProcessor`, so
  `TextureProcessor` implementations can decide how to handle HDR.
* Creating FP16 color textures for HDR input.

Tested via manual testing, adding a no-op GlEffectWrapper to the transformation to
force use of intermediate textures, adding a linear ramp to the fragment shader,
and trying to ascertain that there's a real reduction in posterization when
switching from 4-bit to 8-bit unsigned bytes, and again from 8-bit unsigned bytes
to 16-bit floating point.

PiperOrigin-RevId: 461613117
(cherry picked from commit ba9c9bb9)
      huangdarwin committed
    • HDR: Throw when unexpected color transfer encountered. · add44470 
      This may happen when a containers' color transfer incorrectly does not match
the video's color transfer.

An example of a file with such a mismatch is the current Transformer demo HDR10
sample file.

Manually tested by confirming that no errors are emitted for SDR and HLG sample
files, and that errors are emitted for our incorrect HDR10 sample file.

PiperOrigin-RevId: 461583532
(cherry picked from commit 9f7a159b)
      huangdarwin committed
    • Implement getCurrentTracks in MediaController · 24bfe3a5 
      After this change the current tracks are sent to the controller as part of
`PlayerInfo` and call `Listener.onTracksChanged()` in case of a change in tracks.

PiperOrigin-RevId: 461578695
(cherry picked from commit 9a895cd1)
      bachinger committed
    • Use the current overrides of the player as preset · db25954d 
      Issue: google/ExoPlayer#10429
PiperOrigin-RevId: 461577039
(cherry picked from commit 5c2aabca)
      bachinger committed
    • Make minor fixes to HDR handling · 04fa2fda 
      - Update profile selection logic to pick an HDR-compatible profile when doing HDR editing on H.264/AVC videos.
- Handle doing the capabilities check for all MIME types that support HDR (not just H.265/HEVC).
- Fix a bug where we would pass an HDR input color format to the encoder when using tone-mapping.
- Tweak how `EncoderWrapper` works so decisions at made at construction time.

Manually tested cases:
- Transformation of an SDR video.
- Transformation of an HDR video to AVC (which triggers fallback/tone-mapping on a device that doesn't support HDR editing for AVC).
- Transformation of an HDR video with HDR editing.

PiperOrigin-RevId: 461572973
(cherry picked from commit 604ab7fc)
      andrewlewis committed
    • Update demo HDR10 video URL · c4e64c3d 
      The old URL doesn't correctly signal the HDR10 color info in the container.

The new URL signals ST2084 (PQ) transfer function and BT.2020 color space as expected.

PiperOrigin-RevId: 461560107
(cherry picked from commit 794e366b)
      andrewlewis committed
  7. 15 Jul, 2022 1 commit
  9. 14 Jul, 2022 1 commit
  11. 13 Jul, 2022 5 commits
  13. 12 Jul, 2022 7 commits
  15. 11 Jul, 2022 2 commits
  17. 07 Jul, 2022 1 commit
  19. 06 Jul, 2022 2 commits
  21. 05 Jul, 2022 1 commit
  23. 04 Jul, 2022 1 commit
  25. 01 Jul, 2022 1 commit
    • Fallback to SDR if encoder doesn't support HDR (HLG only). · 3bdecf2a 
      If the input is HDR (HLG), check encoder capabilities for HDR support
and request tone-mapping to SDR during decoder configuration otherwise.
Capabilities are only checked for API 31 and above, as HDR editing is
not supported before.

As the encoder capabilities check needs to happen before selecting the
encoder to use (as this may depend on the resolution output by the
effects chain), the EncoderWrapper checks all candidate encoders
for the MIME type for HDR capabilities and only requests fallback to
SDR if none of them support it.

When the actual encoder is selected, the wrapper checks that it matches
one of the encoders is checked capabilities for.

PiperOrigin-RevId: 458511599
(cherry picked from commit 9c8dcb40)
      hschlueter committed