*** 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
