SDK / exoplayer

PiperOrigin-RevId: 522347729

There is a race with the ad period preparation having completed
and `onDownstreamFormatChanged` being called when a live stream
is joined in an ad period. In this case the stream event metadata
of the period is immediately emitted and causing an ad media period
being created that is selected in `getMediaPeriodForEvent` before
being prepared (1 out of 4).

Using an `isPrepared` flag makes sure we don't hand out the media
period to early in `getMediaPeriodForEvent`.

PiperOrigin-RevId: 522340046

To set the chroma format and depth information for H265 format,the csd-0 data
needs to be parsed. The previous implementation skipped parsing
csd-0 data and hard coded values based on "profile" field in MediaFormat.

Along with above mention changes, corrected some of the comments
as per spec.

PiperOrigin-RevId: 522335595

This change improves `ImaUtil.maybeCorrectPreviouslyUnknownAdDuration` to
handles the case when the timeline moves forward more than a single period
while an ad group with unknown period duration is being played.

PiperOrigin-RevId: 522292612

PiperOrigin-RevId: 522058915

PiperOrigin-RevId: 522046876

`sed` has a different in-place command line syntax in FreeBsd
than GNU tools. This change makes the `sed` commands work with
FreeBSD `sed` on OSX in bash and zsh shells.

Issue: androidx/media#217
PiperOrigin-RevId: 522043938

PiperOrigin-RevId: 522039856

PiperOrigin-RevId: 522010318

NPE in toneMap_hlgFrame_matchesGoldenFile and toneMap_pqFrame_matchesGoldenFile was created because a uEnableColorTransfer uniform was being created on the HDR path, when HDR shader files don't have this uniform. (they don't support disable color transfers right now)

Fix: only create the uniform when input is SDR.

manually tested on failing tests

PiperOrigin-RevId: 522002603

PiperOrigin-RevId: 521805477

PiperOrigin-RevId: 521790733

Need to use NAL unit util methods in muxer module.

PiperOrigin-RevId: 521772831

This ensures that anybody implementing `Player` (which is relatively
unusual) must override at least one `@UnstableApi` method, and therefore
opt-in to the unstable API.

PiperOrigin-RevId: 521769675

PiperOrigin-RevId: 521731485

PiperOrigin-RevId: 521476767

* Add a new event `onAudioCapabilitiesChanged` in `AudioSink.Listener` interface.
* Add an interface `RendererCapabilities.Listener`, which will listen to `onRendererCapabilitiesChanged` events from the renderer.
* Add `getRendererCapabilitiesReceiver` method for `TrackSelector`, and register/unregister the `TrackSelector` as the `RendererCapabilitiesReceiver` (if implemented) when the `ExoPlayer` is initialized/released.
* Trigger the `AudioSink.Listener.onAudioCapabilitiesChanged` and further `RendererCapabilities.Listener.onRendererCapabilitiesChanged` events when the audio capabilities changes are detected in `DefaultAudioSink`.

PiperOrigin-RevId: 521427567

PiperOrigin-RevId: 521427239

This was broken and has been fixed in <unknown commit>.

PiperOrigin-RevId: 521380415

This includes:

- Add an ad for each LOADED event of the SDK by taking the duration
  of the ad from the media structure to exactly match the start position
  of ads and then use `addLiveAdBreak()` that is used for HLS live already.
- When the refreshed content timeline arrives, possibly correct
  the duration of an ad that has been inserted while the period duration was
  still unknown (last period of the live timeline).
- When an ad period is removed the ad group needs to be put into a condition
  that allows continuing playback.

PiperOrigin-RevId: 520919236

Handling of the stream offset and start position was unnecessarily
complex and even incorrect. It was going to be an issue for
concatenation of video and image input.

The stream offset is the offset added before decoding/encoding to
make sure it doesn’t fail in case of negative timestamps (which do
rarely occur).
The start position is equal to the stream offset, plus the clipping
start time if the media is clipped.

Before this change:
- Samples were offset by the start position before decoding, and this
offset was removed before muxing.
- The startPosition of the first MediaItem in a sequence was used for
all the MediaItems in this sequence (which is incorrect).
- The stream offset was removed before applying the GL effects and
added back before encoding so that it was not visible to the OpenGL
processing.

