SDK / exoplayer

The current FLAG_REQUIRE_FORMAT documentation states: If an end of
stream buffer would be read were the flag not set, then behavior is
unchanged.

PiperOrigin-RevId: 380792251

The current FLAG_REQUIRE_FORMAT documentation states: If an end of
stream buffer would be read were the flag not set, then behavior is
unchanged.

PiperOrigin-RevId: 380781976

After this change, multiple BaseURL elements are parsed, but the player still only uses the first BaseURL element appearing in the manifest and its corresponding availabilityTimeOffsetUs.

PiperOrigin-RevId: 380775256

Amend release note for https://github.com/google/ExoPlayer/commit/46bc49a4f6e8194ddb28e7b17eb775157c3e241d.

PiperOrigin-RevId: 380766548

Issue: #9086
#minor-release
PiperOrigin-RevId: 380756562

The problem occurs when the primary media playlist URL switches
from one whose latest snapshot has not yet got the ended tag, to
one whose latest snapshot already has the ended tag. In this case:

- We trigger a redundant load of the ended playlist.
- When the redundant load completes,
  MediaPlaylistBundle.processLoadedPlaylist detects that the
  playlist is unchanged from the one it already has, and so
  doesn't call onPlaylistUpdated.
- PrimaryPlaylistListener.onPrimaryPlaylistRefreshed is never
  called with the new primary. Hence the externally visible primary
  is still the one that hasn't ended. HlsMediaSource therefore thinks
  the event hasn't ended, which in turn prevents the player from
  transitioning to the ended state.

This commit detects when the new primary already has the ended tag.
In this case, we call onPrimaryPlaylistRefreshed directly and remove
the unnecessary playlist load.

Issue: #9067
#minor-release
PiperOrigin-RevId: 380680532

The glitches were introduced in:
https://github.com/google/ExoPlayer/commit/6c31e34528

The problem is that Listener.onEvents is called in a later looper iteration
than the listener methods that were previously used. This created a gap on
the main thread between the UI component dispatching a seek operation to the
player, and onEvents being called to update the progress bar's position.

At the start of this gap the progress bar is rendering the new position,
but its position member variable is still set to the old position. If the
progress bar is re-drawn by another message on the main thread within the
gap, it will briefly show the old position until onEvents is called.

There are multiple possible fixes to this, and the best one is probably to
modify ListenerSet to remove the gap. That's high risk though, so for now we
fix the flicker by always updating the progress immediately after the seek
is dispatched, in addition to when onEvents is called.

Issue: #9049
#minor-release
PiperOrigin-RevId: 380678388

#minor-release

PiperOrigin-RevId: 380655806

Issue: #9061
PiperOrigin-RevId: 380640601

And replace it with factory method which includes more
context for error code assignment.

PiperOrigin-RevId: 380624625

This change parses the entire BaseURL element including DVB extension attributes, stores it in an instance of new BaseUrl class and puts it in a list of base URLs of the resulting Representation. The base url handling itself is still the same, which means that only the first base url is taken into account, just as before this change.

PiperOrigin-RevId: 380609495

This softens the language around suppressing individual test methods.
There are some legitimate cases where this is needed, e.g.
ByteArrayDataSourceContractTest has to suppress all the tests related
to non-existent resources because it's not possible to simulate that
case.

#minor-release

PiperOrigin-RevId: 380570017

Some server will wrongly insert duplicated attributes. We used to treat this as
a unrecoverable error, but it is better to treat the duplicated attributes in
an "over-writable" fashion like HashMaps.

Issue: #9080,
Issue: #9014
PiperOrigin-RevId: 380547079

