SDK / exoplayer

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

PiperOrigin-RevId: 460459378

I don't think it's useful to keep these in numerical order, it makes
more sense to keep them grouped into a 'logical' ordering.

#minor-release

PiperOrigin-RevId: 460453464

Pass the color info and HDR static metadata when configuring the decoder
using MediaFormatUtil.maybeSetColorInfo.

PiperOrigin-RevId: 460424985

This extension is needed for editing HDR input with OpenGL, as the
ExternalTextureProcessor samples raw YUV values from the
external texture for HDR and converts them to RGB itself rather than
relying on the OpenGL driver to do this automatically as for SDR.

PiperOrigin-RevId: 460424154

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

This saves an intermediate texture copy step for use-cases
where matrix transformations are the first or only effects
in the chain.

PiperOrigin-RevId: 460239403

- Added setter to disable this feature.
- Added accompanying tests.
- Plan to run tests on the same set of settings on H265.

PiperOrigin-RevId: 460238673

#minor-release

Issue: google/ExoPlayer#10420
PiperOrigin-RevId: 460223064

Also added the test to `MP4PlaybackTest`.

PiperOrigin-RevId: 459492188

Some other minor nits and adjustments to the API logic.

PiperOrigin-RevId: 459490431

PiperOrigin-RevId: 459485334

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

The SDR constant also specified a color space and range, in addition to
C.COLOR_TRANSFER_SDR. However, it turns out that SDR videos may use different color
space and range values, so following prior ExoPlayer conventions to have `null`
mean "generic SDR" is preferable here.

PiperOrigin-RevId: 459296746

PiperOrigin-RevId: 459215618

PiperOrigin-RevId: 459215225

HDR editing is not supported under API 31

PiperOrigin-RevId: 459211106

This profile is declared as supported although it isn't.

Issue: google/ExoPlayer#10345
Issue: google/ExoPlayer#3537

#minor-release

PiperOrigin-RevId: 459205512

This is to be consistent with what cast `QueueMediaItem` is doing. If a contentId is
not available the contentUrl is used as the ID.

#minor-release

PiperOrigin-RevId: 459133323

PiperOrigin-RevId: 459106221

This feature is disabled by default for now.

PiperOrigin-RevId: 458932471

PiperOrigin-RevId: 458883441

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

Configure the GL shaders and encoder to take in HDR metadata.

This mostly just consists of passing the Format.colorInfo through
the VideoTranscodingSamplePipeline down to the encoder, rather than passing
the PQ-ness down to the GL step.

Due to b/237674316, this will remove HDR10+ support temporarily to introduce
support for HLG10.

Manually tested to confirm that HLG10 operations that don't affect color display
correctly after this CL with "HDR editing" in the demo checked, and continue to display incorrectly (as before this CL) without the option unchecked.

PiperOrigin-RevId: 458490810

The old getString() will throw because FRAME_RATE can only be float or int.

PiperOrigin-RevId: 458481251

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

We used "ALL_COOECS" previously, and it is not necessary because "ALL_CODECS"
additionally the codecs that support tunneling/secure decoding, which there
is no use case in Transformer.

PiperOrigin-RevId: 458470278

Issue: androidx/media#103
#minor-release
PiperOrigin-RevId: 458465479

This allows the service to be switched to run in another process and the app still works the same as if it is running in the same process.

Issue: androidx/media#100
PiperOrigin-RevId: 458460005

Although MediaCodec claims supporting float frame rate, encoder init failed on
API21 Nexus 5. Since it's just a performance hint to the codec, it's OK to
generalize it to other API versions.

PiperOrigin-RevId: 458434650

- Improve variable naming to include time units for clarity
- Fix existing timestamp calculations to respect time units as well as track tempo (default values for now)
- Ensure the synthesizer produces PCM for the correct amount of time (including gaps between commands).

PiperOrigin-RevId: 458428243

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

As per MP4 spec, the length of URL array is a 8 bit number.

#minor-release

PiperOrigin-RevId: 458421436

PiperOrigin-RevId: 458283415

The GlEffectsFrameProcessor that will be part of the effects module
uses the DebugViewProvider. So it does not make sense for it
to be an inner interface of Transformer.

PiperOrigin-RevId: 458014932

The FinalMatrixTransformationProcessorWrapper ensures that the
surface is only replaced when it is not being rendered to and vice
versa.

PiperOrigin-RevId: 458007639