Updated `ExoTrackSelection` to provide the most recent bitrate estimate, enabling the inclusion of measured throughput (mtp) as a CMCD-Request field in Common Media Client Data (CMCD) logging.
Additionally, made changes to the `checkArgument` methods in `CmcdLog` to prevent the use of default values in certain cases.
PiperOrigin-RevId: 549369529
(cherry picked from commit cdb174c91a0a9e5387f9773ac24f015199a7999e)
Added these CMCD-Object fields to Common Media Client Data (CMCD) logging.
PiperOrigin-RevId: 548950296
(cherry picked from commit 1b2a2fcde00c5bd05573e777c4e8a2bf60db7137)
The streams return end-of-input if they read no samples, but know that
they are fully buffered to at least the clipped end time. This helps to
detect the end of stream even if there are no new buffers after the end
of the clip (e.g. for sparse metadata tracks).
The race condition occurs because the buffered position is evaluated
after reading the sample. So between reading "no sample" and checking
the buffered position, the source may have loaded arbitrary amounts
of data. This may lead to a situation where the source has not read
all samples, reads NOTHING_READ (because the queue is empty) and then
immediately returns end-of-stream (because the buffered position
jumped forward), causing all remaining samples in the stream to be
skipped. This can fixed by moving the buffered position check to
before reading the sample, so that it never exceeds the buffered
position at the time of reading "no sample".
#minor-release
PiperOrigin-RevId: 548646464
(cherry picked from commit c64d9fd6da90497547daf3deea536af2007784a5)
Add Ogg ID Header and Comment Header Pages to the Ogg encapsulated Opus for offload playback. This further matches the RFC 7845 spec and provides initialization data to decoders.
PiperOrigin-RevId: 548080222
(cherry picked from commit 847f6f24d3770b6134a233b62a5fa9413c9bd26c)
Added these CMCD-Session fields to Common Media Client Data (CMCD) logging.
PiperOrigin-RevId: 547435498
(cherry picked from commit 0412a36564a09c0a237b91b4a78fed80336ea6b6)
This change also marks the buttons of the custom layout as
enabled/disabled according to available commands in the controller.
Accordingly, `CommandButton.Builder.setEnabled(boolean)` is deprecated
because the value is overridden by the library.
Issue: androidx/media#38
PiperOrigin-RevId: 547272588
(cherry picked from commit ea21d27a6974822a970261f38964ec86c305796b)
Also update type names to match the current names for these types.
PiperOrigin-RevId: 546884049
(cherry picked from commit eed0e42ff805f54161125bbb6983f30ba0d39e8a)
This is only needed for instrumentation tests and should not
be included in regular builds.
Issue: androidx/media#499
PiperOrigin-RevId: 545913113
(cherry picked from commit 2250ffe6c8c5fa6b5bc728cd7a9fa075bcbb04d9)
Based on the spec, ETSI TS 102 366 V1.4.1 Annex F, 6 bits should have skipped instead of 6 bytes.
This correction was pointed out in Issue: androidx/media#474.
PiperOrigin-RevId: 545658365
(cherry picked from commit 07d4e5986b06ef6e362fe00fb97187469f42bc25)
This was helpful in investigating Issue: androidx/media#471
PiperOrigin-RevId: 545393217
(cherry picked from commit 3456382ae7116a8bb57b4212f449dfb50ea490d9)
We introduced truncation to 32 chars in <unknown commit>
and included indent and offset in the calculation. I think this is
technically correct, but it causes problems with the content in
Issue: google/ExoPlayer#11019 and it doesn't seem a problem to only truncate actual
cue text (i.e. ignore offset and indent).
PiperOrigin-RevId: 544677965
(cherry picked from commit e8fdd83558dcb0a4f886c52c8b32e2c1f3637a48)
These fields cannot be set and the logic to handle them can be removed.
PiperOrigin-RevId: 544646460
(cherry picked from commit 2f113c8b8234ca80fd0968f845dd195fcf956c6d)
Add a fail-fast check in `ExoPlayerImpl` to ensure the equality of the lengths of `ShuffleOrder` and the current playlist. Also improve the documentation of `setShuffleOrder(ShuffleOrder)` with explicit instruction on this.
Issue: androidx/media#480
#minor-release
PiperOrigin-RevId: 544009359
(cherry picked from commit d895a46b280f1f9764f63a5fc1ba16ab2727191e)
It currently wrongly documents that it is only called before reading
streams (that has never been the case and all MediaPeriods already need
to handle calls after reading samples from the streams).
It was also a bit unclear what a discontinuity implies and the new
Javadoc calls out the main use case for discontinuties and the intended
meaning of returning a discontinuity.
#minor-release
PiperOrigin-RevId: 543989124
(cherry picked from commit b324b8aa72db8853cf28429fa6462acdbf769f21)
MP4 edit lists sometimes ask to start playback between two samples.
If this happens, we currently change the timestamp of the first
sample to zero to trim it (e.g. to display the first frame for a
slightly shorter period of time). However, we can't do this to audio
samples are they have an inherent duration and trimming them this
way is not possible.
PiperOrigin-RevId: 543420218
(cherry picked from commit 232246240415443ff8d3a8cd5930273b4085ddaa)
`MediaControllerImplBase` has 2 methods for updating listeners about `PlayerInfo` changes - `updatePlayerInfo` (for masking the state) and `onPlayerInfoChanged` (when communicating with the session). There is a set number of listener callbacks related to `PlayerInfo` updates and both methods should go through the same control flow (whether we know that masking will ignore most of them or not).
A unified method `notifyPlayerInfoListenersWithReasons` encapsulates only the shared logic of 2 methods - listeners' callbacks. This ensures that both methods call them in the same order and none are missed out.
PiperOrigin-RevId: 542587879
(cherry picked from commit c2d80516628e4f62a4ec88ae1240002e6cc85aef)
The callbacks for `PlayerInfo` changes are currently in both `MediaControllerImplBase.updatePlayerInfo` (masking) and `MediaControllerImplBase.onPlayerInfoChanged`. But the order was different between them both and `ExoPlayerImpl.updatePlaybackInfo` which they are trying to mimic.
#minor-release
PiperOrigin-RevId: 542519070
(cherry picked from commit b8ac5b42107b7d291162558378c2482bb84576f0)
When an app tried to re-prepare a live streeam with server side inserted
ad after a playback exception, the player tried to find the ad group by
its index in the ad playback state of the next timeline when creating
the first period.
If a source that supports server side ad, has removed the ad playback
state when the source has been removed, this causes a crash. For live
streams this is a reasonable thing to do given the exception could be
caused by an invalid ad playback state.
This change removes the ad metadata from the current period for live
streams and the timeline. In case the ad playback state is not reset
by the source, the first timeline refresh would ad the metadata again.
PiperOrigin-RevId: 541959628
(cherry picked from commit 4604f0cde691311d8a1104d66e6eb724766ce4b0)
Some events may arrive after the playlist is cleared (e.g. load
cancellation). In this case, the DefaultPlaybackSessionManager may
create a new session for the already removed item.
We already have checks in place that ignore events with old
windowSequenceNumbers, but these checks only work if the current
session is set (i.e. the playlist is non-empty). The fix is to add
the same check for empty playlists by keeping note of the last
removed window sequence number.
PiperOrigin-RevId: 541870812
(cherry picked from commit e0191ddded1754cc31b025493970240aeb08a46e)
Instead of providing `playbackDurationUs` and `loadPositionUs` individually, which are used to calculate the buffer duration for CMCD logging, we can directly pass the pre-calculated `bufferedDurationUs` available in the `getNextChunk` method of the chunk source classes.
Issue: google/ExoPlayer#8699
#minor-release
PiperOrigin-RevId: 540630112
(cherry picked from commit be9b057dda1a6a2da0e57b3b6f3620b371b7fd6e)
Additionally, two existing methods to `buildDataSpec` in `DashUtil` have been deprecated, while a new method has been added that allows the inclusion of `httpRequestHeaders`.
Issue: google/ExoPlayer#8699
#minor-release
PiperOrigin-RevId: 540594444
(cherry picked from commit 52878b2aca599d7aee3d87d76d602e81b1946d00)
Current behaviour causes an app to crash if it receives an unrecognized repeat mode send over the wire. In order to avoid the crash, a sensible default had to be chosen.
For `Player.RepeatMode`, it is `Player.REPEAT_MODE_OFF`, which is the same value we use as default when unbundling `PlayerInfo`.
For `PlaybackStateCompat.RepeatMode`, it is `PlaybackStateCompat.REPEAT_MODE_NONE`, which is what we use in the no-arg `LegacyPlayerInfo` constructor.
Issue: androidx/media#448
#minor-release
PiperOrigin-RevId: 540563792
(cherry picked from commit 501da109ced14c498eeafcd62d1fbe12e6ecc76e)
These comments reflect the parameter names of the constructor that
we're reflectively calling, but errorprone complains that they don't
match the parameter names of `Constructor.newInstance`.
PiperOrigin-RevId: 540348118
(cherry picked from commit 567890da9ed473b32b6e23c2b499e1e40d835487)
Previously `AsynchronousMediaCodecCallback.mediaCodecException` was
cleared when flushing completed. This behaviour was changed in
aeff51c507
so now the exception is not cleared.
The result after that commit was that we would **only** suppress/ignore
the expression if a flush was currently pending, and we would throw it
both before and after the flush. This doesn't really make sense, so this
commit changes the behaviour to also throw the exception during the
flush.
This commit also corrects the assertion in
`flush_withPendingError_resetsError` and deflakes it so that it
consistently passes. The previous version of this test, although the
assertion was incorrect, would often pass because the
`dequeueInputBuffer` call would happen while the `flush` was still
pending, so the exception was suppressed.
#minor-release
PiperOrigin-RevId: 540237228
(cherry picked from commit 248d1d99ecd1f3d57b1acc1cdc6f160b3b8aa495)
Currently, the implementation of `MediaControllerImplBase` differs from `ExoPlayerImpl`. The listeners of the former are notified of player error changes only in `onPlayerInfoChanged` and not `updatePlayerInfo` (masking method). Whereas `ExoPlayerImpl` has one unified method - `updatePlaybackInfo` - which sends the events to all the available listeners.
This change fixes the lack of 2 particular callbacks - `onPlayerErrorChanged` and `onPlayerError`, however, there might be more differences. Ideally, there should be a unified method for oldPlayerInfo/newPlayerInfo comparison-update-notify-listeners flow.
Issue: androidx/media#449
#minor-release
PiperOrigin-RevId: 539961618
(cherry picked from commit 4b5a4577905d86ec6e24a92a088a65689c7be901)
1. Not treating 0 as valid buffer index
2. Not handling the case the last frame is a comparison frame
PiperOrigin-RevId: 539607482
(cherry picked from commit 4b1ac2f17229a31754440693dc06ef583752070a)
This flag was introduced to fix links in javadoc search when generating
it with Java 11: <unknown commit>
The flag is no longer supported with Java 17 (which is required for
Gradle 8.0+), and seems to no longer be needed: I generated the javadoc
with it removed and the search links work OK.
PiperOrigin-RevId: 536738686
