SDK / exoplayer

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

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

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

Issue: google/ExoPlayer#10298
#minor-release
PiperOrigin-RevId: 457991028

PiperOrigin-RevId: 457974611

The outputHeight in the TransformationRequest is the height of
the frame as it would be displayed (i.e., after applying any
rotation specified in the format). So pass-through should only
be used if the requested outputHeight matches the input
format's height after applying the rotation.

PiperOrigin-RevId: 457934867

Previously two timelines that differed only in shuffle order were
considered equal, which resulted in no call to
Player.Listener.onTimelineChanged when calling
ExoPlayer.setShuffleOrder. This in turn resulted in no call to
MediaControllerCompat.Callback.onQueueChanged.

Also make a small fix inside ExoPlayerImpl.setShuffleOrder, to ensure
that the new shuffle order is used when constructing the masked
timeline.

Issue: google/ExoPlayer#9889
#minor-release
PiperOrigin-RevId: 457703727

NoUidTimeline still exists as a private detail of TestUtil, but it no
longer extends ForwardingTimeline because the interactions are quite
hard to reason about.

#minor-release

PiperOrigin-RevId: 457703593

pixelWidthHeightRatio is now passed to setInputFrameInfo instead of
the factory.

PiperOrigin-RevId: 457696703

PiperOrigin-RevId: 457680579

Issue: google/ExoPlayer#10363
PiperOrigin-RevId: 457679928

`MetadataRenderer` is updated to output `Metadata` with its presentation time, in microseconds.

PiperOrigin-RevId: 457444718

1. The offloadSchedulingEnabled value doesn't need to be in
   PlaybackInfo because it's never updated in EPII.
2. The sleepingForOffload value in EPII wasn't updated explicitly
   (just via the return value of a method). It was also only
   meant to be enabled while the player is actively playing, but
   confusingly triggered from a path where the player may
   theoretically be buffering as well.
3. The offload sleeping (=not scheduling doSomeWork) was interwoven
   into the actual scheduling code making it slightly hard to follow.
   This can be improved slightly by keeping the offload sleeping
   decision and the scheduling separate.

PiperOrigin-RevId: 457427293

This was likely missed in https://github.com/google/ExoPlayer/commit/33373d0d0a159ad9c9c3590c838098c4c1530910.

PiperOrigin-RevId: 457422574

PiperOrigin-RevId: 457023382

This will be useful for downgrading to a lower resolution during
a slow preview and for processing slide-shows once sequential
multi-asset editing is supported.

PiperOrigin-RevId: 457017255

- Corrected trackEventBytes traversal in TrackChunk where the array position marker was not incremented properly, leading to duplicate sample output.
- Amended TrackEvent "Meta Event" parsing to account for the length of variable length bytes.
- Fixed a bug with TrackEvent message parsing where message data was parsed incorrectly due to miscalculated length.

PiperOrigin-RevId: 456967968

PiperOrigin-RevId: 456814150

videoEncoderFormatUnsupported_completesWithError() has recently
been flaky on API 31 emulators on presubmit because a different
exception than the expected exception is thrown.
This disables it on those emulators to reduce testing noise
until the underlying problem is investigated and resolved.

PiperOrigin-RevId: 456765512

PiperOrigin-RevId: 456753343

This change is just renaming. There is no functional change intended.
The FrameProcessor interface will be created in a follow-up.

PiperOrigin-RevId: 456741628

PiperOrigin-RevId: 456728032

`TextRenderer` is updated to output `CueGroup`, which contains the presentation time of the cues, in microseconds.

PiperOrigin-RevId: 456531399

After this change GlEffects can use any GlTextureProcessor not just
SingleFrameGlTextureProcessor.
MediaPipeProcessor now implements GlTextureProcessor directly which
allows it to reuse MediaPipe's output texture for its output texture
and avoids an extra copy shader step.

PiperOrigin-RevId: 456530718

After this change, FrameProcessorChain chains any GlTextureProcessors
instead of only SingleFrameGlTextureProcessors.

The GlTextureProcessors are chained in a bidirectional manner using
ChainingGlTextureProcessorListener to feed input and output related
events forward and release events backwards.

PiperOrigin-RevId: 456478414