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 3970343846)
Some devices were reported to have wrong PerformancePoint sets
that cause 60 fps to be marked as unsupported even though they
are supported.
Issue: google/ExoPlayer#10898
PiperOrigin-RevId: 512580395
(cherry picked from commit d0cbf0fce8)
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 7ffcc6f7ea)
This test became flaky after ab7e84fb34 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 0c8ce183fe)
Protected system broadcasts should not specify the export flag.
Marking them as NOT_EXPORTED breaks sticky broadcasts in some
cases.
Issue: google/ExoPlayer#10970
PiperOrigin-RevId: 512020154
(cherry picked from commit 93e117928c)
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 f042012495)
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 ab7e84fb34)
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 9eccf09165)
The current javadoc refers to the SessionCallback#onConnected, which doesn't exist.
PiperOrigin-RevId: 510261965
(cherry picked from commit fc642eb45f)
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 a8c87453db)
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 706431059c)
`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 a6dfcf7799)
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 01d7bc7279)
In MediaCodecUtil, use Format.colorInfo, besides the codec string,
to accurately map to a 10bit HEVC profile.
PiperOrigin-RevId: 507500071
(cherry picked from commit a50ea94525)
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 ebe7ece1eb)
Can be used to combine multiple media items into a single timeline window.
Issue: androidx/media#247
Issue: google/ExoPlayer#4868
PiperOrigin-RevId: 506283307
(cherry picked from commit fcd3af6431)
This change fixes an issue that can be reproduced when
a controller `onConnect` creates a `QueueTimeline` out
of the state of a legacy session and then `prepare` is called.
`activeQueueItemId`, `metadata` and the `queue` of the legacy
session are used when a `QueueTimeline` is created. The change
adds unit tests to cover the different combinatoric cases these
properties being set or unset.
PiperOrigin-RevId: 505731288
(cherry picked from commit 4a9cf7d069)
When seeking in fMP4, we try to extract as little samples as possible
by only starting at the preceding sync frame. This comparison should
use <= to allow sync frames at exactly the seek position.
Issue: google/ExoPlayer#10941
PiperOrigin-RevId: 505098172
(cherry picked from commit 00436a04a4)
MergingMediaPeriod creates its track groups with ids concatenating position in its periods array and the underlying child track group id. The ids can be used in selectTracks for matching to periods list.
Issue: google/ExoPlayer#10930
PiperOrigin-RevId: 505074653
(cherry picked from commit 542a1ef03f)
For most missing commands, we already disable the corresponding
controls. This change extends this to more UI elements that are
disabled in case the corresponding action is unavailable.
#minor-release
PiperOrigin-RevId: 505057751
(cherry picked from commit b3e7696ba7)
The commands are partly checked already before enabling
features or calling player methods, but the checks were
still missing in many places.
#minor-release
PiperOrigin-RevId: 504589888
(cherry picked from commit e2ece2f5bc)
These attributes are required when importing our artifacts into
androidx-main in order to generate reference documentation (JavaDoc and
KDoc).
#minor-release
PiperOrigin-RevId: 504502555
(cherry picked from commit 47349b8c4b)
This allows a MediaController to understand which methods calls
are available on a legacy session.
PiperOrigin-RevId: 504306806
(cherry picked from commit 067340cb0a)
ImaUtil calls VideoProgressUpdate.equals() which is annotated as hidden,
which causes lint errors with gradle.
#minor-release
PiperOrigin-RevId: 504306210
(cherry picked from commit 5f6e172c8f)
Created unified MediaUtils method to handle various logic for calling Player.setMediaItems from MediaSessionStub and MediaSessionLegacyStub
PiperOrigin-RevId: 504271877
(cherry picked from commit 7fbdbeb6ca)
Added onSetMediaItems callback listener to allow the session to modify/set MediaItem list, starting index and position before call to Player.setMediaItem(s).
Added conditional check in MediaSessionStub.setMediaItem methods to only call player.setMediaItem rather than setMediaItems if player does not support COMMAND_CHANGE_MEDIA_ITEMS
PiperOrigin-RevId: 503427927
(cherry picked from commit bb11e0286e)
This makes it implicitly clear that if the value of a getter changes due
to a change in command availability then the listener will be invoked,
without needing to explicitly document every command on every listener
method.
#minor-release
PiperOrigin-RevId: 503178383
(cherry picked from commit 280889bc4a)
We stop estimating new position when pausing until we
receive a new position from the player. However, this
means that we will continue to return a possible stale
previous position. Updating the current position before
pausing solves this issue.
PiperOrigin-RevId: 503153982
(cherry picked from commit e961c1b5e9)
We currently only document it for the getCurrentMediaItem(), but
the command was always meant to cover all information about the
current media item and the position therein.
To correctly hide information for controllers, we need to filter
the Timeline when bundling the PlayerInfo class if only this
command is available.
PiperOrigin-RevId: 503098124
(cherry picked from commit f15b752543)
When bundling PlayerInfo, we need to remove information if the
controller is not allowed to access it. This was only partially
done at the moment.
PiperOrigin-RevId: 502852798
(cherry picked from commit 69cfba7c53)