Populate ICY headers into MediaMetadata so that they can
propagate to the app via AnalyticsListener#onMediaMetadataChanged().
This change copies IcyHeaders.name into MediaMetadata.description
and IcyHeaders.genre into MediaMetadata.genre.
Note: MediaItem.metadata maintain their precedence and overwrite any
ICY headers parsed.
Issue: google/ExoPlayer#9677
#minor-release
PiperOrigin-RevId: 410495676
The main point of the IDLE state is that the player is not holding
resources. Clarify this in the documentation of STATE_IDLE, prepare and
stop.
PiperOrigin-RevId: 409950785
This method is helpful when iterating the list of track overrides
to figure out which type the override applies to.
Issue: google/ExoPlayer#9665
PiperOrigin-RevId: 409108977
And in a couple of related places.
This is for consistency with the rest of the codebase where
we exclusively use indices.
#minor-release
PiperOrigin-RevId: 408273372
* Remove GlUtil.Program String[] constructor to unify and just use the
String constructor.
* Add getAttributeArrayLocationAndEnable() to simplify things a tiny bit.
* Increase usage of constant values.
PiperOrigin-RevId: 407570340
Where this introduced an inconsistency (e.g. assigning to something
called `windowIndex`), I generally renamed the transitive closure of
identifiers to maintain consistency (meaning this change is quite
large). The exception is code that interacts with Timeline and Window
directly, where sometimes I kept the 'window' nomenclature.
#minor-release
PiperOrigin-RevId: 407040052
The video scaling mode and stream type defines a default constant
that needs to be added to the IntDef definition to be assignable.
PiperOrigin-RevId: 406835696
These IntDefs are now annotated with TYPE_USE [1], so they can be moved
to directly before the type (int).
[1] Since <unknown commit>
PiperOrigin-RevId: 406803555
This allows the use of the intdef in parameterized types,
e.g. List<@MyIntDef Integer>
For IntDefs that are already released in ExoPlayer 2.15.1 we add
TYPE_USE in addition to all other reasonable targets, to maintain
backwards compatibility with Kotlin code (where an incorrectly
positioned annotation is a compilation failure). 'reasonable targets'
includes FIELD, METHOD, PARAMETER and LOCAL_VARIABLE but not TYPE,
CONSTRUCTOR, ANNOTATION_TYPE, PACKAGE or MODULE. TYPE_PARAMETER is
implied by TYPE_USE.
For not-yet-released IntDefs we just add TYPE_USE.
#minor-release
PiperOrigin-RevId: 406793413
Only deprecated references remain.
Usages of the deprecated methods will be migrated in a follow-up change.
#minor-release
PiperOrigin-RevId: 405927141
Our package-info.java files are annotated with @NonNullApi which results
in everything being non-null by default, so this annotation is never
needed.
#minor-release
PiperOrigin-RevId: 405864737
The static and dynamic metadata now build up in a list, such that when
the MediaMetadata is built, they are applied in an event order. This
means that newer/fresher values will overwrite older ones. The MediaItem
values are then applied at the end, as they take priority over any other.
#minor-release
PiperOrigin-RevId: 405383177
The current API exposes an `ImmutableMap` of
`TrackGroup` -> `TrackSelectionOverride`.
This has several disadvantages:
- A difficult to use API for mutation
(`ImmutableMap.Builder` doesn't support key removal).
- There is no track selection specific methods,
how the generic map API mapps to the selection override is not complex
but to obvious for a casual reader.
- The internal data type is exposed, making internal refactor difficult.
This was done to have the API ready as quick as possible.
When transitioning the clients to the map API in <unknown commit>,
it became clear that the map API was too verbose and not mapping
to the clients needs, so utility methods
were added to make operations clearer and more concise.
Nevertheless, having to use utility method to use easily and correctly
an API is not the sign of a good API.
This cl refactors the track selection API for several improvements:
- Add a type `TrackSelectionParameters` that encapsulate the internal
data structure (map currently).
- For iteration, expose as a list.
- Add a `Builder` for easy mutable operations.
- Add track selection specific methods to avoid having utilities functions.
- Those operations are the same as `DefaultTrackSelector.Parameters`
for easier migration. (`setOverride` was renamed to `addOverride`)
- Move `TrackSelection` classes outside of `TrackSelectionParameters`
as their own top level classes.
The migration of the client code is straightforward as most of it
were already using the previously mentioned utility functions
that are now native methods.
The full migration has not been done yet, and is pending on this cl approval.
PiperOrigin-RevId: 405362719
Builder setters should only accept null when the underlying property can
be null. In this case null is directly converted to an empty map/list.
PiperOrigin-RevId: 403406626
The previous name is quite easy to misread because it sounds like it
splits up like "(session) for (clear types)" when it's meant to be
"(session for clear) (types)".
The old field is left deprecated for backwards compatibility. The
DrmConfiguration.Builder methods are directly renamed without
deprecation because they're not yet present in a released version of
the library.
PiperOrigin-RevId: 403338799
The possibilities to set a ControlDispatcher have been removed in
<unknown commit> so that the ControlDispatcher is always a
DefaultControlDispatcher.
PiperOrigin-RevId: 403327092
Common houses DataSource as an interface for reading data,
but most of the concrete implementations are in ExoPlayer.
This means that in practice, if an app wants to use a module
that reads using DataSource (e.g. extractor), they may be
forced to depend on ExoPlayer as well to get a concrete
implementation (e.g. FileDataSource). This change moves the
DataSource implementations into common to resolve this.
PiperOrigin-RevId: 403222081
