SDK / exoplayer

- Add a checkbox in the demo app to enable experimental HDR editing.
- Add an `experimental_` method to `TransformationRequest` to enable HDR editing.
- Add fragment/vertex shaders for the experimental HDR pipeline. The main difference compared to the existing shaders is that we sample from the decoder in YUV rather than RGB (because the YUV -> RGB conversion in the graphics driver is not precisely defined, so we need to do this to get consistent results), which requires the use of ES 3, and then do a crude YUV -> RGB conversion in the shader (ignoring the input color primaries for now).
- When HDR editing is enabled, we force using `FrameEditor` (no passthrough) to avoid the need to select another edit operation, and use the new shaders. The `EGLContext` and `EGLSurface` also need to be set up differently for this path.

PiperOrigin-RevId: 425570639

Issue: google/ExoPlayer#8213

#minor-release

PiperOrigin-RevId: 425381474

This class is not ready to be released, and only exists in the dev-v2
branch.

TransformerTest sounds like a unit test for Transformer but these
tests test behaviour that involves multiple stages of the pipeline.

PiperOrigin-RevId: 425378369

PiperOrigin-RevId: 425341138

Add a constructor that takes a DrmSessionManagerProvider.
This allows R8 to strip the default implementation.

#minor-release

PiperOrigin-RevId: 425330083

Some phone with limited memory can't allocate bigger
shared memory buffers.
This might or might not be related to Binder's 1M
transaction limit.

Tested on Pixel 4 by setting the minimum buffer size to
1h.

https://github.com/google/ExoPlayer/issues/9712

#minor-release

PiperOrigin-RevId: 425324536

This makes sure the number of ads in an ad group matches to the number of periods representing an ad group in a multi-period timeline. This makes it easier to accurately mark ads as played in multi-period windows which is needed to correctly prevent seeking over unplayed ads.

PiperOrigin-RevId: 425317085

If
  a) the end of stream buffer arrives with a frame rather than an
     empty buffer or
  b) processDataV29() renders several decoder output buffers to the
     FrameEditor's input Surface immediately before encountering the
     EOS flag
these frames were previously stuck in the FrameEditor's input Surface
and never fed to the encoder.

PiperOrigin-RevId: 424898820

This test tests that all frames are processed when transcoding
video to a different sample MIME type (and that the transformation
completes successfully).

PiperOrigin-RevId: 424896014

This fixes some warnings that show up in Android Studio (due to using methods
that autobox unnecessarily).

PiperOrigin-RevId: 424892352

This allows access to custom renderers, for example to send messages
or to access custom fields and methods.

PiperOrigin-RevId: 424878963

*** Original commit ***

Apply suggested AVC profile depending on the API version.

***

PiperOrigin-RevId: 424856077

PiperOrigin-RevId: 424850283

Enforcing the correct thread usage has been enabled since 2.13.0.
Opting-out of this enforement is dangerous as it can hide very hard
to debug bugs.

PiperOrigin-RevId: 424815808

If muxerWrapper.release() was throwing an exception, the progress state
was not updated and getProgress could throw an exception.

#minor-release

PiperOrigin-RevId: 424696783

This shouldn't be required for transformer instrumentation tests, as they don't use a foreground service.

PiperOrigin-RevId: 424654463

The second error is probably a consequence of the first one.

#minor-release

PiperOrigin-RevId: 424619944

When the decoder output buffer was partially read, a call to
Codec.getOutputBuffer() was returning the same buffer, but with the
position reset to 0. The reason was that, in
Codec.maybeDequeueAndSetOutputBuffer(), mediaCodec.getOutputBuffer()
was called with the same buffer index (L350 in old rev), even though
there was already a buffer available (outputBufferIndex >=0). This
change avoids calling mediaCodec.getOutputBuffer() if the previous
buffer has not been released.

#minor-release

PiperOrigin-RevId: 424612197

If the encoder picks a fallback resolution the video pipeline needs
to take this into account when configuring the frameEditor and when
setting up the fallback TransformationRequest that's passed to the
fallbackListener.

PiperOrigin-RevId: 424611290

Move the code in its own class as DefaultAudioTrack
is getting very big. It also help for testability.

The new class is easily configurable and highly tested.
Manual test was used to catch any regression.

https://github.com/google/ExoPlayer/issues/8891

PiperOrigin-RevId: 424602011

AnalyticsCollector can't be null when passed into ExoPlayerImplInternal,
so there is no need to pass it around as nullable.

PiperOrigin-RevId: 424594031

Two of the sessions are finished at the same time in the test
and the order of the corresponding callbacks depends on the randomly
generated session string and the order these strings are stored in a
HashSet.

Update test to assert both callbacks are called and they contain the
right arguments, but don't assert on the order of these two callbacks.

PiperOrigin-RevId: 424548819

Ad playback shouldn't be affected by manual speed adjustments set
by the user. This change enforces unit speed for ad playback.

Issue: google/ExoPlayer#9018
PiperOrigin-RevId: 424546258

This only affects playbacks using the
experimentalUseProgressiveMediaSourceForSubtitles method.

Also update the SingleSampleMediaSource instantiation to be more
similar, to try and highlight differences like this in future.

PiperOrigin-RevId: 424545980

In some cases we need to update the PlaybackParameters at period
boundaries, for example when switching from live to VOD and live
playback speed adjustment was still active at the point of switching.

Currently, we send the update when the playing MediaPeriod changes in
EPII, which is slightly too late because the new speed gets only applied
after the entire existing AudioTrack buffer has been played out.

We can time the update slightly better by updating the values at the
point where we change the reading period. This makes the update slightly
too early because it also applies to all samples currently in the
decoder. But generally, this is a lot better because the time spent
in the decoder is likely to be considerably lower than the duration of
the AudioTrack buffer.

Note that this change isn't perfectly aligning to the period boundary,
but reduces the number of samples with the wrong speed to a minimum.
If we are getting around to add additional code that allows updating
the speed at exactly the boundary, it also needs to be triggered from
the reading period update, so the new code location is also helpful in
the future.

Issue: google/ExoPlayer#9018
PiperOrigin-RevId: 424540551

When I locally link to exoplayer source modules as described in the README and I
do this directly into a fig/citc client, I get an error saying
"missing_aar_type_workaround.gradle': 79: unexpected token: || @ line 79, column
29.". I can fix this by wrapping the expression in parenthesis (¯\_(ツ)_/¯).

I don't think this file lands in the public source tree, but if we want to
correct this, it may help someone from the team.

This CL can be ignored and reverted also.

PiperOrigin-RevId: 424537619

PiperOrigin-RevId: 424383900

PiperOrigin-RevId: 424382031

PiperOrigin-RevId: 424379489

PiperOrigin-RevId: 424366617

PiperOrigin-RevId: 424355325

PiperOrigin-RevId: 424322341

PiperOrigin-RevId: 424287392

PiperOrigin-RevId: 424081451

PiperOrigin-RevId: 424062588

Issue: google/ExoPlayer#9811
PiperOrigin-RevId: 423855051

Issue: google/ExoPlayer#9811
PiperOrigin-RevId: 423849421

PiperOrigin-RevId: 423822317

* @CryptoType is a TYPE_USE annotation, so should appear after modifiers and directly before the type.
  (see go/java-style#s4.8.5-annotations)

This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if the change looks generally problematic.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.

This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.

#codehealth

Tested:
    Local presubmit tests passed.

PiperOrigin-RevId: 423821355