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
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
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
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
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
*** 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
Ignore two tests in AsynchronousMediaCodecBufferEnqueuerTest
until the ShadowMediaCodec's behavior is updated to apply
input buffer ownership.
PiperOrigin-RevId: 318251859
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
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
*** 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
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
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 ***
Propagate format in supportsOutput
It is needed to know if gapless is needed,
as gapless offload might not be supported.
***
PiperOrigin-RevId: 315947888
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
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
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
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
- 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
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
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
- 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
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
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
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
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
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
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
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
- 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
