- 02 Mar, 2023 13 commits
-
-
tonihei committed
-
#minor-release PiperOrigin-RevId: 512897269 (cherry picked from commit 42fae152)
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 408b4449)
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 e79b47cc)tonihei committed -
Issue: androidx/media#192 PiperOrigin-RevId: 508649684 (cherry picked from commit e1d12fc3)
tianyifeng committed
- 28 Feb, 2023 20 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 PiperOrigin-RevId: 512586838 (cherry picked from commit 39703438)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 7ffcc6f7)
tonihei committed -
This test became flaky after https://github.com/androidx/media/commit/ab7e84fb34b7ef4b13e492e1f8918345c712ec30 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 0c8ce183)
tonihei committed -
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 f0420124)
tonihei committed -
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 ab7e84fb)
christosts committed -
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 9eccf091)
tonihei committed -
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. Issue: google/ExoPlayer#10971 PiperOrigin-RevId: 509207881 (cherry picked from commit a8c87453)
michaelkatz committed -
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 70643105)
christosts committed -
`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: google/ExoPlayer#10977 PiperOrigin-RevId: 508619169 (cherry picked from commit a6dfcf77)
ibaker committed -
PiperOrigin-RevId: 508323432 (cherry picked from commit 1249dcdc)
christosts committed -
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 01d7bc72)
tonihei committed -
In MediaCodecUtil, use Format.colorInfo, besides the codec string, to accurately map to a 10bit HEVC profile. PiperOrigin-RevId: 507500071 (cherry picked from commit a50ea945)
christosts committed
-
- 16 Feb, 2023 1 commit
-
-
1.0.0 rc01
christosts committed
-
- 14 Feb, 2023 3 commits
-
-
#minor-release PiperOrigin-RevId: 509501665 (cherry picked from commit 20eae0e0)
christosts committed -
PiperOrigin-RevId: 509222489 (cherry picked from commit a90728fd)
christosts committed -
PiperOrigin-RevId: 509218510 (cherry picked from commit 73909222)
christosts committed
-
- 02 Feb, 2023 3 commits
-
-
christosts committed
-
This change includes 3 things: - when the legacy media session is created, FLAG_HANDLES_QUEUE_COMMANDS is advertised if the player has the COMMAND_CHANGE_MEDIA_ITEMS available. - when the player changes its available commands, a new PlaybackStateCompat is sent to the remote media controller to advertise the updated PlyabackStateCompat actions. - when the player changes its available commands, the legacy media session flags are sent accoridingly: FLAG_HANDLES_QUEUE_COMMANDS is set only if the COMMAND_CHANGE_MEDIA_ITEMS is available. #minor-release PiperOrigin-RevId: 506605905 (cherry picked from commit ebe7ece1)
christosts committed
-
