setBytesRemaining() doesn't work when called after closeCurrentSource()
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182999254
These parsers can be used to get a manifest which includes only the
representations identified by the given keys.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182932874
So far this wasn't possible because Robolectric's Looper and MessageQueue
implementations have multiple shortcomings:
1. The message loop of new HandlerThreads is an not an actual loop and
scheduled messages are executed on the thread the message is enqueued
(not the handler thread).
2. The scheduler used to replace the message queue is synchronizing all its
methods. Thus, when a test attempts to add messages to a Handler from
two different threads, it may easily run into a deadlock.
3. The scheduler doesn't correctly emulate the order of messages as they
would be in an actual MessageQueue:
a. If the message is enqueued on the handler thread, it gets executed
immediately (and not after all other messages at the same time).
b. The list of messages is always re-sorted by time, meaning that the
order of execution for messages at the same time is indeterminate.
4. Robolectric's SystemClock implementation returns the current scheduler
time of the main UI thread. So, unless this scheduler is used to add
messages in the future, the SystemClock time never advances.
This CL adds two helper classes which extend and replace Robolectric's
ShadowLooper and ShadowMessageQueue.
1. We intercept messages being enqueued or deleted in the message queue.
Thus Robolectric's faulty scheduler gets never used. Instead, we keep
a blocking priority queue of messages, sorted first by execution time
and then by FIFO order to correctly emulate the real MessageQueue.
2. We also keep a list of deleted messages to know which messages to ignore
when they come up in the looper.
3. When a new Looper is started, we override the dummy loop to an actual
eternal while loop which waits for new messages, checks if they haven't
been deleted, and runs the messages (similar to what Robolectric's
MessageQueue would have done at this point).
Because we don't actually use the main UI thread in our tests, we can't rely
on the SystemClock to progress in any sensible manner. To overcome this issue,
we can use the auto-advancing FakeClock also used for the simulation tests.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182912510
This achieves two things:
1. All our tests use the same type of assertions.
2. The tests currently run as instrumentation test can be moved to
Robolectric without changing the assertions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182910542
These were caused by two issues:
1. The FakeMediaSource can be updated with a new timeline. The setNewSourceInfo
is called from a different thread than prepareSource and both access local
variables without synchronization.
2. For multi-window playback, the FakeRenderer claims that isReady and isEnded
are both set to false if it read the end of the stream. However isReady should be
true because it is able to "render" its data until the end of the stream.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182785169
When a loaded DASH manifest is invalid (either some periods were removed
illegally, or a manifest for a live event is stale), we will retry using 1
logic:
- Retry loading with back-off up-to a limit.
- Throw a DashManifestExpiredException() if we exceed retry limit.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182770028
Also disable use of dummy surface for devices that require the
workaround. It's only useful in the case that we can use
setOutputSurfaceWorkaround, so if it's disabled the dummy surface
has no purpose (it actually makes things worse by consuming past
the key-frame prior to the current position, which doesn't happen
if you have no surface at all).
Issue: #3724
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182750068
This fixes a very specific case where the data read has non-cached gaps
and a read-only CDS switches to read from upstream in a gap then the
cached data is deleted. When the CDS reaches the end of the gap, it
tries to open the next source. As there is no cached data, it tries to
continue with the already opened upstream data source but as it reached
end of the gap range, the code starts looping.
Also fixes infinite lock which occurs when in the previous case CDS isn't
readonly. It locks the content while filling the gap in the cache. At the
end of the gap, as the following data is deleted it tries to lock the
content for writing but the content is already locked by itself.
The last fix is preventing removal of CachedContent entry from
CachedContentIndex while associated key is locked.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182595426
Some tests in ExoPlayerTest issue commands to the player from the test thread
while the player is actively playing media (playWhenReady=true). Due to the
indeterminate time taken to enqueue the commands on the playback thread, they
may arrive when the player already proceeded to another window or finished
playback.
To ensure the tests are always deterministic, this change pauses playback in
the tests where this may happen before issuing the commands.
Also, for tests where we need to wait for a new window before issuing the
next command, a new action is added which allows to play until a specified
position.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182535096
- Get handling of "stale" and "out of sync" manifests so
they're right next to each other (to be merged)
- Move startLoadingManifest to be next to the methods that
schedule it, and actually start loading stuff.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182530683
As soon as the seek gets acknowledged by EPII, EPI returns the actual position
from the playback info again which is set by EPII. Thus, EPII needs to update
the position to reflect the changes expected by EPI.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182515106
- In IDLE, the button will now call a preparer. This allows
removal of the separate retry button from the demo app.
- In ENDED, the button will seek back to the default position
and play.
- Behavior is made consistent with LeanbackPlayerAdapter.
Issue: #3689
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182506855
When determining the next sample to load, the Mp4Extractor now takes
into account how far one stream is reading ahead of the others.
If one stream is reading ahead more than a threshold (default: 10 seconds),
the extractor continues reading the other stream even though it needs
to reload the source at a new position.
GitHub:#3481
GitHub:#3214
GitHub:#3670
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182504396
It seems good to have EventLogger available from the library.
In particular because when app developers use it and then
submit bug reports, it makes it much easier to work out what
happened. It will also allow EventLogger to be used across
our (now multiple) demo apps.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182389407
This gets rid of the manual tracking of this queue with reading, playing,
and loading period holders. Still keeping these names for queue access methods.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182378944
This solves the problem of having dense tracks' ids change.
For example, if the available variants offer both HEVC and AVC video
tracks, all video samples will map to the same sample queue even if
IDs don't match.
Issue:#3653
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182070486
This avoids issues that can arise due to slight discrepancies between
chunk start times (obtained from the manifest of segment index) and
the timestamps of the samples contained within those chunks.
Issue: #2882
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182054959
For live streaming, there are several types of DASH `emsg' events that directly
target the player. These events can signal whether the manifest is expired, or
the live streaming has ended, and should be handle directly within the player.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182034591
This allows listeners to get notified of any change to the embedded tracks.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=181969023
ChunkSampleStream.seekToUs assumes that if we can seek within the
primary sample queue, we can also seek within the embedded queues.
This assumption can be violated fairly easily if discardBuffer is
called with toKeyframe=true, since this can cause samples to be
discarded from the embedded queues within the period for which a
seek in the primary sample queue will succeed. This change fixes
the issue.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=181965902
These haven't been included in the recent changes but can be reported as
soon as the first sample of each stream is read.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=181753141
We added the other callbacks some time ago, but didn't include onLoadStarted.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=181743764
This it to distinguish between actual period transitions and the
transitions occuring to and from ads within one timeline period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=181606023
Partial reads were performed once using a partial size of 1 byte.
This was not enough to detect problems which only occur in combination
with IOExceptions. Partial reads are now only applied when no exception
is thrown.
Moreover, the tests didn't check whether the total number of sampled bytes
is what it is supposed to be. Added a field to the data dumps checking
the total number of bytes in the sampled data.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=181296545
----------------------------------
Original change description:
DRM fixes
- Parse multiple kids from default_KID. It's specified as a whitespace
separated list of UUIDs rather than a single UUID.
- Opportunistically proceed with playback in cases where the manifest
only defines a single SchemeData with the common PSSH UUID. In such
cases the manifest isn't saying anything about which specific DRM
schemes it supports.
Issue: #3630
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=181137621
This lets apps fail-fast when they try to reuse media source instances.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=180934445
If SimpleExoPlayer is using TextView as output, we can handle video rotation by
automatically applying a matrix transformation to the TextureView when we have
this information available from the video (from video's metadata).
GitHub: #91
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=180925571
In certain conditions CacheDataSource switch to reading from upstream
without writing back to cache. This change makes it detect the change of
these conditions and switch to reading from or writing to cache.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=180901463
DASH manifests can now contain non-null but incomplete
DRM init data. Hence using the manifest init data when
non-null is not always the correct thing to do. This
change merges the sample and manifest formats (which
correctly merges the DRM init data) and then uses the
result.
Issue: #3630
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=180787784
- Parse multiple kids from default_KID. It's specified as a whitespace
separated list of UUIDs rather than a single UUID.
- Opportunistically proceed with playback in cases where the manifest
only defines a single SchemeData with the common PSSH UUID. In such
cases the manifest isn't saying anything about which specific DRM
schemes it supports.
Issue: #3630
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=180675056
This removes the need to calculate the time needed to run the doSomeWork
method. Consequently, we can use both the real Clock/Handler and the
FakeClock without changing the way the playback loop works and without
violating the interfaces of Clock or Handler.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=180665647
Some readability fixes for PlayerMessage and the handling in
ExoPlayerImplInternal.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=180544294
Whilst the previous behavior was WAI and had the advantage of
updating the position to be more exact when known, there were
a couple of disadvantages:
1. If seeking to the very end of a period in a playlist when
paused, the position adjustment could trigger a position
discontinuity to the next period.
2. We de-duplicate seeks to the current playback position.
The position adjustment can prevent this from being
effective. This is particularly important with the new
SeekParameters support. When seeking to nearest sync point
it's often possible to de-duplicate seeks, but we cannot
do so if the playback position adjusts away from the sync
point's time.
Issue: #2439
Issue: #2882
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=180540736
This ensures message order if multiple custom messages running on the
playback thread and direct player commands are called immedately after
each other.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179925852
This allows to inject a FakeClock for tests. Other playback components
(e.g. some media sources) still use SystemClock but they can be amended
in the future if needed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179921889
Especially this removes the need for the Clock interface to directly
implement Handler methods. Instead, we have a separate Handler interface
and the FakeClock is able to construct such a Handler.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179918255
If ClippingMediaSource contains a child MediaSource with embedded metadata
stream, and the embedded stream is being used, it can lead to
ClippingMediaSource not be able to stop after the clipping end point. The
reason being the metadata stream cannot read anymore sample, but it's also not
end of source at that point. This CL fix this by changing the condition to
check if the child stream cannot read anymore sample and it has read past the
clipping end point.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179918038
This adds options to ExoPlayer.sendMessages which allow to specify a window index
and position at which the message should be sent. Additionally, the options can be
configured to use a custom Handler for the messages and whether the message should
be repeated when playback reaches the same position again.
The internal player converts these window positions to period index and position
at the earliest possibility. The internal player also attempts to update these
when the source info is refreshed. A sorted list of pending posts is kept and the
player triggers these posts when the playback position moves over the specified
position.
Issue:#2189
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179683841
*** Original change description ***
Add possiblity to send messages at playback position.
This adds options to ExoPlayer.sendMessages which allow to specify a window index
and position at which the message should be sent. Additionally, the options can be
configured to use a custom Handler for the messages and whether the message should
be repeated when playback reaches the same position again.
The internal player converts these window positions to period index and position
at the earliest possibility. The internal player also at...
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179666357
This adds options to ExoPlayer.sendMessages which allow to specify a window index
and position at which the message should be sent. Additionally, the options can be
configured to use a custom Handler for the messages and whether the message should
be repeated when playback reaches the same position again.
The internal player converts these window positions to period index and position
at the earliest possibility. The internal player also attempts to update these
when the source info is refreshed. A sorted list of pending posts is kept and the
player triggers these posts when the playback position moves over the specified
position.
Issue:#2189
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179563355
- Lint doesn't like a static import of something not available on
the minimum API level.
- The method linked to in the Javadoc was incorrect (wrong signature).
I couldn't really work out why it was there, so I got rid of it
rather than updating.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179222587
Update PlaybackControlView and SimpleExoPlayerView so when showTimeoutMs is set
while the controller is shown, the new timeout takes effect immediately.
GitHub: #3554
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179171727
This adds a parameter to configure a maximum buffer size in bytes. If left
at its default of C.LENGTH_UNSET, the target buffer is determined using a
overridable method based on the track selection. Also adding a parameter
to decide whether to prioritize time or size constraints.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179048554
They worked without being present in the declare-styleable,
but they need to be present for Android Studio auto-complete
to suggest them.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179047478
Also fix ClippingMediaSource to consider the start position an
artificial key-frame, and to properly offset the value returned
by getAdjustedSeekPositionUs.
Issue: #2882
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179032243
Skipping short periods in a while loop is conceptually a new operation
and thus we need to send out the updated playback info in between for
the listeners to receive multiple period transition discontinuities.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=179027334
This is a no-op change replacing the local variables in ExoPlayerImplInternal
with the new ones in PlaybackInfo.
***
Use playbackState, isLoading and trackSelectorResult from playbackInfo in ExoPlayerImpl.
***
Move duplicated listener notification in ExoPlayerImpl to new method.
Also split reset method in one parts which creates the new playback info
and one part which notifies the listeners. The increment of the pending
operation counter needs to happen in between.
***
Use only one pending operation counter in ExoPlayerImpl.
This also allows to move onSeekProcessed into the notification chain.
***
Replace playback info changing messages to ExoPlayerImpl by single message type.
As they are all handled in the same way, they can be summarized to one message.
***
Only send playback info change notifications once per playback thread message.
This ensures that all concurrent changes actually reach ExoPlayerImpl concurrently.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=178907165
- Convert the Builder into a Factory
- Have it use MediaSourceEventListener
- Also made some misc related fixes to other sources
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=178906521
1. The player doesn't acknowledge phantom stops when an exception is thrown anymore.
2. It also makes sure it doesn't reset the pendingPrepareCount unless it's actually
immediately acknowledging these prepares.
3. It ensures a seek is acknowledged even though an exception is thrown during seeking.
Added tests (which previously failed) for all three cases.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=178876362
This is in preparation for supporting non-extractor MediaSources for ads in
AdsMediaSource.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=178377627
If allowed, the media period will try to finish preparation without downloading
chunks (similar to what DashMediaPeriod does). To create track groups,
HlsMediaPeriod will try to obtain as much information as possible from the
master playlist. If any vital information is missing for specific urls,
traditional preparation will take place instead.
This version does not support tracks with DrmInitData info. This affects tracks
with CDM DRM (e.g: Widevine, Clearkey, etc). AES_128 encryption is not affected.
This information needs to be obtained from media playlists, and this version
only takes the master playlist into account for preparation.
Issue:#3149
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=178098759
This should be a no-op change. And it eliminates the need to use the index variable
which will be removed once the MediaPeriodHolderQueue is implemented.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177963360
In some occasions, we may want to discard a part of the buffered media to
improve playback quality. This CL adds this functionality by allowing the
loading media period to re-evaluate its buffer periodically (every 2s) and discard
chunks as it needs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177958910
In order to facilitate enabling a compile-time error check, we are suppressing these existing instances. Once the compile-time error is enabled, we will file bugs to clean up any unfixed instances in [].
Note that this CL should result in no effective changes to the code, but the code as currently-written might contain a real bug. If you'd prefer to fix the bug now, please either reply with edits, or accept this CL then follow up with a change that fixes the underlying issue.
Tested:
tap_presubmit: [] Some tests failed; test failures are believed to be unrelated to this CL
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177836122
This is a step towards harmonizing the MediaSource Builders and (potentially)
providing MediaSource factories.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177783157
Waiting for the timeline change didn't work correctly because the timeline was
already equal to Timeline.EMPTY (due to the masking). Now waiting explicitly
for the empty Timeline exposed by the source.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177749292
- Remove skipping of the VBRI/XING frame before calculating position
offsets. This was incorrect. Instead, a constraint is used to ensure
we don't return positions within these frames, the difference being
that the constraint adjusts only positions that would fall within
the frames, where-as the previous approach shifted positions through
the whole stream.
- Excluded last entry in the VBRI table because it has an invalid
position (the length of the stream).
- Give variables in XingSeeker descriptive names.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177451295
The set of active audio processors was only updated on reconfiguration and when
draining playback parameters completed. Draining playback parameters are cleared
in reset(), so if parameters were set while paused then the sink was quickly
reset, without draining completing, the set of active audio processors wouldn't
be updated. This means that a switch to or from speed or pitch = 1 would not be
handled correctly if made while paused and followed by a seek.
Move resetting active audio processors from configure (where if the active audio
processors were reset we'd always initialize a new AudioTrack) to initialize().
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177442098
- This change snaps the seek position for constant bitrate MP3s
to the nearest frame boundary, avoiding the need to skip one
byte at a time to re-synchronize (this may still happen if the
MP3 does not really have fixed size frames).
- Tweaked both ConstantBitrateSeeker and WavHeader to ensure the
returned positions are valid.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177441798
Support ad MediaSources that aren't prepared immediately by using
DeferredMediaPeriod, moved up from DynamicConcatenatingMediaSource.
In a later change the new interfaces will be made public so that apps
can provide their own MediaSource factories.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177424172
captions fetcher architecture.
1. ManifestlessCaptionsMetadata
Other captions fetchers must first fetch a manifest (HLS or manifest) to
discover captions tracks. This process does not exist for manifestless. All
we need to do is scan the FormatStream's for the right itag, so this is an
all-static class.
2. ManifestlessSubtitleWindowProvider
Once a captions track is selected, a subtitles provider is instantiated. This
is the main interface used by the player to retrieve captions according to
playback position. This class stores fetched captions in a tree index by time
for efficient lookups. Background captions fetches are used to populate
the tree.
3. ManifestlessCaptionsFetch
Captions are fetched one segment at a time. One instance of this object
is required per fetch. It performs a blocking fetch on call(), and is
intended to be submitted to a background-thread executor.
4. ManifestlessCaptionsFetch.CaptionSegment
This is the result of the caption fetch. These values are used to populate
the captions tree.
Manifestlessness
The initial request is always a headm request. There is a separate tree
of every segment indexed by start time. This tree is used to improve
manifestless sequence number calculation. Once we have data for the current
timestamp, we walk forward through the tree to find the next unfetched
sequence number, and fetch that.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177385094
Currently FragmentedMp4Extractor only parses and outputs emsg messages if the
flag FLAG_ENABLE_EMSG_TRACK is set (when there's a metadata renderer that
handles emsg messages). Since there are emsg messages that only targets the
player, which we want to handle independently from MetadateRenderer, this CL
adds the ability for FragmentedMp4Extractor to output emsg messages to an
additional TrackOutput if provided, independently from FLAG_ENABLED_EMSG_TRACK.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177318983
- Avoid re-downloading data prior to the first mdat box when
seeking back to the start of an unseekable FMP4.
- Avoid re-downloading data prior to the first frame for
constant bitrate MP3.
- Update SeekMap.getPosition documentation to allow a non-zero
position for the unseekable case. Note that XingSeeker was
already returning a non-zero position if unseekable.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177317256
There are still things broken about the seeker, but this
cleans up some of the weird bits.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177315136
Makes it less error-prone to accidentatly forget to set the right overwrites.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177282089
This allows to keep the state synced with ExoPlayerImpl after stopping the player,
but still releases the media source immediately as it needs to be reprepared.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177167980
We can acknoledge seeks before preparation finished immediately now,
because ExoPlayerImpl won't leave the masking state until the first prepare
operation is processed.
As a side effect, it also cleans up the responsibility of the callbacks.
Prepares are always acknowledged with a SOURCE_INFO_REFRESHED, while seeks
are always acknowledged with a SEEK_ACK.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177144089
The ExoPlayerImpl implementation forwards the stop request with this optional
parameter. To ensure correct masking (e.g. when timeline updates arrive after
calling reset in ExoPlayerImpl but before resetInternal in
ExoPlayerImplInternal), we use the existing prepareAck counter and extend it
also count stop operations. For this to work, we also return the updated
empty timeline after finishing the reset.
The CastPlayer doesn't support the two reset options so far.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177132107
