Allow skipping an ad group when requested by IMA, even if we aren't currently
playing one, to handle cases where no ads in an ad group will load (so IMA
requests resuming content but we never managed to start playing an ad).
Use the known ad group index (rather than the expected one) when handling ad
group load errors. This ensures we skip the right ad group if we notify IMA of
playback errors for every ad in the ad group, then IMA notifies that the ad
group is empty via a load error.
Also make some other miscellaneous small fixes to ads code:
- Avoid warning about unexpected ad group indices more than once.
- Output a warning if the ad count in an ad group decreases.
- Remove unnecessary assertion.
- Fix getting the ad duration for ad indices that haven't loaded yet.
- Allow setting an ad group state to its current value.
- Fix javadoc for setting the ad resume position.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184831495
The ad index in the ad group may need to skip over ads that failed to load, so
it can't just be incremented any more.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184812556
This feature is supported in the ConcatenatingMediaSource and is easily copied to this
media source. Also adding tests to check whether the atomic property works in normal
concatenation and in also in nested use.
Also fixes a bug where timeline methods of the DeferredTimeline were not correctly
forwarded.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184526881
This could happen when a media source is removed from a
DynamicConcatenatingMediaSource and one of its media periods is still active.
This media period is only removed by the player after the player received
a timeline update and thus we shouldn't release the removed child source
as long as it has active media periods.
Issue:#3796
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184522836
Resolve the media period for ad playback when resolving a subsequent period and
when receiving a timeline where the playing period in range (but wasn't before).
Fix the seek position calculation when a current ad must be skipped and is
followed by another ad.
Check MediaPeriodInfos match when checking MediaPeriodHolders, to handle cases
where a future ad should no longer be played. This may involve playing two
content media periods consecutively.
Issue: #3584
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184514558
DefaultExtractorInput.SCRATCH_SPACE buffer is used to skip data by
reading it into this buffer and discarding.
Simultaneous use of skip methods corrupts this buffer. Normally the
read data is discarded so it doesn't matter but the underlying
DataSource may use the buffer too. If it's a CacheDataSource it uses
this buffer to read data from upstream then write to cache.
Issue: #3762
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184502170
This avoids reading a format that is not equal because of switching between
NO_VALUE and 0.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184298076
This makes assertion errors in code running on the Looper less easy to miss.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184294290
For below API level 16, the logic copied from ConnectivityManagerCompat.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184131406
Helper class to create notifications for downloads using DownloadManager.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183225948
Even if a developer synchronizes every method, thread safety is still not guaranteed
because the internal callback methods can't be synced from outside.
Issue:#3773
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184122072
1. Add string for STATE_CANCELED. Lint doesn't like that the
switch statement on the state IntDef doesn't have a case
for STATE_CANCELED. May as well add one, even if we're not
planning on our demo app showing notifications for this
state.
2. Replace non-human-readable error message with one provided
by ErrorMessageProvider.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184120892
In the case of the components we deliberately access via
reflection, it's normal that they might not be resolved
due to proguarding (i.e. if the app isn't being built to
include them). Don't note their omission.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184120611
I think (?) they're harmless, but lint doesn't like them.
Using them within the class body means the TargetApi
annotation applies, which makes lint happy.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184117951
In MediaCodecRenderer, we currently uses codec.getInput/OutputBuffers event
though these APIs are deprecated and are not recommended from API 21+. This
change makes sure that:
- On API 20 and below, we will keep using codec.getInput/OutputBuffers.
- On API 21+, we will use getInput/OutputBuffer(index) APIs instead.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184112329
*** Reason for rollback ***
Broke everything
*** Original change description ***
Clean up message naming in EPII
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=184061352
This make sure all media sources can be reprepared after being released.
Issue:#3498
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183990416
When the dynamic media source contains multiple empty timelines in a row and some
of them dynamically change to a non-empty timeline, the window and period indices
are not updated correctly because the index of the changed child source is wrong.
To fix this bug, the child index is added to the media period holder to have direct
access on the current child index to prevent ambiguity.
Furthermore, the uid is changed to be the hash code of the MediaSourceHolder not the
MediaSource itself to allow adding the same MediaSource twice without violating the
unique uid policy.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183973462
Also fixes a bug where deferred media periods were kept in the list for
an unprepared media source although the media period was already released.
Issue:#3498
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183800889
This enables caching manifest files for DASH, HLS and SmoothStreaming.
To disable caching a non cache DataSource should be provided for reading
manifest to the used MediaSource.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183794252
In startReadWrite*() methods a new CachedContent is created if the there
isn't one already for the given key. If the span is release without
writing any content, this fix removes the added CachedContent.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183666821
Before this change, the ad playback state stored the number of played ads in
each ad group. There was no way to represent that an ad had failed to load (and
it wouldn't be possible just to increment the played ad count to signal a load
error because there might be an unplayed ad before the ad that failed to load).
Represent the state of each ad (unavailable, available, skipped, played, error)
in each ad group. In a later change the player will use this information to
update its loaded MediaPeriods in response to future ads failing to load.
Also make the AdPlaybackState immutable and remove copying/duplication of its
fields in the ad timeline and period.
Issue: #3584
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183655308
1. When we try and load something via reflection and find the
class, always throw rather than failing silently if we
subsequently fail to instantiate an instance. This is
indicative of a broken proguard setup, and failing silently
makes it hard to spot.
2. Add library/core proguard configuration to ensure extension
renderer constructors that we access via reflection are kept.
3. Add demos/main proguard configuration to ensure ImaAdsLoader
constructor that we access via reflection is kept.
4. Added IMA proguard file to hopefully fix#3723, although I
wasn't actually able to reproduce the issue.
Issue: #3723
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183648187
- Renderers becoming ready is asynchronous, so the change wasn't
well thought through :(.
- This will bring back the possibility of getting stuck in the
buffering-but-not-loading anything state. This will need to be
addressed in a future CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183646837
100ms is unrealistically short and, for example, causes the player to buffer
many periods ahead when looping.
Previously this was not feasible, because ExoPlayerTest as instrumentation test
actually needed to wait for the realtime playback duration.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183646772
MediaPeriodInfoSequence has functionality for determining what MediaPeriod
should be loaded next. Move this into the queue as an initial step towards
moving logic concerning updating the queue of media periods out of
ExoPlayerImplInternal.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183391114
This removes some boiler-plate code for compostite sources and will also
simplify resuing media source in the future (because this class can keep track
of child listeners).
Issue:#3498
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183387123
- This gives LoadControl enough information in shouldContinueLoading
to know whether returning false will result in a terminal non-playback
state.
- DefaultLoadControl will always return true when returning false will
result in a terminal non-playback state, unless the target buffer size
is exceeded. This can help to avoid getting stuck in the case that a
MediaPeriod is providing samples from an unexpected starting time.
- Make the terminal state actually terminal. Previously the player would
end up in an indefinite buffering state. We now fail with an error.
- Also remove the opportunity for LoadControl implementations to livelock
playback. No sane LoadControl should simultaneously tell the player that
it doesn't want to load anything and that it doesn't want to start
playback. So this change removes the opportunity and starts playback in
EPII instead in this case.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183114797
Try to delay failure for as long as possible. That is, propagate
DRM session failures only after an encrypted buffer arrives or clear
sample playback without session is not allowed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=183076348
setBytesRemaining() doesn't work when called after closeCurrentSource()
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=182999254
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
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
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 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
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
- 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
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
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
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
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
Unconditionally waiting for the action schedule to finish in ExoPlayerTestRunner
doesn't work if the action schedule is not intended to be finished.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177024139
Also slightly improve language normalization/documentation.
For this CL, it is assumed that null and "und" languages are different
entities. Once we fully tackle language tag normalization, we can decide
whether to normalize the "undefined" language.
Issue:#2867
Issue:#2980
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177008509
Update the default AdaptiveTrackSelection and DefaultLoadControl to use playback
speed information.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176989168
currentTimeMillis is not guaranteed to be monotonic and elapsedRealtime is
recommend for interval timing.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176853118
Fixed by explicitly waiting for the timeline update. This shouldn't be
necessary and will be removed as soon as the correct order of events
can be guaranteed (timeline change -> state change -> onSeekProcessed).
The waiting for the timeline update is implemented by introducing the
feature that the test runner also waits until the action schedule has
finished before stopping the test.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176848540
This is mostly useful for suppressing the initial position
discontinuity reported by ClippingMediaPeriod.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176758972
This brings ClippingMediaSource clip failures in line with
what MergingMediaSource does when it cannot merge.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176660123
It currently always reports 0, but it should report the position
passed through selectTracks. Reporting should also be disabled if
there's a seekToUs call.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176644228
Until recently, changing primary track formats were reported when the
corresponding media chunk was discarded which always happened immediately
after the sample has been read.
Now, media chunks may be discarded later on or in batches, leaving the
current reporting mechanism broken because changes may never be reported.
This fix separates the discarding from the reporting such that format changes
can be reported when the media chunk is first read from, while the discarding
operation only discards without reporting format changes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176519071
Currently EventMessage's presentationTimeMs is kept separately in
EventSampleStream. However, EventMessage's presentationTimeMs maybe used in
other places besides EventSampleStream, such as when handling `emsg' messages
targeting the player. This CL let EventMessage object to holds its
presentationTimeMs for such use cases.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176502938
We (eventually - albeit possibly infinitely far in the future)
expect a timeline update with a window of known duration. This
also stops live radio stream playbacks transitioning to ended
state when their tracks are disabled.
As part of this fix, I found an issue where getPeriodPosition
could return null even when defaultPositionProjectionUs is 0,
which is not as documented.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176492024
This allows implementations of those classes to take into account the playback
speed for adaptive track selection and controlling when to resume the player.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176484361
The ExoPlayerImplInternal.reset method now takes the same set of options
as the ExoPlayer.prepare method. This also allows to
- Remove some code duplication within ExoPlayerImplInternal
- Fix calls to prepare(sameSource, resetPosition=true, resetState=false)
with enabled shuffle mode where the position was not correctly reset to the
first period index.
- Keep the current timeline when calling stop (in line with ExoPlayerImpl).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176481878
Currently onTimelineChanged doesn't allow to distinguish easily between the
different reasons why it's being called. Especially, finding
out whether a new media source has been prepared or the current source
refreshed dynamically was impossible without tightly coupling the player
operations with the listener.
The new reasons provide this disdinction by either indicating a newly
initialized media source, a dynamic update to an existing timeline
or manifest, or a reset of the player (which usually results in an
empty timeline).
The original onTimelineChanged method without reason is kept in the
DefaultEventListener as deprecated to prevent the need to update all
existing listeners in one go.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176478701
This causes the player to report that it's started loading
when in the ended state.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176371892
- Properly report internal discontinuities
- Add DISCONTINUITY_REASON_SEEK_ADJUSTMENT to distinguish
seek adjustments from other internal discontinuity events
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176367365
Currently for a DASH ChunkSource that consists of multiple sub-streams, we
always use a CompositeSequenceableLoader, which only allows the furthest behind
loader or any loader that are behind current playback position to continue
loading.
This changes allow clients to have more flexibility when deciding the loading
strategy:
- They can construct a different kind of composite SequenceableLoader from
the sub-loaders, and use it by injecting a different CompositeSequeableLoaderFactory accordingly.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176363870
This class implements MediaClock itself and handles the switching between
renderer and standalone media clock.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176340615
Add Builder pattern to SingleSampleMediaSource and mark existing constructors as
deprecated.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176332964
- MediaSourceTestRunner aims to encapsulate some of the logic
currently used in DynamicConcatenatingMediaSourceTest, so it
can be re-used for testing other MediaSource implementations.
- The change also fixes DynamicConcatenatingMediaSourceTest to
execute calls on the correct threads, and to release handler
threads at the end of each test.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176117535
This test seems to obtain a timeline from a prepared
FakeMediaSource, but that's identical to the timeline
passed into that source to start with :).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176117133
This is helpful for tests which don't care about detailled timeline set-ups
besides the number of windows.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176097369
Add Builder pattern to ExtractorMediaSource and mark existing constructors as
deprecated.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=176088810
This change makes sure progress is being made before reporting
a discontinuity. Else in cases like having no network and
playing a live stream, we allow the discontinuity to be read
each time an internal retry occurs, meaning it gets read
repeatedly. This does no harm, but is noisy and unnecessary.
We should also not allow skipping whilst there is a pending
reset or discontinuity notification, just like we don't allow
reads.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=175953064
Also switch from using MIME types to C.ENCODING_* encodings in DefaultAudioSink.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=175936872
The purpose of this change isn't to fix anything. It's just to
simplify things a little bit. There will be following CLs that
make some changes to get things onto correct threads.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=175800354
This allows to remove the LazyMediaSource used within
DynamicConcatenatingMediaSourceTest and also allows to write test which
simulates dynamic timeline or manifest updates.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=175680371
Also replaced the duplicated EMPTY track group array with the one already defined
in TrackGroupArray.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=175670266
Also added tests which verify the intended behaviour.
GitHub:#3452
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=175656478
This is a step toward retaining a back-buffer in a way that
works for all MediaSource implementations. It's not possible
to adjust the discardBuffer calls in ExoPlayerImplInternal
to discard up to (position - backBufferDurationUs). Next steps
are to:
1. Find an appropriate place to specify the back buffer value,
to be passed to the discardBuffer calls. I guess the
LoadControl is the appropriate place to define such values.
2. Enhance discardBuffer to support a toKeyframe argument to
pass through to discardTo.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=175565363
Add onEnable() and onDisable() call-backs to TrackSelection. This allows
TrackSelection to perform interesting operations (like subscribe to
NetworkStatus) and clean up after itself.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=175558485
This will be needed when retaining a back-buffer. Being able to
query the first index allows us to work out when we've discarded
all samples that were obtained from a particular chunk, which
we'll use to determine when to remove chunks from
ChunkSampleStream.mediaChunks.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=175172085
In the case converting cache files from an earlier version of
SimpleCache, there is no previous version of the index file. If the app
doesn't call any SimpleCache methods which would make the index file
stored before it exists whole data gets lost.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=175153650
These callbacks are executed on the app thread after the corresponding
timeline update was triggered. This ensures that seek operations see the
updated timelines and are therefore valid, even if the seek is performed into a
window which didn't exist before.
GitHub:#3407
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=175136187
When the renderer media clock source read its stream to end but is not ready,
this means one of two things. Either the next period is not prepared yet and
we need to stop the renderers and buffer until it's prepared, or we are
waiting for another track in the current period with a uneven (longer)
duration.
The second case was already covered by this if condition and uses the standalone
clock instead to continue.
The first case now also uses the standalone clock, but it doesn't make a
difference, because both clocks are stopped and still synchronized.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=175134975
MPD file may include multiple EventStreams in its Periods, which contains Events
that the application may need to handle/respond to.
This change adds support for parsing the EventStream/Event nodes from MPD
file, and exposing these EventStreams as a metadata sample stream that application
can respond in a similar way to other metadata events.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=175017697
Removes duplicated code and starts cleaning up handling of media clocks.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=174829840
This prevents users from having to check sideloaded subtitles URLs before
preparing a SingleSampleMediaSource with it.
Issue:#3140
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=174475274
This is the first CL in a series to add chunkless preparation support.
Also did a bit a tidying up in HlsSampleStreamWrappen and
HlsMasterPlaylistParserTest.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=174461737
This also allows exposing multiple CC channels to any fMP4 extractor client.
Issue:#1661
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=174458725
First fix, prevents forced rewriting when cipher is set but encrypt is
false.
Second, removes the store() call in SimpleCache.initialize() so
initialization doesn't fail because of CachedContentIndex write issues.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=174450586
The mediaChunks.size() > 1 check was supposed to ensure this, and
did roughly the right thing when there was only a single stream
(although it was unnecessarily restrictive in preventing chunk
cancelation for the first chunk, where bytesLoaded != 0 and none
of the samples had been consumed).
Now we have multiple streams the check doesn't do the right thing,
and adding a back-buffer feature will make even more incorrect.
This change switches to checking the condition we actually want
to check directly :).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=174449398
*** Reason for rollback ***
Breaks setting PlaybackParameters before start of playback
*** Original change description ***
Add support for float output in DefaultAudioSink
Also switch from using MIME types to C.ENCODING_* encodings in DefaultAudioSink.
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=174445506
Client can add this functionality by extending DownloadService.
Also made DownloadManager accept multiple listeners. So instead of
broadcast event, client can listen to DownloadManager directly.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=174335820
Instead of using an Executor to run DownloadTasks creates and manages
threads internally.
Also added DownloadThread internal class to better separate the code
that doesn't run on the main thread.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=174036872
1. Move Timeline/Manifest into PlaybackInfo
2. Don't update externally visible Timeline/Manifest during preparation
3. Ignore MSG_POSITION_DISCONTINUITY during preparation
4. Correctly set masking variables at start of preparation, and use them
Once this change goes in, PlaybackInfo will contain timeline, manifest
and position, which should always be self-consistent with one another.
The next step would then be to move a bunch of logic in ExoPlayerImpl
that derives state from timeline and position into PlaybackInfo, and
split that into its own top level class that can be easily tested to make
sure it never IndexOutOfBounds.
I think we could also replace the masking variables and instead just assign
a new PlaybackInfo to the playbackInfo variable whenever we're doing
something that requires masking. This should be possible because we no
longer update playbackInfo whenever we have pending acks. It would
require allowing PlaybackInfo to mask the window position internally when
the timeline is empty, but I think this is ok, and again is something we
could test pretty easily.
Issue: #3362
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=173909791
This makes it a bit more obvious what's going on during
preparation. In particular, it makes it clear that
MSG_SOURCE_INFO_REFRESHED arrives before MSG_TRACKS_CHANGED.
Issue: #3362
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=173392080
Also switch from using MIME types to C.ENCODING_* encodings in DefaultAudioSink.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=173379623
We don't expect this case to occur, since track selection is
normally expected to check canAcquireSession before selecting
a track. Nevertheless, if an attempt is made to acquire a
session when the media doesn't support the manager's UUID, we
should fail in a more graceful way.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=173124170
Other catch blocks in this class catch everything. This one should
too.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=173118891
Tasks conflict if both of them work on the same media and at least one
of them is remove action.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172741795
We have been using USE_CHORD_PITCH == false for a while and the quality of
pitch changes seems fine. It's now possible to set the sample rate too, but
this only works if USE_CHORD_PITCH is false, so remove the constant.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172736631
- When transitioning to a new period, the value of bufferedDurationUs
passed to TrackSelection.updateSelectedTrack was incorrectly set to
0. It should have been set to correctly reflect buffered media in
previous periods still being played out.
- This change fixes the issue described above, and also propagates the
playback position through to this method. The position of the next
load within the period can be calculated by adding the position and
bufferedDurationUs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172736101
If connecting a Bluetooth audio device fails, the AudioTrack may be left in a
bad state, where it is not actually playing and its position has jumped back to
zero. Detect and work around this case by resetting the track.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172600912
prepare and selectTracks receive the position from which any
loading should start, where-as continueLoading receives the
actual playback position. These are different in the case that
a previous period is still being played out.
Also removed "relative to the start of the period" from prepare
documentation because it couldn't really be relative to anything
else.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172592769
newPlayingPeriodHolder could be set then updated if seeking to a repeated period
that was loaded more than once. This led to MediaPeriodHolders leaking.
Only set newPlayingPeriodHolder once so that any later holders with the same
period identifier get released.
Also add a regression test. FakeMediaSource checks that all created
MediaPeriods were released when it is released.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172591937
This is not really useful with the DefaultAudioSink, but could be used in a
custom AudioSink when mixing audio from sources that have different sample
rates.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172434482
1. Ignore edit list where the sequence doesn't contain a sync
sample, rather than failing.
2. Make Mp4Extractor.readAtomPayload so it doesn't try and read
the same payload twice if a failure occurs parsing it.
3. Make processAtomEnded so that it doesn't pop the moov if
parsing it fails.
Issue: #3351
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=172106244
This change fixes various issues:
- MobileHarness sometimes allocated devices with SDK < 16. As we have no tests running
on these SDKs, a new dimension filter for the mobile_test target ensures that only
devices with SDK >= 16 are selected. A similar filter for SDK version is also added
to the ABR playback tests to ensure no old devices are selected.
- DRM specific tests are skipped for Api < 18, but were not able to run because the
DashTestRunner class tried to link to the MediaDrm constructor. Moved the
constructor to a seperate Builder class to allow execution on Api levels 16 and 17.
- DashWidevineOfflineTest also tried to access code for Api >= 18 without checking
the current level.
- Action implementations which are waiting for events did not ensure that they have a
nextAction to wait for. This caused NullPointerExceptions when this next action was
scheduled.
- DefaultDrmSession always restored the offline keys when a new license was requested,
even if the keys were already restored. These repeated slow calls to restoreKeys
resulted in high numbers of dropped buffers.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171974859
Update the audio track selection logic in DefaultTrackSelector:
- When forcing lowest bitrate, use bitrate as tie-breaker when track scores are
the same, prefer the lower bitrate.
- Otherwise, use one of the following values as tie-breaker in order:
- ChannelCount
- SampleRate
- BitRate
If the format being checked is within renderer's capabilities, select it if it
has higher tie-break value, else, select it if it has lower tie-break value.
If all tie-break values are the same, prefer the already selected track.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171803092
MediaCodecRenderer implementations require DrmSessionManager<FrameworkMediaCrypto>,
but it's currently not possible for an app to provide a custom implementation due
to FrameworkMediaCrypto having a package private constructor. This change exposes
public FrameworkMediaCrypto constructors, hence removing this restriction.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171718853
Calling HandlerThread.quit() or .quitSafely() doesn't immediately terminate
the thread. It just instructs the Looper not to accept any new messages and
to terminate at the next opportunity. Added a HandlerThread.join() everywhere
where the intention is to close and release all resources and to stop all
threads.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171525241
This change also replaces individual DownloadAction versions with a
single master version.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171273880
For initial DRM provisioning and key request, we allow the requests to be
retried (with increasing delay for each successive retry) before failing.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171271384
Controls are still hidden while playing ads, but if the app pauses the player,
controls will be shown. During ads, the player is not seekable.
When the player enters the background then returns to the foreground, the
content period may not be prepared, so also cache the content window duration.
This means that if the app reenters the foreground while an ad is paused the
time bar can be populated.
Issue: #3303
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171123428
Now this counter includes input buffers too, which are dropped as part of
skipping to keyframes for catch up.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=171119930
If the current output buffer is very late and the playback position is in a
later group of pictures, drop all buffers to the keyframe preceding the
playback position.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170975259
This is useful to determine when a seek request was processed by the player
and all playback state changes (mostly to BUFFERING) have been performed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170826793
Updates DefaultDrmSessionManager to use the prefered Widevine version (v1
on >= 23 and v0 for < 23).
For other DRM schemes, uses the first scheme found.
* Always assume a renderer is ready if it's read to the end of
its current stream and there's a subsequent period already
prepared. This prevents getting stuck when a non-clock renderer
has a short stream.
* Switch to the standalone clock if the renderer providing the
media clock has read to the end of its current stream, is no
longer ready, and there's a subsequent period already prepared.
This prevents getting stuck when a clock renderer has a short
stream.
* Remove unnecessary clock synchronization logic (since it would
need to be made more complicated as a result of this change).
* Don't update the playing period holder when playWhenReady is
false. This avoids the position jumping to the start of the
next period when seeking to the very end of the current period
whilst paused (we still end up showing the first frame of video
from the next period, but fixing that will have to wait).
Github: #1874
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170717481
This avoids spurious position reports following an underrun.
Github: #1874
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170344399
This change allows applications to provide custom AudioSinks, which could be
based on android.media.AudioTrack like AudioTrackAudioSink, or could be
completely custom.
The refactoring is mostly mechanical and shouldn't result in any functionality
changes.
Some android.media.AudioTrack-specific details have to appear in the AudioSink
interface so this change modifies the javadoc on the AudioTrack (now AudioSink)
to note that some methods will have no effect.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170311083
This allows simplified listener implementations as most listeners
will not listen to all possible notifications.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=170177821
This includes both cbcs and cenc. Will only work for streams that require a single
pssh.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=169382884
There's no reason to perform the discontinuity check or skip
the adaptation field if we don't have a payload reader for
the packet.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=169374609
This fixes infinite loop in LeastRecentlyUsedCacheEvictor.evictCache when index store fails.
Also made CachedContentIndex not final so it can be mocked and added a package protected SimpleCache
constructor so mock index can be injected.
Issue: #3260
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=169249517
This case may happen if the max span size is more than the max size the
evictor is configured.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=169101093
1- Avoid dropped buffers by using a PriorityQueue instead of a set.
2- Process the end of stream after non-EOS buffers.
Issue:#3250
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=169077365
1. Only tell sessions that want provisioning when provisioning occurs.
2. Also propagate failure to provision to these sessions.
3. If a session responsible for provisioning is released, start
provisioning using another session instead.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168713918
- MediaDrmEventListener.onEvent is typically called on the
app's main thread. mediaDrmHandler is instantiated on the
playback thread. Hence mediaDrmHandler should be volatile
to ensure visibility.
- Nulling mediaDrmHandler could result in a NPE in onEvent.
Instantiate mediaDrmHandler (and don't null it again) to
avoid this. MediaDrmHandler.handleMessage will correctly
discard any events for sessions that are now closed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168707938
AdsMediaSource lives in the core library so only ImaAdsLoader remains in
the ima extension. AdsMediaSource takes an AdsLoader implementation.
ImaAdsMediaSource is deprecated rather than removed for now.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168707921
Currently, to make transition to next media period seamless, after the renderer
has read until the end of the current SampleStream, we may send it the next
SampleStream so the renderer may read from the next SampleStream ahead of the
transition.
For NoSampleRenderer, we should avoid doing this: skipping ahead for such
renderer doesn't have any benefit (the renderer does not consume data from
SampleStream), and it will change the provided rendererOffsetUs while the
renderer is still rendering from the playing media period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168669800
This allows listeners to easily determine the source of the discontinuity.
Reasons can be period transitions, seeks, and internal reasons.
Listeners still using the deprecated ExoPlayer.EventListener interface were
updated to Player.EventListener.
GitHub: #3252
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168549612
Remove gapless functionality that relies on MediaCodec, and implement this in
an AudioProcessor instead.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168547487
Currently our Renderer is always associated with and consume data from
some SampleStreams, which were constructed from the provided MediaSource.
There are use-cases, in which the users want to have simple Renderer
implementation that does not consume data from SampleStream at all, but
render using their custom logic at each rendering position - they mostly just
need ExoPlayer to keep track of the playback position and enable/disable the
renderer.
This CL adds support for such Renderer by adding a TRACK_TYPE_NONE.
Renderer of such type will be:
- Associated with null TrackSelection as the result of track-selection
operation.
- Associated with EmptySampleStream.
GitHub: #3212
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168545749
In live streaming, if the playback position is very close to live edge,
the buffered duration will never reach minDurationForQualityIncreaseMs,
which prevents switching from ever happening. So we will provide the
durationToLiveEdgeUs to AdaptiveTrackSelection in live streaming case,
so it can handle this edge case.
GitHub: #3017
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=168535969
The release callback handler in Loader might not be alive
anymore. Catch this case to prevent warnings about sending
messages on dead threads.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167996538
Remaining instrumentation tests either use android.os.Handler or rely on assets.
In the latter case, the tests are difficult to migrate due to differences
between the internal and external build systems, and configuration needed in
Android Studio. In addition, SimpleCacheSpanTest remains as an instrumentation
test because it fails due to a problem with string encoding on the internal
build (and two other tests in its package are kept with it because they depend
on it).
This test removes a dependency from testutils on Mockito, as a different
version of Mockito needs to be used for instrumentation tests vs Robolectric
tests, yet both sets of tests need to rely on testutils. Mockito setup is now
done directly in the tests that need it.
Move OggTestData to testutils so it can be used from both instrumentation and
Robolectric tests.
It may be possible to simplify assertions further using Truth but this is left
for possible later changes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167831435
Everything should go through the ExoMediaDrm layer. We still
need to abstract away the android.media exception classes, but
this is left as future work.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167710213
Reporting incorrect positions for ad playbacks was causing IMA to
think the ad wasn't playing, when in fact it was.
Issue: #3180
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167702032
Also pass an unresolved end point to ClippingMediaPeriod. This removes some
assertions checking timestamps in the ClippingMediaPeriod, but makes it
possible to identify when the end point is at the end of the media.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167683358
The default implementation is just calling through to handler.postDelayed,
while the fake clock uses its internal time value to trigger the handler
calls at the correct time.
This is useful to apply a fake clock in situations where a handler is used to
post delayed messages.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167567914
Currently FlacDecoder/FlacExtractor always perform resampling to 16bit. In some
case (with 24bit audio), this might lower the audio quality if the system
supports 24bit audio.
Since AudioTrack implementation supports resampling, we will remove the
resampling step, and return an output with the same bits-per-sample as the original stream.
User can choose to re-sample to 16bit in AudioTrack if necessary.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167494350
The bytesRemaining didn't always take into account any skipped bytes, which
meant that reaching the end of the file was not correctly detected in read().
Issue: #3216
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167016672
UTF-8 is the default charset on Android so this should be a no-op change, but
makes the code portable (in case it runs on another platform).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=167011583
*** Reason for rollback ***
Doesn't work because trackOutputProvider can be null when extracting init data.
*** Original change description ***
Don't copy primary-track format to non-primary tracks
Copying non-primary-track formats to non-primary tracks
looks non-trivial (I tried; went down a dead-end), so
leaving that for now.
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166883654
1. Make LeanbackPlayerAdapter use a ControlDispatcher. This
allows apps to suppress control events in some circumstances,
and is in-line with our mobile controls.
2. Misc simplifications and cleanup to LeanbackPlayerAdapter.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166852816
Also workaround the non-repeatable queue and fix other minor issues.
Issue:#2283
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166848894
This mapping when we call into platform components also needs
to be applied when creating the MediaCrypto instance. The fix
is to stop propagating the UUID through all the createMediaCrypto
methods. This is unnecessary, since the eventual target already
knows its own UUID!
Issue: #3138
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166843372
Copying non-primary-track formats to non-primary tracks
looks non-trivial (I tried; went down a dead-end), so
leaving that for now.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166843123
Both cases were not supported so far. Added tests which all failed in the
previous code version and adapted the concatenated media sources to cope with
empty timelines and empty concatenations.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166480344
This is mostly connecting the already stored shuffleMode with the timeline queries
for the playback order.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166199330
The media source is initialized with a DefaultShuffleOrder which can be changed at
any time. Whenever the list of media source is changed, the shuffle order is adapted
accordingly (either on the app thread if the player is not prepared yet, or on the
player thread). The shuffle order is then used to construct the timeline.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166198488
The media source is initialized with a DefaultShuffleOrder which can be changed at
any time. This shuffle order is then used within the corresponding timeline.
The isRepeatOneAtomic flag is extended to also suppress shuffling (now called
isAtomic only).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166197184
Make getMediaFormat protected so that subclasses can set additional MediaFormat
keys. For example, if the decoder output needs to be read back via an
ImageReader as YUV data it is necessary to set KEY_COLOR_FORMAT to
COLOR_FormatYUV420Flexible.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166195211
The implementation in the abstract base class takes care to forward the queries
to the correct methods given the shuffle mode and a given shuffle order.
All concatenated timeline implementations use an unshuffled order so far. The
handling of the shuffle orders will follow in other changes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166191165
In addition, let unit test assert window indices for both shuffle modes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166191069
This functionality is most likely needed by UI modules which currently need
to obtain the timeline, the current repeat and shuffle modes and are only then
able to query the next/previous window index using this information.
Adding these methods simplifies these cumbersome requests.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166181202
This allows to test the expected behaviour of timeline with different shuffle modes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166181091
This parameter is used by methods such as getNextWindowIndex
and getPreviousWindowIndex to determine the playback order.
Additionally, there are method to query the first and last
window index given the shuffle mode.
None of the timeline implementations nor the ExoPlayer
implementation supports shuffling so far.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166170229
The shuffle mode is saved using a message on the playback thread.
After setting the shuffle mode, the same media period holder verification
as for repeat mode changes gets executed.
Note: the shuffle mode is not used yet to change the playback order.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166060231
And implement a basic version of the methods in all implementations.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=166041342
These methods are only used in one place, and offer duplicate
functionality to checking getNext(Previous)WindowIndex == C.INDEX_UNSET.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=165910258
There will be non-ExoPlayer players that can output text
and metadata, so the outputs should be standalone. There
may also be ExoPlayer instances that use non-standard
text and metadata renderers, for which this change also
makes sense.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=165628420
If the main thread was interrupted during
ExoPlayerImplInternal.blockingSendMessage/release, the interrupted flag was
immediately set but then wait() was called on the next iteration. wait() would
immediately throw InterruptedException, causing the main thread to spin until
the blocking operation completed.
Instead of resetting the flag immediately, reset it after the blocking
operation completes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=165426493
to be disabled gracefully: encrypted index files may be read, but plaintext will be written.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=165196508
- HlsDownloader.loadManifest (previously called getHlsPlaylist)
suppressed errors for the offline case, where-as the DashUtil
equivalent method did not. This change makes them consistent
and moves both other to use ParsingLoadable.
- Enable GZIP for manifest loads in both cases.
- Use Uri rather than String to represent Uris. Previously the
strings were parsed into Uris quite deep in the code, which
isn't ideal if the parsing fails; you'd probably prefer the
error to occur early at the top level.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=165181398
We've seen more than one issue filed where a developer has
registered a video listener and been confused by the fact
their SimpleExoPlayerView no longer works properly. There
are also valid use cases for having multiple metadata/text
outputs.
Issue: #2933
Issue: #2800
Issue: #2286
Issue: #2240
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164839882
- There is a proper ClearKey UUID now. This change requires
it to be used instead of the Common PSSH UUID when instantiating
DRM components.
- Internally, we'll map the ClearKey UUID onto the Common PSSH
UUID where necessary to (a) access the ClearKey CDM on older
devices, and (b) access drm init data stored under the Common
PSSH UUID in the stream.
Issue: #3138
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164839213
It's needed in multiple places. MediaSessionConnector uses it
today. Our leanback connector will also use it. Maybe
SimpleExoPlayerView should use one too, to show the message to
the user when an error occurs.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164720020
I considered using Util.scaleLargeTimestamp for this, but
given sample offsets are relative and should always be
small (<<1s), it really shouldn't be necessary.
Issue: #3139
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164443795
This is required to correctly update the playbackInfo.periodId when
seeking close to the end of a period with ads, as the seek operation
leads to an immediate source info refresh when midroll ads are marked as
played.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164257099
This implementation runs as fast as possible by triggering a simplified
playback loop continuously without waiting. The class only supports a basic
use case with a single-period timeline, no timeline update, no seeks or other
user-initiated actions.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164120420
Multiple timelines work as a wrapper around another timeline and forward
most of the method calls to the wrapped timeline. Added a base class meant to
be overridden which handles all the boiler-plate forwarding.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164117264
- Renamed some license URL related variables to keep consistency across the code.
- Added a new parameter to HttpMediaDrmCallback that enables forcing defaultLicenseURL as the license acquisition URL.
These classes maintain a shuffled order of indices allowing to query the
next, previous, first, and last indices. And also support inserting and
removing elements without changing the shuffled order of the rest.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=164116287
This helper class required a scratch instance to write on. Such a scratch
instance may violate the immuatability of the timelines if used by multiple
threads simultaneously.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=163992458
- Fix Ogg extractor to work without sniffing.
- Fix extractors to handle seek() before init().
- Add tests for both issues.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=163992343
This is for consistency with what we do elsewhere;
specifically in FragmentedMp4Extractor.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=163974960
The start code for H.262 codec-specific data may be across a packet boundary.
Before this change the offset passed to CsdBuffer.onData may have been before
the start point of the data in the newData buffer.
After this change, start codes are added directly to the CSD buffer when it's
filling and any start code bytes added by onData (at the end of a packet) are
discarded.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=163943584
- Publish IMA extension
- Force IMA to use the correct version of the support library
- Add missing sr translations for repeat mode strings
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=163705883
We do this in the dynamic case, and I think we've seen
a few GitHub issues where developers do this and don't
understand what they've done wrong (because the failure
comes later).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=163688557
Currently the ExoPlayerWrapper is used to run tests using an ExoPlayer
implementation. Some properties of the test are set in the constructor, some
are set by overloading the class, others are hard-coded in the
ExoPlayerWrapper class, and a mechanism similar to the existing ActionSchedule
is missing.
This change does the following:
1. Renames ExoPlayerWrapper to ExoPlayerTestRunner as it better reflects
its purpose.
2. Adds an internal Builder to easily set-up the test in a coherent way. This
allows to only set necessary test components while using defaults for the rest.
3. Integrate ActionSchedule.
4. Apply the new structure to the existing tests currently using ExoPlayerWrapper.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=163186578
Prepend sequence headers to the next frame, instead of appending them to
the previous frame. Tested decoders like FFMPEG and Google's
Android/MPEG2 expects to read the sequence headers before the first
frame they apply to. When sequence headers are appended to the previous
frame, these are ignored and this leads to incorrect decoding.
There's no way to represent a beta in our integer versioning
scheme. I propose we just set it the same for all betas + the
stable release. The versioning for the demo app isn't that
important, so I've just put it directly to 2.5.0 as well.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162749130
SKIPPED can't be handled as CONTENT_RESUME_REQUESTED because after skipping an
ad there may be further ads to play in its ad group.
Remove workaround for handling unexpected playAd without stopAd, as the player
can instead recover when IMA sends CONTENT_RESUME_REQUESTED. This in turn fixes
handling of the case where playAd is called twice but IMA expects only the
first ad to play, when skipping a particular ad. (Add an ad tag where this
occurs to internal samples.)
Check whether a currently playing ad has been marked as played in
ExoPlayerImplInternal, and handle this case as a seek. This ensures that any
loaded ad periods are discarded in the case of CONTENT_RESUME_REQUESTED.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162610621
When an ExtractorMediaSource is used in a concatenation, and
probably when using repeat modes, it needs to produce multiple
ExtractorMediaPeriods during usage. Currently we fire a
source info refresh every time a new ExtractorMediaPeriod
instance prepares, which triggers ExoPlayer.EventListener's
onTimelineChanged method. In nearly all cases the timeline is
unchanged after the first ExtractorMediaPeriod is prepared.
This change suppresses these no-op changes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162484234
A content period just before a postroll ad group with all ads played
was not being marked as the last media period in the timeline period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162471919
This is the first step towards facilitating Cast integration to ExoPlayer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162366198
When resetting a SampleQueue, by default the upstream format
is not cleared. This is necessary for progressive playbacks,
since (a) the formats never change, and (b) the extractors
only output them once. So when a seek occurs, it's necessary
to clear all sample data from the queue, but retain the current
upstream format.
Uniquely for HLS, the media in a SampleQueue that we may read
from can be in a format not supported by the consuming renderers.
We clear all the sample data from the queue in this case, but
not the upstream format. Since we have an optimization that
allows the upstream format to be read in advance of another
sample being written into the queue, this can result in an
unsupported format being read by a consuming renderer. This
change ensures the upstream format is correctly cleared in the
problematic case.
Issue: #3079
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162360267
The default behaviour stays the same as Clock.DEFAULT == SystemClock. And it
enables bandwidth measurements in tests with simulated clocks.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162350852
All implementations of SequenceableLoader already implement this method.
Moreover, all composite media periods contained an exact copy of an
implementation that now moved to CompositeSequencableLoader.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162349083
The FakeClock allows to simulate timing behaviour including sleep time
for test cases.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162345258
The position returned by getContentPosition() could be C.TIME_END_OF_SOURCE.
Fix the content position stored in MediaPeriodInfos for postroll ads to be the
duration of the containing period.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162322339
We currently read at most 5 packets at a time from the
extractor input. Whether this is inefficient depends on
how efficiently the underlying DataSource handles lots
of small reads. It seems likely, however, that DataSource
implementations will in general more efficiently handle
fewer larger reads, and in the case of this extractor
it's trivial to do this.
Notes:
- The change appears to make little difference in my
testing with DefaultHttpDataSource, although analysis
in #3040 suggests that it does help.
- This change shouldn't have any negative implications
(i.e. at worst it should be neutral wrt performance). In
particular it should not make buffering any more likely,
because the underlying DataSource should return fewer
bytes than are being requested in the case that it
cannot fully satisfy the requested amount.
Issue: #3040
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162206761
If seek is called for a non-seekable period, when the period is prepared the
start position will be updated from the seek position to zero. Because the
start position is part of the renderer offset for the first loaded period
holder, after the update the renderer offset start position and the new start
position would no longer cancel out, leading to the player position being
negative.
The first period holder's renderer offset is the fixed base offset (60 seconds)
plus its start position, but the start position is always subtracted. Avoid
subtracting the start position for the first period holder so that when it
changes there is no need to update the renderer offset.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162188133
This enables adaptive media test cases using TrackGroups with multiple
Formats.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162182005
This allows to create extensions of FakeDataSet and also simplifies the
FakeDataSource class.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=162180952
Also move to using an array to hold the SampleQueues,
as we've moved to doing in ExtractorMediaPeriod.
Issue: #551
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=161972990
drmInitData can be null in DASH if all of the init data is
specified at the manifest level instead. I took a look at
injecting the manifest format into the extractors, so that
we can actually copy the scheme type into it, but that's
at least non-trivial enough to delay for a subsequent CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=161956246
On an old version of okhttp, opening connection clears the thread interrupt flag silently. This is a workaround
to reduce the effect of the bug.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=161784435
ParsableBitArray.readBit in particular was doing an excessive
amount of work. The new implementation is ~20% faster on desktop.
Issue: #3040
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=161666420
Really low hanging fruit optimization for TS extraction.
ParsableBitArray is quite expensive. In particular readBits
contains at least 2 if blocks and a for loop, and was being
called 5 times per 188 byte packet (4 times via readBit). A
separate change will follow that optimizes readBit, but for
this particular case there's no real value to using a
ParsableBitArray anyway; use of ParsableBitArray IMO only
really becomes useful when you need to parse a bitstream more
than 4 bytes long, or where parsing the bitstream requires
some control flow (if/for) to parse.
There are probably other places where we're using
ParsableBitArray over-zealously. I'll roll that into a
tracking bug for looking in more detail at all extractors.
Issue: #3040
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=161650940
This CL also makes DefaultTrackSelector take it into account when RendererCapabilities
sets it to unsupported.
A following CL could add a DefaultTrackSelector parameter to force DRM "known support" for specific track types.
Issue:#1661
Issue:#1989
Issue:#2089
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=161556467
Let's do it this way for now. Note there's an implicit
assumption in here that non-AV tracks consist of only
key-frames, but I think we'll not encounter any issues
in the real world as a result, we already make this
assumption in ChunkSampleStream, and actually tagging
every queue with this information explicitly is a very
painful amount of plumbing.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=161545383
Once background and resuming is supported, the ads loader will be kept when the
player is destroyed and recreated. Move the state relating to the structure of
ads and what ads have been loaded/played out of the media source and into the
loader so the information is not lost when the source is released, in
preparation for supporting background and resuming.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=161503571
This option allows to move the currently playing media source to another position
and also to move other media source without creating a new MediaSource object.
Issue:#1706
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=161402022
1. maybeRenotifyVideoSizeChanged should report reported* variables
2. Add check into maybeNotifyVideoSizeChanged to suppress reporting
in the case that the width and height are still unknown.
Issue: #3007
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160879625
This cleans up test the TestUtil class that in large parts consisted of
assertions for Extractor tests.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160829066
The deprecated methods will be removed as soon as HLS is migrated
to use the new ones.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160827936
This also ensures that TimelineAsserts only contains assert methods.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160827271
They serve the same purpose. One was defined as single window, multi-period
timeline, while the other was a multi-window, single-period-each timeline.
The combined FakeTimeline uses TimelineWindowDefinitions which allow multi-
window, multi-period fake timelines.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160808844
It was a bit strange how it returned something via the return
value and something else via the "out" variable, and doing it
this way wasn't even saving any allocations.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160645640
Fake ExoPlayer componenets used within ExoPlayerTest.java can be useful for
other test classes and are therefore made available in testutils.
They can also be merged with other existing fake components.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160632908
Some parts of TimelineTest provided common assertions and helper classes for
other tests. As such, they better fit into testutils. In line with other
assertion methods, the TimelineVerifier class has been converted to a set of
static assertion methods.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160629797
(Related to GitHub #1706)
When the timeline becomes empty, the playback state transitions to "ended".
When the timeline becomes non-empty again, exceptions are thrown because MSG_DO_SOME_WORK is still regularly sent and media periods are getting prepared.
This change ensures that no MSG_DO_SOME_WORK messages are sent in "ended" state.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160537147
These changes are in part related to handling playback of mixed clear
and encrypted content, where we might want to use a secure decoder
throughout, but only have drm init data and only care about the state
of the DrmSession during playback of encrypted parts.
- requiresSecureDecoderComponent became unnecessary when we added
ExoMediaCrypto, which provides a layer in which requiresSecureDecoderComponent
can be overridden.
- Relaxed requirements for obtaining the MediaCrypto. It's helpful
to allow retrieval in the error state, since it can be used to
instantiate a decoder and play clear samples.
- Deferred throwing of errors in renderer implementations. As long as
we can get a MediaCrypto, we should init the codec. We can also
play clear samples without failing if playClearSamplesWithoutKeys is
true, regardless of the errors state.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160536365
This base class will be used to extend HlsDownloaderFactory from.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160523335
(GitHub issue #1706)
The media source allows adding or removing child sources before and after prepare() was called.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160516636
This is currently happening after toggling the repeat mode. This is line with
the rest of the implementation which requires a seek operation to resume
playback.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160516449
This also adds support for seeking in periods with midroll ads.
Remove Timeline.Period.isAd.
Issue: #2617
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160510702
Two of MediaPeriod's methods are only called after the media period has been
prepared. Added this to JavaDoc of these method to simplify implementations.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160510373
Add a compatibility AudioAttributes class so that the app can specify
audio attributes in the same way before and after API 21.
Deprecate SimpleExoPlayer.setStreamType. Add
SimpleExoPlayer.setAudioAttributes and MSG_SET_AUDIO_ATTRIBUTES.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160408574
Both methods make extensive use of MediaPeriodHolder internals.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160386401
Also update the time bar to show ad markers using in-period ads and
remove support for periods being marked as ads.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160382805
With this change, it becomes possible to depend on ExoPlayer
locally in settings.gradle by doing:
gradle.ext.exoplayerRoot = 'path/to/exoplayer/root'
apply from: new File(gradle.ext.exoplayerRoot, 'core_settings.gradle')
You can optionally add a prefix onto ExoPlayer's module names
by adding:
gradle.ext.exoplayerModulePrefix = 'prefix'
Issue: #2851
Issue: #2974
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160277967
It's currently difficult to use ExoPlayer modules in other gradle
projects because they rely on constants and dependencies defined
in our own top level gradle file. This change moves the constants
into a separate file referenced directly from each module. It also
removes the need for the top level gradle file to declare a
dependency on com.novoda:bintray-release. This is now only needed
if "exoplayerPublishEnabled = true" is specified.
Issue: #2851
Issue: #2974
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160272072
This will allow MediaSources to provide MediaPeriods that correspond to ad
breaks in a timeline period rather than content for a timeline period, in a
future change.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160267841
This better reflects the purpose of this flag and makes code more readable.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160246573
Getting active status of caching is needed to display on UI. Instead of a listener interface polling was chosen because of simplicity and better suits to UI refreshing.
CachingCounters.downloadedBytes was updated after whole data is downloaded. Now it's updated for each read into buffer. Buffer length defines how finer these updates are.
CachingCounters.totalBytes is added so UI can display a progress bar.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160142048
This change allows you to enable/disable tracks within which
all samples are key-frames without any re-buffering (e.g. audio,
text and metadata). This effectively reverts V2 back to the
behavior in V1, only this time we're doing it properly. []ly
disabling/enabling, or disabling/enabling whilst paused, no longer
cause samples to get "lost" between the source and renderers.
Note it also becomes really easy to support a few other things,
although support is not exposed in this change:
- Enable/disable video tracks without any re-buffering, by
changing the toKeyframe argument passed to discardTo to true.
- Retain media in the buffer for some time after it's been played
(e.g. to support a single back-5s-seek efficiently), by
subtracting the desired back-buffer time from the value that's
passed to discardTo.
Issue: #2956
Issue: #2926
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160128586
Make DrmSessionException takes in Throwable cause instead of Exception cause, which is more limiting and doesn't add any benefit.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=160121486
The if clause was never executed because nextLoadingPeriodIndex is set
to C.INDEX_UNSET instead of loadingPeriodIndex + 1.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159948661
It's no more complicated to avoid it, and according to the
Art team it should be faster without.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159816746
- If we have <s1>garbage<s2> and discard <s2>, throw away
the garbage too.
- Cleanup some documentation to consistently refer to the
queue as "queue" rather than "buffer".
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159816309
This will extend our CENC modes support to cbcs and cens. The change was
not split into two different CLs due to lack of test content for
default initialization vectors, aside from AES-CBCS encrypted ones.
Issue:#1661
Issue:#1989
Issue:#2089
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159810371
This was broken prior to my recent changes, since
largestDequeuedTimestampUs was only being updated in readData.
It should have been updated in the skip methods. as well.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159704945
CacheAsserts contains cache assertion methods for testing. It's easier to use in tests than DashDownloadTestBase which requires to be extended.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159688808
It's a bit messy at the moment with the deprecated methods
in there, but on the read side the new set of methods is as
follows:
Modifies the start of buffer:
- discardTo(time, keyframe, ...) [this is new]
- discardToRead()
- discardToEnd()
Modifies the read position:
- rewind()
- advanceTo(time, keyframe, ...) [this is a generalization of skipToKeyframeBefore]
- advanceToEnd() [previously called skipAll]
- read(...)
Which seems quite nice and self-consistent, and is powerful
enough for everything that we need to do as we move MediaSource
implementations over to the new methods.
TODOs for subsequent changes:
- Re-order methods in the two classes so that they're actually in
the same order, and move the deprecated ones out of the way
- Enhance SampleQueueTest to also cover new functionality, as we
start transitioning MediaSource implementations over to use it.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159688660
Made the method copy all of the fields of DataSpec in to the new instance. Also converted
it to an instance method of DataSpec for ease of usage, discovery and maintenance.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159670314
Error prone check doesn't like we pass a variable named 'end' as start parameter and 'start' as end.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159567308
At the moment, only CENC-defined scheme types are known values.
This will allow having more information about the encryption
scheme through the format, which in turn will allow more informed
decisions on format support.
Issue:#1661
Issue:#1989
Issue:#2089
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159538907
A few components in ExoPlayer requires playback looper to operate (such as:
DrmSessionManager#acquireSession), so this CL add back getPlaybackLooper()
to facilitate such cases.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159416012
(Fixing GitHub issue #2923)
Cuurently, ClippingMediaSource issues an initial discontinuity. This causes the
renderers to be disabled and re-enabled when this media source is used in a sequence
with other sources (or in a loop).
This change disables the use of an initial discontinuity for audio-only media under
the assumption that audio streams have random access capabilities.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159221963
Use an actual class for the stub media source instead of an anomymous class.
Allows to call assertReleased() on that class.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159109143
Previously, writeAllocationNode was not advanced to the
terminating node when finishing writing sample data that
fills exactly up to the end of the current write node.
This wasn't actually broken, but is confusing because it
causes edge cases where the start/read references could
temporarily refer the node after the current write node.
This change advances the write reference in this case,
removing this confusion and bringing the implementation
in line with what the design doc says happens.
Also making some simplification and consistency changes.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=159099522
This will allow us to maintain a reference to the middle
of the queue, which is necessary to efficiently support
decoupling the read position from the start of the buffer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158839336
(Preparation for GitHub issue #1706)
AbstractConcatenatedTimeline repeatly calls methods of its implementation to
query a specific child timeline. This may be inefficient if the implementation
repeatly executes the same code to find the timeline.
Changed the class such that it now queries all information at once using a meta
data class. As all methods need at least two of four variables anyway, this
doesn't generate unnecessary overhead.
Also generified the UID for the child indices to allow new implementations to
use some other UID besides the index.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158711979
The same effect can be achieved by checking the isLoading variable of ExoPlayerImplInternal
because this variable is in almost all cases set simultaneously with loadingMediaPeriodHolder.needsContinueLoading.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158697948
Separate MediaPeriodHolder.index and MediaPeriodHolder.periodIndex, so that the
latter is always a period index (which may repeat or jump) whereas the holder
index increases by one each time an item is added to the period holder queue.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158497639
Currently, media is discarded from DefaultTrackOutput
and SampleMetadataQueue as soon as it's been read. In
upcoming changes we'll decouple discard and read. This
will make it possible to retain already-read media in
these buffer classes, and allow the read position to
be moved backward as far as media is retained. This is
important for fixing an edge case around 608/EMSG
tracks, and could also underpin future features like
allowing retaining of X-seconds past media in the
buffer.
This change renames some variables and methods to
prepare for the upcoming changes. read/write indices
are renamed to start/end. The upcoming changes will
add a read index that's between the two. isEmpty is
inverted and renamed to hasNextSample, since it will
be possible to not have a next sample (because the
read index == end index) but for the buffer to not
be empty (because start index < read index).
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158409630
It's pretty big as an inner class, and is going to get a
little more complicated. I think it makes sense to be
able to consider it in isolation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158393754
This allows other tests to reuse the util classes without having to link to playbacktests.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158214560
This prevents strange behaviors for streams that changes the track declaration
order in the PMT.
NOTE: This should not change ANY behavior other than the one described above.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158140890
- Return early if the selection is unchanged.
- Remove unnecessary variables.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158138187
When updating track selection, we should only revert back from ideal
track selection to current track selection if the currently selected
track is not black-listed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158135644
1. Remove tools:replace in manifest files. This attribute is only needed to establish priority when two manifests are merged and have the same attribute with different values.
As this is not happening here, the attributes can be removed.
2. Some BUILD files also define a deprecated manifest merge strategy different from the android default merge strategy. For consistency these are set to "android'.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=158075128
This avoids calling getDecoderInfo repeatedly in the case
where shouldInitCodec return false (e.g. because we don't
have a surface and cannot instantiate a dummy surface).
Issue: #677
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157847702
This will cause the test to exercise the code path of
instantiating a DummySurface, rendering to it for 10
seconds, then re-targeting the real surface again. For
secure content tests the code path is only exercised if
DummySurface.SECURE_SUPPORTED is true. The logic for
checking this is within MediaCodecVideoRenderer itself,
rather than being part of the test.
Issue: #677
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157833026
ExoPlayer.setRepeatMode should be preferred. Deprecate
the constructor and update the relevant documentation.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157829207
This is necessary to make sure that the correct thing happens
where MediaCodecInfo.adaptive is queried directly (for example,
MediaCodecVideoRenderer uses the field to determine how to size
input buffers). Also disable adaptive on Nexus 10.
Issue: #2806
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157583473
We do this everywhere for index based seeking already.
Issue: #2876
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157568788
Use AUDIO_UNKNOWN instead. This is in line with our handling
of video tracks with VIDEO_UNKNOWN.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157209428
This fixes transitioning into the ended state if we see
endOfStream from the chunk source whilst in the pending
reset state. Prior to this fix we'd still be pending a
reset, and so readData would never allow EOS to be read
by the consuming renderer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=157101755
*** Reason for rollback ***
This change may silently introduce bugs where both parameters are acceptable in both places. It's decided that the gain isn't worth the risk.
*** Original change description ***
Make the error messages the first parameter in Assertions methods to match JUnit methods
Reverse parameter order creates a slight confusion.
***
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156844728
Expose the stream offset to BaseRenderer subclasses.
Issue: #2267
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156837514
([]
This change has been automatically generated by an Error Prone check that
detects incorrect argument ordering on calls to assertEquals-style methods. See
[]
Cleanup change automatically generated by javacflume/refactory
Refactoring: third_party/java_src/error_prone/project/core/src/main/java/com/google/errorprone/bugpatterns/argumentselectiondefects:AssertEqualsArgumentOrderChecker_refactoring
Tested:
TAP --sample for global presubmit queue
[]
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156739144
(Related to GitHub Issue #2577)
Added test to ExoPlayerTest which changes the repeat mode during playback.
Test verifies that ExoPlayer shows the periods in the intended order.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156168166
- Call onDisabled last. onDisabled really shouldn't be doing
anything with the stream, so pretty sure this is fine (and
guarantees the stream is cleared properly even if onDisabled
throws a RTE).
- Remove super.onDisabled calls from Text/Metadata renderers.
This is just for consistency; we don't make such calls in
other direct descendants of BaseRenderer.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156130640
If a timeline update removed periods at the end of the timeline which
had been buffered, handleSourceInfoRefreshed would call
getNextPeriodIndex and get back -1 for the last period holder in the
new timeline. Then isLastPeriod(-1) could throw.
Fix this behavior so that the remainder of the timeline is discarded.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=156061016
Checking the expected next/previous window indices and if the correct window
or period gets returned.
TimelineTest defines mock classes and verification methods used by the specific
implementation tests.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155727385
When readingPeriodHolder and playingPeriodHolder are both null, a
NullPointerException is thrown when trying to reassign readingPeriodHolder.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155635846
(Relating to GitHub issue #2577)
Changing the repeat mode during playback may require to discard or rebuffer
certain periods because the requested order of playback changed.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155600910
(Relating to GitHub Issue #2577)
The Timeline base class provides the default implementation.
Timeline wrappers (e.g. ClippingTimeline, ConcatatedTimeline) forward all
requests to the respective inner timelines. Some like ConcatenatedTimeline add
their own additional logic to bridge between the child timelines.
In addition, ConcatenatedTimeline and LoopingTimeline now have a common
abstract base class as they share most of their code.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155509269
Even though this is not strictly spec compliant, this will make exoplayer
behave like it used to before multiple program support. Developers
who want to take advantage of the multiple program support are probably
less than the ones who only want their stream to "just work". This is
particularly useful for streams obtained after a filtering component,
like a tv tuner.
Issue:#2757
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155486122
This will allow supporting more encryption schemes. Including some
that require more encryption data, like the encryption pattern.
Issue:#1661
Issue:#1989
Issue:#2089
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155481889
This is most commonly caused by malformed media, where
the media indicates that something we need to make an
allocation for is *really huge*. Failing playback is
appropriate for this case; killing the process is not.
Issue: #2780
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155408062
Added repeat mode toggle buttons to UI. Current mode gets forwarded to
Exoplayer instance, but without playback behaviour changes yet.
Translations for button descriptions are also missing - this will be another CL.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155386549
The default byte order for ByteBuffers is big endian, but platform decoder
output buffers use native byte order. AudioProcessors handle native byte order
input/output.
When using a software audio decoding extension the Sonic audio processor would
receive big endian input but was outputting to a native byte order buffer,
which could be little endian. This mismatch caused audio output to be
distorted.
After this change both platform decoder and extension decoder output buffers
should be in native byte order.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155320973
If the codec isn't adaptive, there's no need to accommodate
the width/height/input-size of streams that don't have the
same resolution as the current stream. This is because we'll
always need to instantiate a new codec anyway.
Issue: #2607
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155194458
(Relating to GitHub Issue #2577)
All getter, setter and callbacks have been added and value of repeatMode is
passed to getNextXXXIndex methods.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=155071985
A DummySurface is useful with MediaCodec on API levels 23+.
Rather than having to release a MediaCodec instance when the
app no longer has a real surface to output to, it's possible
to retain the MediaCodec, using MediaCodec.setOutputSurface
to target a DummySurface instance instead. When the app has
a real surface to output to again, it can call swap this
surface back in instantaneously. Without DummySurface a new
MediaCodec has to be instantiated at this point, and decoding
can only start from a key-frame in the media.
A future change may hook this up internally in MediaCodecRenderer
for supported use cases, although this looks a little awkward. If
this approach isn't viable, we can require applications wanting
this to set a DummySurface themselves. This isn't easy to do with
the way SimpleExoPlayerView.setPlayer works at the moment, however,
so some changes will be needed either way.
Issue: #677
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154931778
Looper.myLooper(), the default looper, may be null in background threads. This adds a fallback to use the main app looper.
This will allow ExoPlayer instances to be built in background threads in Photos.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154845446
Using the new getNextWindowIndex method of Timeline, LoopingMediaSource now
uses a InfinitelyLoopingTimeline which does not unroll the windows to
157 million iterations but just starts from the beginning. If an explicit
number of iterations is given, we still unroll.
This change also allows multi-window timebars to show infinitely looping
playlists correctly.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154817554
(Preparation for Repeat Toggle Function - GitHub Issue #2577)
In addition, Timeline now also got a getPreviousWindowIndex and a
getNextPeriodIndex method with default implementations.
Changed ExoPlayerImplInternal and PlaybackControlView to use these
methods at all occurances of period and window index operations.
Note: Does not include repeat mode yet and no timelines are actually
using it so far. Please wait for the next CLs for this.
-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=154520664
