- 18 Apr, 2023 10 commits
-
-
`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 (cherry picked from commit 2f7ba44e)
ibaker committed -
When MediaCodecRenderer is given an empty sample stream, it puts its output format change tracking in a bad state where we never process future stream changes because we are waiting for a sample that doesn't exist. We can fix this by: - Looping the pending output stream changes to see if we processed more than one change at once (this fixes the tracking for empty sample streams that are not the first in the queue). - Checking if none of the previous streams queued any samples in onStreamChanged to handle this in the same way as the case where we already output all samples (this fixes the problem when the empty sample stream comes first in the queue). - Also calling onProcessedStreamChange for the case above, which was missing previously. #minor-release PiperOrigin-RevId: 519226637 (cherry picked from commit 652546c7)
tonihei committed -
PiperOrigin-RevId: 518953648 (cherry picked from commit e8117496)
Tianyi Feng committed -
If RTSP Setup Request with UDP receives HTTP Error Status 461 UnsupportedTransport, then client will retry with TCP. Issue: google/ExoPlayer#11069 PiperOrigin-RevId: 518807829 (cherry picked from commit bbd45c8e)
michaelkatz committed -
PiperOrigin-RevId: 517128752 (cherry picked from commit d88dd74b)
Rohit Singh committed -
PiperOrigin-RevId: 517067549 (cherry picked from commit eb6fc93b)
Rohit Singh committed -
The `@CallSuper` annotation should help catch cases where subclasses are calling `delegate.addListener` instead of `super.addListener` but it will also (unintentionally) prevent subclasses from either completely no-opping the listener registration, or implementing it themselves in a very custom way. I think that's probably OK, since these cases are probably unusual, and they should be able to suppress the warning/error. Issue: androidx/media#258 #minor-release PiperOrigin-RevId: 513848402 (cherry picked from commit af45bedf)
ibaker committed
- 05 Apr, 2023 1 commit
-
- 22 Mar, 2023 1 commit
-
-
r2.18.5
tonihei committed
-
- 14 Mar, 2023 9 commits
-
-
- The ExoPlayer docs will link to the media3 ones (for now, we can permanently redirect once no further stand-alone ExoPlayer release is published). - Contibuting issues and PRs should only happen on the media3 repo. - The media3 README is updated to remove any pre-release status information. PiperOrigin-RevId: 516234594 (cherry picked from commit 8a9c51a8)
tonihei committed -
Andrew Lewis committed
-
Andrew Lewis committed
- 03 Mar, 2023 1 commit
-
-
r2.18.4
tonihei committed
-
- 02 Mar, 2023 12 commits
-
-
Add some additional information which methods to override for available commands. #minor-release PiperOrigin-RevId: 513251805 (cherry picked from commit a64a9e67)
christosts committed -
#minor-release PiperOrigin-RevId: 512897269 (cherry picked from commit 48047cf9)
christosts committed -
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 4cf7d3c7)
tonihei committed -
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: google/ExoPlayer#10882 PiperOrigin-RevId: 512658918 (cherry picked from commit d3639771)tonihei committed
- 28 Feb, 2023 6 commits
-
-
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: google/ExoPlayer#8594 #minor-release PiperOrigin-RevId: 512586838 (cherry picked from commit a02c8d85)tonihei committed -
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 39935d7f)
tonihei committed -
This test became flaky after https://github.com/google/ExoPlayer/commit/cbb6878f9fef20ea440c6ffda77dd4edc00ce1f2 because some of the unrealistic frame times ended up on the same release time. Using realistic numbers avoids the flakiness. PiperOrigin-RevId: 512566469 (cherry picked from commit 13700e0a)
tonihei committed -
PiperOrigin-RevId: 512002735 (cherry picked from commit 1ef70cd6)
andrewlewis committed
-
