These are the remaining setter operations. They all share the same
logic that handles playlist and/or position changes. The logic to
create the placeholder state is mostly copied from ExoPlayerImpl's
maskTimelineAndPosition and getPeriodPositonUsAfterTimelineChanged.
PiperOrigin-RevId: 496364712
(cherry picked from commit 09d37641d1ef3b8cf26dc39cfcd317ebe3ef5c79)
Some Player methods operate relative to existing indices in the
playlist (add,remove,move,seek). As these operations may be issued
from a place with a stale playlist (e.g. a controller that sends
a command while the playlist is changing), we have to handle out-
of-bounds indices gracefully. In most cases this is already
documented and implemented correctly. However, some cases are not
documented and the existing player implementations don't handle
these cases consistently (or in some cases not even correctly).
PiperOrigin-RevId: 495856295
(cherry picked from commit a1c0b10482baffc3721561446ee4bb788d8a1231)
The `MediaItem` instances in the following cases are not actually empty but acts as a placeholder. `EMPTY_MEDIA_ITEM` can also be confused with `MediaItem.EMPTY`.
PiperOrigin-RevId: 495843012
(cherry picked from commit 74559b4a188e476378f3f0df908598ce763d909a)
Improves the time taken to construct `playerInfo` from its bundle from ~450 ms to ~400 ms. Each `MediaItem` inside `Timeline.Window` contains `MediaMetadata` and hence is a good candidate for bundling optimisations. There already exists a test to check all parameters for null values when unset.
PiperOrigin-RevId: 495614719
(cherry picked from commit 8dea624c980ff65aece63c6aeecdeef894470231)
This simplifies some position tracking needs for an app implementing
SimpleBasePlayer.
- The period index can always be derived from the media item index
and the position. So there is no need to set it separately.
- The media item index can be left unset in the State in case the app
doesn't care about the value or wants to set it the default start
index (e.g. while the playlist is still empty where UNSET is
different from zero).
- Similarly, we should allow to set the content position (and buffered
position) to C.TIME_UNSET to let the app ignore it or indicate the
default position explictly.
PiperOrigin-RevId: 495352633
(cherry picked from commit 91557ac9d4eaf83e68f563373541dc8e12043e00)
This ensures they are not accidentally triggered again when
the state is rebuilt with a buildUpon method.
PiperOrigin-RevId: 495280711
(cherry picked from commit fa5aaf958d616d831d50fdaceb02d3ff3cbad0fa)
This improves the time taken to construct PlayerInfo from bundle from ~600ms to ~450ms.
PiperOrigin-RevId: 495055355
(cherry picked from commit 7de47fe2a1493da1b0720ddeb357052d2b1dc5bb)
isLoading is not allowed to be true when IDLE, so we have to set to
false when stopping in case it was set to true before.
PiperOrigin-RevId: 494975405
(cherry picked from commit e4f0b73aa325d096b493bd646c63bc6a4bf5880b)
BasePlayer simplifies implementations by handling all the various
seek methods and forwarding to a single method that can then be
implemented by subclasses. However, this loses the information about
the concrete entry point used for seeking, which is relevant when
the subclass wants to verify or filter by Player.Command. This
can be improved by adding the command as a new parameter. Since
we have to change the method anyway, we can also incorporate the
boolean flag about whether the current item is repeated to avoid
the separate method.
PiperOrigin-RevId: 494948094
(cherry picked from commit 6e0f1f10b3666e6c2c74fc5a154dec3f0e03fecb)
Some Player methods like getting the Looper and adding listeners
were always allowed to be called from any thread, but this is
undocumented. This change makes the threading rules of these
methods more explicit.
Removing listeners was never meant to be called from another thread
and we also don't support it safely because final callbacks may
be triggered from the wrong thread. To find potential issues, we
can assert the correct thread when releasing listeners.
Finally, there is a potential race condition when calling addListener
from a different thread at the same time as release, which may lead to
a registered listener that could receive callbacks after the player is
released.
PiperOrigin-RevId: 493843981
(cherry picked from commit e9364b0f6e1a104de9cf4393daab521edc4eccf4)
The folder type has a mix of information about the item. It shows
whether the item is browsable (type != FOLDER_TYPE_NONE) and
which Bluetooth folder type to set for legacy session information.
It's a lot clearer to split this into a boolean isBrowsable and
use the existing mediaType to map back to the bluetooth folder type
where required.
folderType is not marked as deprecated yet as this would be an API
change, which will be done later.
PiperOrigin-RevId: 493544589
(cherry picked from commit 9d059352cff0a75f0f9c4e37010bbfa2fc6079fd)
This adds support for the release handling. To align with the
established behavior in ExoPlayer, the player can only call
listeners from within the release methods (and not afterwards)
and automatically enforces an IDLE state (without listener call)
in case getters of the player are used after release.
PiperOrigin-RevId: 493543958
(cherry picked from commit 3a66c28d4f0fc6bbd7af3f5846a5645aa3ccf778)
In some cases we split a test method, and in other cases we just add
line breaks to make the separation between arrange/act/assert more
clear.
PiperOrigin-RevId: 492182769
(cherry picked from commit 02fa8aa784b518f0ffad5c44da6eec1a94def4ee)
This adds the forwarding logic for most setters in SimpleExoPlayer
in the same style as the existing logic for setPlayWhenReady.
This change doesn't implement the setters for modifying media items,
seeking and releasing yet as they require additional handling that
goes beyond the repeated implementation pattern in this change.
PiperOrigin-RevId: 492124399
(cherry picked from commit e598a17b3628e1179fa4219ca3212407fb3fdeb1)
This helps to denote what type of content or folder the metadata
describes.
PiperOrigin-RevId: 492123690
(cherry picked from commit 1ac72de551a07d37c3b80d96028463244407a5b4)
This better matches the terminology we use elsewhere in the Player
interface, where items inside the playlist are referred to as
"media item" and only the entire list is called "playlist".
PiperOrigin-RevId: 491882849
(cherry picked from commit 6c467590d0fdc27dd5afeefe479c3d4414483de5)
To support OPUS offload, we need to provide a few configuration values
that are currently not set due to the lack of devices supporting
OPUS offload.
PiperOrigin-RevId: 491613716
(cherry picked from commit 4cf877b81428021c4eb2dfa1a743178f280aceb5)
Remove self-links, and remove section that is documenting internal
ordering behaviour of
[`SimpleBasePlayer.getCombinedMediaMetadata`](bb270c62cf/library/common/src/main/java/com/google/android/exoplayer2/SimpleBasePlayer.java (L1770))
rather than anything specifically about this method.
#minor-release
PiperOrigin-RevId: 490923719
(cherry picked from commit ed8c196e2eb36eefef9952d255cb6355807b9e9f)
This change includes a change in the `IMediaController.aidl` file and needs
to provide backwards compatibility for when a client connects that is of an older or
newer version of the current service implementation.
This CL proposes to create a new AIDL method `onPlayerInfoChangedWithExtensions`
that is easier to extend in the future because it does use an `Bundle` rather than
primitives. A `Bundle` can be changed in a backward/forwards compatible way
in case we need further changes.
The compatibility handling is provided in `MediaSessionStub` and `MediaControllerStub`. The approach is not based on specific AIDL/Binder features but implemented fully in application code.
Issue: androidx/media#102
#minor-release
PiperOrigin-RevId: 490483068
(cherry picked from commit f262e9132b32ad89f65853086f30389925b61422)
This adds the full Builders and State representation needed to
implement all Player getter methods and listener invocations.
PiperOrigin-RevId: 489503319
(cherry picked from commit b81cd08271cd94f244ca5d7c995cd29523057a60)
This better matches the callback name (onSurfaceSizeChanged) and
probably cause less confusion with getVideoSize.
PiperOrigin-RevId: 488669786
(cherry picked from commit 8438daca1f8cbea24aa414ee500044baf1a28367)
Util.getAudioTrackChannelConfig() maps a channel count to a
channel mask that is passed to AudioTrack. The method expected that
playback of 8-channel audio is possible from Android 5.1 and playback of
12-channel audio is only possible from Android 12L. However, there is no
restriction on the upper number of channels that can be passed to the
AudioTrack. google/ExoPlayer#10701 is an example where the audio decoder
outputs 12 channels on an Android 10.
This change removes the restrictions for 8 and 12 channels. Note, we still
do not support playback of arbitrary number of channels as it would require
further changes to DefaultAudioSink.
#minor-release
Issue: google/ExoPlayer#10701
PiperOrigin-RevId: 488659831
(cherry picked from commit 1b24e6fd14774d5c8b3e7b8084b30204581d13ce)
When we currently trigger the iteration finished event during the
release, we don't mark the event as triggered. This means that
someone can trigger another release from within the callback,
which then tries to resend the event.
Issue: google/ExoPlayer#10758
#minor-release
PiperOrigin-RevId: 488645089
(cherry picked from commit 3e5103a3e55e2dc545b4a2442beaa49f307ecfdc)
Split inner interface into separate file, which will go in common
module. The old interface will be deprecated and extends the new.
#cleanup
PiperOrigin-RevId: 483732226
(cherry picked from commit ad52b68c738e8321b966b904d3cd2139f7a560ef)
Make it easier to support use of RGBA_101012 rather than RGBA_8888 for EGL
contexts, displays, and surfaces.
This tangentially supports adding HDR tests, by slightly simplifying the color
selection logic we'd have to add in HDR tests.
PiperOrigin-RevId: 482219428
(cherry picked from commit 9e1adee4cbc3386672f42d580734175c442bdbea)
Currently, repeating the same item (via seekNext/Previous) implicitly
results in a seek to the default position of the current item, which
looks exactly the same as a direct seek. As a result, we don't send
onMediaItemTransition as we would for every other seekNext/Previous
call.
This can be fixed by explicitly marking the repeat case in the internal
BasePlayer/ExoPlayerImpl methods, so that the callback can be triggered.
Issue: google/ExoPlayer#10667
PiperOrigin-RevId: 481951788
(cherry picked from commit 76ce0cc69fa12a9b2592103da97dd45c15bfe4d3)
Currently, a frame is dropped if it's requested release time is in the past.
This mode was added to support previewing. However, in normal ExoPlayer
playback, slightly late frames (<30ms late) are also rendered. On MediaCodec
side, this means calling `releaseOutputBuffer` with a release time in the
past.
PiperOrigin-RevId: 479615291
(cherry picked from commit 2188685c465aa6d641e78ab33eaa93fbb92185b8)
Also, update tests to allow AnyOf error codes, and no longer check exception messages, which caused quite a bit of churn.
PiperOrigin-RevId: 479570861
(cherry picked from commit faa796d7365330d1f1d4f5b17901d6b1a78ce868)
This mode is supported by using `C.TIME_UNSET` (which is a negative value). The
new logic decouples the value of `C.TIME_UNSET` and the frame dropping
behaviour.
PiperOrigin-RevId: 479368880
(cherry picked from commit ccab9fba0369ea9709a6987024177e8b73a5c7ac)
The JavaDoc of RequestMetadata should point to the media3 controller,
not the platform one.
PiperOrigin-RevId: 479047924
(cherry picked from commit 088958994776a65666045b3e7b332f5f0c336bcf)
Currently `FrameProcessor.releaseOutputFrame()` method supports
Release at a specific system time
Drops the frame
This API is not that convenient to use when the caller wants to release a frame, now, regardless of the release time. A use case is to release (present) a frame when no frame is shown for a while, and it's thus better to just release the frame, now.
Currently if MCVR wants a frame to be rendered now, MCVR calls release frame with a set offset like 10us: `releaseOutputFrame(System.nanoTime() + 10_000)`. The 10us offset is to prevent the frame processor dropping the frame, due to thread hopping delays.
To make the API better usable, consider adding a mode for releasing the frame now, like (bold marks the new mode)
- Use C.TIME_UNSET to drop
- **Use -1 to release the frame immediately, or**
- Use an actual release time.
PiperOrigin-RevId: 479044215
(cherry picked from commit ff8dd0b4b9aa498a831c9721c530e77bf099a4ed)
"Final" was likely added to reference the FinalMatrixTextureProcessorWrapper,
which is a package-private class. However, I think more clear to express that
this is the input size, which then has all effects applied, to get the output
size.
PiperOrigin-RevId: 477975358
(cherry picked from commit 7286155fc327b1ffcd72903a739368b4bdeebcf8)
* Before this CL, the texture was stored during the construction of the LUT processor. This failed since if one creates a list of GlEffects on the application thread, the texture will get stored in the application thread during the effect creation and not on the GL thread, which executes the FrameProcessors.
* This is an issue since the executing thread then can't index from the texture stored on a different thread.
PiperOrigin-RevId: 476388021
(cherry picked from commit f745c6ee0ea0b610cfdf6a146818b0da7d06326a)
