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
- Make units of time clear for seeking
- Remove option to specify supported repeat modes in default
playback controller. It doesn't seem useful, given we can't
control what the session is sent.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=220464529
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
Copybara propagates this bit on the files, so removing it avoids some
unnecessary changes in the first migrated commit.
Also losslessly optimize two PNG files.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=220268951
*** 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
Some test specific things, like adding an extra listener or adding decoder
counters are currently handled by ExoHostedTest. They can be moved to the
classes actually using them to clean up ExoHostedTest.
This also adds more flexibility to further generic clean-up in onTestFinished.
Also, reorder player setup to what ExoPlayerTestRunner is doing.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=219446276
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
