r2.18.4 #11034
Merged
r2.18.4 #11034
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
In MediaCodecUtil, use Format.colorInfo, besides the codec string, to accurately map to a 10bit HEVC profile. PiperOrigin-RevId: 507500071 (cherry picked from commit 80dbaca)
The AudioTrackPositionTracker needs to correct positions by the speed set on the AudioTrack itself whenever it makes estimations based on real-time (=the real-time playout duration is not equal to the media duration played). This happens for the main playback path already, but not for the mode in which the position is estimated from the playback head position and also not in the phase after the track has been stopped. Both cases are not very noticeable during normal playback, but become relevant when playing in offload mode. PiperOrigin-RevId: 507736408 (cherry picked from commit 4ede931)
PiperOrigin-RevId: 507784608 (cherry picked from commit 08342ea)
…in-cached-content-index PiperOrigin-RevId: 508323432 (cherry picked from commit 20a5e46)
PiperOrigin-RevId: 508602059 (cherry picked from commit 1c29131)
`TrackSelectorResult.rendererConfigurations` can contain null elements: > A null entry indicates the corresponding renderer should be disabled. This wasn't caught by the nullness checker because `ExoPlayerImpl` is currently excluded from analysis. #minor-release Issue: #10977 PiperOrigin-RevId: 508619169 (cherry picked from commit 5e3cd7a)
The AsynchronousMediaCodecAdapter's queuing thread stores any exceptions raised by MediaCodec and re-throws them on the next call to queueInputBuffer()/queueSecureInputBuffer(). However, if MediaCodec raises and error while queueing, it goes into a failed state and does not announce available input buffers. If there is no input available input buffer, the MediaCodecRenderer will never call queueInputBuffer()/queueSecureInputBuffer(), hence playback is stalled. This change surfaces the queueing error through the adapter's dequeueing methods. PiperOrigin-RevId: 508637346 (cherry picked from commit a5f4651)
#minor-release PiperOrigin-RevId: 509189206 (cherry picked from commit e98670e)
In parsing Describe RTSP response messages, IllegalArgumentExceptions are thrown for invalid parameters and values. These exceptions were not caught and crashed the Playback thread. Now these exceptions will be caught and their errors forwarded to the proper error handling listeners. #minor-release Issue: #10971 PiperOrigin-RevId: 509207881 (cherry picked from commit 711fa44)
PiperOrigin-RevId: 509473556 (cherry picked from commit 08cf6db)
#minor-release Issue: androidx/media#245 PiperOrigin-RevId: 510456793 (cherry picked from commit a231ff4)
This call may cause performance overhead in some situations, for example if the AudioTrack needs to query an offload DSP for the current position. We don't need to check this multiple times per doSomeWork iteration as the value is unlikely to change in any meaningful way. PiperOrigin-RevId: 510957116 (cherry picked from commit 829b49d)
When rendering frames at a rate higher than the screen refresh rate, e.g. playing at 8x, the player is releasing multiple frames at the same release time (nanos) which are then dropped by the platform. The output buffers are available later and as a result MediaCodec cannot keep up decoding fast enough. This change skips releasing multiple video frames on the same vsync period and proactivelly drops the frame. The frame is counted as skipped rather than dropped to differentiate with frames dropped due to slow decoding. PiperOrigin-RevId: 510964976 (cherry picked from commit cbb6878)
The current logic uses manual array operations to keep track of pending changes. Modernize this code by using an ArrayDeque and a data class. This also allows to extend the output stream information in the future. This also fixes a bug where a position reset accidentally assigns a pending stream offset instead of keeping the current one. PiperOrigin-RevId: 511787571 (cherry picked from commit 4e0babd)
PiperOrigin-RevId: 512002735 (cherry picked from commit 1ef70cd)
The output info for a new stream is marked pending until the last sample of the previous stream has been processed. However, this fails if the previous stream has already been fully processed. We need to detect this case explicitly to avoid signalling the output change one sample too late. #minor-release PiperOrigin-RevId: 512572854 (cherry picked from commit 39935d7)
MediaCodecRenderer currently has two independent paths to trigger
events at stream changes:
1. Detection of the last output buffer of the old stream to trigger
onProcessedStreamChange and setting the new output stream offset.
2. Detection of the first input buffer of the new stream to trigger
onOutputFormatChanged.
Both events are identical for most media. However, there are two
problematic cases:
A. (1) happens after (2). This may happen if the declared media
duration is shorter than the actual last sample timestamp.
B. (2) is too late and there are output samples between (1) and (2).
This can happen if the new media outputs samples with a timestamp
less than the first input timestamp.
This can be made more robust by:
- Keeping a separate formatQueue for each stream to avoid case A.
- Force outputting the first format after a stream change to
avoid case B.
Issue: #8594
#minor-release
PiperOrigin-RevId: 512586838
(cherry picked from commit a02c8d8)
Playback parameter signalling can be quite complex because
(a) the renderer clock often has a delay before it realizes
that it doesn't support a previously set speed and
(b) the speed set on media clock sometimes intentionally
differs from the one surfaced to the user, e.g. during
live speed adjustment or when overriding ad playback
speed to 1.0f.
This change fixes two problems related to this signalling:
1. When resetting the media clock speed at a period transition,
we don't currently tell the renderers that this happened.
2. When a delayed speed change update from the media clock is
pending and the renderer for this media clock is disabled
before the change can be handled, the pending update becomes
stale but it still applied later and overrides any other valid
speed set in the meantime.
Both edge cases are also covered by extended or new player tests.
Issue: #10882
PiperOrigin-RevId: 512658918
(cherry picked from commit d363977)
Once the value returned from AudioTimestampPoller advances, we only need getPlaybackHeadPosition to sample sync params and verify the returned timestamp. Both of these happen less often and we can avoid calling getPlaybackHeadPosition if we don't actually need it. PiperOrigin-RevId: 512882170 (cherry picked from commit 4cf7d3c)
#minor-release PiperOrigin-RevId: 512890813 (cherry picked from commit 13a86b3)
#minor-release PiperOrigin-RevId: 512897269 (cherry picked from commit 48047cf)
These are not supported by Dackka #minor-release PiperOrigin-RevId: 513176533 (cherry picked from commit ef5a1ce)
…ire_file PiperOrigin-RevId: 513213229 (cherry picked from commit d2ba290)
Add some additional information which methods to override for available commands. #minor-release PiperOrigin-RevId: 513251805 (cherry picked from commit a64a9e6)
PiperOrigin-RevId: 513482096 (cherry picked from commit b634005)
#minor-release PiperOrigin-RevId: 513488487 (cherry picked from commit 3b16231)
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.