* Constructors and methods with the same name should appear sequentially with no other code in between, even when modifiers such as static or private differ between the methods. Please re-order or re-name methods.
  (see http://go/bugpattern/UngroupedOverloads) (2 times)

This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Suggest a fix on the CL (go/how-to-suggest-fix).
* 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

PiperOrigin-RevId: 380544425

*** Original commit ***

Target demo apps to API level 30

***

PiperOrigin-RevId: 380542402

#minor-release

PiperOrigin-RevId: 380531272

The test prepare_withSupportedTrack_playsTrackUntilEnded

- sets up the supported AAC track with the RTSP server;
- uses RtpPacketTransmitter to send RTP packets from the server to the client;
- runs the player until the playback has ended, and
- asserts on the data RTSP has received and queued to the SampleQueue.

In the test, it was necessary to create a FakeUdpDataSourceRtpDataChannel. The
reason we cannot reuse TransferRtpDataChannel is, we rely on BlockingQueue.poll
timeout to identify the end of an RTSP stream, but the time out mechanism is
unstable in Robolectric. For example, when the timeout is set to 8,000 ms, the
actual timeout occasionally happens after 2,000,000 ms (in FakeClock).

PiperOrigin-RevId: 380528710

Also change to explicitly track the provisioning session, which makes
the code easier to reason about than always using the zero'th element
of the list.

PiperOrigin-RevId: 380181453

Allows for compatibility with METADATA_KEY_COMPILATION.

PiperOrigin-RevId: 380179505

PiperOrigin-RevId: 380176846

PiperOrigin-RevId: 380174672

Also avoid mentioning that those fields cannot be null, since they are primitives.

PiperOrigin-RevId: 380169988

This is the package that CacheDataSource and CacheDataSourceTest(2) are
in.

PiperOrigin-RevId: 380156879

If google3 is the source-of-truth for this third_party code (or if this is legacy code that is no longer synced with an external source), just LGTM this CL and Rosie will submit it. If not, you should patch the upstream source of these files, since we will be disabling support for /-as-division in google3 before support is formally removed from the language.

See go/lsc-slash-as-division-deprecation.

Tested:
    TAP found no affected targets. No targets were built or tested.
    http://test/OCL:380056637:BASE:380052721:1623976139468:f2fd2cbd
PiperOrigin-RevId: 380140762

In prepare_withSupportedTrack_sendsPlayRequest(), the DESCRIBE includes two
tracks, one AAC and one MP4A-LATM. The test is run until a PLAY is sent, and
asserts on only one SETUP is sent (for AAC).

In prepare_noSupportedTrack_throwsPreparationError(), the DESCRIBE includes one
track: one MP4A-LATM. This format is not supported at the moment, so the player
will throw out an error, on which we assert.
PiperOrigin-RevId: 380131458

PiperOrigin-RevId: 380009757

PiperOrigin-RevId: 380000589

PiperOrigin-RevId: 379962022

In preparation for the onPlayerError callback to take a PlaybackException.

PiperOrigin-RevId: 379939108

PiperOrigin-RevId: 379935363

Issue: #8960

#minor-release

PiperOrigin-RevId: 379922704

#minor-release

PiperOrigin-RevId: 379913814

This enables actions that are not advertised by the MediaSession to be dispatched either way.

PiperOrigin-RevId: 379765015

PiperOrigin-RevId: 379732136

More information: go/checker-3130-lsc

Tested:
    TAP for global presubmit queue passed after automated deflaking of failures: http://mondo/deflaker/run/ff80a4f9-d5d7-47ac-9560-63372e1ff624 http://mondo/deflaker/run/ca3ce61f-2af8-4fa7-b6e4-c98b5c4d950c
    http://test/OCL:379405669:BASE:379421861:1623763190392:bd2d256a
PiperOrigin-RevId: 379623080

More information: go/checker-3130-lsc

Tested:
    Some test failures are present, but the CL author has decided to mail the change anyway
PiperOrigin-RevId: 379622938

Issue: #9004
#minor-release
PiperOrigin-RevId: 379516815

PiperOrigin-RevId: 379506322

Note that this removes a workaround for malformed content, in which the
track_ID is set incorrectly. It's unclear there was sufficient reason to
implement that workaround, and so it's preferable to remove it, rather
than implementing the concept of unrecognized tracks, which would be
needed to keep it and to also fix this issue.

Issue: #9056
#minor-release
PiperOrigin-RevId: 379506261

The Widevine H264 samples in the demo app now log this from the EventLogger:
```
[X] Track:0, id=1, mimeType=video/avc, bitrate=772315, codecs=avc1.42c01e, drm=[widevine,cenc], res=320x142, fps=24.0, supported=YES
```

And the VP9 ones log:
```
[X] Track:0, id=1, mimeType=video/x-vnd.on2.vp9, bitrate=588256, codecs=vp9, drm=[widevine], res=320x142, fps=23.809525, supported=YES
```

#minor-release

PiperOrigin-RevId: 379498332