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
