1.4.0 #6
Merged
1.4.0 #6
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This annotation is only needed on public classes that are part of a distributed library. Switch to `@OptIn` for the one file where `@UnstableApi` was suppressing lint errors. PiperOrigin-RevId: 633858516
This annotation is only needed on public classes. This change also removes the `/* package */` comment from some `public` classes. PiperOrigin-RevId: 633864544
Also make one class truly package-private and keep the comment instead. This comment should only appear on elements with default (package-private) visibility. PiperOrigin-RevId: 633911914
PiperOrigin-RevId: 633912487
PiperOrigin-RevId: 633917110
The test currently resets the time too far in the past and then has to run through ~30000 additional iterations of doSomeWork to reach the end, sometimes triggering the test timeout. Fix it by resetting the time to the intended start position when transitioning items. PiperOrigin-RevId: 633918706
https://developer.android.com/media/platform/supported-formats#image-formats was updated to include AVIF support in API 34+, so <unknown commit> updated our associated Util's to reflect this. After that change, ExoPlayer's BitmapFactoryImageDecoder will be able to decode AVIF, but the player won't be able to detect or extract it. Add this support for completeness, so that ExoPlayer can continue to say it supports all formats in https://developer.android.com/media/platform/supported-formats#image-formats. PiperOrigin-RevId: 633956245
PiperOrigin-RevId: 633973723
To override this change, and go back to parsing during rendering, apps must make two method calls: 1. `MediaSource.Factory.experimentalParseSubtitlesDuringExtraction(false)` 2. `TextRenderer.experimentalSetLegacyDecodingEnabled(true)` PiperOrigin-RevId: 634262798
Fix "subtitles rendered with border and no fill color" problem: moneytoo/Player#413 because '0' means it's an index to the palette table, not an RGBA value of 0
PiperOrigin-RevId: 634289663
ExoPlayer sometimes calls AudioSink.playToEndOfStream before configuring the sink. Before this CL, the composition player was failing if this happened. PiperOrigin-RevId: 634306592
PiperOrigin-RevId: 634345071
Also Use `Iterables.toArray()` to void the confusing `List.toArray()` method call PiperOrigin-RevId: 634351844
PiperOrigin-RevId: 634409758
This was accidentally introduced in 4fde35c PiperOrigin-RevId: 634465380
PiperOrigin-RevId: 634474584
PiperOrigin-RevId: 634495944
Before this change, if a playback error is thrown the test fails with a timeout and no additional info: ``` java.util.concurrent.TimeoutException at androidx.media3.exoplayer.e2etest.WebvttPlaybackTest.stallPlayerUntilCondition(WebvttPlaybackTest.java:361) ``` After this change, the test failure includes a much more useful stack trace, e.g. from 0352db9: ``` Caused by: java.lang.IllegalStateException: Legacy decoding is disabled, can't handle text/vtt samples (expected application/x-media3-cues). at androidx.media3.common.util.Assertions.checkState(Assertions.java:100) at androidx.media3.exoplayer.text.TextRenderer.assertLegacyDecodingEnabledIfRequired(TextRenderer.java:587) at androidx.media3.exoplayer.text.TextRenderer.onStreamChanged(TextRenderer.java:210) ``` PiperOrigin-RevId: 634672138
The method is only allowed to be called on prepared items. This check was currently missing and also causing the corresponding test to be flaky in ExoPlayerTest. PiperOrigin-RevId: 634694077
The two affected tests where playing until a specific position to enable the player to read ahead. The method pauses at exactly the target position, but then has temporarily undetermined behavior because the playback thread uses player.getClock().onThreadBlocked() that lets the playback thread make progress in parallel to the test thread. The tests were flaky because they sometimes made so much progress that they ended playback before we could query the updated renderer state. This can be fixed by using run(player).untilBackgroundThreadCondition instead, which is guaranteed to be fully deterministic, but may not be able to stop at exactly the desired position (which we don't really need anyway for this test). PiperOrigin-RevId: 634699752
For each item, AudioGraphInput now pads the input audio track with silence to the duration given in onMediaItemChanged. Possibly resolves Issue: #921 . PiperOrigin-RevId: 634753721
PiperOrigin-RevId: 634817614
This case is most likely to happen when re-preparing a multi-period live stream after an error. The live timeline can easily move on to new periods in the meantime, creating this type of update. The behavior before this change has two bugs: - The player resolves the new start position to a subsequent period that existed in the old timeline, or ends playback if that cannot be found. The more useful behavior is to restart playback in the same live item if it still exists. - MaskingMediaSource creates a pending MaskingMediaPeriod using the old timeline and then attempts to create the real period from the updated source. This fails because MediaSource.createPeriod is called with a periodUid that does no longer exist at this point. We already have logic to not override the start position and need to extend this to also not prepare the real source. Issue: #1329 PiperOrigin-RevId: 634833030
This should be no-op overall and helps to disentangle the clock sync update from the state of the manifest. We currently check oldPeriodCount==0 to trigger the clock sync load, which only works because the manifest happens to be null whenever we need a new clock sync. We can decouple these concepts by directly checking whether we have an existing elapsedRealtimeOffsetMs. This also requires to set this value explicitly at the point where we consider it set to the local device clock fallback when the timing element load fails. PiperOrigin-RevId: 634844921
This is a fix for the fix in 319854d. The original fix did not reset the firstPeriodId to avoid any id clashes with future updates. This however only works under the assumption that the next manifest load at the next call to prepare() is exactly the same as the current manifest. This is not true unless the call happens very quickly (and may fail even then). Instead we should keep the existing manifest directly as a reference so we can use it to find the number of removed periods when we get a new manifest at the next call to prepare(). Issue: #1329 PiperOrigin-RevId: 634853524
Queue image again after position reset, and reset timestamp iterator. PiperOrigin-RevId: 635049953
This class is a lower-level UI component that isn't directly needed if apps are using `PlayerView` to handle their video output (it is used as an implementation detail of `PlayerView`). Removing its unecessary usages from this demo avoids developers copying this as an example when building their own apps. #cherrypick PiperOrigin-RevId: 644972454 (cherry picked from commit cb8f87e)
Previously we assumed that `surfaceSyncGroupV34` was always non-null on API 34, but this isn't true in edit mode. Instead we add an explicit null-check before accessing it. We don't need to null-check it at the other usage site because we are already null-checking `surfaceView` (via `instanceof` check). Issue: #1237 #cherrypick PiperOrigin-RevId: 645008049 (cherry picked from commit 9980306)
HttpEngineDataSource is the recommended HttpDataSource when it is available. It uses the [HttpEngine](https://developer.android.com/reference/android/net/http/HttpEngine). #cherrypick PiperOrigin-RevId: 646051562 (cherry picked from commit e591c37)
The test is flaky because the decoding process in the renderer depends on some timing from MediaCodec beyond our control and the new keyframe added in the test is sometimes 'dropped' when it arrives too late. We can fix this by controlling the test progress a bit more tightly: first rendering with the same current time until the key frame is processed and then start increasing the time until we've reached the end. #cherrypick PiperOrigin-RevId: 646064352 (cherry picked from commit ada4dc9)
HttpEngine does not support cookie storage. #cherrypick PiperOrigin-RevId: 646084702 (cherry picked from commit bb568b5)
The two arrays need to have the same length and the selection must match in their nullness (unless for TYPE_NONE renderers). Clarify this more clearly in the docs and add new asssertions for it. This avoids that the player is failing in obscure ways much later. Issue: #1473 #cherrypick PiperOrigin-RevId: 646086833 (cherry picked from commit 71ef848)
PiperOrigin-RevId: 646121082 (cherry picked from commit b026271)
PiperOrigin-RevId: 646402268 (cherry picked from commit 0466728)
Extractors should not report additional tracks once they called ExtractorOutput.endTracks. This causes thread safety issues in ProgressiveMediaPeriod where the array of sample queues is extended while the playback thread accesses the arrays. Detecting this problem early is beneficial to avoid unexplained exceptions later one. In most cases where this may happen (namely TS extractors finding new tracks), it's better to ignore the new tracks instead of failing completely. So this change adds a warning log message and assigns a placeholder output. Note: The same workaround already exists in HlsSampleStreamWrapper and MediaExtractorCompat. Issue: #1476 #cherrypick PiperOrigin-RevId: 646427213 (cherry picked from commit 18e631f)
#cherrypick PiperOrigin-RevId: 646434450 (cherry picked from commit 867410f)
ExoPlayer used to call `stop()` before `release()`. This was removed in <unknown commit>. A framework bug introduced in Android 11 (API 30) resulted in some DRM -> clear transitions failing during `MediaCodec.configure()`. An investigation in Issue: google/ExoPlayer#8696 and b/191966399 identified that this was due to `release()` returning 'too early' and the subsequent `configure()` call was then trying to re-use a `Surface` that hadn't been fully detached from the previous codec. This was fixed in Android 13 (API 33) with http://r.android.com/2094347. ExoPlayer worked around the framework bug by adding an arbitrary 50ms sleep after a failed codec initialization, followed by retrying. This was enough to resolve the problem in the test scenario on a OnePlus AC2003. Issue: #1497 points out that 50ms might not be the appropriate delay for all devices, so it's an incomplete fix. They suggested re-adding the `MediaCodec.stop()` call instead. This also reliably resolves the issue on the OnePlus AC2003 (with neither workaround in place, the problem repros almost immediately). PiperOrigin-RevId: 646461943 (cherry picked from commit 5fcc743)
Setting a `null` value doesn't remove the key as expected per the `MediaFormat` API documentation, using the `removeKey` method instead which is only available starting API level 29. PiperOrigin-RevId: 646462402 (cherry picked from commit 12c4258)
PiperOrigin-RevId: 646917527 (cherry picked from commit 6244d86)
When handling a playback error that originates from a future item in the playlist, we added support for jumping to that item first, ensuring the errors 'happen' for the right 'current item'. See 79b688e. However, when we add this new position discontinuity to the playback state, there may already be other position discontinuities pending from other parts of the code that executed before the error. As we can't control that in this case (because it's part of a generic try/catch block), we need to send any pending updates first before handling the new change. Issue: #1483 PiperOrigin-RevId: 646968309 (cherry picked from commit 7276451)
Upon track transition of offloaded playback of gapless tracks, the framework will reset the audiotrack frame position. The `AudioTrackPositionTracker`'s `AudioTimestampPoller` must be made to expect the reset and cache accumulated sum of `AudioTimestamp.framePosition`. #cherrypick PiperOrigin-RevId: 647294360 (cherry picked from commit a58e77a)
PiperOrigin-RevId: 648282532 (cherry picked from commit 16ef63c)
#cherrypick PiperOrigin-RevId: 648385733 (cherry picked from commit 6bf2461)
This change extends the error replication to a given set of error codes (not only authentication error), but only replicates an error if the caller of the service `Callback` is a legacy controller. It also makes error replication configurable so that apps can opt-out and report errors manually instead, or define the error codes for which replication is enabled. The change also removes the restriction of `sendError` only being available for Media3 controllers. Instead, sending an error to a legacy controller updates the platform playback state in the same way as sending the error to the media notification controller. #cherrypick PiperOrigin-RevId: 648399237 (cherry picked from commit 70c0639)
#cherrypick PiperOrigin-RevId: 648641357 (cherry picked from commit 0510370)
PiperOrigin-RevId: 648745388 (cherry picked from commit 9277a34)
#cherrypick PiperOrigin-RevId: 648982615 (cherry picked from commit b531d93)
#cherrypick PiperOrigin-RevId: 653261278 (cherry picked from commit 68e8d9c)
#cherrypick PiperOrigin-RevId: 653640574 (cherry picked from commit 1cbcd20)
PiperOrigin-RevId: 653654999 (cherry picked from commit 3c9332b)
#cherrypick PiperOrigin-RevId: 655558346 (cherry picked from commit d70ff7e)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.