`TransformerAudioRenderer` reads input and passes `DecoderInputBuffer`s to the `AudioSamplePipeline`. The `AudioSamplePipeline` handles all steps from decoding to encoding. `TransformerAudioRenderer` receives `DecoderInputBuffer`s from the `AudioSamplePipeline` and passes their data to the muxer.
`AudioSamplePipeline` implements a new interface `SamplePipeline`. A pass-through pipeline will be added in a future cl.
PiperOrigin-RevId: 407555102
If the number of samples changes, the sizes will help us to verify whether they are just split differently or extra data was added.
PiperOrigin-RevId: 407346280
Add protected method DefaultRenderersFactory.getCodecAdapter(), so that
subclasses of DefaultRenderersFactory that override
buildVideoRenderers() or buildAudioRenderers() can access the
DefaultRenderersFactory codec adapter factory and pass it to
MediaCodecRenderer instances they may create.
#minor-release
PiperOrigin-RevId: 407345431
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
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
The return values of AudioManager.getPlaybackOffloadSupport are the same as the values defined in C.AudioManagerOffloadMode.
PiperOrigin-RevId: 406817413
The presentation time in fMP4 is calculated by adding and subtracting
3 values. All 3 values are currently converted to microseconds first
before the calculation, leading to rounding errors. The rounding errors
can be avoided by doing the conversion to microseconds as the last step.
For example:
In timescale 96000: 8008+8008-16016 = 0
Rounding to us first: 83416+83416-166833=-1
#minor-release
PiperOrigin-RevId: 406809844
Currently, clipping errors are never thrown if we already have a
MediaPeriod. This may happen for example for ProgressiveMediaSource
where we need to create a MediaPeriod before knowing whether clipping
is supported. Playback will still fail, but with unrelated assertion
errors that are hard to understand for users.
Fix this by setting the pending error on the ClippingMediaPeriod.
#minor-release
Issue: Issue: google/ExoPlayer#9580
PiperOrigin-RevId: 406809737
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
This helps to prevent issues where decoders can't handle negative
timestamps. In particular it avoids issues when the media accidentally
or intentionally starts with small negative timestamps. But it also
helps to prevent other renderer resets at a later point, for example
if a live stream with a large start offset is enqueued in the playlist.
#minor-release
PiperOrigin-RevId: 406786977
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
The return values of AudioManager.getPlaybackOffloadSupport are the same as the values defined in C.AudioManagerOffloadMode.
PiperOrigin-RevId: 406817413
The presentation time in fMP4 is calculated by adding and subtracting
3 values. All 3 values are currently converted to microseconds first
before the calculation, leading to rounding errors. The rounding errors
can be avoided by doing the conversion to microseconds as the last step.
For example:
In timescale 96000: 8008+8008-16016 = 0
Rounding to us first: 83416+83416-166833=-1
#minor-release
PiperOrigin-RevId: 406809844
Currently, clipping errors are never thrown if we already have a
MediaPeriod. This may happen for example for ProgressiveMediaSource
where we need to create a MediaPeriod before knowing whether clipping
is supported. Playback will still fail, but with unrelated assertion
errors that are hard to understand for users.
Fix this by setting the pending error on the ClippingMediaPeriod.
#minor-release
Issue: Issue: google/ExoPlayer#9580
PiperOrigin-RevId: 406809737
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
This helps to prevent issues where decoders can't handle negative
timestamps. In particular it avoids issues when the media accidentally
or intentionally starts with small negative timestamps. But it also
helps to prevent other renderer resets at a later point, for example
if a live stream with a large start offset is enqueued in the playlist.
#minor-release
PiperOrigin-RevId: 406786977
Initialize default components lazily in ExoPlayer.Builder to avoid
redundant component instantiations, useful in cases where apps
overwrite default components with ExoPlayer.Builder setters.
The fields in ExoPlayer.Builder are wrapped in a Supplier (rather than
just making then nullable and initializing them in
ExoPlayer.Builder.build()) so that we maintain the proguarding
properties of this class. The exception is
ExoPlayer.Builder.AnalyticsCollector which became nullable and is
initialized in ExoPlayer.Builder.build() in order to use any Clock
that has been set separately with ExoPlayer.Builder.setClock().
#minor-release
PiperOrigin-RevId: 406345976
This makes sure that #EXT-X-RENDITION-REPORT tags can be placed before the list of segments/parts as well. We were previously assuming that these come at the end, which naturally would make sense and is done like this in all examples, but it is not explicitly defined by the spec.
Issue: google/ExoPlayer#9592
PiperOrigin-RevId: 406329684
Only deprecated references remain.
Usages of the deprecated methods will be migrated in a follow-up change.
#minor-release
PiperOrigin-RevId: 405927141
Also add a setRenderersFactory() method, so that all constructor-provided
components can also be passed via setters.
This comment already appears on the constructor that takes all
components, but it applies to these ones as well.
PiperOrigin-RevId: 405917343
`checkNotNull` should be avoided where possible.
This change adds `@EnsuresNonNull` or `@EnsuresNonNullIf` to configuration methods for fields they initialize.
`checkNotNull` is now avoided for the `@MonotonicNonNull` formats by adding `@RequiresNonNull` annotations.
`checkNotNull` is now avoided for the encoder and decoder in `feedMuxerFromEncoder()`, `feedEncoderFromDecoder()`, `feedDecoderFromInput()`, etc. by creating local variables for `encoder` and `decoder` in `render` after the configuration method calls and passing these as non-null parameters.
PiperOrigin-RevId: 405893824
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
Test file produced with:
$ MP4Box -add "sample.mp4#video:colr=nclc,1,1,1" -new sample_18byte_nclx_colr.mp4
And then manually changing the `nclc` bytes to `nclx`.
This produces an 18-byte `colr` box with type `nclx`. The bitstream of
this file does not contain HDR content, so the file itself is invalid
for playback with a real decoder, but adding the box is enough to test
the extractor change in this commit.
(aside: MP4Box will let you pass `nclx`, but it requires 4 parameters, i.e. it
requires the full_range_flag to be set, resulting in a valid 19-byte colr box)
#minor-release
Issue: #9332
PiperOrigin-RevId: 405842520
- This CL does not introduce functional changes.
- This change will allow searching for the clli box while
parsing the mdcv box in order to construct the HDR
static info contained in ColorInfo.
#minor-release
PiperOrigin-RevId: 405656499
Also check that the output video MIME type is supported with the given container MIME type in `TranscodingTransformer` and `TransformerBaseRenderer`.
PiperOrigin-RevId: 405645362
This has a few benefits:
* Aligns the Builder constructors with the setters
(setRenderersFactory is missing, but can be easily added in a
follow-up change).
* Allows DefaultMediaSourceFactory to be stripped by R8 and
makes the shrinking dev guide for the cases of providing a custom
MediaSourceFactory or directly instantiating MediaSource instances
less weird too.
#minor-release
PiperOrigin-RevId: 405632981
When no encoder video MIME type is specified, the `TransformerTranscodingVideoRenderer` now uses the video MIME type of the input for the encoder format.
The input format is now read in a new method `ensureInputFormatRead` which is called before the other configuration methods. This removes the logic for reading the input format from `ensureDecoderConfigured`, because it is now needed for both encoder and decoder configuration but the encoder needs to be configured before GL and GL needs to be configured before the decoder, so the decoder can't read the format.
The width and height are now inferred from the input and the frame rate and bit rate are still hard-coded but set by the `MediaCodecAdapterWrapper` instead of `TranscodingTransformer`.
PiperOrigin-RevId: 405631263
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
This introduces a new option `setAudioMimeType` in `TranscodingTransformer.Builder` and a corresponding check whether the selected type is supported. This check is done using `supportsSampleMimeType` which is now part of the `Muxer.Factory` and `MuxerWrapper` rather than `Muxer`.
A new field `audioMimeType` is added to `Transformation` and the `TransformerAudioRenderer` uses this instead of the input MIME type if requested.
PiperOrigin-RevId: 405367817
Decoded video frames can be large and there is no need to retrieve the
corresponding ByteBuffer as we render the decoded frames on a surface
for better performance.
PiperOrigin-RevId: 405364950
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
* @Reason is not a TYPE_USE annotation, so should appear before any modifiers and after Javadocs.
(see go/java-style#s4.8.5-annotations)
* Curly braces should be used for inline Javadoc tags: {@code ...}
(see http://go/bugpattern/InvalidInlineTag)
This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if the change looks generally problematic.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.
This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.
#codehealth
PiperOrigin-RevId: 404769260
The HLS Parser converts from a string decimal duration in seconds into long
microseconds.
Because the conversion passes through a java double type it can result in
representation errors.
For example:
`#EXTINF:4.004` -> `Segment.durationUs` of 4003999
This matters because the first sample (which is the IDR) for a segment will be discarded following a seek because of the logic in the `SampleQueue`:
````java
buffer.timeUs = timesUs[relativeReadIndex];
if (buffer.timeUs < startTimeUs) {
buffer.addFlag(C.BUFFER_FLAG_DECODE_ONLY);
}
````
The HLS implementation of `getAdjustedSeekPositionUs()` now completely supports `SeekParameters.CLOSEST_SYNC`
and it's brotheran, assuming the HLS stream indicates segments all start with
an IDR (that is EXT-X-INDEPENDENT-SEGMENTS is specified).
This fixes issue #2882 and improves (but does not completely solve #8592
Issue: #9392 reports occasional IllegalStateExceptions from release()
in crashlytics,`with no way to reproduce locally. It seems likely there
is a bug somewhere in DRM handling, and ideally we would find that and
fix it.
However we haven't been able to find the problem, and in the meantime
these exceptions cause the entire app to crash. Although this is
arguably useful from a debugging perspective, it's obviously a poor
experience for developers and users, since all we're actually trying to
do is release the session, so maybe we shouldn't strictly care that it's
already released?
This change replaces the exception with an error log, which might be a
useful debugging hint if we see other DRM unexpected behaviour due to
references to released sessions being held for too long.
PiperOrigin-RevId: 403942546
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 new forcedSessionTrackTypes field was introduced in
<unknown commit>.
These usages are migrated in a follow-up change to add confidence that
the deprecated field continued to work correctly.
PiperOrigin-RevId: 403342893
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
Also fix a typo where windowIndex was being passed to Objects.hashCode
twice.
The old field is left deprecated for backwards compatibility. Usages
will be migrated in an upcoming change.
PiperOrigin-RevId: 403049260
An upcoming change will modify ExoPlayer.Builder#build() to return
ExoPlayer, so any places that explicitly need a SimpleExoPlayer
instance should be using SimpleExoPlayer.Builder.
PiperOrigin-RevId: 403028312
As suggested in parent change, return a list of
`TrackType` instead of appending to it.
This has the slight disadvantage of iterating twice
over the (short) list, but clarifies the code.
PiperOrigin-RevId: 402844458
Update the UI module, the demos and most other users
to make use of the new player TracksInfo and track
selection override APIs.
PiperOrigin-RevId: 402817857
When ExtractorInput.getLength() returns a defined length, the
SubtitleExtractor will create a buffer of the same length, call
ExtractorInput.read() until it has read the input bytes, plus one more
time where ExtractorInput.read() returns RESULT_END_OF_INPUT. The last
call to ExtractorInput.read() however will make the SubtitleExtractor to
increase its buffer (including a copy) unnecessarily.
This change makes the SubtitleExtractor avoid calling
ExtractorInput.read() if the expected number of bytes have already
been read, so that the internal buffer does not grow.
PiperOrigin-RevId: 402583610
Enable subtitle output in the PlaybackOutput and disable the text
renderer in the MkvPlaybackTest. Add WebvttPlaybackTest to test the
output of side-loaded WebVTT subtitles.
PiperOrigin-RevId: 402526588
Before this change, the SubtitleExtractor did not mark the limit
of the input buffer, thus the SubtitleDecoder attempted to decode
more bytes. If the subtitle file had a new line at the end, this
bug would make the SubtitleDecoder append an line break after the
last subtitle.
PiperOrigin-RevId: 402523039
*** Original commit ***
Migrate callers of ExoPlayer.Builder#build() to buildExoPlayer()
An upcoming change will update build() to return Player.
PiperOrigin-RevId: 401468532
In a future change it will be updated to return ExoPlayer
We no longer need separate methods to build Player and ExoPlayer, so
buildExoPlayer will be removed shortly.
PiperOrigin-RevId: 401441016
Temporary file copy of Transformer, which uses
TransformerTranscodingVideoRenderer instead of
TransformerMuxingVideoRenderer to transform files. This allows devs to test
transcoding more easily using the Transformer demo, while external engineers
continue to see the completely working Muxing-based transformer.
In the future, this will replace the Transformer class.
PiperOrigin-RevId: 401020893
*** Original commit ***
Rollback of 8ed6c9fcf5
*** Original commit ***
Fix capitalization of language in track selector
Issue: #9452
***
***
PiperOrigin-RevId: 400942287
TracksInfo is very similar to
`MappingTrackSelector.MappedTracksInfo` with some
fields removed to simplify the Player API,
notably it doesn't expose the renderer concept.
A significant difference is the addition of a `selected` boolean
field which avoids having a separate `getCurrentTrackSelection`
API.
This cl is a part of the bigger track selection change,
splitted for ease of review.
In particular, the MediaSession implementation and UI usage
have been slitted in child cls.
Find all cls with the tag:
#player-track-selection
PiperOrigin-RevId: 400937124
This change makes asynchronous queueing non-experimental, it enables the
feature by default on devices with API level >= 31 (Android 12+) and
exposes APIs for apps to either fully opt-in or opt-out from the
feature.
The choice to use or not asynchronous queueing is moved out of
MediaCodecRenderer to a new MediaCodecAdapter factory, the
DefaultMediaCodecAdapterFactory. This is because, at the moment,
if an app passes a custom adapter factory to a MediaCodecRenderer and
then enables asynchronous queueing on it, the custom
adapter factory is not used but this is not visible to the user.
The default behavior of DefaultMediaCodecAdapterFactory is to create
asynchronous MediaCodec adapters for devices with API level >= 31
(Android 12+), and synchronous MediaCodec adapters on devices with older
API versions.
DefaultMediaCodecAdapterFactory exposes methods to force enable or force
disable the use of asynchronous adapters so that applications can enable
asynchronous queueing on devices with API versions before 31 (but not
before 23), or fully disable the feature. For applications that build
MediaCodecRenderers directly, they will need to create a
DefaultMediaCodecAdapterFactory and pass it to the renderer constructor.
For applications that rely on the DefaultRenderersFactory, additional
methods have been added on the DefaultRenderersFactory to control
enabling/disabling asynchronous queueing.
Issue: #6348
PiperOrigin-RevId: 400733506
Removes subtitle allow-list by using SubtitleDecoderFactory.DEFAULT.
When the format is unsupported, the extractor registers one track and
sends the format with the Format#sampleMimeType set to TEXT_UNKNOWN and
Format#codecs field set to the actual subtitle MIME type.
The TextRenderer will recognize this MIME Type as not supported which is
gonna be visible in the event log.
PiperOrigin-RevId: 400679058
It calls through to a deprecated method, which is unusual for a
convenience method, and the deprecated method has various
implementations. This allows for a smoother removal of stop(boolean)
and removes an obstacle for the ExoPlayer-SimpleExoPlayer merge.
Adds missing @Deprecated tags to some Players.
PiperOrigin-RevId: 400213422
The format should have the following fields set (as specified in the javadoc):
- width
- height
- frame rate, and
- averageBitrate.
PiperOrigin-RevId: 400204510
Usages of the (already deprecated) Subtitle constructors were not
migrated, as it would require migrating to the Builder which is a more
involved change.
PiperOrigin-RevId: 400153139
This is more consistent with the other MediaItem inner classes which are
all Configurations.
The old class and fields are left deprecated for backwards
compatibility.
The deprecated Subtitle constructors are not moved to
SubtitleConfiguration.
PiperOrigin-RevId: 400144640
If callers need an ExoPlayer instance they should use buildExoPlayer().
Also remove the @InlineMe annotation now these methods are no longer
equivalent.
PiperOrigin-RevId: 400143239
This moves `SelectionOverride` from `DefaultTrackSelector`
to `TrackSelectionParameters`.
It is then use to allow track selection override per
track selection array.
Note that contrary to
`DefaultTrackSelector.Parameters.selectionOverride`, the renderer
concept is not exposed.
This cl is a part of the bigger track selection change,
splitted for ease of review.
Find all cls with the tag:
#player-track-selection
PiperOrigin-RevId: 399933612
There are two very similar tests checking for release events,
one running with Robolectric and one instrumentation test.
The instrumentation test only adds the interaction with the player
to release it while the renderers are active. This same interaction
can be added to the Robolectric test as well.
This arguably improves the realism of the Robolectric test too
as we listen for real player events instead of simulating the same
events.
PiperOrigin-RevId: 399694869
This is more consistent with the other MediaItem inner classes which are
all Configurations.
The old class and fields are left deprecated for backwards
compatibility.
MediaItem.Builder#setClippingProperties is directly renamed (without
deprecation) because it only exists on the dev-v2 branch and hasn't
been included in a numbered ExoPlayer release.
PiperOrigin-RevId: 399471414
Before releasing r2.15.0, we had a regression that crashed
PlaybackStatsListener. A change in the AnalyticsCollector made
it to send an additional AnalyticsListener.onEvents() callback after
calling Player.release() and AnalyticsListener.onEvents() appeared
to arrive with event times that were not monotonically increasing.
The AnalyticsListener.onEvents() callback that contained
AnalyticsListener.EVENT_PLAYER_RELEASED was called with a timestamp that
was smaller than event times of previously AnalyticsListener.onEvents()
calls.
A first fix changed the order of events being forwarded to
AnalyticsListener. Upon calling Player.release(), the AnalyticsCollector
would call AnalyticsListener.onPlayerReleased() and its associated
AnalyticsListener.onEvents() on the same stack call. This fix maintained
that event times are monotonically increasing, but made
AnalyticsListener.onPlayerReleased() be called earlier.
This change:
- Further changes AnalyticsCollector to ensure that
AnalyticsListener.onPlayerReleased() and its related
AnalyticsListener.onEvents() are the last callbacks to be called,
and the associated timestamp is bigger than previously reported
event times.
- Adds an instrumentation test to guard against the regression.
PiperOrigin-RevId: 399437724
The fix for Issue: #8776 was to release and null-out dummySurface if
it doesn't match the security level of the decoder. But it's possible
that this.surface is already set to this.dummySurface, in which case we
must also null out this.surface otherwise we will later try and re-use
the old, released DummySurface instance.
This logic already exists in MCVR#onReset, so I pulled it into a
releaseDummySurface() helper function.
Issue: #9476
#minor-release
PiperOrigin-RevId: 399420476
For Automotive devices, surround encodings can be supported via
the passthrough path. Therefore, include automotive in the allowed
device types in the isDirectPlaybackSupported checks. The automotive
system feature is checked, rather then UI_MODE_TYPE_CAR, because
the UI_MODE_TYPE_CAR can be force enabled via
android.app.UiModeManager.enableCarMode(), whereas FEATURE_AUTOMOTIVE
cannot be forced.
This aligns with other MediaItem.FooConfiguration class names and also
more clearly represents that this class encapsulates information used
for local playback that is lost when serializing MediaItem between
processes.
The old class and fields are kept (deprecated) for backwards
compatibility.
PiperOrigin-RevId: 398742708
- If DownloadService is configured to run as a foreground service,
it will remain started and in the foreground when downloads are
waiting for requirements to be met, with a suitable "waiting for
XYZ" message in the notification. This is necessary because new
foreground service restrictions in Android 12 prevent to service
from being restarted from the background.
- Cases where requirements are not supported by the Scheduler will
be handled in the same way, even on earlier versions of Android.
So will cases where a Scheduler is not provided.
- The Scheduler will still be used on earlier versions of Android
where possible.
Note: We could technically continue to use the old behavior on
Android 12 in cases where the containing application still has a
targetSdkVersion corresponding to Android 11 or earlier. However,
in practice, there seems to be little value in doing this.
PiperOrigin-RevId: 398720114
The MIME type is currently required to select a SubtitleDecoder
implementation in the TextRenderer. Future changes might remove this
requirement, so we pre-emptively mark the field as @Nullable.
The change in SingleSampleMediaSource ensures the track still maps to
the TextRenderer, otherwise it shows up as unmapped. Passing null MIME
type to MediaItem.Subtitle constructor now results in this from
EventLogger:
TextRenderer [
Group:0, adaptive_supported=N/A [
[ ] Track:0, id=null, mimeType=text/x-unknown, language=en, supported=NO_UNSUPPORTED_TYPE
]
]
PiperOrigin-RevId: 398010809
Both license and provisioning requests could be considered 'DRM
requests', and these headers are only sent on license requests, so
rename them to reflect that.
The old field remains deprecated for backwards compatibility.
PiperOrigin-RevId: 397980021
This change only calls setters if we need to override the existing value
(or more specifically, set a value that's absent).
PiperOrigin-RevId: 397979904
The type is already UUID so there's no need to duplicate that info in
the field name, and 'scheme' is a widely used term throughout both
ExoPlayer and android.os.MediaDrm documentation.
The old field remains deprecated for backwards compatibility.
The MediaItem.DrmConfiguration.Builder#setUuid method is renamed
directly (without deprecation) because it's not yet part of a released
ExoPlayer version.
PiperOrigin-RevId: 397961553
This takes advantage of the new MediaItem.LiveConfiguration.Builder
This change will always allocate a new LiveConfiguration.Builder and
LiveConfiguration, but preserves the behaviour of keeping the same
MediaItem instance if no values have changed.
PiperOrigin-RevId: 397961427
Issue: #9430
The current supported SDP (RFC2327) spec only allows for alpha-numeric
characters in the attribute-field. RFC4566 (section 9, token type) allowed
extra characters, and this CL adds the support.
PiperOrigin-RevId: 397301173
This is known to silently drop the value. This setter is now deprecated
in favour of `MediaItem.Builder#setDrmConfiguration(MediaItem.DrmConfiguration)`,
which requires a UUID in order to construct the `DrmConfiguration`
instance.
Issue: #9378 tracks correctly propagating the DRM info out of
`DownloadRequest#toMediaItem`.
PiperOrigin-RevId: 397291013
The previous implementation did the following (after skipping any ID3
headers at the start of the stream):
1. Skip forward byte-by-byte looking for a sync word (0xFFF)
2. Assume this indicates the start of an ADTS frame and read the size
a) If frameSize <= 6 immediately return false
3. Skip forward by frameSize and expect to find another ADTS sync word
(with no further scanning).
b) If we find one, great! Loop from step 2.
a) If we don't find one then assume the **last** sync word we found
wasn't actually one, so loop from step 1 starting one extra byte
into the stream. This means we're looking for a sync word we would
have skipped over in step 3.
The asymmetry here comes from the different handling of frameSize <= 6
(immediately return false) and frameSize being 'wrong because it doesn't
lead to another sync word' (scan the file again from the beginning for
alternative sync words).
With this change both these cases are handled symmetrically (always scan
for alternative sync words). Step 2a) becomes the same as 3b): Loop back
to the beginning of the stream with an incremented offset and scan for
another sync word.
#minor-release
PiperOrigin-RevId: 397285756
The deprecated `Player.addListener(EventListener)`
is moved out of Player into its subclasses
(CastPlayer and ExoPlayer).
This is unlikely to break users because:
- the method has been deprecated in the last major version
- the method is still present in the major implementations
If an users is affected, they can either:
- use ExoPlayer instead of Player
- (recommended) switch to Player.Listener.
Additionally update the threading guarantees that did not
reflect the current implementation.
PiperOrigin-RevId: 397272144
* Avoid ActivityManager log spam by only calling startForeground once,
and subsequently updating the notification via NotificationManager.
* Tweak demo app service to make it a tiny bit easier to swap the Scheduler.
PiperOrigin-RevId: 397179398
The second getScheduler() call violates the documentation of
the class, which states that getScheduler() is not called if
foregroundNotificationId if FOREGROUND_NOTIFICATION_ID_NONE.
Presumably implementing subclasses would return null, in which
case this didn't do any harm, but we should make sure the
implementation behaves as documented regardless.
PiperOrigin-RevId: 397167603
This is a pre-requisite step for merging SimpleExoPlayer into
ExoPlayer, because when StubExoPlayer extends ExoPlayer, it needs
a matching constructor.
PiperOrigin-RevId: 397065374
This was originally reported on #9390. There was a bug that when HLS
loads failed, the player would endlessly retry and never fail with a
player error.
This change fixes a bug in HlsSampleStreamWrapper.onPlaylistError()
which would return true for a playlist whose load encountered an error
but could not be excluded, whereas the method should return false.
Issue: #9390
#minor-release
PiperOrigin-RevId: 397045802
*** Original commit ***
Ensure MediaSourceFactory instances can be re-used
This fixes DefaultDrmSessionManager so it can be used by a new Player
instance (by nulling out its reference to the playback thread, which is
unique per-Player instance). This only works if the
DefaultDrmSessionManager is 'fully released' before being used by the
second Player instance, meaning that the reference count of the manager
and all its sessions is zero.
#exofixit
Issue: #9099
***
PiperOrigin-RevId: 396861138
Previously the released preacquired sessions would start their keepalive
timeout, and so no additional resources would be freed in time for the
manager to retry the session acquisition.
This change adds an additional purge of keepalive sessions *after* the
preacquired sessions are released, which fixes the problem.
#exofixit
#minor-release
PiperOrigin-RevId: 396613352
This is was reported in #9257 where the PlaybackStatsListener may try to
access an emtpy ArrayList.
Issue: #9257
#minor-release
#exofixit
PiperOrigin-RevId: 396329373
This is a candidate fix for #8906. As mentioned in that issue,
negative positions within windows might be (kind of) valid in
live streaming scenarios, where the window starts at some
non-zero position within the period. However, negative positions
within periods are definitely not valid. Neither are positions
that exceed the period duration.
There was already logic in ExoPlayerImplInternal to prevent a
resolved seek position from exceeding the period duration. This
fix adds the equivalent constraint for the start of the period.
It also moves the application of the constraints into Timeline.
This has the advantage that the constraints are applied as part
of state masking in ExoPlayerImpl.seekTo, removing any UI flicker
where the invalid seek position is temporarily visible.
Issue: #8906
PiperOrigin-RevId: 395917413
Instead of selecting the base URL initially or when a load error occurs, it is now selected when a chunk or initialization chunk is created. The selected base URL is then assigned to `RepresentationHolder.lastUsedBaseUrl` that is excluded in case of a load error. For a next chunk another base URL will be selected by using the `BaseUrlExclusionList`.
#minor-release #exo-fixit
PiperOrigin-RevId: 395721221
The new name is consistent with the corresponding parameters to `onVolumeChanged`, `setDeviceVolume` and `onDeviceVolumeChanged`.
PiperOrigin-RevId: 395705288
Since playlist support was added, it's possible for the player to "have media"
and be in STATE_IDLE. The STATE_IDLE documentation therefore became incorrect.
Issue: #8946
#exofixit
#minor-release
PiperOrigin-RevId: 395653716
This fixes DefaultDrmSessionManager so it can be used by a new Player
instance (by nulling out its reference to the playback thread, which is
unique per-Player instance). This only works if the
DefaultDrmSessionManager is 'fully released' before being used by the
second Player instance, meaning that the reference count of the manager
and all its sessions is zero.
#exofixit
#minor-release
Issue: #9099
PiperOrigin-RevId: 395490506
SubtitleExtractor is using IndexSeekMap with only one position to
indicate that its output is seekable. SubtitleExtractor is keeping Cues
in memory anyway so more seek points are not needed. SubtitleExtractor
gets notified about seek occurrence through seek() method. Inside that
method extractor saves seekTimeUs, and on the next call to read()
extractor outputs all cues that should be displayed at this time and
later.
PiperOrigin-RevId: 395477127
Some server will send partial URIs in the RTP-Info header, while the RTSP spec
requires absolute URLs.
Issue: #9346
#exofixit
PiperOrigin-RevId: 395452741
The C2 MP3 decoder produces an extra output buffer when draining after
end-of-stream is queued. This output buffer has a later timestamp than the last
queued input buffer so we need to calculate its timestamp to detect a stream
change in the correct position.
Before this CL we used the original input buffer timestamp as the largest
queued timestamp, which caused the stream change to be detected at the correct
position because the original input buffer timestamp was slightly larger than
the actual last output buffer timestamp. After this change we use exact
calculated timestamp as the largest queued timestamp. I manually verified
gapless continues to work on a device using the C2 MP3 decoder by comparing
output of the MP3 gapless and MP3 gapless stripped playlists in the demo app,
and that the last buffer timestamp now matches.
#exofixit
PiperOrigin-RevId: 395428928
- Fix focus when pausing and resuming
- Prevent repeated readout of the playback position when paused
#exofixit
#minor-release
Issue #9111
PiperOrigin-RevId: 395301765
The current detection logic checks that the two byte terminator starts
at an even position in the ID3 data, where-as it should check that it
starts at an even position relative to the start of the string.
#minor-release
#exofixit
Issue: #9087
PiperOrigin-RevId: 395274934
Simplifies the SubtitleExtractor implementation. Makes the extractor
more aligned with the Extractor interface documentation by removing
STATE_DECODING in which extractor was doing nothing in term of input
and output while returning RESULT_CONTINUE at the same time.
PiperOrigin-RevId: 395267468
C should only hold constants.
Also resolve the TODO in getErrorCodeForMediaDrmErrorCode(), and
annotate the deprecated methods with Error Prone's @InlineMe to
facilitate automated refactoring of callers.
PiperOrigin-RevId: 395244855
This typically happens if there's a discontinuity in the stream.
It's better to say we don't know, than it is to return a negative
position.
Issue: #8346
#exofixit
#minor-release
PiperOrigin-RevId: 395224088
This CL contains integration of the ExoplayerCuesDecoder and the
SubtitleExtractor with the player. The SubtitleExtractor is integrated
inside the DefaultMediaSourceFactory. The flag was added to the
state of the DefaultMediaSourceFactory to let user decide between the
ProgressiveMediaSource and the SingleSampleMediaSource as a source for
subtitles. Choosing the ProgressiveMediaSource will cause data to flow
through the SubtitleExtractor and eventually the ExoplayerCuesDecoder.
PiperOrigin-RevId: 394500305
Empty buffer with flag C.BUFFER_FLAG_END_OF_STREAM is send at the end
of the stream. Handling that flag properly is necessary to make the
ExoplayerCuesDecoder work properly with components like TextRenderer.
PiperOrigin-RevId: 394472642
Extractor was not calling endTracks() and seekMap() on the
extractorOutput which are required to finish the preparation.
At that point extractor does not support seeking.
PiperOrigin-RevId: 393994848
In the old version, the transcoder uses decoder.isEnded() alone as the criteria
to stop the encoding/muxing process. It's rectified to:
- On decoder ending, signal the encoder of EOS after writing all decoded frames to it.
- On encoder ending, write end track to muxer.
PiperOrigin-RevId: 393322114
Make this behaviour optional, so it can be disabled for
AnalyticsCollectorTest where we don't use
FakeExoMediaDrm.LicenseServer.
PiperOrigin-RevId: 393133721
This cl doesn't implement completely the API for
`ExoPlayerImpl` as
`onTrackSelectionParametersChanged` is not called.
The follow up cl adds `TrackSelectionParameters` in PlaybackInfo
to correctly propagate the change event and mask it.
Additionally `TrackSelectionParameters` is serialized as a Parcelable
for now. It is transitioned to bundleable in a follow up cl.
PiperOrigin-RevId: 392899918
- Android 12 will not allow our download service to be
restarted from the background when conditions that
allow downloads to continue are met. As an interim
(and possibly permanent) solution, we'll keep the
service in the foreground if there are unfinished
downloads that would continue if conditions were met.
- Keeping the service in the foreground requires a
foreground notification. Hence we need to be able to
generate a meaningful notification for this state.
PiperOrigin-RevId: 391969986
StyledPlayerControlView was checking whether the player is an ExoPlayer
instance to set the track selector. This means that, if apps were
wrapping an ExoPlayer in a ForwardingPlayer (to replace a
ControlDispatcher for example), the track selector wasn't set anymore.
#minor-release
PiperOrigin-RevId: 391776305
Samples are serialized using our custom CueEncoder. Information in
which format samples are encoded is needed by Renderer to decide which
decoder to use. Extractor receives Format object in the constructor and
prepares new Format object with sampleMimeType moved to codecs field
and new sampleMimeType set to "custom serialized exoplayer Cue".
PiperOrigin-RevId: 391739866
Most of those objects needs to be sent to MediaControler.
`TrackSelectior.Parameters` could have stayed Parcelable,
but it needs to be `Bundleable` as it inherit from
`TrackSelectionParameters` that is and needs to be
serializable anyway for the demo app.
As a result it has also been migrated to bundleable.
PiperOrigin-RevId: 391353293
SubtitleExtractor.release() releases the underlying SubtitleDecoder.
This change introduces the STATE_RELEASED state. The extractor
handles the new state in the read() and seek() methods.
PiperOrigin-RevId: 391046478
SubtitleExtractor is a component that extracts subtitle data taken from
ExtractorInput into samples. Samples are pushed into an ExtractorOutput
(usually SampleQueue). As a temporary solution SubtitleExtractor uses
SubtitleDecoder to extract Cues from input data.
PiperOrigin-RevId: 390319875
The prototype is built upon Transformer and took many references from
TransformerAudioRenderer.
Please take a look and we can discuss more details.
PiperOrigin-RevId: 390192487
The result is plumbed back to `MediaCodecRenderer` via a new
`DrmSession#requiresSecureDecoder` method.
This allows us to use the `MediaDrm#requiresSecureDecoder` method added
in Android 12:
https://developer.android.com/reference/android/media/MediaDrm#requiresSecureDecoder(java.lang.String)
This change also removes
`FrameworkMediaCrypto#forceAllowInsecureDecoderComponents`, replacing it
with equivalent logic in `FrameworkMediaDrm#requiresSecureDecoder`.
PiperOrigin-RevId: 389616038
Adding a CHANGE_FRAME_RATE_STRATEGY_ALWAYS strategy is
omitted from this commit, since adding it is more complicated
than just plumbing it through and leaving everything else
unchanged. Specifically, VideoFrameReleaseTimeHelper would
need updating to behave differently when such a strategy is
enabled. It currently calls setFrameRate in cases such as
pausing, seeking and re-buffering, on the assumption that
changes to the underlying display refresh rate will only be
made if they can be done seamlessly. For a mode in which
this will not be the case, it makes more sense to stick to
the content frame-rate when these events occur. It may also
make sense to only use explicit content frame-rate values,
and not those inferred from individual frame timestamps.
Finally, for adaptive content containing a mix of frame-rates,
it makes sense to use the maximal frame-rate across all
variants, and to avoid calling setFrameRate on switches from
one variant to another.
Applications that know the frame-rate of their content can
set ExoPlayer's strategy to CHANGE_FRAME_RATE_STRATEGY_OFF and
then use setFrameRate directly on the output surface. Note that
this is likely to be a better option for apps than anything we
could implement in ExoPlayer, because the application layer
most likely knows the frame-rate of the content earlier than
ExoPlayer does (e.g., to perform the disruptive mode switch
at the same time as an activity transition).
Adding CHANGE_FRAME_RATE_STRATEGY_ALWAYS will be deferred
until there's clear demand for it. In the meantime, we'll
recommend the alternative approach above.
PiperOrigin-RevId: 389610965
This CL moves SubtitleDecoder and all its dependencies
to common in order to enable using it in extractor
module while implementing SubtitleExtractor.
PiperOrigin-RevId: 388979021
This CL introduces two classes:
* CueEncoder - encodes list of Cue object into byte array.
* CueDecoder - decodes byte array into list of Cue objects.
This two classes are necessary in order to push Cues through SampleQueue. This classes are meant to be used by subtitle Extractor.
PiperOrigin-RevId: 388932088
These API levels have both been finalized. We're also calling methods
from these API levels directly, which may not exist if a device is
running a non-finalized R or S release.
PiperOrigin-RevId: 388903410
Issue: #9254
#minor-release
We used to allow only alphanumerical characters in session id. The spec also
allows "$", "-", "_", ".", "+" (RFC2326 Sections 3.4 and 15.1).
PiperOrigin-RevId: 388873742
This change removes ERROR_CODE_IO_NETWORK_UNAVAILABLE,
ERROR_CODE_IO_NETWORK_CONNECTION_CLOSED, and ERROR_CODE_IO_DNS_FAILED
in favor of keeping only ERROR_CODE_IO_NETWORK_CONNECTION_FAILED.
PiperOrigin-RevId: 388715972
- Fix use of getTimestampOffsetUs in TsExtractor where
getFirstSampleTimestampUs should have been used.
- Don't reset TimestampAdjuster if it's in no-offset mode.
- Improve comment clarity
#minor-release
PiperOrigin-RevId: 388682711
For audio-only playlists, when formats are communicated to the app with
AnalyticsListener.onDownstreamFormatChanged(), the passed MediaLoadData
do not indicate this is an audio track and therefore the
PlaybackStatsListener cannot derive audio format-related information.
This change sets the main SampleStreamWrappers track type to AUDIO, if
the master playlist contains only audio variants.
Issue: #9175
#minor-release
PiperOrigin-RevId: 388676060
The AnalyticsCollector releases listeners lazily so that listener
callbacks triggered on the application looper after
SimpleExoPlayer.release() are still handled. The change in ListenerSet
to post the onEvents callback on the front of the application looper
changed (correctly) how onEvents are propagated, however this made
the AnalyticsCollector deliver onEvents with out-of-order EventTimes.
This change fixes AnalyticsCollector to trigger onPlayerReleased() and
the matching onEvents() event in the correct order.
#minor-release
PiperOrigin-RevId: 388668739
This change aligns all the names for classes that are 'holders of static
methods' to be `ApiNN`. Classes that hold state are named meaningfully
based on that state.
PiperOrigin-RevId: 388641064
This CL addresses the github issue [#8946](https://github.com/google/ExoPlayer/issues/8964). That issue requests support for `font-size` CSS property in WebVTT subtitle format. This CL:
* Adds support for `font-size` property by extending capabilities of WebVTT `CssParser`. Implementation of `font-size` property value parsing is based on the one in `TtmlDecoder`.
* Adds unit test along with test file containing WebVTT subtitles with all currently supported `font-size` units.
#minor-release
PiperOrigin-RevId: 388423859
- Use timestampOffsetUs == C.TIME_UNSET directly as the way of
determining whether the adjuster has determined the offset,
rather than relying on lastSampleTimestampUs checks for this.
- Remove comment referring to lastSampleTimestampUs as holding
the "adjusted PTS". Its value may not have originated from a PTS
timestamp. It's also confusing to refer to it as "adjusted"
given timestampOffsetUs has not been applied to it.
- Fix PassthroughSectionPayloadReader to make sure it'll never
output a sample with an unset timestamp.
#minor-release
PiperOrigin-RevId: 388226180
Prior to this change, an initalized TimestampAdjuster that's then
reset with DO_NOT_OFFSET would incorrectly continue to apply the
offset.
Also add a test case for this issue, and for some other simple use
cases.
#minor-release
PiperOrigin-RevId: 388182645
DefaultHttpDataSource and OkHttpDataSource can share the same error code
assigning logic.
Fixes CronetDataSource's handling of closed connection.
PiperOrigin-RevId: 387791679
The dokka javadoc generation tool complains when parameter names don't match between a method and its override. This change updates occurrences where there is currently a mismatch.
PiperOrigin-RevId: 387367509
The dokka javadoc generation tool complains when parameter names don't match between a method and its override. This change updates occurrences where there is currently a mismatch.
Notable renamings that might be controversial:
- `onPlaybackStateChanged(int state)` to `onPlaybackStateChanged(int playbackState)` affected a lot of lines but seems more consistent with other '-Changed' methods.
- `handleMessage(int messageType, Object payload)` to `handleMessage(int messageType, Object message)`
- `ExtractorInput` and `DataSource` inherit `DataReader` which had `read(byte[] target, ...`, while data sources normally called the first parameter `buffer`. I have standardized these all to use `buffer` even though it looks out of place in the `ExtractorInput` interface (which has more `read` methods with `target`).
PiperOrigin-RevId: 387290360
The documentation on ByteArrayOutputStream and GZIPOutputStream isn't
completely clear that an IOException will *never* happen, so
AssertionError seems a bit strong - but it seems very unlikely, so we
just use IllegalStateException instead.
#minor-release
PiperOrigin-RevId: 387169297
The inference is used when nesting DataSourceExceptions. It is removed because
nesting does not add additional value in surfacing the exceptions, and it is
better to assign an error code at the throw site (in the "leaf" or the bottom
most data source).
PiperOrigin-RevId: 386919118
* @Flags is not a TYPE_USE annotation, so should appear before any modifiers and after Javadocs.
(see go/java-style#s4.8.5-annotations)
This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Suggest a fix on the CL (go/how-to-suggest-fix).
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if the change looks generally problematic.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.
This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.
#codehealth
PiperOrigin-RevId: 386849198
The reason this was not an IO error code is that before other
IOExceptions were classified, this catch would grab non-IO error
codes, like ParserException. Now that we are getting closer to
the final state, we can assume IOExceptions are ok to classify
as IO error codes (unlike, for example, ParserExceptions or
DrmSessionExceptions).
PiperOrigin-RevId: 386496752
Using all lower case RTSP headers is perfectly valid, as the spec mandates case
insensitively. However, some RTSP servers do not implement the RTSP spec
closely and does not recognize the lower case headers. This change aims
at using the header names as defined in the RTSP spec to maximize compatibility.
Issue: #9182
PiperOrigin-RevId: 386224566
In some DataSources, it is not easy to assign an error code at the throw site.
For example, CronetDataSource.readInternal() throws SocketTimeoutException
on L1033, and is caught at L754 as IOException and is thrown.
We need the logic to assign error code for the actual type of the error cause.
While we can certainly do in individual DataSources, IMO there's value in
making this logic generic at a higher level (like what is in this CL).
The catch and translation logic is borrowed from EPII:L646.
PiperOrigin-RevId: 385789629
Before this fix, if DefaultDrmSessionManager.release() was called while
there was at least one 'external' session reference still active (i.e.
session.referenceCount > 1) then the manager will release it's reference
immediately but when the session's reference count subsequently drops to
1 (due to external references being released) the manager will schedule
a task to release its internal reference *again*.
This change fixes the problem by only scheduling the timed release if
the manager is unreleased. This ensures that the internal references
are only released once.
Issue: #9193
#minor-release
PiperOrigin-RevId: 385580741
When the size of the video is unknown,
PlayerView and StyledPlayerView set the aspect ratio as 1,
which could result in wrong view layout.
This CL sets the aspect ratio as 0 (unset) to prevent that.
This handles Issue: #9189.
PiperOrigin-RevId: 385115357
This values won't be configurable from the UI anymore once the
DefaultControlDispatcher is removed.
They can be configured in the Player or by using a ForwardingPlayer.
PiperOrigin-RevId: 385113498
* Constructors and methods with the same name should appear sequentially with no other code in between, even when modifiers such as static or private differ between the methods. Please re-order or re-name methods.
(see http://go/bugpattern/UngroupedOverloads)
This CL looks good? Just LGTM and Approve it!
This CL doesn’t look good? This is what you can do:
* Suggest a fix on the CL (go/how-to-suggest-fix).
* Revert this CL, by replying "REVERT: <provide reason>"
* File a bug under go/error-prone-bug for category ErrorProneStyle if the change looks generally problematic.
* Revert this CL and not get a CL that cleans up these paths in the future by
replying "BLOCKLIST: <provide reason>". This is not reversible! We recommend to
opt out the respective paths in your CL Robot configuration instead:
go/clrobot-opt-out.
This CL was generated by CL Robot - a tool that cleans up code findings
(go/clrobot). The affected code paths have been enabled for CL Robot in //depot/google3/java/com/google/android/libraries/media/METADATA which is reachable following include_presubmits from //depot/google3/third_party/java_src/android_libs/media/METADATA.
Anything wrong with the signup? File a bug at go/clrobot-bug.
#codehealth
PiperOrigin-RevId: 384877648
Issue: #9183
RFC2326 Section C.1.1 specifies that the URI to identify a track can be either
absolute (like rtsp://example.com/path) or relative (like "path"). Currently
we don't handle absolute URI, and this CL is to add the support.
Note though, we don't currently use the Content-Base or Content-Location
headers for the session URI.
PiperOrigin-RevId: 384649818
Also rename hasPrevious/Next to hasPrevious/NextWindow for consistency.
This makes it clearer what the difference between
seekToPrevious/NextWindow and seekToPrevious/Next is.
PiperOrigin-RevId: 384643373
Applications may need to pass a non-visual context when creating
a DefaultTrackSelector (e.g., because they're audio-only or are
creating the selector in a background service).
Obtaining the default display via DisplayManager avoids the strict
mode violation that occurs when retrieving it via WindowManager.
#minor-release
PiperOrigin-RevId: 384487363
Most of the super-interfaces are deprecated, but the intention is that
only the types are deprecated and the methods themselves shouldn't be.
In order to reflect this in javadoc we override all the methods in
`Player.Listener` in order to 'cancel' the deprecation.
This change deliberately doesn't override methods that are explicitly
deprecated with documented replacements (like
`Player.EventListener#onPlayerStateChanged`) - these should contine to
be marked as deprecated in javadoc.
PiperOrigin-RevId: 384253725
The types (open/close/read) does not provide extra information about the thrown
playback exception, and they are not utilized at higher levels.
PiperOrigin-RevId: 384219870
The parameters staying in DefaultTrackSelector are considered
too ExoPlayer specific to be part of the `Player` interface.
Those are:
- exceedVideoConstraintsIfNecessary;
- allowVideoMixedMimeTypeAdaptiveness;
- allowVideoNonSeamlessAdaptiveness;
- exceedAudioConstraintsIfNecessary;
- allowAudioMixedMimeTypeAdaptiveness;
- allowAudioMixedSampleRateAdaptiveness;
- allowAudioMixedChannelCountAdaptiveness;
- disabledTextTrackSelectionFlags;
- exceedRendererCapabilitiesIfNecessary;
- tunnelingEnabled;
- allowMultipleAdaptiveSelections;
- rendererDisabledFlags
Track selection override will be migrated in a follow up cl.
To avoid breaking backward compatibility,
`DefaultTrackSelector.Parameters` extends
`TrackSelectionParameters` and
`DefaultTrackSelector.ParametersBuilder` extends `TrackSelectionParameters.Builder`.
The change are thus transparent for clients.
Test are incomplete for now, as this is a relatively big cl, I though
the reviewer could give a first pass will the tests are completed.
PiperOrigin-RevId: 383767021
In order to avoid doing the classification in ExoPlayerImplInternal. Note:
This only makes the constructor change. The error code assignment will
happen in an immediately following CL.
PiperOrigin-RevId: 383397729
MediaItem.mediaId used to default to the content URI, but this changed:
cc26a92e07
Before the mediaId change linked above, a playlist of different content
all with the same ad URI would play the ads for every item. After the
change the ad would only play once (because mediaId == "" for every
item, so they're all the same). This change restores roughly the
original behaviour by always considering both mediaId and the content
URI.
#minor-release
Issue: #9106
PiperOrigin-RevId: 382763618
The serialization scheme used here is custom, it doesn't need
to be compatible with emsg-v0 or emsg-v1 (since
97183ef558).
This means that C.TIME_UNSET will propagate correctly through the
serialization.
#minor-release
Issue: #9123
PiperOrigin-RevId: 382762873
Without this annotation it seems that `SimpleExoPlayer` effectively
'un-deprecates' the method, specifically:
* A usage of these methods isn't flagged by Android Studio if the
declared type is `SimpleExoPlayer` (up-casting to e.g.
`ExoPlayer.VideoComponent` results in the warning showing up).
* The `SimpleExoPlayer` javadoc doesn't mention this method is
deprecated:
https://exoplayer.dev/doc/reference/com/google/android/exoplayer2/SimpleExoPlayer.html#addVideoListener(com.google.android.exoplayer2.video.VideoListener)
* The Metalava API output for `SimpleExoPlayer` doesn't show these
methods as deprecated.
PiperOrigin-RevId: 382756174
- Use `PlaybackException.ErrorCode` IntDef for `DataSourceException` error code
- Deprecate `DataSourceException.POSITION_OUT_OF_RANGE`
- All other changes are related to replacing the deprecated constant and
constructor
PiperOrigin-RevId: 382683522
In order to use it for error code assignment. Note that these DRM errors
could be thrown on API < 18 (from MediaCodec.CryptoException), which is
the reason we can't put the mapping in FrameworkMediaDrm.
PiperOrigin-RevId: 382512414
PlayerView and StyledPlayerView handled this in
onVideoSizeChanged but it can be omitted.
(e.g. if the player is MediaController)
PiperOrigin-RevId: 382340927
Currently when a HTTP POST request receives a 302, CronetDataSource will change the request method from POST to GET for the redirected request, and drop the post body. This aligns with the behaviours of many user agents, but our use case would like to keep the POST method and the post body.
org.chromium.net.UrlRequest.followRedirect also changes POST to GET for 302, so should be avoided here.
PiperOrigin-RevId: 381233011
A no-op change that changes the signature of the onChunkLoadError method of the ChunkSource. Implementors can get the exclusion duration directly from the LoadErrorHndlingPolicy instead of receiving it as an argument of the callback.
PiperOrigin-RevId: 381102935
No-op change that adds the @FallbackType IntDef and changes the signature of getBlacklistDurationMsFor(LoadErrorInfo) to getExclusionDurationMsFor(@FallbackType, LoadErrorInfo).
PiperOrigin-RevId: 381075496
Previously, a SocketTimeourException is used to signal the end of the stream
that is caused by "no RTP packets received for a while". However, such
signaling is inappropriate under TransferRtpDataChannel, or FakeRtpDataChannel
in RtspPlaybackTests.
Hence, the signaling of end of stream is changed to use RESULT_END_OF_INPUT.
The RtpDataChannel implementations will Still block until a set timeout, but
will return a C.RESULT_END_OF_INPUT should a timeout occur, instead of
throwing a nested SocketTimeoutException.
This also allowed customization of the timeout amount, in
RtspMediaSource.Factory
PiperOrigin-RevId: 380981534
The current FLAG_REQUIRE_FORMAT documentation states: If an end of
stream buffer would be read were the flag not set, then behavior is
unchanged.
PiperOrigin-RevId: 380792251
The current FLAG_REQUIRE_FORMAT documentation states: If an end of
stream buffer would be read were the flag not set, then behavior is
unchanged.
PiperOrigin-RevId: 380781976
After this change, multiple BaseURL elements are parsed, but the player still only uses the first BaseURL element appearing in the manifest and its corresponding availabilityTimeOffsetUs.
PiperOrigin-RevId: 380775256
The problem occurs when the primary media playlist URL switches
from one whose latest snapshot has not yet got the ended tag, to
one whose latest snapshot already has the ended tag. In this case:
- We trigger a redundant load of the ended playlist.
- When the redundant load completes,
MediaPlaylistBundle.processLoadedPlaylist detects that the
playlist is unchanged from the one it already has, and so
doesn't call onPlaylistUpdated.
- PrimaryPlaylistListener.onPrimaryPlaylistRefreshed is never
called with the new primary. Hence the externally visible primary
is still the one that hasn't ended. HlsMediaSource therefore thinks
the event hasn't ended, which in turn prevents the player from
transitioning to the ended state.
This commit detects when the new primary already has the ended tag.
In this case, we call onPrimaryPlaylistRefreshed directly and remove
the unnecessary playlist load.
Issue: #9067
#minor-release
PiperOrigin-RevId: 380680532
The glitches were introduced in:
https://github.com/google/ExoPlayer/commit/6c31e34528
The problem is that Listener.onEvents is called in a later looper iteration
than the listener methods that were previously used. This created a gap on
the main thread between the UI component dispatching a seek operation to the
player, and onEvents being called to update the progress bar's position.
At the start of this gap the progress bar is rendering the new position,
but its position member variable is still set to the old position. If the
progress bar is re-drawn by another message on the main thread within the
gap, it will briefly show the old position until onEvents is called.
There are multiple possible fixes to this, and the best one is probably to
modify ListenerSet to remove the gap. That's high risk though, so for now we
fix the flicker by always updating the progress immediately after the seek
is dispatched, in addition to when onEvents is called.
Issue: #9049
#minor-release
PiperOrigin-RevId: 380678388
This change parses the entire BaseURL element including DVB extension attributes, stores it in an instance of new BaseUrl class and puts it in a list of base URLs of the resulting Representation. The base url handling itself is still the same, which means that only the first base url is taken into account, just as before this change.
PiperOrigin-RevId: 380609495
Some server will wrongly insert duplicated attributes. We used to treat this as
a unrecoverable error, but it is better to treat the duplicated attributes in
an "over-writable" fashion like HashMaps.
Issue: #9080,
Issue: #9014
PiperOrigin-RevId: 380547079
The test prepare_withSupportedTrack_playsTrackUntilEnded
- sets up the supported AAC track with the RTSP server;
- uses RtpPacketTransmitter to send RTP packets from the server to the client;
- runs the player until the playback has ended, and
- asserts on the data RTSP has received and queued to the SampleQueue.
In the test, it was necessary to create a FakeUdpDataSourceRtpDataChannel. The
reason we cannot reuse TransferRtpDataChannel is, we rely on BlockingQueue.poll
timeout to identify the end of an RTSP stream, but the time out mechanism is
unstable in Robolectric. For example, when the timeout is set to 8,000 ms, the
actual timeout occasionally happens after 2,000,000 ms (in FakeClock).
PiperOrigin-RevId: 380528710
Also change to explicitly track the provisioning session, which makes
the code easier to reason about than always using the zero'th element
of the list.
PiperOrigin-RevId: 380181453
In prepare_withSupportedTrack_sendsPlayRequest(), the DESCRIBE includes two
tracks, one AAC and one MP4A-LATM. The test is run until a PLAY is sent, and
asserts on only one SETUP is sent (for AAC).
In prepare_noSupportedTrack_throwsPreparationError(), the DESCRIBE includes one
track: one MP4A-LATM. This format is not supported at the moment, so the player
will throw out an error, on which we assert.
PiperOrigin-RevId: 380131458
More information: go/checker-3130-lsc
Tested:
Some test failures are present, but the CL author has decided to mail the change anyway
PiperOrigin-RevId: 379622938
Note that this removes a workaround for malformed content, in which the
track_ID is set incorrectly. It's unclear there was sufficient reason to
implement that workaround, and so it's preferable to remove it, rather
than implementing the concept of unrecognized tracks, which would be
needed to keep it and to also fix this issue.
Issue: #9056
#minor-release
PiperOrigin-RevId: 379506261
As of [JDK-8247957](https://bugs.openjdk.java.net/browse/JDK-8247957), doclint
no longer supports html4.
Tested:
Some test failures are present, but the CL author has decided to mail the change anyway
PiperOrigin-RevId: 378819179
The size of rtspLoaderWrappers must match the number of tracks exposed by the
RTSP session (a track is exposed if its media description entry appears in
DESCRIBE's SDP response).
When retrying with TCP, the old code will start loading all exposed RTSP
tracks, regardless of whether they are selected.
The fixed code will only start loading selected tracks.
#minor-release
PiperOrigin-RevId: 377931030
The current code does not catch the IAE thrown when building a MediaDescription
or SessionDescription. This CL catches the IAE and propagates it as a
ParserException.
Issue: #9014.
#minor-release
PiperOrigin-RevId: 377544439
The old version's retry logic will not work if using authentication.
Specifically, we use the same authentication parameters from the previous
session, and the RTSP server will reject such parameter.
In this fix, we reset the authentication info on retry. Further, we retry the
last request on receiving a 401 Unauthorized, rather than sending out another
DESCRIBE request.
#minor-release
PiperOrigin-RevId: 377539711
After refactoring MediaCodecAdapter.Factory to create configured and
started MediaCodecAdapters in a single operation, the
AsynchronousMediaCodecAdapter does not need to have separate methods to
configure and start, so they are merged. The CONFIGURED state is
removed.
PiperOrigin-RevId: 377519117
Related to Issue: #8941.
RTSP message body's format is not regulated by the RTSP spec, meaning it can
use either CRLF or LF as its line terminator. The old code assumes every line
ends with CRLF (RTSP message and the message body); the new code will rely on
the Content-Length information to receive the bytes for the message body.
#minor-release
PiperOrigin-RevId: 377475565
`SurfaceTexture` provides a transform matrix with each buffer. Previously
gldemo ignored this but it is important to apply it to have the video render
properly.
The transformation matrix from the surface texture includes flipping so this
change removes the hard-coded flipping from `a_texcoord`.
Issue: #8992
#minor-release
PiperOrigin-RevId: 377271389
Related to: Issue: #9010
Profile-level-id (Format.codecs) can be generated from SPS if SDP does not
include it.
#minor-release
PiperOrigin-RevId: 377251211
Add the `needsReconfiguration` API on the `MediaCodecAdapter` interface so that `MediaCodecRenderer` can reconfigure the `MediaCodec` in case a `MediaCodecAdapter` needs to be reconfigured immediately after being obtained from the `MediaCodecAdapter.Factory`.
PiperOrigin-RevId: 376944334
A renderer is disabled (without being reset) in two situations:
* When transitioning into a period that starts with a discontinuity
* When stopping the player with setForegroundMode(true)
Before this change the behaviour of `MediaCodecRenderer` when disabled
(but not reset) depended on whether the content being decoded had an
associated `DrmSession`:
* For content without an associated DRM session the MediaCodec instance
was kept alive.
* For content with an associated DRM session, the MediaCodec instance
was released. This was to prevent the DRM session from staying alive
and continuing to make license refresh network requests while the
player was stopped in 'foreground mode'.
This change removes the second bullet, and keeps MediaCodec instances
alive in both the secure and insecure case. This will result in the
DRM machinery making occasional license refresh network requests (at
a frequency defined by the license policy) while the player is stopped
and in 'foreground mode'. This network usage is considered to be a
'limited resource' as described by the `ExoPlayer#setForegroundMode`
javadoc.
This means that switches between secure content (or between secure and
clear content when `MediaItem.drmConfiguration.sessionForClearTypes`
indicates a secure decoder should be used for clear content) should
keep the same video decoder, thus avoiding the 'black flash' that occurs
on some devices when switching the surface away from a secure decoder.
Issue: #8842
#minor-release
PiperOrigin-RevId: 376825501
This change introduces a third 'state' for `DefaultDrmSessionManager`:
It's been fully released (prepareCount == 0) but at least one of its
sessions is still active.
In this state new acquisitions are rejected (`(pre)acquireSession()`
calls will fail) but the machinery to support the existing sessions
(ExoMediaDrm and MediaDrmHandler) is kept until they're all released.
This change will allow us to remove the TODO in MediaCodecRenderer
that resolves Issue: #8842.
PiperOrigin-RevId: 376193952
In a follow-up change I will add an additional test to ensure these
events continue to be correctly handled when DefaultDrmSessionManager
has prepareCount==0 but a non-null ExoMediaDrm instance.
PiperOrigin-RevId: 376190225
This helps to remove old ad groups (e.g. those that fell out
of the live window) to keep the data size of AdPlaybackState small.
Also added this case to some existing unit tests to ensure it's
covered.
PiperOrigin-RevId: 376170653
This allows to decouple the data structure from the access. In
a future change, this allows to completely remove old ad groups
(e.g. for live streams where the number of groups would otherwise
grow forever).
Also move the time into the group itself for better encapsulation.
PiperOrigin-RevId: 376170408
Many of the setters are ignored unless others are set - this change:
* Lists these conditions exhaustively.
* Uses more concise language to avoid overshadowing the main details
of what the setter sets.
* Tweaks the language from 'is ignored' to 'shouldn't be called', to
open up the future possibility of throwing an error if these are
called without the 'required' setter also being present (see
Issue: #8957).
#minor-release
PiperOrigin-RevId: 376162385
The docs on setLicenseUri say it's optional, and it has been since
379cd8a04f
(which should have changed this javadoc too)
#minor-release
PiperOrigin-RevId: 376139158
Authentication sequence in RTSP:
- Server replies "Unauthorized" to our DESCRIBE request, and includes the
necessary information (i.e. realm, digest nonce, etc) in WWW-Authenticate
header
- After `RtspClient` receives the response, we
- Parse the WWW-Authenticate header, stores the auth info. The info is saved
for all further RTSP requests (that all need to carry authorization headers)
- send the second DESCRIBE request with the Authorization header.
#minor-release
PiperOrigin-RevId: 376116302
The method openSocket in RtspMessageChannel does not actually open a socket.
The 'open' term refers more to opening the message channel.
#minor-release
PiperOrigin-RevId: 375908999
The callbacks received RTSP messages and RTSP sending errors are now invoked
directly from RtspMessageChannel's internal threads. It's up to the handler
implementation to decide which thread to handle the messages.
#minor-release
PiperOrigin-RevId: 375908282
Previously, RTSP interleaved binary data is posted onto the playback thread
for handling, the playback thread then adds the received data to a queue.
A loader thread will later dequeue the data and process it.
In this CL, the binary data is sent through a separate listener, on
RtspMessageChannel's RTSP receiving thread.
#minor-release
PiperOrigin-RevId: 375907609
Currently acquireSession() fails with an NPE from
checkNotNull(exoMediaDrm). A follow-up change will result in exoMediaDrm
sometimes being non-null while prepareCount==0 (and in this case we
still want acquireSession() to fail).
preacquireSession() doesn't currently fail in a way the caller can
observe - the same NPE is thrown, but asynchronously and it doesn't
propagate out of the background thread. Throwing directly seems
preferable since it's a clear bug to be trying to preacquire sessions
from an unprepared/released manager.
PiperOrigin-RevId: 375906450
Unlike Assertions, the introduced method cannot be disabled and throws
a ParserException instead. This method is meant to replace regular
assertions (which throw RuntimeExceptions) which check input in the
parsing code.
PiperOrigin-RevId: 375085160
We need to avoid reading and skipping into preload chunks as they
may need to be discarded. The current code iterates over all chunks,
but this can be simplified by just checking the last chunk knowing
that the preload chunk must always be the last one.
As a result, we avoid calling getFirstSampleIndex on all chunks. This
is a bug since the method is not allowed to be called for chunks
that have been spliced in. This still leaves the smaller issue of
potentially calling this method for spliced-in preload chunks, which
will be solved separately.
Issue: #8937
#minor-release
PiperOrigin-RevId: 375053638
Preload chunks may still need to be discarded. However, we don't
currently support discarding spliced-in chunks. Thus, we need to
avoid loadng a preload chunk that needs to be spliced-in.
Issue: #8937
#minor-release
PiperOrigin-RevId: 374851661
This media source wraps another source and publishes a Timeline with
ads. The created MediaPeriods for ad and content are mapped back to
the original stream to allow seamless playback.
PiperOrigin-RevId: 374836091
There is a newly added condition to help advancing between SSAI ads
and content in case the ad group position or ad duration changed. The
condition currently doesn't check directly whether it's a SSAI
transition but relies on indrect signals. Making this more direct
helps to understand the purpose and avoid unintentional bugs where
this condition would apply in other cases too.
In addition, we need to exclude TextRenderer from the check because
its read position doesn't correspond to the actual decode position
since the decoding happens in the renderer itself (b/181312195).
PiperOrigin-RevId: 374835985
We can instead just save this information in MediaPeriodInfo, similar
to how we store whether the MediaPeriod is last in the timeline etc.
PiperOrigin-RevId: 374835918
It only covers MediaSession - MediaController
(Does not consider cases that either a legacy session or a legacy controller is involved)
Add PlayerInfo#Builder to clean it up.
PiperOrigin-RevId: 374785779
Notes:
- The only functional change is that createForRemote now assings ERROR_CODE_REMOTE_ERROR.
- createForSource still uses ERROR_CODE_UNSPECIFIED, even though it expects an
IOException. The reason for not using ERROR_CODE_IO_UNSPECIFIED is that the reason for
the error might not be IO. For example, malformed media, or BehindLiveWindowException,
which have non-IO error codes. So using UNSPECIFIED saves a later change in category.
PiperOrigin-RevId: 374390407
When working with SSAI ads, we need to easily convert positions between
the underlying stream and the media model that exposes ad groups. To
simplify this, we can add util methods (that are testable on their own).
In addition, we need an easy way to build AdPlaybackStates for SSAI
inserted ads. The metadata is obtained out-of-band and usually has the
ad group start and end times in the underlying stream only. Hence, we
also add a util method to add a new ad group based on this information.
PiperOrigin-RevId: 374369360
MediaSession default command state contains all
commands.
To avoid having to update MediaSession when a command
is added, allow to create a Commands.Builder that
starts with all commands.
PiperOrigin-RevId: 374183484
Make ForwardingPlayer implement Player and not extend BasePlayer so that
ForwardingPlayer forwards each Player method directly to the wrapped
Player instance.
PiperOrigin-RevId: 374161084
Fix bug where rubies and boutens are missing, tate-chu-yoko is rendered
incorrectly when SubtitleView.setApplyEmbeddedStyles(false). This method
should only affect styling elements and not remove any language features.
There are two main changes that need to be made:
1. Whenever we determine the next ad to play, we need to select a
server-side inserted ad even if it has been played already (because
it's part of the stream).
2. When the Timeline is updated in the player, we need to avoid changes
that would unnecessarily reset the renderers. Whenever a Timeline
change replaces content with a server-side inserted ad at the same
position we can just keep the existing MediaPeriod and also if the
duration of the current MediaPeriod is reduced but it is followed by
a MediaPeriod in the same SSAI stream, we can don't need to reset
the renderers as we keep playing the same stream.
PiperOrigin-RevId: 373745031
In Android 12 mutability flags have to be set on PendingIntents. If they are not, and the app targets Android 12, then the app will be crashed by the system.
PiperOrigin-RevId: 373427591
Content after ad groups currently always resumes at the ad break position (unless
overridden by a seek or similar). In some cases, media inserting ads wants to
specify an offset after the ad group at which playback should resume. A common
example is a live stream that inserts an ad and then wants to continue streaming
at the current live edge.
Support this use case by allowing ad groups to specify a content resume offset
and making sure that the content start position after the ad group uses this offset.
PiperOrigin-RevId: 373393807
NAT will block off incoming UDP connection because the router has no knowledge
of the necessary port mapping (the mapping is never set up because UDP is
connectionless).
The end result is, the UDP socket to receive RTP data will timeout. After the
`SocketTimeoutException` is caught, the following takes place to try streaming
with TCP (or, RTP over RTSP).
- `RtspClient` sends TEARDOWN to tear down the current session.
- `RtspClient` re-connect to the RTSP server.
- `RtspMediaPeriod` cancels all loading `RtpDataLoadables` (that are using UDP)
- `RtspMediaPeriod` constructs new `RtpDataLoadables` that use
`TransferRtpDataChannel`, and starts loading.
- Once the `RtpDataLoadables` are up and running, we are ready to receive.
`RtspClient` sends the SETUP requests.
- The rest of the flow is unchanged.
#minor-release
PiperOrigin-RevId: 373310774
The player already supports changing durations of periods and ads.
The only thing not yet supported is a change in ad break positions
which changes the duration of clipped content ending in an ad break.
Adding support for this requires updating the end position in
MediaPeriodInfo and changing the clip end position of the respective
ClippingMediaPeriod.
Issue: #5067
PiperOrigin-RevId: 373139724
RTSP interleaving enables RTP packets to be sent using RTSP's TCP connection.
The interleaving RTSP messages contain binary data only and always start with a
'$'. Normal RTSP messages contain line breaks (CRLFs) that indicate complete
lines.
#minor-release
PiperOrigin-RevId: 372990181
The method to handle Timeline updates currently uses
isAd() || isPlaceholder()
to trigger two things:
1. Using the existing requested content position as the content
position.
2. Re-resolving the content position from window to period in case
it changed since the last update.
The condition is correct for case (1) because ads must use the content
position (and not the position in the ad) and a placeholder period must
keep using the requested content position as well until the media
information is no longer a placeholder.
However, case (2) only needs to be done if the content position is
C.TIME_UNSET (to start at the default position) OR if the period is
still a placeholder and we want to re-resolve the position.
The case where re-resolution shouldn't be done is for ads with a non-
placeholder period and a concrete content position. This likely only
affects ads in live stream where the content position is currently
moving with the live stream instead of staying where it is.
PiperOrigin-RevId: 372929439
- Don't deprecate methods not deprecated in the base class and that
could one day be useful.
- Better document deprecation of other methods.
#minor-release
PiperOrigin-RevId: 372919080
The existing code results in flaky tests, where sometimes the write
fails (with "EPIPE (broken pipe)") and the exception propagates out
and causes the test to never complete and time out.
Swallowing the exception resolves this flakiness.
#minor-release
PiperOrigin-RevId: 372909415
First intention to support parsing MPEG-H 3D Audio in ExoPlayer is to
take advantage of parsing capability from MediaParser API in AOSP.
Just with this change ExoPlayer does't support decoding MPEG-H 3D Audio
but can support decoding either by adding decoder with an extension or
by using Android OS which has decoder capability with MediaCodec API.
It was originally introduced because it was guaranteed to be non-null
unlike the inherited field. But ExoPlaybackException.cause has been
nullable for some time, so there's no gain in not using the inherited
field.
PiperOrigin-RevId: 372329740
Also make future similar issues less likely by adding isPlaceholder
to the set method of Period (in case forwarding Timeline
implementations use this instead of just updating values selectively)
#minor-release
PiperOrigin-RevId: 372138523
Issues have been identified around
offload gapless track transitions blocking
the track timestamp.
Until those issues are root caused, this settings
allows to disable gapless offload completely.
PiperOrigin-RevId: 372081545
In RtpDataLoadable.load, the second UDP data source is opened on the port we
specify. If the port is already in use, a BindException is thrown.
#minor-release
PiperOrigin-RevId: 371319522
All `add*Listener` and `add*Output` methods are
deprecated in favor of `addListener`.
As for the class themselves `VideoListener` and
`AudioListener` are not used internaly by ExoPlayer,
`VideoRendererEventListener`
and `AudioRendererEventListener` are use in their
place.
As a result `VideoListener` and `AudioListener`
can be deprecated in favor `Listener`.
On the other hand `TextOutput` and `MedataOutput`
are used both in the player interface and internally in
renderers.
This means that those class can't be deprecated.
There usage in the public interface are indirectly
deprecated as their is no way to use them without
using the deprecated `add*Output`.
Thus it's not an issue that the class themselves are
not deprecated.
#minor-release
PiperOrigin-RevId: 371318268
Imported from GitHub PR https://github.com/google/ExoPlayer/pull/8858
Fix bug in text alignment inheritance where child does not correctly inherit ancestor's setting
@icbaker
Merge 70eb4bceb73b3f07e2f8d545b4fa7961189ac52a into 45616f916b
COPYBARA_INTEGRATE_REVIEW=https://github.com/google/ExoPlayer/pull/8877 from dlafayet:multirowalign-cue d942b50a40525fea5d11b35a33d3bbc512550960
PiperOrigin-RevId: 371306966
This change adds an API in the ForwardingPlayer to disable commands.
This is affecting what Player.isCommandAvailable() returns as
well as what is being advertised from the
EventListener.onAvailableCommandsChanged() callback.
For the callback case, the ForwardingPlayer needs to intercept the
callback. It does so by wrapping registered EventListener and Listener
instances, which resulted in some boiler-plate code. In addition, there
is logic on the wrapped listeners to avoid triggering a queued callback
if all listeners have been removed in the meantime. This includes the
case where new listeners are added while callbacks scheduled for the
removed listeners are still pending.
PiperOrigin-RevId: 371139703
Move VideoSize in the common module and have the Player return it.
`Listener` and `AnalyticsListener` `onVideoSizeChanged` are updated
with the old method deprecated.
`VideoRendererEventListener.onVideoSizeChanged` was also migrated to
`VideoSize` but the old method is removed, not deprecated.
This is because:
- apps calling/listening to this method is a rare and niche use-case.
- it would introduce hard to diagnostic issues where if only the caller
or the callee is updated to use the new method, the event will be lost.
This doesn't occur with the other 2 listeners as the caller is always
in ExoPlayer library and was updated to call both the old and new methods.
VideoSize is used everywhere except in `Format` as this would lead to
too much refactoring and backward compatibility breakage for little gain.
#minor-release
PiperOrigin-RevId: 371087419
Rating class should be in the same module as MediaMetadata.
Tested:
$ ./gradlew --stacktrace :exo-library-common:tDUT
$ ./gradlew --stacktrace :media2-session:tDUT
$ ./gradlew --stacktrace :media2-session-vct-current:cAT
PiperOrigin-RevId: 370902917
Session pre-fetching caused this ordering assertion to no longer be
always true. It should have been removed in
795ddfee40
#minor-release
PiperOrigin-RevId: 370880530
