We currently block the loading thread until the calculated load
time has past and then unblock again by a message sent from the
playback thread. However, because the loading thread itself is not
using a Looper and runs freely, we don't control when the short
calculations on the loader thread that determine how long we have
to wait are happening, and we also don't control how long it takes
to start and stop this thread.
To solve these problems and to make the playback deterministic we
can
1. Send a message on the playback thread to block until the loader
thread has started.
2. Block the playback thread whenever a loading thread is doing its
short calculation of wait times. The playback thread knows when it
can continue because loading either enter a new waiting state for
a simulated load time or loading is finished completely.
3. Also wait on the playback thread until the loader has shut down.
As this is waiting for a message on the playback thread, we can
achieve this by sending messages to ourselves at the current time
until the loader is shut down.
All 3 steps together ensure that the loading thread interaction is
compeltely deterministic when simulating bandwidth profiles with the
BandwidthProfileDataSource. As we need to notify the source before and
after the load started/finished, we also need a small wrapper for the
chunk source when running the playback.
PiperOrigin-RevId: 355810408
- When throwing a recoverable error from a renderer, it's important to understand
exactly how the player will attempt recovery. Clarify the documentation to
make this explicit.
- Rename some methods/constants to make it clear that error recovery is specific
to renderer errors. The current recovery mechanism only makes sense for
renderer errors. Making the naming renderer specific avoids reader doubt that
the implementation doesn't appear to be generic enough for other types of
errors.
PiperOrigin-RevId: 355650945
It's for classes to clearly denote they support bundling and it gives
us a good place to document the best practice to implement fromBundle.
PiperOrigin-RevId: 355609942
Before, the level was set to null in this case.
MediaCodecUtil.getCodecProfileAndLevel() was therefore returning null
and the fallback to AVC/HEVC was not enabled in MediaCodecVideoRenderer.
Issue:#8530
#minor-release
PiperOrigin-RevId: 355574499
In both cases it's deliberate that all excluded constants should use
the default branch. Furthermore, there are quite a lot of excluded
constants missing, so it's probably better to suppress the warning
than to include them all.
#minor-release
PiperOrigin-RevId: 355426749
This resolves the following constraint resolution issue when running our release script:
> Cannot find a version of 'org.chromium.net:cronet-api' that satisfies the version constraints:
Dependency path 'com.google.android.exoplayer:extension-cronet:unspecified' --> 'com.google.android.gms:play-services-cronet:17.0.0' --> 'org.chromium.net:cronet-api:72.3626.96'
Constraint path 'com.google.android.exoplayer:extension-cronet:unspecified' --> 'org.chromium.net:cronet-api:{strictly 72.3626.96}' because of the following reason: debugRuntimeClasspath uses version 72.3626.96
Dependency path 'com.google.android.exoplayer:extension-cronet:unspecified' --> 'org.chromium.net:cronet-embedded:76.3809.111' --> 'org.chromium.net:cronet-common:76.3809.111' --> 'org.chromium.net:cronet-api:76.3809.111'
#minor-release
PiperOrigin-RevId: 355414968
* Move cherrypicked changes from dev-v2 to 2.13.0
* Use a bulleted list instead of comma-separated.
* Standardise everything into present, imperative sentences.
* Remove a couple of mixed-font words (I left cases with a separating
apostrophe, as these seemed visually clearer).
* Merge multiple issue links into a single set of parentheses.
#minor-release
PiperOrigin-RevId: 355180143
Main improvement is to switch away from ExoPlayerTestRunner and to
split out the waiting component so that the same class can be used
from Robolectric tests in the future.
The only functional difference is that that BufferLengthLogAction
is removed completely because the data isn't used downstream and the
method of collecting this data is a bit arbitrary.
PiperOrigin-RevId: 355117850
Without this no error is currently logged or propagated to EventLogger.
The propagation doesn't happen because
MergingMediaSource.ForwardingEventListener only propagates events
originating from the "main" source in the merge:
<unknown commit>
#minor-release
PiperOrigin-RevId: 354902467
We can dequeue as part of getting output buffers (or output buffer info) in
`MediaCodecAdapterWrapper`, which simplifies the caller slightly.
Also try to make minor clarifications in method naming in
`TransformerAudioRenderer`.
#minor-release
PiperOrigin-RevId: 354890796
This also moves DefaultHttpDataSource to common, which seems
sensible, else non-player components that need a DataSource
don't have any useful concrete implementations. We should
think about moving some of the other concrete implementations
to common as well.
PiperOrigin-RevId: 354738925
- Store output format in `MediaCodecAdapterWrapper` when we get a format from
the codec, instead of creating it on demand.
- Make format building code not audio-specific.
- Remove `MediaCodecAdapterWrapper.getConfigFormat` and instead keep track of
the input/output formats in the renderer. This will mean that the code still
works if an audio processor changes the audio format in future.
- Make exceptions thrown during audio rendering use the same (input) renderer
format.
- Misc other minor cleanup.
#minor-release
PiperOrigin-RevId: 354556619
This can happen for instrumented tests that are run on a non-Looper
thread. If these tests send a message to a Looper thread to start the
test procedure, they should just triger the message directly as before.
PiperOrigin-RevId: 354066836
- The order of sample stream (and thus the order in which loads are
triggered) currently depends on a Set and thus on the hash codes
of the objects that change with every run. Changing to a List solves
this problem.
- The FakeAdaptiveDataSet directly created a static Random (with random
seed) to compute the variation of chunk sizes. Changing this to an
injected Random object that can always be initialized with the same
seed also removed this randomness from the tests.
PiperOrigin-RevId: 353878661
This is achieved by only triggering one message at a time. After
triggering a message we send another to ourselves to know when the
following message can be triggered.
Other required changes:
- The messages need to be sorted correctly (by time and creation order)
- To prevent deadlocks when one thread is waiting for another,
we need to add new method to Clock to indicate that the current
thread is about to wait. This then allows us to trigger messages
from other threads in FakeClock.
- AnalyticsCollectorTest needed some adjustments:
- onTimelineChanged now deterministically arrives after the initial
timline is already known, so some of the period information changes
from window only to full period info.
- The playlistOperations test suffers from a bug that the first frame
is rendered too early and that's why we now get additional events.
PiperOrigin-RevId: 353877832
We currently only remove messages that have already been sent
to the actual Handler, not the pending ones that are only kept
in the FakeClock. Fix this by also removing matching messages
from the FakeClock list.
PiperOrigin-RevId: 353877049
Currently only delayed messages are handled. Change this to handling
all messages so that we have more control over their execution order.
This requires adding a new wrapper type for the Message to support
the obtainMessage + sendToTarget use case.
PiperOrigin-RevId: 353876557
