SDK / exoplayer

Configure MediaCodec in API 32+ to always output 99 channels
so that we use the audio is spatialized, if the platform can apply
spatialization to it.

In a follow-up change, the output channel count will be set based on the
device's spatialization capabilities.

PiperOrigin-RevId: 414751543

`DefaultAudioSink` already has 3 telescoping
constructors and an other one would be have been
needed to add a buffer size tuning option.

PiperOrigin-RevId: 414703366

The existing code creates an imbalance between `inputBufferCount` and
`droppedBufferCount` by adding 'dropped source buffers' to
`droppedBufferCount` but not to `inputBufferCount`. This results in
assertion failures in `DashTestRunner`.

PiperOrigin-RevId: 414672175

#minor-release

PiperOrigin-RevId: 414671861

It's been observed that some devices fail when releasing a secure codec
attached to a surface and immediately trying to create a new codec
(secure or insecure) attached to the same surface. This change catches
all exceptions thrown during codec creation, sleeps for a short time,
and then retries the codec creation. This is observed to fix the problem
(we believe this is because it allows enough time for some background
part of the previous codec release operation to complete).

This change should have no effect on the control flow when codec
creation succeeds first time. It will introduce a slight delay when
creating the preferred codec fails (while we sleep and retry), which
will either delay propagating a permanent error or attempting to
initialize a fallback decoder. We can't avoid the extra delay to
instantiating the fallback decoder because we can't know whether we
expect the second attempt to create the preferred decoder to succeed or
fail. The benefit to always retrying the preferred decoder creation
(fixing playback failures) outweighs the unfortunate additional delay
to instantiating fallback decoders.

Issue: google/ExoPlayer#8696
#minor-release
PiperOrigin-RevId: 414671743

Also, made a few other refactoring changes for clarity. No functional changes
intended.

PiperOrigin-RevId: 414487729

The decoder is using the SVC NAL unit prefix data on some Samsung
devices.

PiperOrigin-RevId: 414457181

PiperOrigin-RevId: 414428415

Issue: google/ExoPlayer#9673

#minor-release

PiperOrigin-RevId: 414413320

Also, add 144p as an acceptable output resolution, to allow for
a more obvious resolution difference when running the demo.

PiperOrigin-RevId: 414406664

The new field matches the platform's
AudioAttributes.getSpatializationBehavior() API added in Sv2. At the
moment, the platform API is called via reflection, until Sv2 is released
and the compile SDK target can be increased to 32.

PiperOrigin-RevId: 414406126

outputHeight is the actual output height while
transformation.outputHeight could be Format.NO_VALUE
causing the FrameEditor to be used more often than
necessary in the old version.

PiperOrigin-RevId: 414304251

When calling Android's Log class directly, there's a LongLogTag
lint check that detects tags over the 23 char limit, however it
cannot detect long log tags in ExoPlayer due to the way that we
log via our own Log class. This commit adds @Size annotations to
enforce the same rule.

PiperOrigin-RevId: 413976364

On the Sony Android TV device where this was originally reproducible on Android L, on Android N there is an E-AC3 decoder listed which handles the stream correctly. The workaround is harmless anyway but adding the API version restriction means it will be obvious it can be removed once we bump our min API to 24 or above in the future.

#minor-release

PiperOrigin-RevId: 413967443

Using chunkless preparation greatly improves start up time if the master
playlist declares CODECS for the renditions. Hence, we turn this on
by default as it benefits most well-defined HLS master playlists.

The only known reason why developers may want to turn this feature off is
when the renditions contain muxed closed-caption tracks that are not
declared in the master playlist. So this change also updates the documentation
and RELEASENOTES to point out this caveat.

PiperOrigin-RevId: 413950036

Increase timeout for dequeueing a frame from the codec to reduce flakiness. At a timeout of 2 seconds there was a 2/1000 flake rate and at 3 seconds 0/1000. Set the timeout to 5 seconds to give plenty of leeway.

PiperOrigin-RevId: 413946915

PiperOrigin-RevId: 413922123

#minor-release
Issue: google/ExoPlayer#9528
PiperOrigin-RevId: 413887784

