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
Ads can appear due to asynchronous ad tag requests completing after
earlier ads in a pod have loaded, so remove the requirement that the
ad count can't change. The MediaPeriodQueue should handling discarding
buffered content if an ad appears before already buffered content, so
I think this case is actually handled correctly by the core player
already.
Also remove the requirement that an ad URI can't change. This is a
defensive measure for now, but it's likely that a later fix in the IMA
SDK for an issue where loadAd is not called after preloading then
seeking before a preloaded ad plays will result in loadAd being called
more than once, and I think it's possible that the second call to
loadAd may have a different URI. Because the ad URI should only change
after an intermediate seek to another MediaPeriod, there shouldn't be
any problems with buffered data not getting discarded.
Issue: #7477
PiperOrigin-RevId: 316871371
The test was trying to synchronize a background decoding thread by
waiting for pending decode calls. However, the background thread needs
to fully queue the newly available output buffer before we can stop
waiting to ensure it's actually fully predictable. So we change the
pending wait to wait until the input buffer is cleared, which only
happens after the decoder is definitely done with it.
Also properly clean-up decoder (including shutting down the background
thread).
PiperOrigin-RevId: 316870659
- Leaving the TODO, since there are still MIME types we're unsure about.
- Removing AAC because xHE-AAC does not have this property. We may re-add
it with an additional profile check to exclude xHE-AAC in the future.
PiperOrigin-RevId: 316715147
We haven't seen it used anywhere in practice. It's a niche feature not
supported by any other extractors, and is one of the very few things
stopping us from simplifying MediaSource implementations to not set the
decodeOnly sample flag. This is a simplification that we want to make,
since the current mechanism doesn't work properly for cases where a
downstream decoder adjusts the buffer presentation timestamps so that
they're different on the output side than on the input side.
PiperOrigin-RevId: 316712302
This flag isn't needed anymore because the waiting for keys happens on
the source side and the source just returns NOTHING_READ under the
same conditions.
PiperOrigin-RevId: 316704214
We started using this method from other tests unrelated to
TestExoPlayer, so the method is better placed inside a generic Util
class.
PiperOrigin-RevId: 316675067
This change adds MediaSource.getMediaItem and deprecates MediaSource.getTag. For backwards compatibility, the tag is made available through the Window with `mediaItem.playbackProperties.tag` as well as in the deprecated `tag` attribute.
PiperOrigin-RevId: 316539752
Using the default offset as a magic constant makes tests hard to
understand. Improve that by looking up the value from the timeline or
setting it explicitly in multiple places, so the relationship becomes
clear.
PiperOrigin-RevId: 316421977
The correct order of initializing the MediaCodec should be (as per
documentation
https://developer.android.com/reference/android/media/MediaCodec#initialization)
"create -> setCallback -> configure -> start"
but the MediaCodecRenderer currently does
"create -> configure -> setCallback -> start"
MediaCodec implementations did not complain about this so far, but the
wrong sequence does not work with the MediaCodec in block mode (new mode
in Android R) and also the ShadowMediaCodec won't operate in
asynchronous mode otherwise. To initialize the MediaCodec in the correct
order, this commit adds configure() in the MediaCodecAdapter so the
MediaCodecRenderer can do:
adapter.configure(); // sets the callback and then configures the codec
adapter.start(); // starts the codec
PiperOrigin-RevId: 316127680
*** 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: 315948869
*** Original commit ***
Propagate format in supportsOutput
It is needed to know if gapless is needed,
as gapless offload might not be supported.
***
PiperOrigin-RevId: 315947888
*** 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: 315946947
The test uses two items with period-in-window offsets and a non-zero default start position. The test also prepares the first item lazily so
that the start position (and thus the renderer offsets) need to change.
This is arguably the most complicated setup that needs to be tested.
PiperOrigin-RevId: 315903958
The order of source info refresh and onPrepared was accidentally
changed by ed88f4f1dd. This changes it back to the correct order
and adds a test
PiperOrigin-RevId: 315885164
Rename the DedicatedThreadAsyncMediaCodecAdapter to
AsynchronousMediaCodecAdapter as it is the only asynchronous adapter
implementation left after the clean-up.
PiperOrigin-RevId: 315873431
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: 315860373
The option to cancel ongoing loads as part of the queue size evalation
was added recently. This split out the decision to a new method so that
a TrackSelection implementation can independently cancel loads and
discard upstream data. It also clarifies that evaluateQueueSize will
only be called if there is no ongoing load.
Issue: #2848
PiperOrigin-RevId: 315659735
If the previous chunk didn't finish loading, we need to find the appropriate
next chunk based on the current loading position (or the previous chunk's
start time if not independent).
PiperOrigin-RevId: 315658435
This change makes the media item argument in any constructors of the SinglePeriodTimeline non-null. Further a dummy media item is created for deprecated constructors using a tag only.
PiperOrigin-RevId: 315283842
ANSI/CTA-608-E R-2014 Annex B.5 says:
"The concept of a movable base row for a roll-up caption is new."
It means "new" compared to TC1 and TC2 (released in or before 1985).
Issue: #7475
PiperOrigin-RevId: 315258859
Output timestamps are calculated by the codec based on the buffers,
which is offset in Codec2. This adjusts the input timestamps as they
are passed in so they will match the output timestamps produced by
the MediaCodec.
PiperOrigin-RevId: 314963830
FakeMediaSource and FakeTimeline should put a media item to the window just as other media sources and timelines do. This change provides a fake media item for both of them.
Further the MaskingMediaSource needs to provide a media item for when the real timeline of the masked media source is not available. This can be easily done by using mediaSource.getMediaItem() once available. For now a dummy is used to make ExoPlayerTest run green. This can be easily change to use mediaSource.getMediaSource as soon as this method is defined by the MediaSource interface.
PiperOrigin-RevId: 314897474
bear_vorbis_gap.ogg is a copy of bear_vorbis.ogg with 10 garbage bytes
(DE AD BE EF DE AD BE EF DE AD) inserted before the second capture
pattern and 3 garbage bytes inserted at the end (DE AD BE).
Issue: #7230
PiperOrigin-RevId: 314715729
This change makes the media item of Timeline.Window non-null by providing a fallback media item in window.set(...). After having migrated all media sources this should not be needed anymore, but a fallback makes it more safe than just making the mediaItem argument of window.set(...) non-null (which is done in a following CL in this chain of CLs).
PiperOrigin-RevId: 314527983
Before loading a new chunk, the player will call reevaluateBuffer
anyway, so we don't have to do this directly after cancelation.
This simplifies some logic because we can remove the pending queue
size variable.
PiperOrigin-RevId: 314313268
If no deprecated methods on the factory is called, the media item instance that is passed to the createMediaSource method must be passed down to the constructor of the media source.
PiperOrigin-RevId: 314193865
This change applies the same approach of handling tag/streamKeys from factories like in the SmoothStreaming and Hls factories. It is functionally equivalent but improves readability.
PiperOrigin-RevId: 313771318
I was trying to understand why this isn't always checked and didn't
realise there was already a bug tracking this - this way a future
confused reader knows something isn't working quite as intended.
PiperOrigin-RevId: 313765935
If the sample times don't overlap and are independent, splicing makes no
difference because all samples (starting from the first one, which must be
a keyframe) will be appended to the end of the queue anyway.
PiperOrigin-RevId: 313594372
We aim to have the same media item instance published in the timeline that is passed to the createMediaSource(mediaItem) method. This means when the manifest uri is manually replaced by a developer, the media item published in the next timeline update is still the same.
Note: This leads to the fact that the manifest published in that timeline is loaded from a different URI than the URI of the media item in the same timeline.
PiperOrigin-RevId: 313375421
- The new CacheWriter is simplified somewhat
- Blocking on PriorityTaskManager.proceed is moved out of
CacheWriter and into the Downloader tasks. This is because
we want to shift only the caching parts of the Downloaders
onto their Executors, whilst keeping the blocking parts on
the main Downloader threads. Else we can end up "using"
the Executor threads indefinitely whilst they're blocked.
Issue: #5978
PiperOrigin-RevId: 313222923
Add an `_` in long constants.
Eg: 10000 => 10_000.
I'm proposing this change because I have had multiple
missread due to confusing the number of 0 in a long number.
More specifically, added an underscore to all number matching:
`final.*\ [0-9]{2,}000;`
PiperOrigin-RevId: 313186920
The test was flaky because it didn't wait for pending commands to finish
after pausing the test playback.
Also add more debug information to the toString() method because the
expected and actual state only differed in the nextAdGroupIndex in the
flaky case.
PiperOrigin-RevId: 313175919
Sometimes it's useful to be able to block until something on some other thread
"really has finished". This will be needed for moving caching operations onto
the executor in Downloader implementations, since we need to guarantee that
Downloader.download doesn't return until it's no longer modifying the
underlying cache.
One solution to this is of course just to not interrupt the thread that's
blocking on the condition variable, but there are cases where you do need to do
this in case the thread is at some other point in its execution. This is true
for Downloader implementations, where the Download.download thread will also
be blocking on PriorityTaskManager.proceed. Arranging to conditionally
interrupt the thread based on where it's got to is probably possible, but seems
complicated and error prone.
Issue: #5978
PiperOrigin-RevId: 313152413
Every timeline refresh currently assumes that it corresponds to a manifest
refresh and issues the respective load events. However, there are other
timeline updates that don't have a manifest refresh (e.g. ad state updates)and thus shouldn't issue these events.
PiperOrigin-RevId: 313150489
A recent change tried to make this condition clearer by using Integer.MAX_VALUE, but
this only works if the comparison also compares against larger values.
PiperOrigin-RevId: 312697530
The code that uses these variables is already commneted out. Android Studio
complains about unused variables and code and it's better to comment them
out as long as they are not used.
PiperOrigin-RevId: 312660512
This change adds an overloaded createMediaSource method which allows developers to pass in a media item with a in-memory manifest. Without this method the developer would not have a chance to pass in a non-dummy media item when using the factory for creting a DASH media source with an in-memory manifest.
PiperOrigin-RevId: 312660418
Previously if the AudioCapabilities reported that an encoding/channel count was
supported, DefaultAudioSink could try to play it via passthrough. However,
DefaultAudioSink does not support passthrough of every possible format (for
example, it's likely that AAC passthrough does not work given it's never been
tested and recent GitHub issues indicate that trying to use it leads to no
audio being played).
Add additional checks to make sure the encoding is in the list of encodings that
are known to work with passthrough in DefaultAudioSink.
issue:#7404
PiperOrigin-RevId: 312651358
*** Original commit ***
Remove set timeout on release() and setSurface()
Removes the experimental methods to set a timeout when
releasing the player and setting the surface.
***
PiperOrigin-RevId: 312647457
- To make it clear that cache keys are for whole resources
- To explicitly make it clear to implementors that deriving a cache key
from position and length is invalid. We've seen at least one developer
trying to do this [1], so it seems worthwhile to be explicit!
[1] https://github.com/google/ExoPlayer/issues/5978#issuecomment-618977036
Issue: #5978
PiperOrigin-RevId: 312643930
Guava is heavily optimized for Android and the impact on binary size
is minimal (and outweighed by the organic growth of the ExoPlayer
library).
This change also replaces Util.toArray() with Guava's Ints.toArray()
in order to introduce a Guava usage into a range of modules.
PiperOrigin-RevId: 312449093
This will replace the need to use CacheUtil.getCached, and is part of refactoring
CacheUtil to only do writing (it will be renamed to CacheWriter in a subsequent
change).
PiperOrigin-RevId: 312366040
- Remove scratchStyleMatches output parameter from WebvttCueParser.
- Switch from String[] to Set<String> for representing classes.
- In-line WebvttCssStyle.reset() since it's not used anywhere else.
PiperOrigin-RevId: 312249552
Added monitoring storage levels in RequirementsWatcher
Added dependency on extension-workmanager to the demo app to be able to test with WorkManagerScheduler
Added getSupportedRequirements method to Scheduler interface
Implemented getSupportedRequirements for schedulers
- The remove(DataSpec) method was confusing because it ignored
the DataSpec position and range, and instead removed all data
with a matching cache key.
- The remove(String) method seems better put directly on the
Cache interface.
PiperOrigin-RevId: 312113302
This is part of go/exoplayer-playlist-retrieval which aims for all MediaSources to associate the media item to the corresponding window. Media items need to be added to the timeline which then assigns it to the window.mediaItem attribute.
PiperOrigin-RevId: 312065023
The ad break time in seconds from IMA was "-1" for postrolls, but this didn't
match C.TIME_END_OF_SOURCE in the ad group times array.
Handle an ad break time of -1 directly by mapping it onto the last ad group,
instead of trying to look it up in the array.
PiperOrigin-RevId: 312064886
The new behaviour:
- If the session is successfully opened, an acquire event is dispatched
to all attached dispatchers.
- If acquire() is called but the session is already open, the acquire
event is dispatched only to the dispatcher provided in to acquire()
- If the session is successfully released, a release event is dispatched
to all attached dispatchers (in theory at most one should ever be
attached at this point).
- If release() is called but the session isn't released (because
referenceCount > 0) then a release event is dispatched only to the
dispatcher provided to release().
PiperOrigin-RevId: 312062422
Switch to snapshot Robolectric to pick up the latest version of shadows
required by MediaCodecVideoRendererTest and MediaCodecAudioRendererTest.
PiperOrigin-RevId: 312030332
Detect stuck buffering cases in ImaAdsLoader, and discard the ad group after
a timeout. This is intended to make the IMA extension more robust in the case
where an ad group unexpectedly doesn't load.
The timing out behavior is enabled by default but apps can choose to retain
the old behavior by setting an unset timeout on ImaAdsLoader.Builder.
PiperOrigin-RevId: 311729798
EventTime contains information about when an event happened and where
it belongs to. Both places can be fully described using timeline, window
index, media period id and position.
Right now, only the information for where the event belongs to is fully
contained in EventTime, whereas the time when the event happened only has
the position, and none of the other information (timeline, window, period).
This change adds the missing information, so that the EventTime can easily
be used without having access to the Player. This also ensures Event
metadata is self-contained and can be stored and reused later.
issue:#7332
PiperOrigin-RevId: 311727004
Some of the CSS font sizes are derived from the current view height, if
this calculation is done before the view has been measured then a zero
view height results in a zero px font size and no visible text.
This can happen when the view type is changed (and so the
WebViewSubtitleOutput has been recently added to the SubtitleView
ViewGroup).
PiperOrigin-RevId: 311552052
ANSI/CTA-608-E R-2014 spec defines exactly 32 columns on the screen,
and limits all lines to this length.
See 3.2.2 definition of 'Column'.
issue:#7341
PiperOrigin-RevId: 311549881
Some player setup steps that are likely to be only done once
should be moved into the Builder so that player setup can use
a consistent style (builder vs setters).
This also prevents some threading warning issues when the player
is built on a background thread (e.g. for dependency injection
frameworks) and setters can't be used due to threading restrictions.
PiperOrigin-RevId: 311487224
It displays images too, and in fact it's used exclusively to display
images in SubtitleWebView. It also doesn't use a TextView - so all round
a slightly confusing name.
Also rename SubtitleWebView to WebViewSubtitleOutput to match the same
pattern.
PiperOrigin-RevId: 311312758
This is useful for merging the FFmpeg video support pull request,
since it allows a Decoder base class implementation to catch
DecoderException rather than forcing it to catch Exception (i.e.,
everything). Note that unfortunately, Java doesn't allow catching
of a generic type (i.e., you cannot "catch (E e)") due to type
erasure.
PiperOrigin-RevId: 311300719
The only reason to require a context for creating an instance of
DefaultMediaSourceFactory is creating a user agent. DownloadHelper
has a bunch of static methods that need to instantiate a
DefaultMediaSourceFactory without a Context. By adding a setter for
the user agent we can remove that restriction and use a default user
agent.
PiperOrigin-RevId: 311291603
We aim for all SinglePeriodTimelines to set window.mediaItem and hence want to eliminate all constructors not passing a media item. The constructor removed in this CL is the easiest one to remove and fix in google3. It is still a breaking change for external ExoPlayer user who provide a custom media source with this timeline.
PiperOrigin-RevId: 311291493
It's very unlikely any onQueueInputBuffer implementations are looking
at the subsample encryption data, but from a correctness perspective
we should be passing a buffer object that's self-consistent.
PiperOrigin-RevId: 311011246
FFmpeg requires input buffers to be sized larger than the size
of the data they contain. This is to allow optimized decoder
implementations that read data in fixed size chunks, without
the risk of such decoders reading beyond the end of the buffer.
Issue: #2159
PiperOrigin-RevId: 310946866
We currently use the playback position in the current window, not the
position in the window the event belongs to. This creates confusing
outputs, e.g, window=1, mediaPos=100, even if the position refers to
window 0.
issue:#7332
PiperOrigin-RevId: 310896908
The tts:textAlign property only applies to <p> elements, which
correspond 1:1 with ExoPlayer Cue objects, so we can use
Cue.textAlignment to store this info instead of encoding it in
the span-styled text.
This will mean that TTML subtitles used with
SubtitleView#setApplyEmbeddedStyles(false) will start respecting
the tts:textAlign properties from the source data (currently this
information is stripped when we remove all span styling). I think this
is working-as-intended, we respect alignment of other subtitle types
(e.g. WebVTT) when applyEmbeddedStyles=false. We also respect all other
'positioning' related properties in this case e.g. Cue.position and
Cue.line.
PiperOrigin-RevId: 310895499
*** Original commit ***
Rollback of 70273a0361
*** Original commit ***
Assert incoming buffers are little endian in the DefaultAudioSink.
***
***
PiperOrigin-RevId: 310889382
When operating the MediaCodec in asynchronous mode, we are seeing
NPEs raised from the DefaultAudioSink because output buffers are pushed
to the DefaultAudioSink with the DefaultAudioSink not configured yet.
This is possible to happen if an output buffer is passed with
MediaCodecAudioRenderer.processOutputBuffer() before an output format
change.
One possible code path to trigger this is when an output format change
is pending and we flush MediaCodec (e.g. for a seek): the callback is
waiting in the looper's queue but we ignore all currently queued
callbacks after a flush().
This commit checks for a pending output format change during a flush():
if one exists, and the next MediaCodec output callback right after the
flush() is an output buffer (and not a new output format), then the
pending output format is propagated first.
The only adapter that needs to change is the
AsynchronousMediaCodecAdapter which previsouly deleted all pending
callbacks immediately on flush(). The AsynchronousMediaCodecAdapter now
needs to also handle every enqueued callback in order to identify is
there's a pending output format change.
Testing: added unit tests for the new code. I have verified that if we
pass an output buffer to the audio renderer before the output format, it
will result on the specific NPE, but I cannot reproduce the base
scenario (an output format change is pending when flushing) on a real
device because we can't know if an output format is indeed pending.
PiperOrigin-RevId: 310885283
We currently propagate only ColorInfo, but propagating the whole Format
is generally useful (e.g., to get the frame-rate on the output side of
the decoder).
PiperOrigin-RevId: 310359650
This allows properties to propagate when switching view types
(e.g. bottomPaddingFraction).
It also allows the style-stripping code to be pushed up to SubtitleView
and therefore shared.
PiperOrigin-RevId: 310353534
Fixes AsynchronousMediaCodecBufferEnqueuerTest broken tests by
enqueueing input buffers that have previously been dequeued from the
MediaCodec.
The test assumes that the shadow MediaCodec implementation can dequeue
at least 10 input buffers before queueing them back. Although fragile,
it seems to work with the current robolectric shadow MediaCodec. This is
at the moment preferred compared to making the test more complicated.
PiperOrigin-RevId: 310325096
Currently, DashMediaPeriod only takes into account as CEA-608 accessibility tags as embedded
closed captions tracks CEA-608. CEA-708 closed captions format is parsed when is present on
its own AdaptationSet, but not when is embedded as an accessibility tag in a video AdaptaticonSet.
Embedded CEA-708 support is added by parsing accessibility tags like the example below:
<Accessibility schemeIdUri="urn:scte:dash:cc:cea-708:2015" value="1=lang:eng;2=lang:deu"/>
<Accessibility schemeIdUri="urn:scte:dash:cc:cea-708:2015" value="1=lang:eng;2=lang:eng,war:1,er:1"/>
so it creates a new CEA-708 track for accessibility tags with schemeIdUri = urn:scte:dash:cc:cea-708:2015
and extract accessibilityChannel and language from value attribute.
Signed-off-by: Jorge Ruesga <jorge@ruesga.com>
Some part of the audio pipeline in the DefaultAudioSink
(PCM processors) are expecting little endian buffers.
As a result, in order to behave like MediaCodec,
make sure the passthrough MediaCodec-bypass pipeline
also processes little endian output buffers.
PiperOrigin-RevId: 310172464
This aligns mkv with mp4, flv and ts extractors.
This issue was found when AAC in an MKV container was not offloaded
as format.codecs was null.
PiperOrigin-RevId: 310170759
Previously the input format values were used,
but it could be incorrect if two format change were
occurring in quick successions.
PiperOrigin-RevId: 310142675
These methods operate on a thread-safe collection and are thus
inherently thread-safe. This simplifies some player setup configurations
where initial listeners are added on a background thread (e.g. when
using a dependency injection framework).
PiperOrigin-RevId: 310113181
Users of addTextOutput should instead query the current cues if they
need them. This is more consistent with how other listeners are handled.
PiperOrigin-RevId: 310112241
We currently have DecoderVideoRenderer and VideoDecoderRenderer, which
is very confusing! This one is package private, so we can rename it to
remove some of the confusion.
Also fix some nullness issues.
PiperOrigin-RevId: 309964088
In passthrough MediaCodec is not used except if
the format has a DRM.
Nevertheless the code was still requiring that a
passthrough decoder be present even if it was not going to be
used (aka no drm).
PiperOrigin-RevId: 309947271
- Fix DecoderAudioRenderer to re-init codec if the DRM session changes.
- Add canKeepCodec to DecoderVideoRenderer. Previously it was assumed
that the decoder could be re-used, but this will not be true in all
cases for FfmpegVideoRenderer.
Issue: #7079
PiperOrigin-RevId: 309935278
If the condition isn't fulfilled, they currently block until the
test runner times out the test. Our usual approach is to timeout
in the test itself so that the error message is clearly showing the
blocked condition.
Also clean-up some documentation.
PiperOrigin-RevId: 309930198
Now that MediaCodec is not use in passthrough, no
MediaCodec should be created in this mode.
Additionally, do not instantiate a MediaCodec in passthrough
#exo-offload
PiperOrigin-RevId: 309916131
With sample prepare (non-chunkless) the `Format` object in the TrackGroup is derived from the data in the stream and data in the manifest. This change includes the roleFlags from the HLS manifest parse in the final derived format.
DownloadManager doesn't know enough about the Downloader implementations to
know that interrupting the thread is the right thing to do. In particular,
if a Downloader implementation wants to delegate work to additional worker
threads, then it will probably not want its main thread to be interrupted
on cancelation. Instead, it will want to cancel/interrupt its worker threads,
and keep its main thread blocked until work on those worker threads has
stopped (download() must not return whilst the Downloader is still touching
the cache).
This change moves control over what happens to the individual Downloader
implementations.
Issue: #5978
PiperOrigin-RevId: 309419177
- Stop throwing InterruptedException from CacheUtil. When a CacheUtil operation
throws or returns, the caller should always check its own state to determine
whether they canceled the operation. If a caller is trying to catch
InterruptedException separately to IOException to do something different in
that case, they're probably doing the wrong thing. So it's simpler, and probably
less error prone, just to throw an IOException in the case of interruption.
- Throwing InterruptedIOException is also consistent with what our Extractor and
DataSource implementations do.
Issue: #5978
PiperOrigin-RevId: 309411556
We keep an index hint for the next pending player message. This hint
wasn't updated correctly when messages are removed due to a timeline
update.
This change makes sure to only use the hint locally in one method so
that it doesn't need to be updated anywhere else and also adds the "hint"
suffix to the variable name to make it clearer that it's just a hint and
there are no guarantees this index actually exists anymore.
issue:#7278
PiperOrigin-RevId: 309217614
testSubtitleEventTimes/IndicesHelper make assertions that only happen
to be the same because values in two different constants match up. It
seems much better to explicitly put the assertions in each test.
The other assert methods are just obscuring the underlying call to
Truth.
PiperOrigin-RevId: 309022044
Steps 4-10 of https://www.w3.org/TR/webvtt1/#cue-computed-line
This part is harder to fit into our code structure because it depends on
how many cues are simultaneously visible - so it has to go in
WebvttSubtitle not WebvttCueParser (which only deals with individual
cues in isolation).
This removes the `isNormal()` method that was trying to approximate
the correct behaviour.
PiperOrigin-RevId: 309021686
adPlaybackState is now non-null, and the uninitialized case is covered by a new
boolean hasAdPlaybackState. Position progress updates are now non-null and
initialized with IMA's VIDEO_TIME_NOT_READY constant.
Also fix some misc code issues:
- Remove empty branch for SmoothStreaming (Android Studio warns about this).
- Tidy onTimelineChanged and onPositionDiscontinuity and the methods they call
to improve naming.
- Remove logging for IMA events after release, as these methods are expected to
be called in the current IMA SDK behavior.
PiperOrigin-RevId: 308977116
The player's initial PlaylistTimeline has no ad cue points, so its first
MediaPeriodId has no nextAdGroupIndex. When the AdsMediaSource provides its
first timeline, the cue points become known. For the case where a preroll cue
point appeared, the preroll was detected due to isAd changing on the
MediaPeriodId. For the case where a midroll/postroll cue point appeared, the
MediaPeriodId was actually treated as the same, which leads to keeping the
unclipped original MediaPeriod.
Fix this behavior by checking for nextAdGroupIndex becoming set or decreasing.
PiperOrigin-RevId: 308974490
Its only real purpose is to encapsulate a download ID, but it doesn't actually save
any code, and arguably makes it more complicated by having multiple lists of
Downloader instances, indexed by key, and also because it's another (undocumented)
class to understand.
This CL retains the multiple Downloader lists, but they will be flattened in a
child CL.
PiperOrigin-RevId: 308838026
This is equivalent to the method ExoPlayer provides. It's nice for consistency,
and for retrieving the looper from test code.
PiperOrigin-RevId: 308830288
DownloadRunner.getDownloader was creating Downloader instances before the actual
DownloadManager under test would have created them. Tests were then asserting and
manipulating these Downloader instances, which is quite confusing. In particular
FakeDownloader.assertDoesNotStart() is an assertion on a Downloader instance that
only makes sense when called on an instance that DownloadManager would not have
created by itself.
This change replaces FakeDownloader.assertDoesNotStart() with an assertion on
DownloadRunner that no Downloader instance has been created.
PiperOrigin-RevId: 308822398
- Assertion chaining is generally discouraged. For example, because it's harder
to determine which assertion failed given a line number.
- Also removed chaining of the form obj.actionX().assertY(), because it's easy
for someone editing the test to accidentally delete actionX() when deleting
assertY(), where-as actionX() may often be important for subsequent assertions.
PiperOrigin-RevId: 308820503
- Remove assertReleased and replace it with a proper condition variable
that's opened when Downloader.download or Download.remove finish. As
far as I can tell assertReleased was basically implementing "sleep for
10 seconds after the Downloader starts". Note fixing this properly
also makes the tests run much faster!
- Use ConditionVariable instead of CountDownLatch(1).
- Use AtomicInteger instead of volatile int because it's clearer and
allows removal of explanatory comments.
PiperOrigin-RevId: 308819204
- Improve documentation explaining the benefits of ExoPlayer's ConditionVariable
over the one that the platform provides
- Allow Clock injection
- Create TestUtil method for obtaining a ConditionVariable whose block(long)
method times out correctly when used in a Robolectric test
- Add basic unit tests for ConditionVariable
PiperOrigin-RevId: 308812698
A previous change added these getters to CacheDataSource, but it can
also be useful to retrieve these components directly from the factory.
This is useful for tasks where we're going to need to build multiple
CacheDataSource instances (e.g., to make requests in parallel), and
also need to operate directly on the same components. It's a bit more
natural to retrieve them from the factory than from an arbitrary
CacheDataSource in this case, since it can avoid unnatural code where
you create a CacheDataSource instance earlier than you would otherwise
just to use its getters, and/or create one just to use its getters and
then throw it away.
PiperOrigin-RevId: 308606020
- Executor is a superclass of ExecutorService, so this is arguably a little
more flexible.
- It removes the need to use null for direct execution, because Runnable::run
is a direct executor that can be trivially used instead.
- Removing the error-prone "cannot be a direct executor" restriction in the
parallel version of SegmentDownloader requires not relying on the futures
returned from ExecutorService.submit() anyway.
Issue: #5978
PiperOrigin-RevId: 308586620
Currently, this method is only supposed to be called before removing
the listener from the player or when releasing the player.
If called at other times, it will throw an exception later when
a playback session is ended automatically.
issue:#7193
PiperOrigin-RevId: 308254993
The method is used to finish a brief "seeking" state that can be removed entirely
now state changes for seeking are masked.
PiperOrigin-RevId: 308237009
Unmarshal from json to MediaItem instead of Sample. Further the playlist
of MediaItems is converted to Intent extras which are read by the
PlayerActivity.
PiperOrigin-RevId: 308141231
While most ExoPlayer code parsing ByteBuffers is called with buffers in big
endian, in certain situation, buffers in little endian are used too.
MediaCodec produced ByteBuffers are in little endian, while buffers
receive from the sources are in big endian (ByteBuffer's default).
As a result, some code called from AudioSink in passthrough parsed
bytebuffer in little endian. This is not correct because those
format are specified in BigEndian.
Changing the endianness of the ByteBuffer returned from MediaCodec
would impact a lot more code that can currently be tested in the
current COVID lockdown situation.
As a result, this patch instead make the parsing code independent
of the ByteBuffer.order() set. All the code that is called from
DefaultAudioSink now parses the buffer explicitly in Big Endian.
Additionally, the MPEG big endian header data of size 4 bytes was
retrieved with ByteBuffer.get, which only returns one byte.
PiperOrigin-RevId: 308116173
The first session should only be created once we have the media items
and/or called prepare. Otherwise the first session is created with
an EventTime having an empty timeline making it less useful.
issue:#7193
PiperOrigin-RevId: 308100555
Part of what makes these tests hard to deal with (imo) is being
unable to easily run a specific config, or seeing exactly which one
failed (because you always see only the first failure).
I put the parameters as a method on ExtractorAsserts to
reduce the boiler-plate required in each test class.
I'll migrate the extension FlacExtractorTest in a follow-up CL
PiperOrigin-RevId: 307785380
Something that helps a constructor always seemed a bit strange.
It's now possible to use CacheDataSource.Factory directly instead.
PiperOrigin-RevId: 307661930
In the same way it made sense to tie CacheKeyFactory and CacheDataSource
together in
7ea83d7167,
it makes sense to tie the PriorityTaskManager to the CacheDataSource as
well. This prevents error prone scenarios where one can end up being
passed around without (or with the wrong instance of) the other.
This change also internalizes use of PriorityDataSource directly into
CacheDataSource, rather than requiring the caller to chain things
themselves.
PiperOrigin-RevId: 307647290
The sample timestamps are currently rounded to milliseconds, only to
be multiplied by 1000 later. This causes rounding errors where the sample
timestamps don't match the timestamps in the seek table (which are already
in microseconds).
issue:#7086
PiperOrigin-RevId: 307630559
This change generalizes the concept of "reading parameter sets" to
"reading prefix NAL units", ahead of a change that will treat AUD
and suffix SEI NAL units in the same way.
The change also introduces some static isXxxNalUnit methods for
clarity.
Issue: #7113
PiperOrigin-RevId: 307376967
Audio processors are now flushed twice after reconfiguration.
The second flush call cleared the pending trim start bytes so
transitions between tracks were no longer gapless.
Fix this by removing logic to clear pending trim bytes on flush.
As a result we may trim data incorrectly if there is a flush
before any data has been handled for seeking to a non-zero
position, but this edge case will happen rarely and the effect
shouldn't be noticeable.
PiperOrigin-RevId: 307344357
This is the missing attribute to support all features of the Sample with MediaItem. Hence PlayerActivity can use the setMediaItems() method directly without creating actual media sources in the app code.
PiperOrigin-RevId: 307102036
This makes it easier to use the helper methods because the player doesn't
have to be assigned to a SimpleExoPlayer in all cases.
PiperOrigin-RevId: 307039126
Update the comment on a suppression of Field.get(null) which is safe
but blocked by the checker.
These suppressions were introduced in d1e0572448
PiperOrigin-RevId: 307036441
We currently check for shouldContinueLoading, which is the intention to load,
not playbackInfo.isLoading, which is the actual loading state, when detecting
stuck buffering issues.
They only differ if the LoadControl said stop loading (based on nextLoadPosition),
but there is still a load in flight (updating bufferedPosition). This may cause
the exception to be thrown in edge cases that are only temporary.
PiperOrigin-RevId: 307022608
This is required to migrate the PlayerActivity away from Sample to MediaItem. It hence needs adding buildUpon to MediaItem to mix in the customCacheKey and streamKeys before playback.
PiperOrigin-RevId: 306710643
This is a more specific ViewGroup subclass that handles some of the
layout logic automatically. It's designed to work best with a single
child view, as used here.
PiperOrigin-RevId: 306654947
Even though they are annotated as non-null, Java users can pass in null values.
So we should verify the input to fail fast.
PiperOrigin-RevId: 306425487
This is the first CL for the offline qoe reporting
feature. Refer to the design doc for full information.
Design doc: go/exoplayer-offline-qoe
PiperOrigin-RevId: 305459231
Create a Builder that creates SimpleExoPlayer instances with fake
components, suitable for testing.
Basically extracts the Builder from ExoPlayerTestRunner to a standalone
class that can be re-used.
PiperOrigin-RevId: 305458419
This CL is a renaming only. It's mostly about finding a decent naming for the internal Playlist class. The plan is to have a public Playlist class in the converged Player API, so we need to rename the internal one.
PiperOrigin-RevId: 305266196
If we're in the ducked state and updateAudioFocus is called with a
new state for which focus is no longer required, we should restore
the player back to full volume.
Issue: #7182
PiperOrigin-RevId: 305232155
These were introduced in c7164a30a0
In each case I checked that the groups are not optional,
so if they match they must be non-null.
PiperOrigin-RevId: 305213293
This avoids cases where audio focus is never successfully acquired
because another app is holding on to transient audio focus indefinitely.
Issue: #7182
PiperOrigin-RevId: 305108528
When ClippingMediaPeriod first tried to read a buffer, if its end
position was before the end of the stream and it was buffered to its end
position, it would sometimes erroneously signal end-of-stream for
protected content because the sample queue might be waiting for DRM keys
at this point.
Work around the issue temporarily by signaling this specific case back
to ClippingMediaPeriod via the DecoderInputBuffer.
There will likely be a cleaner fix as a result of adding support for
dynamic clip end points in the future, at which point this can be
reverted.
issue:#7188
PiperOrigin-RevId: 305081757
It's interesting WebVTT explicitly handles line & position differently
in horizontal-rl/lr and vertical-lr/rl contexts. position is always
measured from the left of the viewport, even for rtl text, but line in
vertical-rl is measured from the right of the viewport.
We don't have to make Cue match WebVTT (I can go change the WebVTT
decoding instead) but it seems a reasonable 'default' to follow.
PiperOrigin-RevId: 304353900
ExoPlayer needs a codec to decide among WEBVTT and TTML decoder mimeType.
Apple describes IMSC1 in MP4 in
[RFC-8216 Section 3.6](https://tools.ietf.org/html/draft-pantos-hls-rfc8216bis-04#section-3.6).
The DASH manifest specifies the SMPTE-TT captions in the codecs in the manifest
(from W3C [TTML Profiles for Internet Media Subtitles and Captions 1.1](https://www.w3.org/TR/ttml-imsc1.1/#general-0).
DASH just doesn't require the rendition linking, but HLS does.
Apple implies the CODECS attribute of the variant needs to be do this. That is
with SHOULD and MAY language to imply the codec to use for it in the
[Authoring Guidelines](https://developer.apple.com/documentation/http_live_streaming/hls_authoring_specification_for_apple_devices)
This change defaults to WebVTT if no codec is specifed (same as current behavior) otherwise it picks it from the variants
referencing the media.
Without this, URL-encoding is assumed, which means ampersand-codes are
not carried through to the underlying web page correctly.
PiperOrigin-RevId: 304163733
HlsSampleStreamWrapper currently calls HlsMediaChunk.init, which calls back
to HlsSampleStraemWrapper.init. This re-entrancy seems a bit confusing.
PiperOrigin-RevId: 304139462
Selection of a passthrough codec will rarely (if ever) need to be customized, so
remove this capability from MediaCodecInfo.
Applications can still customize whether passthrough is used by overriding
MediaCodecAudioRenderer.usePassthrough, which now also checks for a passthrough
codec.
#exo-offload
PiperOrigin-RevId: 303964682
This is used to generate the initialization vector for encrypting the
cache contents.
Startblock:
<unknown commit> is submitted
and then
3w have passed
PiperOrigin-RevId: 303932151
This avoids massive changes to method signatures to add throws. Also, took suggestion to make it an `IllegalStateException`.
Move the catch outside of the finally that sets `nextLoadPosition` (this allows for possible recovery by reseting the `Extractor` and `TimestampAdjuster`).
Lastly, took the suggestion to make a minimum value for the tolerance (especially usefull for very short i-Frame only segments).
CharSequence is used by Notification builders and allows to set Spannable text.
It's the base interface of the String class, so apps wouldn't be break after
the update.
PiperOrigin-RevId: 303731890
This is required to align google3's stub (currently marked non-null) with Checker Framework's.
More information: go/matcher-nullness-lsc
Tested:
TAP train for global presubmit queue
http://test/OCL:303344687:BASE:303326748:1585344475427:29edc250
PiperOrigin-RevId: 303709053
- They are always listed with their canonical names
- Considering aliases means that blacklisting a decoder can end up
not actually blacklisting it, since it may still be accessible
via an alias. It also means that our decoder fallback logic can
end up falling back to a decoder that we've already tried!
PiperOrigin-RevId: 303348297
This callback will be deprecated, so moving all usages to better callbacks.
Some usages are still remaining that are less straight-forward to update.
PiperOrigin-RevId: 303298834
OnSeekProcessed is documented to be called as soon as all neccessary state changes
as a result of the seek have been made. As we now mask the state changes directly
when calling seekTo, we can also call this callback immediately without changing
the semantics of the method.
Our tests often use this callback as a way to wait for the internal player
to receive all pending commands and then report back. This is a special test
requirement for cases where we want to make sure no further updates happen as
a result of the player handling commands. To facilitate that, a new action is
added with a more descriptive name that achieves the same goal.
PiperOrigin-RevId: 303296210
This moves the playlist API methods to the Player interface. Implementation is moved from ExoPlayerImpl to BasePlayer where possible.
Further the CastPlayer is changed to implement the Player interface. Proper migration of the Playermanager to not use the ConcatenatingMediaSource anymore follows in a separate, future CL.
PiperOrigin-RevId: 302937779
Most of these are no longer needed since aa9eb5abc9
Cleanup change automatically generated by error-prone refactoring
//java/com/google/devtools/staticanalysis/errorprone:UnnecessaryJavacSuppressWarnings_refactoring on targets third_party/java_src/android_libs/exoplayer/v2/... java/com/google/android/libraries/exoplayer/v2/...
PiperOrigin-RevId: 302916092
This is less confusing than having audio processing functionality (e.g., playback
speed adjustment) just "not work" for some pieces of media.
If this change is merged, I will update #6749 to also track making DefaultAudioSink
intelligently enable/disable float output depending on how the audio processors are
configured.
Issue: #7134
PiperOrigin-RevId: 302871568
We currently have multiple places in ExoPlayerImpl that assign PlaybackInfo
instances and then inform listeners of all current changes. This is not ideal
because it causes multiple issues:
1. Some changes may easily be forgotten, e.g. there are clearly some checks
missing to see if isPlaying changed (e.g. in seekTo or setMediaSources)
2. Some callbacks didn't check if the value actually changed before sending
the callback (e.g. for the timeline change in setMediaSources - if the
timeline is still the same, we shouldn't send a onTimelineChanged event).
3. Having multiple callbacks in a single Runnable changes the order of
listener invocations slightly: Currently all events for one listener will
be send first before moving to the next listener. It should however send
a single event to all listeners first before moving to the next event.
All these issues can be solved by always using updatePlaybackInfo and never
assigning playbackInfo directly in another place.
Some tests needed to be updated as well because of issues (2) and (3). Also
added a new test to cover issue (1).
PiperOrigin-RevId: 302844981
It's incorrect to use an AudioFormat returned from AudioProcessor.configure
unless the AudioProcessor is active.
Issue: #7134
PiperOrigin-RevId: 302674132
This is a no-op for DefaultAudioSink for now, because DefaultAudioSink
currently disables processing anyway if the input uses ENCODING_PCM_FLOAT.
Issue: #7134
PiperOrigin-RevId: 302670534
androidTest of core already has the dependency on its main. Without this
exclude, gradle complains about type duplication when merging dex saying
"Type X is defined multiple times".
PiperOrigin-RevId: 302641585
If the start time of the edit falls within a sample, start from that
sample rather than the next one. This ensures playback can start from
the correct point if the sample is a keyframe, rather than having to
start from the next one.
Issue: #7133
PiperOrigin-RevId: 302639115
- Show renderers with no tracks in EventLogger track logging
- Log renderer names in EventLogger track logging
- Add useful message to ExoPlaybackException instances (including
renderer name for renderer errors)
PiperOrigin-RevId: 302421616
If MaskingMediaSource masks a multi-window media source, it may be that a period
is removed while we are using an initial unprepared masking MediaPeriod. That
means it's not guaranteed that a timeline update still contains our
unpreparedMaskingMediaPeriod and we should ignore timeline updates where the
period is no longer present because the it will be removed anyway.
PiperOrigin-RevId: 302383787
- This change also adds support for VideoFrameMetadataListener in the
AV1 renderer
- This is a preliminary step prior to adding FfmpegVideoDecoder
Issue: #2159
PiperOrigin-RevId: 301702460
This is a necessary step for Decoder implementations to support
audio and video. MediaCodecRenderer.DecoderException is renamed
MediaCodecDecoderException and extends the new DecoderException
Issue: #2159
PiperOrigin-RevId: 301698238
We have two known scenarios where the app could create an OOM error and
we want to handle it gracefully:
1. The app continues to allocate memory but doesn't make any progress
in the buffered position. OOM should be prevented by the default
load control and it should eventually throw an exception.
2. An extractor tries to allocate a large amount of memory on the
Loader thread based on information it read in faulty media files.
In this case we should attempt to play remaining media and then
throw an exception.
Both cases are already handled correctly, but we don't have any tests
ensuring that we don't introduce regressions.
PiperOrigin-RevId: 301585700
This removes a workaround that always continues buffering and instead
detects if the LoadControl returns false even though we don't have
any buffer. If enabled by a flag, this condition throws an exception.
PiperOrigin-RevId: 301584239
The restriction that these classes only work with SimpleDecoders
is unnecessary. An FfmpegVideoRenderer will not be able to use a
SimpleDecoder, because the SimpleDecoder assumption that each input
buffer can be decoded immediately into a corresponding output is
not true for all video codecs that Ffmpeg supports (e.g., H264 does
not have this property). Generalizing SimpleDecoderVideoRenderer to
DecoderVideoRenderer will allow FfmpegVideoRenderer to still use
the base class, without having to use a SimpleDecoder.
This is a preliminary change toward being able to merge a version
of https://github.com/google/ExoPlayer/pull/7079.
Issue: #2159
PiperOrigin-RevId: 301412344
The test is flkay (2/1000 runs) because the decoder initialization
before and after the seek are not perfectly deterministic. I couldn't
find a way to make them deterministic, so slightly chaning the test
setup instead. The test setup change doesn't affect the scenario being
tested.
PiperOrigin-RevId: 301390491
When no tracks are selected (or only tracks of unknown type), the
target buffer size is calculated to be 0. This means the player
won't request to buffer more data, nor can it start playback and
will be stuck forever.
PiperOrigin-RevId: 301374229
The assertion about the expected formats doesn't really belong in a
fake, the assertions should be closer to the test method.
This gets in the way when I try and write a new test in
AnalyticsCollectorTest that doesn't use the expected, constant Format
(because i want to specify drmInitData) - but changing the expected
Format is tricky because it's hard-coded into the FakeVideoRenderer
inner class.
I replaced the assertion in FakeRenderer with assertions in test
methods that used to assert on the format count.
PiperOrigin-RevId: 301353072
Previously calling removeListener would remove all instances of that
listener. Now it only removes a single instance.
This probably should have been part of introducing the Multiset:
2bd4d61b9b
PiperOrigin-RevId: 301191940
Without this change there's confusing behaviour if you pass e.g.
AnalyticsCollector (which implements both DrmSessionEventListener and
MediaSourceEventListener) to MediaSource.addEventListener: It will
receive DRM events too, even though you never passed it to
MediaSource.addDrmEventListener.
Also add some tests for MediaSourceEventDispatcher.
PiperOrigin-RevId: 301169915
This prevents OOM errors for high bitrate streams that attempt to fill
the buffer regardless of the memory usage.
Also change the max buffer sizes to ensure this is a no-op for video
streams < 20Mbps and audio streams < 260kbps.
Issue:#6647
Issue:#7006
PiperOrigin-RevId: 300720299
After this change users of ExoPlayerImpl and SimpleExoPlayer can use the media item base playlist API which converts the media item to a media source.
It adds the media item based methods to the ExoPlayer instead of the Player interface. This avoids a big change in the CastPlayer which requires migrating the cast extension to the MediaItem of the core module (follow up CLs).
PiperOrigin-RevId: 300575567
This CL removes the prefixes to the tests added after a6d0caaa3c.
This CL is generated by following command
$ find -name '*Test.java' | xargs -I{} sed -i 's/^\ \ public\ void\ test\([A-Z]\)\(.*\)$/ public void \L\1\E\2/' {}
PiperOrigin-RevId: 300547504
This avoids duplicate events being dispatched to object foo if
addListener(foo) is called more than once.
Part of issue:#6765
PiperOrigin-RevId: 300529733
We currently have the following logic to update renderers during
period transitions:
1. Wait for the currently reading period to finish reading all its
streams.
a. Advance reading period.
b. Set all streams that can't be replaced to final.
c. If streams can be replaced, replace them now.
2. Wait until playback position reaches the transition point
a. Disable all unneeded renderers (or those that need
re-enabling).
b. Advance playing period.
c. Enable all new renderers (i.e. all except the ones where
we replaced streams directly in step 1c.
This logic causes delays because steps 2a and 2c can easily happen
before 2b. Doing this allows a smooth transition for cases where
renderers change or where they need to be re-enabled.
The new order after this change is:
1. Wait for currently reading period to finish reading.
a. Advance reading period.
b. Set all streams that can't be replaced to final.
2. Update reading renderers iteratively.
a. If streams can be replaced, replace them asap.
b. If renderes need to be disabled, do so as soon as the
respective renderer ended.
c. Once step b is fully finished, enable or re-enable all new
renderers.
3. Wait unril playback position reaches the transition point AND
all tasks in step 2 are done (i.e. all renderers are set up for the
playing period).
a. Advance playing period.
As a nice side effect, decoder enabled and disabled events are now
always reported for the reading period, which is more consistent with
other renderer callbacks.
PiperOrigin-RevId: 300526983
This list was meant to simplify some usages where we only want to
make operations on enabled renderers. However, keeping this list
up-to-date is slightly error-prone (because renderers aren't added
and removed from this list next to the corresponding enable and disable
calls) and it makes it hard to do more fine-grained changes that only
enable or disabled a single renderer at a time.
PiperOrigin-RevId: 300513788
After this change MediaClocks and ExoPlayerImplInternal don't depend on the deprecated PlaybackParameter anymore but only know about playbackSpeed.
PiperOrigin-RevId: 300428791
This change deprecates the PlaybackParameters and remove the skipSilenceField from the PlaybackParameters. This implies that enabling and disabling skipping silences needs to be done on the Player.AudioComponent after this change.
After submission of the change, all Player API changes are done which are required to bring playbackSpeed and skipSilenceEnabled in the converged Player API state.
PiperOrigin-RevId: 300420843
In the HLS Spec (https://tools.ietf.org/html/draft-pantos-hls-rfc8216bis-04#section-4.4.3.6), specifically this or condition of this statement:
"... defined by the EXT-X-MAP tag, or is located between the start of the resource
and the offset of the first I-frame segment in that resource."
Change adds code to add this "implicit" Media Initialization Segment if no EXT-X-MAP defines one explicitly.
Pull in change to default to not use i-Frames for base AdaptiveTrackSelection.
The expectation is a subclases, that support transitioning to iFrame, will select these tracks.
This was a change suggested by @ojw28 to allow adpative track selection to work with IFrame only `Variant` as any other adaptive seleted `Track` in the `TrackGroup`. This actually works quite well with the exceptions that:
1. IFrame only tracks do not contain the same Rendition Group references as other non-iframe only varaints (so track selection should disable these tracks even in other non-video renderers.
2. Adapting to iFrame tracks only based on bandwidth might not be so good (as often larger spacial resolution iFrame track might have higher bitrate then lower spacial resolution non-iframe only track).
This change includes one proposed workaround in the AdaptiveTrackSelection class (only use iFrame for higher playback speeds).
Backout making the original `FormatAdjustingSampleQueue` an outer class and combining the new timestamp checking logic. This way the diff from `HlsSampleStreamWrapper` to dev-v2 are easier to see.
Update with code review suggestions:
1. rename to HlsCheckedSampleQueue to HlsSampleQueue and combine with format adjusting class.
2. Copywrite in added classes
3. Capture additional items useful for recovery and reporting in the exception class
4. Remove extraneous logging
5. eliminate magic number (50 seconds) and use percentage of duration
WIP:
- eliminate null check for chunk (chunkless prepare starts load before sampleQueue are created)
- work out recovery strategy
Add a SampleQueue subclass that checks the timestamp range of media samples queued to it and reports an exception on load if the timestamp is outside of spec bounds.
(Smashed to a single commit prior to rebase)
*** Original commit ***
Rollback of 949bbcfb2e
*** Original commit ***
Add masking for playWhenReady.
Masking is needed as soon as updates to a value can happen both in EPI
and EPII. PlayWhenReady is currently not masked because all updates
happen in EPI only. As soon as we allow pausing at certain times
(e.g. end of a stream), playWhenReady c...
***
PiperOrigin-RevId: 300330307
*** Original commit ***
Add masking for playWhenReady.
Masking is needed as soon as updates to a value can happen both in EPI
and EPII. PlayWhenReady is currently not masked because all updates
happen in EPI only. As soon as we allow pausing at certain times
(e.g. end of a stream), playWhenReady changes may be triggered by EPII
as well and that's why we need masking.
To know when the value actually changed, we also need to update the
internal state to include whether playback is supppressed.
***
PiperOrigin-RevId: 300303307
Masking is needed as soon as updates to a value can happen both in EPI
and EPII. PlayWhenReady is currently not masked because all updates
happen in EPI only. As soon as we allow pausing at certain times
(e.g. end of a stream), playWhenReady changes may be triggered by EPII
as well and that's why we need masking.
To know when the value actually changed, we also need to update the
internal state to include whether playback is supppressed.
PiperOrigin-RevId: 300284613
Exceeding the period duration may mean that that playback transitions
to another item even if the player is currently paused.
PiperOrigin-RevId: 300133655
There is no need for that, updating them is often forgotten and
takes up too much line space. Replace by a single TAG per test class.
PiperOrigin-RevId: 300113072
This change uses mime types in a functionally equivalent way to how we used the extension hint so far.
Using a mimeType instead of the extension has some advantages. Most importantly mimeTypes are used by the cast SDK with which we want to achieve interoperability in the cast extension.
Using a mimeType instead of the extension hint further appears to be a bit more clear (which might be opinionated). Further mime types are a well known and widely used concept to identify file type on the internet and it provides asterix based generalizations (audio/*, */*) which could express the media type OTHER that ExoPlayer is using internally (no usage of asterix required so far though).
PiperOrigin-RevId: 300058945
handlePrepare/Stop/SetPlayReady can be merged together as they all
handle changes to the desires state of the player.
Also, simplify parts of the control flow by not mixing code that
determines if audio focus needs to be handled with code that actually
acquires or abandons the focus.
PiperOrigin-RevId: 299824857
Without this option it's impossible to merge periods covering
different timestamps (at least not without playback issues).
Issue:issue:#6103
PiperOrigin-RevId: 299817540
The new version fixes some warnings in Gradle builds. Also
add missing indirect compileOnly dependencies to fix some more warnings
Issue:issue:#7007
PiperOrigin-RevId: 298855510
This option marks streams as final such that renderers play them out
completely, then waits until this happened, and then sets the player
to paused. After that, the player can continue to read the next period
to quickly resume playback if needed.
PiperOrigin-RevId: 298824745
Update it to allow any listener class to be registered (and thus
require the caller of dispatch() to provide the type of listener
to call).
Maintain MediaSourceEventListener.EventDispatcher as a sub-class
for now so that all existing references continue to work. This
avoids creating a huge diff in one CL. The intention is to in-line
these incrementally.
This is pre-work for issue:#6765
PiperOrigin-RevId: 298818198
The default Robolectric Looper simulation mode is changing to PAUSED from LEGACY.
The following tests fail in this new mode, and are thus being defaulted to LEGACY.
For more details see go/robolectric-legacy-looper-mode-lsc
Cleanup change automatically generated by error-prone refactoring
//third_party/android/androidx_test/tools/errorprone/java/androidx/test/tools/errorprone:LegacyLooperModeConverter_refactoring
Tested:
TAP train for global presubmit queue
http://test/OCL:297627974:BASE:298600828:1583273401491:7d94dbaa
PiperOrigin-RevId: 298809656
DashMediaSource is created with Manifest data and streamKeys can be empty given that streamKeys are only created out of MediaItem inside DashMediaSource, and this particular implementation don't extract them out of MediaItem properties.
Tested=Verified playback works.
PiperOrigin-RevId: 298550021
This change adds the createMediaSource(MediaItem mediaItem) method to the MediaSourceFactory interface. It doesn't deprecate createMediaSource(Uri uri) to keep the cl smaller. Deprecation and removing calls to the deprecated method from within the library and extension follow in a separate CL.
PiperOrigin-RevId: 298352442
The test had two problems:
1. It posts messages using a Handler and we need to idle the main looper
to actually deliver this message.
2. SimpleDecoder uses a background thread that is not within our control
from the test. Ensure the decoding happens after we queue input buffers
by using a lock.
PiperOrigin-RevId: 298300175
This is one step toward following the google3's test naming convention.
See go/java-testing/getting_started#basic-test-template for details
why prefix test isn't necessary.
This CL is generated by following command
$ find -name '*Test.java' | xargs -I{} sed -i 's/^\ \ public\ void\ test\([A-Z]\)\(.*\)$/ public void \L\1\E\2/' {}
and then manually modified following tests where test method names conflict with test target.
- VorbisUtilTest
- VorbisReaderTest
- UtilTest
- DownloadManagerDashTest
- DefaultOggSeekerTest
- OggPageHeaderTest
- HlsMasterPlaylistParserTest
PiperOrigin-RevId: 298074653
We should only ignore seek to the current position if we are
currently READY or BUFFERING. Also, pending initial seek positions
should only be saved while we have an empty timeline, independent of
the player state.
Issue:#6886
PiperOrigin-RevId: 297813854
This is more accurate since it's just a placeholder and none of the
values is provided by the media.
It also allows to fix a problem in ClippingMediaSource where we
couldn't detect a clipping error because we didn't know if the
timeline is a placeholder or not.
Issue:#5924
PiperOrigin-RevId: 297813606
When a new Timeline arrives in the Player, we check whether we can keep
existing MediaPeriods. This check currently involves a condition that
checks if the MediaPeriod is already prepared. The only reason we do
that is to avoid calling MediaPeriod.seekToUs, which is not allowed
on an unprepared MediaPeriod.
It's better to keep the MediaPeriod to prevent restarting the
preparation process. The prepration check can move further down to the
place right before we would call seekToUs.
PiperOrigin-RevId: 297812584
AnalyticsCollector keeps a list of existing MediaPeriodInfo that need
to be updated to new Timelines when they arrive. This already
happens in all cases except that the playingMediaPeriod wasn't updated
when it didn't change during the timeline update.
PiperOrigin-RevId: 297812038
The positions were interchangeably used with window and period
positions. This change more clearly ensures that all positions in the
AdPlaybackState are based on periods and that we use the right adjustments
for all usages.
PiperOrigin-RevId: 297811633
This removes noisy data from the dump files and allows updating less
dump files if a format field is added, removed or updated.
PiperOrigin-RevId: 297617138
Parallel asynchronous calls to MediaCodec.queueSecureInputBuffer() may
produce garbled video on some platforms. This workaround synchronizes
calls to MediaCodec.queueSecureInputBuffer() so that only one call is
in flight.
PiperOrigin-RevId: 297601037
This change adds the callback onSkipSilenceEnabledChange to the AudioListener and calls it when changed by the user by calling setPlaybackParameters, or when changed internally by the DefaultAudioSink if the parameters are not applicable. It needs to be plumped through AudioSink, AudioRenderer to SEP which eventually calls the AudioListener.
No changes to the Player interface so far. The getter of skipSilenceEnabled is added to SimpleExoPlayer for completeness, but not yet to the Player interface. The setter is not yet exposed, but implemented as a private method for implementation reasons.
PiperOrigin-RevId: 297590291
DefaultLoadControl applies the same min buffer duration to audio
and video. By default, min buffer is set equal to max buffer (50 seconds).
PiperOrigin-RevId: 297324489
Note: The dump files will need updating again when the extractors
are modified to only set the appropriate bitrate. Enhancing the
test first is nice, because it means that in subsequent CLs the
dump file updates can be used to quickly see what's changed in
the output.
PiperOrigin-RevId: 297188367
- Avoid having ExtractorHolder expose the underlying extractor.
- Make ProgressiveMP inject a DataSource instead of a DefaultExtractor.
This CL should introduce no functional changes.
PiperOrigin-RevId: 296944788
This change deprecates PlaybackParameter in AudioSink and splits it into playbackSpeed and skipSilenceEnabled. These properties are set separately in a future CL. The playback speed will be set through the MediaClock, while skipSilenceEnabled will be set by sending a message to the audio renderer.
PiperOrigin-RevId: 296457043
- Deprecate old Format.createXXX methods
- Deprecate most Format.copyXXX methods
- Stop using deprecated Format.copyXXX methods in the library
Note: Replacing library usages of Format.createXXX method
will be done in follow up CLs. These changes aren't purely
mechanical because we need to decide which out of peakBitrate
and averageBitrate to set in each case where currently a
single bitrate is provided.
Issue: #2863
PiperOrigin-RevId: 296450935
It's not clear why we're currently outputting the format in both init()
and consume() - it seems likely that this was accidentally introduced
in <unknown commit>
when we started outputting the format in consume() but didn't remove it
from init().
The SCTE-35 TsExtractorTest doesn't pass with the current code because
when it seeks back to the beginning of the file init() is not called
again so the second pass through only sees one sample (and
ExtractorAsserts checks that seeking back to 0 produces the same output
as reading the file from the beginning).
I generated the SCTE-35 sample using TSDuck's tsp command:
$ tsp --add-input-stuffing 1/10 \
-I file testdata/src/test/assets/ts/sample.ts \
-P pmt --service 1 --add-programinfo-id 0x43554549 --add-pid 600/0x86 \
-P spliceinject --service 1 --files scte_35.xml --wait-first-batch \
-P filter --negate --pid 0x1FFF \
-O file testdata/src/test/assets/ts/sample_scte35.ts
This was adapted from the instructions in section 5.2.24.1 of the TSDuck
user manual: https://tsduck.io/download/docs/tsduck.pdf
PiperOrigin-RevId: 296217084
Not important, but when overriding a method that can return null,
it seems preferable to put @Override first, followed by what it's
overriding (which includes the @Nullable).
Also remove explicit @NonNull use in the core library. @NonNull is
propagated by default, so this is redundant.
PiperOrigin-RevId: 296188379
This is one step toward following the google3's test naming convention.
See go/java-testing/getting_started#basic-test-template for details
why prefix test isn't necessary.
This CL is generated by following command
$ find -name '*Test.java' | xargs -I{} sed -i 's/^\ \ public\ void\ test\([A-Z]\)\(.*\)$/ public void \L\1\E\2/' {}
PiperOrigin-RevId: 296169886
When copying CryptoInfo for asynchronous input buffer queueing,
re-use the destination CryptoInfo's arrays to avoid re-allocating
memory.
PiperOrigin-RevId: 295706771
Note on UnknownNull: Where there exists a generically typed
base class and both null and non-null types are permitted,
we need to clear the default non-null that's otherwise
propagated everywhere. This then lets the nullness of the
type work properly.
PiperOrigin-RevId: 295582444
CryptoInfo.iv length is always 16. When the actual initialization vector
is shorter, zero out the trailing bytes.
Issue: #6982
PiperOrigin-RevId: 295575845
Previously, the input buffer accessUnit count
was passed as the output of the audio processors
which did not make sense as the processors can
split buffers.
This patch passes the access unit count through a
member variable.
PiperOrigin-RevId: 295572577
This is closer to how our actual renderers look like and allows tests
to use a similar logic to show/suppress the first frame in follow-up changes.
PiperOrigin-RevId: 295557548
We will eventually remove the workaround from ExoPlayerImplInternal
added in
b84bde0252
and replace it by an error that gets thrown if the LoadControl behaves
badly.
PiperOrigin-RevId: 295556131
Previously that was implicit, it was the passthrough dance:
- MimeTypes.getEncoding(inputFormat) did not
implement RAW MIME, so it was returning INVALID_ENCODING for PCM
- and allowPassthrough was returning
MimeTypes.getEncoding() != INVALID_ENCODING
- which was setting codecInfo.passthrough, and passthroughEnabled.
Thus Util.isEncodingPcm(encoding) is the opposite of
(MimeTypes.getEncoding(inputFormat) != C.ENCODING_INVALID)
This was rather implicit and brittle as anyone
could add support for audio/RAW in
MimeTypes.getEncoding and break PCM playback.
As a result make it explicit that allowPassthrough
must always return false in PCM.
PiperOrigin-RevId: 295144013
Modify TrackOutput.sampleData() to accept SampleDataReader instead of ExtractorInput. SampleDataReader supports only read and skip calls, which all sampleData() implementations already restrict themselves to.
PiperOrigin-RevId: 294905155
Currently only one access unit can be written per
buffer write. This has been found to be power
inefficient in an offload situation.
#exo-offload
PiperOrigin-RevId: 294886188
This information isn't easily available to the player at the moment (or it
would need to revaluate this every time), so add it to MediaPeriodInfo similar
to the existing isLastInTimelinePeriod.
The player needs to know whether a MediaPeriod is the last in its Timeline
window if we want to add an option to pause at the end of a window.
PiperOrigin-RevId: 294877628
Add fields in DecoderCounters for computing the average video frame
processing offset.
The MediaCodecVideoRenderer reports the video frame processing offset
and the demo app presents it on the debug information.
PiperOrigin-RevId: 294677878
The transition in EPII happens based on the duration of the periods, not
the windows. So use this duration in case they are not the same.
Also make sure to send the message at duration-1 because the playback position
at the duration is technically already the first position in the next item.
PiperOrigin-RevId: 294669335
This simplifies sending messages to the end of a stream. This was
already possible, but users needed to wait until the duration is known
before sending the message. This duration resolution can happen as part of the message position resolution.
PiperOrigin-RevId: 294626984
Issue #6853
Previously the body of an HTTP response was not included in an
InvalidResponseCodeException. This change adds a field to store
the response body, and updates DefaultHttpDataSource to populate
this value.
Language is already applicable to image formats as well.
It can also apply to video formats. For example when the
video contains burnt in subtitles. Also, some animation
studios produce multiple variants of animations, in which
text within the scene itself (e.g., a signpost) is
replaced to be language specific.
PiperOrigin-RevId: 294500227
- Replace tests specific to HTTP request headers with tests that
more generally test constructor correctness.
- Add test specifically around the constructor that infers the
HTTP method from postBody, since that's a non-trivial bit of
constructor logic.
Note: In general, I'm not sure this type of test (i.e., testing a
bit of trivial copying through a constructor) is worth the cost
of writing and maintaining them. That said, checking the new
uriPositionOffset is calculated correctly is non-trivial, as is
the HTTP method inference, so keeping them for now.
PiperOrigin-RevId: 294488684
This is a preliminary step toward adding a DataSpec.Builder,
which is needed for sanity when adding DataSpec.customData.
The existing absoluteStreamPosition field is very error prone,
because anyone using a Builder to adjust the request position
will need to remember to adjust two values:
dataSpec
.buildUpon()
.setAbsoluteStreamPosition(x)
.setPosition(x)
.build();
Furthermore, the difference between position and
absoluteStreamPosition is irrelevant in nearly all cases. In
the core library, the difference is only relevant when initializing
AES encryption/decryption to write/read cache files.
Replacing absoluteStreamPosition with uriPositionOffset will
simplify the code block above to:
dataSpec
.buildUpon()
.setPosition(x)
.build();
PiperOrigin-RevId: 294485644
Currently, the subset of audio tracks for adaptation is selected
purely based on the size of the subset in the track group, completely
ignoring the previously selected best individual track.
This change ignores all tracks with a different configuration than the
previously selected best track.
PiperOrigin-RevId: 294231806
While the window in which a message or a seek position is resolved is
still a placeholder, we need to re-resolve the position using the
user intent (i.e. the window position) when the timeline updates.
PiperOrigin-RevId: 293346360
The period in this method is most likely prepopulated correctly, but
this assumption is very error-prone and we should populate it locally.
PiperOrigin-RevId: 293345873
This allows to simulate samples in a stream more accurately
particularly when streams are prepared at a non-zero position and
issuing a sample with position=0 is not expected.
Also makes seek more realistic by also issuing one sample again.
PiperOrigin-RevId: 293344081
Once we receive an update from a masked source, we first start the
preparation of an already pending period, and only then notify the
player of the new timeline. If the period prepares immediately inline,
the MediaPeriod.onPrepared callback arrives before the
onPlaylistUpdateRequested call in the Player. THis is the wrong order
and causes issues when the player tries to lookup information in the
timeline that doesn't exist yet.
This change fixes preroll playbacks before live streams.
PiperOrigin-RevId: 293340031
The functional change is to set the bitrate fields to Format.NO_VALUE
in the case that they're non-positive in the header data. Else it's
very easy to to take the fields and copy them directly into Format as
incorrect values.
Issue #2863
PiperOrigin-RevId: 292920141
This change deprecates Player.onPlayerStateChanged(boolean pwr, int state). It removes deprecation for trivial cases. I'll remove other deprecated usages (mostly in ui module) in follow-up CLs to not bloat this CL.
PiperOrigin-RevId: 292917872
This condition is trying to detect when it might be necessary
to switch from a non-secure to a secure codec. This is not
possible if the DRM session is unchanged, unless a different
codec is required for some other reason (e.g., H264 -> H265),
which is anyway handled by canKeepCodec below.
PiperOrigin-RevId: 292909126
*** Original commit ***
Rollback of 3c56b113e4
*** Original commit ***
Rollback of d48dc4c159
*** Original commit ***
Move getting-stuck-prevention into DefaultLoadControl.
We recently added code that prevents getting stuck if the buffer is low and
the LoadControl refuses to continue loading (b84bde0252).
Move this logic...
***
PiperOrigin-RevId: 292457964
Passing EXT-X-KEY DrmInitData through the FragmentedMp4Extractor
doesn't work for streams with key rotation, because an extractor
instance is used for multiple segments, but is only passed the
EXT-X-KEY DrmInitData corresponding to the first segment.
This change removes passing DrmInitData through the extractor,
and instead passes it via FormatAdjustingSampleQueue. This is
in-line with how manifest DrmInitData is handled during DASH
playbacks.
Issue: #6903
PiperOrigin-RevId: 292323429
This is a nice-regardless improvement to SampleQueue, which will
likely to used to fix the referenced issue. It makes it possible
for SampleQueue subclasses to support dynamic changes to format
adjustment in a non-hacky way.
Issue: #6903
PiperOrigin-RevId: 292314720
Fix outline style subtitle
When a ForegroundColorSpan changes the foreground color, it is also applied
to the outline painter. In order to keep the correct color, one needs to
filter out theses span. We do this with a new cue that is our text source
for the specific edgeLayout.
Take care to only apply background color once
Test: Manual check - Subtitle view can show custom color subtitles from specific Subtitle
Renderer and outline is shown correctly using user defined color.
Calling setViewType with the same view type as the
subtitleView is using would throw InvalidArgumentException
instead of being a noop.
PiperOrigin-RevId: 291937202
We currently have 3 states, but the NOT_SET state isn't needed
anymore. We can therefore replace the IntDef by a simple boolean.
PiperOrigin-RevId: 291926049
We currently apply new parameter checkpoints from an absolute media
time and then substract the current media start time again to retrieve
the media time offset for this playback parameter checkpoint.
However, the media start time may change when unexpected discontinuities
happen (the start time doesn't actually change, but we change it to
correct for this discontinuity). This then invalidates the absolute
media time in the playback parameter checkpoints (which should have been
corrected as well).
Avoid this problem by also only applying the new start position
from the checkpoint. We don't have to save the start position anymore
because it will cancel itself out.
Also add some documentation and code clarification for improved
readability.
PiperOrigin-RevId: 291923069
SubtitleView now becomes a ViewGroup that owns a SubtitleTextView. It
handles some common styling defaults, but delegates the underlying
values down into SubtitleTextView through the SubtitleView.Output
interface.
When I add a SubtitleWebView this will also be a ViewGroup containing
a WebView and will implement SubtitleView.Output and convert Cue styling
into HTML & CSS.
PiperOrigin-RevId: 291903294
It doesn't seem worth keeping the cap, since the device
will presumably stop receiving major version updates at
some point anyway.
Issue: #6899
PiperOrigin-RevId: 291899439
This seeker is only seeking to frames that have already been read by the
extractor for playback. Seeking to not-yet-read frames will be
implemented in another change.
Issue: #6787
PiperOrigin-RevId: 291888899
We currently only keep the requested next content start position while
we are playing ads. However, we should also keep at least before a content
period is fully prepared to not loose the information about the user intent.
PiperOrigin-RevId: 291705752
There are existing bugs that need this flag to know whether the
current information in the window is still a placeholder or can
already be relied on for further calculation.
This flag will probably only ever be set in DummyTimeline, so it's
not added to the window.set method to avoid updating all clients.
Issue:#5924
PiperOrigin-RevId: 291705637
It could either live in .util or .extractor, but since it's not needed
outside the extractor package in core (and the FLAC extension), and
FlacStreamMetadataTest uses a FLAC asset, it seems preferable to move it
into the extractor package.
PiperOrigin-RevId: 291372032
CeaUtil depends on TrackOutput so should live in the extractors package.
To avoid having Cea708Decoder depend on extractors, this change also
moves the initialization data building/parsing to CodecSpecificDataUtil.
PiperOrigin-RevId: 291348317
Using @Test(expected=...) is discouraged, since the test will pass if
any statement in the test method throws the expected exception.
PiperOrigin-RevId: 291338224
Since we have the Playlist layer on top, it's always guaranteed that a
new playlist item has a new uid. So we can just keep the old one in all
cases and don't have to be careful to delete it. The deletion was necessary
previously in case multiple MediaSources use the same uids.
PiperOrigin-RevId: 291152349
Move Cea708InitializationData functionality into CeaUtil and delete the
class.
Move CeaUtil to the util package as it needs to be used both in
extraction and decoding.
PiperOrigin-RevId: 291128220
The only remaining use is to provide the initial position for the first media
period in the queue. At this point, the value is always equivalent to
PlaybackInfo.positionUs because they are set together to the same value in
PlaybackInfo.copyWithNewPosition.
PiperOrigin-RevId: 290749294
We have a flag that gets turned on if the current playback position has been
reset, so that messages from this reset position can be triggered. This
mechanism isn't actually depending on the startPositionUs field because it
should always be triggered in the first iteration with the new position.
PiperOrigin-RevId: 290749201
There are a couple of problems with how positions in PlaybackInfo are set at
the moment:
1. PositionUs isn't allowed to be C.TIME_UNSET. This is prevented by always
resolving to the current default position if needed.
2. In some places a window position was used as a period position. Use correct
position resolution procedure.
3. When creating a placeholder position to restart playback, we used the first
period in a window, not the one where the default position is.
4. The start position for ads was in some cases set to 0 without checking
the ad resume position.
PiperOrigin-RevId: 290749042
I needed to use Cue.Builder instead of just SpannableStringBuilder for
the regionOutput values, so I could attach the vertical info where
appropriate (since this is a property of the Cue, not a span).
PiperOrigin-RevId: 290709294
If an exception is thrown between updating the timeline and updating
the position in playbackInfo, the state may be inconsistent.
Exceptions are expected to be thrown while updating the player state
and we should handle such cases in a consistent way.
Similar to how we handle the same situation in seekToInternal,
the state is updated in a final block such that it gets updated to the
latest state even if an error occurs. Moving both the timeline and
position update together also ensures they always stay consistent.
PiperOrigin-RevId: 290624020
This restructure moves all the position resolving code to a static method and
removes the dependency of the MediaPeriodQueue on having an up-to-date timeline.
Both steps allow simplified reasoning about the code as the static method can't change
the state of the player, and there is no risk the queue can use the wrong timeline.
These propoerties allow to fix a bug causing inconsistent states in a follow-up step.
PiperOrigin-RevId: 290616395
It's never assigned or accessed from outside the class.
It was added in
<unknown commit>
then the accessor was removed in
<unknown commit>
PiperOrigin-RevId: 290601998
This makes MPEG audio utilities similar to utilities we have for WAV,
AC-3 etc., and moves them out of the extractor package so that an
extractor module can be split out without needing to have a class in the
extractor package in the common library.
PiperOrigin-RevId: 290595089
*** Original commit ***
Rollback of ff89170b00
*** Original commit ***
Fix some logic in AnalyticsCollector.
All events issued from ExoPlayerImpl (i.e. Player.EventListener events) currently
try to use the media period data from the playing media period as set in the
playback thread queue. This is only correct as long as there no pending masking
operations in ExoPlayerImpl. That's why we currently disable this whenever the timeline
is...
***
PiperOrigin-RevId: 290593700
*** Original commit ***
Fix some logic in AnalyticsCollector.
All events issued from ExoPlayerImpl (i.e. Player.EventListener events) currently
try to use the media period data from the playing media period as set in the
playback thread queue. This is only correct as long as there no pending masking
operations in ExoPlayerImpl. That's why we currently disable this whenever the timeline
is empty or a seek is pending. Since adding all the playlist API methods to the player,
this is no longer the right choice. Moreover,...
***
PiperOrigin-RevId: 290312118
Currently both are updated by separate setters. If an exception is thrown between
the two setters, the state may not be consistent.
Avoid this problem by always setting them together.
PiperOrigin-RevId: 290293600
All events issued from ExoPlayerImpl (i.e. Player.EventListener events) currently
try to use the media period data from the playing media period as set in the
playback thread queue. This is only correct as long as there no pending masking
operations in ExoPlayerImpl. That's why we currently disable this whenever the timeline
is empty or a seek is pending. Since adding all the playlist API methods to the player,
this is no longer the right choice. Moreover, we don't have a definite API that tells
AnalyticsCollector when a playlist API call has been handled (and we don't want to
have one).
We can fix this by always using the current Player position information as the source
of truth (instead of the media period queue). This is definitely more correct and also
works while a masking operation is pending. To fill in the additional information from
the media period queue, we can look up a matching media period. This may not be the
first one in the list if an operation is pending.
The new methods are similar to the previous tryResolveWindowIndex method, but:
1. They are always used (i.e. the current Player state is the main source of truth)
2. They also check the correct ad playback state, that was just ignored previously.
PiperOrigin-RevId: 290284916
Currently seeks are basically ignored. However, it's more realistic to re-queue the
single sample if the seek is to position 0.
PiperOrigin-RevId: 290273564
*** Original commit ***
Rollback of d48dc4c159
*** Original commit ***
Move getting-stuck-prevention into DefaultLoadControl.
We recently added code that prevents getting stuck if the buffer is low and
the LoadControl refuses to continue loading (b84bde0252).
Move this logic into DefaultLoadControl to keep the workaround, and also apply the
maximum buffer size check in bytes if enabled. ExoPlayerImplInternal will now
throw if a...
***
PiperOrigin-RevId: 290273295
- Add additional Listener methods to DownloadManager, to inform of
changes to whether the downloads are paused or waiting for requirements.
- Only schedule the Scheduler if we really are waiting for requirements.
- Only restart the service if we're no longer waiting for requirements,
and if there are queued downloads that will now be restarted.
Previously the service would be restarted whenever the requirements
were met, regardless of whether there was any work to do.
- Restart service if it might be stopping, as well as if it's already
stopped. Also restart service if there's a download state change to a
state for which the service should be started, if.
Issue: #6798
PiperOrigin-RevId: 290270547
First cl towards DefaultMediaSourceFactory (<unknown commit>) does not change the MediaSourceFactory interface except adding @Nullable anotations to setters.
PiperOrigin-RevId: 290269640
Doing so prevent Codec which is a big object with
JNI to be garbage collected.
As the codec can not be hold in the listener, there
is no way to call release, as it must be called on
the same codec.
As a result the release method is also removed.
The downside is that at runtime some callbacks may be
dropped but it should be a short transitive state.
This also simplifies lifecycle of the listener as
the client does not have to know if release needs
to be called or not.
An alternative would have been to hold a weak ref,
but I deemed it too complicated for the
runtime gain.
PiperOrigin-RevId: 290231659
This fixes an issue where a DownloadService implementation
that allows foreground but doesn't provide a scheduler would
not be restarted in the case that it was still in memory but
classed as idle by the platform.
It also speeds up service restart in the case that a
scheduler is provided.
Issue: #6798
PiperOrigin-RevId: 290068960
This method has two use cases:
1. Seeking. Calls are immediately preceded by a call to rewind(), and
the returned value isn't important unless it's ADVANCED_FAILED (i.e.
the caller is only interested in success and failure).
2. Advancing. The return value is important unless it's ADVANCED_FAILED,
in which case the caller wants to treat it as 0.
This change creates separate methods for each use case. The new seekTo
methods automatically rewind and return a boolean. The updated advanceTo
method returns 0 directly in cases where ADVANCED_FAILED was returned.
Arguments that were always hard-coded to true by callers have also been
removed.
This change is a step toward one possible solution for #6155. How we'll
solve that issue is still up for discussion, but this change seems like
one we should make regardless!
Issue: #6155
PiperOrigin-RevId: 290053743
- DownloadManagerHelper now passes all downloads to the
DownloadService when the service is attached (and once
the downloads are known). The service then starts the
foreground notification updater if necessary. This fixes
the ref'd issue.
- Don't call getScheduler() if the service is background
only. This was already documented to be the case on the
DownloadService constructor.
- If the service is started in the foreground on SDK level
26 and higher, satisfy the condition to move the service
to the foreground in onStartCommand rather than in stop().
It's much more obviously correct, and should produce the
same end result.
Issue: #6798
PiperOrigin-RevId: 290050024
Currently the following sequence of events happens at automatic period transitions:
1. Update queue (=release old playing period)
2. Disable unused renderers
3. Enable newly needed renderers
This order requires difficult to follow workarounds in AnalyticsCollector for all
events related to step 2 (disable renderers). The current media period has already
been advanced so can't be used. The current workaround saves the last known playing
media period that was published as part of a PlaybackInfo update in ExoPlayerImpl.
This works in most cases, but is inherently wrong because the published state in
ExoPlayerImpl may be completely unrelated to the updates happening on the playback
thread (e.g. if many other operations are pending).
Simplify and fix this problem by changing the order of the events above:
1. Disable unused renderers.
2. Update queue
3. Enable newly needed renderers.
This way the current playing media period can be used for both renderer disable
and renderer enable events, thus it's correct in all cases and the workaround
in AnalyticsCollector can be removed.
PiperOrigin-RevId: 290037225
Whenever we set the maskingWindowIndex, we also need to set the masking period index
and the masking position. Otherwise it may cause exception when the period index
is used together with the masking timeline.
PiperOrigin-RevId: 290036973
This optimization allows a ChunkSampleStream to output track
formats as soon as they're parsed during an InitializationChunk
load, rather than waiting until after the InitializationChunk
load is completed.
In DASH VOD, a single InitializationChunk typically loads the
moov and sidx atoms in that order. Hence for long form content
where the sidx is a non-trivial size, this may result in the
track formats being output a non-negligible period of time
sooner than was previously the case. This allows downstream
renderers to start codec initialization sooner, potentially
decreasing startup latency.
For a single test stream on a fast & stable network, this
pretty consistently reduced elapsed time until both audio and
video codecs have been initialized from ~0.5s to ~0.3 seconds
on a Galaxy S8. For 5 test runs without and with these patches,
the eventTime logged by EventLogger for the second decoder
init were:
Without (secs): 0.47 0.47 0.45 0.48 0.46
With (secs) : 0.32 0.33 0.34 0.31 0.40
PiperOrigin-RevId: 289845089
The current order of operations means that the Format is only passed
to the chunk's output after the DataSource has been opened. This
means that establishing the network connection and the downstream
renderers initializing their codecs are effectively serialized to
occur one after the other.
In the new order, the Format is passed to the chunk's output before
the DataSource has been opened. This allows the downstream renderers
to initialize their codecs in parallel with the network connection
being established, and hence latency at the start of playback is
reduced.
PiperOrigin-RevId: 289841854
We currently have a currentMediaPeriodId and an activeSessionId that are more
or less tracking the same thing unless the current media period isn't "active" yet.
Simplify this logic by using a single currentSessionId field and the respective
isActive flag of this session. Also move all session creation and activation code in
the same method to make it easier to reason about the code.
This change also fixes a subtle bug where events after a seek to a new window
are not ignored as they should.
PiperOrigin-RevId: 289432181
As discovered whilst investigating #6798, there are cases
where these methods are not correctly. They were added as
convenience methods that could be overridden by concrete
DownloadService implementations, but since they don't work
properly it's preferable to require application code to
listen to their DownloadManager directly instead.
Notes:
- The original proposal to fix#6798 stored the state change
events in memory until they could be delivered. This approach
is not ideal because the events still end up being delivered
later than they should be. We also want to fix the root cause
in a different way that does not require doing this.
- This change does not fix#6798. It's a preparatory step.
Issue: #6798
PiperOrigin-RevId: 289418555
This change makes it clear the SampleQueue doesn't outlive
the wrapping PlayerTrackEmsgHandler, and releases it from
PlayerTrackEmsgHandler.release().
This change is a no-op because calling release() is the
same as reset() in this case (the behavior only differs if
a non-dummy DrmSessionManager is being used).
PiperOrigin-RevId: 289416622
As a result, onMediaChunkLoadStarted gets invoked on the loading thread, and
init on the playback thread, matching the thread access comments.
Issue:#6321
PiperOrigin-RevId: 289167981
Dash live streams require that the client has an accurate wall clock
time and in absence of a UTCTiming element, this is assumed to be the
NTP time.
This change adds NTP time offset resolution for DASH live streams
without such timing elements.
PiperOrigin-RevId: 289098796
Unfortunately devices such as the MI 8 do not provide an alternative
working decoder. Some Vivo devices do provide one though.
PiperOrigin-RevId: 288911897
This improves readability by making clearer that reading no bytes from
the input in readFrames() is an expected case if the buffer is full.
PiperOrigin-RevId: 288711841
Currently, seeks are only tracked if both the start and the end of the seek
is within the same window. This means no seeking state is reported if the
playback switches to a new window during the seek.
This problem is fixed by tracking seek start and end events in all cases,
but only report seeking state once the window becomes the foreground window.
PiperOrigin-RevId: 288706674
These make the interesting bits of each assertion harder to follow imo.
Also remove all the assertWithMessage() calls at the same time, Olly
convinced me these are rarely useful since you can click from the stack
trace to the failing line in the IDE.
PiperOrigin-RevId: 288470704
- Simulate IO exceptions in the test using FlacBinarySearchSeeker for
seeking in FlacExtractorTests. This makes the test slower but covers
more test cases.
PiperOrigin-RevId: 288285057
There's currently no rendering support for ruby text in SubtitleView
or SubtitlePainter, but this does have a visible impact with the
current implementation by stripping the ruby text from Cue.text
meaning it doesn't show up at all under the 'naive' rendering.
This is an improvement over the current behaviour of including
the ruby text in-line with the base text (no rubies is better than
wrongly rendered rubies).
PiperOrigin-RevId: 288280416
This typo was introduced in ddb70d96ad
when migrating a static method with parameter `durationUs` to an
instance method where the correct field to use was `blockDurationUs`
(but `durationUs` also exists).
The test that catches this was only added in 45013ece1e (and
therefore configured with the wrong expected output data).
issue:#6833
PiperOrigin-RevId: 288274197
It's not used. I was trying to work out how to correctly cascade my
text-combine-upright styling, but deleting the method seemed easier...
PiperOrigin-RevId: 287989480
I decided the flags bit was a bit unclear so I played around with this
It's also needed for more 'complex' assertions like colors - I didn't
want to just chuck in a fourth int parameter to create:
hasForegroundColorSpan(int start, int end, int flags, int color)
PiperOrigin-RevId: 287989424
Relying on the precedence of spans seems risky - I can't find it
defined anywhere. It might have changed in Android 6.0?
https://stackoverflow.com/q/34631851
PiperOrigin-RevId: 287989365
-- Optimize Mp4Extractor for AC-4
-- Optimize FragmentedMp4Extractor for AC-4
-- Add test case for AC-4 in MP4
-- Add test case for AC-4 in Fragmented MP4
It's unreliable for at least one IMA ADPCM file I've found.
Calculating the blockIndex to seek to using exact properties
also seems more robust.
Note this doesn't change anything for the existing PCM test,
since averageBytesPerSecond is set correctly. It does make
a difference for an upcoming IMA ADPCM test though.
PiperOrigin-RevId: 287814947
An experiment with this algorithm didn't show positive results. We can
therefore keep the simpler default algorithm.
Startblock:
<unknown commit> is submitted
PiperOrigin-RevId: 287807538
Where media segments are specified using byte ranges, it makes
sense that a server might return 416 (which we don't consider
for blacklisting) if the segment is unavailable, rather than
the 404 (which we do consider for blacklisting) that we expect
when media segments are only specified using a URL.
Issue: #6775
PiperOrigin-RevId: 286620698
The Download constructor considers it invalid to have a failure
reason if the download isn't in the failed state. Unfortunately,
calling DefaultDownloadIndex.removeAllDownloads when there's a
failed download will change the state without clearing the reason.
If the downloads are then read back from the DefaultDownloadIndex
we end up violating the Download constructor assertion.
This change clears the failed reason for any existing rows in the
invalid state, and also fixes the root cause that allows invalid
rows to enter the table in the first place.
Issue: #6785
PiperOrigin-RevId: 286576242
Without this @Nullable, potential subclasses can't override the
method to return null if they don't want to use the renderer as a
media clock.
Issue:#6792
PiperOrigin-RevId: 286545736
This class is only used to hold temporary data while we parse the
settings and text, so we don't need it outside the Parser class.
Also remove all state from WebvttCueParser - this increases
the number of allocations, but there are already many
and subtitles generally aren't very frequent (compared to
e.g. video frames).
PiperOrigin-RevId: 286200002
Add support for MP3 as an encoding format for passthrough.
This change does not change the observable
behavior of Exoplayer.
Also name the magics.
#exo-offload
PiperOrigin-RevId: 286146539
*** Original commit ***
Move getting-stuck-prevention into DefaultLoadControl.
We recently added code that prevents getting stuck if the buffer is low and
the LoadControl refuses to continue loading (b84bde0252).
Move this logic into DefaultLoadControl to keep the workaround, and also apply the
maximum buffer size check in bytes if enabled. ExoPlayerImplInternal will now
throw if a LoadControl lets playback get stuck. This includes the case where
DefaultLoadControl reaches its maximum buffer size and not even a mim...
***
PiperOrigin-RevId: 286071115
We recently added code that prevents getting stuck if the buffer is low and
the LoadControl refuses to continue loading (b84bde0252).
Move this logic into DefaultLoadControl to keep the workaround, and also apply the
maximum buffer size check in bytes if enabled. ExoPlayerImplInternal will now
throw if a LoadControl lets playback get stuck. This includes the case where
DefaultLoadControl reaches its maximum buffer size and not even a mimimal buffer
duration.
PiperOrigin-RevId: 285979989
This offset allows to improve the calculated live offset because it
can take known client-server time offsets into account.
PiperOrigin-RevId: 285970738
I want to add fields related to vertical text support, and neither
adding another constructor nor updating all call-sites of existing
constructors seemed like attractive propositions.
PiperOrigin-RevId: 285956024
- Remove duplicated null assignments
- Move mediaCryptoRequiresSecureDecoder reset to be with all the
other mediaCrypto stuff.
PiperOrigin-RevId: 285955134
MultiLockAsyncMediaCodecAdapter is an implementation of the
MediaCodecAdapter that uses multiple locks to synchronize access to its
data compared to the single-lock approach used in
DedicatedThreadAsyncMediaCodecAdapter.
PiperOrigin-RevId: 285944702
- Make extractor output samples that are uniformly distributed
with respect to time, with a target of ~10 samples per second.
The old approach could in theory put every frame into its own
sample, which would be very inefficient downstream because we'd
need to pass them individually to MediaCodec. It could also put
data corresponding to a long duration of time into a single
sample (e.g. if the sample rate of the content is low), which
is bad downstream because we decide whether to set the decodeOnly
flag on a per sample basis. More generally, the new approach
is more predictable :).
- Stop using the WavSeekMap to get sample timestamps, and instead
calculate them directly from the number of frames output. It's
more obviously correct, particularly for data formats like IMA
ADPCM where we'll need to adjust the data prior to output.
PiperOrigin-RevId: 285750010
In MatroskaExtractor, if the last cue time exceeds the duration
specified in the header, then we end up generating a negative
duration chunk as the last item in the SeekMap. We should probably
not do this, so drop it instead.
Note: Matroska does have a CueDuration element, but it's not used
in the one problematic file I've found.
PiperOrigin-RevId: 285738418
Currently, resetting the internal state related to the codec in done in 4 places
in MediaCodecRenderer:
1. In the constructor to set some sensible initial default.
2. In flushOrReleaseCodec to reset state after flushing
3. In releaseCodec to reset state to default values for a released codec.
4. In initCodec to reset state to defaul values for a new codec.
There are actuall only two types of state reset operations:
1. Resetting state for a released codec, so that a new codec isn't influenced by
previous codecs.
2. Resetting state after flushing an existing codec. This is a subset of (1).
So to simplify the class, this change moves all state resets to two methods
corresponding to the two cases above.
PiperOrigin-RevId: 285731913
These are transitively provided by testutil's build.gradle.
This makes the core module consistent with the others like ui, hls, dash
PiperOrigin-RevId: 285729566
This may happen for example when trying to load unfinished live media
chunks that can only be loaded at real-time playback speed.
The flag can be used by the sources to indicate that network transfer
will knowingly be throttled, such that transfer listeners like the
bandwidth meter can take this information into account.
PiperOrigin-RevId: 285397100
Also change IcyInfo.rawMetatadata from String to byte[]
ICY doesn't specify the character encoding, and there are streams
not using UTF-8 (issue:#6753). It seems the default of at least one
server is ISO-8859-1 so let's support that as a fallback:
https://github.com/savonet/liquidsoap/issues/411#issuecomment-288759200
Also update IcyDecoder to skip strings it doesn't recognise at all
instead of decoding invalid characters.
The feed from issue:#6753 now decodes accents correctly:
EventLogger: ICY: title="D Pai - Le temps de la rentrée", url="null"
PiperOrigin-RevId: 285388522
We previously used Locale.fromLanguageTag and then toLanguageTag to automatically
filter out invalid tags and to replace deprecated tags. However, this only works
for API 21+.
This change does no longer rely on the platform methods and instead:
1. Keeps invalid tags as they are. This may help if developers rely on
non-spec-complaint language tags (for example, #6681).
2. Adds a list of deprcated tags and their modern replacements to our code
3. Normalizes some short codes that have been superseded by macrolanguage codes by
their macrolanguage equivalent.
Issue:#6681
PiperOrigin-RevId: 285384841
This has been broken since
c3d6be3afd
and broken for ICY (where I noticed the problem) since
5695bae9d8.
ICY symptom is that we see no repeated metadata, because the
Icy-MetaData:1 header doesn't make it to the server so we never get back
icy-metaint.
PiperOrigin-RevId: 285379234
The presentationTimeOffsetMs may be C.TIME_UNSET for VOD content
and shouldn't be used in calculations for the windowStartTime.
PiperOrigin-RevId: 285363095
Retrieve the sample number in the extractor instead of passing a holder
to FlacBinarySearchSeeker. This change makes the code easier to
understand and is required to implement the seeking from the seek table.
PiperOrigin-RevId: 285241862
- WavHeader is now immutable and contains only values parsed out
of the WAVE FMT chunk. It no longer contains a C.PcmEncoding
encoding, or mutable data bounds.
- WavHeaderReader now parses the WAVE header chunks without any
additional logic (e.g. validating the block alignment value,
which is format type dependent).
- The SeekMap part of WavHeader is split out into WavSeekMap.
PiperOrigin-RevId: 285232498
This returns the current offset to the live edge. The calculation is
non-intuitive enough to provide this convenience method.
PiperOrigin-RevId: 285171090
This avoids needing to jump through type paremeter hoops to create a
sub-classable Cue.Builder.
Cue should have a standard set of fields, because it will be
consumed by renderers that don't know what type it is. The
existing subclass fields are only used inside their respective
packages, so can be part of a wrapper object instead.
This lays the groundwork for converting Cue's multiple constructors
into a Builder pattern.
PiperOrigin-RevId: 284992135
Keyframe was rendered rather than skipped when performing
an exact seek to a non-zero position close to the start of
the stream.
PiperOrigin-RevId: 284798460
The nullness checker complains about Integers with @IntDef annotations
so replace pairs with custom pair types for the timed event records in
PlaybackStats.
PiperOrigin-RevId: 284731834
Caveats:
- Block additional data is ignored if the block is laced
and contains multiple samples. Note that this is not
a loss of functionality (SimpleBlock cannot have block
additional data, and lacing was previously completely
unsupported for Block)
- Subrip and ASS samples are dropped if they're in laced
blocks with multiple samples (I don't think this is
valid anyway)
Issue: #3026
PiperOrigin-RevId: 284545197
This change constrains the use of sample state member variables to
writeSampleData, finishWriteSampleData and resetWriteSampleData.
Using them elsewhere gets increasingly confusing when considering
features like lacing in full blocks. For example sampleBytesWritten
cannot be used when calling commitSampleToOutput in this case
because we need to write the sample data for multiple samples
before we commit any of them.
Issue: #3026
PiperOrigin-RevId: 284541942
Refator to lift a method to create (and destroy) the OnFrameRenderedListenerV23() and split destroying the Handler from removing the MediaCodec onFrameRenderedListener to avoid double call to codec.setOnFrameRenderedListener()
This makes the format metadata null (instead of an empty Metadata
object) when it is not provided, and is therefore consistent with the
other extractors behavior.
PiperOrigin-RevId: 284171148
The capture frame rate is currently available both via Format.metadata
and decoded in Format.frameRate. As the container Format.frameRate may
be useful to apps, only store the capture frame rate in metadata (apps
will need to decode it but can now access the container frame rate too).
PiperOrigin-RevId: 284165711
- Remove "lacing" from member variables. They're used even if
there is no lacing (and the fact that lacing is the way of
getting multiple samples into a block isn't important).
Issue: #3026
PiperOrigin-RevId: 284152447
- Change sampleHasReferenceBlock to a block reading variable, which is
what it is (the distinction didn't matter previously, but will do so
when we add lacing support in full blocks because there wont be a 1:1
relationship any more.
- Move sampleRead to be a reading state variable.
- Stop abbreviating "additional"
Issue: #3026
PiperOrigin-RevId: 284000937
An I/O error could occur while handling the start of an mdta box, in
which case retrying would cause another ContainerAtom to be added. Fix
this by skipping the mdta header before updating container atoms.
PiperOrigin-RevId: 284000715
Saves around 200 lines of code. High level overview:
- Rename SampleQueue to SampleDataQueue.
- Rename SampleMetadataQueue to SampleQueue.
This CL should not introduce behavior changes. The only significant
changes in synchronization should be:
+ Add synchronized keyword to isReady.
- Seems to be necessary.
+ Add synchronized keyword to SampleQueue.sampleMetadata.
- Before this change, SampleQueue.sampleMetadata could acquire the
SampleMetadataQueue lock three times in a single method call.
Other miscellaneous improvements:
+ Put all private methods at the bottom.
+ Move release() to the right category.
PiperOrigin-RevId: 283795844
This parameter is a little confusing, especially as the behaviour
can be surprising if the intended use-case isn't clear. This change
moves the description of the parameter into the class javadoc,
adds context/justification and slims down each method's
javadoc to refer to the class-level.
Related to investigating/fixing issue:#6700
PiperOrigin-RevId: 283724826
Finailzed logic to update the `SampleQueue` write positions (first index) to push these into `HlsMediaChunk` when the track is initially created (from the Extractor output) and as each new chunk is queued to load (`init()` callback).
Add lots of debuging prints that can come out for the final merge.
Code is very close to a clone of `ChunkSampleStream`.
DASH implements this feature, extend the feature for HLS as well. First change just drops video samples.
For demuxed audio the audio samples will continue to play out to match the
dropped video, so need to keep indexes in all the sample queues related to a chunk and discard them all.
This is a minor change ahead of merging a full variant of
https://github.com/google/ExoPlayer/pull/6706, to make
re-buffers less likely.
Also remove variable substitution when parsing
AVERAGE-BANDWIDTH (it's not required for integer attributes)
PiperOrigin-RevId: 283554106
Calls to new Handler() without arguments are deprecated as of the latest Android
version. Replace them by a Util.createHandler call similar to the ones we
already have.
PiperOrigin-RevId: 283532891
Fixes issue:#6700
sample_cbs_truncated.adts test file produced using
`$ split -b 31795 sample_truncated.adts` to remove the last 10 bytes
PiperOrigin-RevId: 283530136
If LoadControl.shouldContinueLoading returns false and the renderers are not
ready for playback using the already buffered data, playback is stuck.
To prevent this situation, we always continue loading if the buffer is almost
empty. We already have a similar workaround for when
LoadControl.shouldStartPlayback returns false even if loading stopped.
Having both workarounds allows playback to continue even if the LoadControl
tries to prevent loading and playing all the time.
PiperOrigin-RevId: 283516750
*** Original commit ***
Improve `Format` propagation within the `MediaCodecRenderer`.
For example, fix handling of pixel aspect ratio changes in
playlists where video resolution does not change.
Issue:#6646
***
PiperOrigin-RevId: 282903626
When transitioning to a new stream in a different format, the audio
processors are reconfigured. After this, they are drained and then
flushed so that they are ready to handle data in updated formats for the
new stream.
Before this change, some audio processors made the assumption that after
reconfiguration no more input would be queued in their old input format,
but this assumption is not correct: during draining more input may be
queued. Fix this behavior so that the new configuration is not referred
to while draining and only becomes active once flushed.
Issue: #6601
PiperOrigin-RevId: 282515359
flush() is guaranteed to be called in all these cases anyway.
Also clarify documentation for AudioProcessor-specific methods that can
change the 'active' flag.
Issue: #6601
PiperOrigin-RevId: 282515255
This simplifies the contract of configure and is in preparation for
fixing a bug where more input can't be queued when draining audio
processors for a configuration change.
Issue: #6601
PiperOrigin-RevId: 282514367
- Move property to DrmSession; it feels like a more natural place
for it to go (and provides greater flexibility).
- Change flags to a boolean.
PiperOrigin-RevId: 281758729
They are all marked with a JavaDoc comment and the @WorkerThread annotation
which is useful if apps are using threading annotations. All other public
methods in the same classes are marked with @AnyThread to avoid the impression
we forgot to annotate them.
PiperOrigin-RevId: 281490301
The current workaround seems to cause compilation errors inside the
testutils module in Android Studio. This seems to fix them.
This doesn't introduce a circular dependency because it's only
the tests in library-core depending on testutils.
PiperOrigin-RevId: 281318192
Note:
- Fixing this uncovers another bug in how audio processor draining
works, so the test playlist still doesn't play correctly after this
change.
- Once we reconfigure the audio sink based on the ExoPlayer Format
rather than the codec MediaFormat in a later change, this change can
be reverted.
Issue: #6601
PiperOrigin-RevId: 281264149
- Make NonNull, which is already the case when using the manager builder.
- Better document PLAYREADY_CUSTOM_DATA_KEY, now that newPlayReadyInstance
is no more.
PiperOrigin-RevId: 281079288
The implementation of writing HDR10+ static metadata assumed that the
application would use default (big endian) byte order for this metadata but
MediaCodec expects the order to match the specification CTA-861.3.
PiperOrigin-RevId: 281050806
Also remove the "do we really need to do this" comment for AAC.
Parsing from codec specific data is likely to be more robust, so
I think we should continue to do it for formats where we've seen
this problem.
Issue: #6648
PiperOrigin-RevId: 280575466
Previously the renderer EOS (aka last frame rendered), was reported as soon
as the last encoded frame was queued in the codec renderer.
This leaded to EOS reported too early.
PiperOrigin-RevId: 280456277
This speeds up downloads where segments have the same URL with different
byte ranges. We limit the merged segments to 20 seconds to ensure the download
progress of demuxed streams is roughly in line with the playable media duration.
Issue:#5978
PiperOrigin-RevId: 280410761
Clear state for one mode when entering the other in both SimpleExoPlayer
and SimpleDecoderVideoRenderer. The latter is redundant for the case of
renderers that are used inside SimpleExoPlayer, but seems nice to have.
- Entering Surface mode means receiving a non-null Surface, SurfaceHolder
or TextureView in SimpleExoPlayer, or a non-null Surface in
SimpleDecoderVideoRenderer.
- Entering VideoDecoderOutputBufferRenderer means receiving a non-null
VideoDecoderOutputBufferRenderer in SimpleExoPlayer and
SimpleDecoderVideoRenderer.
PiperOrigin-RevId: 280155151
This aligns the method naming and Javadoc. The only remaining
inconsistency I can see is that the initial reference count for
DrmSession is 0 rather than 1. Unfortunately I think it's not
trivial to get these aligned, because DefaultDrmSessionManager
relies on being able to do something between instantiation and
the DrmSession starting to open the session. In practice this
doesn't really matter, since DrmSessions will be obtained via the
manager, which does increment thee reference count to 1 to be
consistent with how ExoMediaDrm acquisition works.
PiperOrigin-RevId: 280136574
The handling of times wasn't really clear to me, hopefully this more
exhaustive documentation helps a bit.
Also assert the end timecode is the 'correct' length for the format.
PiperOrigin-RevId: 279922369
To trigger receiving the broadcast it's necessary to idle() the shadow
main looper, which has to be done from the test thread. Therefore this
change removes the send broadcast action and instead sends the broadcast
from the test thread.
PiperOrigin-RevId: 279660935
- This is for consistency with PlayerControlView.
- Also update PlayerNotificationManager notification if shuffle
mode changes. This is for consistency with what happens when
the repeat mode changes. By default the notification will be
unchanged, but custom implementations can extend and then
override createNotification, and given these modes change
infrequently it feels like we can just do this. The alternative
for achieving consistency would be to remove handling of repeat
mode changes.
Issue: #6582
PiperOrigin-RevId: 277925094
This means multiple failures are all logged, instead of the test
stopping when the first assertion fails. Makes tests like this with
lots of independent assertions much easier to work with.
I limited the expect to a single assertCues() call, otherwise
the error message gets very long and is hard to read, but I
still think this is an improvement.
PiperOrigin-RevId: 277523300
Cue's UNSET and null values should be used when the source data
doesn't specify *and* the spec doesn't provide a clear default.
In the WebVTT case, the defaults are clear, so we use them
explicitly.
PiperOrigin-RevId: 277522899
The framework opus decoder discards some samples after a call to
flush(). Because we flush a decoder that is being retained across an
input format change, this means that the start of audio gets truncated
when transitioning to a new opus stream. See also
https://android.googlesource.com/platform/frameworks/av/+/refs/heads/android10-release/media/libstagefright/codecs/opus/dec/SoftOpus.cpp.
Avoid this by recreating opus decoders instead of flushing them. It
seems fine to do this for all opus decoders as reinitialization should
be cheap, OEM-provided implementations may also discard samples and
playback shouldn't be interrupted on reinitialization due to the
downstream AudioTrack buffer.
PiperOrigin-RevId: 277458759
Update it to throw if hasNext() is false, to match Java's Iterator
interface.
This also simplifies the null-checking annotations required
PiperOrigin-RevId: 277059766
Also remove it from all tests, these aren't covered by the null-checker
Covered by the following package-info.java files:
- j/c/g/a/exoplayer2/ext/mediasession/package-info.java
- j/c/g/a/exoplayer2/package-info.java
- j/c/g/a/exoplayer2/offline/package-info.java
- j/c/g/a/exoplayer2/video/package-info.java
- j/c/g/a/exoplayer2/ui/package-info.java
PiperOrigin-RevId: 277038916
*** Original commit ***
Rollback of bf01ff0f60
*** Original commit ***
Use Float.NaN for Cue#DIMEN_UNSET
Float.MIN_VALUE is very close to zero:
"A constant holding the smallest positive nonzero value of type float"
https://developer.android.com/reference/java/lang/Float.html#MIN_VALUE
Float.NaN more clearly conveys this is an invalid number,
and will also more clearly carry over if we do maths on it a...
***
PiperOrigin-RevId: 276674142
*** Original commit ***
Use Float.NaN for Cue#DIMEN_UNSET
Float.MIN_VALUE is very close to zero:
"A constant holding the smallest positive nonzero value of type float"
https://developer.android.com/reference/java/lang/Float.html#MIN_VALUE
Float.NaN more clearly conveys this is an invalid number,
and will also more clearly carry over if we do maths on it accidentally.
***
PiperOrigin-RevId: 276315786
Float.MIN_VALUE is very close to zero:
"A constant holding the smallest positive nonzero value of type float"
https://developer.android.com/reference/java/lang/Float.html#MIN_VALUE
Float.NaN more clearly conveys this is an invalid number,
and will also more clearly carry over if we do maths on it accidentally.
PiperOrigin-RevId: 276277784
With lots of int comparisons close together, this makes the error
messages much clearer and saves having to manually match up line
numbers.
Also make every @Test just throw Exception
PiperOrigin-RevId: 276079806
Without this, a subtitle track empty edit list used to offset the start of
subtitles is ignored.
Also the current code seems to depend on the order in which
we parse the tracks (audio first means we have gapless info when we parse
video track, while video first we wouldn't).
It's not clear why we can't handle both edit lists & gapless info
PiperOrigin-RevId: 276029744
- Leaving GvrAudioProcessor for now.
- Removing GvrPlayerActivity because it was never released. Also removing
related UI classes. These were released, but it's unlikely anyone would
have been using them directly.
PiperOrigin-RevId: 275822516
*** Original commit ***
Rollback of 4ad4e3e4fc
*** Original commit ***
Rollback of 3b22db33ba
*** Original commit ***
add top-level playlist API to ExoPlayer
Public design doc:
https://docs.google.com/document/d/11...
***
PiperOrigin-RevId: 275813737
ConditionVariable.block(timeout) doesn't work in Robolectric, because it
relies on the system clock which doesn't advance.
PiperOrigin-RevId: 275798281
@MonotonicNonNull is not useful if the variable is final, because it's only
assigned once and guaranteed to keep it's current nullability in the same
way as @MonotonicNonNull ensures it's kept non-null after checking.
This way, the workarounds can also be removed.
PiperOrigin-RevId: 275428656
GlViewGroup doesn't work properly as an actual ViewGroup. For example,
it doesn't support addition of child views after instantiation. This
change turns the class into a renderer, which is also more consistent
with other classes in the package.
PiperOrigin-RevId: 275322295
If an odd resolution is impossible in the specification itself, then we know
that the caller is passing invalid data. Round up on the assumption it's a
rounding error so that playback can proceed.
Issue: #6551
PiperOrigin-RevId: 275226813
Use composition instead.
This makes the null-handling more explicit & complete (previous implementation
tried to prevent null values, but didn't override all mutation methods
e.g. replace(), putIfAbsent() etc.)
PiperOrigin-RevId: 274778513
*** Original commit ***
Remove null-ness of muxedCaptionFormats list
Pre-work for removing HlsMasterPlaylist and HlsPlaylistParser from null-checking
blacklist.
***
PiperOrigin-RevId: 274591502
If a surface was previously passed to the player then an output buffer
renderer was set, we would remove surface callbacks but not clear the
surface on renderers that accept MSG_SET_SURFACE.
PiperOrigin-RevId: 274532266
download calls through to CacheUtil#cache, which handles skipping already downloaded bytes.
It is useful for callers to know that ProgressiveDownloader has this behavior - otherwise, they might reimplement the logic themselves.
I hope this behavior is something that can be part of the public API :)
PiperOrigin-RevId: 274202995
This is a proof of concept for cleanup we should do for all of
our DataSource implementations as we move toward stabilizing
parts of the API.
- Move all XDataSourceFactory classes to be inner classes.
- Remove chained constructors for XDataSourceFactory classes. Keep
required args going through constructors. Use setters for the
rest.
- Not applicable in this case, but we probably want to deprecate
all but the no-arg method for instantiating eac XDataSource
instance (with the all-arg method kept but with the intention
of making it package private).
PiperOrigin-RevId: 274162076
- Verifies that playWhenReady doesn't become true if audio focus
is denied.
- Also verifies there's no suppression reason in this case, because
the denial is permanent rather than temporary.
PiperOrigin-RevId: 274141099
When newIndex overlaps oldIndex with newstarttime < oldstarttime, according to the segNum of endtime
in newIndex and oldIndexLastSegnum to calculate the segmentNumShift.
It's confusing that app:played_color also modifies the colors
that derive from it, but the corresponding setter does not. It
seems generally clearer just to define constants.
PiperOrigin-RevId: 273249557
Move reusable code from LibvpxVideoRenderer to SimpleDecoderVideoRenderer.
Pass outputBuffer to renderOutputBuffer method instead of keeping the reference in the renderer.
PiperOrigin-RevId: 272899549
It's confusing that seekTo(player, windowIndex, positionMs) does
clamping, because it only makes sense if windowIndex is the current
window.
Note: This doesn't actually fix anything (other than code clarity).
In cases where we were passing other windowIndices, we always
passed 0 as the position and so the clamping logic wouldn't have
had any effect.
PiperOrigin-RevId: 272857104
We currently set it to shouldContinueLoading, which isn't correct if
shouldContinueLoading is set to false and we still have an ongoing load.
Change it to also be true if the media period is still loading.
PiperOrigin-RevId: 272823473
This method allows the player to figure out whether we still have an ongoing
load even if LoadControl.shouldContinueLoading returns false.
PiperOrigin-RevId: 272445577
This ensures a more consistent playback behavior no matter if an item is the
first playlist item or a later one. For example, each playlist item gets its
own onRenderedFirstFrame callback and other logic within the renderer that
force renders the first frame more quickly is also triggered.
PiperOrigin-RevId: 272434814
This doesn't change the current behaviour, just adds a clear error message
to the developer with instructions on how to avoid it.
Issue:#6470
PiperOrigin-RevId: 272405556
*** Original commit ***
Modify EventMessageDecoder to return null if decoding fails (currently throws exceptions)
This matches the documentation on MetadataDecoder.decode:
"@return The decoded metadata object, or null if the metadata could not be decoded."
***
PiperOrigin-RevId: 272405287
Created the WakeLockManager for use in SimpleExoPlayer.
Added a setter in SimpleExoPlayer to adjust this functionality.
Issue:#5846
PiperOrigin-RevId: 272176998
This flag is currently merged into Window.isDynamic, which isn't always true
because
1. A window can be dynamic for other reasons (e.g. when the duration is still
missing).
2. A live stream can be become non-dynamic when it ends.
Issue:#2668
Issue:#5973
PiperOrigin-RevId: 271999378
Before: "Unexpected first three bytes of ID3 tag header: 6845556"
After: "Unexpected first three bytes of ID3 tag header: 0x687474"
PiperOrigin-RevId: 271949486
Adding this callback makes sense for completeness (we have similar callbacks
for all other playback state properties), and also to detect audio focus loss
while buffering which would currently trigger no callback because isPlaying
is still false.
Issue:#6203
PiperOrigin-RevId: 271347351
DrmSessionManagers may now be in released state, in which case they
may release their MediaDrm. In that case, it would be invalid to
forward method calls to the underlying MediaDrms. Users should
instead call these methods directly on the MediaDrm.
Issue:#4721
PiperOrigin-RevId: 270963393
This method should be used where we previously checked for active playback
by state==READY and playWhenReady=true. Using the new method ensures we take
audio focus into account for these usages.
Also update some method naming to avoid confusion with the isPlaying method.
Issue:#6203
PiperOrigin-RevId: 270910982
Inline invocations of these methods, which still leaks the MediaDrms.
However, it will be fixed once the DefaultDrmSessionManager API is finalized
and ExoMediaDrm.Providers are introduced.
Issue:#4721
PiperOrigin-RevId: 270681467
Remove the flag DataSpec.FLAG_ALLOW_ICY_METADATA. Instead, set the
header IcyHeaders.REQUEST_HEADER_ENABLE_METADATA_NAME in the DataSpec
httpRequestHeaders.
BUG:134034248
PiperOrigin-RevId: 270662676
In DefaultDashChunkSource.copyWithNewRepresentation, it will handle the logic that
new MPD manifest file is updated and calculate a newSegmentNumShift for furthermore
segNum index calculation in getSegmentUrl, when a shorter window MPD updated and then
back to a longer window MPD, copyWithNewRepresentation will go into the overlap case
but the new index actually contains the old index..
With the internal playlist some new situation may happen that were not possible before:
- handlePlaylistInfoRefreshed in EPII called in IDLE state
- handlePlaylistInfoRefreshed in EPII called in ENDED state with an empty playlist
- seeks in ENDED state with an empty playlist
PiperOrigin-RevId: 270316681
*** Original commit ***
Refactor HlsSampleStreamWrapper#track() to clarify the return paths
I found the original implementation quite hard to follow, and I believe this is functionally identical.
***
PiperOrigin-RevId: 270263186
This option allows to set the preferred text language and role flags based
on the user's accessiblity captioning settings.
Issue:#5749
PiperOrigin-RevId: 270233205
Allows streamlining the way we handle unsupported DRM. In general, either:
* The device does not support the CDM. For example, phones don't support
PlayReady.
* The device does not support the protection scheme. For example, API < 25
devices do not support AES-CBC.
Currently we handle both cases differently. A dummy ExoMediaDrm will allow
the existence of dummy DefaultDrmSessionManagers.
PiperOrigin-RevId: 269315687
Allows shared ownership of ExoMediaDrms. Shared ownership will
allow users to pre-create ExoMediaDrms in their apps, as opposed
to having the DrmSessionManager create the ExoMediaDrm.
Issue:#4721
PiperOrigin-RevId: 269305850
The player may suppress playback when waiting for audio focus even if the
state==Player.READY. There is currently no getter or callback to obtain this
piece of information for UI updates or analytics.
Also, it's a important derived state to know whether the playback position is
advancing. Add isPlaying and the corresponding callback to allow retrieving
this information more easily.
Issue:#6203
PiperOrigin-RevId: 268921721
We currently force render the first frame in all cases. However, when joining
video to an ongoing playback, there is no defined first frame and we should
rather drop frames if we are late until we caught up with the audio playback.
PiperOrigin-RevId: 268698093
When the queue is empty, we may still get multiple requests for a window
sequence number using the same periodUid. We should keep the initially
assigned number because no window change happened.
PiperOrigin-RevId: 268649009
The fLaC prefix is included in the initialization data output
from the MKV extractor, so this is highly likely ot be the
right thing to do.
Issue: #6397
PiperOrigin-RevId: 268244365
This allows to uniquely identify a window within a Timeline. The value is set
correctly for all Window instances, but is not used anywhere yet.
PiperOrigin-RevId: 267556516
We currently don't test if an ad needs to be played in case we are already
playing content.
This is to prevent recreating the current content period when
an ad is marked as skipped. We prefer playing until the designated ad group
position and appending another piece of content. This is less likely to cause
visible discontinuities in case the ad group position is at a key frame
boundary.
However, this means we currently miss updates that require us to play an ad
after a timeline update.
PiperOrigin-RevId: 267553459
Select a track with matching role flags even if someone specifies a preferred role flgs without providing a preferred language
Prefer track without captions or describing music and sound flag when no role flag preference is provided.
Removing this method requires custom MediaSource implementations to switch
to the new version. While this breaks the implmentation, it also avoids problems
with accidentely forwarding to the wrong method or with accidental stack
overflows when none of the two methods gets implemented.
It's unlikely any callers are affected because this is only the extended version
with the defaultProjectionPositionUs parameter that no caller except the
internal player will use.
PiperOrigin-RevId: 267323042
Include Dataspec.httpRequestHeaders in CronetDataSource,
and OkHttpDataSource. Updated documentation of
HttpDataSource.open() to suggest that it should set request
headers (in decreasing priority) from (1) the passed DataSpec,
(2) parameters set with setRequestProperty() and (3) default
parameters set in the HttpDataSource.Factory. No mechanism
has been put in place to enforce this.
PiperOrigin-RevId: 266895574
Sniffing is performed in ProgressiveMediaPeriod even if a single
extractor is provided. Skip it in that case to improve performances.
Issue:#6325
PiperOrigin-RevId: 266766373
The Javadoc for open() won't be read by anyone because it's an overridden method
of the interface and not called directly from application code.
Move doc to class documentation as this is a generic explanation about the
functionality of the class. Also added "all" to clarify that all the parameters
will be added and the order of preference just applies in case of key clashes.
PiperOrigin-RevId: 266753249
This is a no-op interim change to introduce key request error
handling customization. Following changes will allow users to
inject their own LoadErrorHandlingPolicy implementations.
Issue:#6334
PiperOrigin-RevId: 266344399
- Surface information provided by methods isHardwareAccelerated,
isSoftwareOnly and isVendor added in Android Q in MediaCodecInfo
class.
- Estimate this information based on the codec name for earlier API
levels.
Issue:#5839
PiperOrigin-RevId: 266334850
This generalizes our "does file still exist" check to also check
that the file is the expected length. If it's not, we don't trust
it. This avoids infinite recursion in CacheDataSource if a cache
file is truncated underneath the cache.
Issue: #6165
PiperOrigin-RevId: 265707928
Implementations of ForwardingTimeline may override any of the two variants of
this method. We need to ensure that the customized override is always called.
Add back the deprecated method and make it final to forward to the
non-deprecated method in all cases for ForwardingTimelines.
PiperOrigin-RevId: 265419830
The last selection criteria is the audio bitrate to prefer higher-quality
streams. We shouldn't apply this criterium though if the languages of the
tracks are different.
Issue:#6335
PiperOrigin-RevId: 265064756
The implementation can't work properly unless these methods are called by
subclasses, so annotate them to require calling the super implementation when
overriding.
PiperOrigin-RevId: 265017433
The error is closely related to the playback state IDLE and should be updated
in sync with the state to prevent unexpected event ordering and/or keeping the
error after re-preparation.
Issue:#5407
PiperOrigin-RevId: 265014630
Currently the value of FLAG_ALLOW_CACHE_FRAGMENTATION is defined as "1 << 4" but commented as "8". Either the value of FLAG_ALLOW_CACHE_FRAGMENTATION should be "1 << 3", or the comment should be 16. Here I am modifying the comment since it does not affect any current behavior.
PiperOrigin-RevId: 265011839
The app is able to pass a more specialized array type, so the Arrays.copyOf call
produces an array into which it's not valid to store arbitrary AudioProcessors.
Create a new array and copy into it to avoid this problem.
PiperOrigin-RevId: 264779164
This situation happens if the first chunk to load is already behind the end
of the stream. In this case, the preparation never completes because
HlsSampleStreamWrapper gets stuck in a prepared=false and loadingFinished=true
state.
Gracefully handle this situation by attempting to load the last chunk if still
unprepared to ensure that track information is obtained as far as possible.
Otherwise, it wouldn't be possible to play anything even when seeking back.
Issue:#6314
PiperOrigin-RevId: 264599465
Extract supplemental data from block additions in WebM/Matroska.
Allow storing supplemental data alongside samples in the SampleQueue and write
it as a separate field in DecoderInputBuffers.
Handle supplemental data in the VP9 extension by propagating it to the output
buffer.
Handle supplemental data for HDR10+ in MediaCodecVideoRenderer by passing it to
MediaCodec.setParameters, if supported by the component.
PiperOrigin-RevId: 264582805
There is no point in having this parameter as the tag should always be a single
immutable object instantiated at the time the Timeline is created or earlier.
So there is no preformance benefit and it's error-prone in case people
forget to set setTag=true.
PiperOrigin-RevId: 264117041
This solves various issues around event association for buffering and
error throwing around period discontinuities.
The main changes are:
- Logic around being "ready" at the end of a period no longer checks if the
next period is prepared.
- Advancing the playing period no longer checks if the next one is prepared.
- Prepare errors are always thrown for the playing period.
This changes the semantics and assumptions about the "playing" period:
1. The playing period can no longer assumed to be prepared.
2. We no longer have a case where the queue is non-empty and the playing or
reading periods are unassigned (=null).
Most other code changes ensure that these changed assumptions are handled.
Issue:#5407
PiperOrigin-RevId: 263776304
This matches the documentation on MetadataDecoder.decode:
"@return The decoded metadata object, or null if the metadata could not be decoded."
PiperOrigin-RevId: 263767144
Most users are likely to be only interested in the playlist items. So put the
Window definition first and explicitly mention that this is a playlist
item.
PiperOrigin-RevId: 263764515
The current ExoPlayerFactory is growing too big and usage becomes increasingly
complicated because it's not possible to set individual components without
specifying many other defaults.
Adding new builder classes makes building easier and more future-proof.
PiperOrigin-RevId: 263339078
entries are used in .equals(), so it's good to have them printed in toString() too (for test failures) and it makes logging easier too.
PiperOrigin-RevId: 263335503
The current max video buffer is 13MB which is too small for high quality
streams and doesn't allow the DefaultLoadControl to buffer up to its default
max buffer time of 50 seconds.
Also move util method and constants only used by DefaultLoadControl into this
class.
PiperOrigin-RevId: 263328088
We no longer need two modules as AndroidX-Test takes care of the system
abstraction and we no longer have Robolectric Handler/Looper workarounds.
PiperOrigin-RevId: 262363201
I think we need to start clearing the holder as part of the
DRM rework. When we do this, it'll only be valid to read
from the holder immediately after it's been populated.
PiperOrigin-RevId: 262362725
We're no longer tied to the emsg spec, so we can skip unused fields
and assume ms for duration.
Also remove @Nullable annotation from EventMessageEncoder#encode, it
seems the current implementation never returns null
PiperOrigin-RevId: 262135009
We already allow mixed mime type and mixed sample rate adaptation on request,
so for completeness, we can also allow mixed channel count adaptation.
Issue:#6257
PiperOrigin-RevId: 261930046
This also decouples EventMessageEncoder's serialization schema from the emesg spec (it happens to still match the emsg-v0 spec, but this is no longer required).
PiperOrigin-RevId: 261877918
If we keep streams in chunk sources after selecting new tracks, we also keep
a reference to a stale disabled TrackSelection object. Fix this by updating
the TrackSelection object when keeping the stream. The static part of the
selection (i.e. the subset of selected tracks) stays the same in all cases.
Issue:#6256
PiperOrigin-RevId: 261696082
We currently keep the sequence number if we don't reset the position. However,
the sequence number should be kept if we don't reset the state. Otherwise
re-prepare with position reset is counted as new playback although it's still
the same.
PiperOrigin-RevId: 261644924
- When in STATE_SEEK with targetGranule==0, seeking would exit
without checking that the input was positioned at the correct
place.
- Seeking could fail due to trying to read beyond the end of the
stream.
- Seeking was not robust against IO errors during the skip phase
that occurs after the binary search has sufficiently converged.
PiperOrigin-RevId: 261317035
Two tests have very low propability flakiness (1:1000) due to not waiting for
a seek in one case and the chance of already being ended in another case.
Fix these and also adjust wrong comments about state changes.
PiperOrigin-RevId: 261309976
These values can easily default to the empty track group and the empty
selection. As a result we can remove restrictions about not calling
holder.getTrackGroups before the period finished preparation.
PiperOrigin-RevId: 261280927
A previous change switched to calculation of the bitrate based on the
first MPEG audio header in the stream. This had the effect of fixing
seeking to be consistent with playing from the start for streams where
every frame has the same padding value, but broke streams where the
encoder (correctly) modifies the padding value to match the declared
bitrate in the header.
Issue: #6238
PiperOrigin-RevId: 261163904
Android considers ALAC initialization data to consider of the magic
cookie only, where-as FFmpeg requires a full atom. Standardize around
the Android definition, since it makes more sense (the magic cookie
being contained within an atom is container specific, where-as the
decoder shouldn't care what container the media stream is carried in)
Issue: #5938
PiperOrigin-RevId: 261124155
Checking inputPosition == 0 isn't sufficient because the synchronization
at the top of read() may advance the input (i.e. in the case where there's
some garbage prior to the seek frame).
PiperOrigin-RevId: 261086901
This factory was only needed in the past when we didn't have
AnalyticsCollector.setPlayer. Code becomes easier to use without this factory.
PiperOrigin-RevId: 261081860
This new annotation declares everything as non-null by default and can be
used as a package annotation in package-info.java.
In this change the core lib offline package and the mediasession extension is
annotated that way as initial example usage.
PiperOrigin-RevId: 260894548
DefaultMediaClock has currently two non-ideal behaviours:
1. One part of checking if it should use the renderer clock is checking whether
the associated renderer finished reading its stream. This only makes sense
if the renderer isn't already reading ahead into the next period. This can
be solved by forwarding if we are reading ahead to the sync command.
2. When switching from stand-alone to renderer clock we assume they are
exactly at the same position. This is true in theory, but in practise there
may be small differences due to the different natures of these clocks. To
prevent jumping backwards in time, we can temporarily stop the stand-alone
clock and only switch once the renderer clock reached the same position.
PiperOrigin-RevId: 260690468
Both periods are rarely updated in the same iteration. If they are, advancing
the reading period first seems more logical and also more efficient as it may
avoid one extra doSomeWork iteration.
PiperOrigin-RevId: 260463735
When using speed adjustment it was possible for playback to get stuck at a
period transition when the channel count changed: SonicAudioProcessor would be
drained at the point of the period transition in preparation for creating a new
AudioTrack with the new channel count, but during draining the incorrect (new)
channel count was used to calculate the output buffer size for pending data from
Sonic. This meant that, for example, if the channel count changed from stereo to
mono we could have an output buffer size that stored an non-integer number of
audio frames, and in turn this would cause writing to the AudioTrack to get
stuck as the AudioTrack would prevent writing a partial audio frame.
Use Sonic's current channel count when draining output to fix the issue.
PiperOrigin-RevId: 260156541
We keep track of the last publicly known playing period to report it as part
of events happening after the period has been released.
In cases where a period briefly becomes the playing one and is released
immediately afterwards, we currently don't save it as the "last known playing
one". Improve that by saving an explicit reference.
Issue:#5407
PiperOrigin-RevId: 259737218
Creating a period in MaskingMediaSource may result in delayed event reporting
depending on when the actual period gets created. To avoid event reporting
inaccuracies, report the mediaPeriodCreated and mediaPeriodReleased events
directly.
Issue:#5407
PiperOrigin-RevId: 259737170
This changes the logic in the following ways:
- If no preferred language is matched, prefer better scores for the selected
audio language.
- If a preferred language is matched, always prefer the better match
irrespective of default or forced flags.
- If a preferred language score and the isForced flag is the same, prefer
tracks with a better selected audio language match.
PiperOrigin-RevId: 259707430
Some variables were defined although they are the default and other things
were set-up in a non-sensible way, e.g. asserting that audio is selected
although no audio renderer is available, or using unset duration for
everything.
PiperOrigin-RevId: 259532782
PlaybackInfo changes are one of the last ones not masked and reported in the same
way as all other changes.
The main change to support this is to also mask the parameters set in
DefaultAudioSink.
PiperOrigin-RevId: 258787744
1. Using the Locale on API<21 doesn't make any sense because it's a no-op
anyway. Slightly restructured the code to avoid that.
2. API<21 often reports languages with non-standard underscores instead of
dashes. Normalize that too.
3. Some invalid language tags on API>21 get normalized to "und". Use original
tag in such a case.
Issue:#6153
PiperOrigin-RevId: 258773463
2-letter codes (ISO 639-1) are the standard Android normalization and thus we
should prefer them to 3-letter codes (although both are technically allowed
according the BCP47).
This helps in two ways:
1. It simplifies app interaction with our normalized language codes as the
Locale class makes it easy to convert a 2-letter to a 3-letter code but
not the other way round.
2. It better normalizes codes on API<21 where we previously had issues with
language+country codes (see tests).
3. It allows us to normalize both ISO 639-2/T and ISO 639-2/B codes to the same
language.
PiperOrigin-RevId: 258729728
If we use the default start position, we currently resolve it immediately
even if we need to play an ad first, and later try to project forward again
if we believe that the default start position should be used.
This causes problems if a specific start position is set and the later
projection after the preroll ad shouldn't take place.
The problem is solved by keeping the content position as TIME_UNSET (= default
position) if an ad needs to be played first. The content after the ad can
then be resolved to its current default position if needed.
PiperOrigin-RevId: 258583948
These methods helps to indicate that a media source isn't used to create new
periods in the immediate term and thus limited resources can be released.
PiperOrigin-RevId: 258373069
It's easy to forget to forward methods when using basic wrapping. For example,
ExtractorMediaSource.addEventListener is currently a no-op because it's not
forwarded.
PiperOrigin-RevId: 257757556
This is a temporary workaround until we have migrated all MediaSources uses.
This change avoids having to migrate all uses of MediaSources immediately.
PiperOrigin-RevId: 257459138
- Remove manifest argument from callbacks of Player.EventListener and
SourceInfoRefreshListener. Instead make it accessible through
Player.getCurrentManifest() and Timeline.Window.manifest.
- Fix all MediaSource implementation to include the manifest in the
Timeline instead of passing it to the SourceInfoRefreshListener.
- Refactor ExoPlayerTestRunner, FakeTimeline, FakeMediaSource to
reflect these changes and make tests pass.
PiperOrigin-RevId: 257359662
Sending MESSAGE_PREPARE_SOURCE should happen last in the constructor.
It was previously happening before initialization finished (and in
particular before pendingMediaPeriods was instantiated).
Issue: #6146
PiperOrigin-RevId: 257158275
We currently handle most the control code logic after handling special
characters. This includes filtering out repeated control codes and checking
for the correct channel. As the special character sets are control codes as well,
these checks should happen before parsing the characters.
Issue:#6133
PiperOrigin-RevId: 256993672
- Explicitly specify HTTP_METHOD_POST (previously this was
implicit as a result of the body data being non-null)
- Use null when there's no body data (it's converted to
null inside of the DataSpec constructor anyway)
PiperOrigin-RevId: 256573384
Currently, we sometimes apply new playback parameters directly and sometimes
through the list of playbackParameterCheckpoints. Only when using the checkpoints,
we also reset the offset and corresponding position for speedup position
calculation. However, these offsets need to be changed in all cases to prevent
calculation errors during speedup calculation[1].
This change channels all playback parameters changes through the checkpoints to
ensure the offsets get updated accordingly. This fixes an issue introduced in
31911ca54a.
[1] - The speed up is calculated using the ratio of input and output bytes in
SonicAudioProcessor.scaleDurationForSpeedUp. Whenever we set new playback
parameters to the audio processor these two counts are reset. If we don't reset
the offsets too, the scaled timestamp can be a large value compared to the input
and output bytes causing massive inaccuracies (like the +20 seconds in the
linked issue).
Issue:#6117
PiperOrigin-RevId: 256533780
The masking logic for unprepared MediaSources is currently part of
ConcatanatingMediaSource. Moving it to its own class nicely separates the
code responsibilities and allows reuse.
PiperOrigin-RevId: 256360904
1. Only output video starting from a keyframe
2. When calculating the timestamp offset to adjust live streams to start
at t=0, use the timestamp of the first tag from which a sample is actually
output, rather than just the first audio/video tag. The test streams in
the referenced GitHub issue start with a video tag whose packet type is
AVC_PACKET_TYPE_SEQUENCE_HEADER (i.e. does not contain a sample) and whose
timestamp is set to 0 (i.e. isn't set). The timestamp is set correctly on
tags that from which a sample is actually output.
Issue: #6111
PiperOrigin-RevId: 256147747
The total window and period count, as well as the period offset for each holder
are not actually needed and can be removed.
Also added a TODO to remove two other variables if possible.
PiperOrigin-RevId: 255945584
We are currently queuing periods in a way such that the new start position
lines up with the end of the previous period (to ensure continuous playback).
However, if the start position of the new period is larger than the total of
all previously played period durations, we may end up with negative renderer
timestamps when seeking back to the beginning of this new period. Negative
timestamps should be avoided as most decoders have problems handling them
correctly.
This change forces a renderer reset if we detect such a seek to a negative
renderer time and also resets the renderer offset to 0 every time all
renderers are disabled, as this is the only time where we can savely change
the offset of an existing media period.
Also, if playback starts with an ad, we choose the content position as
renderer offset to prevent the whole issue from occurring for the seek-behind-
midroll case.
Issue:#6009
Issue:#5323
PiperOrigin-RevId: 253790054
In some edge cases the renderer position may be slightly ahead of the
buffered position and the total buffered duration is thus negative. We already
filter that in ExoPlayerImpl for the publicly accessible value. However, we
forward the unfiltered value to other components like the LoadControl, which
may be confusing.
Issue:#6015
PiperOrigin-RevId: 253780460
This permission has normal access right and can't be revoked by the user.
However, an app can choose to revoke it when using ExoPlayer, e.g. if
no network is required and the app doesn't want to list this permission.
Support this use case by gracefully catching the exception in the relevant
places.
Issue:#6019
PiperOrigin-RevId: 253759332
We currently report MediaCodec exceptions as unexpected exceptions instead of
as renderer error. All such exceptions are now wrapped in a new DecoderException
to allow adding more details to the exception.
PiperOrigin-RevId: 252054486
It's only thrown in an edge case on API level 20 and below. If it
is thrown it causes playback failure when playback could succeed,
by throwing up through configureCodec.
It seems better just to catch the exception and have the codec be
configured using the format's own width and height.
PiperOrigin-RevId: 251745539
We currently don't display the last frame because the seek time is behind the
last frame's timestamps and it's thus marked as decodeOnly.
This case can be detected by checking whether all data sent to the codec is
marked as decodeOnly at the time we read the end of stream signal. If so, we
can re-enable the last frame. This should work for almost all cases because the
end-of-stream signal is read in the same feedInputBuffer loop as the last
frame and we therefore haven't released the last frame buffer yet.
Issue:#2568
PiperOrigin-RevId: 251425870
Using parallel adaptation for Formats without bitrate information currently
causes an exception. Handle this gracefully and also cases where all formats
have the same bitrate.
Issue:#5971
PiperOrigin-RevId: 250682127
Setting the requested encoding in all cases ensures we receive the relevant
response headers indicating whether gzip was used. Doing that allows to
detect the content length in cases where gzip was requested, but the server
replied with uncompressed content.
PiperOrigin-RevId: 250660890
cache() opens all connections with unset length to avoid position errors.
This makes more data then needed to be downloading by the underlying
network stack.
This fix makes makes it open connections for only required length.
Issue:#5927
PiperOrigin-RevId: 250546175
"Write case, lock not available" was a bit confusing. When the
content is not cached and the lock is held, it's neither a read
or a write case. It's a "can't do anything" case. When blocking,
it may subsequently turn into either a read or a write.
PiperOrigin-RevId: 250530722
The former is deprecated and replaced by the latter in Mockito 2. However, there is a
functional difference: ArgumentMatchers will reject `null` and check the type
if the matcher specified a type (e.g. `any(Class)` or `anyInt()`). `any()` will
remain to accept anything.
PiperOrigin-RevId: 250458607
Removes the need for duplicate calls to SampleQueue#read when
implementing DecryptionResources acquisition in the MediaSources.
PiperOrigin-RevId: 250298175
According to Cue's constructor (for bitmaps) documentation:
+ cuePositionAnchor does horizontal anchoring.
+ cueLineAnchor does vertical anchoring.
Usage is currently inverted.
Issue:#5633
PiperOrigin-RevId: 250253002
The only known use case for contentTypePredicate is to catch
the case when a paywall web page is returned via a DataSource,
rather than the data that was being requested. These days streaming
providers should be using HTTPS, where this problem does not exist.
Devices have also gotten a lot better at showing their own
notifications when paywalls are detected, which largely mitigates
the need for the app to show a more optimal error message or
redirect the user to a browser.
It therefore makes sense to deprioritize this feature. In
particular by removing the arg from constructors, where nearly
all applications are probably passing null.
PiperOrigin-RevId: 249634594
This prevents further unexpected updates if the MediaSource happens to
finish its preparation at a later point.
Issue:#5915
PiperOrigin-RevId: 249439246
The SurfaceListener just sets the surface on the VideoComponent, but
SphericalSurfaceView already accesses the VideoComponent directly so it seems
simpler to update the surface directly.
PiperOrigin-RevId: 249242185
We are currently defaulting to targetSdk=1 as no targetSdk is specified. Only
tests which explicitly ask for another SDK use another test SDK. With the
versioned manifest, all tests run using the targetSDK by default.
PiperOrigin-RevId: 249060796
If a PlayerMessage throws an exception, it is currently not deleted from the
list of pending messages. This may be problematic as the list of pending
messages is kept when the player is retried without reset and the message is
sent again in such a case.
PiperOrigin-RevId: 247414494
Adding an explicit option to clear all downloads prevents repeated database
access in a loop when trying to delete all downloads.
However, we still create an arbitrary number of parallel Task threads for this
and seperate callbacks for each download.
PiperOrigin-RevId: 247234181
1. A content session after an ad has been played was not re-marked as active,
leading to new ad session being marked as active too early.
2. Switching from content to post-roll ended the content session because
the return value of getAdGroupTimeUs of C.TIME_END_OF_SOURCE was not
handled. Using the nextAdGroupIndex instead.
PiperOrigin-RevId: 246977327
As justification for why we should not have this type of logging,
it would scale up to about 13K LOC, 1800 Strings, and 36K (after
pro-guarding - in the case of the demo app) if we did it through
the whole code base*. It makes the code messier to read, and in
most cases doesn't add significant value.
Note: I left the Scheduler logging because it logs interactions
with some awkward library components outside of ExoPlayer, so is
perhaps a bit more justified.
* This is a bit unfair since realistically we wouldn't ever add
lots of logging into trivial classes. But I think it is fair
to say that the deltas would be non-negligible.
PiperOrigin-RevId: 246181421
- Removed DownloadInternal and its sometimes-out-of-sync
duplicate state
- Fixed downloads being in STOPPED rather than QUEUED state
when the manager is paused
- Fixed setMaxParallelDownloads to start/stop downloads if
necessary when the value changes
- Fixed isWaitingForRequirements
PiperOrigin-RevId: 246164845
They behave identically, and the old names are being removed.
Open-source note: The new methods are available in Truth as of version 0.44.
END_PUBLIC
More information:
go/issameas-lsc
Tested:
TAP --sample ran all affected tests and none failed
http://test/OCL:246024032:BASE:246042619:1556672975894:513e7746
PiperOrigin-RevId: 246101315
Can happen if the load position falls behind in every playlist and
when we try to load the next segment, the adaptive selection logic
decides to change variant.
Issue:#5816
PiperOrigin-RevId: 245923006
This resolves some naming confusion that previously existed
as a result of DownloadThread also being used for removals.
Some related variables (e.g. activeDownloadCount) would refer
to both download and removal tasks, whilst others
(e.g. maxParallelDownloads) would refer only to downloads.
This change renames those that refer to both to use "task"
terminology.
This change also includes minor test edits.
PiperOrigin-RevId: 245913671
[Problem]
There are 3 services / modes transported on line 21:
- Captioning
- TEXT (generally not program related)
- XDS (eXtended Data Services)
Bytes belonging to the unsupported modes are interleaved with the
bytes of the captioning mode.
See Chapter 7, Chapter 8.5 and Chapter 8.6 of the CEA608 Standard for
more details.
[Solution]
Drop all bytes belonging to unsupported modes.
[Test]
- All streams containing only captioning services should not be influenced
- Test all 4 CEA 608 channels with live over-the-air content and
using all available TEXT and XDS streams.
There are no logic changes here. It's just moving code around and removing
the "internal" part of names where no longer required.
PiperOrigin-RevId: 245407238
We currently toggle the view in onTouchEvent ACTION_DOWN which is non-standard
and causes problems when used in a ViewGroup intercepting touch events.
Switch to standard Android click handling instead which is also what most
other player apps are doing.
Issue:#5784
PiperOrigin-RevId: 245219728
The AndroidX bundled version (0.42) lags behind the most up-to-date public
release (0.44) making it more difficult to stay close to the actual head
revision which is used internally.
PiperOrigin-RevId: 244848568
This ensures we keep the loading period in sync with the the playing period in
PlybackInfo, when the latter changes to something new.
PiperOrigin-RevId: 244838123
Also re-enable two of them, although note that the fix here is
not related to the flakiness that caused them to be disabled.
I'm re-enabling them since much has changed in DownloadManager,
and the hope is that these tests are no longer flaky.
PiperOrigin-RevId: 244826225
Experiments show this is beneficial for rebuffers with only minor impact
on battery usage.
Configurations which explicitly set a minimum buffer duration are unaffected.
Issue:#2083
PiperOrigin-RevId: 244823642
Before this change we'd release the audio track and create a new one as soon
as audio processors had drained when reconfiguring.
Fix this behavior by stop()ing the AudioTrack to play out all written data.
Issue: #2446
PiperOrigin-RevId: 244812402
- We had buildAddRequest and sendNewDownload. Converged to
buildAddDownload and sendAddDownload.
- Also fixed a few more inconsistencies, and brought the
action constants into line as well.
PiperOrigin-RevId: 244274041
- Listener based reporting of progress allows the content length
to be persisted into the download index (and notified via a
download state change) as soon as it's available.
- Moved contentLength back into Download proper. It should only
ever change once, so I'm not sure it belongs in the mutable part
of Download.
- Made a DownloadProgress class, for naming sanity.
PiperOrigin-RevId: 244242487
1. customCacheKey for DASH/HLS/SS is now asserted against
in DownloadRequest
2. Merging of event delivery in DownloadManager is very
tricky to get right and probably not a good idea
PiperOrigin-RevId: 244048392
Currently SimpleCache will touch cache spans whenever it reads
from them. With legacy SimpleCache setups this involves a potentially
expensive file rename. With new SimpleCache setups it involves
a more efficient but still non-free database write.
For offline use cases, and more generally any use case where the
eviction policy doesn't use last access timestamps, touching is
not useful. This change allows the evictor to specify whether it
needs cache spans to be touched or not. SimpleCache will only touch
spans if the evictor requires it.
Note: There is a potential change in behavior in cases where a
cache uses an evictor that doesn't need cache spans to be touched,
but then later switches to an evictor that does. The new evictor
may temporarily make sub-optimal eviction decisions as a result.
I think this is a very fair trade-off, since this scenario is
unlikely to occur much, if at all, in practice, and even if it
does occur the result isn't that bad.
PiperOrigin-RevId: 244005682
One goal we forgot about a little bit was to allow applications
to provide their own index implementation. This requires the
writable side to also be defined by an interface.
PiperOrigin-RevId: 243979660
ImaAdsLoader gets the player position after the app releases
the player to support resuming ads at their current position
if the same ads loader is reused.
PiperOrigin-RevId: 243969916
ShadowLooper -> ShadowLegacyLooper
ShadowRealisticLooper -> ShadowPausedLooper
ShadowBaseLooper -> ShadowLooper
And all public methods from ShadowLegacyLooper get pushed up to ShadowLooper
Pull Request: https://github.com/robolectric/robolectric/pull/4868
Copybara: OK
Also adjust Google3 tests using custom looper shadows where necessary.
Convert exoplayer to paused looper to eliminate reliance on custom shadows
PiperOrigin-RevId: 243839311
The removed condition only applies when prepare fails and no timeline was or
is known. We should keep a pending seek position in such a case. The internal
player does the same thing already.
PiperOrigin-RevId: 243819466
- Expose constructors that take DatabaseProvider. Deprecate those
that do not.
- Expose Cache.getUid. This will likely be used for naming of the
tables accessed by DefaultDownloadIndex .
PiperOrigin-RevId: 243637786
- Allows enforcing immutability, which in a future CL will allow
avoiding allocating a new array/list on every call.
- Also some left over doc cleanup from the DownloadState rename.
PiperOrigin-RevId: 243627352
The old domain automatically forwards to the new one. For consistency, change
all doc and code references regardless.
Also adds GitHub CNAME config file which configures our page for the custom
domain.
PiperOrigin-RevId: 243592110
handleSourceInfoRefreshed checks for various conditions which may trigger a
change in position. In all cases, we need to resolve the new position for ads,
and if the corresponding MediaPeriods already exist, perform the seek to the new
position.
This change simplified the code by
1. Moving all conditions in a single if-else structure which just determines
the new playback position. This makes it easier to read and to follow.
2. Doing the subsequent seek and position update in one final step to remove
duplicated code.
As a side effect, it also improves some edge cases. For example when skipping
an ad to an already prebuffered period, we now properly update the existing
prebuffered period.
PiperOrigin-RevId: 243588014
- Make a best effort to avoid posting MSG_DOWNLOAD_THREAD_STOPPED
if the internal thread has already quit. Doing so is harmless,
but causes an error in Logcat. We used to generate this warning
quite a bit in ExoPlayerImplInternal as well, and we got quite
a few issues filed about it, so best to avoid it if possible.
- Null out the back reference DownloadThread holds to its manager
on release. This avoids a potential issue where a download thread
can prevent GC of its manager if it doesn't cancel quickly.
There's similar logic (with a similar comment) in Loader.LoadTask.
PiperOrigin-RevId: 243365143
- Rename getAllDownloads to getCurrentDownloads to make it clear
that it doesn't include completed and failed downloads
- Change getDownloadCount to isWaitingForRequirements, which is
what it's used for. Added TODO to make it returns the right thing
PiperOrigin-RevId: 243257856
If the returned retry delay is unset, we should use a DONT_RETRY_FATAL action
instead and dispatch the event with the "canceled" flag.
PiperOrigin-RevId: 243251554
Non-trivial download state transitions are currently split across
DownloadManager and Download. These transitions are part of the
same state machine, so it's clearer if they're all in the same place
(i.e. DownloadManager, since this is the component that transitions
downloads between states).
PiperOrigin-RevId: 243249915
The only state DownloadInternal holds is duplicate of state contained
in Download, but can confusingly be temporarily out of sync. This is
error prone because it's easy to use the wrong variable (e.g.
download.state vs state). DownloadInternals methods are called into
and call out into DownloadManager, which makes some code paths that
are quite hard to follow.
It's possible to simplify DownloadManager quite a lot by removing the
duplicated state in DownloadInternal, at which point DownloadInternal's
methods flatten into DownloadManager, which can just hold an internal
list of Downloads directly.
This is a first step, which makes it clear that DownloadThready only
needs its immutable DownloadAction + an isRemove flag.
PiperOrigin-RevId: 243245288
Put methods into a more sensible order (the same order as
in the switch statement, which is a more natural order with
e.g. initialize coming first and release coming last).
PiperOrigin-RevId: 242891742
- Changed startDownloads/stopDownloads back to their previous behavior
of starting and stopping all downloads at the manager level.
- Made setManualStopReason methods for the new case of setting a manual
stop reason or some or all downloads.
- Added plumbing to specify an initial manual stop reason when adding a
new download, without also overwriting the manual stop reasons of all
other preexisting downloads. Using the value is left as a TODO pending
a bit of further cleanup that'll make it easier.
PiperOrigin-RevId: 242891688
- Remove completed downloads from progress notification.
- Treat restarting as a downloading, When there are both
remove and download tasks ongoing, we prefer to show a
download notification to a remove one. A restarting task
encapsulates is basically a (remove+download) task. Given
our preference, we should treat it as a download rather
than as a removal.
PiperOrigin-RevId: 242867228
Both manifest loads currently use the default retry delay although a
LoadErrorHandlingPolicy is provided to the MediaSource.
PiperOrigin-RevId: 242852672
- Remove NETWORK_TYPE_NOT_ROAMING and NETWORK_TYPE_METERED
because JobScheduler doesn't support them, and they're
probably not useful to many people (data when roaming is
normally enabled/disabled at the OS level, and restricting
to *only* metered networks seems niche)
- Convert network requirements proper flags
- Stop persisting requirements in DownloadIndex. The direction
we're headed to solve the manager start/stop problem is
going to involve state in DownloadManager determining whether
downloads actually start, and if we're doing that then it's
no worse to do it for this as well
PiperOrigin-RevId: 242713196
Robolectric calls messages posted to the main thread immediately inline. This
will change in the upcoming release and will break tests implicitly relying
on that behavior.
Update ConcatenatingMediaSourceTest to actually wait for the posted message.
PiperOrigin-RevId: 242631531
HashMap.values does not guarantee a stable order, but our tests
assert that the order is stable. It's probably a nice property
that the order is the same as that in which downloads are added,
so this change makes the order stable, with that order.
A future change will likely improve the way this works, by
changing the internal thread "downloads" variable to have type
ArrayList<Download>, at which point the internal thread can just
pass a read-only copy of its list to the main thread whenever a
state changes.
PiperOrigin-RevId: 242460725
- Fix ID being dropped when DownloadAction is serialized and
de-serialized as it's passed to DownloadService
- Properly set DownloadAction.id when building an action from
a DownloadState
- Make ID a required constructor argument. Else it's too easy
to not propagate it by accident.
PiperOrigin-RevId: 242457831
Remove MediaCodecSelector.DEFAULT_WITH_FALLBACK, as codec selectors
will need to be able to return a list of decoder infos even when not
using fallback in a later change. Instead signal that fallback should
be used via a renderer constructor.
Fallback is always disabled for audio.
PiperOrigin-RevId: 242454172
Adding a protected method for that allows to supply a customized
TrackOutputProvider to the ExtractorWrapper used by the ContainerMediaChunk
(e.g. for logging purposes).
The alternative would be to provide a TrackOutputProvider through the
ChunkSampleStream constructor, but the extra initialization taking place
in the ChunkSampleStream constructor would need to move somewhere else and
some methods of BaseMediaChunkOutput would need to move to the
TrackOutputProvider interface. This seems too much effort for niche
customization case.
PiperOrigin-RevId: 242448776
The position should be subtracted from the total content length
retrieved from the cache in this case, both for iteration and for
filling out counters.contentLength (for the latter, note not
doing it this way is inconsistent with what happens when dataSpec
length is set to a known value).
PiperOrigin-RevId: 242445034
It's a transient state whose only use is when passing a removed
download to onDownloadStateChanged. It's a bit strange to have it
as a proper state, since we end up asserting that it's an invalid
value in other places.
This change adds an explicit onDownloadRemoved, which allows
removal of the transient STATE_REMOVED, related assertions, and
uncertainty when dealing with an @State variable whether it's
necessary to handle it being STATE_REMOVED.
PiperOrigin-RevId: 242444128
This is the last cl of a series of cls that will convert DownloadManager
threading model as public methods post actions on an internal thread
which then do the work.
PiperOrigin-RevId: 242437229
The priority task manager only needs to listen to loading state changes and
is independent of the rest of DefaultLoadControl. This also fixes problems
where the player stops loading without consultin the LoadControl.
PiperOrigin-RevId: 242098374
This is the second cl of a series of cls that will convert DownloadManager
threading model as public methods post actions on an internal thread
which then do the work.
PiperOrigin-RevId: 241773765
Necessary for implementing scheme-independant resource management.
Example: A media source needs to have ownership of a crypto resource
while samples are in buffer (but not yet in the renderer).
PiperOrigin-RevId: 241698575
Most of our components that have Handler instances for calling
back to application code instantiate the Handler using Util.getLooper
in the constructor. This makes the two components that do
something else consistent with that model.
PiperOrigin-RevId: 241545575
If no track matches the preferred language or no preferred language is provided,
use the system Locale language as the next decision criterion.
PiperOrigin-RevId: 241322703
- This removes the need for Variant and Rendition to have a common
base class, allowing the url field to be marked as @Nullable in
Rendition but not in Variant.
- The addition of mediaPlaylistUrls is needed for the new StreamKey
indexing for HLS. It's also convenient in a couple of places (e.g.
HlsDownloader), where a list of all media playlist URLs is needed.
- Lots of places where HlsUrl was passed only needed the actual
URL (not the Format, which is the other piece of HlsUrl). Passing
just the URL is a little simpler, and resolves some of the naming
confusion.
Issue: #5596
Issue: #2600
PiperOrigin-RevId: 240970466
This is to make it possible to use equality of HlsUrl.url fields
to determine whether two HlsUrls point at the same media playlist.
This doesn't work currently because it's possible to mix absolute
and relative urls, which will not be equal until after the relative
url is resolved against the playlist baseUrl.
Issue: #5596
Issue: #2600
PiperOrigin-RevId: 240966503
Also make combination of language and role flags the default over the label,
as it's more readable and auto-translated into other languages.
PiperOrigin-RevId: 240801070
Custom factories currently need to copy most of the code in the
AdaptiveTrackSelection.Factory to make use of the same functionality.
Simplify this by allowing to overwrite the factory.
PiperOrigin-RevId: 240773271
This is the first of a series of cls that will convert DownloadManager
threading model as public methods post actions on an internal thread
which then do the work.
PiperOrigin-RevId: 240743400
Still skipping any renditions that have a null URL, which means that
closedCaptions in particular is always empty. This restriction will
be removed in a subsequent change, which will also remove muxedAudioFormat
and muxedAudioCaptions from HlsMasterPlaylist and instead derive them
from the Variant and Rendition information in HlsMediaPeriod.
Issue: #5596
Issue: #2600
PiperOrigin-RevId: 240623500
The one functional change here is to require subclasses to implement getForegroundNotification. It seems easier and less error prone to
force developers to implement it than it does to document the cases
in which they need to override it (which is most cases).
PiperOrigin-RevId: 240566737
Issue: #5596
This arguably made a worse problem than it solved, and also I think subtly broken HLS
downloads by changing which renditions HlsMasterPlaylist.copy would retain in some
cases. Reverting as a mini step toward removing smart logic from the HLS playlist parser.
*** Original commit ***
Expand check for muxed audio media tags to include uris that match variants
Issue:#5313
***
PiperOrigin-RevId: 240348969
If enabled, DefaultTrackSelector returns multiple groups with more than one
track. AdaptiveTrackSelection then decides on the order in which the tracks
are changed such that the BandwidthProvider for each selection can figure out
the allocated bandwidth.
PiperOrigin-RevId: 240150206
It's currently very difficult to actually set a reason for track selection
triggered by a SelectionOverride. It would require creating a new custom
TrackSelection.Factory where the reason gets injected somehow before the
override is specified on the player.
Simplify this whole procedure by allowing to set the reason directly and
forward this reason to all fixed selections created based on this override.
PiperOrigin-RevId: 240114942
3 ("11") is the reserved code for fscod in AC3. The spec says that "If the
reserved code is indicated, the decoder should not attempt to decode audio and
should mute."
We currently throw an exception as we try to access an array with an invalid
index. Now ignoring the track instead by invalidating the format.
Issue:#5638
PiperOrigin-RevId: 240106255
This allows to distinguish between regional variants and scripts.
We still need to normalize the language code itself to make track selection
independent of the whether 2 or 3 letter codes are used.
PiperOrigin-RevId: 239783115
Any seek map with non-zero offsets breaks playback with ICY metadata as
the metadata is no longer read from the correct position.
Issue:#5658
PiperOrigin-RevId: 239605839
*** Reason for rollback ***
Trying to forward fix instead.
*** Original change description ***
Automated g4 rollback of changelist 237051112.
*** Original change description ***
Add SimpleCache deletion functionality
This is needed now that index data may be stored outside
of the cache directory.
***
***
PiperOrigin-RevId: 239429430
*** Original change description ***
Add SimpleCache deletion functionality
This is needed now that index data may be stored outside
of the cache directory.
***
PiperOrigin-RevId: 239294713
When an error occurs we call stopInternal, and this clears the MediaPeriodQueue,
which in turn releases media period holders and notifies that media periods have
been released. AnalyticsCollector updates its information about media periods
using the media period release events, which means that if we post the source
error after stopInternal posts its events we can't determine what media period
the source error corresponds to.
Move error notifications before calling stopInternal, so that
AnalyticsCollector's model of the media period queue contains the loading period
at the point when it handles the error.
For consistency also move the other (non-source) error notifications to match
the new ordering.
PiperOrigin-RevId: 238559324
This simplifies the DownloadHelper code in the demo app and is generally
useful for more specific updates with SelectionOverrides.
PiperOrigin-RevId: 238228276
This replaces the deprecated usages of RobolectricTestRunner and
RuntimeEnvironent and fully migrates the tests to androidx.
PiperOrigin-RevId: 238011667
We may currently throw if the load completes before we finished preparation.
Don't throw and instead check for this condition in maybeThrowPrepareError.
PiperOrigin-RevId: 237237000
These are thrown for non-IOException encountered during loading. Also, they
are thrown from an unexpected position and retrying is likely to fail anyway
because the Extractor is left in an unrecoverable state.
PiperOrigin-RevId: 237043948
SQLiteException is a runtime exception, which makes it easy to
forget to handle it. This change converts SQLiteExceptions into
a checked exception, which is then handled appropriately.
PiperOrigin-RevId: 237038793
Currently a flags-only DecoderInputBuffer may hold only the end-of-stream
flag. This change makes flags-only buffer read any kind of flag set in
the next sample. If no sample is available RESULT_NOTHING_READ is
returned.
PiperOrigin-RevId: 237027581
nalPrefix.readUnsignedIntToInt() will throw if the unsigned output doesn't fit
in an int. Before this change, in the error case we'd retry reading from after
the NAL prefix position. Throw a ParserException so that reading an obviously
invalid NAL prefix will be treated as a fatal exception by the default load
error handling policy.
PiperOrigin-RevId: 236839690
There are 6 different situations which are now more explicitly covered to
ensure we handle them correctly:
1. Radio button (non-adaptive, single group only)
Selected -> Do nothing.
Unselected -> Replace override with selected track.
2. Check box (non-adaptive, but multi-group allowed)
Selected -> Remove track (and override). If last one, set isDisabled flag.
Unselected -> Replace override with selected track.
3. Check box (adaptive allowed, single or multi group)
Selected -> Remove track. If last, remove override and maybe set isDisabled.
Unselected -> Add track to override.
PiperOrigin-RevId: 236668642
The release needs to post to the MediaSource thread and also needs to post
back to the DownloadHelper thread to prevent sending updates after release has
been called. The point where we release the downloadHelper also needs to
dismiss the dialog in case the creation has already been queued before the
release.
PiperOrigin-RevId: 236652309
This is more in line with "forgetting all previous state" as documented for
resetState=True. Also only apply the current position as initial seek position
in this case.
PiperOrigin-RevId: 236623630
We currently throw if a pending seek position was valid when the user issued
it on the app thread, but can't be resolved on the playback thread because the
timeline changed in the meantime. Throwing in this case seems wrong as the
user could not have known about the issue (and the seek position was actually
valid). Also, in other cases where the currently playing period is no longer
in the new timeline, we gracefully use a subsequent period or transition to
ENDED state instead of throwing. So it seems more consistent to transition to
ENDED state as well.
PiperOrigin-RevId: 236274862
Instead just set the currently clicked item as override. If the already
selected button is clicked, the override is reset with the same value.
PiperOrigin-RevId: 236118429
We currently do not show check boxes if the renderer does not support adaptive
switches between tracks in one group. However, we assume check boxes in the
onClick method.
Use same logic for both methods to be consistent.
PiperOrigin-RevId: 236118372
The flag in ExoPlayer.prepare is documented as keeping the current window
index and window position. We are currently using the current period UID and
period position instead. This causes problems when the media source is changed
but the position is not reset.
Using the initial seek position instead ensures we actually use the window
index and position.
Issue:#5520
PiperOrigin-RevId: 236101024
Adding new error types may cause issues when listeners assume a fixed set of
error types and don't handle arbitrary defaults.
Fixing error handling in one case and improving documentation to make people
aware of the issue.
PiperOrigin-RevId: 236093265
While disabled the renderer does not have non-null stream formats. This means
that setting the operating rate could cause a NullPointerException if there was
a codec for reuse.
Check for being enabled/started before trying to set the operating rate. After
the renderer is enabled it should receive a new input format which will update
the operating rate as needed.
PiperOrigin-RevId: 235494384
If the DefaultAudioSink was reconfigured in a way that was compatible with the
previous configuration just after having been reset, we would try to drain audio
processors despite not having an AudioTrack. This could result in a
NullPointerException if speed adjustment was active.
Fix this behavior by only trying to drain audio processors if we actually have
an AudioTrack.
PiperOrigin-RevId: 235355466
- Expose constructor (package private for now, for tests only)
- Add some tests for cache initialization
- Add some TODOs for handling initialization failure
PiperOrigin-RevId: 235188386
*** Reason for rollback ***
Breaks ExoPlayer's gradle build
*** Original change description ***
Migrate Mockito Matchers.{hamcrestMethods} to MockitoHamcrest.{hamcrestMethods}
All methods accepting a hamcrest Matcher in org.mockito.Matchers have been changed
to only accept an ArgumentMatcher. The corresponding methods are now available on
MockitoHamcrest.
For more information see http://go/mockito-2-lsc
Tested:
TAP --sample for global presubmit queue
http://test/OCL:235033293:BASE:234998256:1550793421835:c2ccbbda
***
PiperOrigin-RevId: 235186705
All methods accepting a hamcrest Matcher in org.mockito.Matchers have been changed
to only accept an ArgumentMatcher. The corresponding methods are now available on
MockitoHamcrest.
For more information see http://go/mockito-2-lsc
Tested:
TAP --sample for global presubmit queue
http://test/OCL:235033293:BASE:234998256:1550793421835:c2ccbbda
PiperOrigin-RevId: 235153912
*** Reason for rollback ***
Reverting as this may break playback on other Amlogic devices and/or playback of non-interlaced content.
*** Original change description ***
Add max video size workaround for Amlogic decoder.
The Amlogic awesome decoder reduces the video size of interlaced videos by half
if the internal configuration isn't force reset with new maximum input size
values. The product of these new values must exceed 1920x1088 to force the
reset.
Issue:#5003
***
PiperOrigin-RevId: 234967314
Currently IMA determines that the overlay is obstructing, even
if it's empty. Register it as friendly, which means we're
assuming that anything the apps puts in it is necessary for
playback.
PiperOrigin-RevId: 234963065
HlsSampleStream#read should return end of stream when
there is no mapping for the sample stream, instead of
nothing read. This allows the player to transition to
ended.
Issue:#5524
PiperOrigin-RevId: 234764027
- Use Cache UID for CacheContentIndex and CacheFileMetadataIndex. This
enables SD card swapping for a single device.
- I'm hopeful of finding a way to get the Cache UID to DefaultDownloadIndex
so we can do the same there.
PiperOrigin-RevId: 234662753
Horizontal orientation doesn't make sense. I thought about
overriding the setter to throw something, but it's probably
not worth the extra lines.
PiperOrigin-RevId: 234632530
This bug affects any playlist that uses initialization segments. In practice,
almost exclusively fragmented mp4 segmented playlists are affected.
The bottom line is that extractors are chosen for reuse after the
initialization segment connection is open. However, reused extractors
do not need re-parsing the init segment, so loading the initialization is
wasteful.
PiperOrigin-RevId: 234479467
TrackSelectionView requires an initialization with a call to init(...).
That's why we shouldn't let the view retain its view hierarchy automatically
as the views won't be backed by data if restored. Instead add a listener
which lets the containing activity/fragment save and restore the state if
needed.
PiperOrigin-RevId: 234152491
This is a temporary fix to prevent NullPointerException exceptions.
Though writing to cache will still fail if the cache folder isn't a real
folder.
There are a few thing we can try:
* The listing might be failing because the cache folder is just created.
We can wait and try again.
* If the cache folder is a regular file, we can try deleting and creating
a folder with the same name.
PiperOrigin-RevId: 234121925
Previously we would get a new AudioTrack and flush all audio processors if any
AudioProcessor needed to be flushed on reconfiguration. This was problematic for
the case of TrimmingAudioProcessor because it could become active or inactive
due to transitioning to a period with gapless metadata or without it (we don't
keep it active all the time because it is wasteful to populate its end buffer
for content that is not gapless).
This change handles the case where we don't need an AudioTrack but
AudioProcessors do need to be flushed. In this case we drain all the audio
processors when next handling data then switch to the new configuration.
This avoids truncation when period transitions change whether
TrimmingAudioProcessor is active but don't require a new AudioTrack, and is also
a step towards draining the AudioTrack when transitioning between periods if we
do need a new AudioTrack.
To do this, it needs to be possible to drain any pending output data from an
AudioProcessor after it's configured to a new format, so this change makes sure
AudioProcessors allow calling playToEndOfStream and getOutput after
reconfiguration and before flush.
PiperOrigin-RevId: 234033552
This cleanup is in preparation for draining audio processors on reconfiguration
to a format that doesn't require a new AudioTrack to be created.
PiperOrigin-RevId: 233990983
Stop encoding/decoding presentation time as part of the message.
What's actually in emsg boxes is a presentation time delta,
which is why it's only 32 bits, and hence why it doesn't handle
large absolute timestamps. We were using this field to hold
absolute timestamps only for the purpose of passing presentation
times from DashManifestParser.parseEvent back to the calling
method. After this change, we return Pair<Long, EventMessage>
instead.
Issue: #5490
PiperOrigin-RevId: 233561731
builder.mActions is marked as @RestrictTo(LIBRARY_GROUP). We'll
just have to put up with notification flicker on KitKat if the
actions change.
PiperOrigin-RevId: 233420076
Switch from passing an ad UI ViewGroup to passing an object that can also
provide information about controls overlays.
Also switch to using a dedicated overlay for ads instead of the overlay frame
layout, which apps have easy access to.
PiperOrigin-RevId: 233393500
Supporting multiple overrides allows to select tracks from multiple groups, if
enabled. As more options are added, the creation of the dialog is moved to a
separate builder class.
PiperOrigin-RevId: 233366282
Imported from GitHub PR https://github.com/google/ExoPlayer/pull/5438
Plus the following changes:
- Only support profile 5 (handling other profiles requires
backward-compatibility changes in the renderer which are left for a later
change.)
- Only add KEY_PROFILE to the codec configuration MediaFormat for Dolby Vision.
- In MediaCodecUtil support all DV profiles that Android has constants for. This
includes ones that are "not supported for new applications". Since we don't
extract these profiles, this is currently only for the benefit of custom
extractors.
- Misc code style fixes and reordering for consistency.
Merge 37878b975c2bc082b0568e21cbe62bfcef97c10d into 67be9e7783
PiperOrigin-RevId: 233066799
Given the change to require setPlayer on AdsLoaders, it seems like a good
opportunity to clean up deprecated ads-related symbols.
PiperOrigin-RevId: 233020171
When SimpleCache uses a CacheFileMetadataIndex, it will be able to avoid
querying file.length() and renaming files, both of which are expensive
operations on some file systems.
PiperOrigin-RevId: 232664255
Now we're reusing the builder, it's necessary to set maxProgress
back to 0 to avoid the progress bar appearing for end state
notifications.
PiperOrigin-RevId: 232520007
DefaultDownloadIndex is currently just forwarding all calls to its
inner class. getDownloadTable() handles initialization, but this
doesn't really seem different to having an initialization method. It
doesn't guarantee initialization happens, since a bad method
implementation could try and access downloadTable directly, just as
a bad method implementation could forget to call the initialization
method. Hence this change removes the indirection.
PiperOrigin-RevId: 232482228
This combines all the different listeners in ExoVideosPlayerV2 into one and
moves the PlaybackLogger class towards ExoPlayer's AnalyticsCollector with
the same purpose.
In the future this allows two things:
1. Gradually move LogginClient implementations to AnalyticsListener to
prevent custom event forwarding.
2. Using ExoPlayer's QoE extension (which is also an AnalyticsListener).
PiperOrigin-RevId: 232321182
When calling releaseSource(), all pending messages will be removed. That means
that all action-on-completion callbacks which are somewhere in flight are
just dropped without being called. This change adds code to keep track of the
current state of each callback to allow all of them being called when the
source is released.
Issue:#5464
PiperOrigin-RevId: 232312528
This change enables transitioning to/from different Storage
implementations, to allow experimentally enabling (and if
necessary, disabling) SQLiteStorage. All that's left to do
is the final wiring to turn it on
PiperOrigin-RevId: 232304458
If there is data after the last samples in the container, we may request
continue loading after the last samples have been read but before the load has
completed. In this situation the buffered position is returned as
Long.MAX_VALUE, which prevents continuing loading, yet the media period is not
treated as fully buffered because its buffered position is not
C.TIME_END_OF_SOURCE.
PiperOrigin-RevId: 231406964
We can keep the reading media period and continue playing if we haven't read
beyond the new duration. Otherwise, we can keep the period, but need to reset
the renderers as we already read too far.
PiperOrigin-RevId: 231406252
It better describes what the class does. More importantly, we've had
inconsistent class names since we added offline support, for which we
added ProgressiveDownloader ("ExtractorDownloader" doesn't make any
sense). We could really do with aligning the names for clarity.
(Sorry)
PiperOrigin-RevId: 231387268
This requires to prepare the media source and the periods in a small helper similar
to the metadata retriever. It also gets rid of the need to have abstract protected
methods to load the manifest, to extract the track groups and to convert to stream keys,
as this can now be handled by the media period.
PiperOrigin-RevId: 231385590
Currently, we remove all variants if none of the stream keys contains any
variants. This causes HlsMediaPeriod to throw exceptions as it expects at least
one variant.
Change it to support master playlists without variants.
PiperOrigin-RevId: 231385547
Converting a single track selection to stream keys is only possible if the output
is independent from other track selections being made.
This is not the case for DASH and HLS embedded track groups which should select the
already selected primary track if possible (and thus needs to know whether a primary
track group is selected).
Also, update the test method to take a period index.
PiperOrigin-RevId: 231385490
The way it is currently, it's very unclear that an operation on the
version table will correctly belong to a transaction in code such as
this, taken from DefaultDownloadIndex:
writableDatabase.beginTransaction();
try {
writableDatabase.execSQL(...);
versionTable.setVersion(...);
writableDatabase.setTransactionSuccessful();
} finally {
writableDatabase.endTransaction();
}
This change explicitly passes the database, to make it obvious that
the operation will really go into the same transaction:
writableDatabase.beginTransaction();
try {
writableDatabase.execSQL(....);
VersionTable.setVersion(writableDatabase, ...);
writableDatabase.setTransactionSuccessful();
} finally {
writableDatabase.endTransaction();
}
PiperOrigin-RevId: 231374933
Float output is only possible from API 21, but the high-res int
to float conversion path was checking for 32-bit PCM not float
output capability.
PiperOrigin-RevId: 231172495
This will allow CachedContentIndex to start using database
storage without us having to change the SimpleCache and
CachedContentIndex constructors to require a Context or a
DatabaseProvider.
PiperOrigin-RevId: 230884501
If are allowing changing durations of periods, we shouldn't use the end position
of clipped content as part of the id as it may change. This change moves the end
position back to MediaPeriodInfo and adds the next ad group index to the id
instead to ensure we still have unique ids for all content parts.
PiperOrigin-RevId: 230878389
The combination of pre-16 API levels accounting for ~0.5% of the device
population, and that the most important components in ExoPlayer (e.g.
the MediaCodec renderers) have always required API level 16, mean it's
very unlikely this will negatively impact on anyone.
PiperOrigin-RevId: 230701808
We need to support serialization to/from an SQLite table. The
model of passing something around for each class to write into
doesn't work well for SQL, and it would be messy to have two
different structural designs for serialization. This change
centralizes the logic in CachedContentIndex, where a centralized
SQL based version can more easily sit alongside it.
PiperOrigin-RevId: 230692291
This method is a generalization of the existing hasReadStreamToEnd. It is
useful to determine whether a renderer already read beyond a new duration of
a period.
PiperOrigin-RevId: 230689165
1. The method kept track of the current period index to check if the next
period is still in the correct period. This is unneccessary since we no longer
use the period index but the actual uid in MediaPeriodId and mismatches are
already detected by canKeepMediaPeriodHolder.
2. We updated the MediaPeriodIndfo twice: once in getFollowingMediaPeriodInfo
and once in getUpdatedMediaPeriodInfo. That's confusing and difficult to
follow. The only difference is that getUpdatedMediaPeriodInfo keeps the
content position while getFollowingMediaPeriodInfo resets it. This is made more
explicit for readability.
3. The durations compatibility check for all following periods was broken as
it compared the same durations (partly due to the confusion caused by 2.)
PiperOrigin-RevId: 230519295
* Add AC-4 MIME type definition
* Add AC-4 format support in Mp4Extractor and TsExtractor
* Add AC-4 Extractor
* Add AC-4 playback support in MPEG-4, MPEG-DASH, TS and HLS
ExoPlaybackExceptions of type SOURCE are always associated with the loading
period and thus we can use the event time for the loading period in
onPlayerError. Renderer and unexpected exceptions are still associated with the
currently playing period.
Issue:#5407
PiperOrigin-RevId: 230216253
The Amlogic awesome decoder reduces the video size of interlaced videos by half
if the internal configuration isn't force reset with new maximum input size
values. The product of these new values must exceed 1920x1088 to force the
reset.
Issue:#5003
PiperOrigin-RevId: 230206675
That's the same position set in MediaPeriod.prepare (where it may be removed
in the future).
Having the position at an earlier point is necessary to fix an
issue with lazy preparation in ConcatenatingMediaSource where the prepare
position was assumed to be known but MediaPeriod.prepare hasn't been called
yet.
Issue:#5350
PiperOrigin-RevId: 229756637
[Problem]
CC1 is shown even when CC2-3-4 is selected
[Solution]
* use incoming channel and frame information
* Misc Codes need to handle use Frame information
* Add checks everywhere
[Test]
* Live channels and already existing test should not show any difference
in behavior when CC1 is selected.
* Live channels might have CC2-CC3-CC4
* Sarnoff test content has specific test cases for channel support
When the extra adaptation set of a switch group isn't defined in the manifest, we
currently assume it's the first adaptation group. This either leads to wrong grouping
or duplicate track groups.
Such a case may easily happen if the manifest is filtered such that only one of the
switch adaptation sets will be present in the manifest.
PiperOrigin-RevId: 229365379
The buffered position is currently based on the mimimum queued timestamp of
all AV tracks. If the tracks have unequal lengths, one track continues loading
without bounds as the "buffered position" will always stay at the shorter
track's duration.
This change adds an optional buffer flag to mark the last sample of the
stream. This is set in the Mp4Extractor only so far. ExtractorMediaSource
uses this flag to ignore AV streams in the buffered duration calculation if
they already finished loading.
Issue:#3670
PiperOrigin-RevId: 229359899
That was previously handled by the player. But since we switched to Handler
messages instead of player messages, we should do that manually.
PiperOrigin-RevId: 229341747
This is not necessary as the track selection needs to be updated with
updateSelectedTrack anyway. It's also error-prone as the selection code
calls into a protected method of a not fully initialized class.
PiperOrigin-RevId: 229331669
DataSpec.FLAG_ALLOW_CACHE_FRAGMENTATION is added to indicate to the
cache when fragmentation is allowed. This flag is set for progressive
requests only.
To avoid breaking changes, CacheDataSink defaults to ignoring the flag
(and enabling fragmentation) for now. Respecting the flag can be
enabled manually. DownloaderConstructorHelper enables respecting of
the flag.
Issue: #4253
PiperOrigin-RevId: 229176835
We currently forget whether a source is seekable at re-preparation. This was
implemented intentionally this way under the assumption that we really can't seek
until we have loaded the seek map again. However, seek operations are only
allowed after a media period is prepared. So there is no harm in remembering
whether a source is seekable.
This problem currently prevents reusing ClippingMediaSources with
ExtractorMediaSource and a non-zero start clip position.
Issue: #5351
PiperOrigin-RevId: 229169441
ExoMediaCrypto.requiresSecureDecoderComponent() is removed, and
FrameworkMediaCrypto.forceAllowInsecureDecoderComponents is made
public to allow determining whether a secure decoder is required
to be implemented in MediaCodecRenderer.
PiperOrigin-RevId: 228909771
There were some edge cases in which we'd forget to release DRM
sessions. For example if we read a format and acquired a
pendingDrmSession (in onInputFormatChanged), then immediately
read another format and overwrote pendingDrmSession, we'd
forget to release the one that's been overwritten.
This change hopefully makes release much clearer. We keep a list
of all drm sessions we're currently holding. Whenever we update
either drmSession or pendingDrmSession, we release any other
sessions that are in the list.
PiperOrigin-RevId: 228905465
The window object is used without being filled with data. This used to work
well for most cases as the same live stream is sending regular updates and the
first update is almost never used if it's not the first item in a playlist.
It causes problems when the first timeline update of a live stream is actually
used for playback (e.g. when the live stream is lazily prepared in a playlist
and played first).
PiperOrigin-RevId: 228530232
Reported in https://github.com/google/ExoPlayer/issues/3860
For failing examples see the github link above.
[Problem]
We drop matching control codes even if they are not received on
consecutive frames.
The specification says
"(4) If the first transmission of a control code pair passes parity,
it is acted upon within one video frame. If the NEXT frame contains
a perfect repeat of the same pair, the redundant code is ignored."
Keyword is the NEXT. The frames must arrive immediately after
each other.
See https://www.law.cornell.edu/cfr/text/47/79.101
[Solution]
Set an additional flag when any data is processed. Control code
duplication checks should be limited only for the first control
byte pairs processed after any control code.
[Test]
Sarnoff tests have equivalent CEA708 and CEA608 Streams.
This is the initialization part of mitigating issue #4253. The
remaining work is on the writing side, and is simply a case of
having startFile return File instances that are sharded into
sub-directories. We still need to decide what scheme we want
to use for doing that.
Issue: #4253
PiperOrigin-RevId: 228306327
Calls to File.length() can be O(N) where N is the number of files
in the containing folder. This is believed to be true for at least
FAT32. Repeated calls for the same file tend to be faster,
presumably due to caching in the file system, however are still
surprisingly expensive. Hence minimizing the number of calls is
preferable.
Issue: #4253
PiperOrigin-RevId: 228179921
They are not longer needed anywhere, are error-prone (because of threading
requirements), and complicate testing and using MediaSources without a player.
PiperOrigin-RevId: 227871157
We currently either use the app thread returned by the player or the thread
the commands are called on depending on whether the media source is already
prepared or not.
This change lets the application decide which callback thread to use. As a
side effect, we also don't longer need access the player instance passed to
MediaSource.prepare.
PiperOrigin-RevId: 227871111
Also configure the FFmpeg context to ignore errors as far as possible (this
appears to have an effect only for certain decoders).
Issue: #5293
PiperOrigin-RevId: 227851397
The top level requirement only tried to ensure that the entire timeline only
has one period. This is already asserted by ImaAdsLoader. AdsMediaSource
itself works fine as long as the wrapped timeline has one period only. This
is now asserted instead.
PiperOrigin-RevId: 227682141
Passing the player through MediaSource.prepare is only needed for the AdsLoader
and complicates other usages of MediaSource. Providing the player directly to
the AdsLoader is also in line with the usage pattern of PlayerView and other
components.
Also rename methods to start/stop to better reflect their usage.
PiperOrigin-RevId: 227682112
Made DownloadState top level class.
Replaced action field DownloadAction fields.
Added removing, removed and restarting states.
Renamed started state to downloading.
PiperOrigin-RevId: 227664735
ExoPlayer methods must not be called from any thread besides the specified
app thread. Therefore we shouldn't use them here. Using a regular Handler
instead is fully equivalent.
Issue:#5240
PiperOrigin-RevId: 227650489
- Increase the default cache file size to 5MB
- Recommended a minimum cache file size of 2MB to discourage
applications from specifying values small enough such that
unreasonably large numbers of cache files are generated
- Allow maxCacheFileSize=C.LENGTH_UNSET, equivalent to setting it
to MAX_VALUE. This is just for API consistency with other APIs
we have that accept LENGTH_UNSET
Issue: #4253
PiperOrigin-RevId: 227524233
CacheEvictor.onStartFile currently receives a length, which is the
maximum size of the content that might be written. The LRU cache
evictor will make sure there's sufficient space for the specified
size. If the actual size of the content is unknown, CacheDataSink
passes maxCacheFileSize.
The current behavior isn't ideal. It seems valid for a developer to
specify maxCacheFileSize=Long.MAX_VALUE if they don't want any
file fragmentation in the cache. However if they then attempt to
cache something with unknown length, LRU cache will try and make
room for content of length Long.MAX_VALUE, and end up evicting the
entire cache to do so.
This change alters the logic so a length is only passed if the
actual size of the content is known. In other cases C.LENGTH_UNSET
is now passed. The LRU evictor will not evict until after the file
is committed. Note a custom LRU evictor could still opt to evict to
ensure some application specified amount of space, if that's the
desired behavior.
PiperOrigin-RevId: 227509525
This also applies when seeking or transitioning to unprepared media, which
isn't clear from the current documentation.
Issue:#5267
PiperOrigin-RevId: 226486685
* Add AC-4 MIME type definition
* Add AC-4 format support in Mp4Extractor and TsExtractor
* Add AC-4 Extractor
* Add AC-4 playback support in MPEG-4, MPEG-DASH, TS and HLS
When a Download is created it's set to queued state but doesn't notify
listeners about this state. DownloadManager checks if it can start the
download. After this checks it notifies the listeners.
With this change Download can immediately check if it can be started and
sends correct notification.
PiperOrigin-RevId: 225967129
Problem: There is nothing in the Cache interface that enforces that
these methods are implemented by reading/writing content metadata,
however our own code (CacheDataSource) relies on this property since
it mixes use of [get|set]ContentLength and use of metadata. Using
metadata is the right approach because it minimizes the number of
index writes (e.g. it allows the redirect URI and the content length
to be committed by a single write).
Solution: Remove [get|set]ContentLength, which are redundant anyway,
and use metadata everywhere. Also expose the keys being used through
the public API; there's no particular reason why they shouldn't be.
We previously had an API for getting and setting content length, but
no API for getting and setting redirect uri.
PiperOrigin-RevId: 225383211
This adds the basic track selection capabilties (including tests).
The new capabilities are not exposed yet through the DownloadHelper implementations
and there will also be more helper methods (e.g. to select multiple audio lanuages at
once).
PiperOrigin-RevId: 224518477
We currently have two factory methods where it is completely unclear which one needs
to be overridden.
This change deprecates the old one, adds a Util method to easily map back from the new
to the old behaviour, and updates all implementations of the now deprecated method in
our code.
PiperOrigin-RevId: 224303560
[Problem]
As the alignment of each lineas are calculated individually, the
artificially introduced CENTER and RIGHT alignments can be mixed
with each other and with the default LEFT alignment. The mixed results
look worse than just using the original DEFAULT, and the readability
is radically decreased.
[Solution]
Pre-calculate the alignment for each line, and use the leftmost of them
for all lines. The intention of caption provider could be different, but
the worst case scenario is that we revert back everything to LEFT
alignment that is the only option in the CEA608 standard so we
show everything at the exact location it is set in the content.
The readability is never worse than the one given by the content
provider.
[Test]
This should influence CEA608 pop-up cations only. (Not roll up).
Test various live channels with this change.
Note: Beginning of commercials tend to have PAINT-ON mode as that
is immediately showing incoming characters, not just at the end
of the line like POP-on mode.
This instantiates the renderers and extract the capabilities. None of the known
renderes incurs any overhead during instantiation.
PiperOrigin-RevId: 224118511
- Enable GZIP for media playlist + encryption key chunk requests in
HLS, as we do during playback
- Pass around DataSpecs rather than Uris. This will be needed for if
we add manifest cacheKey support (which seems like a good idea for
completeness, if nothing else)
PiperOrigin-RevId: 224057139
We currently default to not caching data if the content length
cannot be resolved once the DataSource has been open. The
reason for this is to avoid caching progressive live streams.
By doing this we were accidentally not caching in other places
where caching is possible, such as DASH/SS/HLS segments during
playback if the server doesn't include a Content-Length header.
Also HLS encryption key chunks, which were very unlikely to be
cached during playback because we explicitly set FLAG_ALLOW_GZIP
(which normally stops content length from resolving) without
setting FLAG_ALLOW_CACHING_UNKNOWN_LENGTH.
It seems like a good idea to flip the default at this point,
and explicitly disable caching in the one case where we want
that to happen.
PiperOrigin-RevId: 223994110
This is in line with how Player.EventListener and AnalyticsListener methods are
defined and helps to only implement the callbacks needed.
PiperOrigin-RevId: 223991262
Moving most of the logic to the base DownloaderHelper helps to implement track
selection for downloading in a single place instead of multiple places.
PiperOrigin-RevId: 223964869
This option to block bandwidth already exists on the AdaptiveTrackSelection itself
but it's not currently possible to forward the total fixed track bandwidth
automatically.
PiperOrigin-RevId: 223785139
- Asus ZenFone GO (ASUS_X00AD_2)
- Sugar S9 (i9031)
- Redmi Note 3 (kate)
These devices trigger native crashes similar to
https://github.com/google/ExoPlayer/issues/4460
I'm not sure why Asus Zenfone Go (model: ZB500KL, device: ASUS_X00AD_2) was removed here
73af056da3
PiperOrigin-RevId: 223580393
A remove action will eventually just be the unique ID of the download
that should be removed. This is a step toward that goal.
PiperOrigin-RevId: 222832456
[Problem]
PAINT-ON mode is not implemented. From the compliance tests:
* RDC command has no effect except to select paint-on style.
* Next data are written directly to the display upon receipt.
* If other captioning is already on the screen, the four-row
limit is still in effect.
[Solution]
It is a rare use case, we do not support overriding characters in
existing cueBuilders as PAINT-ON would require. But several
compliance tests check if the screen is cleared when the mode
switch happens. We must keep the old captions when switching
to PAINT-ON mode
[Test]
- Live Over-the-Air content, beginning of commercials often uses
PAINT-ON mode
- Add DownloadAction.fromByteArray for symmetry with toByteArray
- Make DownloadService call fromByteArray, for symmetry with calls
to toByteArray
PiperOrigin-RevId: 222801703
We already have tests for comment blocks, and they already
pass because we discard the comment when we fail to parse it
as a cue. We should just skip it directly, however.
The input.getLength() check is invalid because the length may be
unknown (i.e. if the server doesn't include a Content-Length
response header when serving chunks).
Issue: #5063 (tangentially related only)
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222406347
This allows more efficient range removals and is consistent with addition,
which supports adding multiple elements in a single operation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222396310
This allows to account for bandwidth used by fixed track selections.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222383736
BandwidthProvider allows bandwidth allocation logic to be customized.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222293581
1. Pull up all subclasses of DownloadAction into DownloadAction
2. Add DownloaderFactory for Downloader instantiation, and DefaultDownloaderFactory
to replace the instantiation logic being removed from the DownloadAction
subclasses.
This change will upgrade existing action files gracefully (i.e. it does not
lose compatibility with the existing offline implementation, other than some
minor breaking changes to the API).
TODOs:
1. Move test methods from the XDownloadActionTest classes into DownloadActionTest.
This will be done in a subsequent CL. There's a lot of consolidation that can
be done here, including de-duplicating some of the test code added in this CL.
2. Look at merging DownloaderConstructorHelper into DefaultDownloaderFactory.
3. Use customCacheKey in DASH/HLS/SS Downloaders, for completeness.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222258983
createTrackSelections decides whether to create an adaptive or a fixed track seletion to create.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222231011
Forwarding the listeners to the notification update is meant to ensure we
only notify the listeners which were registered at the time the event happened
However, we currently just copy the reference to the actual list instead of
doing a deep copy of the listeners.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222227735
This ensures that all callbacks use the same notification mechanism.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222226913
The update is actually unrelated and putting it all in one large update
object complicates adding the same update mechanism for other values.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222226825
WindowedTrackBitrateEstimator, uses future and past chunks in a window
of time to estimate track bitrate values.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=222065409
Currently no path may be chosen if
minBufferUs == maxBufferUs == bufferedDurationUs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221639199
This is needed because the allocator can't be reused for example.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221638233
- Increase the search window size to fix TS seeking for problematic
media we've had provided to us.
- As per my comments on the issue, we should look at doing more here
to better fix the problem. This will solve the worst of the
immediate problem, however.
- The memory usage is non-trivial, particularly with the increased
search window size. I've made the allocations only live whilst
determining duration and seeking to address this. I've done the same
for PS just for consistency.
Issue: #5097
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221449988
The remaining work is to split Window.isDynamic so that it's
possible to represent a window that wont be appended to, but
may still be removed from.
Issue: #4780
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221439220
This is a precursor for fixing the ref'd issue. These classes are
well tested, so the tests passing should give you reasonable
confidence I didn't break anything :).
Issue: #5097
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221435824
LegacyVideoTrackSelection is the previous implementation (unchanged).
VideoTrackSelection is rewritten to extend AdaptiveTrackSelection.
An experiment is added to allow use of the new VideoTrackSelection
implementation. It's envisaged that this transition will be more or
less a no-op change. The experiment flag is only in case of bugs
during roll-out, and will be removed with LegacyVideoTrackSelection
upon successful transition.
VideoTrackSelection also implements discard-on-trick-play-exit, which
was a TODO in the previous implementation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221153827
- This brings it in line with PlayerControlView. The play action is displayed
instead, and pressing it seeks to the default position of the current window.
- Do the same for MediaSessionConnector
- Add support for PlaybackPreparer consistent with PlayerControlView
Issue: #5072
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221076008
This change also paves the way for splitting out functionality into a utility class.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=221070262
When in REPEAT_MODE_ONE, it's unlikely apps want next/previous methods
on the player to keep them in the same window. Music apps in particular
tend to implement next/previous functionality as though repeat mode were
off when in this mode (i.e. current song loops forever during playback,
but next/previous navigation still navigates to next/previous items).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=220469655
This fixes an issue where disabling audio focus handling
while audio focus is held would not release audio focus.
A new test was added for this situation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=220316866
*** Reason for rollback ***
Rolling forward again as [] should fix issue that prompted the rollback
*** Original change description ***
Automated g4 rollback of changelist 219130576.
*** Original change description ***
Re-enable codec re-use
Issue: #2826
***
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=220124362
It's no longer guaranteed that onOutputFormatChanged will always be
called when the renderer is re-enabled, since the codec may be kept
and its output format may not change. Hence we need to avoid resetting
state in onDisabled that we need when the renderer is enabled again.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219821519
Currently, MediaCodecRenderer's render loop does not have any time limit. We
always try to drain and feed as much buffers as possible. This may lead to a
pattern of feeding phase takes too much time from previous loop, which makes
the next draining phase drops all buffers, making these buffers available for
feeding all at once, and the pattern keeps repeating.
This CL adds an experimental parameter for setting a time limit. If the time
limit is exceeded, the feeding process stops even if more input could be fed.
The default behavior is unchanged
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219820386
This makes extractor selection a bit more efficient for some CMAF files.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219795105
This prevents leaving an inconsistent state after a EOF exception.
Issue:#5039
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219785275
Before this change, the player state would be STATE_ENDED then
STATE_BUFFERING (when the postroll ad was marked as played) then
STATE_ENDED again.
Queueing a final content media period with start point equal to
the content duration after a postroll ensures that the player
state doesn't change to STATE_ENDED transiently.
Switch from using C.TIME_END_OF_SOURCE to C.TIME_UNSET for media
periods that should not have an end point and are not followed
by an ad.
Content media periods before postrolls have end position
C.TIME_END_OF_SOURCE. If the postroll ad loads, its content
position is set to the content duration, which should be known
at the point of loading the postroll, then a final 'empty'
content media period with start position equal to its duration
is queued. If the postroll fails to load, this empty content
media period is queued up directly after the preceding content
media period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219443683
- Handling EVENT_PROVISION_REQUIRED is unnecessary because we handle
it via NotProvisionedException, which was thrown on all API levels.
- Handling EVENT_KEY_EXPIRED during playback is unnecessary. All it
does is cause an error to be thrown, but an error will be thrown
anyway out of the MediaCodec when it tries to use the expired keys.
It's currently a race condition where the error gets thrown from,
where-as having it always be thrown from one place is preferable.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219172021
This paves the way to cleanly fix the first two issues
listed in [] onDisabled will null inputFormat,
but nulling of codecFormat will remain tied to the codec
being released.
Issue: #2826
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219125458
ExoCastMessage contains all player management messages that the sender app can
send to the receiver app. ExoCastMessages can be serialized as JSON strings.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218846977
- Only use bitrate when comparing two tracks if their bitrates are
actually different.
- For audio, prefer to use bitrate over selection flags.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218660886
- Improve variable naming
- In the edge case that bytes are transferred in a sample that
has 0 elapsed time, carry the bytes forward into the next
sample. If we don't do this then the estimate will be calculated
as though those bytes were never transferred. In practice I
suspect this very rarely occurs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218551208
If EventDispatcher.removeListener is called to remove a listener,
and if the call is made from the same thread that said listener
handles events on, then it should be guaranteed that the listener
will not be subsequently invoked on that thread.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218331427
In ConcatenatingMediaSource, the source may be removed before it started
preparing (this may happen if lazyPreparation=true). In this case, we
shouldn't call releaseSource as the preparation didn't start.
Issue:#4986
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=218141658
There are multiple subtle issues with the current implementation:
1. setOperatingRate can cause a codec initialization even if the
renderer is disabled. This is not supposed to happen.
2. If the codec is released whilst the renderer is disabled, the
renderer can instantiate a new codec using the old format when
it's enabled again, only to immediately have to reconfigure or
release it if the actual format to be played is different.
3. Codec reuse does not take into account renderer configuration.
The specific case where this is problematic is if the video
renderer is re-enabled with a different tunneling session id.
The reused codec is then not configured correctly.
Also moved availableCodecInfos reset into releaseCodec for sanity.
Issue: #2826
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217924592
This is a no-op change as the respective values are not used so far but
the change makes the current state cleaner and is less error-prone.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217892421
- Added ability to override the DefaultBandwidthMeter network type.
- These methods currently only work properly if called before the
meter is used, but the plan is for them to be handled in the same
way as internally detected network changes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217887019
This method only ensured backward compatibility while the new version was not
public yet. Now ExoPlayer 2.9.0. is public, this workaround can be removed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217881691
I don't think there's any particular reason for releasing
dummySurface when we release the codec. It seems to make
more sense to decouple the two, and treat a dummySurface as
a resource that should be released on reset.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217711788
setSurface only sets the output surface on the codec if the
renderer is enabled or started. This was fine in the past
because the codec was always null in other states, however
the recent codec reuse work means this is no longer the case.
The output surface should always be set if the codec is
non-null. If setting the surface requires releasing the codec
instance, we should only instantiate the new instance if
enabled or started. This is in line with what onDisabled does
if flushing requires releasing the codec
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217676434
Just not doing it seems simplier and more obviously correct
than suppressing the warnings in our proguard file.
Issue: #4890
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217675527
1. Remove option to pass null context to Util.getNetworkType. IMO it's
clearer for the caller to just not call the method in this case.
2. Stop using deprecated DefaultBandwidthMeter.Builder constructor in
all but one place.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217147091
The assertion was so weak it probably wouldn't detect genuine
misuse of the DefaultAllocator API, so it seems fine just to
remove it.
We don't really know what happens when the player is allowed to
continue on the affected devices, but hopefully it either "just
works" or fails in a more graceful way.
Issue: #4532
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217113060
Robustness fix to make sure we ignore tags with known names, but
which are nested inside of unknown tags. For example we don't want
to parse the third period in:
<Period>...</Period>
<Period>...</Period>
<CustomTag>
<Period>...</Period>
</CustomTag>
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=217101630
For decoder reuse, we want disable() to flush the decoder. However,
if the flush needs to release the decoder for some reason, it seems
non-ideal to immediately re-initialize it. Re-initialization can
also throw ExoPlaybackException, which we don't want for disabling.
This change allows a variant of flush that wont re-initialize the
decoder if it has to be released, which will be used from disable().
Issue: #2826
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=216834862
reloading frmo snapshots. b/117347850. This is a no-op change as the current
default == _fullboot. When we globally flip and make snapshots the default,
these tests would fail and we are moving them over so that when we flip your
tests still pass.
https://groups.google.com[]forum/#!topic/mobile-ninjas/Y69PTAT5GyY
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=216634430
- Always clip to period duration for the last chunk. We previously
did this only when the last chunk explicitly exceeded the period
end time. We now also do it when the chunk claims to end at the
period boundary, but still contains samples that exceed it.
- If pendingResetPositionUs == chunk.startTimeUs == 0 but the
chunk still contains samples with negative timestamps, we now
clip them by setting the decode only flag. Previously we only
clipped such samples if the first chunk explicitly preceeded the
start of the period.
Issue: #4899
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215763467
- It's a no-op for now
- Renderers that want to support retaining resources will move
some functionality from their disable() implementations into
reset()
- ExoPlayerImplInternal will be updated to not always call reset()
immediately after disable(), which is what will enable resources
to actually be retained.
Issue: #2826
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215729783
This makes the following changes to improve consistency among the PlaybackInfo
values:
1. Update buffered position and total buffered duration after loading period
is set as both values are affected by a loading period update.
2. Add copyWithPosition to allow updating the position without resetting the
loading period.
3. Forward the total buffered duration to playing position updates
as it may have changed with the new playing position.
Issue:#4899
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215712328
When SubtitlePainter positions the cues centred in the given box, it must add
the left offset of the box to get the correct position.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215535289
SubtitleView forwards the cue box position to SubtitlePainter. This should be
the position relative to the canvas of the SubtitleView. Currently, however,
we forward the position relative to the parent of SubtitleView. That causes
problems if SubtitleView has a non-zero offset position to its parent.
Issue:#4788
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215535281
This removes the experimental bandwidth meter and uses it as the new default.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215404065
A lot of methods just forward to other methods and there is no conceivable
way a player should implement it another way. Moving these methods to a
base player class allows to remove duplicated code across our player
implementations.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215374192
For example, using ExoPlayer.STATE_IDLE falls back to the Player.STATE_IDLE
automatically and thus there is no need to keep the deprecated members.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215363841
If we prepare a deferred media period before the actual timeline is available,
we either prepare with position zero (= the default) or with a non-zero
initial seek position.
So far, the zero (default) position got replaced by the actual default position
(including any potential non-zero window offset) when the timeline became known.
However, a non-zero initial seek position was not corrected by the non-zero
window offset. This is fixed by this change.
Related to that, we always assumed that the deferred media period will the
first period in the actual timeline. This is not true if we prepare with an
offset (either because of an initial seek position or because of a default
window position). So, we also determine the actual first period when the
timeline becomes known.
Issue:#4873
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215213030
These two methods are meant to indicate to the track selection that it's
started or stopped being used. This is helpful to schedule background tasks
related to track selection (e.g. register network change listeners etc.).
This intention is not clearly stated in the method docs.
Also, all track selections of all prebuffered periods stay enabled in
parallel at the moment. As the whole purpose of these methods is to know
whether dynamic updates via updateSelectedTrack may happen, it's better to
only enable track selections of the current loading media period. That's
similar to how we always forward the loading track selections to the
LoadControl.
This change:
1. Improves the JavaDoc of TrackSelection.
2. Disables track selections if loading moves to another period.
3. Reenables track selection if loading moves back to a previous period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215199987
Switch to the recommended way of checking whether the app is running on a TV
device.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=215177587
Extend Sony workaround up to and including Oreo.
Due to a platform issue the Display API couldn't report 1080p UI
and 4k SurfaceView support until Oreo. Since Oreo it is still
common for devices to misreport their display sizes via Display,
so this change switches to using system properties up to and
including Pie.
On Pie treble may prevent writing sys.display-size so check for
vendor.display-size instead.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214987203
More specifically, if the parts of the Format that are used
for decoder configuration are unchanged.
Issue: #2826
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214791234
If a source is removed from the playlist, the player may still call createPeriod
for a period of the removed source as long as the new timeline hasn't been handled
by the player. These events are stale and can be ignored by using a dummy media
source. The stale media period will be released when the player handles the updated
timeline.
Issue:#4871
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214787090
This simplifies code skipping items in a playlist programatically.
Issue:#4863
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=214580742
This method needs to be called whenever the track selection of the current
loading period changes, but also when the loading period itself (and thus
the "loading track selection") changes. These are the same situations in which
we update the loading media period id and thus we can move both updates in
a common helper method.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213959982
From API 23 this uses the timed format queue. Before API 23 the
format is notified as soon as the buffer is queued.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213830729
Before this change we would reset the start trim to zero after initial
configuration (at the start of playback) and after seeking to any position. The
fact that no trimming was applied at the start of playback meant that after the
first period transition we'd see a mismatch between the next buffer timestamp
(equal to the duration of the period taking into account edits) and the duration
of audio submitted to the sink.
This change modifies the behavior so that we reset the start trim to zero only
if some audio was queued since configuration. This is incorrect in the case of
starting playback at a non-zero position, but fixes the common case of starting
at zero. As before, a later seek to any position is handled via a flush and
resets the trim as required.
Transitions from one period to the next are unaffected by this change.
One way to implement start trimming correctly would be to provide the input
buffer timestamp to the audio processors and only trim when handling audio from
the start of the stream, but that is a larger change so left for later.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213828511
After a period transition the first buffer queued has the sum of previous period
durations added to its source presentation timestamp. These durations take into
account gapless edits, but the check on the timestamp was based on the submitted
frame count, not the frame count after trimming.
This change fixes an issue where audio/video would gradually drift apart due to
accumulated error in the audio track position, which could lead to freezing due
to the audio renderer stopping being ready and switching to the standalone media
clock.
Issue: #4559
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213819908
Fixed and random track selection were still overriding the deprecated version
of updateSelectedTrack.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213637728
The only use of track selection factories is as adaptive track selection factories
in the DefaultTrackSelector. Using the fixed track selection factory here is dangerous
as it will throw if more than one track is selected.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213637500
With default of value set to -1, every single dropped frame is reported because of expression: if (droppedFrames >= maxDroppedFramesToNotify) { maybeNotifyDroppedFrames(); }
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213502573
The decoder doesn't claim to be adaptive, but if we're staying
in the same resolution we'll try and re-use the decoder anyway.
The H264 decoder can't handle this case on the Tab 4 can't deal
with this case.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213478378
This doesn't break apps which violate this policy. But it creates a clear
warning which is also likely to be reported in analytics tools.
Issue:#4463
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213442510
The DefaultTrackSelector can now be constructed without leaving out a
vital part of the initialization. This allows this new simple factory method.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213438163
Currently there is no way to disable (or reduce) the logcat output generated
by ExoPlayer.
Issue:#4665
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213421072
This allows creating multiple HLS media sources from a single Factory, as
required by the interface.
Issue:#4814
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213297850
ExoPlayer can be run on a background thread, but some components (UI and IMA)
only support players on the main thread. This adds some documentation and
assertions for that.
To simplify assertions, this also moves the getApplicationLooper method from
ExoPlayer to Player.
Issue:#4439
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213280359
Kotlin will throw NPE whenever a method returns null or an interface is
called with a null parameter and the respective values are not marked as
@Nullable.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213262886
To check the validity of a window index it needs to be compared with a greater
or equal sign to the window count.
Issue:#4822
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=213234403
Also prevent an unnecessary allocation when the removed range is empty.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212993427
Not having this annotation may cause Kotlin implementations to fail.
Issue:#4802
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212980643
If we can select a track that has a strictly higher score than a
selection already made for a renderer of the same type, we should
prefer it.
Issue: #4711
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212835895
- Make addMediaSource a specific case of addMediaSources.
- Make clear a specific case of removeMediaSourceRange.
- Make removeMediaSource a specific case of removeMediaSourceRange.
- Remove the unnecessary message handling and constants.
- Move a method so that depending appears before depended.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212809667
This allows to update the shuffle order after the ConcatenatingMediaSource
has been created. ShuffleOrder objects should be immutable to ensure thread
safety and thus there is no way to do this currently.
Issue:#4791
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212443146
- Fixes the referenced issue.
- Provides more consistent behavior for the edge case of empty
chunks (i.e. chunks containing now samples). Format changes
will now always be reported for such chunks, unless the empty
chunk is discarded from upstream before there's a chance to
do so.
Issue: #4533
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212443043
When the stream is changed in the audio renderer, the timestamps of the
samples can no longer be expected to match the calculations in the AudioSink.
This change tracks the samples at which the stream is changed and notifies the
AudioSink of the discontinuity.
Issue:#4559
Issue:#3829
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212435859
When a reset is pending the sample queues normally contain pre-seek
samples (which will be emptied when a pending load is canceled). The
position passed to discard will be a post-seek position. I don't
think anything bad happened in any of the cases being changed, but
discarding is unnecessary in such cases, and reasoning about such
cases is difficult.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212435556
- This makes it so that onDownstreamFormatChanged will occur before the corresponding
renderer event. This was not previously the case, since the renderer would typically
read the format (and report its event), then a sample (causing the
onDownstreamFormatChanged event).
- The remaining ones to update are ChunkSampleStream (DASH + HLS), which will be done
in a way that fixes#4533, and HLS.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212434874
If there's already a pending reset, we need only update the pending
reset position. We can currently end up calling cancelLoading more
than once on the loader for the same task, which is hard to reason
about (although I don't think anything actually broke in practice).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212432266
We currently apply the track.timescale whereas we should be applying the
track.movieTimescale. The parsing for the trak atom does this correctly
and the duration from the trak atom currently always takes precedence over the
durations from the stbl atoms as it's always larger.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212421687
Ignoring all edit lists if they don't start with a keyframe causes A/V sync
issues when valid edit lists are applied at the beginning.
This change allows such edit lists again but removes all samples before the
first keyframe (these samples would be ignored by the renderer anyway if at
the beginning OR cause visible distortions when appended to an unrelated
keyframe).
Issue:#4774
Issue:#4348
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=212244407
- There's no particular need to read or skip a sample before notifying
- Add missing isPendingReset check
Issue: #4533
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=211959762
The default character set is always UTF-8 anyway on Android, but
we don't want our code to behave any differently where it's not
(e.g. robolectric test runs could potentially run in an environment
where UTF-8 isn't the default?).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=211953885
1. Currently, we may throw source info refresh errors while the previous media
period is still playing.
2. We don't throw if the next period in a playlist fails to prepare and the
previous renderers are all disabled.
3. We throw source info refresh errors for playlists before playback reaches
the culprit source.
This change:
1. Defers the exceptions until all existing media periods have been played.
2. Checks for period preparation exception if the next period is not
getting prepared and the renderer time reached the next period.
3. Does no longer throw from ConcatenatingMediaSource.maybeThrowSourceInfo
RefreshError. The deferred media periods take care of that for each source
individually.
Issue:#4661
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=211819436
To report DRM session metrics in the future as part of the listener, we need
a callback at the end of the drm session to get the final metric state.
For completion, the session acquired callback is also added.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=211328412
Also make some javadocs more consistent with the rest of the library.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=211071559
The current structure tries to associate events to media periods and windows
based on the reported values and the current timeline. However the reported
EventTime may not always be consistent in case the timeline doesn't contain
windows or media periods yet or not anymore.
The recent changes to MediaPeriodId allow to use it as a unique identifer for
media periods independent of the timeline. This enables more accurate tracking
of the media period queue and prevents reporting events with inconsistent
data.
Issue:#4492
Issue:#4634
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210713120
This provides the list of currently buffered media chunks and iterators over
the potential next chunks to the track selection. Having these two parameters
enables more advanced decision logic based on this data.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210551812
This fixes or suppresses all reported issues by the code review linter tools.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210107759
There are C.CLEARKEY_UUID.equals(uuid) checks in FrameworkMediaDrm,
so uuid needs to be CLEARKEY_UUID, not COMMON_PSSH_UUID
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210094372
- Add @Deprecated on overrides of deprecated method.
- Suppress deprecation warnings where appropriate.
- Use non-deprecated alternatives where appropriate.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210092434
This prevents problems caused by unintended double-registration of the same
transfer listener.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210078454
This option is currently not available as a non-null adaptive track selection
has to be provided. Adds a parameter "forceHighestSupportedBitrate" which
corresponds to the default fixed track selection for audio and video.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210073675
At the point of starting to play a postroll, source info refreshes for future
postroll ads in the same ad group would cause a seek that incorrectly identified
the media period to play as the content media period. Fix the logic in
getAdGroupIndexForPositionUs to address this.
Also handle empty postroll ad breaks by resetting the expected ad group index
when we send content complete.
Issue: #4710
Issue: #4681
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=210071054
Similar to getBufferedPosition and getCurrentPosition, getDuration should
mention that it also returns the duration of the current ad.
And, also similar to getContentBufferedDuration and getContentPosition, a
new method getContentDuration simplifies querying the content duration while
playing an ad.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209914696
The response headers of the last load are available from the loading source
when creating media source events and can be easily forwarded.
Issue:#4361
Issue:#4615
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209900693
The doc can be improved by enumerating and linking all possible values from
the interface doc.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209772309
Apps targeting P or later now must request this permission in order to
use foreground services.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209762160
Also remove NonNull, since we assume NonNull by default. Except
where explicitly overriding a method with NonNull annotated args,
in which case we're still expected to use it.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209758204
Some tests were flaky because of the PlayUntilPosition action which called
player.setPlayWhenReady from the wrong thread. Also fixed some other misc
flakiness.
ExoPlayerTest seems to be non-flaky now (tested with 10000 runs).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209743076
They don't need to be accessed publicly and are can be moved into the
respective chunk sources. This is the same structure used for Dash.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209507217
The MediaPeriodId with index is only properly defined together with a
timeline containing the index. Changing it to the period uid allows to use
the MediaPeriodId independent of the corresponding timeline.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=209430257
