*** Original commit ***
Pass startPositionUs into Renderer.replaceStream
Plumb this down into BaseRenderer.onStreamChanged and use it when
deciding whether to render the first frame of a new period.
***
PiperOrigin-RevId: 323447253
It's potentially confusing that this resets both position & limit, so
require callers to pass `limit` explicitly, or call setPosition(0)
if that's actually what they intended.
This makes enforcing the limit in an upcoming change slightly safer.
PiperOrigin-RevId: 323340485
This allows us to enforce the limit because the array can only be
reassigned through reset(byte[]) or reset(byte[], int) (which update
the limit)
PiperOrigin-RevId: 323339960
This removes Supplier, Function and Predicate. Consumer is kept because
Guava doesn't have an equivalent (Java 8 does, but we can't use that
yet).
#exofixit
PiperOrigin-RevId: 323324392
MP3 is last in the sniffing order now, so I think it's fine to do this
without worrying about impacting on other file types.
PiperOrigin-RevId: 322996771
We currently mix point-based systems with Comparable-based systems.
This switches all scoring to using Comparable and modernizes it by
using ComparisonChain.
Using Comparator chains is more maintainable than point systems because
the reader doesn't have to think about all combinatorial combinations
of points.
PiperOrigin-RevId: 322766278
These callbacks were only necessary to track the queue in AnalyticsCollector and there is no other known benefit of having them.
PiperOrigin-RevId: 322535274
This commit duplicates some code from the testutils module
in common test in order to break the dependency from testutils.
PiperOrigin-RevId: 322366013
This only manifests when turning ParsableByteArray#data into a getData()
method but I'm fixing it beforehand to avoid introducing changes into a
big refactoring change.
#exofixit
PiperOrigin-RevId: 322342497
The dependency is only used to create a dialog in
TrackSelectionDialogBuilder that is compatible with newer styling
options.
This dependendy adds over 500Kb to the apk (even if unused) and we
shoudn't force this on an app. Instead make the dependency optional by
automatically falling back to the platform version if the AndroidX one
doesn't exist.
Issue: #7357
PiperOrigin-RevId: 322143005
getExoMediaCryptoType will only return null for drmInitData == null and
track types for which placeholder sessions are not used. This change
will allow renderers to abstract themselves from format.drmInitData.
PiperOrigin-RevId: 322131219
Replace `type` with (optional) `mimeType` and add `keySetId` in
DownloadRequest. The DownloadHelper infers the downloading method (DASH,
HLS, SmoothStreaming or Progressive) from the content's MIME type and
URI.
PiperOrigin-RevId: 322117384
The logic to clear the playlist is currently duplicated in various
reset methods so that calls to player.stop(true) can clear the playlist.
This can be deduplicated by clearing the playlist as a seperate
operation that reuses the existing code.
PiperOrigin-RevId: 321578759
We currently try to call onAdPlaybackStarted even if the ad session
is not created yet and if not, we never call the callback afterwards.
Make sure to update and create the current session before trying to
send onAdPlaybackStarted.
As a result, we can merge updateSessions into the existing
handleTimelineChanged and handleDiscontinuity calls as they always
need to be called together.
PiperOrigin-RevId: 321383860
Float values are allowed to be > 0dbfs,
it is just not nominal as it will might
distort the signal when played without
attenuation.
This is also consistent with
[AudioTrack.write(FloatBuffer)](https://developer.android.com/reference/android/media/AudioTrack#write(float[],%20int,%20int,%20int)) that explicitly
allows it up to 3dbfs.
PiperOrigin-RevId: 321345077
The method has been called from two call sites in EPII triggered by EPII.updatePeriods(). The first call site was calling it when the MediaSourceList is empty or not yet prepared. This can be removed because if empty or not prepared no source ever could have thrown yet.
The second call site was checking for potential source refresh exceptions when queue.getNextMediaPeriodInfo() returns null when trying to getting the next loading period. Looking into all reasons for why the method returns null, none of them is caused by an exception of a media source. The reasons are:
- if we are at the last period of the timeline
- if the defaultPosition of the next period in the timeline is null (if the window.durationUs == C.TIME_UNSET or defaultPositionProjectionUs is projected beyond the duration of the window)
- if we are waiting for an ad uri to arrive (period.isAdAvailable(...) == false)
- if we are waiting for the ad group count to be updated (adCountInCurrentAdGroup == C.LENGTH_UNSET)
The above reasons are not caused by a source error and may be resolved when doSomeWork is called the next time. Hence it is save to remove the calls to maybeThrowSourceInfoRefreshError().
Beside this, an actual sourceInfoRefreshError will be reported by maskingMediaSource.maybeThrowPrepareError(), which is called each time doSomeWork() is called and the playing period is not yet prepared (EPII:L836). So the player is notified by source errors that way, which confirms removing the above calls is fine.
PiperOrigin-RevId: 321331777
Plumb this down into BaseRenderer.onStreamChanged and use it when
deciding whether to render the first frame of a new period.
PiperOrigin-RevId: 321175627
This change masks playbackInfo.periodId and playbackInfo.loadingPeriodId for operations which change these periods (set/add/remove sources and seeks).
Because this masking is reflected in the playbackInfo object, player attributes can be retrieved without the maskingXyz variables in EPI. This has the advantage that the playbackInfo object always reflects the public state of the player even when operations are still pending. The maskingXyz variables in EPI are only required for the deprecated use case of an initial seek in an empty timeline.
PiperOrigin-RevId: 321160092
In order to use DeviceInfo class in media2, this CL moves the class to
common module. It didn't move the other file in the same package,
DeviceListener, as it's for DeviceComponent but media2 SessionPlayer
doesn't have components as it is already flattened. PlayerCallback will
have equivalent methods of DeviceListener.
PiperOrigin-RevId: 321154997
The method currently advances the read position and returns the number
of skipped samples. This prevents checking how many samples are skipped
before the operation is executed.
Instead, we have a new method that returns the number of to be skipped
samples and a skip method that executes the skipping.
PiperOrigin-RevId: 320953439
- DefaultAudioSink always supports floating point input. Make it
advertise this fact.
- Remove the ability to enable/disable floating point output in
FfmpegAudioRenderer, since this ability is now also provided on
DefaultAudioSink.
- Let FfmpegAudioRenderer query the sink to determine whether it
will output floating point PCM directly or resample it to 16-bit
PCM.
PiperOrigin-RevId: 320945360
CSS background-color isn't inherited to inner HTML elements by default:
https://developer.mozilla.org/en-US/docs/Web/CSS/background-color
But Android Span styling assumes an outer BackgroundColorSpan will
affect inner spans. This usually doesn't make a difference, because
HTML elements are transparent by default, so there's an implicit
inheritance by just being able to see through to the 'outer' element
underneath. However this doesn't work if the inner element sits outside
the bounding box of the outer element, e.g. <rt> (ruby text, sits above/below)
or a <span> with font-size > 100%.
END_PUBLIC
Demo of <rt> and font-size problems: http://go/cpl/ruby-backgrounds/1
Demo of CSS inheritance: http://go/cpl/css-inheritance/1
PiperOrigin-RevId: 320915999
Previously, the automatically selected subtitle track
has not been marked (with check mark) in subtitle track list,
just like audio track.
But, in subtitle track option UI, there is no 'auto' option,
which is different from audio track selection menu.
This CL marks the auto selected subtitle track name in the cc list.
PiperOrigin-RevId: 320802575
Sharing the Handler has led to it being accidentally used for purposes
beyond the original intention.
Instead for EPII -> EPI communication: Call methods directly on
ExoPlayerImpl that then post from the playback thread to the
application thread.
And for the MediaSourceList and Queue initialization, create a dedicated
Handler based on the same applicationLooper.
PiperOrigin-RevId: 320590527
Also flip DefaultDrmSessionManager#prepare()/release() into guard
clauses.
Suggestions from review comments on:
316f8a88cd
PiperOrigin-RevId: 320572462
AdDisplayContainer now takes the video ad player at construction time,
and obstructions are registered/unregistered via a new method. Also
'content complete' is now notified via ad callbacks rather than the
AdsLoader.
PiperOrigin-RevId: 320567666
DecoderCounters are reset in onEnabled, but the way the local
counters in MediaCodecVideoRenderers were reset assumed the
DecoderCounters were reset in onStarted.
PiperOrigin-RevId: 320440991
Building on the Format that was provided on the input side of the
decoder creates a format that's a mixture of the formats on the
input and output sides of the decoder. This change instead builds
a PCM format from scratch.
PiperOrigin-RevId: 320405656
The renderers are currently constructing formats that consist of their
input format with added PCM encoding. Such formats are not self-consistent,
and this only works because DefaultAudioSink ignores the rest of the
format if the format has a PCM encoding. It would not work if the sink
implementation checked the MIME type, for example, which wouldn't be a
strange or incorrect thing for it to do.
The more correct approach is to construct a new format that properly
represents the PCM that will be provided to the sink.
This change also renames supportsOutput to supportsFormat, because
AudioSink itself has both an input and an output side, and this method
is actually evaluating support on the input side of the sink.
PiperOrigin-RevId: 320396089
This is useful for subclasses to easily query the point up to which
they should only decode (but not render) content, rather than each
subclass having to have its own startPositionUs and update it in
onPositionReset.
PiperOrigin-RevId: 320163677
*** Original commit ***
Stop parsing unsupported WebVTT CSS properties
The spec lists an exhaustive list of CSS properties that should be
recognised, all others must be ignored:
https://www.w3.org/TR/webvtt1/#the-cue-pseudo-element
***
PiperOrigin-RevId: 320150427
*** Original commit ***
Rollback of 0943886cbd
*** Original commit ***
Use last queue format instead of previous decision to select new track
We currently use the save...
***
PiperOrigin-RevId: 320015109
*** Original commit ***
Use last queue format instead of previous decision to select new track
We currently use the saved selectionIndex to base our new track
selection decision on. This index might be stale if the previous
selection didn't result in a queue update (e.g. when loading live
streams where the new chunk isn't available yet).
Fix this by using the format of the last chunk to make the new decision.
Issue: #7582
***
PiperOrigin-RevId: 319991676
We currently use the saved selectionIndex to base our new track
selection decision on. This index might be stale if the previous
selection didn't result in a queue update (e.g. when loading live
streams where the new chunk isn't available yet).
Fix this by using the format of the last chunk to make the new decision.
Issue: #7582
PiperOrigin-RevId: 319957980
The wait time parameter is an implementation detail where we can just
provide a default.
In addition, we should also force the evaluation when the last chunk
in the queue changed to ensure it is always evaluated before starting
to load a new chunk.
Issue: #7582
PiperOrigin-RevId: 319949251
ExoMediaCrypto with the sole purpose of being unsupported. So all
renderers checking whether the type is supported will report
encrypted content as unsupported, unless the source producing
the format replaces it with a valid value.
PiperOrigin-RevId: 319824703
This is a partial revert of 0a2bacb7b7. I've added a comment
explaining why the code path is necessary after all, to avoid
future confusion.
PiperOrigin-RevId: 319822696
Clearing the exception puts the SimpleDecoder into a silent failure
state - the decoder thread is dead (because decode() has returned
false) but it's still possible to queue buffers to the decoder (they
just never get decoded). This partially reverts
4107375c9d
Also always recreate the decoder when handling an error in TextRenderer
This ensures we can try and decode a later subtitle sample after
encountering a decode error. This behaviour is what nulling out the
exception in SimpleDecoder.flush() was trying to achieve. We need to
ensure we don't start passing data to the new decoder until we've
hit the next key frame, so we throw away any non-keyframe samples
inside TextRenderer#render().
Issue: #7590
PiperOrigin-RevId: 319785908
We currently try to keep track of the playback queue (MediaPeriodQueue)
by listening to onMediaPeriodCreated/onMediaPeriodReleased events.
This approach has some problems:
1. It's easily broken by custom MediaSources that don't report these
events correctly.
2. We need to make some assumptions about what the order of these
events actually means. For example it is currently important that
the playing period gets released last in MediaPeriodQueue.clear()
3. We don't see batched events (like MediaPeriodQueue.clear()), so that
it is impossible to keep the "last reading period" for example. This
information is needed to correctly associate renderer errors to
periods after the queue has been cleared.
All of these problems can be solved by directly tracking the queue.
This also makes the onMediaPeriodCreated/Released/ReadingStarted events
obsolete and they can be removed in a future change.
PiperOrigin-RevId: 319739993
The current code only works if the tts:ruby attributes are defined
directly on the in-line elements. This changes that so we also consider
tts:ruby attributes on `style` nodes referenced by ID.
PiperOrigin-RevId: 319515177
We don't need the renderer immediately after stopping, so the
renderer should not throw a checked exception until it's used again.
This is inline with the not throwing from disable().
Also, none of the known implementation throw an exception at the moment
and all reasonable base classes omit the throws clause already.
PiperOrigin-RevId: 319503643
They are all for Context.getSystemService that is allowed to return
null. In most cases where we need to service, we make an assertion that
it is available.
PiperOrigin-RevId: 319503557
The test was incorrectly assuming that with LooperMode.PAUSE,
HandlerThread instances needed explicit calls to execute
tasks. This commit fixes the test flakiness by manually pausing the
HandlerThead when needed.
PiperOrigin-RevId: 319411552
Without checking if getFramesPerEncodedSample fails,
the frame count becomes negative which leads to
hard to debug errors.
PiperOrigin-RevId: 319247618
Passthrough mode can use a codec or not, but
the code only mentioned "passthrough" in most cases,
making the specific mode confusing.
For example both `MediaCodecRenderer` and
it's derived class `MediaCodecAudioRenderer`
had a private `passthroughEnabled` field,
but they were used for the opposite modes!
This change renames all relevant variables/functions
to explicit `CodecPassthrough` or `Bypass`.
PiperOrigin-RevId: 319225235
The system services may return a null value if the service is
not available. Guard against this by falling back to default values.
PiperOrigin-RevId: 319187882
Issue: #7011
Issue: #6725
Issue: #7066
This also mitigates (but doesn't fix) Issue: #4133 because it
prevents a second key load after a short clear section.
PiperOrigin-RevId: 319184325
SampleStreams should always provide samples starting from a keyframe.
We do not have equivalent logic in any of our extension decoder renderers.
PiperOrigin-RevId: 319012365
The list of MediaSourceHolder in ExoPlayerImpl is only maintained to be able to create a PlaylistTimeline for masking. By keeping only the id and a snapshot of the timeline of the MediaSourceHolder in ExoPlayerImpl, parallel access is prevented and we still have sufficient information to create the masking timeline.
PiperOrigin-RevId: 319003837
We can't restore the previous state of the remaining chunk, so we can't
support discarding from spliced-in chunks. Mark this explicitly instead
of attempting to discard from the previous chunk.
PiperOrigin-RevId: 318983628
This fixes an issue where, even if captioning manager is disabled, the latest used captioning manager preference
related to text size is being applied.
In order to replicate:
1. Go to Captioning Preferences under device Settings and enable it
2. Change the text size to "very large"
3. Observe the selected text size is used for subtitles, for example in Youtube
4. Go to Captioning Preferences under device Settings and disable it
5. Observe the text size used for subtitles does not come back to normal, stays on "very large"
- Deprecate constructors that don't take an executor, to direct
developers toward the new ones. Callers can trivially pass
Runnable::run to one of the new ones if they want old behaviour.
- Add comment explaining warning suppression added in the CL that
added parallelised download support.
Issue: #5978
PiperOrigin-RevId: 318803296
This enhances readability, particularly as those methods will become
more complex when partially fragmented media will be supported.
PiperOrigin-RevId: 318795536
Previously only pcm encoding were stored in Format,
this was an issue as for audio passthrough and offload
lots of code needs to pass complex format informations
(encoding, sample rate, channel count, gapless metadata)
but could not use Format and each function was taking
each as different parameter.
By allowing Format to contain any encoding, and not only
pcmEncoding, it allows to pass a Format everywhere in ExoPlayer
code that needs a Format.
This patch does not have any functional change. It is only an internal refactor.
PiperOrigin-RevId: 318789444
Gapless offload is fixed in later R beta builds of all Pixels supporting R.
On the firsts R beta builds of Pixel 4, run the following command.
`setprop vendor.audio.offload.gapless.enabled true`.
It can not be enabled on the first Pixel 2 and 3 beta build.
PiperOrigin-RevId: 318436134
This it is enabled only on a list of
manually tested devices.
The list is empty in this CL.
*** Reason for rollforward ***
Fixed dependent cl was rolled forward.
*** Original change description ***
Rollback of 962e08d3be
*** Original commit ***
Add Offload gapless support
Confirmed to work on a Pixel 4 after enabling the feature:
`setprop vendor.audio.offload.gapless.enabled true`
***
***
PiperOrigin-RevId: 318433123
*** Reason for rollforward ***
Fixed dependent cl was rolled forward
*** Original change description ***
Rollback of 2aac0717d7
*** Original commit ***
Propagate format in supportsOutput
It is needed to know if gapless is needed,
as gapless offload might not be supported.
***
***
PiperOrigin-RevId: 318429321
*** Reason for rollforward ***
Rollforward after making sure the handler is created,
and that a test is written preventing a
similar regression.
*** Original change description ***
Rollback of b6f5a263f7
*** Original commit ***
Rollforward of commit 5612ac50a3.
*** Reason for rollforward ***
Rollforward after making sure the handler is created
from the playback thread and not from an app thread.
*** Original change description ***
Rollback of e1beb1d194
*** Original commit ***
PiperOrigin-RevId: 318274400
Ignore two tests in AsynchronousMediaCodecBufferEnqueuerTest
until the ShadowMediaCodec's behavior is updated to apply
input buffer ownership.
PiperOrigin-RevId: 318251859
The existing code moves a multi-line cue box by multiples of the height
of the whole cue box (incorrect), rather than multiples of the first
line of text (correct). These two are equivalent for single-line cues,
which is why I didn't initially spot the problem.
PiperOrigin-RevId: 318036793
Numerical lines conceptually map to a grid of lines in the viewport,
with the Cue text lines being aligned to one of the viewport lines.
It doesn't make sense to position a single-line cue differently based
on lineAnchor when it's expected to 'snap' to a particular line on the
viewport grid. So we redefine the position to be in terms of the cue
lines rather than the bounds of the cue box.
It's also not possible to always handle ANCHOR_TYPE_MIDDLE when
lineType=NUMBER (as it relies on the number of lines in the cue being
odd), so it's easier to ignore lineAnchor completely.
PiperOrigin-RevId: 318034664
This removes a lot of duplication from the module configuration,
avoids divergence, and makes sure that only the important differences
to the default are visible in each module file.
PiperOrigin-RevId: 318024823
Postrolls would be skipped because the period duration wasn't know at
the moment of resuming playback after backgrounding, so the position
wouldn't be resolved to resume the postroll ad.
We have the period duration stored in the AdPlaybackState, so we can
use that directly.
Issue: #7518
PiperOrigin-RevId: 317830418
They currently fall back to the main Looper if the current thread
doesn't have a Looper. All the changed Handlers are guaranteed to
be created on a thread with a Looper (mostly the ExoPlayer playback
Looper) and thus can make this stricter assumption. This makes it
easier to reason about the code as there are no ambiguities as to which
thread the Handler is running on.
PiperOrigin-RevId: 317334503
The setForeground mode method blocks in the same way as release
and should use the same timeout if configured.
In case the method runs into the timeout, a player error is reported.
PiperOrigin-RevId: 317283808
*** Original commit ***
Rename Util methods to clarify which Looper is used.
The method name didn't clarify that either the main or current
Looper is used.
***
PiperOrigin-RevId: 317283606
- It seems conceptually simpler for DefaultExtractorsFactory
- It seems unlikely we'll need to diverge the two. In the case of
workaround flags we can just have them be no-ops in the version
that doesn't need them.
PiperOrigin-RevId: 317151955
Looks like this change was introduced in
<unknown commit>
onKeysRemoved is currently not triggered in DefaultDrmSessionManager
as far as I can tell. It seems like it should be called from here.
PiperOrigin-RevId: 317072794
It seems more natural given we always end up instantiating a Matroska extractor,
not one that's specific to the WebM subset of Matroska. There's also no reason
not to support Matroska MIME types in DASH.
PiperOrigin-RevId: 316975451
*** Original commit ***
Rollforward of commit 5612ac50a3.
*** Reason for rollforward ***
Rollforward after making sure the handler is created
from the playback thread and not from an app thread.
*** Original change description ***
Rollback of e1beb1d194
*** Original commit ***
Expose experimental offload scheduling
Add a new scheduling mode that stops ExoPlayer main loop
when the audio offload buffer is full and resume it...
***
PiperOrigin-RevId: 316914147
*** Reason for rollforward ***
Rollforward after making sure the handler is created
from the playback thread and not from an app thread.
*** Original change description ***
Rollback of e1beb1d194
*** Original commit ***
Expose experimental offload scheduling
Add a new scheduling mode that stops ExoPlayer main loop
when the audio offload buffer is full and resume it when
it has been partially played.
This mode needs to be enabled and dissabled manually by the app
for now.
#exo-offload
***
***
PiperOrigin-RevId: 316898804