When no editing is needed, the OpenGL steps can be skipped.

PiperOrigin-RevId: 413884305

Hardware audio decoders aren't really a thing, particularly on older
devices. SOC vendors do sometimes provide their own software decoders
though. Hence we update the approximation to assume that audio
decoders on older devices are software.

PiperOrigin-RevId: 413757859

PiperOrigin-RevId: 413751821

PiperOrigin-RevId: 413682281

Issue: google/ExoPlayer#9744

We do not rely on the payload type to determine the sample MIME type, we depend
on the SDP message, so it's worthless checking the payload type.

After removing the line, a server can use payload type 35 (an unassigned
payload type) for H264; while normally H264 requires payload type >= 96).

PiperOrigin-RevId: 413658076

Previously, transformation_matrix was incorrectly applied to
texture sampling coordinates, which led to transformations
seemingly moving in the opposite position, and an undesirable
GL_CLAMP_TO_EDGE behavior when sampling outside the edge of
the texture.

PiperOrigin-RevId: 413653360

Allowing duplicate groups caused some other code working with the
array to use reference equality comparison. This is error-prone,
easily forgotten (e.g. when using the TrackGroups in a map) and
causes bugs when TrackGroups are serialized to disk or to another
process.

All TrackGroups created by ExoPlayer are already unique and custom
code creating TrackGroupArrays with identical groups can easily
distringuish them by adding an id to each group.

Issue: google/ExoPlayer#9718
PiperOrigin-RevId: 413617005

It seems fine to remove the documentation about the WebM case now we are only supporting unfragmented MP4, so that new users coming to this API aren't confused about how to set the container MIME type.

PiperOrigin-RevId: 413611472

This allows to give TrackGroups an identifier. The underlying goal is
to provide a way to make otherwise identical TrackGroups
distinguishable.

Also set this id in all internal sources that may produce identical
TrackGroups in certain edge cases.

Issue: google/ExoPlayer#9718
PiperOrigin-RevId: 413430719

Allows a transformation matrix to be input into Transformer,
to apply vertex transformations like cropping, rotation,
and other transformations built into android.graphics.Matrix.

Not building out into a VertexTransformation class yet, as
that class structure wouldn't make sense until we can modify
resolution, per TODOs.

PiperOrigin-RevId: 413384409

This will remove the need to implement compat code handling very old API
versions where some symbols are not available, and it reduces the burden of
dealing with media framework issues around concurrent codec usage that are
worse on older API versions. Top apps that we've surveyed as potential users
for transformer library features are using API 21 or later.

PiperOrigin-RevId: 413341540

PiperOrigin-RevId: 413188534

Sometimes the empty end of stream buffer has a non-zero
data limit. Calling flip first, resets the limit to the
position which is zero in these cases.

PiperOrigin-RevId: 413156455

The test extracts and decodes the first video frame in the test media, renders it to the frame editor's input surface and then processes data. It then reads back the output from the frame editor, converts it to a bitmap and then compares that with a 'golden' bitmap (which is just the same as the test media's first video frame).

PiperOrigin-RevId: 413131811

*** Original commit ***

Remove usage of @ForOverride.

Fixes the gradle compilation failures.

Gradle dependencies need revising if we want to be using this, as
checkerframework is ahead of their latest version, such that we
can't compile.

***

PiperOrigin-RevId: 412901827

PiperOrigin-RevId: 412901581

PiperOrigin-RevId: 412856100

Currently we prefer technical preferences set in the Parameters over
content preferences implied by the media. It proably makes more
sense in the opposite order to avoid the situation where a
non-default track (e.g. commentary) is selected just because it
better matches some technical criteria.

Also add comments explaining the track selection logic stages.

PiperOrigin-RevId: 412840962

When the input is not a slow motion video, then flattening should do
nothing, so there is no need to re-encode audio.

PiperOrigin-RevId: 412443097

PiperOrigin-RevId: 412438389

Use @VisibleForTesting and add some comments for GL code.

Refactoring change only. No functional changes intended

PiperOrigin-RevId: 412428196

Issue: google/ExoPlayer#9719

#minor-release

PiperOrigin-RevId: 412424558