Skip to content

SDK / exoplayer

Go to a project
Switch branch/tag
  1. 28 Jul, 2022 1 commit
  3. 19 Oct, 2022 1 commit
  5. 27 Jul, 2022 3 commits
  7. 26 Jul, 2022 10 commits
  9. 25 Jul, 2022 5 commits
  11. 22 Jul, 2022 1 commit
    • Allow stream offset passed to GlEffectsFrameProcessor to change. · b9f6df79 
      This is needed for applying effects to a playlist.

The effects are applied based on the presentation time of the
frame in its corresponding media item and the offset is added
back before encoding.

Each time the offset changes, end of input stream is signalled
to the texture processors. This is needed because the texture
processors can expect monotonically increasing timestamp within
the same input stream but when the offset changes, the timstamps
jump back to 0.

PiperOrigin-RevId: 462714966
(cherry picked from commit 46ab06b8)
      hschlueter committed
  13. 21 Jul, 2022 3 commits
  15. 20 Jul, 2022 1 commit
  17. 19 Jul, 2022 6 commits
  19. 18 Jul, 2022 5 commits
    • HDR: Use FP16 color representation for texture processors. · 76093e25 
      * 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 f67c1a73)
      huangdarwin committed
    • HDR: Throw when unexpected color transfer encountered. · 7d147509 
      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 fd046bd2)
      huangdarwin committed
    • Use the current overrides of the player as preset · 26b062bf 
      Issue: google/ExoPlayer#10429
PiperOrigin-RevId: 461577039
(cherry picked from commit f828130c)
      bachinger committed
    • Make minor fixes to HDR handling · 0e156891 
      - 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 0db07c67)
      andrewlewis committed
    • Update demo HDR10 video URL · ce3cdf85 
      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 405be80f)
      andrewlewis committed
  21. 15 Jul, 2022 1 commit
  23. 14 Jul, 2022 1 commit
  25. 13 Jul, 2022 2 commits
    • Use COLOR_Format32bitABGR2101010 for HDR encoder configuration. · 79e75cc6 
      Also remove VideoEncoderSettings.colorProfile as there are no
concrete use cases for customizing this and it clashes with picking
the color format automatically based on SDR vs. HDR.

PiperOrigin-RevId: 460746987
(cherry picked from commit db78a87f)
      hschlueter committed
    • Use SingleThreadExecutor to release AudioTracks · 2d640e49 
      We currently start a simple Thread to release AudioTracks
asynchronously. If many AudioTracks are released at the same
time, this may lead to OOM situations because we attempt to
create multiple new threads.

This can be improved by using a shared SingleThreadExecutor.
In the simple case of one simmultaneous release, it's exactly
the same behavior as before: create a thread and release it
as soon as it's done. For multiple simultanous releases we
get the advantage of sharing a single thread to avoid creating
more than one at the same time.

Issue: google/ExoPlayer#10057
PiperOrigin-RevId: 460698942
(cherry picked from commit 1e8d1631)
      tonihei committed