This makes the distinction more clear between the methods that test
a specific behaviour (and are meant to be used with parameterized
tests) and those that test everything in one go.
Also add a TODO to FlacExtractorTest to migrate it when we can
PiperOrigin-RevId: 308228421
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
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
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
The new TestExoPlayer.Builder asserts that a Looper is present in
the constructor, although it can be set later for cases where no
such Looper exists.
PiperOrigin-RevId: 306403491
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
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
- 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
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
The FakeSampleStream is currently always ready even if it doesn't
have any samples to read. Fix that by checking for the conditions
under which read() will be successful.
PiperOrigin-RevId: 301371031
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
This is a partial revert of <unknown commit>. The split and the order is important. For
example, as things are currently, if playback fails for a test that makes additional
assertions in onTestFinished, the visible reason the test failed is quite likely to
be one of the additional assertions, rather than the error that actually caused the
playback to fail. I think we probably also don't want to log metrics if playback
fails.
PiperOrigin-RevId: 300733109
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 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
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 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
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
This info is already in the javadoc of FakeExtractorOutput#assertOutput
but it's not super discoverable if you just see the test failure. I was
manually copying the dump results around before realising there was
a mechanism to auto-update.
PiperOrigin-RevId: 296204463
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 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
