SDK / exoplayer

It's always safe to ignore the result of these methods, because the
caller already has a reference to the returned value.

PiperOrigin-RevId: 462388947

r2.18.1

Issue: google/ExoPlayer#10454
PiperOrigin-RevId: 462375294

Also rearranged release notes to correctly show when the changes were released.

#minor-release

PiperOrigin-RevId: 462361982
(cherry picked from commit c6e69a35)

Also rearranged release notes to correctly show when the changes were released.

#minor-release

PiperOrigin-RevId: 462361982

This allows us to use BT.2020 RGB linear for intermediate shaders, which also
allows us to re-enable PeriodicVignetteProcessor, which should work properly in
linear color-spaces.

Manually tested by adding a GlEffectsWrapper, and confirming that HLG HDR editing still looks correct.

PiperOrigin-RevId: 462265821

PiperOrigin-RevId: 462232813

#minor-release

PiperOrigin-RevId: 461902089

This adds two methods that are helpful when working with Futures.
One is a version of postOrRun that can indicate completion by a
Future and the other is a simplified version of Guava's
Futures.transformAsync (which can't be used as it's in Beta).

PiperOrigin-RevId: 461896598

Issue: androidx/media#10310
#minor-release
PiperOrigin-RevId: 461889651

PiperOrigin-RevId: 461888238

Otherwise, invalid ColorInfo instances generated using faulty
MediaFormat#getInteger values could cause exceptions.

Confirmed that b/239435670 reproduces without this CL, and does not reproduce
with this CL.

PiperOrigin-RevId: 461862191

This will help developers self-diagnose issues like Issue: google/ExoPlayer#10392
where the NPE occurs far from the original null value because a field
gets assigned to null.

This change aims to ensure that every stable method on Player,
ExoPlayer and ExoPlayer.Builder that takes a non-null type will fail
with an NPE before returning.

#minor-release

PiperOrigin-RevId: 461846580

* 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

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

Issue: google/ExoPlayer#10429
PiperOrigin-RevId: 461577039

- 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

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

#minor-release

PiperOrigin-RevId: 461177918
(cherry picked from commit 7a10dd15)

#minor-release

PiperOrigin-RevId: 461177918

PiperOrigin-RevId: 461165173

#minor-release

PiperOrigin-RevId: 461162552
(cherry picked from commit 6d27ff86)

#minor-release

PiperOrigin-RevId: 461162552

These are providing more variety and complexity.

All files are okay to be public.

PiperOrigin-RevId: 460935247

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

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

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

Add test that verifies SSIM with API enabled.

#minor-release

PiperOrigin-RevId: 460692420

PiperOrigin-RevId: 460689252

#cleanup
#minor-release

PiperOrigin-RevId: 460688226

PiperOrigin-RevId: 460662425

Note: This was already reviewed in <unknown commit>. This doesn't mean we cannot apply further changes though.
PiperOrigin-RevId: 460542835

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

PiperOrigin-RevId: 460513413

PiperOrigin-RevId: 460500666

`HevcConfig.parse` misreads reserved bit to determine NAL unit type. This is currently meant to be always set to 0, but could be given some kind of meaning in a future revision.

Issue: google/ExoPlayer#10366
PiperOrigin-RevId: 460487613

Issue: google/ExoPlayer#2518
PiperOrigin-RevId: 460482615

Issue: androidx/media#25
PiperOrigin-RevId: 460476841

Some calls to handleBuffer return false while a previous
flush is still handled in the background.

Fix this by either asserting the method returns true if
we don't expect any delay, or calling it repeatedly until
it returns true (within a timeout).

PiperOrigin-RevId: 460474419