After this change:
- The start position is subtracted in the AssetLoader, so that the
downstream components don’t have to deal with the stream offsets and
start positions.
- Decoded samples with negative timestamps are not passed to the
SamplePipelines. The MediaMuxer doesn’t handle negative timestamps
well. If a stream is 10 secondes long and starts at timestamp -2
seconds, the output will only contain the samples corresponding to the
first 8 (10 - 2) seconds. It won’t contain the last 2 seconds of the
stream. It seems acceptable to remove the first 2 seconds instead.

PiperOrigin-RevId: 520916464

PiperOrigin-RevId: 520886975

Releasing the player once a sequence has ended seems to make our
emulator tests flaky. Comment out until we find the cause. The player
will still be released from TransformerInternal, when the export ends.

PiperOrigin-RevId: 520886181

Issue: google/ExoPlayer#11008
PiperOrigin-RevId: 520864579

The `DashMediaSource` wrongly added an offset to the media times set
to the `MediaLoadData`. With this the `startTimeMS` and `endTimeMs`
don't represent the positions in the period but in the stream.

`DashMediaSource` was the only call site that was setting the offset
to a non-zero value. So if we are using 0 for the `DashMediaSource`
as well, the offset is redundant and we can remove it everywhere.

PiperOrigin-RevId: 520682026

PiperOrigin-RevId: 520663415

The media3-hosted versions of these SVGs were removed due to a change in
the way the reference docs are generated. While work on getting them
hosted on developer.android.com, this change simply links to the
(identical) exoplayer2 versions in order to fix the media3 docs.

#minor-release

PiperOrigin-RevId: 520647905

*** Original commit ***

Rollback of https://github.com/google/ExoPlayer/commit/927105ed0dc6c811a1057db4b664003cf753ac12

*** Original commit ***

Intercept audio capabilities change in `DefaultAudioSink`

***

***

PiperOrigin-RevId: 520619600

RawCC is a Google-internal subtitle format that is no longer directly
supported by this library (since https://github.com/google/ExoPlayer/commit/4f616d60034e13e2236f321cbb3187ac92a2709d).

PiperOrigin-RevId: 520591591

This method has been deprecated for over 2 years.

PiperOrigin-RevId: 520586238

This means we don't need to manually store the result of `get()` into a
local to convince the nullness checker that it remains non-null.

PiperOrigin-RevId: 520576719

For multi-period live streams the content timeline for
which the global ad playback state has been split needs
to be kept together to not run into a race between
timeline refreshes and ad events.

PiperOrigin-RevId: 520358964

And some further remaining usages of "master" in the HLS module.
These usages are all package-private.

PiperOrigin-RevId: 520334163

In multi-period live streams, we can't use the content timeline if we want to
lookup a period from the public timeline by index or uid because it may be
that the content timeline has already been refreshed in the
`ImaServerSideAdInsertionMediaSource` but hasn't yet arrived in `ExoPlayerImpl`.

This change is taking the current position that needs to be reported
to the SDK every 200ms is not relying on the content timeline.

PiperOrigin-RevId: 520328126

By having a single base class for GL shader programs we simplify the customization
of new shader programs. The concrete cases include

- Allow frame dropping in shader program
- Creating a FrameCache that selectively (based on timestamp) replays and clears
  the cached content

PiperOrigin-RevId: 520322060

PiperOrigin-RevId: 520314781

`DefaultDrmSession(Manager)` expect most of their methods to be called
on the 'playback thread'. There isn't a playback thread in the case of
`OfflineLicenseHelper`, but in that case it's the thread backing
`DefaultDrmSessionManager.playbackLooper`, which is `OfflineLicenseHelper.handlerThread`.

PiperOrigin-RevId: 520053006

PiperOrigin-RevId: 520037412

*** Original commit ***

Rollback of https://github.com/google/ExoPlayer/commit/782f19edcf9dcc4ecf47dc32776429990c4a928f

*** Original commit ***

Release SequenceAssetLoader when ended

Before, the SequenceAssetLoader was released at the end of the export.
Release resources earlier if possible.

***

***

PiperOrigin-RevId: 520036433

PiperOrigin-RevId: 520027236